HyperLedger Fabric Peers(node) 개념

요약

피어는 HyperLedger Fabric의 가장 기본적인 구성요소로, 네트워크를 형성하고, 체인코드와 원장을 호스트하고, 트랜잭션 제안 및 응답을 처리하고, 승인된 트랜잭션을 검증하여 원장을 업데이트하고 일관성을 유지하는 역할을 한다. 

# Peers

 

블록체인 네트워크는 피어 노드(간단히 피어)들의 집합으로 구성되어 있다. 피어들은 네트워크의 기본적인 구성요소이다. 왜냐하면 원장과 스마트계약을 호스팅하기 때문이다. 스마트 계약에 의해 생성된 모든 트랜잭션을 원장이 기록한다는 점을 기억하자. 

스마트 계약과 원장은 각각 공유프로세스와 공유정보를 네트워크에서 캡슐화하는데 사용된다.

피어의 이러한 측면 Fabric 네트워크를 이해하는데 좋은 출발점이 된다. 

블록체인 네트워크는 피어 노드로 구성되며, 각 노드는 장부 사본과 스마트 계약 사본을 보유할 수 있다. 

이 예에서, 네트워크 N은 피어 P1, P2, P3으로 구성되며, 각각은 분산 원장의 인스턴스를 유지한다.

 

피어는 생성, 시작, 중지, 재구성, 심지어 삭제될 수 있다. 

피어는 관리자 및 응용 프로그램이 제공하는 서비스와 상호 작용할 수 있는 API 집합을 제공한다. 

체인코드≒스마트 컨트랙트

 

피어는 원장의 인스턴스와 체인코드의 인스턴스를 호스팅한다. 이렇게 하면 의도적인 이중화를 제공하여

single point of failure 를 방지할 수 있다. 

 

single point of failure

기능이 제대로 작동하지 않을 경우 전체 시스템에 장애를 발생하는 시스템의 비중복적인 부분. 

피어가 원장과 체인코드의 master이기 때문에, 

아플리케이션과 관리자들은 이런 자원들에 접근하기 위해서는 반드시 피어와의 상호작용이 필요하다. 

이게 피어가 패브릭 네트워크의 가장 중요한 기초로 간주되는 이유이다. 

피어가 처음 생성되면, 원장도. 체인코드도 갖고 있지 않다. 

 

피어는 하나 이상의 원장을 호스팅할 수 있다. 

이건 유연한 시스템 디자인을 가능하게 하기 때문에 유용하다. 

가장 간단한 구성은 피어가 하나의 원장을 관리하는 것이지만.  

요구된다면 피어는 두개이상의 원장을 호스팅하는 것이 적합하다. 

 

# Multiple Chaincodes

피어는 하나 이상의 원장을 호스팅하며 

각 원장은 0개 이상의 체인 코드를 적용한다. 

이 예에서는 P1 이 L1 및 L2를 호스트하고, L1은 체인코드 S1을 사용하여 접근한다. 

반면, 레더 L2는 체인 코드 S1과 S2를 사용하여 접근한다.

체인 코드는 단일 채널에서 인스턴스화된다.

각 채널(및 원장)은 채널과 상호 작용하는 여러 체인 코드를 가질 수 있다. 

 

# Applications and Peers

원장-쿼리는 애플리케이션과 피어 사이의 간단한 대화를 수반하며. (read)

반면 원장-업데이트(쓰기)는 추가 단계를 포함 (write)

 

클라이언트 아플리케이션은 원장과 체인코드에 접근하기 위해 피어의 패브릭 게이트웨이 서비스와 연결된다. 

Fabric v2.4부터 Gateway SDK를 사용하면 프로그래머들이 쉽게 사용할 수 있다. API를 사용하면 애플리케이션이 

게이트웨이를 통해 트랜잭션 제안서를 제출하고, 승인을 요청하고. 이벤트를 수신하고, 승인된 트랜잭션을 주문 서비스에 전할 수 있다. 

게이트웨이의 피어 연결을 통해서 아플리케이션은 체인 코드를 실행하여 원장을 읽거나 갱신할 수 있다. 

원장-쿼리 트랜잭션의 결과는 단순한 처리로 반환되는 반면에 

원장-업데이트(쓰기)는 애플리케이션, 피어, 주문자 간의 좀 더 복잡한 작업흐름을 포함한다. 

 

피어는 orderers와 함께 원장이 채널의 모든 피어에서 일관되고 최신상태로 유지되는 것을 보장한다. 

 

1.  Transaction Proposal and Endorsement

 

원장 업데이트(쓰기)의 첫번째 단계는 트랜잭션 제안서 제출과 실행, 그리고 승인으로 구성되어 있다. 

 

a) Transaction proposal 

클라이언트 애플리케이션이 서명된 트랜잭션 제안서를 P1의 게이트웨이 서비스를 통해 제출한다.

클라이언트 아플리케이션은 게이트웨이 서비스에게 승인 조직의 선택을 위임하거나 보증에 필요한 조직을 명시적으로 식별해야 한다. 

 

b) Transaction execution

게이트웨이 서비스는 P1이나 같은 조직의 다른 피어를 선택하고, 트랜잭션을 실행한다. 

선택된 피어는 제안에 의해 지정된 체인코드를 실행한다. 읽기-쓰기등을 포함하는 제안 응답을 생성한다. 

선택된 피어는 제안 응답에 서명하고 게이트웨이로 반환한다.  

 

c) Transaction endorsement

게이트웨이는 체인코드 보증정책에서 요구하는 각 조직에 대해 트랜잭션 실행(b)을 반복한다. 

게이트웨이 서비스는 서명된 제안 응답을 수집한다. 그리고 트랜잭션 봉투를 만들고 서명을 위해 클라이언트에게 반환한다. 

 

2. Transaction Submission and Ordering

 

a) Transaction submission 

클라이언트는 서명된 트랜잭션 봉투를 게이트웨이 서비스에 보낸다. 

게이트웨이는 그 봉투를 ordering node에게 전달하고, 성공 메시지를 클라이언트에게 반환한다. 

 

b) Transaction ordering 

ordering 노드는 서명을 검증한다. 그리고 ordering service가 트랜잭션을 주문하고, 다른 주문 트랜잭션과 함께 블록으로 패키징한다. 그리고 나서 주문 서비스는 원장에 대한 유효성 검사와 commitment를 위해 채널의 모든 피어에 블록을 배포한다. 

3.  Transaction Validation and Commitment

 

a) Transaction validation 

각각의 피어는 트랜잭션에 동봉된 클라이언트의 서명이 원래 트랜잭션 제안서에 있는 서명이랑 일치하는지 확인한다.

또한 각 피어는 모든 읽기-쓰기 집합과 상태 응답이 동일한지(모든 피어의 보증이 일치하는지) 확인하고.각 보증이 보증정책을 만족하는지 확인한다. 각 피어는 원장의 commitment 를 위해 원장에 각 트랜잭션을 유효 or 무효로 표시한다.  

 

b) Transaction commitment

각 피어는 정렬된 트랜잭션 블록을 채널 원장에 커밋한다. 

커밋은 채널 원장에 대한 불변의 ledger update다. 

채널의 world state(모든 유효한 트랜잭션의 합)는 오직 유효한 트랜잭션 결과만으로 갱신된다. 

 

c) Commit event 

원장에 커밋된 각 피어는 클라이언트에게 원장 업데이트 증명과 함께 커밋 상태 이벤트를 보낸다. 

 

# Peers and Channels

채널 컴포넌트는 피어 노드들과, orderer 노드와 아플리케이션을 포함한다. 

채널에 가입함으로써, 그들은 일괄적으로 관리하고 공유하기 위해 협력하기로 동의한다.

 

채널을 친구그룹과 비교할 수 있다. 한 사람의 여러 그룹의 친구를 가질 수 있고, 각 그룹은

서로 다른 활동에 참여할 수 있다. 그룹은 완전히 분리되어 있거나, 그들 사이에 크로스오버 멤버십이 있을 수 있다. 각 친구그룹은 회원 자격을 확립하고 유지하는 특정 규칙을 가진 entity다. 

 

채널 멤버십은 다른 그룹에서와 같은 방식으로 작동한다. 

어떤 피어는 여러 채널에 속할 수 있고, 각 채널에 특정한 원장과 체인코드를 유지할 수 있다.

또는 피어는 오직 하나의 채널에만 속하고 따라야 하는 하나의 규칙의 집합만 가지고 있다. 

 

채널은 특정 아플리케이션 집합과 피어가 서로 Fabric 블록체인 네트워크에서 의사소통하는 것을 허용한다.  예를 들어 A라는 아플리케이션은 채널 C에 있는 게이트웨이 서비스를 통해서 Peer1 과 Peer2와 소통한다. 채널은 특정 아플리케이션과 피어들의 커뮤니케이션을 위한 통로다. 

 

채널은 피어와 같은 방식으로 존재하지 않는다. 채널을 물리적 피어의 컬렉션에 의해 형성된 논리적 구조라 생각하는 것이 더 정확하다. 

피어는 채널에 대한 액세스 및 관리를 위한 컨트롤 포인트를 제공한다. 

 

# Peers and Organizations

Fabric 블록체인 네트워크는 하나의 조직보다 조직들의 컬렉션에 의해서 관리된다. 

피어는 조직이 소유하고 있는 네트워크 연결지점이기 때문에 분산 네트워크 구축 방법의 중심이라고 할 수 있다. 

채널 C 는 네트워크 N 에서 다섯개의 피어와 연결되어 있다.

 

위 조직이 소유하고 있는 다른 피어들은 채널에 가입되어 있지 않다. 하지만 하나 이상의 다른 채널에 가입한다. 

// A1 조직의 P1은 채널 C에 join 한 상태, P2는 다른 채널에 가입되어 있다..

 

조직에서 개발한 아플리케이션은 Fabric 게이트웨이 서비스를 통해 피어와 연결하고, 채널의 다른 조직의 피어에도 연결된다. 

 

네트워크는 리소스를 제공하는 여러 조직에 의해 형성되고 관리된다. 이 항목에서 설명하는 리소스는 피어지만, 조직들은 체인코드나 ordering service node 같은 다른 리소스도 제공한다. 

 

조직이 네트워크에 개별 자원을 기여하지 않는다면, 네트워크는 존재하지 않는다. 

네트워크는 협력하는 조직이 자원을 제공함에 따라 성장하고, 복원력과 보안이 증가한다.

 

보면 알겠지만 중앙집권화된 리소스는 없다. 만약에 조직들이 그들의 피어와 다른 자원을 제공하지 않으면 네트워크 N은 존재하지 않는다. 

네트워크는 어떤 개별 조직에도 의존하지 않는다. 네트워크 구성원이 네트워크가 자체적으로 정의한 요구사항을 충족하는 한 계속 존재한다. 이게 분산된 네트워크의 heart다. 네트워크 모든 회원의 조직은 동등하게 공유하고 기여한다. 

 

각 조직에서 사용하는 어플리케이션은 같을 수도 있고.. 같지 않을 수도 있다. 

왜냐 각각의 조직 원장에 있는 데이터를 어떻게 사용할지 정할 수 있기 때문이다. 

모든 피어가 동일한 원장 사본을 호스팅하더라도. 앞플리케이션과 표현논리는 조직에 따라 다를 수가 있다. 

 

 # Peers and Identity 

 피어들이 그들의 관리자에 의해 어떻게 조직에 할당되는지...

 

 피어는 특정인증기관의 디지털 인증서를 통해 할당된 identity가 있다. 

 네트워크의 모든 피어에 피어를 소유하고 있는 조직의 관리자가 디지털 인증서를 할당한다.

 

 피어가 채널에 연결되면, 해당 디지털 인증서는 채널 MSP를 통해 소유조직을 식별한다. 

 위 예에서 P1 및 P2는 CA1에서 발급한 ID를 갖는다. 채널 C는 채널 구성의 정책을 통해 CA1의 ID가 ORG1.MSP를 사용하여 ORG1과 연결되도록 한다. 마찬가지로 P3와 P4도 ORG2로 식별된다.

 

 피어가 Fabric 네트워크 채널에 연결할 때마다 채널 구성의 정책은 피어의 ID를 사용하여 피어의 권한을 결정한다. 조직에 대한 ID 매핑은 MSP라는 컴포넌트에 의해 제공된다. 이 컴포넌트는 피어가 특정 조직에서 특정 역할에 할당되어 리소스에 대한 인증된 접근 권한을 얻는 방법을 결정한다. 또한 피어는 단일 조직에서만 소유할 수 있으므로 단일 MSP와 연결된다. MSP는 패브릭 네트워크의 특정 조직 역할과 개별 ID를 연결하는 것으로 생각하면 된다. 

 

 피어 그리고 패브릭네트워크와 상호작용하는 모든 것은 디지털 인증서와 MSP에서 조직 ID를 얻는다.

 피어, 아플리케이션, 최종 사용자, 관리자 및 주문자는 네트워크와 상호작용하려면 각각 ID랑 관련된 MSP를 가지고 있어야 한다. 

 

 아이디를 사용해서 블록체인 네트워크와 상호작용하는 모든 엔티티를 principal이라고 한다. 

 ID는 피어가 물리적으로 위치(클라우드, 조직이 소유한 데이터 센터 또는 로컬 머신)에 따라 구별되며, 피어와 연결된 디지털 인증서는 피어가 특정 조직에서 소유한 것으로 식별된다. 

이전 예제 다이어그램에서 P3는 Org1의 데이터 센터에서 호스팅할 수 있지만 관련된 디지털 인증서가 CA2에 의해 발급되는 한 그것은 Org2에 소유된다. 

 

# Orderers and the Three Phases 

애플리케이션과 피어가 채널 전체에서 원장을 최신 상태로 일관되게 유지하기 위해서 서로 상호작용하는 

메커니즘은 Orderer라고 하는 특수 노드에 의해 조정된다. 

1. Transaction Proposal

트랜잭션 워크플로우의 1단계에는 클라이언트 아플리케이션, 피어, 주문자의 상호작용을 포함한다. 1단계에서 클라이언트 애플리케이션이 트랜잭션 제안 평가를 위해 Fabric 게이트웨이 서비스에 요청을 시작한다.

 

클라이언트 아플리케이션에 의해 선택된 대상(target) 피어는 체인코드를 호출하여 트랜잭션을 실행한다. 

- 이 단계는 트랜잭션을 시뮬레이션하는 것으로 설명할 수 있다. 원장에 영향을 미치지 않고 거래를 실행하기 때문이다. 그러면 피어는 트랜잭션 결과를 클라이언트에게 반환한다. 

 

게이트웨이 서비스는 보증된 피어들(보증정책에 기반한)에게 트랜잭션 제안을 전달한다. 또한 트랜잭션을 실행하고 그 결과를 피어에게 반환한다. 게이트웨이 서비스는 모든 응답을 수집한다. 응답이 공통적으로 지지정책을 만족한다면,  트랜잭션을 ordering 서비스에 전한다.

 

만약에 제안된 트랜잭션이 private 데이터 컬렉션에  write 한다면, 클라이언트 아플리케이션은 보증에 필요한 조직을 명시적으로 지정해야한다. 

 

피어는 디지털 서명을 추가하고,개인 키를 사용하여 전체 페이로드에 서명하여 트랜잭션을 보증한다.

이 보증은 나중에 조직의 피어가 특정 응답을 발생했다는 것을 증명하는데 사용된다. 

 

2. Transaction Ordering 

트랜잭션 워크플로우의 2단계는 ordering과 packaging.

ordering service(orderer 노드에서 작동하는) 게이트웨이를 통해서 서명된 트랜잭션과 승인된 제안 응답을 하나 이상의 아플리케이션에서 받아서 트랜잭션을 블록에 정렬하고 패키징한다. 

순서대로 정렬되어있는 보증되었고 주문된 트랜잭션으로 구성된 블록은 블록체인 원장을 구성한다. 

 

3. Validation and Commitment

 

트랜잭션 워크플로우의 마지막 단계는  orderer에서 peer들로 주문된 트랜잭션을 배포하는 것이다.

각 피어는 각 트랜잭션을 검증하고 각각의 트랜잭션이 모든 요구된 기관으로부터 일관성 있게 승인되었다는 것을 보증한다. 

 

orderer 노드는 검증과 commitment를 위해 ordered blocks를 배포한다. 

 

예를 들어. orderer O1 은 block B2를 peer P1과 P2에게 배포한다. 

P1은 block B2를 P1이 소유하고 있는 원장 L1을 추가하고. 동시에 P2는 block B2를 P2가 소유하고 있는 원장 L1에 새로운 블록으로 추가한다.   완료되면 P1과 P2에서 장부 L1이 일관되게 갱신되고, 게이트웨이 서비스는 그 트랜잭션이 커밋되었다는 것을 연관된 애플리케이션에게 알린다.  

 

3단계는 orderer에게 연결된 모든 피어에게 블록을 배포하는 것으로 시작한다. 새 블록이 생성되면 피어들은 orderer에 연결되고, orderer에게 연결된 모든 피어들은 orderer에게 새로운 블록의 사본을 받는다.

각 피어는 이 블록을 독립적으로 처리하지만 같은 채널 안에 있는 다른 피어들과 같은 방식으로 처리한다. 이런 방식으로 우리는 원장을 일관되게 유지할 수 있다. 모든 피어가 주문자와 연결될 필요가 없다는 것은 주목할 만하다. 피어는 독립적으로 처리하면서도, gossip 프로토콜을 이용해 다른 피어들과 블록을 cascade 할 수 있다. 

 

블록을 수신하면 피어는 블록에 명시되어 있는대로 순서대로 각 트랜잭션을 처리한다.  각각의 트랜잭션에서 피어는 트랜잭션이 트랜잭션을 생성하는 체인코드의 보증정책에 따라 요구되는 기관에 의해 보장되었는지 검증한다. 예를 들어서 어떤 트랜잭션은 오직 하나의 조직에게만 보증을 받으면되는데. 다른 트랜잭션은 다수의 보증을 받아야한다. 이 검증과정은 모든 연관된 조직이 같은 결과를 생성하고 있다는 것을 확인한다.

트랜잭션이 올바르게 승인되면 피어가 트랜잭션을 원장에 적용하려고 시도한다. 

그러기 위해서, 피어는 제안된 업데이트가 발생한 시점에서의 원장과 현재의 원장이 호환가능한지 확인하는 원장 

일관성 체크를 반드시 수행해야한다. 

 

트랙잰션이 완전히 보증된 상황에서도 이게 항상 가능한 것은 아니다.  예를 들어서 다른 트랜잭션이 원장의 동일한 자산을 갱신하여 트랜잭션 업데이트가 더 이상 유효하지 않고, 따라서 적용할 수 없을 수도 있다. 

그래서 원장이 채널의 각 피어에서 일관되게 유지된다. 왜냐면, 검증을 위해 동일한 규칙을 따르기 때문이다. 

 

피어는 각 개별 트랜잭션의 유효성을 검사한 후 업데이트 된다. 실패한 트랜잭션은 원장에 적용되지는 않지만 성공한 트랜잭션과 마찬가지로 감사목적으로 보관된다. 

 

3단계에서는 체인코드를 실행할 필요가 없다. 1단계에서만 수행되며 중요합니다. 즉, 체인코드는 블록체인 네트워크 전체가 아니라 보증된 노드에서만 사용할 수 있어야 한다. 이것은 체인코드의 논리를 보증하는 조직에게만 비밀로 유지된다. 이는 거래 승인 여부에 관계없이 채널의 모든 피어와 공유되는 체인코드의 결과(트랜잭션 제안 응답)과 상반된다. 피어를 보증하는 이 전문화는 확장성과 기밀성을 돕도록 설계되었다. 

 

마지막으로, 블록이 피어의 원장에 커밋될 때마다 해당 피어는 이벤트를 생성한다. 블록 이벤트에는 전체 블록 콘텐츠가 포함되는 반면 블록 트랜잭션 이벤트에는 블록의 각 트랜잭션이 검증 또는 무효화되었는지 여부와 같은 요약 정보만 포함된다. 체인코드 실행이 생성한 체인코드 이벤트도 이때 게시할 수 있다. 애플리케이션은 알림을 위해 이러한 이벤트를 등록할 수 있습니다. 커밋 이벤트 알림은 트랜잭션 워크플로의 3번째이자 마지막 단계다.

 

요약하면 3단계에서 주문자가 생성한 트랜잭션 블록이 확인되고 지속적으로 원장에 적용된다, 트랜잭션을 블록으로 엄격하게 정렬하면 각 피어가 트랜잭션이 전체 채널에 일관되게 업데이트 되었는지 확인할 수 있다. 

# Orderers and Consensus 

 

이 전체 트랜잭션 워크플로우 프로세스를 합의라고 한다. 피어들이 주문자의 중재를 통해 트랜잭션의 순서와 내용에 대해 집합적으로 합의에 이르러야하기 때문이다. 

합의는 다단계 프로세스고, 원장 업데이트는 프로세스가 성공적으로 완료된 경우에만 발생한다. 다른 피어에서 다른 시간에 발생할 수 있다. orderer를 피어가 트랜잭션을 승인하고 블록을 원장에 추가할 수 있도록. 원장 업데이트 순서를 지정하고 배포하는 노드로 생각할 수 있다. 

# Peers Summary 

피어는 하이퍼레저 패브릭의 가장 기본적인 구성요소. 네트워크를 형성하고, 체인코드와 원장을 호스트하고, 트랜잭션 제안 및 응답을 처리하고,승인된 트랜잭션으로 검증하여 원장을 업데이트하고 일관성을 유지한다.