하이퍼레저 패브릭 - Peer

Peer?

• 각 Peer별로 Ledger와 Chaincode를 모두 가진다.

• Peer은 하나 이상의 Ledger를 호스팅할 수 있다.

애플리케이션 및 Peer

• 애플리케이션은 Ledger 및 체인코드에 엑세스할 때 항상 Peer에 연결한다.

• Fabric SDK를 사용하면 이를 쉽게 수행할 수 있다.

• Ledger의 query는 즉시 반환되지만, Invoke(Update)의 경우 보다 복잡한 절차를 가진다.

Query 밑 Invoke(Upate) 과정

1. 애플리케이션은 Peer(P1)와 연결한다.

2. Peer은 체인코드를 호출하여 제안 응답(proposal response)을 생성한다.

3. 애플리케이션은 제안 응답을 수신한다. → Query의 경우, 프로세스는 여기까지가 끝이다. (밑은 Update의 경우 수행)

4. 애플리케이션은 트랜잭션을 작성하여 Orderer에게 주문을 보낸다. Orderer는 모든 Peer에게 트랜잭션을 배포한다. Peer은 Ledger에 커밋하기 전 트랜잭션의 유효성을 검사한다.

5. Ledger가 성공적으로 업데이트 되면 Peer은 애플리케이션에게 업데이트 완료를 나타내는 이벤트를 생성한다.

• 업데이트 트랜잭션은 쿼리 트랜잭션에서 두 가지의 추가 단계(4, 5)가 있다

• Query때와 달리 개별 Peer가 Ledger Update를 수행할 수 없다(합의 과정이 필요함). Orderer를 사용함으로써 합의 프로세스를 진행할 수 있다.

Channel 및 Peer

• Peer들은 채널을 통해 서로 통신할 수 있다.

• Peer 노드, Orderer 노드, 응용 프로그램 등이 채널에 가입하여, 해당 채널과 연결된 동일한 복사본을 집합적으로 공유하고 관리하기 위해 협력한다.

Organization 및 Peer

• 블록체인 네트워크는 단일 조직이 아닌 여러 조직에서 관리한다.

• 블록체인 네트워크는 리소스를 제공하는 여러 조직에 의해 형성되고 관리한다. 하단의 이미지에는 Orderer 노드는 표시되지 않았다.

Identity 및 Peer

• Peer는 인증 기관의 디지털 인증서(X.509)를 통해 할당받은 ID가 있다. 네트워크의 모든 Peer은 소유 조직의 관리자가 디지털 인증서를 할당한다.

• Peer가 채널에 연결할 때 해당 디지털 인증서는 채널 MSP를 통해 Org를 식별한다. 예를 들면, 채널 C에서의 채널 구성 정책에 따라 CA1에서 발급한 ID를 가지고 있는 P1와 P2는 ORG1.MSP를 통해 Org1의 멤버라고 식별된다.

• Peer가 채널을 사용하여 블록체인 네트워크에 연결할 때마다 채널 구성의 정책(Policy)은 피어의 ID를 사용하여 권한을 결정한다.

• Peer뿐만 아니라 Orderer, 애플리케이션, 사용자들도 블록체인 네트워크와 상호작용을 하려면 ID와 관련 MSP가 있어야 한다.

Orderer 및 Peer

• 응용 프로그램과 Peer가 서로 상호작용하며 모든 Peer의 Ledger가 서로 일관성을 유지하도록 하는 매커니즘은 Orderer에 의해 이루어진다.

• 위에서 본 것처럼 Query와 달리, Update는 단일 Peer가 할 수 없고 다른 Peer의 동의가 필요하다. → 이를 합의(consensus)라고 한다. Peer와 Orderer가 합의 프로세스를 관리하는데, 이 프로세스는 3단계로 이루어진다.
• 첫 단계에서, 애플리케이션은 endorsing Peer의 하위 집합과 함께 작동하며, 각 Peer는 제안된 Ledger 업데이트에 대한 보증을 제공하지만 Ledger 사본에 적용시키지는 않는다.
• 두 번째 단계에서, 이러한 개별 보증(endorsement)은 트랜잭션으로 수집되고, 블록으로 패키징된다.
• 세 번째 단계에서, 이 블록은 각 트랜잭션이 해당 Peer의 Ledger 사본에 커밋되기 전 유효성이 검사되는 모든 Peer에 다시 배포된다.

Orderer와 Peer의 Detail Process

1. Proposal(제안)
[첫 번째 단계에서는 응용 프로그램과 Peer 사이의 상호 작용이 포함된다. Orderer는 포함되지 않는다.]



1. 애플리케이션은 endorsement(승인)을 위해 필요한 각 Peer 집합에 트랜잭션 Proposal을 생성한다.
2. 각 endorsing Peer은 트랜잭션 Proposal을 사용하여 체인코드를 독립적으로 실행하여 애플리케이션에 보낸다. 이 업데이트는 Ledger에 적용시키지는 않는다.
3. 애플리케이션이 Proposal 응답을 수신하면 첫 단계는 완료된다.
 
2. 트랜잭션을 블록으로 주문 및 패키징
이 프로세스에 대해 더 자세한 설명은 Ordererd 문서에 정리
 
1. 유효성 검사 및 커밋
이 프로세스에 대해 더 자세한 설명은 Ordererd 문서에 정리