본문 바로가기

Hyperledger Fabric/Document

[HYPERLEDGER FABRIC v1.0]5. 아키텍처

 아키텍처 ( ARCHITECTURE )

아키텍처 설명 ( 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와 함께 보증 정책이 제공되지 않지만, deploytxPayload에는 보증 정책 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).
  • epSigtran-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-proposalendorsement의 요소.
  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-proposal1tran-proposal2는 상태 업데이트와 승인하는 동료에서만 서로 다릅니다.

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

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

유효한 원장 ( Validated ledger (VLedger) )

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

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

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

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

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


PeerLedger 체크포인트 ( PeerLedger Checkpointing )

원장에 유효하지 않은 트랜잭션이 포함되어있어 영원히 기록되지 않을 수도 있습니다. 그러나 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를 설정하기 위해 blocknoblocknohash 및 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 명의 다른 피어에 의해 확인 된 경우 각 피어가 체크 포인트를 신뢰할 수 있습니다.


Transaction Flow(거래 흐름)

이 문서는 표준 자산 교환 중에 발생하는 트랜잭션 메커니즘에 대해 설명합니다. 시나리오에는 무를 사고 파는 두 명의 고객 A와 B가 포함됩니다. 이들은 각각 네트워크를 통해 거래를 보내고 원장과 상호 작용하는 동료를가집니다.


Assumptions(가정)

이 플로우는 채널이 설정되어 실행 중이라고 가정합니다. 응용 프로그램 사용자는 조직의 인증 기관 (CA)을 등록 및 등록하고 네트워크 인증에 필요한 필수 암호화 자료를 다시 수신합니다.

무 코드 시장의 초기 상태를 나타내는 일련의 키 값 쌍을 포함하는 체인 코드가 피어에 설치되고 채널에 인스턴스화됩니다. 체인 코드는 일련의 거래 지시 사항과 무에 대해 합의 된 가격을 정의하는 로직을 포함합니다. 이 체인 코드에 대한 보증 정책이 설정되어있어 peerA와 peerB가 트랜잭션을 보증해야한다는 것을 나타냅니다.


1. 클라이언트 A, 트랜잭션 시작

무슨 일이야? - 고객 A가 무를 구입하라는 요청을 보냈습니다. 요청은 각각 클라이언트 A와 클라이언트 B를 대표하는 peerApeerB를 대상으로합니다. 보증 정책은 두 피어가 모든 트랜잭션을 보증해야한다는 것을 나타내므로 요청은 peerApeerB로 이동합니다. 다음으로 거래 제안이 구성됩니다. 지원되는 SDK (노드, 자바, 파이썬)를 활용하는 애플리케이션은 트랜잭션 제안서를 생성하는 사용 가능한 API 중 하나를 사용합니다. 제안은 체인 코드 기능을 호출하여 데이터를 판독기에 쓰거나 쓰기 (즉, 자산에 대한 새로운 키 값 쌍 작성) 할 수 있도록하는 요청입니다. SDK는 트랜잭션 제안서를 적절하게 설계된 형식 (gRPC를 통한 프로토콜 버퍼)으로 패키지화하기위한 shim 역할을하며 사용자의 암호화 자격 증명을 사용하여이 트랜잭션 제안서의 고유한 서명을 생성합니다.


2. 피어를 인증하고 트랜잭션을 실행하는 것을 보증하는 피어

(1) 거래 제안서가 잘 형성되었는지

(2) 과거에 제출되지 않았는지 (재생 공격 보호)

(3) 서명이 유효한지 (MSP 사용)

(4) 제출자 (예 : 클라이언트 A)가 해당 채널에서 제안 된 작업을 수행 할 수 있도록 적절한 권한을 부여 받았음을 나타냅니다. (즉, 각 인증 피어는 제출자가 채널의 작성자 정책을 충족하는지 확인합니다)

{MSP는 클라이언트에서 도착한 거래 요청을 확인하고 거래 결과 (보증)에 서명 할 수있는 피어 구성 요소입니다. * 쓰기 정책은 채널 생성시 정의되며 해당 채널에 트랜잭션을 제출할 수있는 사용자를 결정합니다.} *


3. 제안 응답 검사

응용 프로그램은 승인 피어 서명을 확인하고 제안 응답 (페이로드 표현을 포함 할 용어 용어에 대한 링크)을 비교하여 제안 응답이 동일하고 지정된 보증 정책이 충족되었는지 확인합니다 (예 : peerA 및 peerB 양측지지). 응용 프로그램이 응답을 조사하지 않거나 다른 방법으로 전달되지 않은 트랜잭션을 전달하는 경우에도 정책은 여전히 ​​동료와 시행 확인 단계에서 유지됩니다.


4. 클라이언트가 보증을 트랜잭션으로 어셈블

응용 프로그램은 거래 제안서와 응답을 "거래 메시지"내에서 주문 서비스로 "방송"합니다. 트랜잭션에는 읽기 / 쓰기 세트, 승인 피어 서명 및 채널 ID가 포함됩니다. Ordering Service는 트랜잭션을 수행하기 위해 트랜잭션의 전체 내용을 검사 할 필요가 없으며 네트워크의 모든 채널에서 트랜잭션을 수신하고 채널별로 시간순으로 순서를 지정하며 채널당 트랜잭션 블록을 생성합니다.


5. 거래가 확인되고 commit 됨

거래 블록은 채널의 모든 피어에게 전달됩니다. 블록 내의 트랜잭션은 보증 정책이 충족되고 트랜잭션 집합에 의해 읽기 집합이 생성 되었기 때문에 읽기 집합 변수에 대한 원장 상태가 변경되지 않았는지 확인하기 위해 유효성이 검사됩니다. 블록의 트랜잭션은 유효하거나 유효하지 않은 것으로 태그가 지정됩니다.


6. 원장 업데이트

각 피어는 블록을 채널의 체인에 추가하고 유효한 트랜잭션마다 쓰기 세트가 현재 상태 데이터베이스에 커밋됩니다. 클라이언트 응용 프로그램에 트랜잭션 (호출)이 체인에 영구적으로 추가되었음을 알리고 트랜잭션의 유효성을 검사했는지 유효하지 않은지 여부를 알리는 이벤트가 생성됩니다.

참고 : 서버 측 흐름과 프로토 버퍼를 더 잘 이해 하려면 스윔 레인 다이어그램을 참조하십시오.


패브릭 CA의 유저가이드 ( Fabric CA's User Guide )

이 문서의 빌드는 "master"브랜치의 것입니다.

패브릭 CA 유저가이드 시작하기


하이퍼레저패브릭 SDK ( Hyperledger Fabric SDKs )

Hyperledger Fabric은 다양한 프로그래밍 언어에 대해 다양한 SDK를 제공 할 예정입니다. 처음 두 가지는 Node.js와 Java SDK입니다. 1.0.0 릴리스 이후 곧 Python 및 Go SDK를 제공하기를 바랍니다.

Hyperledger Fabric Node SDK 설명서

Hyperledger Fabric Java SDK 설명서


Kafka 기반 주문 서비스 시작 ( Bringing up a Kafka-based Ordering Service )

경고 emptor ( Caveat emptor )

이 문서는 독자가 일반적으로 Kafka 클러스터와 ZooKeeper 앙상블을 설정하는 방법을 알고 있다고 가정합니다. 이 가이드의 목적은 OSled (Hyperledger Fabric 주문 서비스 노드) 세트가 Kafka 클러스터를 사용하고 블록 체인 네트워크에 주문 서비스를 제공하기 위해 취해야 할 단계를 식별하는 것입니다.

청사진 ( Big picture )

Fabric의 각 채널은 Kafka의 별도의 단일 파티션 주제에 매핑됩니다. OSN이 Broadcast RPC를 통해 트랜잭션을 수신하면 브로드 캐스트 클라이언트가 채널에 쓸 수있는 권한이 있는지 확인한 다음 카프카의 적절한 파티션으로 해당 트랜잭션을 중계합니다. 이 파티션은 수신 된 트랜잭션을 로컬 블록으로 그룹화하고 로컬 원장에 유지하며 Deliver RPC를 통해 클라이언트를 수신하는 OSN에 의해 소비됩니다. 낮은 수준에 대한 자세한 내용은이 디자인에 대한 정보를 제공하는 문서를 참조하십시오. 그림 8은 위에 설명 된 프로세스의 개략적인 표현입니다.

순서 ( Steps )

K 와 Z를 각각 Kafka 클러스터와 ZooKeeper 앙상블의 노드 수로 봅시다.

i. 최소한 K는 4로 설정해야합니다 (아래 4 단계에서 설명 하겠지만, 이것은 고장 내결함성을 나타 내기 위해 필요한 최소 노드 수입니다. 즉, 4 개의 브로커가있는 경우 1 개의 브로커가 작동하지 않을 수 있습니다. 모든 채널은 계속해서 쓰기 및 읽기가 가능하며 새로운 채널을 만들 수 있습니다.)

ii. Z는 3, 5 또는 7 중 하나입니다. 스플릿 브레이브 시나리오를 피하기 위해 홀수 여야하며 단일 실패 지점을 피하기 위해 1보다 커야합니다. 7 개의 ZooKeeper 서버를 초과하는 것은 과잉으로 간주됩니다.

다음과 같이 진행하십시오.

1. 주문자 : 네트워크의 기원 블록에 카프카 관련 정보를 암호화하십시오. configtxgen을 사용하는 경우 configtx.yaml을 편집하거나 시스템 채널의 genesis 블록에 대한 사전 설정된 프로필을 선택하십시오.

  • Orderer.OrdererTypekafka로 설정됩니다.
  • Orderer.Kafka.Brokers 에는 클러스터에있는 두 개 이상의 Kafka 중개자의 주소가 IP:port  notation에 들어 있습니다. 이 목록은 완전 할 필요는 없습니다. (이들은 귀하의 seed brokers입니다.)

2. 주문자 : 최대 블록 크기를 설정하십시오. 각 블록은 configtx.yaml에서 설정할 수있는 최대 바이트 수 (헤더 제외)입니다. 여기에서 선택한 값을 A로 지정하고 4 단계에서 Kafka 중개인을 구성하는 방법에 영향을줍니다.

3. 주문자 : 제네시스 블록을 만듭니다. configtxgen을 사용하십시오. 위의 1 단계와 2 단계에서 선택한 설정은 시스템 전체의 설정입니다. 즉, 모든 OSN에 대해 네트워크 전체에 적용됩니다. 제네시스 블록의 위치를 ​​기록하십시오.

4. Kafka cluster: 카프카 브로커를 적절하게 구성하십시오. 모든 카프카 중개인은 다음과 같은 키들을 구성해야합니다.

  • unclean.leader.election.enable = false – 데이터 일관성은 블록 체인 환경에서 핵심입니다. 동기화 된 복제 세트 외부에서 채널 리더를 선택할 수 없거나 이전 리더가 생성 한 오프셋을 덮어 쓸 위험이 있습니다. 결과적으로 주문자가 생산하는 블록 체인을 다시 작성합니다.
  • min.insync.replicas = M – 여기서 1 <M <N과 같은 값 M을 선택합니다 (아래 default.replication.factor 참조). 데이터는 최소한 M 개의 복제본에 기록 될 때 커밋 된 것으로 간주됩니다 (동기화 후 동기화로 간주되어 동기화 된 복제 세트 또는 ISR에 속함). 다른 경우, 쓰기 조작은 오류를 리턴합니다. 그때:
    • 채널 데이터가 기록되는 N 개 중 최대 N-M 개의 복제본을 사용할 수 없게되면 작업이 정상적으로 진행됩니다.
    • 더 많은 복제본을 사용할 수 없게되면 Kafka는 M의 ISR 집합을 유지할 수 없으므로 쓰기 허용을 중지합니다. 문제없이 작업을 읽습니다. 채널은 M개의 복제본이 동기화 될 때 다시 쓰기 가능하게됩니다.
  • default.replication.factor = N – 여기서 N <K 인 값 N을 선택합니다. N의 복제 인수는 각 채널의 데이터가 N개의 브로커에 복제됨을 의미합니다. 이들은 채널의 ISR 세트 후보입니다. 위의 min.insync.replicas section 에서 언급했듯이 모든 브로커가 항상 사용 가능해야하는 것은 아닙니다. N- 브로커가 N보다 적 으면 채널 제작을 진행할 수 없기 때문에 NK보다 작게 설정해야합니다. 따라서 N = K로 설정하면 단일 브로커가 중단된다는 것은 블록 체인 네트워크에 새로운 채널을 만들 수 없다는 것을 의미합니다. 주문 서비스의 오류 방지 기능은 존재하지 않습니다.
  • message.max.bytes 및 replica.fetch.max.bytes는 위의 2 단계에서 Orderer.AbsoluteMaxBytes에서 선택한 값보다 큰 값으로 설정해야합니다. 머리말을 설명 할 버퍼를 추가하십시오. 1 MiB가 충분합니다. 다음 조건이 적용됩니다. Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes
  • (완성을 위해 message.max.bytes는 기본적으로 100 MiB로 설정된 socket.request.max.bytes보다 작아야합니다. 100 MiB보다 큰 블록을 원한다면 하드를 편집해야합니다 abric/orderer/kafka/config.go에있는 brokerConfig.Producer.MaxMessageBytes의 값을 인코딩하고 소스에서 이진 파일을 다시 작성하십시오.
  • log.retention.ms = -1. Fabric의 주문 서비스에서 Kafka 로그의 가지 치기에 대한 지원이 추가 될 때까지는 시간 기반 보존을 비활성화하고 세그먼트가 만료되지 않도록해야합니다. (크기 기반 보존 - log.retention.bytes 참조 -이 글을 쓰고있는 시점의 Kafka에서는 기본적으로 사용 중지되어 있으므로 명시 적으로 설정할 필요가 없습니다.) 앞서 설명한 내용을 토대로 M과 N의 최소 허용 값은 각각 2와 3입니다. 이 구성은 앞으로 나아갈 새로운 채널을 생성하고 모든 채널이 계속 쓰기 가능하도록합니다.

5. 지시자 : 각 OSN을 제네시스 블록으로 향하게하십시오. orderer.yaml에서 General.GenesisFile을 편집하여 위의 3 단계에서 생성 된 기원 블록을 가리 키도록합니다. (그 동안 YAML 파일의 다른 모든 키가 적절하게 설정되었는지 확인하십시오.)


6. 주문자 : 폴링 간격 및 타임 아웃을 조정합니다. (선택 단계.)

  • orderer.yaml 파일의 Kafka.Retry 섹션을 사용하여 메타 데이터 / 제작자 / 고객 요청의 빈도와 소켓 시간 초과를 조정할 수 있습니다. (이들은 카프카 제작자 또는 소비자에게 기대되는 모든 설정입니다.)
  • 또한 새 채널을 만들거나 기존 채널을 다시로드하면 (순서가 다시 시작된 경우) 주문자는 다음과 같은 방법으로 Kafka 클러스터와 상호 작용합니다.
    • 채널에 해당하는 Kafka 파티션을위한 Kafka 제작자 (작성자)를 만듭니다.
    • 이 생성자는 해당 파티션에 no-op CONNECT 메시지를 게시합니다.
    • 해당 파티션에 대한 Kafka 소비자 (독자)를 만듭니다.


7. SSL을 통해 통신 할 수 있도록 OSN과 Kafka 클러스터를 설정하십시오. (옵션 단계이지만 권장 됨) 방정식의 Kafka 클러스터 측면에 대한 Confluent 가이드를 참조하고 그에 따라 모든 OSN의 orderer.yaml 에있는 Kafka.TLS 에서 키를 설정하십시오.


8. ZooKeeper 앙상블, Kafka 클러스터, 주문 서비스 노드 순서로 노드를 가져옵니다.

추가 고려 사항 ( Additional considerations )


1. 기본 메시지 크기. 위의 2 단계 (단계 섹션 참조)에서 Orderer.Batchsize.PreferredMaxBytes 키를 설정하여 원하는 블록 크기를 설정할 수도 있습니다. 상대적으로 작은 메시지를 처리 할 때 Kafka는 높은 처리량을 제공합니다. 1 MiB보다 크지 않은 값을 목표로 삼는다.


2. 환경 변수를 사용하여 설정을 무시합니다. 환경 변수를 사용하여 Kafka 브로커 또는 ZooKeeper 서버 설정을 무시할 수 있습니다. 구성 키의 점을 밑줄로 바꿉니다 (예 : KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false 를 지정하면 unclean.leader.election.enable의 기본값을 무시할 수 있습니다. 로컬 구성에 대한 OSN에도 동일하게 적용됩니다 (즉, orderer.yaml에서 설정할 수있는 항목). 예를 들어 ORDERER_KAFKA_RETRY_SHORTINTERVAL=1s을 사용하면 Orderer.Kafka.Retry.ShortInterval의 기본값을 무시할 수 있습니다.


지원되는 카프카 버전 및 업그레이드 ( Supported Kafka versions and upgrading )

Supported Kafka versions for v1 are 0.9 and 0.10. (Fabric uses the sarama client library and vendors a version of it that supports Kafka 0.9 and 0.10.)

v1에 대해 지원되는 카프카 버전은 0.9와 0.10입니다. Fabric은 sarama 클라이언트 라이브러리를 사용하고 공급 업체는 Kafka 0.9 및 0.10을 지원하는 버전을 사용합니다.

상자에서 Kafka 버전의 기본값은 0.9.0.1입니다. 지원되는 다른 버전을 사용하려면 소스 코드를 편집 (orderer / orderer/localconfig/config.go에서 defaults 구조체의 Version 필드 수정)하고 orderer 바이너리를 다시 빌드해야합니다. 예를 들어, 0.10.0.1을 실행하는 Kafka 클러스터에서 주문 서비스를 실행하려면 다음과 같이 파일을 편집하십시오.

...
Verbose: false,
Version: sarama.V0_10_0_1,
TLS: TLS{
...

그리고 바이너리를 다시 빌드하십시오. (이 과정은 FAB-4619로 개선 될 것입니다.)


디버깅 ( Debugging )

General.LogLevelDEBUG로 설정하고 orderer.yamlKafka.Verbosetrue로 설정합니다.


예시 ( Example )

샘플 도커 위의 권장 설정으로 인라인 구성 파일을 작성하려면 fabric/bddtests 디렉토리 아래에 있습니다. dc-orderer-kafka-base.yml와 dc-orderer-kafka.yml을 찾으십시오.


채널 ( Channels )

Hyperledger 패브릭 채널은 비공개 및 기밀 트랜잭션을 수행하기 위해 두 명 이상의 특정 네트워크 구성원 간의 통신에 대한 개인 "서브넷"입니다. 채널은 구성원 (조직), 구성원 당 앵커 피어, 공유 원장, 체인 코드 응용 프로그램 및 주문 서비스 노드 (들)에 의해 정의됩니다. 네트워크상의 각 트랜잭션은 채널에서 실행되며 각 당사자는 인증되고 해당 채널에서 거래 할 권한이 있어야합니다. 채널에 참여하는 각 피어는 구성원 서비스 공급자 (MSP)가 제공 한 자체 ID를 가지며 채널 피어 및 서비스에 대한 각 피어를 인증합니다.

새 채널을 만들려면 클라이언트 SDK가 구성 시스템 체인 코드를 호출하고 앵커 피어 ** 및 구성원 (조직)과 같은 속성을 참조합니다. 이 요청은 채널 정책, 구성원 및 앵커 피어에 대한 구성 정보를 저장하는 채널 원장에 대한 ** 창 블록을 만듭니다. 기존 채널에 새 구성원을 추가 할 때이 기원 블록 또는 적용 가능한 경우 최신 재구성 블록이 새 구성원과 공유됩니다.

노트 - 구성 트랜잭션의 등록 정보 및 프로토 구조에 대한 자세한 내용은 채널 구성 (configtx) 섹션을 참조하십시오.

채널의 각 구성원에 대한 선임 피어가 선출되면 피어가 구성원을 대신하여 주문 서비스와 통신하는지 결정합니다. 리더가 식별되지 않으면 알고리즘을 사용하여 리더를 식별 할 수 있습니다. 컨센서스 서비스는 거래를 명령하고이를 각 피어 (peer)에게 전달하며, 피어는 피어 투 피어 (peer)와 가십 프로토콜을 사용하여 채널을 통해 피어 투 피어에게 배포합니다.

하나의 앵커 피어가 여러 채널에 속할 수 있기 때문에 여러 원장을 유지할 수 있지만 원장 데이터는 한 채널에서 다른 채널로 전달할 수 없습니다. 이 원장 분리는 채널별로 구성 체인 코드, ID 멤버십 서비스 및 가십 데이터 보급 프로토콜에 의해 정의되고 구현됩니다. 장부 원장 및 채널 멤버십에 대한 정보가 포함 된 데이터의 보급은 해당 채널의 회원 자격이 검증 된 동료에게만 국한됩니다. 피어 및 원장 데이터를 채널별로 분리하면 사설 및 기밀 트랜잭션이 필요한 네트워크 구성원이 비즈니스 경쟁자 및 다른 제한된 회원과 동일한 블록 체인 네트워크에서 공존할 수 있습니다.


원장 ( Ledger )

원장은 패브릭의 모든 상태 전이에 대한 순차적 인 변조 방지 기록입니다. 상태 전이는 참여 당사자가 제출 한 체인 코드 호출 ( '트랜잭션')의 결과입니다. 각 트랜잭션은 생성, 업데이트 또는 삭제와 같이 원장에게 커밋되는 일련의 자산 키 - 값 쌍을 생성합니다.

원장은 불변의 시퀀스 된 레코드를 블록으로 저장하는 블록 체인 (chainchain)과 현재 패브릭 상태를 유지하는 상태 데이터베이스로 구성됩니다. 채널 당 1 개의 원장이 있습니다. 각 피어는 회원 인 각 채널에 대해 원장 사본을 보관합니다.


체인 ( Chain )

체인은 각 블록에 N 개의 트랜잭션 시퀀스가 들어있는 해시 - 링크 블록으로 구성된 트랜잭션 로그입니다. 블록 헤더에는 이전 블록의 헤더 해시뿐만 아니라 블록 트랜잭션의 해시도 포함됩니다. 이렇게하면 원장의 모든 트랜잭션이 순서가 지정되고 함께 암호로 링크됩니다. 즉, 해시 링크를 손상시키지 않고 원장 데이터를 무단으로 변경할 수 없습니다. 최신 블록의 해시는 이전에 온 모든 트랜잭션을 나타내므로 모든 피어가 일관되고 신뢰할 수있는 상태에 있음을 보장 할 수 있습니다.

체인은 피어 파일 시스템 (로컬 또는 연결된 스토리지)에 저장되어 효율적으로 블록 체인 작업 부하의 추가 전용 특성을 지원합니다.


상태 데이터베이스 ( State Database )

원장의 현재 상태 데이터는 체인 트랜잭션 로그에 포함 된 모든 키의 최신 값을 나타냅니다. 현재 상태는 채널에 알려진 모든 최신 키 값을 나타내므로 때로는 세계 상태라고합니다.

체인 코드 호출은 현재 상태 데이터에 대해 트랜잭션을 실행합니다. 이러한 체인 코드 상호 작용을 매우 효율적으로 만들기 위해 모든 키의 최신 값이 상태 데이터베이스에 저장됩니다. 상태 데이터베이스는 단순히 체인의 트랜잭션 로그에 대한 인덱싱 된 뷰이므로 언제든지 체인에서 다시 생성 할 수 있습니다. 상태 데이터베이스는 트랜잭션이 수락되기 전에 피어가 시작될 때 자동으로 복구됩니다 (또는 필요한 경우 생성됩니다).


거래 흐름 ( Transaction Flow )

높은 수준에서 트랜잭션 흐름은 응용 프로그램 클라이언트가 특정 승인하는 동료에게 보내는 트랜잭션 제안으로 구성됩니다. 인증 피어는 클라이언트 서명을 확인하고 체인 코드 기능을 실행하여 트랜잭션을 시뮬레이트합니다. 출력은 chaincode 결과, chaincode (읽기 세트)에서 읽은 키 / 값 버전 세트 및 chaincode (쓰기 세트)로 작성된 키 / 값 세트입니다. 제안서 응답은 보증 서명과 함께 고객에게 반송됩니다.

클라이언트는 보증서를 트랜잭션 페이로드로 어셈블하고 이를 주문 서비스에 브로드 캐스트합니다. 주문 서비스는 정렬 된 트랜잭션을 채널의 모든 피어에게 블록으로 전달합니다.

committal 전에 동료는 거래를 확인합니다. 첫째, 그들은 지정된 피어들의 정확한 할당이 결과에 서명했는지 확인하기 위해 보증 정책을 점검하고 트랜잭션 페이로드에 대해 서명을 인증합니다.

둘째, 동료는 데이터 무결성을 보장하고 이중 지출과 같은 위협으로부터 시스템을 보호하기 위해 트랜잭션 읽기 세트에 대한 버전 확인을 수행합니다. 패브릭은 처리량을 높이기 위해 트랜잭션을 병렬 처리 (endorser)하고 동시성 제어 (모든 피어가 모든 트랜잭션을 처리)를 수행하여 다른 트랜잭션이 읽은 데이터를 수정하지 않았는지 확인합니다. 즉, 체인 코드 실행 중에 읽은 데이터가 실행 (보증) 시간 이후 변경되지 않았으므로 실행 결과가 여전히 유효하며 원장 상태 데이터베이스에 커밋 될 수 있습니다. 읽은 데이터가 다른 트랜잭션에 의해 변경된 경우 블록의 트랜잭션은 유효하지 않은 것으로 표시되고 원장 상태 데이터베이스에 적용되지 않습니다. 클라이언트 응용 프로그램에 경고가 표시되고 오류를 처리하거나 적절하게 다시 시도 할 수 있습니다.

트랜잭션 구조, 동시성 제어 및 상태 DB에 대해 자세히 알아 보려면 트랜잭션 흐름읽기 - 쓰기 세트 의미 항목을 참조하십시오.


상태 데이터베이스 옵션 ( State Database options )

상태 데이터베이스 옵션에는 LevelDB 및 CouchDB (베타)가 포함됩니다. LevelDB는 피어 프로세스에 포함 된 기본 키 / 값 상태 데이터베이스입니다. CouchDB는 선택적 대체 외부 상태 데이터베이스입니다. LevelDB 키 / 값 저장소와 마찬가지로 CouchDB는 체인 코드로 모델링 된 모든 이진 데이터를 저장할 수 있습니다 (CouchDB 첨부 기능은 비 JSON 바이너리 데이터에 내부적으로 사용됩니다). 그러나 JSON 문서 저장소 인 CouchDB는 체인 코드 값 (예 : 에셋)을 JSON 데이터로 모델링 할 때 체인 코드 데이터에 대한 추가 쿼리를 추가적으로 지원합니다.

LevelDB 및 CouchDB는 키 가져 오기 및 설정 (자산)과 키 기반 쿼리와 같은 핵심 체인 코드 작업을 지원합니다. 키는 범위별로 쿼리 할 수 ​​있으며 복합 키는 여러 매개 변수에 대해 등가 쿼리를 사용할 수 있도록 모델링 할 수 있습니다. 예를 들어 (owner, asset_id)의 복합 키를 사용하여 특정 엔티티가 소유 한 모든 자산을 조회 할 수 있습니다. 이러한 키 기반 쿼리는 원장에 대한 읽기 전용 쿼리와 원장을 업데이트하는 트랜잭션에 사용할 수 있습니다.

애셋을 JSON으로 모델링하고 CouchDB를 사용하는 경우 체인 코드 내의 CouchDB JSON 쿼리 언어를 사용하여 체인 코드 데이터 값에 대해 복잡한 리치 쿼리를 수행 할 수도 있습니다. 이러한 유형의 쿼리는 원장의 내용을 이해하는 데 탁월합니다. 이러한 유형의 쿼리에 대한 제안 응답은 일반적으로 클라이언트 응용 프로그램에 유용하지만 일반적으로 주문 서비스에 대한 트랜잭션으로 제출되지는 않습니다. 실제로 패브릭은 결과 세트가 풍부한 쿼리의 경우 체인 코드 실행과 커밋 시간 사이에 안정적이라는 것을 보장하지 않으므로 응용 프로그램이 결과 집합이 체인 코드 실행 시간과 안정성을 보장 할 수없는 한 풍부한 쿼리가 업데이트 트랜잭션에 사용하기에 적합하지 않습니다. 커밋 시간, 또는 후속 트랜잭션의 잠재적 변경을 처리 할 수 ​​있습니다. 예를 들어, Alice가 소유 한 모든 자산에 대해 풍부한 쿼리를 수행하고이를 Bob으로 전송하는 경우 체인 코드 실행 시간과 커밋 시간 사이에 다른 트랜잭션으로 Alice에 새 자산을 할당 할 수 있습니다.이 '팬텀'항목을 놓치게됩니다.

CouchDB는 피어와 함께 별도의 데이터베이스 프로세스로 실행되므로 설정, 관리 및 작업과 관련하여 추가 고려 사항이 있습니다. 기본 임베디드 LevelDB로 시작하는 것을 고려해 볼 수 있으며 추가로 복잡한 리치 쿼리가 필요한 경우 CouchDB로 이동하십시오. 체인 코드 자산 데이터를 JSON으로 모델링하는 것이 좋습니다. 그러면 나중에 필요할 경우 복잡한 리치 쿼리를 수행 할 수 있습니다.

CouchDB를 상태 데이터베이스로 사용하려면 /fabric/sampleconfig/core.yaml stateDatabase 섹션을 구성하십시오.

읽기-쓰기 의미 설정 ( Read-Write set semantics )

이 문서는 읽기 - 쓰기 의미 설정에 관한 현재 구현의 세부 사항을 설명합니다.


트랜잭션 시뮬레이션 및 읽기 - 쓰기 설정 ( Transaction simulation and read-write set )

endorser에서 트랜잭션을 시뮬레이션하는 동안 트랜잭션에 대해 읽기 - 쓰기 세트가 준비됩니다. read set 에는 시뮬레이션 중에 트랜잭션이 읽는 고유 키 및 커밋 된 버전의 목록이 포함됩니다. write set에는 고유 키 목록 (읽기 세트에있는 키와 겹칠 수 있음)과 트랜잭션이 작성하는 새 값 목록이 포함됩니다. 트랜잭션에 의해 수행 업데이트가 키를 삭제할 경우 삭제 마커는 키 (새로운 값의 장소에) 설정되어 있습니다.

또한 트랜잭션이 키에 여러 번 값을 쓰는 경우 마지막으로 기록 된 값만 유지됩니다. 또한 트랜잭션이 키에 대한 값을 읽는 경우 트랜잭션이 읽기 전에 해당 값을 갱신하더라도 커밋 된 상태의 값이 반환됩니다. 즉, 읽기 - 쓰 기 의미론은 지원되지 않습니다.

앞에서 언급했듯이 키의 버전은 읽기 세트에만 기록됩니다. 쓰기 세트에는 고유 키 목록과 트랜잭션에 의해 설정된 최신 값이 포함됩니다.

버전을 구현하기위한 다양한 계획이있을 수 있습니다. 버전 관리 체계에 대한 최소한의 요구 사항은 주어진 키에 대해 반복되지 않는 식별자를 생성하는 것입니다. 예를 들어, 버전에 대해 단조롭게 증가하는 숫자를 사용하면 이러한 스키마 중 하나 일 수 있습니다. 현재 구현에서는 커밋 트랜잭션의 높이가 트랜잭션에 의해 수정 된 모든 키의 최신 버전으로 사용되는 블록 체인 높이 기반 버전 관리 체계를 사용합니다. 이 체계에서 트랜잭션의 높이는 튜플로 표시됩니다 (txNumber는 블록 내의 트랜잭션 높이입니다). 이 방법은 증분 번호 체계보다 많은 장점을 가지고 있습니다. 주로, 술어 b, 트랜잭션 시뮬레이션 및 유효성 검사와 같은 다른 구성 요소를 사용하여 효율적인 설계 선택을 할 수 있습니다.

다음은 가상 트랜잭션의 시뮬레이션으로 준비된 읽기 쓰기 세트의 예입니다. 단순화를 위해 그림에서 버전을 나타내는 데 필요한 증분 숫자를 사용합니다.

<TxReadWriteSet>
  <NsReadWriteSet name="chaincode1">
    <read-set>
      <read key="K1", version="1">
      <read key="K2", version="1">
    </read-set>
    <write-set>
      <write key="K1", value="V1"
      <write key="K3", value="V2"
      <write key="K4", isDelete="true"
    </write-set>
  </NsReadWriteSet>
<TxReadWriteSet>

또한 트랜잭션이 시뮬레이션 중에 범위 쿼리를 수행하면 범위 쿼리와 그 결과가  query-info로 읽기 / 쓰기 세트에 추가됩니다.


읽기 및 쓰기 설정을 사용하여 트랜잭션 유효성 검사 및 세계 상태 업데이트 ( Transaction validation and updating world state using read-write set )

committer는 읽기 쓰기 세트의 읽기 세트 부분을 사용하여 트랜잭션의 유효성을 확인하고 읽기 및 쓰기 세트의 쓰기 세트 부분을 검사하여 영향을받는 키의 버전 및 값을 업데이트합니다.

유효성 검사 단계에서 트랜잭션의 읽기 세트에 있는 각 키의 버전이 월드 상태의 동일한 키에 대한 버전과 일치 할 경우, 트랜잭션이 valid한 것으로 간주됩니다. 이전의 valid 모든 트랜잭션 (동일한 트랜잭션 블록)이 커밋 (커밋 - 상태)됩니다. 읽기 - 쓰기 세트에 하나 이상의 query-info도 포함되어 있으면 추가 검증이 수행됩니다.

이 추가 검증은 쿼리 정보에 캡처 된 결과의 수퍼 범위 (즉, 범위의 합집합)에 키가 삽입 / 삭제 / 업데이트되지 않았 음을 보장해야합니다. 즉, 커밋 된 상태의 유효성 검사 중에 범위 쿼리 (시뮬레이션 중에 수행 된 트랜잭션)를 다시 실행하면 시뮬레이션시 트랜잭션이 관찰 한 것과 동일한 결과가 나타납니다. 이 확인은 트랜잭션이 커밋 중에 팬텀 항목을 관찰하면 트랜잭션이 유효하지 않은 것으로 표시되어야 함을 보장합니다. 이 팬텀 보호는 범위 쿼리 (즉, 체인 코드의 GetStateByRange 함수)로 제한되며 다른 쿼리 (즉, 체인 코드의 GetQueryResult 함수)에는 아직 구현되지 않았습니다. 다른 쿼리는 유령의 위험이 있으므로 응용 프로그램이 시뮬레이션과 유효성 검사 / 커밋 시간 사이에 결과 집합의 안정성을 보장 할 수없는 경우 주문에 제출되지 않은 읽기 전용 트랜잭션에서만 사용해야합니다.

트랜잭션이 유효성 검사를 통과하면 커미터는 쓰기 상태를 사용하여 세계 상태를 업데이트합니다. 업데이트 단계에서 쓰기 세트에있는 각 키의 경우 동일한 키에 대한 월드 상태의 값이 쓰기 세트에 지정된 값으로 설정됩니다. 또한, 세계 상태의 키의 버전이 최신 버전을 반영하도록 변경됩니다.


시뮬레이션 및 검증의 예 ( Example simulation and validation )

이 절에서는 예제 시나리오를 통한 의미 이해에 도움이 됩니다. 이 예제의 목적을 위해, 세계 상태에서 키 k의 존재는 튜플 (k,ver,val)로 표현되며, 여기서 ver은 값을 val로 갖는 키 k의 최신 버전입니다.

이제 세계 상태의 동일한 스냅 샷에서 시뮬레이션 된 다섯 개의 트랜잭션 T1, T2, T3, T4, T5를 고려해보십시오. 다음 스 니펫은 트랜잭션이 시뮬레이션되는 세계 상태의 스냅 샷과 이러한 각 트랜잭션이 수행하는 읽기 및 쓰기 활동의 순서를 보여줍니다.

World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5)
T1 -> Write(k1, v1'), Write(k2, v2')
T2 -> Read(k1), Write(k3, v3')
T3 -> Write(k2, v2'')
T4 -> Write(k2, v2'''), read(k2)
T5 -> Write(k6, v6'), read(k5)

이제 이러한 트랜잭션이 T1, .., T5 순서로 정렬되어 있다고 가정합니다 (단일 블록 또는 다른 블록에 포함될 수 있음)

  1. T1은 읽기를 수행하지 않기 때문에 유효성 검사를 통과합니다. 또한, 월드 상태의 키 k1과 k2 의 튜플은 (k1,2,v1'), (k2,2,v2')로 업데이트된다.
  2. T2는 선행 트랜잭션(T1)에 의해 수정 된 키 k1을 읽음으로써 검증에 실패합니다.
  3. T3 passes the validation because it does not perform a read. Further the tuple of the key, k2, in the world state is updated to (k2,3,v2'')
  4. T3는 읽기를 수행하지 않기 때문에 유효성 검사를 통과합니다.  또한 키의 튜플은, k2는 세계 상태 (k2,3,v2'')에 업데이트됩니다.
  5. 이전 트랜잭션T1에 의해 수정 된 키 k2를 읽으므로 T4가 유효성 검사에 실패합니다.
  6. T5 passes validation because it reads a key, k5, which was not modified by any of the preceding transactions
  7. T5는 이전 트랜잭션 중 하나에서 수정되지 않은 키 k5를 읽으므로 유효성 검사를 통과합니다.

노트 : 다중 읽기 - 쓰기 세트가 있는 트랜잭션은 아직 지원되지 않습니다.


가십 데이터 보급 프로토콜 ( Gossip data dissemination protocol )

Hyperledger 패브릭은 트랜잭션 실행 (보증 및 커밋) 피어 및 트랜잭션 주문 노드에서 작업 부하를 나누어 블록 체인 네트워크 성능, 보안 및 확장 성을 최적화합니다. 이러한 네트워크 운영의 분리는 데이터 무결성 및 일관성을 보장하기 위해 안전하고 신뢰할 수 있으며 확장 가능한 데이터 보급 프로토콜을 필요로합니다. 이러한 요구 사항을 충족하기 위해 패브릭은 gossip data dissemination protocol을 구현합니다.


가십 프로토콜 ( Gossip protocol )

피어들은 가저를 활용하여 원장과 채널 데이터를 확장 가능한 방식으로 방송합니다. 가십 메시지는 계속되고 채널의 각 피어는 여러 피어로부터 현재의 일관된 원장 데이터를 지속적으로 수신합니다. 각각의 험담 메시지에 서명함으로써 위조 된 메시지를 보내는 비잔틴 참가자가 쉽게 식별되고 원치 않는 목표에 대한 메시지 배포를 막을 수 있습니다. 지연, 네트워크 파티션 또는 블록 손실로 인한 다른 원인에 영향을받는 피어는 이러한 누락 된 블록을 소유 한 피어에게 연락하여 현재 원장 상태로 동기화됩니다.

가십 기반의 데이터 보급 프로토콜은 패브릭 네트워크에서 세 가지 기본 기능을 수행합니다.

  1. 사용 가능한 구성원 피어를 계속 식별하고 결국 오프라인이 된 피어를 감지하여 피어 검색 및 채널 구성원을 관리합니다.
  2. 채널의 모든 피어에 대해 원장 데이터를 보급합니다. 나머지 채널과 동기화되지 않은 데이터가있는 피어는 누락 된 블록을 식별하고 올바른 데이터를 복사하여 동기화합니다.
  3. 원장 데이터의 피어 - 투 - 피어 상태 전송 업데이트를 허용하여 새로 연결된 피어를 최대 속도로 가져옵니다.

험담 기반 방송은 다른 피어로부터 채널의 메시지를 수신 한 피어가 작동 한 다음이 메시지를 채널의 무작위로 선택된 다수 피어로 전달합니다.이 숫자는 구성 가능한 상수입니다. 동료는 메시지 전달을 기다리는 대신 끌어 오기 메커니즘을 사용할 수도 있습니다. 이주기가 반복되어 채널 멤버십의 결과로 원장과 상태 정보가 지속적으로 최신 상태로 유지됩니다. 새로운 블록을 보급하기 위해 채널의 리더 피어는 주문 서비스의 데이터를 가져와 동료에게 험담을 퍼뜨립니다.


가십 메시지 ( Gossip messaging )

온라인 피어는 PKI (공개 키 인프라) ID와 보낸 사람의 메시지 서명이 포함 된 "활성"메시지를 지속적으로 브로드 캐스팅함으로써 가용성을 나타냅니다. 피어는 이러한 살아있는 메시지를 수집하여 채널 멤버쉽을 유지합니다. 피어가 특정 피어로부터 살아있는 메시지를 수신하지 않으면이 "죽은"피어는 결국 채널 멤버쉽에서 제거됩니다. "살아있는"메시지는 암호로 서명되기 때문에 악의적 인 피어는 루트 인증 기관 (CA)이 승인 한 서명 키가 없으므로 절대로 다른 피어를 사칭 할 수 없습니다.

수신 된 메시지의 자동 전달 외에도 상태 조정 프로세스는 각 채널의 피어간에 세계 상태를 동기화합니다. 각 피어는 불일치가 확인되면 자체 상태를 복구하기 위해 채널의 다른 피어에서 계속 블록을 가져옵니다. 가십 거리의 데이터 보급을 유지하기 위해 고정 연결이 필요하지 않기 때문에이 프로세스는 노드 충돌에 대한 내구성을 포함하여 공유 원장에 데이터 일관성 및 무결성을 안정적으로 제공합니다.

채널이 분리되어 있기 때문에 한 채널의 피어는 다른 채널에서 정보를 보내거나 공유 할 수 없습니다. 모든 피어가 다중 채널에 속할 수 있지만 분할 메시징은 피어의 채널 구독을 기반으로 메시지 라우팅 정책을 적용하여 채널에없는 피어로 블록이 전파되는 것을 방지합니다.

노트: 1. 지점 간 메시지 보안은 피어 TLS 계층에서 처리하며 서명이 필요하지 않습니다. 피어는 CA에서 할당 한 인증서로 인증됩니다. TLS 인증서도 사용되지만 가십 계층에서 인증 된 것은 피어 인증서입니다. 원장 블록은 주문 서비스에 의해 서명 된 다음 채널의 리더 피어에게 전달됩니다. 2. 인증은 피어에 대한 멤버쉽 서비스 공급자의 관리를받습니다. 피어가 처음으로 채널에 연결되면 TLS 세션이 패브릭 멤버쉽 ID와 바인딩됩니다. 이는 본질적으로 네트워크와 채널의 회원 자격과 관련하여 연결 피어에 대한 각 피어를 인증합니다.

문제 해결 및 FAQ ( TROUBLESHOOTING AND FAQS )

하이퍼레저패브릭 자주 묻는 질문 ( Hyperledger Fabric FAQs )

보증 ( Endorsement )

보증 아키텍쳐 ( Endorsement architecture )

  • Q. 네트워크에서 얼마나 많은 동료가 트랜잭션을 승인해야합니까?
  • A. 트랜잭션을 보증하는 데 필요한 피어의 수는 체인 코드 배포 시간에 지정된 보증 정책에 의해 결정됩니다.
  • Q. 애플리케이션 클라이언트가 모든 피어에 연결해야합니까?
  • A. 클라이언트는 체인 코드에 대한 보증 정책에서 요구하는만큼 많은 피어에 연결하면됩니다.

보안 및 액세스 제어 ( Security & Access Control )

데이터 개인 정보 보호 및 액세스 제어 ( Data Privacy and Access Control )

  • Q. 데이터 프라이버시를 어떻게 보장합니까?
  • A. 데이터 프라이버시에는 다양한 측면이 있습니다. 먼저 네트워크를 채널로 분리 할 수 ​​있습니다. 여기서 각 채널은 해당 채널에 배포 된 체인 코드의 데이터를 볼 수있는 참가자의 하위 집합을 나타냅니다. 둘째, 채널 내에서 가시성 설정을 사용하여 입력 데이터를 체인 코드로 제한하고 엔도 서 세트로만 제한 할 수 있습니다. 가시성 설정은 출력 데이터와 비교하여 입력 및 출력 체인 코드 데이터가 제출 된 트랜잭션에 포함되는지 여부를 결정합니다. 셋째, chaincode를 호출하기 전에 데이터를 해시하거나 암호화 할 수 있습니다. 데이터를 해시하면 원본 데이터를 패브릭 외부에서 공유 할 수있는 방법이 필요합니다. 데이터를 암호화하는 경우 패브릭 외부에서 암호 해독 키를 공유 할 방법이 필요합니다. 넷째, 체인 코드 논리에 대한 액세스 제어를 구축하여 조직의 특정 역할에 대한 데이터 액세스를 제한 할 수 있습니다. 다섯째, 나머지 원장 데이터는 피어의 파일 시스템 암호화를 통해 암호화 될 수 있으며 전송중인 데이터는 TLS를 통해 암호화됩니다.
  • Q.주문자가 거래 데이터를 볼 수 있습니까?
  • A. 아니, 주문자는 거래만 주문하며 거래를 하지 않습니다. 데이터가 순서 지정자를 거치지 않고 입력 데이터에 대해서만 염려하는 경우 가시성 설정을 사용할 수 있습니다. 가시성 설정은 출력 데이터와 비교하여 입력 및 출력 체인 코드 데이터가 제출 된 트랜잭션에 포함되는지 여부를 결정합니다. 따라서 입력 데이터는 엔도서만 전용으로 사용할 수 있습니다. 주문자가 chaincode 출력을 보지 못하도록하려면 chaincode를 호출하기 전에 데이터를 해시하거나 암호화 할 수 있습니다. 데이터를 해시하면 원본 데이터를 패브릭 외부에서 공유 할 수있는 방법이 필요합니다. 데이터를 암호화하는 경우 패브릭 외부에서 암호 해독 키를 공유 할 방법이 필요합니다.

응용 프로그램 부분 프로그래밍 모델 ( Application-side Programming Model )

트랜잭션 실행 결과 ( Transaction execution result )

  • Q. 애플리케이션 클라이언트는 트랜잭션의 결과를 어떻게 알 수 있습니까?
  • A. 거래 시뮬레이션 결과는 제안서 응답에서 보증인이 고객에게 반환합니다. 여러 명의 엔도 서가있는 경우 클라이언트는 응답이 모두 동일한 지 확인하고 주문 및 약정에 대한 결과 및 보증을 제출할 수 있습니다. 궁극적으로 커밋하는 동료는 트랜잭션을 확인하거나 무효화하고 클라이언트는 SDK를 통해 응용 프로그램 클라이언트가 사용할 수있게하는 이벤트를 통해 결과를 알게됩니다.

원장 쿼리 ( Ledger queries )

  • Q. 원장 데이터는 어떻게 조회합니까?
  • A. chaincode 내에서 키를 기반으로 쿼리 할 수 있습니다. 키는 범위별로 쿼리 할 수 있으며 복합 키는 여러 매개 변수에 대해 등가 쿼리를 사용할 수 있도록 모델링 할 수 있습니다. 예를 들어 (owner, asset_id)의 복합 키를 사용하여 특정 엔티티가 소유 한 모든 자산을 조회 할 수 있습니다. 이러한 키 기반 쿼리는 원장에 대한 읽기 전용 쿼리와 원장을 업데이트하는 트랜잭션에 사용할 수 있습니다. 자산 데이터를 체인 코드의 JSON으로 모델링하고 CouchDB를 상태 데이터베이스로 사용하는 경우 chaincode 내의 CouchDB JSON 쿼리 언어를 사용하여 체인 코드 데이터 값에 대해 복잡한 리치 쿼리를 수행 할 수도 있습니다. 응용 프로그램 클라이언트는 읽기 전용 조회를 수행 할 수 있지만 일반적으로 이러한 응답은 거래의 일부로 주문 서비스에 제출되지 않습니다.
  • Q. 내역 데이터를 쿼리하여 데이터 출처를 이해하려면 어떻게해야합니까?
  • A. 체인 코드 API GetHistoryForKey()는 키의 값 기록을 반환합니다.
  • Q. 쿼리 된 피어가 복구되고 블록 처리를 따라 잡을 때 특히 쿼리 결과가 올바른지 보장하는 방법은 어떻게 해야하나요?
  • A. 클라이언트는 여러 피어를 쿼리하고, 블록 높이를 비교하고, 쿼리 결과를 비교하고, 높은 블록 높이에서 피어를 선호 할 수 있습니다.

체인 코드 (스마트 계약 및 디지털 자산) ( Chaincode (Smart Contracts and Digital Assets) )

  • 패브릭 구현이 현명한 계약 논리를 지원합니까? 네. 체인 코드는 추가 기능이있는 스마트 계약 방식 / 알고리즘에 대한 패브릭의 해석입니다. 체인 코드는 네트워크에서 배포 된 프로그래밍 방식의 코드로, 컨센서스 프로세스 중에 함께 체인 유효성 검사기에 의해 실행되고 유효성이 검사됩니다. 개발자는 체인 코드를 사용하여 비즈니스 계약, 자산 정의 및 공동 관리되는 분산 된 응용 프로그램을 개발할 수 있습니다.
  • 패브릭을 사용하여 비즈니스 계약을 작성하려면 어떻게합니까? 일반적으로 비즈니스 계약을 개발하는 두 가지 방법이 있습니다. 첫 번째 방법은 개별 계약을 독립 실행 형 체인 코드 인스턴스로 코딩하는 것입니다. 두 번째 방법, 그리고 아마도보다 효율적인 방법은 하나 또는 여러 유형의 비즈니스 계약의 수명주기를 관리하는 분산 응용 프로그램을 만드는 데 chaincode를 사용하고 최종 사용자가 이러한 응용 프로그램 내에서 계약 인스턴스를 인스턴스화 할 수있게하는 것입니다.
  • 패브릭을 사용하여 자산을 어떻게 만들 수 있습니까? 사용자는 비즈니스 규칙 용 체인 코드와 디지털 토큰 용 멤버십 서비스를 사용하여 자산을 관리하는 논리뿐만 아니라 자산을 설계 할 수 있습니다. 대부분의 블록 체인 솔루션에서 자산을 정의하는 데는 두 가지 방법이 일반적입니다. 즉, 계정 잔액이 과거 트랜잭션 레코드로 인코딩되는 상태 비 저장 UTXO 모델입니다. 계정 잔액은 원장의 상태 저장 공간에 보관되는 계정 모델입니다. 각 접근법에는 각각 장점과 단점이 있습니다. 이 블록 체인 패브릭은 어느 한 쪽을 다른쪽에 옹호하지 않습니다. 대신 첫 번째 요구 사항 중 하나는 패브릭에서 사용할 수있는 도구를 사용하여 두 가지 방법 모두를 쉽게 구현할 수 있도록하는 것이 었습니다.
  • 체인 코드 작성을 위해 지원되는 언어는 무엇입니까? 체인 코드는 모든 프로그래밍 언어로 작성되고 패브릭 컨텍스트 계층 내부의 컨테이너에서 실행될 수 있습니다. 우리는 또한 체인 코드로 컴파일되거나 인터프리터를 체인 코드 컨테이너에 내장 할 수있는 템플리트 언어 (Apache Velocity와 같은)를 개발하려고합니다. 패브릭의 최초로 완벽하게 지원되는 체인 코드 언어는 Golang이며 2016 년에는 JavaScript 및 Java에 대한 지원이 계획되어 있습니다. 추가 언어에 대한 지원과 패브릭 관련 템플릿 언어 개발에 대한 논의가 있었으며 가까운 시일 내에 자세한 내용이 발표 될 예정입니다. * 페브릭에 원화가 있습니까? 아닙니다. 그러나 체인 네트워크에 고유 통화가 실제로 필요한 경우 체인 코드로 고유 통화를 개발할 수 있습니다. 기본 통화의 공통 속성 중 하나는 거래가 체인에서 처리 될 때마다 일정 금액이 거래가 발생한다는 것입니다 (해당 통화를 정의하는 체인 코드가 호출 됨).


기여 ( CONTRIBUTING )

기여를 환영합니다( Contributions Welcome! )

우리는 Hyperledger 프로젝트에 대한 여러 가지 기부를 환영하며 언제나 할 일이 많습니다! 먼저 참여하기 전에 Hyperledger 프로젝트의 행동 강령을 검토하십시오. 우리가 일을 민사 소중히하는 것이 중요합니다.


필수 구성요소 설치 ( Install prerequisites )

시작하기 전에 아직 수행하지 않은 경우, 블록 체인 응용 프로그램을 개발하거나 Hyperledger Fabric을 운영 할 플랫폼에 모든 필수 구성 요소가 설치되어 있는지 확인하고 싶을 수 있습니다.


Linux Foundation 계정 얻기 ( Getting a Linux Foundation account )

Hyperledger Fabric 프로젝트의 개발에 참여하려면 Linux Foundation 계정이 필요합니다. Gerrit, Jira 및 Wiki를 포함한 모든 Hyperledger 커뮤니티 개발 도구에 액세스하려면 LF ID를 사용해야합니다 (편집 전용).


SSH 키 설정하기 ( Setting up your SSH key )

Gerrit의 경우 검토를 위해 변경 세트를 제출하기 전에 공개 SSH 키를 등록해야합니다. LFID로 Gerrit에 로그인하고 브라우저 창의 오른쪽 상단에있는 이름을 클릭 한 다음 '설정'을 클릭하십시오. 왼쪽 여백에는 'SSH Public Keys'에 대한 링크가 표시됩니다. 공개 SSH 키를 복사하여 붙여 넣기하고 '추가'를 누르십시오.


도움 받기 ( Getting help )

작업 할 무언가를 찾고 있거나 문제를 디버깅하거나 문제 해결을 위해 전문가의 도움이 필요하다면 커뮤니티는 항상 도움을 청합니다. 우리는 채팅, IRC (freenode.net의 #hyperledger) 및 메일 링리스트에서 행 아웃을합니다. 우리 대부분은 물지 않습니다. 미소를 지으면 도움이 될 것입니다. 바보 같은 질문은 당신이 묻지 않는 질문입니다. 실제로 질문은 프로젝트를 개선하는 데 도움이되는 훌륭한 방법입니다.


요구사항 및 사용 사례 ( Requirements and Use Cases )

We have a Requirements WG that is documenting use cases and from those use cases deriving requirements. If you are interested in contributing to this effort, please feel free to join the discussion in chat.


버그 보고 ( Reporting bugs)

사용자이고 버그를 발견하면 JIRA를 사용하여 문제를 제출하십시오. 문제를 재현하기 위해 다른 사람에게 충분한 정보를 제공하십시오. 프로젝트 관리자 중 한 명이 24 시간 내에 문제에 응답해야합니다. 그렇지 않은 경우 댓글에 문제를 표시하고 검토를 요청하십시오. 채팅에서 # fabric-maintainers 채널에 게시 할 수도 있습니다.


문제 해결 및 실무 사례 ( Fixing issues and working stories )

문제점 목록을 검토하고 관심있는 것을 찾으십시오. "도움이 필요한"목록을 확인할 수도 있습니다. 상대적으로 솔직하고 성취 가능한 것으로부터 시작하는 것이 현명하며, 아무도 이미 배정되지는 않았습니다. 아무도 할당되지 않은 경우 문제를 자신에게 할당하십시오. 합리적인 시간에 끝내지 못하면 배정을 철저히하거나 철회하거나 조금 더 시간이 필요할 경우 적극적으로 문제를 해결하고 있다고 말하는 의견을 추가하십시오.


기능 / 향상 제안 만들기 ( Making Feature/Enhancement Proposals )

JIRA를 검토하십시오. 동일한 기능에 대해 아직 공개되지 않은 (또는 최근에 닫힌) 제안이 없는지 확인하십시오. JIRA Epic, Story, Improvement 중 가장 적합한 것으로 보이는 쪽을 열어서 기능이 무엇을 할 것인지를 명시한 제안서의 "한 페이저"를 링크하거나 인라인 할 것을 제안합니다. 가능한 경우 구현 방법을 설명합니다. 기능이 필요한 특정 유스 케이스 (들)을 식별하는 것과 같은 기능을 추가해야하는 이유와 기능을 구현할 때 어떤 이점이 있는지에 대한 사례를 작성하는 것도 도움이 될 것입니다. JIRA 이슈가 생성되고 "하나의 호출기"가 첨부되거나, 설명 필드에 인라인되거나, 공개적으로 액세스 가능한 문서에 대한 링크가 설명에 추가되면, hyperledger-fabric@lists.hyperledger로 소개 이메일을 보냅니다. JIRA 이슈를 링크하는 org 메일 링리스트, 그리고 피드백 요청하기.

제안 된 기능에 대한 토론은 JIRA 이슈 자체에서 수행되어야합니다. 그래서 우리는 디자인 토론을 어디서 찾을 수 있는지에 대해 지역 사회 내에서 일관된 패턴을 유지해야합니다.

새로운 기능에 대해 세 명 이상의 Fabric 관리자가 지원을 받으면 기능의 관련 CR이 병합 될 가능성이 크게 높아집니다.


로컬 clone 및 Gerrit 작업 ( Working with a local clone and Gerrit )

우리는 코드 기여를 관리하기 위해 Gerrit를 사용하고 있습니다. 익숙하지 않은 경우 계속하기 전에이 문서를 검토하십시오.

Gerrit에 익숙해지고 lf-sandbox 프로젝트로 놀아 봤다면 로컬 개발 환경을 설정할 준비가되었습니다.

그런 다음 로컬 개발 환경에서 프로젝트를 빌드하여 모든 것이 올바르게 설정되었는지 확인하십시오.

로깅 제어 문서에서는 Fabric 내의 다양한 구성 요소의 로깅 수준을 조정하는 방법에 대해 설명합니다. 마지막으로 모든 소스 파일에는 라이센스 헤더가 포함되어야합니다. 원칙 작성자의 저작권 선언문을 포함하도록 수정되었습니다.


좋은 변경 요청은 무엇입니까? ( What makes a good change request? )

  • 한 번에 하나씩 변경하십시오. 5가 아니라 3이 아니라 10이 아닙니다. 오직 하나뿐입니다. 왜? 변화의 폭발 영역을 제한하기 때문입니다. 회귀 분석을 통해 더 많은 코드에 영향을 미치는 복합 변경이있는 경우보다 범인 커밋을 식별하는 것이 훨씬 쉽습니다.
  • 변경 사항에 대한 JIRA 이야기에 대한 링크를 포함하십시오. 왜? 왜냐하면 a) 우리는 우리가 전달할 수 있다고 생각하는 것을 더 잘 판단하기 위해 속도를 추적하기를 원하기 때문입니다. 왜냐하면 우리는 변화를보다 효과적으로 정당화 할 수 있기 때문입니다. 많은 경우 제안 된 변경 사항에 대해 몇 가지 논의가 있어야하며 변경 자체의 문제와 다시 연결하려고합니다.
  • 모든 변경 사항에 대해 단위 테스트 및 통합 테스트 (또는 기존 테스트 변경)를 포함하십시오. 이것은 단지 행복한 경로 테스트 중 하나를 의미하지 않습니다. 또한 모든 방어 코드의 부정 테스트를 통해 입력 오류를 정확하게 잡아낼 수 있음을 의미합니다. 코드를 작성할 때 코드를 테스트하고 변경 내용이 주장하는 바를 증명하는 테스트를 제공해야합니다. 왜? 왜냐하면 이것 없이는 현재 코드베이스가 실제로 작동하는지 아무런 단서도 없기 때문입니다.
  • 단위 테스트에는 외부 종속성이 없어야합니다. 언어에 대한 테스트 또는 동등한 테스트를 통해 단위 테스트를 실행할 수 있어야합니다. 외부 의존성이 필요한 테스트 (예 : 다른 구성 요소를 실행하기 위해 스크립팅해야 함)에는 적절한 조롱이 필요합니다. 다른 것은 단위 테스트가 아니며 정의에 의한 통합 테스트입니다. 왜? 많은 오픈 소스 개발자가 테스트 주도 개발을하기 때문에. 그들은 코드가 변경되면 자동으로 테스트를 호출하는 디렉토리에 시계를 배치합니다. 이것은 코드 변경 사이에 전체 빌드를 실행하는 것보다 훨씬 효율적입니다. 효과적인 단위 테스트를 작성하는 데 유의해야 할 좋은 기준 집합에 대해서는 단위 테스트의 정의를 참조하십시오.
  • CR 당 코드 줄을 최소화하십시오. 왜? 관리자는 낮에도 일할 수 있습니다. 1,000 또는 2,000 개의 LOC 변경을 보내면 해당 코드를 모두 검토하는 데 얼마나 걸릴 것으로 생각하십니까? 가능한 경우 <200-300 LOC로 변경하십시오. 더 큰 변화가 있다면, 그것을 여러 독립적 인 변화로 분해하십시오. 새로운 기능의 요구 사항을 충족시키기 위해 새로운 기능을 추가하는 경우 테스트와 함께 별도로 추가 한 다음이를 사용하여 기능을 제공하는 코드를 작성하십시오. 물론 항상 예외가 있습니다. 작은 변화를 추가하고 300 LOC 테스트를 추가하면 광범위한 영향을 미치는 변경이나 생성 된 코드 묶음 (protobufs 등)을 변경해야하는 경우 용서받을 수 있습니다. 다시 예외가있을 수 있습니다.
  • 참고 : 큰 변경 요청 (예 : 300 명이 넘는 LOC가있는 사람들은 -2를받지 못하는 것보다 더 가능성이 높습니다.이 지침에 따라 변경 사항을 리팩터링하라는 메시지가 나타납니다.
  • 관련이없는 한 변경 요청을 쌓아서는 안됩니다 (예 : 이전 CR과 동일한 지점에서 CR 제출). 이렇게하면 병합 충돌을 최소화하고 변경 내용을 더 빨리 병합 할 수 있습니다. 요청을 스택하면 이전 요구의 검토 주석으로 인해 후속 요청이 보류 될 수 있습니다.
  • 의미있는 커밋 메시지를 작성하십시오. 의미있는 50 자 (또는 그 이하)의 문자 제목과 빈 줄을 추가하고 변경 사항에 대한보다 포괄적 인 설명을 추가하십시오. 각 변경 사항에는 변경 사항에 해당하는 JIRA 식별자가 포함되어야합니다 (예 : [FAB-1234]). 이것은 제목에있을 수 있지만 커밋 메시지의 본문에 있어야합니다. Gerrit는 자동으로 JIRA 항목에 대한 하이퍼 링크를 생성합니다.

e.g.

[FAB-1234] fix foobar() panic

Fix [FAB-1234] added a check to ensure that when foobar(foo string) is called,
that there is a non-empty string argument.

마지막으로, 응답하십시오. Rebase가 필요한 시점에 검토 주석이 포함 된 변경 요청을 fester에 보내지 마십시오. 병합을 가져 오는 데 더 많은 시간이 걸리고 병합 충돌을 수정하기 위해 더 많은 작업이 추가됩니다.


통신 ( Communication )

Google은 통신을 위해 RocketChat을 사용하고 개발자 간의 화면 공유를 위해 Google 행 아웃 ™을 사용합니다. 우리의 개발 계획과 우선 순위 결정은 JIRA에서 이루어지며, 우리는 더 긴 실행 토론 / 결정을 메일 링리스트로 가져갑니다.


유지 관리자 ( Maintainers )

프로젝트의 유지 관리자는 검토를 위해 제출 된 모든 패치를 검토 및 병합해야하며 Hyperledger 프로젝트의 기술 운영위원회 (TSC)에서 제정 한 지침에 따라 프로젝트의 전반적인 기술적 방향을 안내합니다.


유지 관리자 되기 ( Becoming a maintainer )

이 프로젝트는 우리 헌장에 설명 된 바와 같이 개방형 거버넌스 모델에 따라 관리됩니다. 프로젝트 또는 하위 프로젝트는 유지 보수 담당자에 의해 주도됩니다. 새 하위 프로젝트는 프로젝트가 처음 승인 될 때 최상위 프로젝트의 기존 유지 보수자가 승인 할 초기 관리자 세트를 지정할 수 있습니다. 프로젝트의 관리자는 가끔씩 관리자를 추가하거나 제거하는 것을 고려할 것입니다. 기존 관리자는 MAINTAINERS.rst 파일에 변경 집합을 제출할 수 있습니다. 관리자가 8 명 미만인 경우 해당 프로젝트의 기존 유지 관리자 대다수가 변경 세트를 병합해야합니다. 기존의 관리자가 8 명 이상인 경우, 5 명 이상의 관리자가 제안서에 동의하면 변경 세트가 병합되고 관리자는 관리자 그룹에 추가됩니다 (또는 대안으로 제거됩니다). 명백한 사임, 행동 규범의 일부 위반 또는 일관성없는 가난한 판단의 시연.

참고 : 각 소스 파일에는 Apache Software License 2.0에 대한 라이센스 헤더가 있어야합니다. 라이센스 헤더의 템플릿을 참조하십시오.

우리는 가능한 한 쉽게 기부하도록 노력했습니다. 이는 기여의 법적 측면을 어떻게 처리하는지에 적용됩니다. 우리는 Linux® Kernel 커뮤니티가 코드 기여를 관리하는 데 사용하는 개발자 기원 1.1 (DCO)과 동일한 접근 방식을 사용합니다.

검토를 위해 패치를 제출할 때 개발자는 커밋 메시지에 사인 오프 문을 포함시켜야합니다.

다음은 제출자가 DCO를 승인한다는 것을 나타내는 Signed-by-by 회선의 예입니다.

Signed-off-by: John Doe <john.doe@hisdomain.com>

git commit -s를 사용하는 저장소.-s


유지 관리자 ( Maintainers )

Name Gerrit GitHub RocketChat email
Artem Barger c0rwin c0rwin c0rwin [[1]]
Binh Nguyen binhn binhn binhn [[2]]
Chris Ferris ChristopherFerris christo4ferris cbf [[3]]
Dave Enyeart denyeart denyeart dave.enyeart [[4]]
Gabor Hosszu hgabre gabre hgabor [[5]]
Gari Singh mastersingh24 mastersingh24 garisingh [[6]]
Greg Haskins greg.haskins ghaskins ghaskins [[7]]
Jason Yellick jyellick jyellick jyellick [[8]]
Jim Zhang jimthematrix jimthematrix jzhang [the matrix@hotmail.com|jim_the_matrix@hotmail.com]
Jonathan Levi JonathanLevi JonathanLevi JonathanLevi [[9]]
Keith Smith smithbk smithbk smithbk [[10]]
Kostas Christidis kchristidis kchristidis kostas [[11]]
Manish Sethi manish-sethi manish-sethi manish-sethi [[12]]
Sheehan Anderson sheehan srderson sheehan [[13]]
Srinivasan Muralidharan muralisr muralisrini muralisr [[14]]
Tamas Blummer TamasBlummer tamasblummer tamas [[15]]
Yacov Manevich yacovm yacovm yacovm [[16]]
Yaoguo Jiang jiangyaoguo jiangyaoguo jiangyaoguo [[17]]


Jira를 사용하여 현재 작업 항목 이해하기 ( Using Jira to understand current work items )

이 문서는 커뮤니티 로드맵을 기반으로하는 초소형 건물 / 패브릭 v1 아키텍처에 대한 진행중인 작업에 대한 자세한 정보를 제공하기 위해 작성되었습니다. 로드맵에 대한 요구 사항은 Jira에서 추적 중입니다.

접수 된 피드백에 따라 구현 될 항목의 우선 순위를보다 잘 추적하고 보여주기 위해 전력 질주를 조직하기로 결정했습니다. 우리는 보드를 통해이 작업을 수행했습니다. 이 보드와 우선 순위를 보려면 보드 -> 보드 관리를 클릭하십시오.

지라 판

이제 화면 왼쪽에서 모든 보드를 클릭하십시오 :

Jira boards

이 페이지에는 공개 된 모든 게시판이 표시됩니다. 현재 스프린트 포커스가있는 항목을 보려면 Visibility가 All Users 인 열과 Board type 열이 Scrum으로 표시된 보드를 클릭하십시오. 예를 들어 이사회 이름 합의 :

게시판 이름에서 Consensus를 클릭하면 다음 열이 포함 된 페이지로 이동합니다.

이 열의 의미는 다음과 같습니다.

백 로그 - 현재 스프린트로 예정된 항목 목록 (스프린트는 2 주 반복으로 정의 됨), 현재 진행되지는 않음

진행 중 - 현재 커뮤니티의 누군가가 작업하고있는 항목입니다.

검토 중 - Gerritt에서 검토 및 병합 대기 중

완료 - 스프린트에서 병합 및 완료.

특정 기능 세트에 대한 백 로그의 모든 항목을 보려면 화면의 왼쪽 탐색에서 스택 된 행을 클릭하십시오.

여기에는 상단의 현재 스프린트에 대한 항목과 맨 아래에있는 백 로그의 모든 항목이 표시됩니다. 항목은 우선 순위에 따라 나열됩니다.

작업에 관심이있는 항목이 있거나 더 많은 정보를 원하거나 질문이 있거나 우선 순위가 높은 항목이있는 경우 Jira 항목에 직접 의견을 추가하십시오. 모든 피드백과 도움은 대단히 감사하겠습니다.


개발 환경 설정 ( Setting up the development environment )

개요 ( Overview )

v1.0.0 릴리스 이전에는 개발 환경에서 Ubuntu 이미지를 실행하여 MacOS, Windows, Linux 및 Windows와 같은 다양한 플랫폼에서 작업하는 개발자를위한 일관된 환경을 보장하는 수단으로 Docker 컨테이너를 시작했습니다. 또는 무엇이든. Docker의 고급 기능 덕분에 가장 인기있는 개발 플랫폼 인 macOS 및 Windows에 대한 기본 지원이 활성화되었습니다. 따라서 우리는 이러한 발전을 최대한 활용하기 위해 빌드를 수정했습니다. Docker가 지원하지 않는 이전 버전의 macOS 및 Windows에서 사용할 수있는 Vagrant 기반 접근 방식을 계속 유지하면서도 비 애매한 개발 설정을 사용하는 것이 좋습니다.

Vagrant 기반 개발 설정은 클라우드 컨텍스트에서 사용할 수 없지만 Docker 기반 빌드는 AWS, Azure, Google 및 IBM과 같은 클라우드 플랫폼을 지원합니다. 아래의 Ubuntu 빌드 지침을 따르십시오.


선결요건 ( Prerequisites )

  • Git client
  • Go - 1.7 or later(for releases before v1.0, 1.6 or later)
  • For macOS, Xcode 반드시 설치해야한다.
  • Docker - 1.12 or later
  • Docker Compose - 1.8.1 or later
  • Pip
  • (mac OS)macOS에는 bsdtar가 기본으로 제공되기 때문에 gnutar를 설치해야 할 수도 있지만 빌드에서는 gnutar 플래그를 사용합니다. Homebrew를 사용하여 다음과 같이 설치할 수 있습니다.
  • (only if using Vagrant) - Vagrant - 1.7.04 later
  • (only if using Vagrant) - VirtualBox - 5.0 or later
  • BIOS Enabled Virtualization Varies based on hardware
  • 참고 : BIOS Enabled Virtualization은 BIOS의 CPU 또는 보안 설정 내에 있을 수 있습니다.
    brew install gnu-tar --with-default-names
    
pipbehave and docker-compose
pip install --upgrade pip
pip install behave nose docker-compose
pip install -I flask==0.10.1 python-dateutil==2.2 pytz==2014.3 pyyaml==3.10 couchdb==1.0 flask-cors==2.0.1 requests==2.4.3 pyOpenSSL==16.2.0 pysha3==1.0b1 grpcio==1.0.4

#PIP packages required for some behave tests
pip install urllib3 ndg-httpsclient pyasn1 ecdsa python-slugify grpcio-tools jinja2 b3j0f.aop six


순서 ( Steps )

GOPATH 설정 ( Set your GOPATH )

호스트의 GOPATH 환경 변수를 올바르게 설정했는지 확인하십시오. 이를 통해 호스트와 VM을 모두 구축 할 수 있습니다.

Go 배포본이 가정하는 표준 위치와 다른 위치에 Go를 설치 한 경우 GOROOT 환경 변수도 설정해야합니다.


Windows 사용자 참고 사항 ( Note to Windows users )

git clone 명령을 실행하기 전에 Windows를 실행하는 경우 다음 명령을 실행하십시오.

git config --get core.autocrlf

core.autocrlftrue로 설정된 경우 실행하여 false로 설정해야합니다.

git config --global core.autocrlf false

If you continue with core.autocrlf set to true, the vagrant up command will fail with the error:

./setup.sh: /bin/bash^M: bad interpreter: No such file or directory


Fabric 프로젝트 복제 ( Cloning the Fabric project )

Fabric 프로젝트는 Go 프로젝트이므로 Fabric Repo를 $ GOPATH / src 디렉토리에 복제해야합니다. $ GOPATH에 경로 구성 요소가 여러 개인 경우 첫 번째 경로 구성 요소를 사용하는 것이 좋습니다. 약간의 설정이 필요합니다.

cd $GOPATH/src
mkdir -p github.com/hyperledger
cd github.com/hyperledger

Recall that we are using Gerrit for source control, which has its own internal git repositories. Hence, we will need to clone from Gerrit. For brevity, the command is as follows:

자체적 인 git 저장소가있는 소스 컨트롤에 Gerrit을 사용하고 있음을 상기하십시오. 그러므로 우리는 Gerrit로부터 복제해야 할 것입니다. 간결함을 위해 명령은 다음과 같습니다.

git clone ssh://LFID@gerrit.hyperledger.org:29418/fabric && scp -p -P 29418 LFID@gerrit.hyperledger.org:hooks/commit-msg fabric/.git/hooks/

참고 : 물론 LFID를 자신의 Linux Foundation ID로 바꾸는 것이 좋습니다.


Vagrant를 사용하여 VM 부트 스트랩하기 ( Bootstrapping the VM using Vagrant )

Vagrant 개발자 환경을 사용할 계획이면 다음 단계가 적용됩니다. 다시 말하지만 Mac이나 Windows 용 Docker에서 지원하지 않는 이전 버전의 macOS 및 Windows에 제한된 개발자를 제외하고는 사용하지 않는 것이 좋습니다.

cd $GOPATH/src/github.com/hyperledger/fabric/devenv
vagrant up

가서 커피를 마시고 ... 몇 분이 걸릴 것입니다. 완료되면 방금 생성 한 Vagrant VM에 ssh 할 수 있어야합니다.

vagrant ssh

VM 내부에서 $GOPATH/src/github.com/hyperledger/fabric 아래에서 피어 프로젝트를 찾을 수 있습니다. 또한 / hyperledger로 마운트됩니다.

패브릭 만들기 ( Building the fabric )

일단 모든 종속성을 설치하고 저장소를 복제하면, fabric을 빌드하고 테스트 할 수 있습니다.

참고 ( Notes )

참고 : 로컬 패브릭 디렉토리 ($ $GOPATH/src/github.com/hyperledger/fabric)에있는 파일을 변경할 때마다 업데이트가 VM 패브릭 디렉토리에서 즉시 사용할 수 있습니다.

참고 : HTTP 프록시 뒤에서 개발 환경을 실행하려면 프로비저닝 프로세스가 완료 될 수 있도록 게스트를 구성해야합니다. vagrant-proxyconf 플러그인을 통해이를 수행 할 수 있습니다. vagrant plugin install vagrant-proxyconf 를 설치 한 다음 vagrant up를 실행하기 전에 VAGRANT_HTTP_PROXY 및 VAGRANT_HTTPS_PROXY 환경 변수를 설정하십시오. 자세한 내용은 https://github.com/tmatilai/vagrant-proxyconf/에서 확인할 수 있습니다.

참고 : 이 명령을 처음 실행하면 완료하는 데 꽤 오랜 시간이 걸릴 수 있으며 (환경에 따라 30 분 이상 소요될 수 있음) 시간이 지남에 따라 아무 것도하지 않는 것처럼 보일 수 있습니다. 오랫동안 오류 메시지를 남기지 않는 한 모든 것이 좋다. 단지 크랭크 작업 일 뿐이다.

Windows 10 사용자 참고 사항 : Windows 10의 유조기에는 알려진 문제점이 있습니다 (seemitchellh / vagrant # 6754). vagrant up 명령이 실패하면 Microsoft Visual C ++ 재배포 가능 패키지가 설치되어 있지 않을 수 있습니다. 누락 된 패키지는 다음 주소에서 다운로드 할 수 있습니다. http://www.microsoft.com/en-us/download/details.aspx?id=8328


패브릭 만들기 ( Building the fabic )

다음 지침에서는 개발 환경을 이미 설정했다고 가정합니다.

패브릭을 빌드하려면

cd $GOPATH/src/github.com/hyperledger/fabric
make dist-clean all

단위 테스트 실행하기 ( Running the unit tests )

다음 순서에 따라 모든 단위 테스트를 실행하십시오.

cd $GOPATH/src/github.com/hyperledger/fabric
make unit-test

테스트의 서브 세트를 실행하려면, TEST_PKGS 환경 변수를 설정하십시오. 패키지 목록을 공백으로 구분하여 지정하십시오 밑의 예를 보면,

export TEST_PKGS="github.com/hyperledger/fabric/core/ledger/..."
make unit-test

특정 테스트를 실행하려면 -run RE 플래그를 사용하십시오. 여기서 RE는 테스트 케이스 이름과 일치하는 정규식입니다. 자세한 출력으로 테스트를 실행하려면 -v 플래그를 사용하십시오. 예를 들어, TestGetFoo 테스트 케이스를 실행하려면 foo_test.go를 포함하는 디렉토리로 변경하고 / 실행합니다.

go test -v -run=TestGetFoo

Node.js 단위 테스트 실행하기 ( Running Node.js Unit Tests )

또한 Node.js 단위 테스트를 실행하여 변경 사항에 따라 Node.js 클라이언트 SDK가 손상되지 않도록해야합니다. Node.js 단위 테스트를 실행하려면 여기에 나온 지침을 따르십시오.

동적 BDD 테스트 실행 ( Running Behave BDD Tests )

참고 : 현재 Vagrant 환경에서 동작 테스트를 실행해야합니다. Vagrant 환경을 아직 설정하지 않은 경우 개발 환경 설정 지침을 참조하십시오.

행동 테스트는 다른 보안 및 합의 구성으로 동료 네트워크를 설정하고 트랜잭션이 제대로 실행되는지 확인합니다. 이 테스트를 실행하려면

cd $GOPATH/src/github.com/hyperledger/fabric
make behave

일부 동작 테스트는 Docker 컨테이너에서 실행됩니다. 테스트가 실패하고 Docker 컨테이너에서 로그를 가져 오려면이 옵션을 사용하여 테스트를 실행하십시오.

cd $GOPATH/src/github.com/hyperledger/fabric/bddtests
behave -D logs=Y


Vagrant 외부 구축 ( Building outside of Vagrant )

프로젝트를 빌드하고 다른 직원을 Vagrant의 바깥에 둘 수 있습니다. 일반적으로 말해서, Vagrant 설정 파일을 원하는 플랫폼으로 '변환'해야합니다.

Z 만들기 ( Building on Z )

Z를 더 쉽고 빠르게 만들기 위해이 스크립트가 제공됩니다 (방랑벽에 제공된 설정 파일과 비슷합니다). 이 스크립트는 RHEL 7.2에서만 테스트되었으며 재 방문 (방화벽 설정, 루트 사용자로 개발 등) 할 수있는 몇 가지 가정이 있습니다. 그러나 개인적으로 할당 된 VM 인스턴스의 개발에는 충분합니다.

새로 설치 한 OS에서 시작하려면 다음을 수행하십시오

sudo su
yum install git
mkdir -p $HOME/git/src/github.com/hyperledger
cd $HOME/git/src/github.com/hyperledger
git clone http://gerrit.hyperledger.org/r/fabric
source fabric/devenv/setupRHELonZ.sh

이 시점에서 위에서 설명한대로 Vagrant 개발 환경을 진행할 수 있습니다.

cd $GOPATH/src/github.com/hyperledger/fabric
make peer unit-test behave

파워 플랫폼 구축 ( Building on Power Platform )

Power (ppc64le) 시스템의 개발 및 구축은 여기에 설명 된대로 외부에서 수행됩니다. Ubuntu에서 dev 환경을 쉽게 설정하려면이 스크립트를 루트로 호출하십시오. 이 스크립트는 Ubuntu 16.04에서 검증되었으며 특정 사항 (예 : 개발 시스템에 OS 저장소가 있고 방화벽 설정 등)을 가정하고 일반적으로 더 즉석에서 처리 할 수 있습니다.

Ubuntu와 함께 설치된 Power 서버를 시작하려면 먼저 호스트의 GOPATH 환경 변수를 올바르게 설정했는지 확인하십시오. 그런 다음, 다음 명령을 실행하여 패브릭 코드를 작성하십시오.

mkdir -p $GOPATH/src/github.com/hyperledger
cd $GOPATH/src/github.com/hyperledger
git clone http://gerrit.hyperledger.org/r/fabric
sudo ./fabric/devenv/setupUbuntuOnPPC64le.sh
cd $GOPATH/src/github.com/hyperledger/fabric
make dist-clean all


구성 ( Configuration )

구성은 바이퍼 및 코브라 라이브러리를 사용합니다.

피어 프로세스의 구성을 포함하는 core.yaml 파일이 있습니다. 대부분의 구성 설정은 구성 설정과 일치하는 ENV 변수를 설정하지만 'CORE_'접두사로 설정하여 명령 줄에서 무시할 수 있습니다. 예를 들어 환경을 통한 로깅 수준 조작은 아래와 같습니다.

CORE_PEER_LOGGING_LEVEL=CRITICAL peer


로깅 ( Logging )

로깅은 go-logging 라이브러리를 사용합니다.

사용 가능한 로그 레벨은 자세한 표시 순으로 다음과 같습니다. CRITICAL | 오류 | 경고 | 주의 사항 | 정보 | 디버그

다양한 Fabric 구성 요소를 실행할 때 출력 할 로그 메시지의 레벨을 조정하는 방법은 로깅 제어 문서를 참조하십시오.

Linux Foundation 계정 요청 ( Requesting a Linux Foundation Account )

Fabric 코드 기반에 대한 기여는 Linux Foundation 계정이 필요합니다. 아래 단계에 따라 Linux Foundation 계정을 만드십시오.

Linux Foundation ID 만들기 ( Creating a Linux Foundation ID )

  1. Linux Foundation ID 웹 사이트로 이동하십시오.
  2. I need to create a Linux Foundation ID옵션을 선택하십시오.
  3. 나타나는 양식을 작성하십시오.
  4. 전자 메일 계정을 열고 "Linux Foundation ID 전자 메일 유효성 검사"제목 줄이 포함 된 메시지를 찾습니다.
  5. 수신 된 URL을 열어 이메일 주소의 유효성을 확인하십시오.
  6. You have successfully    validated your e-mail address 메시지가 표시되는지 확인합니다.
  7. 로그인 Sign In을 선택하고, Gerrit에 엑세스 하십시오.
  8. Linux Foundation ID를 사용하여 로그인하십시오 :

SSH를 사용하도록 Gerrit 구성 ( Configuring Gerrit to Use SSH )

Gerrit는 SSH를 사용하여 Git 클라이언트와 상호 작용합니다. SSH 개인 키는 Gerrit 서버에서 일치하는 공개 키로 개발 컴퓨터에서 생성되어야합니다.

이미 SSH 키 쌍이 있다면이 섹션을 건너 뛰십시오.

예를 들어, Linux 환경에서 SSH 키 쌍을 생성하는 단계를 제공합니다. OS에서 동일한 단계를 따르십시오.

  • 키 쌍을 작성하려면 다음을 입력하십시오.
  • ssh-keygen -t rsa -C "John Doe john.doe@example.com" 참고 : 이렇게하면 고유 키를 생성 할 때 개인 키를 보호하기위한 암호를 묻습니다. 이 암호는 비공개로 유지하고 빈 암호를 입력하지 마십시오. 생성된 키 쌍은 ~/.ssh/id_rsa 과 ~/.ssh/id_rsa.pub에 있습니다.
  • 열쇠 고리의 id_rsa 파일에 비공개 키를 추가하십시오.
  • ssh-add ~/.ssh/id_rsa 키 쌍이 생성되면 공용 키를 Gerrit에 추가해야합니다. 공개 키 id_rsa.pub를 Gerrit 계정에 추가하려면 다음 단계를 따르십시오.
    1. Gerrit로 이동하십시오.
    2. 오른쪽 상단에서 계정 이름을 클릭하십시오.
    3. 팝업메뉴에서 Settings을 선택하세요.
    4. 왼쪽 메뉴에서 SSH Public Keys를 클릭하십시오. 
    5. 공개 키 ~/.ssh/id_rsa.pub의 내용을 붙여넣고 Add key를 클릭하십시오. 참고 : id_rsa.pub 파일은 텍스트 편집기로 열 수 있습니다. 파일의 모든 내용을 선택하고 복사하여 Gerrit의 Add SSH key 창에 붙여 넣었는지 확인하십시오. 참고: ssh 키 생성 지시문은 사용자가 기본 이름 지정을 사용한다는 가정하에 작동합니다. 여러 개의 ssh 키를 생성하고 결과 파일의 이름을 다르게 지정할 수 있습니다. 이를 수행하는 방법에 대한 자세한 내용은 ssh-keygen 설명서를 참조하십시오. 기본값이 아닌 키를 생성 한 후에는 Gerrit에 올바른 키를 사용하도록 ssh를 구성해야합니다. 이 경우 ~/.ssh/config 파일을 만들어야합니다. host gerrit.hyperledger.org HostName gerrit.hyperledger.org IdentityFile ~/.ssh/id_rsa_hyperledger_gerrit User <LFID> Linux Foundation ID는 어디에 있고 IdentityFile의 값은 생성 한 공개 키 파일의 이름입니다. 경고 : 잠재적 인 보안 위험! 개인 키를 복사하지 마십시오 ~ / .ssh / id_rsa public ~ / .ssh / id_rsa.pub 만 사용하십시오.

소스코드 체크아웃 ( Checking Out the Source Code )

  1. SSH가 제대로 설정되었는지 확인하십시오. 자세한 내용은 Configuring Gerrit to Use SSH 을 참조하십시오.
  2. Linux Foundation ID로 저장소를 복제하십시오 (). git clone ssh://<LFID>@gerrit.hyperledger.org:29418/fabric fabric 로컬 컴퓨터에 대한 소스 코드 복사본을 성공적으로 체크 아웃했습니다.


Gerrit으로 작업 ( Working with Gerrit )

다음 지침에 따라 Gerrit 검토 시스템을 통해 Hyperledger Fabric Project에서 공동 작업을 수행하십시오.

메일링리스트에 가입되어 있는지 확인하십시오. 도움이 필요하면 채팅으로 연락하십시오.

Gerrit은 사용자에게 다음 역할을 할당합니다.

  • Submitters: 고려 사항 변경 사항을 제출하고 다른 코드 변경 사항을 검토하고 +1 또는 -1로 투표하여 수락 또는 거절 권고를 제출할 수 있습니다.
  • Maintainers: +2 또는 -2의 투표자 검토 결과에 따라 변경 사항을 승인하거나 거부 할 수 있습니다.
  • Builders: (예 : 젠킨스) 빌드 자동화 인프라를 사용하여 변경 사항을 확인할 수 있습니다.

유지 관리자는 검토 프로세스에 익숙해야합니다. 그러나 누구나 검토 변경을 환영하며 (따라서 권장 할 수 있습니다!) 따라서 가치있는 문서를 찾을 수 있습니다.

Git-검토 ( Git-review )

Gerrit로 작업 할 때 git-review라는 매우 유용한 도구가 있습니다. 이 명령 줄 도구는 다음 섹션의 대부분을 자동화 할 수 있습니다. 물론 뒤에서 일어나는 일을 이해할 수 있도록 아래 정보를 읽는 것이 좋습니다.

샌드박스 프로젝트 ( Sandbox project )

개발자가 Gerrit 및 워크 플로우에 익숙해 지도록 샌드 박스 프로젝트를 만들었습니다. 이 프로젝트를 사용하여 아래 명령과 도구를 사용해보십시오.

Gerrit에 대해 자세히 알아보기 ( Getting deeper into Gerrit )

Gerrit에 대한 포괄적 인 설명은이 문서의 범위를 벗어납니다. 인터넷에는 많은 리소스가 있습니다. 좋은 요약은 여기에서 찾아 낼 수있다. 또한 유용한 모범 사례를 제공했습니다.

저장소의 로컬 복제 작업 ( Working with a local clone of the repository )

새로운 기능이든 버그 수정이든 무언가를 작업하려면 다음을 수행하십시오.

  1. Gerrit Projects 페이지를 여십시오.
  2. 작업하려는 프로젝트를 선택하십시오.
  3. Terminal 창을 열고 Clone with git hook URL을 사용하여 프로젝트를 로컬로 복제하십시오. ssh가 선택되어 있으면 인증이 훨씬 간단 해집니다.
    git clone ssh://LFID@gerrit.hyperledger.org:29418/fabric && scp -p -P 29418 LFID@gerrit.hyperledger.org:hooks/commit-msg fabric/.git/hooks/
    
    참고 : 패브릭 프로젝트 저장소를 복제하는 경우 $GOPATH/src/github.com/hyperledger 디렉토리에 복제하여 빌드하고 Vagrant 개발 환경에서 사용할 수 있도록합니다.
  4. 복제 된 저장소에서 설명 적으로 명명 된 분기 만들기
    cd fabric
    git checkout -b issue-nnnn
    
  5. 코드를 커밋하십시오. 효과적인 커밋을 만드는 방법에 대한 자세한 내용은 변경 내용 제출시 이 문서를 참조하십시오.
    git commit -s -a
    
    그런 다음 정확하고 읽기 쉬운 커밋 메시지를 입력하고 제출하십시오.
  6. 문서에 영향을 미치는 모든 코드 변경 사항에는 문서 및 테스트에 대한 해당 변경 사항 (또는 추가 사항)이 수반되어야합니다. 이렇게하면 병합 된 PR이 되돌려지면 변경 사항의 모든 흔적도 바뀌게됩니다.

변경 제출 ( Submitting a Change )

현재 Gerrit는 검토를 위해 변경 사항을 제출하는 유일한 방법입니다.

참고 : 변경 사항 제출 및 제출 지침을 검토하십시오.

git review 사용 ( Use git review )

참고 : 원할 경우 다음 대신 git-review 도구를 사용할 수 있습니다. 예 :

.git/config에 다음 섹션을 추가하고 <USERNAME>을 gerrit ID로 바꿉니다.

[remote "gerrit"]
    url = ssh://<USERNAME>@gerrit.hyperledger.org:29418/fabric.git
    fetch = +refs/heads/*:refs/remotes/gerrit/*

git review로 변경 사항을 제출하십시오.

$ cd <your code dir>
$ git review

패치를 업데이트 할 때 git commit --amend로 커밋 한 다음 git review명령을 반복하십시오.

git review 사용 안 함 ( Not Use git review )

소스 코드 작성 지침을 참조하십시오.

변경 내용을 제출할 준비가되면 Gerrit는 변경 내용을 특수 분기로 푸시해야합니다. 이 특수 분기의 이름에는 일단 허용되는 코드가 있어야 할 마지막 분기에 대한 참조가 들어 있습니다.

Hyperledger Fabric Project의 경우 특수 분기는 refs/for/master라고 합니다. 

현재 로컬 개발 브랜치를 gerrit 서버로 푸시하려면 복제 된 리포지토리의 루트에서 터미널 창을 엽니다.

cd <your clone dir>
git push origin HEAD:refs/for/master

명령이 올바르게 실행되면 출력은 다음과 유사하게 나타납니다.

Counting objects: 3, done.
Writing objects: 100% (3/3), 306 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Processing changes: new: 1, refs: 1, done
remote:
remote: New Changes:
remote:   https://gerrit.hyperledger.org/r/6 Test commit
remote:
To ssh://LFID@gerrit.hyperledger.org:29418/fabric
* [new branch]      HEAD -> refs/for/master

gerrit 서버는 변경 사항을 추적 할 수있는 링크를 생성합니다.

검토자 추가하기 ( Adding reviewers )

필요에 따라 변경 사항에 검토자를 추가 할 수 있습니다.

명령 행을 통해 검토 자 목록을 지정하려면 push 명령에 % r=reviewer@project.org를 추가하십시오. 예를 들어,

git push origin HEAD:refs/for/master%r=rev1@email.com,r=rev2@notemail.com

또는 커밋에 동일한 평가자가 모두있는 경우 검토 자 세트를 추가하도록 GIT를 자동 구성 할 수 있습니다.

기본 검토 자 목록을 추가하려면 프로젝트 디렉토리에서 : file : .git/config 파일을 열고 [ branch “master” ]섹션에 다음 줄을 추가하십시오.

[branch "master"] #.... push =
HEAD:refs/for/master%r=rev1@email.com,r=rev2@notemail.com`

@email.com and @notemail.com 주소 대신 실제 이메일 주소를 사용해야합니다. origin을 git 원격 이름으로 바꾸는 것을 잊지 마십시오.

Gerrit를 사용하여 검토하기 ( Reviewing Using Gerrit )

  • Add: 이 버튼을 사용하면 변경 제출자가 변경 사항을 검토해야하는 사람들의 이름을 수동으로 추가 할 수 있습니다. 이름 입력을 시작하면 시스템에 등록 된 사람 목록과 시스템에 대한 액세스 권한에 따라 시스템이 자동 완성됩니다. 그들은 당신이 그들의 입력을 요구하고 있다는 것을 이메일로 통보 받게 될 것입니다.
  • Abandon: 이 버튼은 제출자 만 사용할 수 있습니다. 이것은 커미터가 변경 사항을 포기하고 병합 대기열에서 제거 할 수있게합니다.
  • Change-ID: 이 ID는 Gerrit (또는 system)에 의해 생성됩니다. 검토 프로세스에서 커밋을 수정해야한다고 결정할 때 유용합니다. 새 버전을 제출할 수 있습니다. 동일한 Change-ID 헤더 (및 값)가있는 경우 Gerrit는이를 기억하고 동일한 변경 사항의 다른 버전으로 제시합니다.
  • Status: 현재 왼쪽 상단 모서리의 'Needs Verified (확인 필요)'로 표시된 변경 사례가 리뷰 상태입니다. 검토 자 목록은 모두 의견을 발표하며, 병합에 동의하면 +1을, 동의하지 않으면 -1을 표시합니다. Maintainer 역할을 가진 Gerrit 사용자는 +2 또는 -2의 투표로 병합하거나 거부 할 수 있습니다.

통지는 커밋 메시지의 Signed-by-by 행의 전자 메일 주소로 보내집니다. Gerrit 대시 보드를 방문하여 요청 진행 상황을 확인하십시오. Gerrit의 기록 탭에는 인라인 코멘트와 리뷰 작성자가 표시됩니다.

대기중인 변경 사항보기 ( Viewing Pending Changes )

Find all pending changes by clicking on the link in the upper-left corner, or open this link.

왼쪽 상단 모서리의 All --> Changes 링크를 클릭하여 보류중인 변경 사항을 모두 찾거나이 링크를 여십시오. 여러 프로젝트에서 공동 작업하는 경우 오른쪽 상단의 검색 창을 통해 특정 분기로 검색을 제한 할 수 있습니다.

필터 프로젝트 : fabric을 추가하여 가시적 인 변경 사항을 Hyperledger Fabric Project의 변경 사항으로 제한하십시오.

My --> Changes를 클릭하거나이 링크를 열어 제출 한 모든 현재 변경 사항을 나열하거나 입력이 필요한 변경 사항 만 나열하십시오.


Gerrit에 변경 사항 제출 ( Submitting a Change to Gerrit )

변경 사항을 제출하기 전에 다음을 주의 깊게 검토하십시오. 이 가이드 라인은 오픈 소스를 처음 사용하는 개발자는 물론 경험 많은 오픈 소스 개발자에게도 적용됩니다.

요구 사항 변경 ( Change Requirements )

이 섹션에는 검토를 위해 코드 변경을 제출하기위한 지침이 포함되어 있습니다. Gerrit를 사용하여 변경 사항을 제출하는 방법에 대한 자세한 내용은 Gerrit를 참조하십시오.

변경 사항은 Git 커밋으로 제출됩니다. 각 커밋은 다음을 포함해야합니다.

  • 짧고 설명이 포함 된 제목 줄 (72 자 이하)과 빈 줄이옵니다.
  • 변경 사항에 대한 논리 또는 추론에 대한 설명 변경, 빈 줄
  • Signed-off-by line, 콜론 (Signed-off-by :)
  • Change-Id 식별자 행 다음에 콜론 (Change-Id :)이옵니다. Gerrit는이 식별자가없는 패치를 허용하지 않습니다.

위의 세부사항을 가진 커밋은 올바른 것으로 간주됩니다.

Gerrit에 전송 된 모든 변경 사항 및 주제는 올바른 형식이어야합니다. 정보를 제공하기 위해 커밋 메시지에는 다음 내용이 포함되어야합니다.

  • what the change does,(변화가 무엇인지,)
  • why you chose that approach, and(왜 당신이 그 접근법을 선택했는지, 그리고)
  • how you know it works – for example, which tests you ran.(어떻게 작동하는지 알 수있는 방법 - 예를 들어 어떤 테스트를 실행했는지.)

커밋은 서로의 상단에 적용될 때 깨끗하게 구축되어야하며 따라서 이등분 성이 깨지지 않도록해야합니다. 각 커밋은 식별 가능한 단일 문제를 처리해야하며 논리적으로 자체 포함되어야합니다.

예를들어, 한 커밋은 공백 문제를 수정하고, 다른 커밋은 함수의 이름을 바꾸고 세 번째 커밋은 코드의 기능을 변경합니다. 다음은 커밋 파일의 예입니다.

A short description of your change with no period at the end

You can add more details here in several paragraphs, but please keep each line
width less than 80 characters. A bug fix should include the issue number.

Fix Issue # 7050.

Change-Id: IF7b6ac513b2eca5f2bab9728ebd8b7e504d3cebe1
Signed-off-by: Your Name <commit-sender@email.address>

각 커밋은 커밋 메시지 맨 아래에 다음 행을 포함해야합니다.

Signed-off-by: Your Name <your@email.address>

Signed-by-by 라인의 이름과 귀하의 이메일은 변경 저자 정보와 일치해야합니다. your : file : .git/config가 올바르게 설정되었는지 확인하십시오. 항상 Gerrit를 통해 변경 사항 전체를 제출하십시오.


변경 사항 검토 ( Reviewing a Change )

  • 1. 수신 또는 발신 검토를 위한 링크를 클릭하십시오.
  • 2. 변경 사항 및 현재 상태가 로드됩니다.
    • Status: 변경의 현재 상태를 표시합니다. 아래 예에서 상태는 Needs Verified로 표시됩니다.
    • Reply: 검토 후이 버튼을 클릭하여 최종 검토 메시지와 점수 -1, 0 또는 +1을 추가하십시오. +1.
    • Patch Sets: 패치의 여러 개정판이있는 경우이 단추를 사용하여 개정판을 탐색하여 변경 사항을 볼 수 있습니다. 기본적으로 가장 최근의 개정판이 표시됩니다.
    • Download: 이 버튼은 현재 변경 집합을 다운로드하거나 체크 아웃 할 수있는 여러 옵션이있는 다른 창을 불러옵니다. 오른쪽의 버튼은 선을 클립 보드로 복사합니다. git 인터페이스에 패치를 붙여 넣으면 원하는대로 패치 작업을 수행 할 수 있습니다.

커밋 정보 아래에 이 패치로 변경된 파일이 표시됩니다.

  • 3. 파일 이름을 클릭하여 검토하십시오. 차별화 할 코드 기반을 선택하십시오. 기본값은 Base이며 일반적으로 필요한 것입니다.
  • 4. 검토 페이지에는 파일에 대한 변경 사항이 표시됩니다. 리뷰의 맨 위에서, 프리젠 테이션은 일반적인 탐색 옵션을 보여줍니다. 오른쪽 상단의 화살표를 사용하여 패치 세트를 탐색하십시오. 세트의 이전 또는 다음 파일로 이동하거나 기본 변경 화면으로 돌아갈 수 있습니다. 노란 끈적한 패드를 클릭하여 전체 파일에 주석을 추가하십시오.

페이지의 초점은 비교 창에 있습니다. 변경 사항은 왼쪽의 기본 버전과 오른쪽의 녹색으로 표시됩니다. 코드의 특정 섹션에 대한 피드백을 제공하려면 실제 변경 내에서 텍스트를 두 번 클릭하여 강조 표시하십시오. 해당 섹션에 주석을 추가하려면 코드가 강조 표시되면 c를 누릅니다.

  • 5. 주석을 추가 한 후에는 초안으로 저장됩니다.
  • 6. 모든 파일을 검토하고 피드백을 보내면 오른쪽 상단의 녹색 위쪽 화살표를 클릭하여 주 변경 페이지로 돌아갑니다. Reply 버튼을 클릭하고 몇 가지 최종 코멘트를 작성한 다음 패치 세트 점수를 제출하십시오. Post을 클릭하여 검토 된 각 파일의 리뷰와 최종 코멘트 및 점수를 제출하십시오. Gerrit는 변경 제출자 및 나열된 모든 검토 자에게 전자 메일을 보냅니다. 마지막으로 나중에 참조 할 수 있도록 검토를 기록합니다. Post 버튼을 클릭 할 때까지 모든 개별 주석은 임시로 저장됩니다.

이 문서는 Gerrit를보다 효과적으로 사용하는 데 도움이되는 몇 가지 모범 사례를 제공합니다. 콘텐츠를 쉽게 제출할 수있는 방법을 보여주기위한 것입니다. 권장 사례를 사용하여 문제 해결 시간을 줄이고 커뮤니티 참여를 향상 시키십시오.

Git 트리 찾아보기 ( Browsing the Git Tree )

Visit Gerrit then select Projects --> List --> SELECT-PROJECT --> Branches. Select the branch that interests you, click on gitweb located on the right-hand side. Now, gitweb loads your selection on the Git web interface and redirects appropriately.

Gerrit를 방문한 다음 Projects --> List --> SELECT-PROJECT --> Branches를 선택하십시오. 관심있는 지점을 선택하고 오른쪽에있는 gitweb을 클릭하십시오. 이제, gitweb은 Git 웹 인터페이스에서 선택한 것을로드하고 적절히 리디렉션합니다.

프로젝트 보기 ( Watching a Project )

Gerrit를 방문한 다음 오른쪽 상단에있는 Settings을 선택하십시오. Watched Projects를 선택한 다음 관심있는 프로젝트를 추가하십시오.

커밋 메시지 ( Commit Messages )

Gerit은 Git commit 메시지 형식을 따른다. 머리글이 맨 아래에 있고 서로 사이에 빈 줄이 들어 있지 않은지 확인하십시오. 다음 예는 커밋 메시지에서 예상되는 형식과 내용을 보여줍니다.

짧은 줄 (50 자 이하) 한 줄 설명.

이유 (동기 부여), 변경된 사항 및 테스트 방법을 참조하여 변경된 사항을 정교하게 요약합니다. 72 자 / 줄로 텍스트를 줄 바꿈하여 코드 변경 사항과 일관되게 유지되도록 만든 설명서의 변경 사항도 확인하십시오.

Jira : FAB-100

변경 ID : LONGHEXHASH

서명 한 사람 : 귀하의 이름 your.email@example.org

AnotherExampleHeader : 다른 값의 예

Gerrit 서버는 한 번 사용하는 Change-Id를 자동 생성하기위한 사전 커밋 (precommit hook)을 제공합니다.

추천 읽을 자료 : Git Commit 메시지 작성 방법

Avoid Pushing Untested Work to a Gerrit Server(테스트되지 않은 작업을 Gerrit Server로 푸시 피하기)

테스트되지 않은 작업을 Gerrit로 푸시하지 않기

변경 사항을 Gerrit로 보내기 전에 작업을 적어도 세 번 확인하십시오. 게시하는 정보에 유의하십시오.

변경 사항 추적 ( Keeping Track of Changes )

  • Gerrit가 이메일을 보내도록 설정합니다.
  • 개발자가 당신을 리뷰어로 추가하거나 특정 패치 세트에 대해 의견을 제시하면 Gerrit가 변경 사항을 이메일 배포 목록에 추가합니다.
  • Gerrit의 리뷰 인터페이스에서 변경 사항을 열면 해당 변경 사항을 신속하게 따라 할 수 있습니다.
  • Gerrit의 Gerrit 프로젝트 섹션에서 프로젝트를보고 새 변경 사항, 새 패치 세트, 모든 설명 및 제출 된 변경 사항을 선택하십시오.

항상 작업중인 프로젝트를 추적하십시오. 또한 피드백 / 설명 메일 링리스트를보고 다른 사람들이 배우는 것을 도울 수 있습니다.

주제 브런치 ( Topic branches )

주제 브런치는 논리적으로 그룹화 된 종속 커밋 세트를 커밋하기 위해 푸시하는 임시 분기입니다.

TopicName에서 주제로 검토하기 위해 REMOTE/master 트리에서 Gerrit로 변경 사항을 푸시하려면 다음 명령을 예로 사용하십시오.

$ git push REMOTE HEAD:refs/for/master/TopicName

주제는 리뷰에 표시됩니다 : abbr : UIOpen Changes List. 주제 분기는 내용이 병합 될 때 마스터 트리에서 사라집니다.

주제에 대한 커버레터 작성 ( Creating a Cover Letter for a Topic )

표지 말을 기록부에 표시 할 것인지 여부를 결정할 수 있습니다.

  1. 내역에 표시되는 커버 레터를 만들려면 다음 명령을 사용하십시오.
    git commit --allow-empty
    
    커밋 메시지를 편집하면이 메시지가 커버 레터가됩니다. 사용 된 명령은 소스 트리에있는 파일을 변경하지 않습니다.
  2. 기록에 나타나지 않는 안내문을 작성하려면 다음 단계를 따르십시오.
    • 빈 커밋을 커밋 리스트의 마지막에 넣어 rebase하지 않고. 무시 될 수 있게 한다.
    • 이제 커밋을 추가하십시오.
      git commit ...
      git commit ...
      git commit ...
      
    • 마지막으로, 커밋을 주제 분기로 푸시하십시오. 다음 명령은 예제입니다. git push REMOTE HEAD:refs/for/master/TopicName 이미 커밋을했지만 커버 레터를 설정하려면 커버 레터에 빈 커밋을 작성하고 커밋을 이동하여 목록의 마지막 커밋이되도록합니다. 다음 명령을 예제로 사용하십시오.
      git rebase -i HEAD ~ # 커밋
      
      이동하기 전에 커밋의 주석을 제거하십시오. #Commits는 커밋과 새 커버 레터의 합계입니다.

사용 가능한 주제 찾기 ( Finding Available Topics )

$ ssh -p 29418 gerrit.hyperledger.org gerrit query \ status:open project:fabric branch:master \
| grep topic: | sort -u
  • gerrit.hyperledger.org 프로젝트가 호스팅되는 현재 URL입니다.
  • status 주제의 현재 상태 (열림, 합병, 취소됨, 초안, 병합 충돌)를 나타냅니다.
  • 프로젝트 프로젝트의 현재 이름 (이 경우에는 fabric)을 나타냅니다.
  • branch이 브랜치에서 토픽이 검색된다.
  • topic 특정 주제의 이름으로 공백으로두면 모두 포함 할 수 있습니다.
  • sort 찾은 주제를이 경우 update (-u)로 정렬합니다.

다운로드 또는 변경을 체크 아웃 ( Downloading or Checking Out a Change )

검토 UI에서 오른쪽 상단 모서리의 다운로드 링크는 명령 및 하이퍼 링크 목록을 제공하여 체크 아웃하거나 diff 또는 파일을 다운로드합니다.

git review 플러그인을 사용하는 것이 좋습니다. git review를 설치하는 단계는이 문서의 범위를 벗어납니다. 설치 과정에 대해서는 git review 문서를 참조하십시오.

Git을 사용하여 특정 변경 사항을 확인하려면 다음 명령을 사용하십시오.

git review -d CHANGEID

Git-review가 설치되어 있지 않으면 다음 명령이 동일한 작업을 수행합니다.

git fetch REMOTE refs/changes/NN/CHANGEIDNN/VERSION \ && git checkout FETCH_HEAD

예를 들어, 변경 2464의 네 번째 버전에서 NN은 처음 두 자리 (24)입니다.

git fetch REMOTE refs/changes/24/2464/4 \ && git checkout FETCH_HEAD

Draft 분기 사용 ( Using Draft Branches )

변경 사항을 게시하기 전에 초안 분기를 사용하여 특정 검토자를 추가 할 수 있습니다. Draft Branches는 refs/drafts/master/TopicName으로 푸시됩니다.

다음 명령은 로컬 분기가 작성되도록합니다. 

git checkout -b BRANCHNAME

다음 명령은 변경 사항을 TopicName 아래의 초안 분기로 푸시합니다.:

git push REMOTE HEAD:refs/drafts/master/TopicName

샌드 박스 분기 사용 ( Using Sandbox Branches )

자체 분기를 만들어 기능을 개발할 수 있습니다. 브랜치는 refs/sandbox/USERNAME/BRANCHNAME 위치로 푸시됩니다.

이 명령은 Gerrit의 서버에서 분기를 만들도록합니다.

git checkout -b sandbox/USERNAME/BRANCHNAME
git push --set-upstream REMOTE HEAD:refs/heads/sandbox/USERNAME/BRANCHNAME

일반적으로 콘텐츠를 만드는 프로세스는 다음과 같습니다.

  • 코드를 개발하고,
  • 정보를 작은 커밋으로 나누고,
  • 변경 사항 제출,
  • 피드백을 적용하고,
  • rebase.

다음 명령은 검토없이 강제로 푸시됩니다.

git push REMOTE sandbox/USERNAME/BRANCHNAME

검토를 통해 강제로 밀어 낼 수도 있습니다.

git push REMOTE HEAD:ref/for/sandbox/USERNAME/BRANCHNAME

변경 버전 업데이트 ( Updating the Version of a Change )

검토 과정에서 변경 사항을 업데이트하라는 메시지가 표시 될 수 있습니다. 동일한 변경 사항의 여러 버전을 제출할 수 있습니다. 변경의 각 버전을 패치 세트라고합니다.

할당 된 Change-Id는 항상 유지하십시오. 예를 들어, 주제 분기로 제출 된 커밋 목록 c0 ... c7이 있습니다.

git log REMOTE/master..master

c0
...
c7

git push REMOTE HEAD:refs/for/master/SOMETOPIC

reviewers의 피드백을 받으면 수정해야하는 c3c4의 변경 사항이 있습니다. 수정 사항에서 리베이스가 필요한 경우 리베이스 (rebase)는 커밋 ID를 변경합니다. 자세한 정보는 리베이닝 섹션을 참조하십시오. 그러나 동일한 Change-Id를 유지하고 변경 사항을 다시 푸시해야합니다.

git push REMOTE HEAD:refs/for/master/SOMETOPIC

이 새로운 푸시는 패치 개정을 작성하고 로컬 히스토리가 지워집니다. 그러나 각 변경 사항에 대해 review UI 섹션의 Gerrit에서 변경 내역에 계속 액세스 할 수 있습니다.

새 버전을 만들 때 더 많은 커밋을 추가 할 수도 있습니다.

리베이스 ( Rebasing )

Rebase는 일반적으로 Gerrit에 변경 사항을 적용하기 전에 마지막 단계입니다. 이렇게하면 필요한 변경 ID를 만들 수 있습니다. 변경 ID는 동일하게 유지되어야합니다.

  • squash : 두 개 이상의 커밋을 하나의 커밋으로 혼합합니다.
  • reword : 커밋 메시지를 변경합니다.
  • edit : 커밋 내용을 변경합니다.
  • reorder : 커밋의 순서를 바꿀 수 있습니다.
  • rebase : 커밋을 마스터 위에 겹쳐 씁니다.

Pull 도중 리베이스 ( Rebasing During a Pull )

마스터에 리베이스를 보내기 전에 히스토리가 연속 된 순서를 가지는지 확인하십시오.

예를 들어, REMOTE/master에는 a0에서 a4까지의 커밋 목록이 있습니다. 그런 다음 변경 사항 c0 ... c7a4 위에 있습니다. 그러므로:

git log --oneline REMOTE/master..master

a0
a1
a2
a3
a4
c0
c1
...
c7

REMOTE/master가 커밋 a5, a6 및 a7을받는 경우. 다음과 같이 리베이스를 가져옵니다.

git pull --rebase REMOTE master

그러면 a5-a7이 풀리고 c0-c7이 다시 적용됩니다.

$ git log --oneline REMOTE/master..master
a0
...
a7
c0
c1
...
c7


Git에서 더 나은 로그 얻기 ( Getting Better Logs from Git )

보다 나은 로그를 생성하기 위해 Git의 설정을 변경하려면 다음 명령을 사용하십시오 :

git config log.abbrevCommit true

위의 명령은 커밋의 해시를 줄이기 위해 로그를 설정합니다.

git config log.abbrev 5

위의 명령은 약어 길이를 해시의 마지막 5 자로 설정합니다.

git config format.pretty oneline

위의 명령은 작성자 행 앞에 불필요한 행이 삽입되지 않도록 합니다.

현재 Git 사용자에 대해 이러한 구성 변경을 수행하려면 다음과 같이 --global 에 config 경로 옵션을 추가해야합니다.


테스팅 ( Testing )

단위 테스트 ( Unit test )

단위 테스트 지침을 위해 패브릭 구축을 참조하십시오. 단위 테스트 적용 범위 보고서를 참조하십시오. 패키지 및 모든 하위 패키지의 적용 범위를 보려면 -cover스위치를 사용하여 테스트를 실행하십시오.

go test ./... -cover

패키지에 대해 다루지 않은 라인을 정확히 보려면, 적용 범위로 주석이 달린 소스 코드가있는 html 보고서를 생성하십시오.

go test -coverprofile=coverage.out
go tool cover -html=coverage.out -o coverage.html

시스템 테스트 ( System test )

[WIP] ... 곧 나옵니다.

이 항목에는 권장되는 테스트 시나리오는 물론 다양한 구성에 대한 현재 성능 수치가 포함되어 있습니다.


코딩 가이드 라인 ( Coding guidelines )

코딩 고언어 ( Coding Golang )

Go ™ 코드를 작성하고 모범 사례를 엄격히 준수하며 편차를 허용하지 않습니다. Go 코드에 대해 다음 도구를 실행하고 모든 오류 및 경고를 수정해야합니다. - golint - go vet - goimports


gRPC 코드 생성 ( Generating gRPC code() )

.proto 파일을 수정하는 경우 다음 명령을 실행하여 .pb.go 파일을 생성 / 업데이트하십시오.

cd $GOPATH/src/github.com/hyperledger/fabric
make protos


이동 패키지 추가 또는 업데이트 ( Adding or updating Go packages )

Hyperledger Fabric은 패키지 관리를 위해 Govendor를 사용합니다. 즉, 필요한 모든 패키지는 $GOPATH/src/github.com/hyperledger/fabric/vendor  폴더에 있습니다. Go는 go install 또는go build  명령이 실행될 때 GOPATH 대신이 폴더에서 패키지를 사용합니다. 공급 업체 폴더의 패키지를 관리하기 위해 Vagrant 환경에 설치된  vendor를 사용합니다. 패키지 관리에는 다음 명령을 사용할 수 있습니다.

# Add external packages.
govendor add +external

# Add a specific package.
govendor add github.com/kardianos/osext

# Update vendor packages.
govendor update +vendor

# Revert back to normal GOPATH packages.
govendor remove +vendor

# List package.
govendor list


부록 ( APPENDIX )

용어 사전 ( Glossary )

전문 용어가 중요하므로 모든 Fabric 사용자와 개발자는 각 특정 용어의 의미에 동의합니다. 예를 들어 체인 코드 란 무엇입니까? 그래서 우리는 자신을 다시 안심시키고 싶을 때마다 그곳에서 여러분을 지적 할 것입니다. 물론, 원한다면 한 번에 전체 내용을 자유롭게 읽을 수 있습니다. 꽤 교육적입니다!

앵커 피어 ( Anchor Peer )

모든 다른 피어가 검색하고 통신 할 수있는 채널의 피어 노드입니다. 채널의 각 구성원은 앵커 피어 (또는 단일 실패 지점을 방지하기위한 여러 앵커 피어)를 가지고 있으므로 서로 다른 구성원에 속한 피어가 채널의 모든 기존 피어를 검색 할 수 있습니다.

블록 ( Block )

채널의 선행 블록에 암호로 링크 된 순서화 된 트랜잭션 집합입니다.

체인 ( Chain )

원장 체인은 해시로 연결된 트랜잭션 블록으로 구성된 트랜잭션 로그입니다. 피어는 주문 서비스에서 거래 블록을 받고, 승인 정책 및 동시성 위반에 따라 블록의 트랜잭션을 유효 또는 무효로 표시하고 해당 블록을 피어의 파일 시스템에 해시 체인에 추가합니다.

체인 코드 ( Chaincode )

Chaincode는 자산을 암호화하기 위해 원장에서 실행되는 소프트웨어이며 자산 수정을위한 트랜잭션 지침 (비즈니스 논리)입니다.

채널 ( Channel )

채널은 패브릭 네트워크의 개인 블록 체인 오버레이로 데이터 격리 및 기밀성을 허용합니다. 채널 별 원장은 채널의 동료간에 공유되며 거래 당사자는 상호 작용하기 위해 채널에 대해 올바르게 인증되어야합니다. 채널은 Configuration-Block에 의해 정의됩니다.

커밋 ( Commitment )

채널의 각 피어는 순서가 지정된 트랜잭션 블록의 유효성을 검사 한 다음 블록을 채널 원장의 복제본으로 커밋 (쓰기 / 추가)합니다. 또한 피어는 각 블록의 각 트랜잭션을 유효 또는 무효로 표시합니다.

동시성 제어 버전 확인 ( Concurrency Control Version Check )

동시성 제어 버전 검사는 채널의 피어간에 상태를 동기화하는 방법입니다. 피어는 트랜잭션을 병렬로 실행하고 장부에 대한 커밋 전에 피어는 실행 시간에 읽은 데이터가 변경되지 않았는지 확인합니다. 트랜잭션에 대해 읽은 데이터가 실행 시간과 확약 시간 사이에 변경되면 병행 제어 버전 확인 위반이 발생하고 트랜잭션이 원장에서 유효하지 않은 것으로 표시되고 값이 상태 데이터베이스에서 업데이트되지 않습니다.

구성 블록 ( Configuration Block )

시스템 체인 (주문 서비스) 또는 채널에 대한 구성원 및 정책을 정의하는 구성 데이터가 들어 있습니다. 채널 또는 전체 네트워크 (예 : 회원 탈회 또는 가입)에 대한 구성을 수정하면 새로운 구성 블록이 해당 체인에 추가됩니다. 이 블록은 기원 블록의 내용과 델타를 포함합니다.

일치 ( Consensus )

주문에 대한 동의를 생성하고 블록을 구성하는 일련의 거래의 정확성을 확인하는 역할을하는 전체 거래 흐름을 포괄하는 광범위한 용어.

현재 상태 ( Current State )

원장의 현재 상태는 체인 트랜잭션 로그에 포함 된 모든 키의 최신 값을 나타냅니다. 피어는 처리 된 블록에 포함 된 각 유효한 트랜잭션에 대해 최근 값을 원장 현재 상태로 커밋합니다. 현재 상태는 채널에 알려진 모든 최신 키 값을 나타내므로 때로는 세계 상태라고합니다. Chaincode는 현재 상태 데이터에 대한 트랜잭션 제안을 실행합니다.

동적 회원 ( Dynamic Membership )

Fabric은 전체 네트워크의 조작성을 손상시키지 않으면 서 구성원, 피어 및 주문 서비스 노드의 추가 / 제거를 지원합니다. 비즈니스 관계가 조정되고 엔터티가 여러 가지 이유로 추가 / 제거되어야 할 때 동적 멤버십이 중요합니다.

보증 ( Endorsement )

특정 피어 노드가 체인 코드 트랜잭션을 실행하고 클라이언트 응용 프로그램에 제안 응답을 반환하는 프로세스를 나타냅니다. 제안 응답에는 체인 코드 실행 응답 메시지, 결과 (읽기 세트 및 쓰기 세트) 및 이벤트 뿐만 아니라 피어 체인 코드 실행의 증거로 사용될 서명이 포함됩니다. 연쇄 코드 응용 프로그램에는 해당 인증 정책이 있으며 여기에는 인증 피어가 지정됩니다.

보증 정책 ( Endorsement policy )

특정 체인 코드 응용 프로그램에 연결된 트랜잭션을 실행해야하는 채널의 피어 노드와 필수 응답 조합 (보증)을 정의합니다. 정책은 최소 수의 동급 동료, 최소 동료 수의 백분율 또는 특정 연쇄 코드 응용 프로그램에 할당 된 모든 승인하는 동료에 의해 트랜잭션이 승인되도록 요구할 수 있습니다. 정책은 신청서와 승인 된 동료에 의한 (의도적이든 아니든) 오작동에 대한 원하는 탄력성 수준에 따라 관리 될 수 있습니다. 트랜잭션 설치 및 인스턴스화를위한 확실한 보증 정책도 필요합니다.

Fabric-ca

Fabric-ca는 기본 인증 기관 구성 요소로서 네트워크 구성원 조직 및 해당 사용자에게 PKI 기반 인증서를 발급합니다. CA는 각 구성원에게 하나의 루트 인증서 (rootCert), 각 인증 된 사용자에게 하나의 등록 인증서 (eCert) 및 각 eCert에 대한 트랜잭션 인증서 (tCerts) 수를 발급합니다.

제네시스 블록 ( Genesis Block )

블록 체인 네트워크 또는 채널을 초기화하고 체인의 첫 번째 블록 역할을하는 구성 블록.

가십 프로토콜 ( Gossip Protocol )

험담 데이터 보급 프로토콜은 세 가지 기능을 수행합니다.

1) 피어 검색 및 채널 구성원을 관리합니다.

2) 채널의 모든 동료를 통해 원장 데이터를 보급합니다.

3)는 채널의 모든 피어간에 원장 상태를 동기화합니다. 자세한 내용은 가십 주제를 참조하십시오.

초기화 ( Initialize )

체인 코드 응용 프로그램을 초기화하는 메서드입니다.

설치 ( Install )

피어의 파일 시스템에 체인 코드를 배치하는 프로세스입니다.

인스턴스화 ( Instantiate )

특정 채널에서 체인 코드 응용 프로그램을 시작하고 초기화하는 프로세스입니다. 인스턴스 생성 후에 체인 코드가 설치된 피어는 체인 코드 호출을 받아 들일 수 있습니다.

호출 ( Invoke )

chaincode 함수 호출에 사용됩니다. 클라이언트 응용 프로그램은 피어에 트랜잭션 제안서를 전송하여 체인 코드를 호출합니다. invoke

피어는 체인 코드를 실행하고 승인 된 제안 응답을 클라이언트 응용 프로그램에 반환합니다.

클라이언트 응용 프로그램은 보증 정책을 충족시키기에 충분한 제안 응답을 수집 한 다음 주문, 유효성 검사 및 커밋에 대한 트랜잭션 결과를 제출합니다.

클라이언트 응용 프로그램은 트랜잭션 결과를 제출하지 않을 수도 있습니다.

예를 들어 호출이 장부에 쿼리 한 경우 클라이언트 응용 프로그램은 일반적으로 감사 목적으로 장부에 읽기를 기록하려는 경우가 아니면 읽기 전용 트랜잭션을 제출하지 않습니다.

invoke에는 채널 식별자, 호출 할 chaincode 함수 및 인수 배열이 포함됩니다.

리딩 피어 ( Leading Peer )

각 멤버는 구독하는 각 채널에서 여러 피어를 소유할 수 있습니다. 이러한 피어 중 하나는 회원을 대신하여 네트워크 주문 서비스와 통신하기 위해 채널의 주요 동료 역할을합니다. 주문 서비스는 채널의 주요 피어 (peer)에게 블록을 "배달"한 다음 동일한 멤버 클러스터 내의 다른 피어에게 배포합니다.

원장 ( Ledger )

원장은 채널의 체인 및 각 피어가 채널에서 유지 관리하는 현재 상태 데이터입니다.

멤버 ( Member )

네트워크에 대한 고유 한 루트 인증서를 소유 한 법적으로 분리 된 엔터티. 피어 노드 및 응용 프로그램 클라이언트와 같은 네트워크 구성 요소는 구성원에 연결됩니다.

Membership Service Provider(MSP)

Membership Service Provider (MSP)는 클라이언트에게 자격 증명을 제공하는 시스템의 추상적 구성 요소를 지칭하며 동료가 Hyperledger 패브릭 네트워크에 참여할 수 있도록합니다. 클라이언트는이 자격 증명을 사용하여 트랜잭션을 인증하고 피어는이 자격 증명을 사용하여 트랜잭션 처리 결과 (보증)를 인증합니다. 시스템의 트랜잭션 처리 구성 요소와 강력하게 연결되어 있지만이 인터페이스는 시스템의 트랜잭션 처리 구성 요소의 핵심을 수정하지 않고도이를 구현할 수있는 멤버쉽 서비스 구성 요소를 정의하는 것을 목표로합니다.

멤버 서비스 ( Membership Services )

멤버십 서비스는 허가 된 블록 체인 네트워크에서 ID를 인증, 권한 부여 및 관리합니다. 동료 및 주문자에서 실행되는 회원 서비스 코드는 블록 체인 작업을 인증하고 권한을 부여합니다. PKI 기반 멤버십 서비스 공급자 (MSP) 추상화 구현입니다.

fabric-ca 구성 요소는 ID를 관리하기위한 구성원 서비스의 구현입니다. 특히, 등록 인증서 및 트랜잭션 인증서 발급 및 해지를 처리합니다.

등록 인증서는 장기 ID 신임장입니다. 트랜잭션 인증서는 익명이거나 링크 할 수없는 단기 신원 신임장입니다.

주문 서비스 ( Ordering Service )

트랜잭션을 블록으로 정렬하는 노드 집합입니다. 주문 서비스는 피어 프로세스와 독립적으로 존재하며 네트워크상의 모든 채널에 대해 선착순으로 거래를 주문합니다. 주문 서비스는 즉시 사용 가능한 SOLO 및 Kafka 품종을 벗어난 플러그 가능 구현을 지원하도록 설계되었습니다. 주문 서비스는 전체 네트워크에 대한 공통 바인딩입니다. 여기에는 각 회원에게 연결된 암호화 신원 자료가 들어 있습니다.

피어 ( Peer )

장부를 유지 관리하고 체인 코드 컨테이너를 실행하여 원장에 대한 읽기 / 쓰기 작업을 수행하는 네트워크 엔터티. 동료는 회원이 소유하고 유지 관리합니다.

정책 ( Policy )

보증, 검증, 블록 커밋, 체인 코드 관리 및 네트워크 / 채널 관리에 대한 정책이 있습니다.

요청 ( Proposal )

한 채널의 특정 동료를 겨냥한 추천 요청. 각 제안은 인스턴스 작성 또는 호출 (읽기 / 쓰기) 요청 중 하나입니다.

쿼리 ( Query )

쿼리(Query)는 원장 현 상태를 읽지만 원장에게 쓰지 않는 chaincode 호출입니다. Chaincode 함수는 원장의 특정 키를 쿼리하거나 원장의 키 집합을 쿼리할 수 있습니다. 쿼리는 원장 상태를 변경하지 않으므로 클라이언트 응용 프로그램은 일반적으로 주문, 유효성 검사 및 커밋을 위해 이러한 읽기 전용 트랜잭션을 제출하지 않습니다. 일반적이지는 않지만 클라이언트 응용 프로그램은 주문, 유효성 검사 및 커밋에 대한 읽기 전용 트랜잭션을 제출하도록 선택할 수 있습니다. 예를 들어 클라이언트가 특정 시점에서 특정 원장 상태를 알고 있는 원장 체인의 감사가능한 경우

소프트웨어 개발 키트 (SDK) ( Software Development Kit(SDK) )

Hyperledger 패브릭 클라이언트 SDK는 개발자가 체인 코드 응용 프로그램을 작성하고 테스트 할 수있는 라이브러리의 구조화 된 환경을 제공합니다. SDK는 표준 인터페이스를 통해 완전히 구성 가능하고 확장 가능합니다. 시그너처, 로깅 프레임 워크 및 상태 저장소에 대한 암호화 알고리즘을 포함한 구성 요소는 SDK에서 쉽게 교환 할 수 있습니다. SDK는 트랜잭션 처리, 멤버십 서비스, 노드 트래버 설 및 이벤트 처리를위한 API를 제공합니다. SDK는 여러 가지 형태로 제공됩니다: Node.js, Java. 및 Python

상태 데이터베이스 ( State Database )

현재 상태 데이터는 체인 코드에서 효율적인 읽기 및 쿼리를 위해 상태 데이터베이스에 저장됩니다. 이러한 데이터베이스에는 levelDB 및 couchDB가 포함됩니다.

시스템 체인 (System Chain )

시스템 수준에서 네트워크를 정의하는 구성 블록(configuration block)을 포함합니다. 시스템 체인은 주문 서비스 내에 있으며 채널과 유사하게 MSP 정보, 정책 및 구성 세부 정보와 같은 정보를 포함하는 초기 구성을 갖습니다. 전체 네트워크가 변경되면 (예 : 새 조직에 가입하거나 새 주문 노드를 추가하면) 시스템 구성에 새로운 구성 블록이 추가됩니다.

시스템 체인은 채널 또는 채널 그룹에 대한 공통 바인딩으로 생각할 수 있습니다. 예를 들어, 금융 기관의 집합체가 컨소시엄 (시스템 체인을 통해 표현됨)을 형성 한 다음 조정되고 다양한 비즈니스 아젠다와 관련된 채널을 만들 수 있습니다.

트랜잭션 ( Transaction )

주문, 검증 및 커밋(ordering, validation, commit)을 위해 제출된 결과를 호출하거나 인스턴스화합니다. 호출(Invoke)은 원장에서 데이터를 읽고 쓰는 요청입니다. Instantiate는 채널의 체인코드를 시작하고 초기화하라는 요청입니다. 응용 프로그램 클라이언트는 Peer-to-Peer의 응답을 호출하거나 인스턴스화하고 결과와 보증을 주문, 유효성 검사 및 커밋(ordering, validation, and commit)을 위해 제출된 트랜잭션으로 패키지화합니다.


릴리즈 노트 ( Release Notes )

  • v1.0.0-rc1 June 23, 2017
  • v1.0.0-beta June 8, 2017
    • 버그 수정, 문서화 및 테스트 범위 개선, 사용자 피드백과 다양한 정적 검사 결과 (사용되지 않은 코드, 정적 보안 검사, 맞춤법 검사, linting 등)를 다루는 변경을 기반으로 한 UX 개선.
    • gRPC-go의 최신 버전 (1.4.0의 선구자)으로 업그레이드되었으며 향상된 탄력성을 위해 연결 유지 기능을 구현했습니다.
    • 사용자가 채널 구성 트랜잭션의 내용을 사람이 읽을 수있는 형식으로 변환 할 수있는 새로운 도구가 추가되었습니다.
    • 알려진 취약점 없음
    • 해결된 취약점 없음
    • 알려진 문제점 및 해결 방법 configtx.yaml의 BCCSP 콘텐츠가 제거되었습니다. 이 변경으로 인해 제거 된 BCCSP 컨텐트가 포함 된 configtx.yaml 파일로  도구를 실행할 때 패닉이 발생할 수 있습니다 . 아직 완성되지 않았기 때문에 Java 체인 코드 지원은 1.0.0 이후까지 사용 중지되었습니다. 이 기능은 하이퍼 리더 / 패브릭 저장소를 복제하고, 이 커밋을 되돌리고 자신 만의 포크 (fork)를 빌드 함으로써 실험을 위해 다시 사용할 수 있습니다 .
    • 로그 변경
  • v1.0.0-alpha2
    • v1.0.0 Hyperledger Fabric 프로젝트의 두 번째 알파 릴리스. 이제 코드가 완성되었습니다. 지금부터 v1.0.0 릴리스까지 커뮤니티는 문서 개선, 테스트, 강화, 버그 수정 및 툴링에 중점을 둡니다. 우리는 릴리스 회사가 올라감에 따라 정기적으로 릴리스 후보를 발표 할 예정입니다.
    • 로그 변경
  • v1.0.0-alpha March 16, 2017
    • v1.0.0 Hyperledger Fabric 프로젝트의 첫 번째 알파 릴리스. 이 코드는 개발자가 v1.0 아키텍처를 탐색 할 수 있도록 제공됩니다.
    • 로그 변경
  • v0.6-preview September 16, 2016
    • 릴리스 물류를 사용하고 개발자가 시험해 볼 수있는 기능을 안정화시키기위한 Hyperledger Fabric의 개발자 미리보기 릴리스입니다. 이것은 원래 아키텍처에서 마지막으로 릴리스됩니다. 모든 후속 릴리스는 v1.0 아키텍처에서 제공됩니다.
    • 로그 변경
  • v0.5-developer-preview June 17, 2016
  • 릴리스 물류를 사용하고 개발자가 시험해 볼 수있는 기능을 안정화시키기위한 Hyperledger Fabric의 개발자 미리보기 릴리스입니다.
  • 주요 특징들: 즉각적인 최종성을 가진 허가 된 블록 체인 체인 코드 (일명 스마트 계약) 실행 환경 Docker 컨테이너 (사용자 체인 코드) 피어 (시스템 체인 코드)의 프로세스 내 PBFT, NOOPS (개발 모드), SIEVE (프로토 타입)의 Pluggable Consensus 이벤트 프레임 워크는 사전 정의 된 맞춤 이벤트 클라이언트 SDK (Node.js), 기본 REST API 및 CLI 알려진 주요 버그 및 진행중인 작업
    • 1895 - 잘못된 매개 변수가 지정되면 클라이언트 SDK 인터페이스가 중단 될 수 있습니다.
    • 1901 - 몇 시간의 스트레스 테스트 후 느린 응답
    • 1911 - 클라이언트 SDK에 피어 이벤트 수신기가 없습니다.
    • 889 - TCert의 속성은 암호화되지 않습니다. 이 작품은 아직 진행 중이다.


아직도 질문이 있나요? ( till Have Questions ? )

우리는 다양한 대상에 대한 포괄적 인 문서 세트를 유지하려고합니다. 그러나 우리는 자주 대답하지 않은 질문이 있음을 알고 있습니다. 이 문서에서 설명하지 않은 Hyperledger Fabric 프로젝트와 관련된 기술적 인 질문은 StackOverflow 를 사용하십시오 . 필요한 것을 찾는데 도움이 필요하시면 주저하지 말고 메일링리스트에 편지를 보내 거나 RocketChat(Slack의 대안) 에 대해 문의하십시오 .


상태 ( Status )

이 프로젝트는 Active Hyperledger 프로젝트입니다. 이 프로젝트의 역사에 대한 더 자세한 정보는 Fabric Wiki 페이지를 참조하십시오. Hyperledger Project Lifecycle 문서에서 Active가 수행하는 작업에 대한 정보를 찾을 수 있습니다.


라이센스 ( License )

Hyperledger 프로젝트는 Apache License Version 2.0 소프트웨어 라이센스를 사용합니다.