월간, 블록체인

Ubuntu 기본 환경을 설치하는 스크립트 파일

installBasicUtils.sh : 기본 유틸 설치(build-essential, make, curl, unzip, g++, libtool) installGitClient.sh : Git Client 설치 installGo.sh : Go 언어 설치 및 실행 테스트(버전 1.10) installNodeJS.sh : Node.JS 설치(버전 선택: 8.x / 6.x) installJava.sh : Java 설치(JDK 버전 8) installDocker.sh : Docker & Docker Compose(버전 1.11.2) 설치 installAll.sh : 모든 도구들을 한 번에 설치

Ubuntu Settings 기본 설정

Ubuntu Settings 프로젝트를 다운받기 위해, Git Client를 수동으로 설치하고 프로젝트를 다운로드합니다.

설치 경로는 홈 디렉토리로 설정합니다.

한 번에 모든 도구 설치

모든 도구들을 한 번에 설치

개별적으로 도구 설치

installALL.sh

installBasicUtils.sh

installGitClient.sh

installGo.sh

installNodeJS.sh

installDocker.sh

installJava.sh

본 블로그 중 '[블록체인] 하이퍼레저 > [하이퍼레저] 공식문서 번역본 ' 하위의 포스팅된 글은

하이퍼레저 패브릭 공식 사이트의 ' release-1.1'의 doc  부분을 번역한 자료 입니다.

스터디를 하면서 1차 번역후 포스팅 한 것으로 잘못 번역된 부분이 있습니다.

월간, 블록체인 멤버들이 시간날때 조금씩 짬짬히  번역을 손보고 있으니..

너그러이 이해해주시고..

이점 참고하여 보시기 바랍니다.

또한 포스팅 순서가 목차와 동일하지 않아  이해가 어려울 수 있으므로

아래의 목차를 참조하여 포스팅글을 보시면 하이퍼레저 패브릭 문서를 보시는데 도움이 되시리라 생각합니다.

(아래 목차에 본 블로그의 포스팅과 링크를 걸어두었습니다.)

HyperLedger Fabric Table of Contents

1. Getting Started

• Install Prerequisites
• Install Binaries and Docker Images
• Hyperledger Fabric Samples
• API Documentation
• Hyperledger Fabric SDKs
• Hyperledger Fabric CA

2. Key Concepts

• Introduction
• Hyperledger Fabric Functionalities
• Hyperledger Fabric Model
• Identity
• Membership

• Peers
• Ledger
• Use Cases

3. Tutorials

• Building Your First Network
• Writing Your First Application
• Adding an Org to a Channel
• Upgrading Your Network Components
• Chaincode Tutorials
• Chaincode for Developers
• Chaincode for Operators
• System Chaincode Plugins
• Videos

4. Operations Guides

• Upgrading from v1.0.x
• Updating a Channel Configuration
• Membership Service Providers (MSP)
• Channel Configuration (configtx)
• Endorsement policies
• Error handling
• Logging Control
• Securing Communication With Transport Layer Security (TLS)
• Bringing up a Kafka-based Ordering Service

5. Commands Reference

• peer command
• peer chaincode
• peer channel
• peer version
• peer logging
• peer node
• configtxgen
• configtxlator
• Cryptogen Commands
• Fabric-CA Commands

6. Architecture Reference

• Architecture Explained
• Transaction Flow
• Hyperledger Fabric CA’s User Guide
• Hyperledger Fabric SDKs
• Channels
• Capability Requirements
• CouchDB as the State Database
• Peer channel-based event services
• Read-Write set semantics
• Gossip data dissemination protocol

7. Hyperledger Fabric FAQ

• Endorsement

• Security & Access Control

• Application-side Programming Model

• Chaincode(Smart Contracts and Digital Assets)

• Differences in Most Recent Releases

8. Ordering Service FAQ

• General

• Solo

• Kafka
• BFT
 

9. Contributions Welcome!

10.Glossary

Fabric CA User’s Guide

Hyperledger 요구 사항 WG는 많은 블록 체인 사용 사례를 문서화하고 여기 에 인벤토리를 유지 관리합니다 .

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/usecases.html

원장

원장 (ledger)은 모든 State 전이에 대해 순서를 변경하고 변조를 방지하는 기록입니다. State 전이는 참여 당사자가 제출 한 체인 코드 호출 ( "트랜잭션")의 결과입니다. 각 트랜잭션은 생성, 갱신 또는 삭제와 같이 원장에게 커밋되는 일련의 자산 키 - 값 쌍을 생성합니다.

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

체인

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

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

State Database 

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

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

State 데이터베이스 옵션에는 LevelDB 및 CouchDB가 포함됩니다. LevelDB는 피어 프로세스에 포함 된 기본 State 데이터베이스이며 키 코드 값 쌍으로 체인 코드 데이터를 저장합니다. CouchDB는 체인 코드 데이터를 JSON으로 모델링 할 때 추가 쿼리 지원을 제공하는 선택적 대체 외부 State 데이터베이스로서 JSON 컨텐트에 대한 풍부한 쿼리를 허용합니다. 참조) State 데이터베이스로 CouchDB를을 CouchDB를에 대한 자세한 정보를 얻을 수 있습니다.

Transaction흐름

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

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

committal 전에 동료는 트랜잭션을 확인합니다. 먼저 지정된 피어의 정확한 할당이 결과에 서명하고 트랜잭션 payload에 대해 서명을 인증하는지 확인하기 위해 Endorsement Policy을 확인합니다.

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

참고 항목 트랜잭션 흐름 , 세트 의미를 읽기 - 쓰기 및 국가 데이터베이스로 CouchDB를 트랜잭션구조, 동시성 제어 및 State DB에 깊은 다이빙에 대한 항목을 참조하십시오.

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

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

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

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

전문 용어

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

원장 및 체인 코드

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

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

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

복수 원장

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

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

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

다중 Chain Code

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

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

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

어플리케이션 및 피어

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

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

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

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

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

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

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

피어 및 채널

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

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

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

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

피어 및 조직

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

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

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

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

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

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

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

피어 및 신원

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

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

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

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

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

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

피어 및 Orderer

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

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

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

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

1 단계 : 제안

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

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

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

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

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

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

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

2 단계 : 포장

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

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

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

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

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

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

2 단계가 끝나면 Orderere는 제안 된 트랜잭션 업데이트를 수집하고 순서정렬하고,이를 블록으로 포장하여 배포 할 수있는 간단하지만 중요한 프로세스에 책임이 있음을 확인합니다.

3 단계 : 유효성 검사

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

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

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

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

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

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

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

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

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

Orderer 및 합의

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

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

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

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/peers/peers.html

만약 지난 Identity 문서를 읽으셨다면, PKI가 어떻게 인증가능한 Identity를 신뢰 사슬을 통해 제공하는지 배우셨을 겁니다.

이제, 이러한 Identity가 어떻게 블록체이 네트워크 내부의 신뢰 받는 사용자로서 나타나 지기위해서 사용될 수 있는지에 대해서 배워보시겠습니다.

이 곳이 Membership Service Provider(MSP)가 활동은 시작하는 영역입니다. MSP는 어떤 루트 CA나 중간 CA가 신뢰 도메인의 사용자를 정의하기 위해서 신뢰받고 있는지를 구별해냅니다.

MSP는 사용자 identity 목록을 만듦으로서 또는 어떤 CA가 사용자의 유효한 Identity에 발급 권한이 있음을 앎으로서 , 또는 가장 일반적인 케이스일 경우 둘의 조합으로 구별해냅니다.

MSP의 힘은 누가 네트워크 참여자인지 또는 채널의 사용자 인지에 대한 단순한 목록을 만드는 정도는 뛰어넘습니다.

MSP는 일정 범위 안에서 또는 MSP가 대표하는 조직(트러스트 도메인)(예 : MSP 관리자, 조직 하위 구성원)에서 액터가 역할을 수행 할 수도 있는 특별한 역할을 식별할 수 있습니다.

그리고 또한 MSP는 네트워크나 채널 문맥 속에 접근 권한을 규정하기 위한 기반을 구성합니다.(예: 채널 관리자, 독자, 작가)

MSP의 설정은 모든 채널에 알려지고, 이 알려진 채널은 해당하는 조직에 참여하는 사용자입니다.(channel MSP의 형태로)

피어, Orderer, 클라이언트는 또한 채널 밖의 문맥에서 조직 구성원의 메시지를 인증하기 위해서 로컬 MSP 인스턴스를 유지합니다.(ILocal MSP로 알려진)

게다가, MSP는 이미 폐지된 Identity의 목록 인증을 허가합니다.(우리는 Identity 문서에서 이미 다루었지만, 이 프로세스가 어떻게 MSP로 넓혀지는지를 설명하겠습니다.)

우리는 로컬 그리고 채널 MSP에 대해서 잠시동안 조금 더 많은 내용을 설명하겠습니다. 지금부터 일반적인 상황에 MSP가 작동하는지를 설명하겠습니다.

MSP를 조직에 연결하기

조직은 구성원의 관리된 그룹이고, 다국적 기업에서 작은 꽃집까지 될 수 있는 하나의 그룹입니다.

조직에서 가장 중요한 것은 단일 MSP 이하의 구성원을 관리합니다.

이것은 우리가 나중에 설명할 X.509 인증 안에서의 조직 개념과는 다르다는 것을 주의하셔야 됩니다.

조직과 그 조직의 MSP 사이의 배타적인 관계는 조직 이후의 MSP의 이름 짓는 것을 더욱 민감하게 만듭니다.

여러분은 대부분의 정책 설정 안에 관습을 찾으실 수 있을 것입니다. 예를 들자면, 조직 org1은 MSP에선 org1-msp로 불리울 수 있습니다.

몇몇 경우에 조직은 다양한 멤버십 그룹을 요구할 수 있습니다. 예를 들면, 채널이 매우 다르게 다양한 멤버십 그룹에 요구하는 것과 같습니다.

이러한 경우에 다양한 MSP를 가지는 것이 일리가 있고, 그들을 각각 ORG2-MSP-NATIONAL, ORG2-MSP-GOVERNMENT와 같이

ORG2 안에 각각 다른 신뢰 멤버십 루트를 National 판매량 채널과 Govenment 규제 채널로 나누어 반영하는 하는 것은 일리가 있습니다.

조직을 위한 두 개의 다른 MSP 입니다. 첫 번째 설정은 MSP와 조직의 전형적인 관계를 보여줍니다. 단일 MSP는 조직 구성원의 리스트를 정의합니다.

두 번째 설정은, 각기 다른 MSP가 national, international, government 소속 조직적인 그룹을 대표하는 것에 사용됩니다.

조직적인 단위와 MSP

조직은 때론 여러 조직 단위(Organizational Unit; OU)로 나뉘며 각 조직 단위에는 특정한 책임에 대한 집합이 있습니다.

예를 들자면, ORG1 조직에서 이러한 개별 영업 방침을 반영하기 위해 조직 단위 ORG1-MANUFACTURER과 ORG1-DISTRIBUTION 조직 단위를 둘 수 있습니다.

CA가 X.509 인증을 발급하면, ou라는 인증서의 필드는 ID가 속한 사업부를 지정하게 됩니다.

OU가 블록체인 네트워크의 구성원으로 간주되는 조직의 부분을 제어하는 것에 있어서 어떤 방식으로 도움이 되는 지 차후에 알 수 있습니다.

예를 들어 ORG1-MANUFACTURING 조직 단위의 ID만 채널에 접근 할 수 있지만 ORG1-DISTRIBUTION은 채널에 접근할 수 없습니다.

마지막으로 조직 단위의 약간의 잘못된 사용일 수 있지만 컨소시엄으로 서로 다른 조직에서 서로를 구별하기 위해서 사용 할 수 있습니다.

이러한 경우에 서로 다른 조직에서는 신뢰 루트에 대해 동일한 루트 CA와 중간 CA를 사용하지만 OU의 각각 조직원의 구성원을 식별할 수 있도록 필드를 적절하게 할당합니다.

차후엔 이를 달성하기 위한 MSP 구성 방법도 알아보겠습니다.

로컬 및 채널 MSP

MSP는 채널 구성 ( 채널 MSP )과 배우의 전제 ( 로컬 MSP ) 의 로컬에서 Blockchain 네트워크의 두 위치에 나타납니다 . 노드 (피어 또는 발주자) 및 사용자 (SDK를 사용하는 CLI 또는 클라이언트 응용 프로그램을 사용하는 관리자 )에 대해 정의 된 로컬 MSP 모든 노드와 사용자는 로컬 MSP를 정의해야합니다 . 그 수준에서 관리 권한이나 참여 권한을 가진 사람과 채널 컨텍스트 (예 : 동료 조직의 관리자)를 정의합니다.

대조적으로 채널 MSP는 채널 수준에서 관리 및 참여 권한을 정의합니다 . 채널에 참여하는 모든 조직은 정의 된 MSP가 있어야합니다. 채널의 피어 및 Orderer는 모두 채널 MSP에서 동일한보기를 공유하므로 채널 참여자를 올바르게 인증 할 수 있습니다. 즉, 조직이 채널에 가입하고자하는 경우 조직 구성원에 대한 신뢰 체인을 포함하는 MSP를 채널 구성에 포함시켜야합니다. 그렇지 않으면이 조직의 신원에서 비롯된 트랜잭션이 거부됩니다.

여기에서 로컬 및 채널 MSP 간의 주요 차이점은 어떻게 작동하는지가 아니라 해당 범위 입니다.

로컬 및 채널 MSP. 각 피어의 신뢰 도메인 (예 : 조직)은 피어의 로컬 MSP (예 : ORG1 또는 ORG2)에 의해 정의됩니다. 채널에서 조직의 대표는 조직의 MSP를 채널에 포함시킴으로써 성취됩니다. 예를 들어,이 그림의 채널은 ORG1과 ORG2에 의해 관리됩니다. 비슷한 원리가 네트워크, Orderer및 사용자에게 적용되지만, 여기서는 설명의 편의를 위해 여기에 표시되지 않습니다.

로컬 MSP는 적용 대상 노드 또는 사용자의 파일 시스템에서만 정의 됩니다. 따라서 물리적 및 논리적으로 노드 나 사용자별로 하나의 로컬 MSP 만 있습니다. 그러나 채널 MSP는 채널의 모든 노드에서 사용할 수 있으므로 구성시 채널에 한 번 논리적으로 정의됩니다. 그러나 채널 MSP는 채널의 모든 노드의 파일 시스템에서 인스턴스화되고 컨센서스를 통해 동기화 된 State로 유지됩니다 . 따라서 각 노드의 로컬 파일 시스템에 각 채널 MSP의 사본이있는 반면, 논리적으로 채널 MSP는 채널이나 네트워크에 상주하며 유지 관리됩니다.

위 그림에서와 같이 블록 체인 관리자가 스마트 계약을 설치하고 인스턴스화 할 때 발생하는 상황을 확인하여 로컬 및 채널 MSP를 사용하는 방법을 확인하는 것이 도움이 될 수 있습니다 .

관리자 B는 RCA1에 자신의 로컬 MSP에 의해 발행되고 저장된 ID로 피어에 연결합니다 . 때 B는 피어에 스마트 계약을 설치하려고, 피어는 로컬 MSP를 확인 ORG1-MSP의 신원을 확인하기 위해, B는 ORG1의 진정한 구성원입니다. 성공적으로 확인하면 설치 명령이 성공적으로 완료됩니다. 이어서 B는 채널에서 스마트 계약을 인스턴스화하려고합니다. 이는 채널 운영이므로 채널의 모든 조직이 동의해야합니다. 따라서 피어는이 명령을 성공적으로 커밋하기 전에 채널의 MSP를 확인해야합니다. (다른 일도 일어나야하지만 지금은 위에 집중해야합니다.)

채널 자체가 논리적 구성인 것처럼 채널 MSP를 관찰 할 수 있습니다 . 채널 org 동료의 로컬 파일 시스템에서 인스턴스화되고 관리되는 경우에만 물리적으로됩니다.

MSP 수준

채널 및 로컬 MSP 사이의 분리는 피어 또는 발주자 노드와 같은 로컬 리소스 및 채널 또는 네트워크 수준에서 작동하는 원장, 스마트 계약 및 컨소시엄과 같은 채널 리소스를 관리하는 조직의 요구를 반영합니다. 그것은 다른에있는 이러한 MSP를 생각하는 것이 도움이 수준 으로, 네트워크 관리 문제에 관한 높은 수준에서 MSP를 하면서 민간 자원의 관리를위한 낮은 수준의 핸들 정체성에 MSP가 . MSP는 모든 관리 수준에서 필수적입니다. 즉, 네트워크, 채널, 피어, Orderer 및 사용자에 대해 정의해야합니다.

MSP 레벨. 피어 및 발주자에 대한 MSP는 로컬이며, 채널의 MSP (네트워크 구성 채널 포함)는 해당 채널의 모든 참가자에게 공유됩니다. 이 그림에서 네트워크 구성 채널은 ORG1에 의해 관리되지만 다른 응용 프로그램 채널은 ORG1 및 ORG2에 의해 관리 될 수 있습니다. 피어는 ORG2의 구성원이며 ORG2가 관리하지만 ORG1은 그림의 순서를 관리합니다. ORG1은 RCA1의 신원을 신뢰하지만 ORG2는 RCA2의 신원을 신뢰합니다. 이들은 관리 구성표로서 누가 이러한 구성 요소를 관리 할 수 ​​있는지 반영합니다. 따라서 ORG1이 네트워크를 관리하는 동안 ORG2.MSP는 네트워크 정의에 존재합니다.

• 네트워크 MSP : 네트워크 의 구성은 참가자 조직 MSP를 정의하여 네트워크의 구성원과 관리 작업 (예 : 채널 만들기)을 수행 할 권한이있는 구성원을 정의합니다.
• 채널 MSP : 채널에서 회원의 MSP를 별도로 유지 관리하는 것이 중요합니다. 채널은 조직의 특정 집합간에 사적인 통신을 제공하며 차례로 관리를 제어합니다. 채널의 MSP와 관련하여 해석되는 채널 정책은 채널에 대한 특정 작업 (예 : 조직 추가 또는 체인 코드 인스턴스 생성)에 참여할 수있는 권한을 가진 사용자를 정의합니다. 채널을 관리 할 수있는 권한과 네트워크 구성 채널 (또는 다른 채널)을 관리 할 수있는 권한 간에는 필요한 관계가 없습니다. 관리 권한은 관리 대상 범위 내에 존재합니다 (규칙이 다르게 작성되지 않은 경우 - ROLE아래 속성 에 대한 설명 참조).
• 피어 MSP : 이 로컬 MSP는 각 피어의 파일 시스템에 정의되며 각 피어에 대해 단일 MSP 인스턴스가 있습니다. 개념적으로 채널 MSP와 정확히 동일한 기능을 수행하지만, 정의 된 피어에만 적용된다는 제한이 있습니다. 피어의 로컬 MSP를 사용하여 권한 부여를 평가하는 작업의 예는 피어 전제에 체인 코드를 설치하는 것입니다.
• 발주자 MSP : 피어 MSP와 마찬가지로 발주자 로컬 MSP도 노드의 파일 시스템에 정의되어 있으며 해당 노드에만 적용됩니다. 피어 노드와 마찬가지로 Orderer는 단일 조직에서 소유하므로 신뢰할 수있는 액터 또는 노드를 나열하는 단일 MSP가 있습니다.

MSP 구조

지금까지 MSP의 가장 중요한 두 요소는 해당 조직에서 액터 또는 노드의 구성원을 설정하는 데 사용 된 (루트 또는 중간) CA의 사양입니다. 그러나 멤버십 기능을 보조하기 위해이 두 가지 요소와 함께 사용되는 요소가 더 많습니다.

위의 그림은 로컬 MSP가 로컬 파일 시스템에 저장되는 방법을 보여줍니다. 비록 채널 MSP가 정확히 이런 방식으로 물리적으로 구조화되어 있지는 않지만, 그것들에 대해서 생각하는 것은 여전히 ​​유용한 방법입니다.

보시다시피 MSP에는 9 가지 요소가 있습니다. MSP 이름이 MSP 구성의 다른 요소를 나타내는 각 하위 폴더와 함께 루트 폴더 이름 인 디렉터리 구조에서 이러한 요소를 생각하는 것이 가장 쉽습니다.

이 폴더에 대해 좀 더 자세하게 설명하고 중요한 이유를 알아 보겠습니다.

• 루트 CA : 이 폴더는이 MSP가 나타내는 조직에서 신뢰하는 루트 CA의 자체 서명 된 X.509 인증서 목록을 포함합니다. 이 MSP 폴더에는 적어도 하나의 루트 CA X.509 인증서가 있어야합니다. 이는 다른 모든 인증서를 파생시켜 해당 조직의 구성원으로 간주해야하는 CA를 식별하기 때문에 가장 중요한 폴더입니다.

• 중간 CA : 이 폴더는이 조직에서 신뢰하는 중간 CA의 X.509 인증서 목록을 포함합니다. 각 인증서는 MSP의 루트 CA 중 하나 또는 서명 된 CA 체인이 궁극적으로 신뢰할 수있는 루트 CA로 연결되는 중간 CA에 의해 서명되어야합니다. 직간접 적으로 해당 조직의 구조와 관련하여 중간 CA를 사용하는 경우 중간 CA는 조직의 다른 하위 또는 조직 자체를 나타낼 수 있습니다 (예 : 상업용 CA가 조직의 ID 관리에 사용되는 경우). 후자의 경우, CA 계층 구조에서 더 낮은 다른 중간 CA를 사용하여 조직 세목을 나타낼 수 있습니다. 여기 에서 MSP 구성에 대한 모범 사례에 대한 자세한 정보를 찾을 수 있습니다. 중개 CA가없는 작동하는 네트워크를 가질 수 있으며이 경우이 폴더는 비어있을 수 있습니다. 루트 CA 폴더와 마찬가지로이 폴더는 조직의 구성원으로 간주되도록 인증서를 발급해야하는 CA를 정의합니다.

• 조직 구성 단위 (OU) : $Fabric_CFG_PATH/msp/config.yaml 디렉토리에 나열되며 조직 구성 단위 목록을 포함합니다. 구성 단위 목록은이 MSP가 대표하는 조직의 구성원으로 간주됩니다. 이는 조직의 구성원을 특정 OU가있는 ID (MSP 지정 CA 중 하나가 서명 한 ID)가있는 조직 구성원으로 제한하려는 경우에 특히 유용합니다. OU를 지정하는 것은 선택 사항입니다. OU가 목록에 없으면 루트 CA 및 중간 CA 폴더로 식별되는 MSP의 일부인 모든 ID가 조직의 구성원으로 간주됩니다.

• 관리자 : 이 폴더는이 조직의 관리자 역할을 맡은 액터를 정의하는 ID 목록을 포함합니다. 표준 MSP 유형의 경우이 목록에 하나 이상의 X.509 인증서가 있어야합니다. 액터가 관리자의 역할을한다고해서 특정 리소스를 관리 할 수있는 것은 아닙니다. 시스템 관리와 ​​관련하여 주어진 신원이 갖는 실제 권한은 시스템 자원을 관리하는 정책에 의해 결정됩니다. 예를 들어, 채널 정책은 ORG1-MANUFACTURING 관리자 에게 채널 에 새 조직을 추가 할 수있는 권한이 있음을 관리자가 지정할 수있는 권한을 지정할 수 있습니다 ORG1-DISTRIBUTION. X.509 인증서에는 ROLE속성 (예 : 액터가 지정되어 있음 admin)이 있지만 이는 블록 체인 네트워크가 아니라 조직 내에서 액터의 역할을 나타냅니다. 이것은 OU속성 의 목적과 유사합니다. 정의 된 경우 속성은 조직의 액터의 위치를 ​​나타냅니다. ROLE속성은 수 채널에 대한 정책 (예 : 인스턴스 chaincode 같은) 특정 채널 기능을 수행하는 조직 (또는 특정 조직) 권한에서 모든 관리자를 할 수 있도록 작성되어있는 경우 채널 수준에서 관리 권한을 부여하는 데 사용. 이러한 방식으로 조직 역할이 네트워크 역할을 부여 할 수 있습니다. 이것은 미국 플로리다 주에서 발행 한 운전 면허증을 소지 한 사람이 미국의 모든 주에서 운전할 수있는 권리를 갖는 것과 개념적으로 유사합니다.

• 해지 된 인증서 : 액터의 신원이 취소 된 경우 ID 자체가 아닌 신원에 관한 정보를 식별하는이 폴더에 보관됩니다. X.509 기반 ID의 경우 이러한 식별자는 SKI (Subject Key Identifier) ​​및 AKI (Authority Access Identifier)로 알려진 문자열 쌍이며 X.509 인증서를 사용하여 인증서가 없는지 확인 될 때마다 확인됩니다 취소됨. 이 목록은 개념적으로 CA의 인증서 해지 목록 (CRL)과 동일하지만 조직의 구성원 자격 해지와 관련이 있습니다. 결과적으로 로컬 또는 채널의 MSP 관리자는 CA의 업데이트 된 CRL을 발급 한 취소 인증서를 광고함으로써 조직에서 배우 또는 노드를 신속하게 취소 할 수 있습니다. 이 "목록 목록"은 선택 사항입니다. 인증서가 폐기되면서 만 채워집니다.

• 노드 신원 : 이 폴더에는 노드의 신원, 즉 KeyStore의 내용과 결합하여 노드가 채널 및 네트워크의 다른 참가자에게 보내는 메시지에서 자신을 인증 할 수있게하는 암호 자료가 들어 있습니다. X.509 기반 ID의 경우이 폴더에는 X.509 인증서 가 포함되어 있습니다 . 이것은 피어가 트랜잭션 제안 응답에 포함시키는 인증서입니다 (예 : 피어가이를 보증했음을 나타 내기 위해). 이후 검증 시간에 결과 트랜잭션의 endorsement policy에 대해 확인할 수 있습니다. 이 폴더는 로컬 MSP에는 필수 항목이며 노드에 정확히 하나의 X.509 인증서가 있어야합니다. 채널 MSP에는 사용되지 않습니다.

• 개인 키용 키 저장소 : 이 폴더는 피어 또는 발주자 노드 (또는 클라이언트의 로컬 MSP)의 로컬 MSP에 대해 정의되며 노드의 서명 키를 포함합니다 . 이 키는 Node Identity 폴더에 포함 된 노드의 ID와 암호 학적으로 일치하며 데이터 서명에 사용됩니다. 예를 들어 승인 단계의 일부로 트랜잭션 제안 응답에 서명하는 데 사용됩니다. 이 폴더는 로컬 MSP에는 필수 항목이며 정확하게 하나의 개인 키가 있어야합니다. 분명히이 폴더에 대한 액세스는 피어에 대한 관리 책임이있는 사용자 인 아이디로만 제한되어야합니다. 채널 MSP의 구성에는 채널 MSP 가 서명 확인 기능이 아닌 신원 확인 기능 만 제공하기 때문에이 부분은 포함되지 않습니다.

• TLS 루트 CA : 이 폴더는 TLS 통신 을 위해이 조직 에서 트러스트 된 루트 CA의 자체 서명 된 X.509 인증서 목록을 포함합니다 . TLS 통신의 예로는 피어가 원장 업데이트를받을 수 있도록 Orderer에게 연결해야 할 때입니다. MSP TLS 정보는 네트워크를 사용하는 노드 (응용 프로그램 및 관리자)가 아닌 네트워크 내부의 노드 (예 : 동료 및 Orderer)와 관련이 있습니다. 이 폴더에는 하나 이상의 TLS 루트 CA X.509 인증서가 있어야합니다.

• TLS 중간 CA : 이 폴더에는 TLS 통신 을 위해이 MSP가 나타내는 조직에서 신뢰하는 중간 CA 인증서 CA 목록이 들어 있습니다 . 이 폴더는 상용 CA가 조직의 TLS 인증서에 사용될 때 특히 유용합니다. 멤버쉽 중간 CA와 마찬가지로 중간 TLS CA를 지정하는 것은 선택 사항입니다. TLS에 대한 자세한 내용은 여기를 클릭 하십시오 .

이 문서와 Identity 에 관한 문서를 읽은 경우 , Hyperledger Fabric에서 ID와 멤버십이 어떻게 작동하는지 꽤 잘 이해해야합니다. PKI와 MSP를 사용하여 블록 체인 네트워크에서 협력하는 액터를 식별하는 방법을 살펴 보았습니다. MSP가 물리적 및 논리적으로 구조화 된 방법 외에도 인증서, 공용 / 개인 키 및 신뢰의 뿌리가 어떻게 작동 하는지를 배웠습니다.

출처 : https://hyperledger-fabric.readthedocs.io/en/release-1.1/membership/membership.html

Bringing up a Kafka-based Ordering Service

Caveat emptor

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

Big picture

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

Steps

K와 Z 를 Kafka 클러스터와 ZooKeeper 앙상블의 노드 수로 각각 설정합니다. :

1. K는 최소한 4로 설정해야합니다 (아래 4 단계에서 설명 하겠지만, 이것은 고장 내결함성을 나타내기 위해 필요한 노드의 최소 수입니다. 즉, 4 개의 브로커를 사용하면 1 개의 브로커가 다운 될 수 있습니다. 채널은 계속해서 쓰기 및 읽기가 가능하며 새로운 채널을 만들 수 있습니다.)
2. Z는 3, 5 또는 7 중 하나입니다. 스플릿 브레이브 시나리오를 피하기 위해서는 홀수이어야하며 단일 실패 지점을 피하려면 1보다 커야합니다. 7 개의 ZooKeeper 서버를 초과하는 것은 과잉으로 간주됩니다.

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

1. Orderer : 네트워크의 기원 블록(genesis block)에 카프카 관련 정보를 암호화하십시오. configtxgen을 사용중인 경우 configtx.yaml을 편집하거나 시스템 채널의 기원 블록(genesis block)에 대한 사전 설정된 프로필을 선택하여 다음과 같이하십시오.
   1. Orderer.OrdererType은 kafka로 설정됩니다.
   2. Orderer.Kafka.Brokers에는 클러스터에 있는 두 개 이상의 Kafka 중개인의 주소가 IP:port으로 들어있습니다. 이 목록은 완전 할 필요는 없습니다. (이들은 부트 스트랩 브로커입니다.)
2. Orderers : 최대 블록 크기를 설정하십시오. 각 블록에는 대부분 Orderer.AbsoluteMaxBytes 바이트(헤더 제외)가 있으며 configtx.yaml에 설정할 수 있습니다. 여기에서 선택한 값을 A로 지정하고 기록해 두십시오 - 6 단계에서 Kafka 중개인을 구성하는 방법에 영향을 줍니다.
3. Orderers : 기원 블록(genesis block)을 만듭니다. configtxgen을 사용합니다. 위의 3 단계와 4 단계에서 선택한 설정은 시스템 전체의 설정입니다. 즉, 모든 OSN에 대해 네트워크 전체에 적용됩니다. 기원 블록(genesis block)의 위치를 ​​기록하십시오.
4. Kafka 클러스터 : Kafka brokers를 적절하게 구성하십시오. 모든 카프카 중개인은 다음과 같은 키를 구성해야합니다.
   1. unclean.leader.election.enable = false - 데이터 일관성은 블록 체인 환경에서 핵심입니다. 동기화된 복제 세트 외부에서 채널 리더를 선택할 수 없거나 이전 리더가 생성한 오프셋을 덮어 쓸 위험이 있습니다. 결과적으로 orderer가 생산하는 블록 체인을 다시 작성합니다.
   2. min.insync.replicas = M -  1 < M < N와 같은 M 값을 선택하십시오(아래 default.replication.factor 참조). 데이터는 최소한 M개의 복제본에 기록 될 때 커밋된 것으로 간주됩니다 (동기화 후 동기화 된 것으로 간주되고 동기화 된 복제 집합 또는 ISR에 속함). 다른 경우, 쓰기 조작은 오류를 리턴합니다. 그때:
      1. 채널 데이터가 기록되는 N개까지의 N-M 복제본을 사용할 수 없게 되면 작업이 정상적으로 진행됩니다.
      2. 더 많은 복제본을 사용할 수 없게 되면 Kafka는 M의 ISR 집합을 유지할 수 없으므로 쓰기 허용을 중지합니다. 문제없이 작업을 읽습니다. 채널은 M개의 복제본이 동기화 될 때 채널에 다시 쓸 수 있게 됩니다.
   3. default.replication.factor = N - 여기서 N < K인 값 N을 선택합니다. N의 복제 인수는 각 채널이 N개의 브로커에 복제된 데이터를 갖게됨을 의미합니다. 이들은 채널의 ISR 세트 후보입니다. 위의 min.insync.replicas section에서 언급했듯이 모든 브로커가 항상 사용 가능해야하는 것은 아닙니다.  N 브로커보다 적으면 채널 생성을 진행할 수 없으므로 N을 K보다 반드시 작게 설정해야합니다. 따라서 N = K로 설정하는 경우 단일 브로커가 중단된다는 것은 블록 체인 네트워크에 새로운 채널을 만들 수 없다는 것을 의미합니다. ordering 서비스의 오류 방지 기능은 존재하지 않습니다. 위에서 설명한 것을 바탕으로, M과 N의 최소 허용 값은 각각 2, 3입니다. 이 구성은 앞으로 나아갈 새로운 채널을 생성하고 모든 채널이 계속 쓰기 가능하도록 합니다.
   4. message.max.bytes 및 replica.fetch.max.bytes는 위의 4단계의 Orderer.AbsoluteMaxBytes에서 선택한 A 값보다 큰 값으로 설정되어야합니다. 헤더를 설명할 버퍼를 추가하십시오. 1 MiB가 충분합니다. 다음 조건이 적용됩니다. : Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes  (완전성을 위해 message.max.bytes는 기본적으로 100 MiB로 설정되는 socket.request.max.bytes 값보다 작아야 하며, 100 MiB보다 큰 블록을 사용하려면 fabric/orderer/kafka/config.go에 있는 brokerConfig.Producer.MaxMessageBytes의 하드 코딩된 값을 수정하고 소스에서 이진 파일을 다시 작성해야 합니다. 이것은 권장되지 않습니다.)
   5. log.retention.ms = -1. ordering 서비스가 Kafka 로그의 가지 치기에 대한 지원을 추가 할 때까지는 시간 기반 보존을 비활성화하고 세그먼트가 만료되지 않도록해야합니다. (크기 기반 보존 - log.retention.bytes -는 본문 작성 시점에 Kafka에서는 기본적으로 비활성화되어 있으므로 명시적으로 설정할 필요가 없습니다.)
5. Orderers : 각 OSN을 기원 블록(genesis block)으로 향하게 하십시오. General.GenesisFile을 orderer.yaml에서 편집하여 위의 5 단계에서 생성된 기원 블록(genesis block)을 가리키도록 합니다. (그 동안 YAML 파일의 다른 모든 키가 적절하게 설정되었는지 확인하십시오.)
6. Orderers : 폴링 간격 및 타임 아웃을 조정합니다. (선택 단계.)
   1. orderer.yaml 파일의 Kafka.Retry 섹션을 사용하여 메타 데이터/제작자/고객 요청의 빈도와 소켓 시간 초과를 조정할 수 있습니다. (이들은 Kafka 제작자 또는 소비자에게 기대되는 모든 설정입니다.)
   2. 또한 새 채널이 생성되거나 기존 채널이 다시 로드 될 때 (orderer가 방금 다시 시작된 경우) orderer는 다음과 같은 방법으로 Kafka 클러스터와 상호 작용합니다.
      1. 채널에 해당하는 Kafka 파티션을위한 Kafka 제작자 (작성자)를 만듭니다.
      2. 해당 생성자를 사용하여 해당 파티션에 no-op CONNECT 메시지를 게시 합니다.
      3. 해당 파티션에 대한 Kafka 소비자 (판독기)를 만듭니다. 이러한 단계 중 하나라도 실패하면 반복되는 빈도를 조정할 수 있습니다. 구체적으로 그들은 Kafka.Retry.ShortInterval의 총합을 위해 Kafka.Retry.ShortInterval마다 다시 시도될 것이며, Kafka.Retry.LongInterval을 성공할 때까지 Kafka.Retry.LongTotal의 총합을 구하기 재시도합니다. 위의 모든 단계가 성공적으로 완료 될 때까지 orderer는 채널에 쓰거나 채널에서 읽을 수 없습니다.
7. SSL을 통해 통신할 수 있도록 OSN 및 Kafka 클러스터를 설정합니다. (옵션 단계이지만 적극 추천합니다.) 방정식의 Kafka 클러스터 측면에 대해서는 Confluent 가이드 문서를 참조하고 그에 따라 모든 OSN에서 Kafka.TLS의 키를 orderer.yaml로 설정하십시오.
8. ZooKeeper 앙상블, Kafka 클러스터, ordering 서비스 노드 순서로 노드를 가져옵니다.

Additional considerations

1. 기본 메시지 크기. 위의 4 단계 (Steps 섹션 참조)에서 Orderer.Batchsize.PreferredMaxBytes 키를 설정하여 원하는 블록 크기를 설정할 수도 있습니다. 상대적으로 작은 메시지를 처리 ​​할 때 Kafka는 높은 처리량을 제공합니다. 1 MiB보다 크지 않은 값을 목표로 삼는다.
2. 환경 변수를 사용하여 설정을 무시합니다. Fabric과 함께 제공되는 샘플 Kafka 및 Zookeeper Docker 이미지 (images/kafka 및 images/zookeeper 참조)를 사용하는 경우, 환경 변수를 사용하여 Kafka 브로커 또는 ZooKeeper 서버의 설정을 무시할 수 있습니다. 구성 키의 점을 밑줄로 바꾸십시오 - 예를 들어 KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false를 지정하면 unclean.leader.election.enable의 기본값을 무시할 수 있습니다. 로컬 구성에 대한 OSN에도 동일하게 적용됩니다 ( 즉, orderer.yaml에서 설정할 수 있는 항목). 예를 들어 ORDERER_KAFKA_RETRY_SHORTINTERVAL=1s이면 Orderer.Kafka.Retry.ShortInterval의 기본값을 재정의할 수 있습니다.

Kafka Protocol Version Compatibility

패브릭은 sarama 클라이언트 라이브러리와 공급 업체를 사용하여 Kafka 0.10에서 1.0까지 지원하지만 아직 이전 버전에서 작동하는 것으로 알려져 있습니다.

orderer.yaml의 Kafka.Version 키를 사용하여 Kafka 클러스터의 브로커와 통신하는 데 사용되는 Kafka 프로토콜 버전을 구성할 수 있습니다. Kafka 브로커는 이전 버전의 프로토콜과 역 호환됩니다. Kafka 브로커의 이전 프로토콜 버전과의 이전 호환성으로 인해 Kafka 브로커를 새 버전으로 업그레이드하는 경우 Kafka.Version 키 값을 업데이트할 필요는 없지만 Kafka 클러스터는 이전 프로토콜 버전을 사용하는 동안 성능이 저하 될 수 있습니다.

Debugging

General.LogLevel을 DEBUG로 설정하고 orderer.yaml의 Kafka.Verbose를 true로 설정합니다.

Example

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

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/kafka.html

Securing Communication With Transport Layer Security (TLS)

패브릭은 TLS를 사용하는 노드 간의 보안 통신을 지원합니다. TLS 통신은 단방향 (서버 만) 및 양방향 (서버 및 클라이언트) 인증을 모두 사용할 수 있습니다.

Configuring TLS for peers nodes

피어 노드는 TLS 서버와 TLS 클라이언트입니다. 다른 피어 노드, 응용 프로그램 또는 CLI가 다른 피어 노드 또는 Orderer와 연결될 때 다른 피어 노드, 응용 프로그램 또는 CLI가 이 노드에 연결하고 후자를 피어 노드로 연결하면 전자가 됩니다.

피어 노드에서 TLS를 사용하도록 설정하려면 다음 피어 구성 속성을 설정하십시오.

• peer.tls.enabled = true
• peer.tls.cert.file = TLS 서버 인증서가 포함 된 파일의 정규화 된 경로
• peer.tls.key.file = TLS 서버 개인 키가 들어있는 파일의 정규화 된 경로
• peer.tls.rootcert.file = TLS 서버 인증서를 발급한 인증 기관(CA)의 인증서 체인을 포함하는 파일의 정규화 된 경로

기본적으로 TLS 클라이언트 인증은 피어 노드에서 TLS를 사용하도록 설정하면 해제됩니다. 즉, 피어 노드는 TLS 핸드 셰이크 중에 클라이언트 (다른 ​​피어 노드, 응용 프로그램 또는 CLI)의 인증서를 확인하지 않습니다. 피어 노드에서 TLS 클라이언트 인증을 사용하려면 피어 구성 속성 peer.tls.clientAuthRequired를 true로 설정하고 peer.tls.clientRootCAs.files 속성을 조직의 클라이언트에 대해 TLS 인증서를 발급한 CA 인증서 체인이 포함 된 CA 체인 파일로 설정합니다.

기본적으로 피어 노드는 TLS 서버 및 클라이언트로 작동 할 때 동일한 인증서 및 개인 키 쌍을 사용합니다. 클라이언트 측에 대해 다른 인증서와 개인 키 쌍을 사용하려면 peer.tls.clientCert.file 및 peer.tls.clientKey.file 구성 등록 정보를 각각 클라이언트 인증서와 키 파일의 정규화된 경로로 설정하십시오.

클라이언트 인증을 사용하는 TLS는 다음 환경 변수를 설정하여 활성화 할 수도 있습니다.

• CORE_PEER_TLS_ENABLED = true
• CORE_PEER_TLS_CERT_FILE = 서버 인증서의 정규화 된 경로
• CORE_PEER_TLS_KEY_FILE = 서버 개인 키의 정규화 된 경로
• CORE_PEER_TLS_ROOTCERT_FILE = CA 체인 파일의 정규화 된 경로
• CORE_PEER_TLS_CLIENTAUTHREQUIRED = true
• CORE_PEER_TLS_CLIENTROOTCAS_FILES = CA 체인 파일의 정규화 된 경로
• CORE_PEER_TLS_CLIENTCERT_FILE = 클라이언트 인증서의 정규화 된 경로
• CORE_PEER_TLS_CLIENTKEY_FILE = 클라이언트 키의 정규화 된 경로

클라이언트 인증이 피어 노드에서 활성화되면 클라이언트는 TLS 핸드 셰이크 중에 인증서를 보내야합니다. 클라이언트가 인증서를 보내지 않으면 핸드 셰이크가 실패하고 피어는 연결을 닫습니다.

피어가 채널에 조인하면 채널 구성원의 루트 CA 인증서 체인이 채널의 config 블록에서 읽히고 TLS 클라이언트 및 서버 루트 CA 데이터 구조에 추가됩니다. 따라서 피어 투 피어 통신, 피어 투 발주자 통신은 매끄럽게 작동해야합니다.

Configuring TLS for orderer nodes

orderer 노드에서 TLS를 사용하려면 다음 orderer 구성 등록 정보를 설정하십시오.

• General.TLS.Enabled = true
• General.TLS.PrivateKey = 서버 개인용 키가 들어있는 파일의 완전한 경로
• General.TLS.Certificate = 서버 인증서를 포함하는 파일의 정규화 된 경로
• General.TLS.RootCAs = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

기본적으로 TLS 클라이언트 인증은 피어의 경우와 마찬가지로 orderer에서 해제됩니다. TLS 클라이언트 인증을 사용하려면 다음 구성 등록 정보를 설정하십시오.

• General.TLS.ClientAuthRequired = true
• General.TLS.ClientRootCAs = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

클라이언트 인증을 사용하는 TLS는 다음 환경 변수를 설정하여 활성화 할 수도 있습니다.

• ORDERER_GENERAL_TLS_ENABLED = true
• ORDERER_GENERAL_TLS_PRIVATEKEY = 서버 개인용 키가 들어있는 파일의 완전한 경로
• ORDERER_GENERAL_TLS_CERTIFICATE = 서버 인증서를 포함하는 파일의 정규화 된 경로
• ORDERER_GENERAL_TLS_ROOTCAS = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로
• ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED = true
• ORDERER_GENERAL_TLS_CLIENTROOTCAS = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

Configuring TLS for the peer CLI

TLS 사용 가능 피어 노드에 대해 피어 CLI 명령을 실행하는 경우 다음 환경 변수를 설정해야합니다.

• CORE_PEER_TLS_ENABLED = true
• CORE_PEER_TLS_ROOTCERT_FILE = TLS 서버 인증서를 발급한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

원격 서버에서 TLS 클라이언트 인증을 사용하는 경우 위의 변수 외에 다음 변수를 설정해야합니다.

• CORE_PEER_TLS_CLIENTAUTHREQUIRED = true
• CORE_PEER_TLS_CLIENTCERT_FILE = 클라이언트 인증서의 정규화 된 경로
• CORE_PEER_TLS_CLIENTKEY_FILE = 클라이언트 개인 키의 완전한 경로

피어 채널 <create | update | fetch> 또는 피어 체인 코드 <invoke | instantiate> 와 같이 orderer 서비스에 연결하는 명령을 실행하는 경우 Orderer에서 TLS를 사용하는 경우 다음 명령 줄 인수도 지정해야합니다.

• -tls
• -cafile <orderer의 인증 코드 체인을 포함하는 파일의 완전한 경로 CA>

TLS 클라이언트 인증이 orderer에 대해 사용 가능한 경우 다음 인수도 지정해야합니다.

• -clientauth

• -keyfile <클라이언트 개인 키가 들어있는 파일의 완전한 경로>
• -certfile <클라이언트 인증서가 들어있는 파일의 전체 경로>

Debugging TLS issues

TLS 문제를 디버깅하기 전에 TLS 클라이언트와 서버 측 모두에서 GRPC debug를 활성화 하여 추가 정보를 얻는 것이 좋습니다. GRPC debug를 사용하려면 CORE_LOGGING_GRPC 환경 변수를 DEBUG로 설정하십시오.

클라이언트 쪽에서 remote error: tls: bad certificate 오류 메시지가 표시 되면 일반적으로 TLS 서버에서 클라이언트 인증을 사용하고 서버가 올바른 클라이언트 인증서를 받지 못했거나 신뢰할 수없는 클라이언트 인증서를 받았다는 의미입니다. 클라이언트가 인증서를 보내고 피어 또는 orderer 노드가 신뢰하는 CA 인증서 중 하나가 서명했는지 확인하십시오.

체인 코드 로그에 remote error: tls: bad certificate 오류 메시지가 표시되면 Fabric v1.1 이상에서 제공되는 체인 코드 심을 사용하여 체인 코드가 빌드되었는지 확인하십시오. chaincode에 shim의 판매자 된 사본이 없으면 chaincode 컨테이너를 삭제하고 해당 피어를 다시 시작하면 현재 shim 버전을 사용하여 chaincode 컨테이너를 다시 작성합니다. 체인 코드가 이전 버전의 shim을 제공했다면, vend -vendored-shim 을 업그레이드 하는 방법에 대한 문서를 검토하십시오.

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/enable_tls.html

Logging Control

Overview

peer 응용 프로그램 및 shim 인터페이스에서 체인 코드 로깅은 github.com/op/go-logging 패키지에서 제공하는 기능을 사용하여 프로그래밍 됩니다. 이 패키지는

• 메시지의 심각도를 기반으로 로깅 제어
• 메시지를 생성하는 소프트웨어 모듈을 기반으로 한 로깅 제어
• 메시지의 심각도를 기반으로 한 다양한 pretty-printing 옵션

모든 로그는 현재 stderr로 이동되며 pretty-printing은 현재 수정되었습니다. 그러나 심각도 별 로깅의 전역 및 모듈 수준 제어는 사용자와 개발자 모두에게 제공됩니다. 현재 각 심각도 수준에서 제공되는 정보 유형에 대한 형식화 된 규칙은 없지만 버그 보고서를 제출할 때 개발자는 전체 로그를 DEBUG 수준으로 보고 싶어 할 수 있습니다.

pretty-printing 로그에서 로깅 수준은 색상과 4 자리 코드로 표시됩니다 (예 : ERROR에 ERRO, DEBU에 DEBUG 등). 로깅 컨텍스트에서 모듈 은 임의의 이름 (문자열)입니다. 개발자가 관련 메시지 그룹에 제공합니다. 아래의 예에서, "peer", "rest"및 "main"로깅 모듈은 로그를 생성합니다.

16:47:09.634 [peer] GetLocalAddress -> INFO 033 Auto detected peer address: 9.3.158.178:7051
16:47:09.635 [rest] StartOpenchainRESTServer -> INFO 035 Initializing the REST service...
16:47:09.635 [main] serve -> INFO 036 Starting peer with id=name:"vp1" , network id=dev, address=9.3.158.178:7051, discovery.rootnode=, validator=true

런타임에 임의의 수의 로깅 모듈을 생성할 수 있으므로 모듈의 "마스터 목록"이 없고 로깅 제어 구조가 로깅 모듈이 실제로 존재하는지 또는 존재하는지 여부를 확인할 수 없습니다. 또한 로깅 모듈 시스템은 계층 구조 또는 와일드 카드를 이해하지 못합니다. 코드에서 "foo/bar"와 같은 모듈 이름을 볼 수 있지만 로깅 시스템은 플랫 문자열만 볼 수 있습니다. "foo/bar"는 어떤 식 으로든 "foo"와 관련이 있거나 "foo/*"가 foo의 모든 "하위 모듈"을 나타낼 수 있다는 것을 이해하지 못합니다.

peer

peer 명령의 로깅 수준은 --logging-level 플래그를 사용하여 각 호출에 대해 명령 줄에서 제어 할 수 있습니다 ( 예 :

peer node start --logging-level=debug

각 개별 peer 하위 명령의 기본 로깅 레벨은 core.yaml 파일에서 설정할 수도 있습니다. 예를 들어, 키 logging.node는 node 서브 커맨드의 기본 레벨을 설정합니다. 이 파일의 주석은 환경 변수를 사용하여 다양한 방법으로 로깅 수준을 재정의하는 방법을 설명합니다.

로깅 심각도 수준은 다음에서 선택된 대/소문자를 구분하지 않는 문자열을 사용하여 지정됩니다.

CRITICAL | ERROR | WARNING | NOTICE | INFO | DEBUG

peer의 전체 로깅 수준 사양은 다음과 같습니다.

[<module>[,<module>...]=]<level>[:[<module>[,<module>...]=]<level>...]

로깅 레벨 자체가 전체 기본값으로 간주됩니다. 그렇지 않으면 모듈의 개별 또는 그룹에 대한 재정의는 다음을 사용하여 지정할 수 있습니다.

<module>[,<module>...]=<level>

구문. 사양 예 ( --logging-level, 환경 변수 및 core.yaml 설정 모두에 유효 ) :

info                                       - Set default to INFO
warning:main,db=debug:chaincode=info       - Default WARNING; Override for main,db,chaincode
chaincode=info:main=debug:db=debug:warning - Same as above

Go chaincodes

체인 코드 애플리케이션 내에서 로그하는 표준 메커니즘은 피어를 통해 각 체인 코드 인스턴스에 노출된 로깅 전송과 통합하는 것입니다. chaincode shim 패키지는 체인 코드가 로그를 형식화하고 shim 로그와 일관되게 인터리브되는 로깅 객체를 생성하고 관리할 수 있게 해주는 API를 제공합니다.

독자적으로 실행되는 프로그램처럼, 사용자 제공 체인 코드는 기술적으로 stdout/stderr에 출력을 생성할 수도 있습니다. 자연적으로 "devmode"에 유용하지만 일반적으로 프로덕션 네트워크에서는 이러한 채널이 손상되어 악성 코드의 악용을 방지합니다. 그러나 CORE_VM_DOCKER_ATTACHSTDOUT = true 구성 옵션을 통해 피어가 관리하는 컨테이너 (예 : "netmode")의 경우에도 이 출력을 피어 단위로 활성화 할 수 있습니다.

일단 활성화되면, 각 체인 코드는 해당 컨테이너 ID에 의해 자체 로깅 채널을 수신하게됩니다. stdout 또는 stderr에 기록된 출력은 각 행별로 피어의 로그와 통합됩니다. 프로덕션 환경에서 이를 활성화하는 것은 권장되지 않습니다.

API

NewLogger(name string) *ChaincodeLogger - 체인 코드에서 사용할 로깅 개체 만들기 (c *ChaincodeLogger) SetLevel(level LoggingLevel) - 로거의 로깅 수준 설정

(c *ChaincodeLogger) IsEnabledFor(level LoggingLevel) bool - 지정된 레벨에서 로그가 생성되면 true를 반환합니다.

LogLevel(levelString string) (LoggingLevel, error) - 문자열을 LoggingLevel로 변환하십시오.

LoggingLevel은 열거 형의 멤버입니다.

LogDebug, LogInfo, LogNotice, LogWarning, LogError, LogCritical

대/소문자를 구별하지 않는 버전의 문자열을 전달하여 직접 사용할 수 있습니다.

DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL

LogLevel API.

다양한 심각도 수준의 형식화 된 로깅은 함수에 의해 제공됩니다.

(c *ChaincodeLogger) Debug(args ...interface{})
(c *ChaincodeLogger) Info(args ...interface{})
(c *ChaincodeLogger) Notice(args ...interface{})
(c *ChaincodeLogger) Warning(args ...interface{})
(c *ChaincodeLogger) Error(args ...interface{})
(c *ChaincodeLogger) Critical(args ...interface{})

(c *ChaincodeLogger) Debugf(format string, args ...interface{})
(c *ChaincodeLogger) Infof(format string, args ...interface{})
(c *ChaincodeLogger) Noticef(format string, args ...interface{})
(c *ChaincodeLogger) Warningf(format string, args ...interface{})
(c *ChaincodeLogger) Errorf(format string, args ...interface{})
(c *ChaincodeLogger) Criticalf(format string, args ...interface{})

f 형식의 로깅 API는 로그의 형식을 정확하게 제어합니다. 비 f 형식의 API는 현재 인수의 출력 표현 사이에 공백을 삽입하고 임의로 사용할 형식을 선택합니다.

현재 구현에서 shim 및 ChaincodeLogger에 의해 생성된 로그에는 타임 스탬프가 지정 되고 로거 이름 및 심각도 수준이 표시되며 stderr에 기록됩니다. 로깅 레벨 컨트롤은 현재 ChaincodeLogger가 생성 될 때 제공된 이름을 기반으로 합니다. 모호함을 피하기 위해 모든 ChaincodeLogger에는 "shim" 이외의 고유한 이름을 지정 해야합니다. 로거 이름 은 로거에 의해 작성된 모든 로그 메시지에 나타납니다. shim은 "심"으로 기록됩니다.

Go 언어 체인 코드는 SetLoggingLevel API를 통해 체인 코드 shim 인터페이스의 로깅 수준을 제어 할 수도 있습니다.

SetLoggingLevel(LoggingLevel level) - 심의 로깅 수준 제어

shim의 기본 로깅 수준은 LogDebug 입니다.

다음은 체인 코드가 LogInfo 레벨에서 로깅하는 개인 로깅 오브젝트를 작성하는 방법과 환경 변수를 기반으로 shim이 제공하는 로깅의 양을 제어 하는 간단한 예제입니다.

var logger = shim.NewLogger("myChaincode")

func main() {

    logger.SetLevel(shim.LogInfo)

    logLevel, _ := shim.LogLevel(os.Getenv("SHIM_LOGGING_LEVEL"))
    shim.SetLoggingLevel(logLevel)
    ...
}

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/logging-control.html

 Error handling

General Overview

Hyperledger 패브릭 코드는 Go에서 제공하는 표준 오류 유형 대신 판매된 패키지 github.com/pkg/errors 를 사용해야합니다. 이 패키지는 오류 메시지가 있는 스택 추적을 쉽게 생성하고 표시 할 수 있습니다.

Usage Instructions

fmt.Errorf() 또는 errors.New()에 대한 모든 호출 대신 github.com/pkg/errors를 사용해야합니다. 이 패키지를 사용하면 오류 메시지에 추가될 호출 스택이 생성됩니다.

이 패키지를 사용하는 것은 간단하며 코드를 쉽게 조정할 수 있습니다.

먼저 github.com/pkg/errors를 가져와야 합니다.

그런 다음 오류 생성 함수 (errors.New (), errors.Errorf (), errors.WithMessage (), errors.Wrap (), errors.Wrapf () 중 하나를 사용하도록 코드에서 생성된 모든 오류를 업데이트하십시오.

Note! 사용 가능한 오류 생성 기능에 대한 자세한 내용은 https://godoc.org/github.com/pkg/errors를 참조 하십시오. 또한 패브릭 코드에 패키지를 사용하기 위한 구체적인 지침은 아래의 일반 지침 섹션을 참조하십시오.

마지막으로, 로거 또는 fmt.Printf() 호출에 대한 형식 지시자를 %s에서 %+v로 변경하여 호출 스택을 오류 메시지와 함께 출력하십시오.

General guidelines for error handling in Hyperledger Fabric

• 사용자 요청을 처리하는 중이라면 오류를 기록한 다음 반환해야합니다.
• Go 라이브러리 나 판매자 패키지와 같은 외부 소스에서 오류가 발생하면 errors.Wrap()을 사용하여 오류를 래핑하여 오류에 대한 호출 스택을 생성하십시오.
• 다른 패브릭 함수에서 오류가 발생하면 호출 스택을 영향을받지 않고 errors.WithMessage()를 사용하여 오류 메시지에 추가 컨텍스트를 추가하십시오.
• 패닉이 다른 패키지로 퍼지면 안됩니다.

Example program

다음 예제 프로그램은 패키지 사용에 대한 명확한 데모를 제공합니다.

package main

import (
  "fmt"

  "github.com/pkg/errors"
)

func wrapWithStack() error {
  err := createError()
  // do this when error comes from external source (go lib or vendor)
  return errors.Wrap(err, "wrapping an error with stack")
}
func wrapWithoutStack() error {
  err := createError()
  // do this when error comes from internal Fabric since it already has stack trace
  return errors.WithMessage(err, "wrapping an error without stack")
}
func createError() error {
  return errors.New("original error")
}

func main() {
  err := createError()
  fmt.Printf("print error without stack: %s\n\n", err)
  fmt.Printf("print error with stack: %+v\n\n", err)
  err = wrapWithoutStack()
  fmt.Printf("%+v\n\n", err)
  err = wrapWithStack()
  fmt.Printf("%+v\n\n", err)
}

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/error-handling.html