[Hyperledger Fabric] Peer 설명

Peer

Peer는 장부 상태 (Ledger State)와 체인코드 (Chaincode)를 관리하는 네트워크 노드입니다.

블록체인 네트워크는 Peer들의 집합으로 이루어져 있습니다.

Peer들은 Ledgers와 Chaincode(Smart Contracts)에 대해 호스팅하기에 블록체인 네트워크의 기본적인 요소입니다.

Ledger(장부)는 Chaincode(Smart Contracts)로 인해 발생하는 모든 거래를 불변하게 기록하게 됩니다.

Chaincode와 Ledger는 각각 공유 프로세스와 정보를 네트워크에 캡슐화하는데 사용됩니다.

블록체인 네트워크는 Peer로 구성되며 각 Peer는 Ledger 사본과 Chaincode 사본을 보유 할 수 있습니다.

위 그림은 네트워크 N은 Peer P1, P2, P3로 구성되어 있으며 각 Peer는 분산 Ledger L1의 자체 인스턴스를 유지 관리합니다.

P1, P2, P3는 동일한 Chaincode S1을 사용하여 L1 사본에 엑세스 합니다.

Multiple Ledgers

Peer는 둘 이상의 ledger를 호스팅 할 수 있으므로 유연한 시스템 설계가 가능합니다. 단순한 구성은 Peer가 단일 Ledger를 관리하는 것이지만 필요할 때는 둘 이상의 Ledger를 호스팅하는 것이 적합합니다.

위 그림은 여러 Ledger를 호스팅하는 Peer를 나타내고 있습니다. Peer는 하나 이상의 Ledger를 호스팅 하고 각 ledger는 0개 이상의 Chaincode가 적용됩니다. Peer P1이 Ldeger L1, L2를 호스팅하고 있으며, Ledger L1은 Chaincode S1을 사용하여 엑세스 됩니다.

L2는 Chaincode S1, S2를 사용하여 엑세스 할 수 있습니다.

Multiple Chaincodes

Peer가 가지고 있는 Ledger의 수와 해당 Ledger에 접근할 수 있는 Chaincode의 수는 고정되어 있지 않습니다.

Peer는 많은 Chaincode와 Ledger를 사용할 수 있습니다.

Applications and Peers

Peer는 Orderer와 함께 모든 Ledger에게 최신 상태로 유지되도록 합니다. 위 그림에서 Application A는 Peer P1에 연결하고 Chaincode S1을 호출하여 Ledger L1을 query 또는 update를 합니다. P1은 S1을 호출하여 query의 결과 또는 Proposal된 Ledger 갱신을 포함하는 Proposal Response를 생성합니다. Application A는 Proposal Response를 수신하고 query의 경우 프로세스가 완료됩니다. update의 경우 A는 모든 Response에 대해 Transaction을 생성하여 Order를 위해 Orderer에 전송하게 됩니다. Orderer O1은 수집한 Transaction을 모든 피어에 배포하여 P1은 L1에 적용하기 전에 Transaction의 유효성을 검사합니다. L1이 업데이트가 되면 P1은 A가 수신 할 수 있는 이벤트를 생성하고 완료가 됩니다.

Peer는 query 요청에 만족 시킬 수 있는 모든 정보가 Peer`s Ledger 사본에 있으므로 query 결과를 즉시 Application에 반환 할 수 있습니다. 또한 Query를 위해 다른 Peer들과 통신을 할 필요도 없습니다. 그러나 Application은 하나 이상의 Peer를 연결하여 Query를 발행 할 수 있습니다. 예를 들어 여러 Peer간에 결과를 확증하거나 정보가 오래되었다는 의심이 들 경우 다른 Peer들에서 최신 결과를 검색 할 수 있습니다.

Update Transaction은 Query Transaction와 동일한 방식으로 시작되지만 두가지 추가적인 단계가 있습니다. 

Ledger Update Application은 Ledger Query Application과 달리 체인 코드를 호출하기 위해 Peer에 연결되지만, 개별 Peer에 Ledger를 업데이트 수행 할 수 없습니다. 왜냐하면 다른 Peer들이 먼저 변경사항에 대해서 동의를 해야하기 때문입니다.

동의 하는 절차를 합의라고 부릅니다. 따라서 Peer는 Proposal update(다른 Peer들에게 사전 동의를 받아 적용 될 업데이트)를  Application에 반환합니다. Application은 Proposal update와 일치하는 적절한 집합을 Peer 전체 네트워크에 보내어 각 Ledger에 대해 Commit을 위해 Transaction을 요구합니다.

이것은 Orderer를 사용하여 Transaction을 블록으로 패키징하고 이를 Peer의 전체 네트워크에 분배하여 각 Peer의 Ledger 사본에 적용되기 전에 확인 할 수 있습니다. 이 전체 Order 처리가 완료되는 몇시간이 걸리므로 Application은 비동적으로 응답을 전해받습니다.

Peers and Channels

Channel -- 블록체인 네트워크 내의 구성요소로, 개인적으로 팅신하고 거래를 할 수 있는 매커니즘

위 구성요소는 일반적으로 Peer, Orderer, Application이며, 채널에 가입함으로써 공동 작업을 통해 해당 채널에 연결된 Ledger의 동일한 복사본을 공동으로 공유하고 관리하는데 동의되어 집니다.

개념으로 채널은 친구 그룹과 유사하다고 생각 할 수 있습니다. 한 사람에게는 여러 그릅의 친가 있을 수 있으며, 각 그룹에는 함께하는 활동이 있듯이..

채널을 사용하면 특정 Peer 및 Application 집합이 블록체인 네트워크 내에서 서로 통신할 수 있습니다. 위 그림은 Application A가 채널 C를 사용하여 Peer P1, P2를 직접 통신 할 수 있게 하는 것입니다. 채널은 특정 Application과 Peer간의 통신 경로라고 생각할 수 있습니다.

Peers and Organizations

블록체인 네트워크는 단일 조직이라기보다는 조직의 집합에 의해 관리가 됩니다. Peer들은 이러한 종류의 분산 네트워크가 어떻게 구성되어있는지에 대한 핵심 역할을 하게 됩니다.

여러 조직과 블록체인 네트워크에 있는 Peer들, 볼륵체인 네트워크는 소유된 Peer들과 조직들의 기여로 구성되어 집니다. 

위 그림은 네트워크 형성을 위해 4개의 조직에 기여가 되는 8개의 Peer를 볼 수 있습니다.

채널 C는 블록체인 네트워크 N에서 P1, P3, P5, P8을 연결합니다. C채널에 가입하지 않았지만 일반적으로 모든 Peer는 하나 이상의 채널에 가입을 합니다. 특정 조직에서 개발한 Application은 다른 조직의 Application과 마찬가지로 자신의 조직 Peer와 연결되게 됩니다.

네트워크는 리소스를 제공하는 여러 조직에 의해 형성되고 관리 되어집니다. Peer는 이 항목에서 논의 중인 리소스이지만 조직에서 제공해주는 리소스는 단순한 것 이상입니다. 네트워크는 말 그대로 조직이 개별 리소스를 집단 네트워크에 기여하지 않으면 존재하지 않습니다.

위 그림에서 조직이 Peer를 제공하지 않을 경우 네트워크가 존재하지 않다는 걸 알 수 있는데, 즉 중앙 리소스가 존재하지 않다는 뜻입니다. 이것은 조직에서 리소스를 제공 할 때까지 그리고 조직이 리소스를 기여할 때까지 네트워크가 딱히 의미가 없다는 사실을 반영합니다. 또한 네트워크는 개별 조직에 종속되어 있지않아, 어떤 조직이 출입을 하든 조직이 남아 있다면 네트워크는 계속 존재할 것입니다. 이것은 네트워크가 분산화된다는 걸 의미하고 있습니다.

또한 위 그림에서와 같이 다른 조직의 Application은 동일하거나 다를 수 있습니다. 왜냐하면 Application이 Peer의 Ledger 사본을 어떻게 처리하는지는 조직에 의해서 결정됨으로, 각각의 Peer가 정확히 동일한 Ledger Data를 호스팅하더라도 Application 논리와 표시 논리가 조직마다 다를 수 있다는 것입니다.

Application은 필요한 Ledger 상호작용의 특성에 따라 조직의 Peer 또는 다른 조직의 Peer와 연결됩니다. Ledger query의 경우 일반적으로 Application이 자체 조직의 Peer와 연결되지만 update의 경우 Ledger update 승인을 위해 필요한 모든 조직의 대표하는 Peer에게 Application을 연결합니다.

Peers and Identity

Peer는 특정 인증 기관의 디지털 인증서를 통해 자신에게 할당되는 ID를 가지게 됩니다.

네트워크의 모든 Peer들은 소유 조직의 관리자가 디지털 인증서를 통해 할당을 합니다.

Peer가 채널에 연결되면 디지털 인증서는 채널 MSP를 통해 소유 조직을 식별합니다.

HyperLedger Fabric에는 멤버십 서비스 프로바이더(Membersip Service Provider, MSP)가 존재합니다. MSP는 신분증 역할을 한다고 생각하면 이해하기 쉽습니다. 위 그림은 P1, P2가 CA1에서 발행한 ID를 가집니다. 채널 C는 채널 구성의 정책에서 CA1의 ID가 ORG1.MSP를 사용하여 Org1과 연관되어야 한다고 결정합니다. 마찬가지 P3, P4는 ORG2.MSP에 의해 Org2의 일부로 식별됩니다.

Peer가 채널을 사용하여 블록체인 네트워크에 연결할 때마다 채널 구성 정책은 Peer의 ID를 사용하여 권한을 결정합니다. MSP는 조직에 대한 ID의 매핑을 담당하며, Peer가 특정 조직의 특정 역할에 할당되는 방식을 결정하고 따라서 블록체인 리소스에 대한 적절한 엑세스 권한을 얻습니다. 또한 Peer는 단일 조직에서만 소유 할 수 있으므로 단일 MSP와 연결됩니다.

Peer 및 블록체인 네트워크와 상호작용하는 모든 것은 디지털 인증서와 MSP에서 조직 신원을 획득합니다.

블록체인 네트워크와 상호작용을 하려는 경우 Peer, Application, end user, 관리자, Orderer는 ID 및 관련 MSP가 존재해야합니다. 신원을 사용하는 블록체인 네트워크와 상호 작용하는 모든 엔티티, 즉 주체에 이름을 부여합니다.

마지막으로 Peer가 실제로 위치하는 곳은 중요하지 않습니다. 클라우드 또는 조직 중 하나가 소유한 데이터 센터나 로컬 시스템에 위치 할 수 있습니다. 특정 조직이 소유하고 있다는 것을 식별만 하면 됩니다.

Peers and Orderers

우리는 Peer들이 Peer와 연결된 Application에 의해 Query 또는 Update 될 수 있는 Ledger과 Chaincode를 호스팅하는 블록 체인 네트워크의 기반을 형성하는 것을 확인하였습니다. 그러나 Application과 Peer가 서로 상호작용하여 모든 Peer's Ledger이 일관성을 유지하도록 하는 매커님은 Orderer라는 특수 노드가 중재합니다.

Update Transaction은 단일 Peer가 자체적으로 Ledger을 업데이트 할 수 없기 때문에 Query Transaction과 상당히 다릅니다. Update를 하려면 네트워크의 다른 Peer들의 동의가 필요합니다. 이 프로세스를 합의라고 하며, 간단한 query보다 완료하는데 훨씬 많은 시간이 걸립니다. 그러나 Transaction을 승인해야 하는 모든 Peer가 승인을 할 경우 Transaction이 Leger에 맡겨지며 Peer는 연결된 Application에 Ledger가 갱신되었음을 통보합니다.

Ledger를 업데이트하려는 Application은 3단계 프로세스와 관련되어 있어 블록체인 네트워크의 모든 Peer가 Ledger를 서로 일관되게 유지 할 수 있습니다.

1단계 : Proposal

Transaction work flow의 1단계에는 Application과 Peer들 사이의 상호 작용이 포함되어 있으나 Orderer는 포함되어 있지 않습니다. 1단계는 Proposal Chaincode 호출 결과에 동의하도록 다른 조직의 승인을 해야하는 Peer에게 요청하는 Application에 대한 내용입니다.

1단계를 시작하기 위해 Application은 Transaction Proposal을 생성하여 보증을 위해 필요한 Peer들에게 전송합니다. 그런 다음 각 Peer들은 Transaction Proposal를 사용하여 Chain Proposal를 독립적으로 실행하여 Transaction Proposal Response를 생성합니다. 이 업데이트는 Ledger에 적용되지 않고 단순히 서명만 한 후 Application에 반환됩니다. Application에 충분한 수의 서명된 Response가 받아지면 1단계 Transaction work flow가 종료 됩니다.

Transaction Proposal은 승인된 Response를 반환하는 peer에 의해 독립적으로 실행됩니다. 위 예에서 어플리케이션 A1은 트랜잭션 T1 제안서 P를 생성하여 채널 C에 P1, P2 모두에게 전송합니다. P1은 트랜잭션 T1 제안서 P를 사용하여 S1을 실행하여 E1에서 보증하는 트랜잭션 T1과 응답 R1을 생성합니다. 독립적으로 P2는 트랜잭션 T1 제안서 P를 사용하여 S1을 실행하고 E2로 보증하는 트랜잭션 T1 응답 R2를 생성합니다. 응용 프로그램 A1은 트랜잭션 T1에 대해 두개의 승인된 응답, 즉 E1, E2를 받습니다.

처음에는 일련의 Proposal Ledger Update를 생성하기 위해 Application이 Peer들을 선택합니다. 그렇다면 어떤 Peer들이 선택이 될까요? 보증정책으로 인해 결정 됩니다. 이것은 사실상 합의를 달성한다는 것을 의미합니다. 승인을 해야되는 Peer의 조직들은 모두 변경되기 전에 승인을 해야합니다.

 

Peer는 디지털 서명을 추가하고 개인 키를 사용하여 전체 페이로드에 서명하여 Proposal Response을 승인합니다. 이 승인 이후에 이 조직의 Peer가 특정 Response를 생성했음을 입증하는데 사용될 수 있습니다. 위 예에서 Peer P1이 조직 Org1에 의해 소유된 경우 보증 E1dms "Ledger L1의 Transaction T1 Response이 Org1의 Peer P1에 의해 제공되었습니다." 라는 증거가 됩니다.

1단계는 Application이 충분한 Peer로부터 보증된 Proposal Response를 받으면 끝이납니다.  우리는 다른 Peer들이 동일한 Transaction Proposal에 대해 Application에 대해서 서로 다르기때문에 일치 하지 않는 Response가 반환 될 수 있음을 알아둬야 합니다. Chaincode가 비결정적이므로 결과가 다를 수 있습니다. 

1단계가 끝나면 Application은 일관성 없는 Transaction Response를 자유롭게 버리고 이를 원할 경우 Transaction work flow를 효과적으로 종료합니다. 또한 Application이 일치하지 않는 Transaction Response를 사용하여 원치 않는 업데이트하려고하면 거부 될 것입니다.

2단계 : Packaging

Transaction work flow의 두번째 단계는 패키징입니다. Orderer는 이 프로세서의 중추적인 역할을 합니다. 많은 Application에서 승인 된 Response를 포함하는 Transaction을 받습니다. 그것은 각 Transaction을 다른 Transaction과 비교하여 order(정렬)하고, Transaction의 일괄처리를 원래의 승인하는 Peer를 포함하여 Orderer에게 연결된 모든 Peer에게 배포할 준비가 된 블록으로 패키징하는 것입니다.

Orderer의 첫번째 역할은 Proposal Ledger Update를 패키징하는 것입니다. 이 예에서 응용 프로그램 A1은 E1 및 E2가 승인한 트랜잭션 T1를 Orderer O1에게 전송합니다. 병렬로, 응용 프로그램 A는 E1이 승인한 트랜잭션 T2를  Orderer O1에게 전송합니다. O1은 응용 프로그램 A1의 트랜잭션 T1과 응용 프로그램 A2의 트랜잭션 T2를 네트워크의 다른 응용 프로그램에서 받은 다른 트랜잭션과 함께 B2 블록으로 패키징합니다. B2에서 트랜잭션 순서는 T1, T2, T3, T4, T6, T5입니다. 이러한 트랜잭션이 Orderer 도착한 순서와 다를 수 있습니다.

Orderer는 특정 채널의 네트워크에 있는 많은 다른 응용 프로그램으로부터 제안 된 원장 갱신을 동시에 받습니다. 이 작업은 제안 된 업데이트를 잘 정의 된 순서로 정렬 한 다음 후속 포를 위해 블록으로 패키지화 하는 것입니다. 그리고 이 블록은 블록체인의 블록이 됩니다. 일단 Orderer가 원하는 크기의 블록을 생성하거나 최대 경과 시간 후에 블록은 특정 채널에서 연결된 모든 Peer로 전송됩니다. 

3단계 : Vaildation

Transaction work flow의 최종단계는 Orderer에서 Peer에게 블록을 배포하고 이후에 유효성 검사를 수행하여 Ledger에 적용하는 것입니다. 특히, 각 Peer에서 블록 내의 모든 Transaction은 Ledger에 적용되기 전에 모든 관련 조직에 일관되게 보증되도록 유효성이 검사 됩니다. 실패한 Transaction은 검사를 위해 보유는 하고 있지만 Ledger에 적용되지는 않습니다.

Orderer의 두번째 역할은 Peer들에게 블록을 배포하는 것입니다. 위 예에서는 Orderer O1은 블록 B2를 P1과 P2에 분배합니다. P1은 B2를 처리하여 새로운 블록이 L1에 추가되게 합니다. 병렬적으로 P2는 B2가 L1에 추가되게 합니다. 이 프로세스가 완료되면 L1이 P1, P2에 일괄되게 업데이트되고 각각 연결 된 Application에 Transaction이 처리되었음을 알릴 수 있습니다.

3단계는 Orderer가 블록을 연결된 모든 Peer들에게 배포하는 것으로 시작합니다. Peer는 새로운 블록이 생성되면 Orderer에게 연결된 모든 피어가 새 블록의 사본을 받을 수 있도록 채널에 Orderer를 연결합니다. 각 Peer들은 이 블록을 독립적으로 처리하지만 채널의 다른 모든 Peer와 정확히 같은 방식으로 처리합니다. 모든 Peer가 Orderer와 연결 될 필요는 없습니다. Peer는 gossip 프로토콜을 사용하여 블록을 다른 Peer에게 종속 시킬 수 있습니다.

블록을 수신하면 Peer는 각 Transaction을 블록에 나타나는 순서대로 처리합니다. 모든 Transaction에 대해 각 Peer는 보증정책에 따라 필요한 조직이나 Transaction을 승인했는지 확인합니다. Transaction을 생성한 Chaincode의 예를 들어, 일부 Transaction은 단일 조직이 보증해야하는 반면에, 다른 Transaction은 여러 조직의 보증을 요구 할 수 있습니다. 이 유효성 검사 프로세스는 모든 관련 조직 또는 결과를 생성했음을 검증합니다. 또한 유효성 검증은 1단계 보증확인과 다르다는 것을 유의 해야합니다. 위 검증은 승인하는 Peer로부터 응답을 수신하고 Proposal Transaction을 전송하기로 결정하는 Application입니다.

Peer는 각각의 개별 Transaction의 유효성을 성공적으로 확인 후 Ledger에 업데이트합니다. 실패한 Transaction은 Ledger에 적용되지 않지만 성공적인 Transaction 검사 목적으로 유지됩니다. 

유효성 검사는 체인 코드를 실행할 필요가 없습니다. 체인 코드가 블록체인 네트워크 전체가 아닌 승인 노드에서만 사용 가능해야 한다는 것을 의미합니다. 이는 체인 코드의 논리가 조직을 지지하는데 기밀로 유지되도록 도움이 되는 경우가 종종 있습니다. 이는 거래를 승인했는지 여부에 관계없이 채널의 모든 피어와 공유되는 체인코드의 출력과 대조됩니다.

 

마지막으로 블록이 피어의 장부에 커밋 될때마다 해당 피어는 적절한 이벤트를 생성합니다. 블록 이벤트에는 전체 블록의 컨텐츠가 포함되며 블록 트랜잭션 이벤트에는 블록의 각 트랜잭션의 유효성이 검증되었는지 유효하지 않은지 여부와 같은 요약 정보만 포함됩니다. 체인코드 실행이 생성한 체인 코드 이벤트도 이 시간에 게시 할 수 있습니다. 응용프로그램은 이러한 이벤트 유형에 대해 등록 할 수 있으므로 이벤트 유형이 발생할 때 이를 알릴 수 있습니다. 이러한 통지는 트랙재션의 워크 플로의 세번째이자 마지막 단계입니다.

 

 

Orderer and Consensus

 

이 전체 트랜잭션 워크 프로세스는 합의자라고하며, 모든 피어가 Orderer가 중재하는 프로세서에서 트랜잭션의 순서 및 내용에 대한 합의에 도달합니다. 합의는 다단계 프로세스이며, 응용 프로그램은 프로세스가 완료 될 때까지 원장 업데이트만 통보 됩니다.