[Hyperledger Fabric v1.1] 2. Key Concepts: Peers

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/peers/peers.html

블록 체인 네트워크는 주로 피어 노드 집합으로 구성됩니다. 원장은 원장 및 Smart Contract를 호스팅하는 이유로 네트워크의 기본 요소입니다. 장부는 Smart Contract에 의해 생성 된 모든 트랙잭션을 수정 불가능 하도록 기록한다는 점을 기억하셔야합니다. Smart Contract 및 원장은 공유 프로세스와 정보 를 각각의 네트워크 에 캡슐화하기 위해서 사용됩니다 . 피어의 이러한 측면은 Hyperledger Fabric 네트워크를 이해하는 데 좋은 시작점이됩니다.

원장 및 Smart Contract, Orderer, 정책, 채널, 어플리케이션, 조직, ID 및 멤버십과 같은 블록 체인 네트워크의 다른 요소도 물론 중요합니다. 그리고 자신의 전용 토픽에 대해 자세히 알아볼 수 있습니다. 이 토픽는 피어 및 Hyperledger Fabric 블록 체인 네트워크의 다른 요소와의 관계에 중점을 둡니다.

블록 체인 네트워크는 피어 노드로 구성되며 각 노드는 원장 및 Smart Contract 사본을 보유 할 수 있습니다. 이 예시를 보시면 네트워크 N은 피어 P1, P2 및 P3에 의해 형성됩니다. P1, P2 및 P3은 각각 원장 L1의 자체 인스턴스를 유지합니다. P1, P2, P3는 체인 코드 S1을 사용하여 원장 L1 사본에 액세스합니다.

피어는 생성, 시작, 중지, 재구성 및 삭제할 수 있습니다. 관리자와 어플리케이션이 제공하는 서비스와 상호 작용할 수있는 일련의 API를 제공합니다. 이 주제에 대한 자세한 내용은 이 서비스를 참조하십시오.

전문 용어

Hyperledger Fabric은 chaincode 라고하는 기술 개념을 사용하여 Smart Contract을 구현합니다. Smart Contract란 지원되는 프로그래밍 언어 중 하나로 작성된 원장에 접근하는 간단한 코드입니다. 이 주제에서는 일반적으로 chaincode 라는 용어를 사용하겠지만, 이 용어를 사용하는 것이 익숙하시다면 Smart Contract 토픽을 읽으십시오 . 물론 Chaincode와 Smart Contract는 같은 주제입니다.

원장 및 체인 코드

피어를 조금 더 자세히 살펴 보겠습니다. 원장과 체인 코드를 모두 호스트하는 것이 피어임을 알 수 있습니다. 더 정확하게, 피어는 실제로 Instance 원장과 Instance chaincode를 호스팅합니다. 이는 Fabric 네트워크에서 고의적 이중화를 제공합니다. 그리고 그로 인해 단일 실패 지점을 피할 수 있습니다. 이 주제의 뒷부분에선 블록 체인 네트워크의 분산 된 특성에 대해 더 배우게됩니다.

피어는 원장의 인스턴스와 체인 코드의 인스턴스를 호스팅합니다. 이 예에서 P1은 원장 L1의 인스턴스와 체인 코드 S1의 인스턴스를 호스팅합니다. 개별 피어에서 호스팅되는 다양한 원장과 체인 코드가 있을 수 있습니다.

피어는 원장 및 체인 코드 의 호스트 이기 때문에 애플리케이션 및 관리자는 이러한 리소스에 액세스하려는 경우 피어와 상호 작용해야합니다. 이것이 피어가 Hyperledger Fabric 블록 체인 네트워크의 가장 기본적인 빌딩 블록으로 간주되는 이유입니다. 피어가 처음 만들어지면 원장이나 체인 코드를 가지고 있지 않습니다. 원장이 어떻게 생성되고 체인 코드가 설치되는지 나중에 알게 될 것입니다.

복수 원장

피어는 둘 이상의 원장을 호스팅 할 수 있고 유연한 시스템 설계가 가능해서 도움이됩니다. 가장 단순한 피어 구성은 하나의 원장을 갖는 것이지만 필요에 따라 피어가 둘 이상의 원장을 호스팅하는 것이 적합할 때도 있습니다.

여러 원장을 호스팅하는 피어입니다. 피어는 하나 이상의 원장을 호스팅하고 각 원장에는 0 개 이상의 체인 코드가 적용됩니다. 위의 사진에서 피어 P1이 원장 L1 및 L2를 호스팅한다는 것을 알 수 있습니다. 원장 L1은 체인 코드 S1을 사용하여 액세스됩니다. 원장 L2는 체인 코드 S1 및 S2를 사용하여 액세스 할 수 있습니다.

피어가 액세스하는 체인 코드를 호스팅하지 않고 원장 인스턴스를 호스팅하는 것이 완벽하게 가능할 수도 있지만 피어가 이와 같이 구성되는 것은 매우 드뭅니다. 대다수의 피어는 피어의 원장 인스턴스를 쿼리하거나 업데이트 할 수있는 체인 코드가 하나 이상 설치됩니다. 사용자가 외부 어플리케이션에서 사용할 수 있도록 체인 코드를 설치했는지에 대한 여부를 전달하는 것에 있어 언급 할 가치가 있으며, 피어는 항상 존재하는 특별한 시스템 체인 코드 도 가지고 있습니다 . 이 항목에서는 이러한 항목에 대해 자세히 설명하지 않습니다.

다중 Chain Code

피어가 가지고있는 원장의 수와 해당 원장에 액세스 할 수있는 체인 코드의 수 사이에는 고정된 관계가 없습니다. 피어는 많은 체인 코드와 많은 원장을 사용할 수 있습니다.

여러 체인 코드를 호스팅하는 피어의 예입니다. 각 원장에는 다수의 체인 코드가있어 액세스 할 수 있습니다. 이 예에서 피어 P1은 원장 L1 및 L2를 호스팅한다는 것을 알 수 있습니다. L1은 체인 코드 S1 및 S2에 의해 액세스되는 반면 L2는 S3 및 S1에 의해 액세스됩니다. S1은 L1과 L2 모두에 액세스 할 수 있음을 알 수 있습니다.

우리는 이후 피어에게 여러 원장이나 여러 개의 체인 코드를 호스팅 할 때 Hyperledger Fabric 의 Channel 개념 이 중요한 이유를 알아 보겠습니다.

어플리케이션 및 피어

이제 어플리케이션이 피어와 상호 작용하여 원장에 액세스하는 방법을 보여 드리겠습니다. 원장 - 쿼리 상호 작용에는 어플리케이션과 피어간에 간단한 3 단계 대화가 포함됩니다. 장부 - 갱신 상호 작용은 좀 더 복잡하고 두 가지 추가 단계가 필요합니다. Hyperledger Fabric을 시작하는 데 도움이 되도록 단계를 단순화했지만 걱정하지 마십시오. 원장 쿼리의 원장 업데이트 트랜잭션 스타일과 비교하여 어플리케이션 - 피어 상호 작용의 차이점을 이해하는 것이 가장 중요합니다.

원장 및 체인 코드에 액세스해야하는 경우 항상 피어에 연결됩니다. Hyperledger Fabric Software Development Kit(SDK)을 사용하면 프로그래머가 쉽게 어플리케이션을 작성할 수 있습니다. API를 사용하여 어플리케이션에서 피어에 연결하고 체인 코드를 호출하여 트랜잭션을 생성하고 네트워크에 트랜잭션을 제출하여 주문을 받고 분산 원장에게 커밋하고 이벤트를 수신 할 수 있을 때 이 과정이 완료된 것입니다.

피어 연결을 통해 어플리케이션은 체인 코드를 실행하여 장부를 쿼리하거나 업데이트 할 수 있습니다. 장부 쿼리 트랜잭션의 결과는 즉시 반환되는 반면 원장 업데이트는 어플리케이션, 피어 및 Orderer의 상호작용보다 더욱 복잡한 상호 작용을 수반합니다. 조금 더 자세하게 조사해 봅시다.

피어는 Orderer와 함께 모든 원장에게 장부가 최신 상태로 유지되도록합니다. 이 예제에서 어플리케이션 A는 P1에 연결하고 체인 코드 S1을 호출하여 원장 L1을 쿼리하거나 업데이트합니다. P1은 S1을 호출하여 쿼리 결과 또는 제안 된 원장 갱신을 포함하는 제안 응답을 생성합니다. 어플리케이션 A가 제안 응답을 받고 쿼리에 대해 프로세스가 완료되었습니다. 업데이트의 경우 A는 모든 응답에서 트랜잭션을 작성하고 주문을 위해 O1로 전송합니다. O1은 네트워크에서 블록으로 트랜잭션을 수집하여이를 P1을 포함한 모든 피어에 배포합니다. P1은 L1에 적용하기 전에 트랜잭션의 유효성을 검사합니다. L1이 업데이트되면, P1은 A가 수신 한 이벤트를 생성하여 완료를 나타냅니다.

피어는 쿼리 요구에 필요한 모든 정보가 피어의 원장 사본에 있으므로 쿼리 결과를 즉시 어플리케이션에 반환 할 수 있습니다. 피어는 다른 피어와 소통하여 어플리케이션에 쿼리를 반환하지 않습니다. 그러나 어플리케이션은 하나 이상의 피어에 연결하여 쿼리를 발행 할 수 있습니다. 예를 들어 여러 피어간에 결과를 확증하거나 정보가 부족한 것으로 의심되는 경우 다른 피어에서 최신 결과를 검색 할 수 있습니다. 날짜. 다이어그램에서 원장 쿼리는 간단한 3 단계 프로세스임을 알 수 있습니다.

업데이트 트랜잭션은 쿼리 트랜잭션과 동일한 방식으로 시작되지만 두 가지 추가 단계가 있습니다. 이라는 프로세스 - 원장 - 어플리케이션 업데이트도 원장 - 쿼리 어플리케이션과 달리 chaincode를 호출하는 피어에 연결할 수 있지만 다른 피어 먼저 변경에 동의해야하기 때문에, 개인 피어는이 시간에 원장 업데이트를 수행 할 수 없습니다 합의 . 따라서 피어는 제안 된 업데이트 (이 피어가 다른 피어의 사전 동의에 따라 적용될 업데이트)를 어플리케이션에 반환합니다 . 첫 번째 단계 인 네 번째 단계에서는 어플리케이션이 제안 된 업데이트와 일치하는 적절한 집합을 피어 네트워크 전체에 보내어 각 원장에 대한 약정을 위한 트랜잭션으로 전달해야합니다. 이것은 Orderer를 사용하는 어플리케이션에 의해 달성됩니다. 트랜잭션을 블록으로 패키지화하고 이를 피어의 전체 네트워크에 배포하며, 각 피어의 원장 사본에 적용되기 전에 이를 확인할 수 있습니다. 이 전체 주문 처리가 완료되는 데 몇 시간이 걸리므로 5 단계 에서처럼 어플리케이션에 비동기 적으로 통지됩니다.

이 항목의 뒷부분에서이 주문 프로세스의 세부적인 특성에 대해 자세히 알아보고이 프로세스에 대한 자세한 내용은 트랜잭션 흐름 항목을 참조하십시오.

피어 및 채널

이 주제는 채널이 아닌 피어에 관한 내용이지만 피어가 서로 상호 작용하는 방식을 이해하고 채널을통해 어플리케이션을 이해하는 데 약간의 시간을 투자 할 가치가 있습니다. 블록 체인 네트워크 내의 구성 요소 집합이 개인적으로 통신하고 상호 작용할 수 있는 메커니즘 입니다.

이러한 구성 요소는 일반적으로 피어 노드, 발주자 노드 및 어플리케이션이며 채널에 가입함으로써 함께 모여 해당 채널에 대한 원장의 동일한 복사본을 공동으로 공유하고 관리하는 데 동의합니다. 개념적으로 채널은 친구 그룹과 유사하다고 생각할 수 있습니다 (채널 회원은 확실히 친구 일 필요는 없습니다!). 한 사람에게는 여러 그룹의 친구가있을 수 있으며, 각 그룹에는 함께하는 활동이 있습니다. 이 그룹들은 완전히 별개의 그룹 일 수도 있고 (취미 친구들의 그룹과 비교하여 일하는 친구 그룹 일 수도 있습니다.), 또는 그들 사이에 크로스 오버가있을 수 있습니다. 그럼에도 불구하고 각 그룹은 일종의 "규칙"을 가진 자체 엔티티입니다.

채널을 사용하면 특정 피어 집합과 어플리케이션 집합이 블록 체인 네트워크 내에서 서로 통신 할 수 있습니다. 이 예시에서, 어플리케이션 A는 채널 C를 사용하여 피어 P1 및 P2와 직접 통신 할 수 있습니다.이 채널을 특정 어플리케이션과 피어 간의 통신 경로로 생각할 수 있습니다. (간략하게하기 위해 해당 다이어그램에는 Orderer가 표시되지 않지만 제대로 작동하는 네트워크에 있어야합니다.)

우리는 피어들이하는 것과 같은 방식으로 채널이 존재하지 않는다는 것을 알았습니다. 채널을 물리적 피어 집단에 의해 형성된 논리적 구조로 생각하는 것이 더 적절합니다. 이 것을 이해하는 것이 중요합니다. 피어는 채널에 대한 액세스 및 관리를 위한 제어 지점을 제공합니다.

피어 및 조직

이제 피어와 원장, 체인 코드 및 채널과의 관계를 이해하면 여러 조직이 모여 블록 체인 네트워크를 구성하는 방법을 알 수 있습니다.

블록 체인 네트워크는 단일 조직 이라기보다는 조직의 집합에 의해 관리됩니다. 피어들은 이러한 종류의 분산 네트워크가 이러한 조직에 의해 소유되고 네트워크에 대한 연결 지점이기 때문에 구축되는 방식의 핵심입니다.

여러 조직이있는 블록 체인 네트워크의 피어. 블록 체인 네트워크는 다른 조직이 소유한 피어들로 구성됩니다. 이 예에서는 네트워크를 형성하기 위해 8 명의 피어에 기여하는 4 개의 조직을 볼 수 있습니다. 채널 C는 네트워크 N-P1, P3, P5, P7 및 P8에서 이러한 피어 중 다섯 개를 연결합니다. 이 조직이 소유 한 다른 피어는이 채널에 가입하지 않았지만 일반적으로 하나 이상의 다른 채널에 가입합니다. 특정 조직에서 개발 한 어플리케이션은 다른 조직의 어플리케이션과 마찬가지로 자신의 조직의 피어와 연결됩니다. 다시 말하지만, 간단하게하기 위해이 다이어그램에는 Orderer 노드가 표시되지 않습니다.

블록 체인 네트워크의 형성 과정을 파악할 수 있어야합니다. 네트워크는 자원을 제공하는 여러 조직에 의해 형성되고 관리됩니다. 피어는이 항목에서 논의하는 리소스이지만 조직에서 제공하는 리소스는 단순한 것 이상입니다. 여기서 일하는 원칙이 있습니다. 네트워크가 말 그대로 조직이 개별 리소스를 집단 네트워크에 기여하지 않으면 존재하지 않습니다. 또한 네트워크는 이러한 공동 작업 조직에서 제공하는 리소스로 확장 및 축소됩니다.

위 의 예 에서 조직이 피어를 제공하지 않은 경우 네트워크 ( N )가 존재하지 않는다는 것을 볼 수 있습니다 (주문 서비스 이외). 중앙 리소스 가 없습니다. 이는 조직이 조직에서 자원을 기여할 때까지 그리고 조직이 자원을 기여할 때까지 네트워크가 의미있는 의미로 존재하지 않는다는 사실을 반영합니다. 또한 네트워크는 개별 조직에 의존하지 않습니다. 어떤 조직이 어떤 조직에 출입 할지라도 조직이 남아있는 한 계속 존재할 것입니다. 이것은 네트워크가 분산화된다는 의미의 중심에 있습니다.

위의 예시와 같이 다른 조직의 어플리케이션 은 동일하거나 다를 수 있습니다. 그 이유는 어플리케이션이 피어의 원장 사본을 어떻게 처리하는지는 전적으로 조직에 달려 있기 때문입니다. 즉, 각각의 피어가 정확히 동일한 원장 데이터를 호스팅하더라도 어플리케이션 논리와 표시 논리가 조직마다 다를 수 있음을 의미합니다.

어플리케이션은 필요한 원장 상호 작용의 특성에 따라 조직의 피어 또는 다른 조직의 피어와 연결됩니다. 원장 - 쿼리 상호 작용의 경우 일반적으로 어플리케이션이 자체 조직의 피어와 연결됩니다. 원장 - 업데이트 상호 작용의 경우 원장 업데이트를 승인하는 데 필요한 모든 조직의 피어에게 어플리케이션을 연결해야하는 이유를 나중에 알 수 있습니다.

피어 및 신원

이제 다른 조직의 피어들이 함께 모여 블록 체인 네트워크를 구성하는 방법을 보았으므로 관리자가 조직에 피어를 할당하는 방법을 이해하는 데 잠시 시간을 할애 할 가치가 있습니다.

피어는 특정 인증 기관의 디지털 인증서를 통해 ID를 할당받습니다. X.509 디지털 인증서가이 가이드의 다른 곳에서 작동하는 방식에 대해 더 많이 읽을 수 있지만 디지털 인증서는 피어에 대한 검증 가능한 많은 정보를 제공하는 ID 카드와 같다고 생각할 수 있습니다. 네트워크의 모든 피어는 소유 조직의 관리자가 디지털 인증서를 할당받습니다 .

피어가 채널에 연결되면 디지털 인증서는 채널 MSP를 통해 소유 조직을 식별합니다. 이 예에서 P1과 P2는 CA1이 발행 한 ID를가집니다. 채널 C는 채널 구성의 정책에서 CA1의 ID가 ORG1.MSP를 사용하여 Org1과 연관되어야한다고 결정합니다. 마찬가지로 P3과 P4는 ORG2.MSP에 의해 Org2의 일부로 식별됩니다.

피어가 채널을 사용하여 블록 체인 네트워크에 연결할 때마다 채널 구성의 정책은 피어의 ID를 사용하여 해당 권한을 결정합니다. 조직에 대한 ID의 매핑은 멤버쉽 서비스 공급자(MSP) - 피어가 특정 조직의 특정 역할에 할당되는 방식을 결정하므로 이에 따라 블록 체인 리소스에 대한 적절한 액세스 권한이 부여됩니다. 또한 피어는 단일 조직에서만 소유 할 수 있으므로 단일 MSP와 연결됩니다. 이 항목의 뒷부분에서 피어 액세스 제어에 대해 자세히 알아보고이 가이드의 MSP 및 액세스 제어 정책에 대한 전체 항목을 제공합니다. 그러나 지금은 MSP가 블록 체인 네트워크에서 개별 신원과 특정 조직의 역할 간 연계를 제공한다고 생각하십시오.

그리고 잠시 빗나가려면 블록 체인 네트워크와 상호 작용하는 모든 것 뿐만 아니라 피어 가 디지털 인증서와 MSP에서 조직 정체성을 획득하십시오 . 블록 체인 네트워크와 상호 작용하려는 경우 피어, 어플리케이션, 최종 사용자, 관리자, Orderer는 ID 및 관련 MSP가 있어야합니다. 신원을 사용하여 블록 체인 네트워크와 상호 작용하는 모든 엔티티 (주체)에게 이름을 제공합니다. 이 가이드의 다른 곳에서 교장 및 조직에 관해 더 많은 것을 배울 수는 있지만, 지금은 피어에 대한 이해를 계속하기에 충분합니다.

마지막으로 피어가 실제로 위치하는 곳은 중요하지 않습니다. 클라우드 또는 조직 중 하나가 소유 한 데이터 센터 나 로컬 시스템에 상주 할 수 있습니다. 특정 조직이 소유하고 있습니다. 위의 예에서 P3은 Org1의 데이터 센터에서 호스팅 될 수 있지만 CA2와 연결된 디지털 인증서가있는 한 Org2가 소유합니다.

피어 및 Orderer

우리는 피어들이 피어 - 연결된 어플리케이션에 의해 질의되고 업데이트 될 수있는 원장과 체인 코드 계약을 호스팅하는 블록 체인 네트워크를 형성하는 것을 보아 왔습니다. 그러나 어플리케이션과 피어가 서로 상호 작용하여 모든 피어의 원장이 일관성을 유지하도록하는 메커니즘은 주문 자라고불리는 특수 노드에 의해 조정되며 , 이제 우리가주의를 돌리는 노드입니다.

하나의 피어가 자체적으로 원장을 업데이트 할 수 없으므로 업데이트 트랜잭션은 쿼리 트랜잭션과 상당히 다릅니다. 이는 네트워크의 다른 피어의 동의가 필요하기 때문입니다. 피어는 네트워크의 다른 피어가 피어의 로컬 원장에 적용되기 전에 원장 업데이트를 승인해야합니다. 이 프로세스를 합의 라고 하며 쿼리보다 완료하는 데 훨씬 오래 걸립니다. 그러나 트랜잭션을 승인해야하는 모든 피어가 그렇게하고 트랜잭션이 원장에게 맡겨지면 피어는 연결된 어플리케이션에 원장이 업데이트되었음을 ​​알립니다. 이 섹션에서 피어 및 Orderer가 합의 프로세스를 관리하는 방법에 대해 자세히 자세히 설명하려고합니다.

특히 원장을 업데이트하려는 어플리케이션은 3 단계 프로세스와 관련되어 있으므로 블록 체인 네트워크의 모든 피어가 원장을 서로 일관되게 유지할 수 있습니다. 첫 번째 단계에서 어플리케이션은 승인 된 보조 프로그램의 하위 집합과 함께 작동합니다 . 각 하위 프로그램 은 제안 된 원장 업데이트를 어플리케이션에 대한 보증으로 제공하지만 원장 사본에 제안 된 업데이트를 적용하지 않습니다. 두 번째 단계에서는 이러한 별도의 보증을 트랜잭션으로 수집하여 블록으로 패키지화합니다. 마지막 단계에서 이러한 블록은 각 트랜잭션이 확인 된 모든 피어로 다시 분산되어 해당 피어의 원장 사본에 적용됩니다.

알 수 있듯이 Orderer 노드는이 프로세스의 핵심입니다. 따라서 어플리케이션 및 피어가 Orderer를 사용하여 분산 된 복제 원장에 일관되게 적용 할 수있는 원장 업데이트를 생성하는 방법에 대해 좀 더 자세히 살펴 보겠습니다.

1 단계 : 제안

트랜잭션 워크 플로우의 1 단계에는 애플리케이션과 피어 집합 간의 상호 작용이 포함됩니다. 이는 Orderer를 포함하지 않습니다. 1 단계는 제안 된 체인 코드 호출의 결과에 동의하도록 다른 조직의 승인하는 피어에게 요청하는 어플리케이션에만 관련됩니다.

1 단계를 시작하기 위해 어플리케이션은 트랜잭션 제안서를 생성하여 필요한 피어 집합을 보냅니다. 그런 다음 각 피어는 트랜잭션 제안서 응답을 생성하기 위해 트랜잭션 제안서를 사용하여 독립적으로 체인 코드를 실행합니다. 이 업데이트는 원장에 적용되지 않지만 피어가 서명하고 어플리케이션에 반환합니다. 신청서가 충분한 수의 서명 된 제안서 응답을 받으면 거래 흐름의 첫 번째 단계가 완료됩니다. 이 단계를 조금 더 자세히 살펴 보겠습니다.

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

처음에는 일련의 제안 된 원장 업데이트를 생성하기 위해 어플리케이션이 피어 집합을 선택합니다. 어떤 피어가 어플리케이션에서 선택합니까? 네트워크에 의해 승인되기 전에 제안 된 장부 변경을 승인해야하는 조직 집합을 정의 하는 보증 정책 (chaincode에 대해 정의 됨) 에 따라 달라집니다 . 이것은 사실상 합의를 달성한다는 것을 의미합니다. 문제가되는 모든 조직은 모든 ​​원장의 장부에 승인 되기 전에 제안 된 원장 변경을 승인해야합니다 .

피어는 디지털 서명을 추가하고 개인 키를 사용하여 전체 페이로드에 서명함으로써 제안 응답을 보증합니다. 이 보증은 이후에이 조직의 피어가 특정 응답을 생성했음을 입증하는 데 사용될 수 있습니다. 이 예에서 피어 P1이 조직 Org1 소유이면 보증 E1은 "원장 L1의 트랜잭션 T1 응답 R1이 Org1 피어 P1에 의해 제공되었습니다!"라는 디지털 증거에 해당합니다.

1 단계는 신청서가 충분한 피어로부터 서명 된 제안서 응답을 받으면 끝납니다. 서로 다른 피어가 동일한 거래 제안서에 대해 어플리케이션에 대해 서로 다르기 때문에 일치하지 않는 거래 응답을 반환 할 수 있습니다 . 다른 국가의 원장이있는 다른 피어에게 결과가 서로 다른 시간으로 생성되었을 수도 있습니다.이 경우 어플리케이션은 단순히 최신 제안 응답을 요청할 수 있습니다. 체인 코드가 비 결정적이기 때문에 결과는 다를 수 있습니다.. 비 결정 성은 체인 코드 및 원장의 적이며, 발생하는 경우 일관성없는 결과가 원장에게 적용될 수 없기 때문에 제안 된 거래에 심각한 문제가 있음을 나타냅니다. 개별 피어는 트랜잭션 결과가 비 결정적이라는 것을 알 수 없습니다. 비 결정 성을 감지하기 전에 트랜잭션 응답을 함께 수집하여 비교해야합니다. 엄밀히 말하면, 이것으로도 충분하지는 않지만, 비 결정성에 대해 자세히 논의하는 트랜잭션 주제에 대해서는이 논의를 연기합니다.

1 단계가 끝나면 어플리케이션은 일관성없는 트랜잭션 응답을 자유롭게 버리고이를 원할 경우 트랜잭션 워크 플로를 효과적으로 종료합니다. 나중에 애플리케이션이 일관성없는 트랜잭션 응답을 사용하여 원장을 업데이트하려고하면 거부 될 것입니다.

2 단계 : 포장

트랜잭션 워크 플로의 두 번째 단계는 패키징 단계입니다. Orderer는 이 프로세스의 중추적 인 역할을합니다. 많은 애플리케이션에서 승인된 거래 제안 응답을 포함하는 거래를받습니다. 그것은 각 거래를 다른 거래와 비교하여 주문하고, 트랜잭션의 일괄 처리를 원래의 승인하는 피어를 포함하여 Orderer에게 연결된 모든 피어에게 배포 할 준비가 된 블록으로 패키지화합니다.

Orderer 노드의 첫 번째 역할은 제안 된 원장 갱신을 패키지하는 것입니다. 이 예에서 어플리케이션 A1은 E1 및 E2가 승인 한 트랜잭션 T1을 순서자 O1에 전송합니다. 병행하여, 어플리케이션 A2는 E1이 승인 한 트랜잭션 T2를 발주자 O1에게 전송합니다. O1은 어플리케이션 A1의 트랜잭션 T1과 어플리케이션 A2의 트랜잭션 T2를 네트워크의 다른 어플리케이션에서 다른 트랜잭션과 함께 B2 블록으로 패키지화합니다. B2에서 트랜잭션 순서는 T1, T2, T3, T4, T6, T5입니다. 이러한 트랜잭션이 Orderer 노드에 도착한 순서가 아닐 수 있습니다! (이 예제는 매우 단순화 된 Orderer 구성을 보여줍니다.)

발주자는 특정 채널의 네트워크에있는 여러 어플리케이션에서 제안 된 원장 갱신을 동시에받습니다. 이 작업은 제안 된 업데이트를 잘 정의 된 순서로 정렬 하고 이후 배포를 위해 블록으로 패키지화하는 것 입니다. 이 블록은 될 것이다 블록 blockchain의! 일단 Orderer가 원하는 크기의 블록을 생성하거나 최대 경과 시간 후에 블록은 특정 채널에서 연결된 모든 피어로 전송됩니다. 이 블록이 3 단계에서 어떻게 처리되는지 살펴 보겠습니다.

한 블록 내의 거래 순서가 Orderer에게 거래가 도착한 순서와 반드시 같지는 않다는 점은 주목할 가치가 있습니다! 트랜잭션은 블록에 임의의 순서로 패키징 할 수 있으며 실행 순서가되는 순서입니다. 중요한 것은이 때문이다 인 것이 아니라, 엄격한 위해 어떤 순서입니다.

블록 내에서의 트랜잭션의 엄격한 주문은 Hyperledger Fabric을 동일한 트랜잭션을 여러 블록으로 패키징 할 수있는 다른 블록 체인과 조금 다릅니다. Hyperledger Fabric에서는 이러한 일이 발생할 수 없습니다 . 거래가 블록에 쓰여지면 장부의 위치가 확실하게 보장되기 때문에 Orderer 컬렉션에 의해 생성 된 블록이 최종 이라고합니다. Hyperledger Fabric의 최종성은 원장 포크 로 알려진 비참한 사건이 발생할 수 없다는 것을 의미 합니다. 블록에서 트랜잭션을 캡처하면 추후 시점에서 해당 트랜잭션에 대한 내역을 다시 쓸 수 없습니다.

우리는 또한 피어가 원장과 체인 코드를 호스팅하는 반면에 Orderer는 그렇지 않음을 알 수 있습니다. Orderer에게 도착한 모든 거래는 기계적으로 하나의 블록에 포장되어 있습니다. Orderer는 거래의 가치에 대해 아무런 판단도하지 않습니다. 이것은 Hyperledger Fabric의 중요한 동작입니다. 모든 트랜잭션은 엄격한 순서로 정렬되며, 트랜잭션은 삭제되거나 우선 순위가 결정됩니다.

2 단계가 끝나면 Orderer는 제안 된 거래 업데이트를 수집하고 주문하고,이를 블록으로 포장하여 배포 할 수있는 간단하지만 중요한 프로세스에 책임이 있음을 확인합니다.

3 단계 : 유효성 검사

거래 워크 플로의 최종 단계에는 Orderer로부터 피어에게 블록을 배포하고 이후 유효성 검사를 수행하여 장부에 적용 할 수 있습니다. 특히, 각 피어에서 블록 내의 모든 트랜잭션은 장부에 적용되기 전에 모든 관련 조직에서 일관되게 보증되도록 유효성이 검사됩니다. 실패한 트랜잭션은 감사를 위해 보관되지만 장부에 적용되지 않습니다.

Orderer 노드의 두 번째 역할은 피어에 블록을 배포하는 것입니다. 이 예에서, 순서 Y O1은 블록 B2를 피어 P1과 피어 P2로 분 h합니다. 피어 P1은 블록 B2를 처리하여 새로운 블록이 P1의 원장 L1에 추가됩니다. 병렬 적으로 피어 P2는 블록 B2를 처리하여 새로운 블록이 P2의 원장 L1에 추가됩니다. 이 프로세스가 완료되면 원장 L1이 피어 P1 및 P2에서 일관되게 업데이트되고 각각 연결된 어플리케이션에 트랜잭션이 처리되었음을 알릴 수 있습니다.

3 단계는 Orderer가 블록을 연결된 모든 피어에게 배포하는 것으로 시작됩니다. 피어는 새로운 블록이 생성되면 Orderer에게 연결된 모든 피어가 새 블록의 사본을 전송하도록 채널의 Orderer에게 연결됩니다. 각 피어는이 블록을 독립적으로 처리하지만 채널의 다른 모든 피어와 정확히 같은 방식으로 처리합니다. 이렇게하면 원장이 일관되게 유지 될 수 있습니다. 모든 피어가 발주자와 연결될 필요는 없다는 점도 주목할 가치가 있습니다. 피어는 험담 프로토콜을 사용하여 블록을 다른 피어에게 캐스케이드 할 수 있으며 , 이들은 또한 독자적으로 처리 할 수 ​​있습니다. 그러나 그 토론을 다른 시간에 남겨 둡시다!

블록을 수신하면 피어는 각 트랜잭션을 블록에 나타나는 순서대로 처리합니다. 모든 거래에 대해 각 피어는 트랜잭션 을 생성 한 체인 코드 의 보증 정책 에 따라 필요한 조직이 해당 트랜잭션을 보증했는지 확인 합니다. 예를 들어, 일부 거래는 단일 조직이 보증해야하는 반면, 다른 거래는 유효한 것으로 간주되기 전에 여러 보증을 요구할 수 있습니다. 이 유효성 확인 프로세스는 모든 관련 조직이 동일한 결과 또는 결과를 생성했음을 검증합니다.

트랜잭션이 올바르게 승인되면 피어는이를 원장에게 적용하려고 시도합니다. 이렇게하려면 피어가 원장 일관성 검사를 수행하여 제안 된 업데이트가 생성되었을 때 원장의 현재 상태가 원장의 상태와 호환되는지 확인해야합니다. 트랜잭션이 완전히 승인 된 경우에도 항상 가능하지는 않습니다. 예를 들어 다른 트랜잭션이 원장의 동일한 자산을 업데이트하여 트랜잭션 업데이트가 더 이상 유효하지 않아 더 이상 적용 할 수 없게 될 수 있습니다. 이러한 방식으로 각 피어의 원장 사본은 각각 동일한 유효성 검사 규칙을 따르므로 네트워크를 통해 일관되게 유지됩니다.

피어가 각 개별 트랜잭션의 유효성을 성공적으로 검사 한 후 원장을 업데이트합니다. 실패한 트랜잭션은 원장에 적용되지 않지만 성공적인 거래와 같이 감사 목적으로 유지됩니다. 이는 피어 블록이 블록의 각 트랜잭션에서 유효하거나 유효하지 않은 표시기를 제외하고 Orderer로부터 수신 된 블록과 거의 동일 함을 의미합니다.

3 단계에서는 체인 코드 실행이 필요하지 않습니다. 이는 1 단계에서만 수행되며 중요합니다. 즉, 체인 코드는 블록 체인 네트워크 전체가 아닌 승인 노드에서만 사용할 수 있어야합니다. 이는 체인 코드의 논리를 기밀로 유지하여 조직을지지하는 데 도움이되는 경우가 많습니다. 이는 거래를 승인했는지 여부에 상관없이 채널의 모든 피어에게 공유되는 체인 코드 (거래 제안서 응답)의 출력과 대조됩니다. 이 인증 피어링 전문가는 확장 성을 높이기 위해 설계되었습니다.

마지막으로, 블록이 피어의 원장에게 맡길 때마다 해당 피어는 적절한 이벤트를 생성합니다 . 블록 이벤트 는 전체 블록 컨텐츠를 포함하는 반면, 블록 트랜잭션 이벤트 는 블록의 각 트랜잭션의 유효성 검증 또는 무효화 여부와 같은 요약 정보만을 포함합니다. 체인 코드 실행이 생성 한 체인 코드 이벤트도이 시점에 게시 할 수 있습니다. 어플리케이션은 이러한 이벤트 유형에 대해 등록 할 수 있으므로 이벤트 유형을 통지 할 수 있습니다. 이러한 통지는 트랜잭션 워크 플로의 세 번째이자 마지막 단계입니다.

요약하면 3 단계는 주문 원이 원장에 일관되게 적용하여 생성 한 블록을 확인합니다. 트랜잭션을 블록으로 엄격하게 정렬하면 각 피어는 트랜잭션 업데이트가 블록 체인 네트워크 전체에 일관되게 적용되는지 확인할 수 있습니다.

Orderer 및 합의

이 전체 트랜잭션 워크 플로우 프로세스는 모든 피어가 Orderer가 중재하는 프로세스에서 트랜잭션의 순서 및 내용에 대한 합의에 도달했기 때문에 합의 라고 합니다. 합의는 여러 단계의 프로세스이며, 프로세스가 완료되면 어플리케이션은 원장 업데이트 만 통보됩니다. 이는 다른 피어에서 약간 다른 시간에 발생할 수 있습니다.

우리는 향후 발주자 주제에 대해 더 자세하게 발주자에 대해 논의 할 예정이지만, 당분간은 발주자를 피어 신청서의 장부 업데이트를 수집하여 배포하여 장부에 검증하고 포함시키는 노드로 생각하십시오.

그게 다야! 이제 Hyperledger Fabric과 관련된 피어 및 다른 구성 요소에 대한 둘러보기를 마쳤습니다. 우리는 피어들이 네트워크를 구성하고 체인 코드와 장부를 구성하고 트랜잭션 제안 및 응답을 처리하며 일관되게 트랜잭션 업데이트를 적용하여 장부를 최신 상태로 유지하는 것을 여러 측면에서 가장 근본적인 요소로 인식했습니다.