7. Peers(1)

7. Peers

블록 체인 네트워크는 주로 피어 노드 집합으로 구성된다. 피어는 원장 및 스마트 컨트랙트를 호스트하기 때문에 네트워크의 기본 요소입니다. 원장은 스마트 컨트랙트 (또는 체인 코드)에 의해 생성된 모든 거래를 기록하며, 변경할 수 없다. 스마트 컨트랙트와 원장은 각각 공유 프로세스와 공유 정보를 네트워크에 캡슐화 하는데 사용된다.

블록 체인 네트워크의 다른 요소들도 역시 중요하다. 원장 및 스마트 컨트랙트, orderer, 정책, 채널, 어플리케이션, 조직, ID 및 멤버십 등의 요소들이 있다. 이 섹션에서는 피어 및 Hyperledger 패브릭 네트워크의 다른 요소와의 관계에 중점을 둔다.

 

블록 체인 네트워크는 피어 노드로 구성되며 각 노드는 원장 사본 및 스마트 컨트랙트 사본을 보유할 수 있다. 그림에서 네트워크 N은 피어 P1, P2 및 P3으로 구성되며 각 피어는 분산 원장 L1의 자체 인스턴스를 유지 관리합니다. P1, P2 및 P3은 동일한 체인 코드 S1을 사용하여 해당 분산 원장의 사본에 액세스한다.

피어는 생성, 시작, 중지, 재구성 및 삭제할 수 있다. 피어는 관리자 및 어플리케이션이 제공하는서비스와 서로 상호 작용할 수 있는 일련의 API를 제공한다. 이 섹션에서는 이러한 서비스에 대해 자세히 설명한다.

전문 용어

 

Hyperledger Fabric은 체인 코드 (chaincode)라고하는 기술 개념을 사용하여 스마트 컨트랙트를 구현한다. 지원되는 프로그래밍 언어 중 하나로 작성된 원장에 액세스하는 간단한 코드이다. 이 주제에서는 일반적으로 chaincode라는 용어를 사용하지만, smart contract라는 용어가 더 익숙하다면 smart contract로 읽어도 상관없다. 두 개의 용어는 같은 것이다.

원장 및 체인 코드

 

그림에서 피어를 좀 더 자세히 살펴보면 원장과 체인 코드를 모두 호스트하는 피어임을 알 수 있다. 보다 정확하게, 피어는 실제로 원장의 인스턴스와 chaincode 인스턴스를 호스팅한다. 이는 Fabric 네트워크에서 복사본을 갖게 하므로 단일 실패 지점을 피할 수 있다.

피어가 원장 및 체인 코드의 호스트이기 때문에 애플리케이션 및 관리자는 이러한 리소스에 액세스하려는 경우 피어와 통신해야 한다. 이것이 피어가 Hyperledger 패브릭 네트워크의 가장 기본적인 빌딩 블록으로 간주되는 이유이다. 피어가 처음 생성되면 원장이나 체인 코드가 없다. 이후에 어떻게 원장이 생성되는지, 그리고 어떻게 체인코드가 설치되는지 알아볼 것이다.

다중 원장

 

피어는 둘 이상의 원장을 호스팅 할 수 있으므로 유연한 시스템 설계가 가능하다. 가장 단순한 구성은 피어가 한 개의 원장을 관리하는 것이지만 필요하다면 한 개의 피어가 두 개 이상의 원장을 호스팅해도 전혀 문제가 없다.

그림은 여러 원장을 호스팅하는 피어이다. 피어는 하나 이상의 원장을 호스팅하고 각 원장에는 0 개 이상의 체인 코드가 적용된다. 이 예에서 피어 P1는 원장 L1 및 L2를 호스팅한다. 원장 L1은 체인 코드 S1을 사용하여 액세스할 수 있고, 원장 L2는 체인 코드 S1 및 S2를 사용하여 액세스 할 수 있다.

피어가 해당 원장에 액세스하는 체인 코드를 호스팅하지 않고 원장 인스턴스를 호스팅 할 수도 있지만 이와 같이 구성되는 경우는 거의 없다. 대다수의 피어는 피어의 원장 인스턴스를 쿼리하거나 업데이트 할 수 있는 체인 코드가 하나 이상 설치된다. 외부 어플리케이션에서 사용하기 위해 사용자가 체인코드를 설치하지 않았어도 피어에는 항상 존재하는 특수 시스템 체인 코드가 존재한다.

다중 체인 코드

 

피어가 가지고 있는 원장의 수와 해당 원장에 액세스 할 수 있는 체인 코드의 수는 정해진 원칙이 없다. 피어는 많은 체인 코드와 많은 원장을 소유할 수 있다.

위 그림은 여러 체인 코드를 호스팅하는 피어이다. 각 원장에는 다수의 체인 코드가 있어 액세스 할 수 있다. 피어 P1은 원장 L1 및 L2를 호스팅하며 여기서 L1은 체인 코드 S1 및 S2에 의해 액세스되고 L2는 S1 및 S3에 의해 액세스된다. S1은 L1과 L2 모두에 액세스 할 수 있다.

어플리케이션 및 피어

 

이제 어플리케이션이 피어와 상호 작용하여 원장에 액세스할 수 있다. 원장과 쿼리의 상호 작용에는 어플리케이션과 피어간에 간단한 3단계 과정이 있다. 원장과 업데이트의 상호 작용은 좀 더 복잡하고, 두 가지 단계가 더 필요하다. 가장 중요한 것은 어플리케이션과 피어의 상호 작용에서 원장-쿼리와 원장-업데이트의 차이점을 이해하는 것이다.

원장 및 체인 코드에 액세스 해야하는 경우 항상 피어에 연결된다. Hyperledger 패브릭 소프트웨어 개발 키트 (SDK)를 사용하면 프로그래머가 쉽게 API를 사용할 수 있다. API를 사용하면 어플리케이션에서 피어에 연결하고, 체인 코드를 호출하여 트랜잭션을 생성하며, 네트워크에 트랜잭션을 배포하여 정렬한 후 분산 원장에 기록된다. 이 과정이 완료되면 이벤트를 수신한다.

피어 연결을 통해 어플리케이션은 체인 코드를 실행하여 원장를 쿼리하거나 업데이트 할 수 있다. 원장의 쿼리 트랜잭션의 결과는 즉시 반환되는 반면에 원장의 업데이트는 어플리케이션, 피어, orderer 사이의 보다 복잡한 상호 작용을 수반한다.

피어는 orderer와 함께 모든 원장이 최신 상태로 유지되도록 한다. 그림에서 어플리케이션 A는 P1에 연결하고 체인 코드 S1을 호출하여 원장 L1을 쿼리하거나 업데이트한다. P1은 S1을 호출하여 쿼리 결과 또는 요청된 원장의 업데이트를 포함하는 응답을 생성한다. A가 쿼리에 대한 응답을 수신하면 프로세스가 완료된다. 업데이트의 경우 A는 모든 응답 받은 모든 트랜잭션을 정렬하기 위해 O1에 보낸다. O1은 네트워크에서 블록으로 트랜잭션을 수집하여 이를 P1을 포함한 모든 피어에 배포한다. P1은 그 결과를 L1에 적용하기 전에 트랜잭션의 유효성을 검사한다. L1이 업데이트되면, P1은 A에 의해 수신된 이벤트를 생성하여 완료를 나타낸다.

피어는 쿼리를 수행하기 위해 필요한 모든 정보가 피어의 원장 사본에 있으므로 쿼리 결과를 즉시 어플리케이션에 반환할 수 있다. 피어는 애플리케이션의 쿼리에 응답하기 위해 다른 피어와 통신하지 않는다. 그러나 어플리케이션은 하나 이상의 피어에 연결하여 쿼리를 생성할 수 있다. 예를 들어 여러 피어간에 결과를 공유하거나 데이터가 너무 오래되어 다른 피어로부터 최신의 데이터를 받고 싶을 때 어플리케이션은 여러 피어에 연결하여 쿼리를 생성한다. 그림에서 원장의 쿼리는 간단한 3단계 프로세스임을 알 수 있다.

업데이트 트랜잭션은 쿼리 트랜잭션과 동일한 방식으로 시작되지만 두 가지 추가 단계가 있다. 원장 업데이트 어플리케이션은 체인 코드를 호출하기 위해 피어와 연결되는 것은 같지만 원장 쿼리 어플리케이션과 달리 우선 다른 피어들이 승인해야 하므로(합의라고 함) 연결된 피어는 현재로선 원장 업데이트를 수행할 수 없다. 따라서 피어는 제안된 업데이트 (이 피어가 다른 피어의 승인에 따라 적용될 업데이트)를 어플리케이션에 반환한다. 첫 번째 추가 단계인 네 번째 단계에서는 어플리케이션이 제안된 업데이트를 orderer에게 보내면, Orderer는 트랜잭션을 블록으로 패키지화 하고 이를 피어의 전체 네트워크에 분배하여 각 피어의 원장 사본에 적용되기 전에 확인할 수 있다. 이 전체 ordering 처리가 완료되는 데 시간이 걸리므로(몇 초) 어플리케이션은 처리가 완료된 후 통보받는다.