[Hyperledger Fabric v1.0] 5. ARCHITECTURE(아키텍트): Architecture Explained(아키텍트 설명)

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

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release/arch-deep-dive.html

 Architecture Explained(아키텍트 설명)

Hyperledger 패브릭 아키텍처는 다음과 같은 이점을 제공합니다.

• 체인코드 신뢰 유연성(Chaincode trust flexibility). 이 아키텍처는 체인 코드 (블록 체인 어플리케이션)에 대한 신뢰 가정을 주문에 대한 신뢰 가정으로부터 분리합니다. 즉, 주문 서비스는 한 세트의 노드(주문자)에 의해 제공 될 수 있으며 일부는 실패하거나 오작동하는 것을 허용하며, 엔드 코드는 각 체인 코드마다 다를 수 있습니다.
• 확장성(Scalability). 특정 체인 코드를 담당하는 엔도 서 노드는 주문자와 직각을 이루기 때문에 시스템이 동일한 노드에서 이러한 기능을 수행하는 경우보다 확장 성이 좋습니다. 특히, 서로 다른 체인 코드가 분리 된 endorser를 지정하면 endorsors 사이에 chaincode를 분할하고 parallel chaincode를 실행할 수 있습니다 (보증). 게다가, 비용이 많이 드는 체인 코드 실행은 주문 서비스의 중요한 경로에서 제거됩니다.
• 기밀 유지(Confidentiality). 이 아키텍처는 컨텐트 및 해당 트랜잭션의 상태 업데이트와 관련하여 기밀성 요구 사항이있는 체인 코드 배포를 용이하게합니다.
• 컨센서스 모듈성(Consensus modularity). 이 아키텍처는 모듈 식이며 플러그 가능한 컨센서스 (즉, 주문 서비스) 구현을 허용합니다.

Part I: Hyperledger Fabric v1과 관련된 아키텍처 요소

• 시스템 아키텍처
• 거래 보증의 기본 워크 플로
• 추천 정책

Part II:  아키텍처의 v1 이후 요소

• 원장 체크포인트(잘라내기)

System architecture(시스템 아키텍처)

블록 체인은 서로 통신하는 많은 노드로 구성된 분산 시스템입니다. 블록 체인은 chaincode라는 프로그램을 실행하고 상태 및 원장 데이터를 보유하며 트랜잭션을 실행합니다. 체인 코드는 트랜잭션이 체인 코드에서 호출되는 중심 요소입니다. 거래는 "보증"되어야하며 승인 된 거래 만 커밋되어 해당 주에 영향을 미칠 수 있습니다. 관리 기능 및 매개 변수에 대한 하나 이상의 특수 체인 코드 (시스템 체인 코드라고도 함)가있을 수 있습니다.

Transactions(트랜잭션)

거래에는 두 가지 유형이 있습니다.

Deploy transactions : 새로운 체인 코드를 생성하고 프로그램을 매개 변수로 사용합니다. 배포 트랜잭션이 성공적으로 실행되면 체인 코드가 블록 체인의 "위에" 설치됩니다.

Invoke transactions : 이전에 배포된 체인 코드의 컨텍스트에서 작업을 수행합니다. 호출 트랜잭션은 체인 코드와 제공된 기능 중 하나를 참조합니다. 성공하면 chaincode는 지정된 함수를 실행합니다.이 함수는 해당 상태를 수정하고 출력을 반환합니다. 나중에 설명 하듯이 배포 트랜잭션은 invoke 트랜잭션의 특별한 경우이며 새 체인 코드를 만드는 배포 트랜잭션은 시스템 체인 코드의 호출 트랜잭션에 해당합니다.

[참고] 이 문서는 현재 트랜잭션이 새로운 체인 코드를 생성하거나 이미 배치 된 체인 코드에 의해 제공되는 작업을 호출한다고 가정합니다. 이 문서에서는 a) 쿼리 (읽기 전용) 트랜잭션 (v1에 포함) 최적화, b) 교차 체인 트랜잭션 (v1 이후 기능) 지원 *

Blockchain datastructures(블록체인 데이터 구조)

State(상태)

블록 체인의 최신 상태 (또는 단순히 상태)는 키가 이름이고 값이 임의의 얼룩 인 버전 관리 된 키 / 값 저장소 (KVS)로 모델링됩니다. 이 엔트리들은 put과 get  KVS 연산을 통해 블록 체인에서 실행되는 체인 코드 (응용 프로그램)에 의해 조작됩니다. 상태는 지속적으로 저장되고, 상태에 대한 업데이트가 기록됩니다. 버전이 지정된 KVS가 상태 모델로 채택되며 구현시 실제 KVS를 사용할 수 있지만 RDBMS 또는 다른 솔루션을 사용할 수 있습니다.

보다 공식적으로, 상태 s는 K -> (V X N)의 매핑 요소로 모델링된다.

• K 는 키 집합입니다.
• V 는 값들의 집합이다.
• N 은 버전 번호의 무한한 순서 집합입니다. 다음 함수 : N -> N은 N의 원소를 취하여 다음 버전 번호를 반환합니다.

V 와 N은 모두 특수 요소 \bot을 포함하는데,  N은 가장 낮은 요소입니다. 처음에는 모든 키가(\bot,\bot)에 매핑됩니다. s(k)=(v,ver)의 경우  s(k).value로 인해 v 로 표시하고, ver by s(k).version으로 표시합니다.

KVS 운영은 다음과 같이 모델링됩니다.

• put(k,v), for k\in K and v\in V,  s 상태의 블록체인을 취하고, k'!=k에 대해  s'(k')=s(k')인 s'(k)=(v,next(s(k).version)) 를 s' 로 변경합니다.
• get(k) 는 s(k)를 반환합니다.

상태는 피어에 의해 유지되지만, 주문자 및 고객에 의해 유지되지는 않습니다.

상태 파티션. KVS의 키는 특정 체인 코드의 트랜잭션 만이 체인 코드에 속하는 키를 수정할 수 있다는 의미에서 특정 체인 코드에 속하도록 이름에서 인식 할 수 있습니다. 원칙적으로 모든 체인 코드는 다른 체인 코드에 속하는 키를 읽을 수 있습니다. 두 개 이상의 체인 코드에 속하는 상태를 수정하는 교차 체인 코드 트랜잭션 지원은 post-v1 기능입니다.

Ledger(원장)

Ledger는 시스템 운영 중에 발생하는 모든 성공적인 상태 변경 (유효한 트랜잭션에 대해 이야기 함) 및 상태 변경 시도 실패 (유효하지 않은 트랜잭션에 대해 이야기)의 검증 가능한 기록을 제공합니다.

Ledger는 주문 서비스 (1.3.3 절 참조)가 (유효하거나 유효하지 않은) 트랜잭션 블록의 완전히 정렬 된 해시 체인으로 구성됩니다. 해시 체인은 원장에 블록의 전체 순서를 부과하고 각 블록에는 완전히 정렬 된 트랜잭션의 배열이 포함됩니다. 이렇게하면 모든 거래에서 전체 주문이 부과됩니다.

원장은 모든 동료 및 선택적으로 주문자의 하위 집합에 보관됩니다. 발주자의 맥락에서 우리는 원장을 원고 (OrdererLedger)라고 부르지 만, 피어의 맥락에서는 원장을 피어 리더 (PeerLedger)라고 부릅니다. PeerLedger는 OrdererLedger와 다른 점은 동료는 유효하지 않은 트랜잭션과 유효한 트랜잭션을 구분하는 비트 마스크를 로컬에서 유지한다는 점입니다 (자세한 내용은 XX 절 참조).

PeersLedger는 섹션 XX (v1 기능 이후)에서 설명한대로 피어 투 피할 수 있습니다. OrdererLedger는 내결함성 및 가용성 (PeerLedger)을 유지 관리하며 주문 서비스 속성 (1.3.3 참조)이 유지되면 언제든지 제거 할 것인지 결정할 수 있습니다.

회계 원장은 동료가 모든 거래 내역을 재생하고 상태를 재구성 할 수있게합니다. 그러므로 Sec 1.2.1에서 기술 된 상태는 선택적 데이터 구조이다.

Nodes(노드)

노드는 블록 체인의 통신 엔터티입니다. "노드"는 동일한 유형의 여러 노드가 동일한 물리적 서버에서 실행될 수 있다는 점에서 논리적인 기능입니다. "신뢰 도메인"에서 노드를 그룹화하고 노드를 제어하는 논리 엔터티와 관련된 노드의 수를 계산합니다.

세 가지 유형의 노드가 있습니다.

1. 클라이언트 또는 제출 클라이언트(submitting-client) : 실제 트랜잭션 호출을 최종 사용자에게 제출하고 트랜잭션 제안을 주문 서비스에 브로드 캐스팅하는 클라이언트.
2. 피어 (Peer) : 트랜잭션을 커밋하고 주와 원장의 복사본을 유지하는 노드입니다 (1.2 절 참조). 게다가 동료는 특별한 보증인 역할을 할 수 있습니다.
3. 주문 서비스 노드 또는 주문자 : 원자력 또는 총 주문 방송과 같은 배달 보증을 구현하는 통신 서비스를 실행하는 노드.

다음은 노드 유형에 대해 자세히 설명합니다.

Client(클라이언트)

클라이언트는 최종 사용자를 대신하여 작동하는 엔티티를 나타냅니다. 블록 체인과 통신하기 위해 피어에 연결해야합니다. 클라이언트는 원하는 피어에 연결할 수 있습니다. 클라이언트는 트랜잭션을 작성하고 이로 인해 트랜잭션을 호출합니다.

2 절에서 자세히 설명했듯이 클라이언트는 동료 및 주문 서비스와 통신합니다.

Peer(피어)

피어는 주문 서비스에서 블록 형태로 주문 된 상태 업데이트를 받고 상태와 원장을 유지 관리합니다.

또래는 피어 (peer) 또는 보증인 (endorser)의 특별한 역할을 수행 할 수 있습니다. 엔도 싱 피어의 특수 기능은 특정 체인 코드와 관련하여 발생하며 커밋되기 전에 트랜잭션을 승인하는 것으로 구성됩니다. 모든 체인 코드는 보증하는 피어 세트를 참조 할 수있는 보증 정책을 지정할 수 있습니다. 이 정책은 섹션 2 및 3에서 나중에 설명하는 바와 같이 유효한 트랜잭션 보증 (일반적으로 엔도 터스 시그너처 세트)에 필요한 충분 조건을 정의합니다. 새 체인 코드를 설치하는 배포 트랜잭션의 특수한 경우 (배포) 보증 정책은 다음과 같습니다. 시스템 체인 코드의 보증 정책으로 지정됩니다.

Ordering service nodes(Orderers)(주문 서비스 노드(주문자))

주문자는 주문 서비스, 즉 배송 보증을 제공하는 통신 패브릭을 형성한다. 주문 서비스는 여러 가지 방법으로 구현 될 수 있습니다. 즉, 중앙 집중식 서비스 (개발 및 테스트에 사용됨)에서 다른 네트워크 및 노드 결함 모델을 대상으로하는 분산 된 프로토콜에 이르기까지 다양합니다.

주문 서비스는 클라이언트와 동료에게 공유 통신 채널을 제공하여 트랜잭션이 포함 된 메시지에 대한 브로드 캐스트 서비스를 제공합니다. 클라이언트는 채널에 연결하여 채널에서 메시지를 브로드 캐스팅 한 다음 모든 피어에 전달할 수 있습니다. 이 채널은 모든 메시지의 원자 배달, 즉 총 주문 배송 및 메시지 전달 (구현 관련) 안정성을 지원합니다. 즉, 채널은 연결된 모든 피어에게 동일한 메시지를 출력하고 동일한 논리적 순서로 모든 피어에게 출력합니다. 이 원자 적 통신 보장은 전체 주문 방송, 원자력 방송 또는 분산 시스템의 컨센서스라고도합니다. 전달된 메시지는 블록 체인 상태에 포함될 후보 트랜잭션입니다.

• 파티셔닝 (서비스 채널 주문) : 주문 서비스는 게시 / 가입 (게시 / 보조) 메시징 시스템의 주제와 비슷한 여러 채널을 지원할 수 있습니다. 클라이언트는 주어진 채널에 연결하여 메시지를 보내고 도착 메시지를 얻을 수 있습니다. 채널은 파티션이라고 생각할 수 있습니다. 한 채널에 연결하는 클라이언트는 다른 채널의 존재를 인식하지 못하지만 클라이언트는 여러 채널에 연결할 수 있습니다. Hyperledger Fabric v1에 포함 된 일부 주문 서비스 구현은 여러 채널을 지원하지만 프레젠테이션의 편의를 위해이 문서의 나머지 부분에서는 주문 서비스가 단일 채널 / 주제로 구성된다고 가정합니다.

• 주문 서비스 API : 피어는 주문 서비스에서 제공하는 인터페이스를 통해 주문 서비스에서 제공하는 채널에 연결합니다. 주문 서비스 API는 두 가지 기본 작업 (보다 일반적으로 비동기 이벤트)으로 구성됩니다.

• TODO : 클라이언트 / 피어 지정 시퀀스 번호 아래에서 특정 블록을 가져 오기위한 API 부분을 추가하십시오.
  • broadcast(blob): 클라이언트가 채널을 통해 전파하기 위해 임의의 메시지 blob을 방송하기 위해 이것을 호출합니다. 이것은 요청을 서비스에 보낼 때 BFT 컨텍스트에서 request(blob)이라고도합니다.
  • deliver(seqno, prevhash, blob): 주문 서비스는 피어에서 이것을 호출하여 지정된 음수가 아닌 정수 시퀀스 번호 (seqno)와 가장 최근에 전달 된 blob(prevhash)의 해시를 사용하여 메시지 blob을 전달합니다. 즉, 주문 서비스의 출력 이벤트입니다. deliver()은 pub-sub 시스템에서는 notify() 또는 BFT 시스템에서 commit()이라고도합니다.

• Ledger and block formation(원장 및 블록 형성): 장부 (1.2.2 절 참조)에는 주문 서비스가 출력 한 모든 데이터가 포함됩니다. 간단히 말해서, 이것은 전달 (seqno, prevhash, blob) 이벤트의 시퀀스이며, 앞에서 설명한 prevhash의 계산에 따라 해시 체인을 형성합니다.

대부분의 경우, 효율성 향상을 위해 개별 트랜잭션(blobs)을 출력하는 대신 주문 서비스는 BLOB 및 출력 블록을 단일 deliver 이벤트 내에서 그룹화(batch)합니다. 이 경우, 순서 서비스는 각 블록 내의 얼룩의 결정론적 순서를 부과하고 전달해야한다. 블록 내의 얼룩의 수는 주문 서비스 구현에 의해 동적으로 선택 될 수있다.

다음에서는 표현의 편의를 위해 서비스 프로퍼티(이 하위 섹션의 나머지 부분)를 정의하고 deliver , 이벤트 당 하나의 blob 가정하여 트랜잭션 보증의 워크 플로 (2 절)를 설명합니다. 블록에 대한 deliver 이벤트가 블럭 내의 blob의 위에서 언급 한 결정 론적 순서에 따라 블록 내의 각 blob에 대한 개별 deliver 이벤트의 시퀀스에 해당한다고 가정하면 이러한 이벤트는 블록으로 쉽게 확장됩니다.

• Ordering service properties(주문 서비스 속성): 주문 서비스 (또는 원자력 방송 채널)의 보장은 방송 된 메시지에 어떤 일이 일어나고 전달 된 메시지간에 어떤 관계가 존재 하는지를 규정합니다. 이러한 보증은 다음과 같습니다.

1. 안전성 (일관성 보장) : 피어가 채널에 충분히 오랜 기간 연결되어있는 경우 (연결이 끊어 지거나 충돌 할 수는 있지만 다시 시작하고 다시 연결됨) 동일한 일련의 전달 된 메시지 (seqno, prevhash, blob) 가 표시됩니다. 메시지. 즉, 출력 (deliver()  이벤트)은 모든 피어에서 동일한 순서로 시퀀스 번호에 따라 발생하며 동일한 시퀀스 번호에 대해 동일한 내용 (blob and prevhash)을 전달합니다. 이것은 논리적 순서 일 뿐이며, 한 peer의 deliver(seqno, prevhash, blob) 는 다른 peer에서 같은 메시지를 출력하는 deliver(seqno, prevhash, blob)와 실시간 관계가 필요하지 않습니다. 다르게 말하자면 특정 seqno,가 주어지면 두 개의 올바른 피어가 다른prevhash 또는 blob 값을 제공하지 않습니다. 또한, 일부 클라이언트 (피어)가 실제로 broadcast(blob)을 호출하지 않고, 바람직하게는, 브로드 캐스트 된 모든 브롭 (blob)이 단지 한 번만 전달되는 경우가 아니라면, 가치 브롭 (blob)은 전달되지 않는다. 또한 deliver()이벤트는 이전 deliver()  이벤트(prevhash)의 데이터에 대한 암호화 해시를 포함합니다. 순서 서비스가 원자 적 브로드 캐스트 보장을 구현할 때 prevhash는 시퀀스 번호 seqno-1이있는 deliver () 이벤트의 매개 변수를 암호화 해시입니다. 이렇게하면 나중에 섹션 4와 5에서 설명하는대로 주문 서비스 출력의 무결성을 확인하는 데 사용되는 deliver() 이벤트에서 해시 체인을 설정합니다. 첫 번째 deliver() 이벤트의 특별한 경우, prevhash는 기본값을가집니다.
2. 생명 (배달 보증) : 주문 서비스에 대한 보증은 주문 서비스 구현에 의해 지정됩니다. 정확한 보증은 네트워크 및 노드 결함 모델에 따라 달라질 수 있습니다. 원칙적으로 제출 클라이언트가 실패하지 않으면 주문 서비스는 주문 서비스에 연결된 모든 올바른 피어가 결국 제출 된 모든 트랜잭션을 제공하도록 보장해야합니다.

요약하면 주문 서비스에서는 다음 속성을 보장합니다.

• Agreement(협정). 올바른 seersno를 가진 올바른 동료 dddeliver (seqno, prevhash0, blob0) 및 ddddeliver (seqno, prevhash1, blob1)의 두 이벤트에 대해서는 prevhash0 == prevhash1 및 blob0 == blob1;

• Hashchain integrity(해쉬체인 무결성). deliver(seqno-1, prevhash0, blob0) and deliver(seqno, prevhash, blob),prevhash = HASH(seqno-1||prevhash0||blob0).

• No skipping(건너 뛰지 않아). 주문 서비스가 seqno> 0과 같은 올바른 피어 p에서 deliver(seqno, prevhash, blob) at a correct peer p, such that seqno>0, then p already delivered an eventdeliver(seqno-1, prevhash0, blob0).

• No creation(창조가 없습니다). deliver(seqno, prevhash, blob) at a correct peer must be preceded by a broadcast(blob) event at some (possibly distinct) peer;

• No duplication(optional, yet desirable)(중복 없음). For any two events broadcast(blob) and broadcast(blob'), when two events deliver(seqno0, prevhash0, blob) and deliver(seqno1, prevhash1, blob') occur at correct peers and blob == blob', then seqno0==seqno1 andprevhash0==prevhash1.

• Liveness(활력).  If a correct client invokes an event broadcast(blob) then every correct peer “eventually” issues an event deliver(*, *, blob), where * denotes an arbitrary value.

Basic workflow of transaction endorsement(거래 보증의 기본 흐름)

다음은 트랜잭션에 대한 상위 레벨 요청 플로우를 개괄적으로 설명합니다.

참고 : 다음 프로토콜 *은 모든 트랜잭션이 결정적이라고 가정하지 않습니다. 즉, 결정적이지 않은 트랜잭션을 허용합니다.

클라이언트는 트랜잭션 생성하고, 선택한 피어를 인증하는 동료에게 전송

트랜잭션을 호출하기 위해 클라이언트는 자신이 선택한 피어 투 피어 집합에 PROPOSE 메시지를 보냅니다 (동시에는 아니지만 - 섹션 2.1.2 및 2.3 참조). 지정된 chaincodeID에 대한 승인 피어 집합은 피어를 통해 클라이언트에 제공되며, 이는 인증 정책에서 피어를 인정하는 피 인증 자 집합을 알게됩니다 (3 절 참조). 예를 들어, 주어진 chaincodeID의 모든 endorsers로 트랜잭션을 전송할 수 있습니다. 즉, 일부 최종 사용자는 오프라인 일 수 있고, 다른 사용자는 반대 할 수 있으며 거래를 승인하지 않을 수도 있습니다. 제출하는 클라이언트는 사용 가능한 엔도서를 사용하여 정책 표현식을 만족 시키려고 시도합니다.

다음에서는 먼저 PROPOSE 메시지 형식을 자세히 설명한 다음 제출하는 클라이언트와 엔도 서 간의 상호 작용 패턴을 논의합니다.

PROPOSE message format(PROMISE 메시지 형식)

PROPOSE 메시지의 형식은 <PROPOSE,tx,[anchor]>입니다. 여기서 tx는 다음에서 설명하는 필수 및 anchor 선택적 인수입니다.

• tx=<clientID,chaincodeID,txPayload,timestamp,clientSig>, where
  • clientID 는 제출하는 클라이언트의 ID이며,
  • chaincodeID 는 트랜잭션이 속한 체인 코드를 나타내며,
  • txPayload 는 제출 된 트랜잭션 자체를 포함하는 페이로드이며,
  • timestamp 는 클라이언트에 의해 유지되는 (모든 새로운 트랜잭션마다) 단조롭게 증가하는 정수이며,
  • clientSig 는 tx의 다른 필드에있는 클라이언트의 서명입니다.  txPayload의 세부 사항은 호출 트랜잭션과 배치 트랜잭션 (즉, 배치 특정 시스템 체인 코드를 참조하는 트랜잭션 호출) 사이에서 달라집니다. invoke 트랜잭션의 경우 txPayload 는 두 개의 필드로 구성됩니다.
  • txPayload = <operation, metadata>, 여기서
    • operation은 체인 코드 연산 (함수)과 인수를 나타내며,
    • metadata는 호출과 관련된 속성을 나타냅니다. 배포 트랜잭션의 경우 txPayload는 세 개의 필드로 구성됩니다.
  • txPayload = <source, metadata, policies>, 여기서
    • source는 체인 코드의 소스 코드를 나타내며,
    • metadata는 체인 코드 및 애플리케이션과 관련된 속성을 나타내며,
    • policies 에는 보증 정책과 같이 모든 피어가 액세스 할 수있는 체인 코드와 관련된 정책이 포함됩니다. 배포 트랜잭션에는 txPayload와 함께 보증 정책이 제공되지 않지만, deploy의 txPayload에는 보증 정책 ID 및 해당 매개 변수가 포함됩니다 (3 절 참조).
• anchor는 KVS (1.2 절 참조)의 특정 버전의 키에 대해 PROPOSE 요청을 바인딩하거나 "앵커"하는 키 버전 쌍 (즉, 앵커는 KxN의 하위 집합)을 포함합니다. 클라이언트가 anchor 인수를 지정하면, endorser는 로컬 KVS match anchor (자세한 내용은 2.2 절 참조)에 있는 해당 키의 버전 번호 읽기에서만 트랜잭션을 승인합니다.

Cryptographic hash of tx is used by all nodes as a unique transaction identifier tid (i.e., tid=HASH(tx)). The client stores tid in memory and waits for responses from endorsing peers.

tx의 암호화 해시는 모든 노드에서 고유 한 트랜잭션 식별자 tid (즉, tid=HASH(tx))로 사용됩니다. 클라이언트는 메모리에 tid를 저장하고 피어를 승인하는 응답을 기다립니다.

Message patterns(메시지 패턴)

For example, a client would typically send <PROPOSE, tx> (i.e., without the anchor argument) to a single endorser, which would then produce the version dependencies (anchor) which the client can later on use as an argument of its PROPOSE message to other endorsers. As another example, the client could directly send <PROPOSE, tx> (without anchor) to all endorsers of its choice. Different patterns of communication are possible and client is free to decide on those (see also Section 2.3.).

클라이언트는 엔도 서와의 상호 작용 순서를 결정합니다. 예를 들어, 클라이언트는 일반적으로 anchor 인자가없는 <PROPOSE, tx>를 하나의 엔도 서에 보내면 나중에 클라이언트가 PROPOSE 메시지의 인수로 사용할 수있는 버전 종속성 (anchor)을 생성합니다 다른 endorsers. 또 다른 예로, 클라이언트는 자신이 선택한 모든 endorsers에 직접 <PROPOSE, tx> ( anchor가 없는)를 보낼 수 있습니다. 서로 다른 의사 소통 패턴이 가능하며 고객은 자유롭게 결정할 수 있습니다 (2.3 절 참조).

검증하는 피어는 거래를 시뮬레이션하고 보증 서명을 생성

클라이언트로부터 <PROPOSE,tx,[anchor]> 메시지를 수신하면, 인증 피어 epID는 먼저 클라이언트의 서명 clientSig를 검증 한 다음 트랜잭션을 시뮬레이트합니다. 클라이언트가 anchor를 특정하면, 엔도 싱 피어는 그 로컬 KVS 내의 대응하는 키의 판독 버전 번호 (즉, 아래에서 정의 된 readset)가 anchor에 의해 지정된 버전 번호와 일치 할 때만 트랜잭션을 시뮬레이트한다.

트랜잭션을 시뮬 레이팅하는 것은 트랜잭션이 참조하는 체인 코드 (chaincodeID)를 호출하고 승인하는 피어가 로컬로 보유하고있는 상태의 복사본을 호출하여 트랜잭션을 임시로 실행 (txPayload)하는 피어를 승인하는 것과 관련됩니다.

실행 결과로, 승인하는 피어는 DB 언어로 MVCC + postimage 정보라고도하는 읽기 버전 종속성 (readset) 및 상태 업데이트 (writeset)를 계산합니다.

상태는 키 / 값 (k / v) 쌍으로 구성됩니다. 모든 k / v 항목은 버전이 지정됩니다. 즉, 모든 항목은 키 아래에 저장된 값이 업데이트 될 때마다 증가하는 순서화 된 버전 정보를 포함합니다. 트랜잭션을 해석하는 피어는 체인 코드로 읽거나 쓰는 모든 k / v 쌍을 기록하지만 피어는 아직 상태를 업데이트하지 않습니다. 더 구체적으로는:

• 보증하는 피어가 트랜잭션을 실행하기 전에 상태가 주어지면 트랜잭션이 읽는 모든 키 k에 대해 pair (k,s(k).version)가 readset에 추가됩니다.
• 또한 트랜잭션에 의해 새로운 값 v'로 수정 된 모든 키 k에 대해 pair (k,v')가 writeset세트에 추가됩니다. 또는 v '는 이전 값 (s(k).value)에 대한 새 값의 델타가 될 수 있습니다.

클라이언트가 PROPOSE 메시지에서 anchor를 지정하면 클라이언트 지정 anchor는 트랜잭션을 시뮬레이션 할 때 피어를 승인하여 생성 된 readset과 같아야합니다.

그런 다음 피어는 트랜잭션을 승인하는 피어의 로직 (승인 논리라고 함)으로 내부적으로 tran-proposal (아마도 tx)을 전달합니다. 기본적으로 피어의 논리를 승인하면 트란 제안을 받아들이고 단순히 tran-proposal에 서명합니다. 그러나, 승인 논리는 임의의 기능을 해석하여 예를 들어 tran-proposal과 tx  및 레거시 시스템과 상호 작용하여 트랜잭션을 보증할지 여부에 대한 결정에 이르게 할 수있다.

승인 로직이 트랜잭션을 승인하기로 결정하면 <TRANSACTION-ENDORSED, tid, tran-proposal,epSig> 메시지를 제출 클라이언트 (tx.clientID)로 전송합니다. 여기서,

• tran-proposal := (epID,tid,chaincodeID,txContentBlob,readset,writeset), where txContentBlob is chaincode/transaction specific information. The intention is to have txContentBlob used as some representation of tx (e.g., txContentBlob=tx.txPayload). 여기서 txContentBlob는 체인 코드 / 거래 관련 정보입니다. 의도는 txContentBlob를 tx의 일부 표현으로 사용하는 것입니다 (예 : txContentBlob=tx.txPayload).
• epSig는 tran-proposal에서 승인하는 피어의 서명입니다.

그렇지 않으면, 보증 논리가 거래를 승인하는 것을 거부하는 경우, 보증인은 제출 클라이언트에게 (TRANSACTION-INVALID, tid, REJECTED) 메시지를 보낼 수 있습니다.

엔도서가이 단계에서 상태를 변경하지 않는다는 것을 주의하십시오. 승인의 컨텍스트에서 트랜잭션 시뮬레이션에 의해 생성 된 업데이트는 상태에 영향을 미치지 않습니다!

제출 클라이언트는 거래에 대한 보증을 수집하고, 주문 서비스를 통해 이를 방송

제출 클라이언트는 "충분한"메시지와 서명 (TRANSACTION-ENDORSED, tid, *, *)을 수신 할 때까지 기다렸다가 거래 제안서가 승인되었다고 결론을 내립니다. 2.1.2 절에서 논의 된 바와 같이, 이것은 하나 이상의 endorsers와의 상호 작용의 왕복 여행을 포함 할 수 있습니다.

"충분함"의 정확한 수는 chaincode 보증 정책에 따라 다릅니다(섹션 3 참조). 보증 정책이 충족되면 거래가 승인됩니다. 아직 커밋되지 않았 음을 유의하십시오. 트랜잭션이 승인되었음을 입증하는 피어 투 피어 (peer)로부터의 서명 된 TRANSACTION-ENDORSED 메시지의 집합을 보증 (endorsement)이라고 부르며 보증으로 표시합니다.

제출 고객이 거래 제안서에 대한 보증을 수집하지 않으면 나중에 재 시도 할 수있는 옵션으로이 트랜잭션을 포기합니다.

유효한 보증서가있는 거래의 경우 이제 broadcast(blob),를 사용하기 시작합니다. 제출 클라이언트는 blob=endorsement 인 브로드 캐스트 (blob)를 사용하여 순서 서비스를 호출합니다. 클라이언트가 직접 주문 서비스를 호출 할 능력이없는 경우, 클라이언트는 자신이 선택한 피어를 통해 브로드 캐스트를 프록시 할 수 있습니다. 그러한 피어는 endorsement으로부터 어떠한 메시지도 제거하지 않도록 클라이언트에 의해 신뢰되어야하며, 그렇지 않으면 거래가 무효로 간주 될 수 있습니다. 그러나 프록시 피어는 유효한 endorsement을 작성하지 않을 수 있습니다.

주문 서비스는 동료에게 트랜잭션을 전달

이벤트 deliver(seqno, prevhash, blob)이 발생하고 피어가 시퀀스 번호가 seqno보다 낮은 blob에 대한 모든 상태 업데이트를 적용하면 피어는 다음을 수행합니다.

• blob.endorsement가 참조하는 chaincode (blob.tran-proposal.chaincodeID)의 정책에 따라 blob.endorsement가 유효한지 확인합니다.
• 일반적인 경우에는 종속성 (blob.endorsement.tran-proposal.readset)이 위반되지 않았 음을 확인합니다. 보다 복잡한 유스 케이스의 경우, 보증서의 tran-proposal가 다를 수 있으며,이 경우 보증 정책(3절)은 국가의 진화 방식을 지정합니다.

종속성 확인은 상태 업데이트에 대해 선택되는 일관성 속성 또는 "격리 보증"에 따라 여러 가지 방법으로 구현 될 수 있습니다. 연쇄 코드 보증 정책이 다른 연쇄 보증 정책을 지정하지 않는 한 연 속성은 기본 격리 보증입니다. readset의 모든 키와 관련된 버전을 해당 상태의 해당 키 버전과 같게 요구하고이 요구 사항을 충족시키지 않는 트랜잭션을 거부함으로써 직렬화 기능을 제공 할 수 있습니다.

• 이러한 모든 검사가 통과되면 트랜잭션은 유효하거나 완결 된 것으로 간주됩니다. 이 경우 피어는 PeerLedger의 비트 마스크에서 트랜잭션을 1로 표시하고 blob.endorsement.tran-proposal.writeset을 블록 체인 상태에 적용합니다 (tran-proposals가 동일한 경우 그렇지 않으면 승인 정책 로직이 blob을 사용하는 함수를 정의합니다). 배서).
• blob.endorsement의 보증 정책 확인이 실패하면 트랜잭션은 유효하지 않으며 피어는 PeerLedger의 비트 마스크에서 트랜잭션을 0으로 표시합니다. 유효하지 않은 트랜잭션으로 인해 상태가 변경되지는 않습니다.

주어진 시퀀스 번호로 배달 이벤트 (블록)를 처리 한 후에 모든 (올바른) 피어가 동일한 상태를 유지하기에 충분하다는 점에 유의하십시오. 즉, 순서 서비스의 보증에 의해, 모든 올바른 피어는 동일한 deliver(seqno, prevhash, blob) 이벤트를 수신합니다. 보증 정책의 평가와 readset의 버전 종속성 평가가 결정적이기 때문에 모든 정확한 피어는 BLOB에 포함 된 트랜잭션이 유효한지 여부와 동일한 결론에 도달하게됩니다. 따라서 모든 피어는 동일한 트랜잭션 순서를 적용 및 적용하고 동일한 방식으로 상태를 업데이트합니다.

트랜잭션 흐름 (일반적인 경우 경로)의 그림.

그림 1. 하나의 가능한 트랜잭션 플로우 (일반적인 경우 경로)의 그림.

Endorsement policies(보증 정책)

Endorsement policy specification(보증 정책 사양)

보증 정책은 거래를 승인하는 조건입니다. 블록 체인 피어는 특정 체인 코드를 설치하는 배포 트랜잭션에 의해 참조되는 사전 지정된 일련의 deploy 정책을 가지고 있습니다. 승인 정책을 매개 변수화 할 수 있으며 이러한 매개 변수는 deploy 트랜잭션에 의해 지정 될 수 있습니다.

블록 체인 및 보안 속성을 보장하기 위해 보증 정책 집합은 한정된 실행 시간 (종료), 결정론, 성능 및 보안 보장을 보장하기 위해 제한된 기능 세트로 입증 된 정책 세트여야만 합니다.

(예 : 체인 코드 배포 시간에 deploy  트랜잭션을 통한) 승인 정책의 동적 추가는 제한적 정책 평가 시간 (종료), 결정론, 성능 및 보안 보장 측면에서 매우 민감합니다. 따라서 승인 정책의 동적 추가는 허용되지 않지만 향후 지원 될 수 있습니다.

Transaction evaluation against endorsement policy(보증 정책에 대한 거래 평가)

A transaction is declared valid only if it has been endorsed according to the policy. An invoke transaction for a chaincode will first have to obtain an endorsement that satisfies the chaincode’s policy or it will not be committed. This takes place through the interaction between the submitting client and endorsing peers as explained in Section 2.

트랜잭션은 정책에 따라 승인 된 경우에만 유효한 것으로 선언됩니다. 체인 코드에 대한 호출 트랜잭션은 먼저 체인 코드의 정책을 충족하거나 커밋되지 않는 보증을 획득해야합니다. 이것은 섹션 2에서 설명한 바와 같이 제출 클라이언트와 승인하는 동료 간의 상호 작용을 통해 발생합니다.

공식적으로 보증 정책은 보증에 대한 술어이며, TRUE 또는 FALSE로 평가 될 가능성이있는 추가 상태 일 수 있습니다. 배포 트랜잭션의 경우 보증은 시스템 전체 정책 (예 : 시스템 체인 코드)에 따라 수행됩니다.

보증 정책 술어는 특정 변수를 나타냅니다. 잠재적으로 다음을 참조 할 수 있습니다.

1. 체인 코드의 메타 데이터에있는 체인 코드와 관련된 키 또는 ID (예 : 일련의 엔도 서)
2. 상기 체인 코드의 추가 메타 데이터;
3. endorsement.tran-proposal 및 endorsement의 요소.
4. 그리고 잠재적으로 더.

위의 목록은 표현력과 복잡성이 증가함에 따라 정렬됩니다. 즉, 노드의 키와 ID 만 참조하는 정책을 지원하는 것은 비교적 간단합니다.

보증 정책 술어의 평가는 결정론적이어야합니다. 다른 피어와 상호 작용할 필요가 없지만 모든 올바른 피어가 동일한 방법으로 보증 정책을 평가할 수 있도록 모든 피어가 로컬로 평가해야합니다.

Example endorsement policies(예시 보증 정책)

어는 논리 표현식을 포함 할 수 있으며 TRUE 또는 FALSE로 평가됩니다. 일반적으로 조건은 체인 코드에 대해 피어를 보증함으로써 발행 된 트랜잭션 호출에서 디지털 서명을 사용합니다.

체인 코드가 엔도 서 집합 E = {Alice, Bob, Charlie, Dave, Eve, Frank, George}를 지정한다고 가정합니다. 몇 가지 예시 정책 :

• A의 모든 서명은 E의 모든 회원들로부터받은 동일한 tran-proposal 에 있습니다.
• E의 단일 회원으로부터 A 유효한 서명.
• 조건 (Alice OR Bob) AND (any two of: Charlie, Dave, Eve, Frank, George)에 따라 피어를 승인하는 것과 동일한 tran-proposal 에서 유효한 서명
• 7 명의 endorsers 중 5 명이 동일한 tran-proposal에서 유효한 서명. (더 일반적으로 n > 3f  endorser 인 chaincode, n endorsers 중 2f+1에 의한 유효한 서명 또는 (n + f) / 2 endorsers 이상의 그룹에 의한 유효한 서명)
• {Alice=49, Bob=15, Charlie=15, Dave=10, Eve=7, Frank=3, George=1}과 같이 endorsers에 "stake"또는 "weights" 총 지분은 100입니다 : 정책은 {Alice, X}와 George와 다른 X가있는 지분의 대부분 (즉, 지분을 50 개 이상 보유한 그룹)의 유효한 서명이 필요합니다. {everyone together except Alice}. 등등.
• 앞의 예제 조건에서 스테이크의 할당은 정적 (체인 코드의 메타 데이터에 고정) 또는 동적 (예 : 체인 코드의 상태에 따라 다르며 실행 중에 수정 될 수 있음) 일 수 있습니다.
• tran-proposal1의 (Alice or Bob)에서 유효한 서명과 tran-proposal2의 Charlie, Dave, Eve, Frank, George 중 어느 하나의 유효한 서명. 여기서 tran-proposal1과 tran-proposal2는 상태 업데이트와 승인하는 동료에서만 서로 다릅니다.

이러한 정책의 유용성은 애플리케이션, 엔도 서의 실패 또는 오작동 및 기타 다양한 속성에 대한 솔루션의 원하는 복원력에 따라 달라집니다.

(post-v1). Validated ledger and PeerLedger checkpointing (pruning)((v1 이후)검증된 원장 및 PeerLedger검사 점(잘라내기))

Validated ledger (VLedger) (확인된 원장(VLedger))

유효하고 커밋 된 트랜잭션 (예 : Bitcoin)이 포함 된 원장의 추상화를 유지하기 위해 동료는 주 및 원장 외에도 Validated Ledger (또는 VLedger)를 유지 관리 할 수 있습니다. 이것은 유효하지 않은 트랜잭션을 필터링하여 원장에서 파생 된 해시 체인입니다.

VLedger 블록 (여기서 vBlocks라고 함)의 구성은 다음과 같이 진행됩니다. PeerLedger 블록에는 유효하지 않은 트랜잭션 (즉, 잘못된 보증 또는 잘못된 버전 종속성이있는 트랜잭션)이 포함될 수 있으므로 블록에서 트랜잭션이 vBlock에 추가되기 전에 이러한 트랜잭션이 피어에 의해 필터링됩니다. 모든 피어는 (PeerLedger와 관련된 비트 마스크를 사용하여) 스스로 처리합니다. vBlock은 필터링 된 잘못된 트랜잭션이없는 블록으로 정의됩니다. 이러한 vBlock은 기본적으로 크기면에서 동적이며 비어있을 수 있습니다. vBlock 구성에 대한 그림이 아래 그림에 나와 있습니다.

그림 2. 원장 (PeerLedger) 블록에서 검증 된 원장 블록 (vBlock) 형성의 그림.

vBlock은 모든 피어에 의해 해시 체인에 연결됩니다. 보다 구체적으로, 검증 된 원장의 모든 블록에는 다음이 포함됩니다.

• 이전 vBlock의 해시입니다.

• vBlock 번호.
• 마지막 vBlock이 계산 된 이후에 피어에 의해 커밋 된 모든 유효한 트랜잭션 (즉, 해당 블록에서 유효한 트랜잭션 목록)의 정렬 된 목록입니다.
• 현재 vBlock이 파생 된 해당 블록의 해시 (PeerLedger에서).

PeerLedger Checkpointing(PeerLedger 체크포인트)

원장에 유효하지 않은 트랜잭션이 포함되어있어 영원히 기록되지 않을 수도 있습니다. 그러나 PeerLedger 블록을 폐기 한 후에 PeerLedger를 삭제하면 해당되는 vBlock을 생성 할 수 없습니다. 즉,이 경우 새 피어가 네트워크에 조인하면 다른 피어가 PeerLedger와 관련된 삭제 된 블록을 참여 피어로 전송할 수 없으며 참가 피어에게 해당 vBlock의 유효성을 알리지 못합니다.

PeerLedger의 제거 (pruning)를 용이하게하기 위해이 문서는 검사 점 메커니즘을 설명합니다. 이 메커니즘은 피어 네트워크에서 vBlock의 유효성을 확인하고 체크 포인트 된 vBlock이 폐기 된 PeerLedger 블록을 대체 할 수있게합니다. 이렇게하면 유효하지 않은 트랜잭션을 저장할 필요가 없으므로 저장 공간이 줄어 듭니다. 또한 PeerLedger를 재생하여 상태를 재구성 할 때 개별 트랜잭션의 유효성을 확인할 필요가 없으므로 유효성을 검사 한 원장에 포함 된 상태 업데이트를 재생할 수 있으므로 네트워크에 가입 한 새 피어의 상태를 재구성하는 작업이 줄어 듭니다.

Checkpointing protocol(체크포인트 프로토콜)

검사 점 지정은 CHK 블록마다 피어에 의해 주기적으로 수행되며 CHK는 구성 가능한 매개 변수입니다. 검사 점을 초기화하기 위해 피어는 다른 피어에게 <CHECKPOINT,blocknohash,blockno,stateHash,peerSig> 메시지를 브로드 캐스트 (예 : 험담)합니다. 여기서 blockno는 현재 블록 번호이고 blocknohash는 해당 해시이고 stateHash는 최신 상태의 해시입니다 (예 : Merkle 해시에 의해 생성됨), peerSig는 검증 된 원장을 참조하는 (CHECKPOINT, blocknohash, blockno, stateHash)의 피어 서명입니다.

피어는 유효한 CHECKPOINT를 설정하기 위해 blockno, blocknohash 및 stateHash가 일치하는 서명 된 메시지를 충분히 얻을 때까지 CHECKPOINT 메시지를 수집합니다 (4.2.2 절 참조).

blocknohash가있는 블록 번호 blockno에 대한 유효한 검사 점을 설정하면 피어가 다음을 수행합니다.

blockno>latestValidCheckpoint.blockno 인 경우, 피어는 latestValidCheckpoint=(blocknohash,blockno)를 할당하고,

유효한 체크 포인트를 구성하는 각각의 피어 서명들의 세트를 세트 latestValidCheckpointProof에 저장하고,

stateHash에 상응하는 상태를 latestValidCheckpointedState에 저장하고,

(선택 사항) 블록 번호 blockno(포함)까지 PeerLedger 를 제거합니다.

Valid checkpoints(유효한 체크포인트)

명확하게, 체크 포인트 프로토콜은 다음과 같은 질문을 제기합니다 : 피어가 언제``PeerLedger``를자를 수 있습니까? 얼마나 많은``CHECKPOINT`` 메시지가 "충분히 많다"는 것인가? 이는 체크 포인트 유효성 정책에 의해 정의되며, 적어도 두 가지 가능한 접근법이 결합 될 수 있습니다.

로컬 (피어 전용) 검사 점 유효성 정책 (LCVP). 주어진 피어 p의 로컬 정책은 피어 P 트러스트와 그의 CHECKPOINT 메시지가 유효한 체크 포인트를 설정하기에 충분한 피어 세트를 지정할 수있다. 예를 들어 피어 앨리스의 LCVP는 앨리스가 밥 또는 찰리와 데이브 모두로부터 CHECKPOINT 메시지를 수신해야한다고 정의할 수 있습니다.

글로벌 체크 포인트 유효성 정책 (GCVP). 체크 포인트 유효성 정책은 전 세계적으로 지정 될 수 있습니다. 이는 로컬 피어 정책과 비슷하지만 피어 세분성이 아닌 시스템 (블록 체인) 단위로 규정된다는 점만 다릅니다. 예를 들어, GCVP는 다음을 지정할 수 있습니다.

각 피어는 11 개의 다른 피어에 의해 확인되면 체크 포인트를 신뢰할 수 있습니다.

모든 발주자가 동일한 시스템 (즉, 신뢰 도메인)의 피어와 함께 배치되고 f 명의 발주자가 (비잔틴) 오류 일 수있는 특정 배포에서는주문자와 병치된 f + 1 명의 다른 피어에 의해 확인 된 경우 각 피어가 체크 포인트를 신뢰할 수 있습니다.