Capability Requirements

Fabric은 대개 여러 국가 또는 대륙에있는 여러 조직을 포함하는 분산 시스템이기 때문에 여러 다른 버전의 Fabric 코드가 네트워크에 존재할 수 있습니다 (일반적으로). 그럼에도 불구하고 네트워크가 트랜잭션을 동일한 방식으로 처리하여 모든 사람이 현재 네트워크 State에 대해 동일한 시각을 갖도록하는 것이 중요합니다.

즉, 모든 네트워크와 네트워크 내의 모든 채널은 처리 트랜잭션에 참여할 수 있도록 "기능"이라고하는 집합을 정의해야합니다. 예를 들어, Fabric v1.1은 "피어"와 "클라이언트"의 새로운 MSP 역할 유형을 소개합니다. 그러나 v1.0 피어가 이러한 새로운 역할 유형을 이해하지 못하면 해당 역할 유형을 참조하는 Endorsement Policy를 적절히 평가할 수 없습니다. 즉, 새 역할 유형을 사용하기 전에 네트워크가 v1.1 채널 기능 요구 사항을 사용하도록 동의해야 모든 피어가 동일한 결정을 내릴 수 있습니다.

필요한 기능을 지원하는 바이너리만 채널에 참여할 수 있으며 최신 바이너리 버전에서는 해당 기능을 사용할 수있을 때까지 새로운 유효성 검사 논리를 사용할 수 없습니다. 이런 식으로 기능 요구 사항은 서로 다른 빌드와 버전이 있더라도 네트워크가 State를 포착 할 수 없음을 보장합니다.

기능 요구 사항 정의

기능 요구 사항은 채널 구성 (채널의 가장 최근 구성 블록에 있음)에서 채널별로 정의됩니다. 채널 구성에는 세 가지 위치가 있으며 각 위치는 다른 유형의 기능을 정의합니다.

• 채널 :이 기능은 피어 및 Orderer 모두에게 적용되며 루트 채널 그룹에 있습니다.
• Orderer: Orderer에게만 적용되며 Orderer 그룹에 있습니다.
• 응용 프로그램 : 피어에만 적용되며 응용 프로그램 그룹에 있습니다.

기능은 기존 관리 구조와 일치시키기 위해 이러한 그룹으로 분류됩니다. Orderer 기능을 업데이트하는 것은 주문 조직이 응용 프로그램 조직과 독립적으로 관리하는 것입니다. 마찬가지로 응용 프로그램 기능을 업데이트하는 것은 응용 프로그램 관리자 만 관리 할 수있는 것입니다. "Orderer"와 "Application"사이의 기능을 분리함으로써 가상의 네트워크는 v1.6 피어 어플리케이션 네트워크를 지원하면서 v1.6 주문 서비스를 실행할 수 있습니다.

그러나 일부 기능은 'Application'및 'Orderer'그룹을 교차합니다. 이전에 보았 듯이 새로운 MSP 역할 유형을 추가하는 것은 Orderer 및 응용 프로그램 관리자가 모두 동의하고 인식해야하는 것입니다. Orderer는 거래가 주문서를 통과 할 수 있도록하기 위해 MSP 역할의 의미를 이해해야하며 동료는 트랜잭션을 확인하기 위해 역할을 이해해야합니다. 이러한 종류의 기능 (응용 프로그램과 Orderer 구성 요소 모두에 걸쳐 있음)은 최상위 "채널"그룹에 정의됩니다.

기능 설정

기능은 채널 구성의 일부로 설정됩니다 (초기 구성의 일부로 - 잠시 후에 - 또는 재구성의 일부로).

새 채널은 기본적으로 Orderer 시스템 채널의 구성을 복사하므로 Orderer 시스템 채널의 Orderer 및 채널 기능 및 채널 생성 트랜잭션에서 지정한 응용 프로그램 기능을 사용하도록 새 채널이 자동으로 구성됩니다. 그러나 이미 존재하는 채널은 재구성해야합니다.

Capabilities 값의 스키마는 다음과 같이 protobuf에 정의됩니다.

message Capabilities {
      map<string, Capability> capabilities = 1;
}

message Capability { }

{
    "capabilities": {
        "V1_1": {}
    }
}

초기 구성의 기능

릴리스 아티팩트의 config 디렉토리에 분산 된 configtx.yaml 파일에는 기능 유형 (채널, Orderer 및 애플리케이션)에 대해 가능한 기능을 나열하는 기능 섹션이 있습니다.

기능을 활성화하는 가장 간단한 방법은 v1.1 샘플 프로파일을 선택하고 네트워크에 맞게 사용자 정의하는 것입니다. 예 :

SampleSingleMSPSoloV1_1:
    Capabilities:
        <<: *GlobalCapabilities
    Orderer:
        <<: *OrdererDefaults
        Organizations:
            - *SampleOrg
        Capabilities:
            <<: *OrdererCapabilities
    Consortiums:
        SampleConsortium:
            Organizations:
                - *SampleOrg

루트 수준 (채널 기능 용) 및 Orderer 수준 (Orderer 기능 용)에 정의 된 기능 섹션이 있습니다. 위의 샘플은 YAML 참조를 사용하여 YAML의 맨 아래에 정의 된대로 기능을 포함합니다.

발주자 시스템 채널을 정의 할 때 응용 프로그램 섹션이 없으므로 해당 기능은 응용 프로그램 채널을 만드는 동안 정의됩니다. 채널 생성시 새로운 채널의 응용 프로그램 기능을 정의하려면 응용 프로그램 관리자가 SampleSingleMSPChannelV1_1 프로파일 다음에 채널 생성 트랜잭션을 모델링해야합니다.

SampleSingleMSPChannelV1_1:
     Consortium: SampleConsortium
     Application:
         Organizations:
             - *SampleOrg
         Capabilities:
             <<: *ApplicationCapabilities

여기서 응용 프로그램 섹션에는 YAML 끝에 정의 된 ApplicationCapabilities 섹션을 참조하는 Capabilities라는 새로운 요소가 있습니다.

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

Architecture Explained

 아키텍처 설명

Hyperledger Fabric이 제공하는 이점

• Chaincode의 신뢰 유연성(Chaincode trust flexibility) : 이 아키텍처는 체인코드(블록체인 어플리케이션)을 Ordering Service와 분리하였습니다. 이는 Ordering Service의 한 노드 set에 의해 제공 될수 있으며, 일부 오류나 오작동을 수용할 수 있습니다. endorsers는 각 체인코드마다 다를 수 있습니다.
• 확장성(Scalability) : 특정 체인코드를 담당하는 endorser 노드는 Orderer와 역할이 다르기 때문에 동일한 노드에서 기능을 수행하는 것 보다 확장성이 좋습니다. 특히 서로 다른 체인 코드가 분리된 endorser를 지정하면 endorser 사이에 체인코드를 분할하고 패러럴 하게 체인코드를 실행 하여 보증할 수 있습니다. 게다가 비용이 많이 드는 체인코드 실행은 Ordering Service 의 중요한 경로에서 제거가 됩니다.
• 기밀유지(Confidentiality) : 컨텐츠 및 해당 트랜잭션의 State 업데이트와 관련하여 기밀성 요구 사항이 있는 체인코드 배포가 용이합니다.
• 컨센서스의 모듈화(Consensus modularity) : 모듈식으로 컨센서스가 플러그인이 가능하도록 수성되었습니다.

시스템 아키텍처

블록체인은 서로 통신하는 많은 노드로 구성된 분산 시스템입니다. 블록체인은 chaincode 라는 프로그램으로 실행하여 트랜잭션을 발생시키며 State 및 원장 데이터를 보유하고 있습니다.체인코드는 트랜잭션을 호출하는 핵심 요소 입니다. 트랜잭션는 "보증" 되어야 되며 승인된 트랜잭션만 커밋되어 해당 State에 영향을 미칠수 있습니다.

• 관리 기능 및 매개 변수에는 하나 이상의 특수한 체인코드(시스템 체인 코드)가 있을수 있습니다.

트랜잭션(Transactions)

트랜잭션에는 두가지 유형이 있습니다.

• 배포 트랜잭션(Deploy transactions) : 새로운 체인코드를 생성하고 프로그램을 매개변수로 사용합니다. 배포 트랜잭션이 성공적으로 실행되면 체인코드가 블록체인 위에 설치가 됩니다.
• 호출 트랜잭션( Invoke transactions) : 이전에 배포된 체인코드의 컨텍스트에서 작업을 수행하는 부분입니다. 호출 트랜잭션은 체인코드와 제공된 기능 중 하나를 참조합니다. 성공하면 체인코드에 지정된 함수를 실행 합니다. 이 함수는 해당 State를 수정하고 내용을 반환 합니다.

다음에 설명하듯이 배포 트랜잭션은 호출 트랜잭션의 특수한 경우이며 새로운 체인코드를 만들어서 배포 하는 것은 시스템체인코드의 호출 트랜잭션에 해당 합니다.

비고 : 이 문서는 현재 트랜잭션이 새로운 체인코드를 생성하거나 이미 배치 된 하나의 체인코드에 의해 제공되는 연산을 호출한다고 가정 합니다. 이문서에서 a 쿼리 트랜잭션, b 교차 체인 트랜잭션을 지원

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

State

블록체인의 최신 State는 Key 값이 이름이고 Value가 내용이 key-value store 로 모델링이 되어있습니다. 이 부분은 블록체인에 put 과 get kvs 로 체인코드로 작업이 진행 되고 있습니다.

State는 지속적으로 저장되고 State에 대한 업데이트가 기록되게 됩니다. kvs가 State 모델로 채택되어 사용되고 있지만 RDBMS 또는 다른 솔루션으로 대체하여 사용할 수도 있습니다.

KVS의 s(State)는 K -> (V X N) 으로 매핑 됩니다.

• K는 키의 집합
• V는 값의 집합
• N은 제한 없이 순서대로 설정되는 버전 번호입니다. 다음 함수 : N -> N은 N의 구성요소를 바탕으로 다음 버전 번호를 반환합니다

V와 N은 모두 특수 요소 ⊥ (빈 유형)를 포함하며, N은 가장 낮은 요소입니다. 처음에는 모든 키가 (⊥, ⊥)에 매핑됩니다. s (k) = (v, ver)에 대해 우리는 v를 s(k).value로 표시하고 ver은 s(k)로 나타내게 됩니다.

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

• k ∈ K와 v ∈ V에 대해 put (k, v)를 취하고 블록 체인 State s를 취하여

  s'(k) = (v, next (s) (k') = s (k') k' != k

• get(k)는 s(k)를 반환 합니다.

State는 peer에 의해 유지되지만 Orderer 및 Client에 의해 유지되지는 않습니다.

State파티션 : KVS의 키는 특정 체인코드의 트랜잭션만이 체인코드에 속하는 키를 수정 할수 있다는 의미에서 특정 체인코드에 속하도록 이름에서 인식 할 수 있습니다. 원칙적으로 모든 체인코드는 다른 체인코드에 속한 키를 읽을 수 있습니다. 두개 이상의 체인코드에 속하는 State를 수정하는 교차 트랜잭션에 대한 지원이 v1 이후 가능해 졌습니다.

원장

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

Ledger는 Ordering Serivce에 의해 트랜잭션 블록을 완전히 정렬 된 해시 체인으로 구성합니다. 해시 체인은 원장에 블록의 전체 순서를 정하고 각 블록에 정렬된 트랜잭션의 배열을 포함시킵니다. 이렇게 하면 모든 트랜잭션에서 전체 Orerer에 순서가 부과(타임 스탬프) 되는 것입니다.

Ledger는 모든 peer 및 선택적으로 orderer와의 하위 집합으로 보관 됩니다. orderer 입장에서 원장을 원고 (OrdererLedger)라고 부르지 만 피어 (PeerLedger)에 대해서는 원장을 참조하는 것입니다. PeerLedger는 Orderer Ledger와 다른 점은 peer은 유효하지 않은 트랜잭션과 유효하지 않은 트랜잭션을 구별하는 비트 마스크를 로컬에서 유지한다는 점입니다

PeersLedger는 피어 투 피어를 할 수 있습니다. OrdererLedger는 내결함성 및 가용성 (PeerLedger)을 유지 관리하며 Ordering Service 에 속하게 됩니다.

노드(Node)

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

노드에는 3가지 유형이 있습니다.

1. 클라이언트 또는 submitting-client : 실제 클라이언트 호출을 endorser에게 제출하고 Transaction Proposal를 Ordering Service의 브로드 캐스팅 하는 클라이언트
2. 피어(peer) : 트랜잭션을 커밋하고 State와 원장의 복사본을 유지하는 노드. peer가 특별한 endorser의 역할도 수행할 수도 있습니다.
3. Ordering Service 노드 또는 Orderer(Ordering-service-node or orderer)  : atomic 또는 Order의 브로드캐스팅과 같은 delivery 보증을 구현한 통신 서비스를 실행하는 노드

Client

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

PEER

peer은 Ordering Servic의 블록형태로 요청된 State를 업데이트 받고 State와 원장의 관계를 유지 관리합니다.

peer은 endorsing peer이나 endorser의 역할을 수행 할 수 있습니다. endorsing peer의 특수 기능은 특정 체인코드와 관련하여 발생하며 커밋 되기 전에 트랜잭션을 승인 하는 것으로 구성됩니다. 모든 체인코드는 Endorsement Policy을 지정할 수 있습니다. 이 Policy는 유효한 트랜잭션 보증에 필요한 충분 조건으로 정의합니다. 새로운 체인코드를 설치하고 배포 트랜잭션의 특별한 (배포) 은 다음과 같습니다. 이는 시스템 체인코드의 보증 정책으로 지정됩니다.

Ordering service nodes (Orderers)

orderers의 형태는 Ordering Service, 즉 배달의 보장을 제공하는 통신 패브릭입니다. Ordering Service는 여러가지 방법으로 구현 될 수 있습니다. 예를 들어 개발 및 테스트에 사용되는 중앙 집중식 서비스 부터 다양한 네트워크 및 노드의 결함 모델을 대상으로 하는 분산된 프로토콜에 이르기 까지 다양합니다.

Ordering Service는 클라이언트와 peer에게 공유하는 통신채널을 제공하여 트랜잭션이 포함된 메시지에 대한 브로드 캐스트 서비스를 제공합니다. 클라이언트를 채널에 연결하고 채널에서 메시지를 브로드캐스팅 한 다음 모든 피어에 전달 할수 있습니다. 이 채널은 모든 메시지의 배달, 즉 총 Order, 배송 및 메시지 전달의 안정성을 지원합니다. 즉 채널은 연결된 모든 피어에게 동일한 메시지를 보내게 되고 논리적 순서로 모든 피어에게 내용을 전달 합니다. 이 통신의 보장은 총 Ordere에 대한 브로드캐스트 또는 합의라고도 합니다. 분산 시스템과 관련하여 전달된 메시지는 블록체인의 State에 포함될 후보 트랜잭션입니다.

Partitioning (ordering service channels) : Ordering Service의 publicsh/subscrbe 에 관한 메시징 시스템의 주제를 비슷한 여러 채널에 지원할 수 있습니다. 클라이언트는 주어진 채널에 연결 할 수 있으며 메시지를 보내고 도착한 메시지를 확인 할수 있습니다. 채널을 파티션으로도 생각할 수 있습니다. 한 채널에 연결하는 클라이언트는 다른 채널의 존재를 인식하지 못하지만 클라이언트는 여러 채널에 연결 할 수 있습니다. Hyperledger Fabric에 포함된 일부 Ordering Service의 구현은 여러 채널을 지원하지만 여기서는 편의를 위해 Ordering Service가 단일 채널/ 주제로 구성 된다고 가정 합니다.

Ordering service API. : peer은 Ordering Service에서 제공하는 인터페이스를 통해 Ordering Service에서 제공하는 채널에 연결합니다. Ordering ServiceAPI는 두가지 기본 작업(비동기 이벤트)으로 구성됩니다.

TODO  : 클리이언트/peer의 시퀀스 번호 아래 특정 블록을 패치하기 위한 API를 추가 할 예정입니다.

• broadcast(blob) : 클라이언트는 채널을 통한 전파를 위해 임의의 메시지 BLOB를 브로드 캐스트하기 위해 이를 호출합니다. 이것은 서비스에 요청을 보낼 때 BFT 컨텍스트에서 요청 (blob)이라고도합니다.
• deliver(seqno, prevhash, blob) : Ordering Service는 peer에 대해 이것을 호출하여 지정된 음수가 아닌 정수 시퀀스 번호 (seqno)와 가장 최근에 전달 된 blob (prevhash)의 해시를 사용하여 메시지 blob을 전달합니다. 즉, Ordering Service의 출력 이벤트입니다. deliver ()는 pub-sub 시스템에서는 notify () 또는 BFT 시스템에서 commit ()이라고도합니다.

원장및 블록 형성 : 원장에는 ordering serivce가 보낸 모든 데이터가 포함됩니다. 이것은 deliver (seqno, prevhash, blob) 이벤트의 시퀀스이며, 앞에서 설명한 prevhash의 계산에 따라 해시 체인을 형성합니다. 

효율성을 위해 대부분의 경우 개별 트랜잭션 (blob)을 출력하는 대신 Ordering Service 단일 전달 이벤트 내에서 blob 및 내용 블록을 그룹화합니다 (일괄 처리). 이 경우, Ordering Service 는 각 블록 내의 blob 순서를 부과하고 전달합니다. 블럭 내의 blob수는 Ordering Service 구현에 의해 동적으로 선택 될 수있다.

다음에서는 표현의 편의를 위해 서비스 속성(이 하위 섹션의 나머지 부분)를 정의하고 전달 이벤트 당 하나의 BLOB를 가정하여 트랜잭션 승인 워크 플로 (섹션 2)를 설명합니다. 블록에 대한 전달 이벤트가 블럭 내의 BLOB의 위에서 언급 한 결정 순서에 따라 블록 내의 각 BLOB에 대한 개별 전달 이벤트의 시퀀스에 해당한다고 가정하면 이러한 이벤트는 블록으로 쉽게 확장됩니다.

Ordering Service 속성(Ordering service properties)

Ordering Serivce에서 보장되는 것은 브로드캐스팅 된 메시지에 어떤 일이 일어나고 전달된 메시지 간에 어떤 관계가 존재 하는지 규정하는 것입니다. 이러한 보증은 다음과 같습니다.

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

요약하면 Ordering Service에서는 다음과 같은 속성을 보장 해야 합니다.

• 협정(Agreement) : 올바른 seagno, prevhash0 == prevhash1 및 blob0 == blob1을 사용하여 올바른 피어에서 전달되는 두 이벤트 (예 : seqno, prevhash0, blob0) 및 deliver (seqno, prevhash1, blob1)
• Hashchain 무결성(Hashchain integrity) : 올바른 피어에서의 두 이벤트가 (seqno-1, prevhash0, blob0) 및 deliver (seqno, prevhash, blob) 인 경우 prevhash = HASH (seqno-1 || prevhash0 || blob0).
• No skipping : Ordering Service가 seqno> 0과 같은 올바른 피어 p에서 deliver (seqno, prevhash, blob)를 출력하면 p는 이미 이벤트 전달을 전달합니다 (seqno-1, prevhash0, blob0).
• No creation : 올바른 피어의 모든 이벤트 전달 (seqno, prevhash, blob) 앞에는 일부 (가능하면 별개의) 피어에서 브로드 캐스트 (blob) 이벤트가 있어야합니다.
• No duplication (optional, yet desirable) : 2 개의 이벤트 전달 (seqno0, prevhash0, blob) 및 deliver (seqno1, prevhash1, blob ')가 올바른 피어 및 blob == blob'에서 발생하는 두 개의 이벤트 브로드 캐스트 (blob) 및 브로드 캐스트 (blob ')의 경우 seqno0 = = seqno1 및 prevhash0 == prevhash1.
• Liveness : 올바른 클라이언트가 이벤트 브로드 캐스트 (blob)를 호출하면 모든 올바른 피어는 이벤트 전달 (*, *, blob)을 발행합니다. 여기서 *는 임의의 값을 나타냅니다.

트랜잭션 보증의 기본 workflow

트랜잭션에 대한 요청 플로우를 개괄적으로 설명합니다.

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

클리이언트는 트랜잭션을 생성하고 선택한 피어를 승인하는 곳으로 보내게 됩니다.

트랜잭션을 호출하기 위해 클라이언트는 자신이 선택한 피어 투 피어 집합에 PROPOSE 메시지를 보냅니다 지정된 chaincodeID에 대한 승인 피어 세트는 피어를 통해 클라이언트에 제공되며, 이는 인증 계약에서 보증하는 피어 세트를 구성하게 됩니다. 예를 들어, 트랜잭션은 주어진 chaincodeID의 모든 endorsers에게 전송 될 수 있습니다. 즉, 일부 최종 사용자는 오프라인 일 수 있고, 다른 사용자는 반대 할 수 있으며 트랜잭션를 승인하지 않을 수도 있습니다. 제출하는 클라이언트는 사용 가능한 endorser를 사용하여 정책 표현식을 만족 시키려고 시도합니다.

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

PROPOSE message format

PROPOSE메시지 포맷은 <PROPOSE,tx,[anchor]> 이며 tx는 필수이고 anchor은 옵셔널한 입력 변수 입니다.

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

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

Message patterns

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

피어는 트랜잭션를 시뮬레이션 하고 보증의 서명을 생성합니다.

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

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

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

State는 키 - 값 쌍으로 구성됩니다. 모든 키 - 값 엔트리는 버전 관리됩니다. 즉, 모든 항목에는 키 아래에 저장된 값이 업데이트 될 때마다 증가하는 순서화 된 버전 정보가 들어 있습니다. 트랜잭션을 해석하는 피어는 읽기 또는 쓰기를 위해 체인 코드에 의해 액세스 된 모든 키 - 값 쌍을 기록하지만 피어는 해당 State를 아직 업데이트하지 않습니다.

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

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

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

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

• 여기서 txContentBlob는 체인 코드 / 트랜잭션 관련 정보입니다. txContentBlob를 tx의 일부 표현으로 사용하는 것입니다 (예 : txContentBlob = tx.txPayload).
• epSig는 tran-proposal에서 승인하는 피어의 서명입니다.

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

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

제출 클라이언트는 트랜잭션에 대한 보증을 수집하고Ordering Service를 통해 브로드 캐스트 합니다.

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

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

제출 클라이언트가 트랜잭션 제안서에 대한 보증을 수집하지 못하면 나중에 재시도 할 수 있는 옵션을 사용하여 트랜잭션을 포기하게 됩니다.

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

Ordering Service는 트랜잭션을 peer에게 전달합니다.

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

• blob.endorsement가 참조하는 chaincode (blob.tran-proposal.chaincodeID)의 정책에 따라 blob.endorsement가 유효한지 확인합니다.
• 일반적인 경우에는 종속성 (blob.endorsement.tran-proposal.readset)도 위반하지 않았다는 것을 확인합니다. 보다 복잡한 유스 케이스에서는 보증서의 트란 - 제안 필드가 다를 수 있으며이 경우 보증 정책은 State의 변화 방식을 지정합니다.

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

• 이러한 모든 검사가 통과되면 트랜잭션은 유효하거나 완료된 것으로 간주됩니다. 이 경우 피어는 PeerLedger의 비트 마스크에서 트랜잭션을 1로 표시하고 blob.endorsement.tran-proposal.writeset을 블록 체인 State에 적용합니다
• blob.endorsement의 보증 정책 확인이 실패하면 트랜잭션은 유효하지 않으며 피어는 PeerLedger의 비트 마스크에서 트랜잭션을 0으로 표시합니다. 유효하지 않은 트랜잭션으로 인해 State가 변경되지는 않는 것입니다.

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

추천정책

보증 정책 요소

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

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

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

보증 정책에 대한 트랜잭션 평가

트랜잭션은 정책에 따라 승인 된 경우에만 유효한 것으로 선언됩니다. 체인 코드에 대한 호출 (invoke) 트랜잭션은 먼저 체인 코드의 정책을 만족시키는 보증 을 획득해야하며 그렇지 않으면 커밋되지 않습니다. 이것은 제출 클라이언트와 승인하는 동료 간의 상호 작용을 통해 발생합니다.

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

보증 정책 에 입각한 특정 변수를 나타냅니다. 잠재적으로 다음을 참조 할 수 있습니다.

1. 체인 코드의 메타 데이터에있는 체인 코드와 관련된 키 또는 ID
2. 체인 코드의 추가 메타 데이터
3. endorsement, endorsement.tran-proposa 구성요소
4. 잠재적으로 더 많은 것들

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

보증 정책 내용의 평가는 결정 론적이어야합니다. endorsement는 모든 피어로 평가되어야 하고 다른 동료들과 상호 작용해야 하며 같은 방법으로 승인 정책을 평가 해야 합니다.

보증정책의 예

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

체인 코드가 endorser  집합 E = {Alice, Bob, Charlie, Dave, Eve, Frank, George}를 지정한다고 가정합니다.

• E의 모든 구성원의 동일한 tran-proposal에있는 유효한 서명.
• E의 단일 회원으로부터 유효한 서명
• 조건 (Alice OR Bob) AND (Charlie, Dave, Eve, Frank, George 중 둘 중 하나)에 따라 동료를 승인하는 것과 동일한 tran-proposal에 유효한 서명.
• 7 명의 endorsers 중 5 명이 동일한 tran-proposal에서 유효한 서명. (보다 일반적으로, n> 3f endorsers의 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가있는 지분의 대부분 (즉, 스테이크가 결합 된 그룹)이 유효한 세트의 유효한 서명이 필요합니다. 앨리스를 제외한 모두 함께}.
• 앞의 예제 조건에서 스테이크의 할당은 정적 (체인 코드의 메타 데이터에 고정) 또는 동적 (예 : 체인 코드의 State에 따라 다르며 실행 중에 수정 될 수 있음) 일 수 있습니다.
• tran-proposal1의 (Alice or Bob)에서 유효한 서명과 tran-proposal2의 Charlie, Dave, Eve, Frank, George 중 어느 하나의 유효한 서명. 여기서 tran-proposal1과 tran-proposal2는 승인하는 동료에서만 서로 다릅니다.

이러한 정책이 얼마나 유용한지는 응용 프로그램, endorsers의 실패 또는 오작동 및 다양한 기타 속성에 대한 솔루션의 원하는 복원력에 따라 달라집니다.

검증된 원장 및 PeerLedger 체크포인트

검증된 원장(VLedger)

유효하고 커밋된 트랜잭션을 포함하는 원장의 추상화를 위해 peer는 주 원장 이외에도 유효 원장을 유지 관리 할수 있습니다. 유효하지 않은 트랜잭션을 필터링 하여 원장에서 파생된 해시 체인입니다.

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

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

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

이 모든 정보는 피어에 의해 연결되고 해시되어 유효성 검사기에서 vBlock의 해시를 생성합니다.

PeerLedger 체크포인팅

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

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

Checkpointing protocol

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

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

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

• blockno> latestValidCheckpoint.blockno이면 피어가 latestValidCheckpoint = (blocknohash, blockno)를 지정합니다.
• 유효한 체크 포인트를 구성하는 각각의 피어 서명들의 세트를 세트의 latestValidCheckpointProof
• stateHash에 해당하는 State를 latestValidCheckpointedState에 저장합니다.
• (선택 사항) 블록 번호 blockno (포함)까지 PeerLedger를 제거합니다.

Valid checkpoints

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

• 로컬 (피어 전용) 검사 점 유효성 정책 (LCVP). 주어진 피어 p의 로컬 정책은 피어 P 트러스트와 그의 CHECKPOINT 메시지가 유효한 체크 포인트를 설정하기에 충분한 피어 세트를 지정할 수있다. 예를 들어, 피어 앨리스의 LCVP는 앨리스가 밥 또는 찰리와 데이브 모두로부터 CHECKPOINT 메시지를 수신해야한다고 정의 할 수 있습니다.
• 글로벌 체크 포인트 유효성 정책 (GCVP). 체크 포인트 유효성 정책은 전 세계적으로 지정 될 수 있습니다. 이는 로컬 피어 정책과 유사하지만 피어 세분성보다는 시스템 (블록 체인) 세밀도에서 규정된다는 점만 다릅니다. 예를 들어, GCVP는 다음을 지정할 수 있습니다.
  • 11 명의 서로 다른 동료 가 확인한 경우 각 피어는 체크 포인트를 신뢰할 수 있습니다 .
  • 모든 발주자가 동일한 시스템 (즉, 신뢰 도메인)의 피어와 함께 배치되고 f 명의 발주자가 (비잔틴) 오류가있을 수 있는 특정 배포에서는 f + 1 명의 다른 피어에 의해 확인 된 경우 각 피어가 체크 포인트를 신뢰할 수 있습니다.

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

Hyperledger Fabric CA는 Hyperledger Fabic 용 CA (Certificate Authority)입니다. fabric-ca client 및 fabric-ca server에 사용 가능한 명령은 아래 링크에 설명되어 있습니다.

Fabric-CA Client

fabric-ca-client 명령을 사용하면 ID 관리(특성 관리 포함) 및 인증서 (갱신 및 해지 포함)를 관리 할 수 있습니다.

fabric-ca-client 명령에 대한 자세한 내용은 여기를 참조하십시오.

Fabric-CA Server

fabric-ca-server 명령을 사용하면 하나 이상의 인증 기관을 호스트 할 수있는 서버 프로세스를 초기화하고 시작할 수 있습니다.

fabric-ca-server명령에 대한 자세한 사항은 여기를 참조하십시오.

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

 cryptogen commands

Cryptogen은 Hyperledger Fabric의 key 자료를 생성하는 유틸리티입니다.

주로 테스트 환경에서 사용하기위한 것입니다.

Syntax

cryptogen명령은 그 안에 다른 하위 명령이 있습니다.

cryptogen [subcommand]

다음과 같습니다.

cryptogen generate 
cryptogen showtemplate 
cryptogen version 
cryptogen extend 
cryptogen help 
cryptogen

이러한 하위 명령은 유틸리티가 제공하는 여러 기능을 분리합니다.

각 하위 명령에는 사용할 수 있는 다양한 옵션들이 있고, 그로인해 각 항목에 대한 설명은 본 글의 각 section에 있습니다.

별다른 명령 옵션을 지정하지 않으면 다소 높은 수준의 도움말 텍스트가 반환됩니다.

cryptogen flags

cryptogen 명령은 관련 플래그 세트가 있습니다 :

cryptogen [flags]

다음과 같습니다.

cryptogen --help 
cryptogen generate --help

이 플래그는 cryptogen에 대한 자세한 정보를 제공하며 모든 명령 수준에서 사용할 수 있기 때문에 전역으로 지정 됩니다. 예를들어 --help 플래그는 cryptogen 명령어 및 cryptogen generate명령 및 각 옵션에 대한 도움말을 제공합니다.

Flag details

--help

help를 사용하여 cryptogen 명령에 대한 간단한 도움말 텍스트를 확인해보세요. help 플래그는 종종 개별 명령의 도움말을 얻기위해 다른 수준에서 사용된다, 심지어 명령 옵션에 관한 도움까지도 가능하다. 자세한 내용은 개별 명령을 참조하세요.,

Usage

다음은 peer 명령에서 사용 가능한 여러 플래그를 사용하는 몇 가지 예제 입니다.

--help flag

cryptogen --help

usage: cryptogen [<flags>] <command> [<args> ...]

Utility for generating Hyperledger Fabric key material

Flags:
  --help  Show context-sensitive help (also try --help-long and --help-man).

Commands:
  help [<command>...]
    Show help.

  generate [<flags>]
    Generate key material

  showtemplate
    Show the default configuration template

  version
    Show version information

  extend [<flags>]
    Extend existing network

The cryptogen generate Command

The cryptogen generate Command 명령을 사용하여 키 재료를 생성 할 수 있습니다.

Syntax

cryptogen generate 명령은 다음과 같습니다.

cryptogen generate [<flags>]

cryptogen generate

cryptogen generate 플래그는 다른 플래그를 가지고 있기에, 각 플래그는 관련 명령 주제에 설명되어 있습니다.

cryptogen generate [flags]

다음과 같습니다.

cryptogen generate --output="crypto-config" 
cryptogen generate --config=CONFIG

전역 cryptogen명령 플래그는 cryptogen 명령 플래그에 설명 된대로 적용됩니다.

--help

Flag details

--output="crypto-config"

아티팩트를 배치 할 출력 경로

--config=CONFIG

사용할 구성 템플릿

Usage

cryptogen generate 명령에서 사용 가능한 여러 플래그를 사용하는 몇 가지 예제입니다.

./cryptogen generate --output="crypto-config"

org1.example.com
org2.example.com

The cryptogen showtemplate Command

cryptogen showtemplate 명령은 기본 구성 템플릿을 표시합니다.

Syntax

cryptogen showtemplate 명령 구문은 다음과 같습니다.

cryptogen showtemplate

Usage

cryptogen showtemplate 명령의 출력은 다음과 같습니다.

cryptogen showtemplate

# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
  # ---------------------------------------------------------------------------
  # Orderer
  # ---------------------------------------------------------------------------
  - Name: Orderer
    Domain: example.com

    # ---------------------------------------------------------------------------
    # "Specs" - See PeerOrgs below for complete description
    # ---------------------------------------------------------------------------
    Specs:
      - Hostname: orderer

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
  # ---------------------------------------------------------------------------
  # Org1
  # ---------------------------------------------------------------------------
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: false

    # ---------------------------------------------------------------------------
    # "CA"
    # ---------------------------------------------------------------------------
    # Uncomment this section to enable the explicit definition of the CA for this
    # organization.  This entry is a Spec.  See "Specs" section below for details.
    # ---------------------------------------------------------------------------
    # CA:
    #    Hostname: ca # implicitly ca.org1.example.com
    #    Country: US
    #    Province: California
    #    Locality: San Francisco
    #    OrganizationalUnit: Hyperledger Fabric
    #    StreetAddress: address for org # default nil
    #    PostalCode: postalCode for org # default nil

    # ---------------------------------------------------------------------------
    # "Specs"
    # ---------------------------------------------------------------------------
    # Uncomment this section to enable the explicit definition of hosts in your
    # configuration.  Most users will want to use Template, below
    #
    # Specs is an array of Spec entries.  Each Spec entry consists of two fields:
    #   - Hostname:   (Required) The desired hostname, sans the domain.
    #   - CommonName: (Optional) Specifies the template or explicit override for
    #                 the CN.  By default, this is the template:
    #
    #                              "{{.Hostname}}.{{.Domain}}"
    #
    #                 which obtains its values from the Spec.Hostname and
    #                 Org.Domain, respectively.
    #   - SANS:       (Optional) Specifies one or more Subject Alternative Names
    #                 to be set in the resulting x509. Accepts template
    #                 variables {{.Hostname}}, {{.Domain}}, {{.CommonName}}. IP
    #                 addresses provided here will be properly recognized. Other
    #                 values will be taken as DNS names.
    #                 NOTE: Two implicit entries are created for you:
    #                     - {{ .CommonName }}
    #                     - {{ .Hostname }}
    # ---------------------------------------------------------------------------
    # Specs:
    #   - Hostname: foo # implicitly "foo.org1.example.com"
    #     CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
    #     SANS:
    #       - "bar.{{.Domain}}"
    #       - "altfoo.{{.Domain}}"
    #       - "{{.Hostname}}.org6.net"
    #       - 172.16.10.31
    #   - Hostname: bar
    #   - Hostname: baz

    # ---------------------------------------------------------------------------
    # "Template"
    # ---------------------------------------------------------------------------
    # Allows for the definition of 1 or more hosts that are created sequentially
    # from a template. By default, this looks like "peer%d" from 0 to Count-1.
    # You may override the number of nodes (Count), the starting index (Start)
    # or the template used to construct the name (Hostname).
    #
    # Note: Template and Specs are not mutually exclusive.  You may define both
    # sections and the aggregate nodes will be created for you.  Take care with
    # name collisions
    # ---------------------------------------------------------------------------
    Template:
      Count: 1
      # Start: 5
      # Hostname: {{.Prefix}}{{.Index}} # default
      # SANS:
      #   - "{{.Hostname}}.alt.{{.Domain}}"

    # ---------------------------------------------------------------------------
    # "Users"
    # ---------------------------------------------------------------------------
    # Count: The number of user accounts _in addition_ to Admin
    # ---------------------------------------------------------------------------
    Users:
      Count: 1

  # ---------------------------------------------------------------------------
  # Org2: See "Org1" for full specification
  # ---------------------------------------------------------------------------
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: false
    Template:
      Count: 1
    Users:
      Count: 1

The cryptogen extend Command

cryptogen extend 명령을 사용하면 기존의 네트워크를 확장할 수 있습니다. 즉, 새로 추가된 엔티티가 필요로하는 모든 추가적인 key 자료의 생성을 의미합니다.

Syntax

cryptogen extend 명령의 문법은 다음과 같습니다.

cryptogen extend [<flags>]

crpytogen extend flags

cryptogen extend 플래그는 사용할 수 있는 다른 플래그를 가지고 있기에, 각 플래그는 관련 명령 주제에 설명되어 있습니다.

crpytogen extend [flag]

다음과 같습니다.

cryptogen extend --input="crypto-config" 
cryptogen extend --config=CONFIG

전역 cryptogen명령 플래그는 cryptogen 명령 플래그에 설명 된대로 적용됩니다.

--help

flag details

--output="crypto-config"

아티팩트를 배치 할 출력 경로

--config=CONFIG

사용할 구성 템플릿.

Usage

cryptogen extend 명령에서 사용 가능한 여러 플래그를 사용하는 몇 가지 예제 입니다.

cryptogen extend --input="crypto-config" --config=config.yaml

org3.example.com

config.yaml은 org3.example.com 라는 새로운 peer 조직을 추가합니다.

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

 Description

configtxlator 명령을 사용하여 사용자는 protobuf와 JSON 버전의 fabric 데이터 구조 사이를 변환하고 구성 업데이트를 만들 수 있습니다. 이 명령은 REST서버를 시작하여 HTTP를 통해 해당 기능을 표시하거나 명령줄 도구로 직접 사용할 수 있습니다.

Syntax

configtxlator는 4개의 하위 명령이 있습니다.

configtxlator start

REST 서버를 시작합니다.

usage: configtxlator start [<flags>]

Start the configtxlator REST server

Flags:
  --help                Show context-sensitive help (also try --help-long and --help-man).
  --hostname="0.0.0.0"  The hostname or IP on which the REST server will listen
  --port=7059           The port on which the REST server will listen

configtxlator proto_encode

JSON 문서를 protobuf 메시지로 변환합니다.

usage: configtxlator proto_encode --type=TYPE [<flags>]

Converts a JSON document to protobuf.

Flags:
  --help                Show context-sensitive help (also try --help-long and --help-man).
  --type=TYPE           The type of protobuf structure to encode to. For example, 'common.Config'.
  --input=/dev/stdin    A file containing the JSON document.
  --output=/dev/stdout  A file to write the output to.

configtxlator proto_decode

protobuf 메시지를 JSON 문서로 변환합니다.

usage: configtxlator proto_decode --type=TYPE [<flags>]

Converts a proto message to JSON.

Flags:
  --help                Show context-sensitive help (also try --help-long and --help-man).
  --type=TYPE           The type of protobuf structure to decode from. For example, 'common.Config'.
  --input=/dev/stdin    A file containing the proto message.
  --output=/dev/stdout  A file to write the JSON document to.

configtxlator compute_update

기존 config와 수정된 config에 기반하여 config 업데이트를 계산합니다.

usage: configtxlator compute_update --channel_id=CHANNEL_ID [<flags>]

Takes two marshaled common.Config messages and computes the config update which transitions between the two.

Flags:
  --help                   Show context-sensitive help (also try --help-long and --help-man).
  --original=ORIGINAL      The original config message.
  --updated=UPDATED        The updated config message.
  --channel_id=CHANNEL_ID  The name of the channel for this update.
  --output=/dev/stdout     A file to write the JSON document to.

configtxlator version

버전을 표시합니다.

usage: configtxlator version

Show version information

Flags:
  --help  Show context-sensitive help (also try --help-long and --help-man).

Examples

Decoding

fabric_block.c블록을 JSON으로 디코딩하고 stdout에 인쇄하십시오.

configtxlator proto_decode --input fabric_block.pb --type common.Block

또는 REST서버를 시작한 후 다음 벤딩 명령이 REST API를 통해 동일한 작업을 수행합니다.

curl -X POST --data-binary @fabric_block.pb "${CONFIGTXLATOR_URL}/protolator/decode/common.Block"

Ending

정책에 대한 JSON문서를 stdin에서 policy.snmp라는 파일로 변환합니다.

configtxlator proto_encode --type common.Policy --output policy.pb

또는 REST서버를 시작한 후 다음 벤딩 명령이 REST API를 통해 동일한 작업을 수행합니다.

curl -X POST --data-binary /dev/stdin "${CONFIGTXLATOR_URL}/protolator/encode/common.Policy" > policy.pb

Pipelines

original_config.pb및 modified_config.pb의 config 업데이트를 계산하여 JSON에 맞게 stdout에 디코딩 합니다.

configtxlator compute_update --channel_id testchan --original original_config.pb --updated modified_config.pb | configtxlator proto_decode --type common.ConfigUpdate

또는 REST서버를 시작한 후 다음 벤딩 명령이 REST API를 통해 동일한 작업을 수행합니다.

curl -X POST -F channel=testchan -F "original=@original_config.pb" -F "updated=@modified_config.pb" "${CONFIGTXLATOR_URL}/configtxlator/compute/update-from-configs" | curl -X POST --data-binary /dev/stdin "${CONFIGTXLATOR_URL}/protolator/encode/common.ConfigUpdate"

도구 이름은 configtx 및 translator 의 portmanteau이며 도구가 단순히 다른 동등한 데이터 표현 사이에서 변환된다는 것을 전달하기 위한 것이다. 구성을 생성하지 않습니다. configuration을 제출하거나 검색하지 않습니다. 구성 자체를 수정하지 않고, configtx 형식의 다른 보기 사이에서 일부 임의 작업만 제공할 뿐입니다.

configtxlatorREST 서버에 포함 된 구성 파일 이나 인증 또는 권한 부여 기능 은 없습니다. config.lator는 민감한 데이터, 주요 정보 또는 기타 정보에 대한 액세스 권한이 없기 때문에 서버 소유자가 다른 클라이언트에 노출될 위험이 없습니다. 그러나 사용자가 REST 서버로 보낸 데이터는 기밀 일 수 있으므로 사용자는 서버 관리자를 신뢰하거나 로컬 인스턴스를 실행하거나 CLI를 통해 작동해야합니다.

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

Description

configtxgen 명령을 통해 사용자는 채널 config와 관련된 아티팩트를 작성하고 검사 할 수 있습니다. 생성 된 아티팩트의 내용은 configtx.yaml의 내용에 의해 결정됩니다.

Syntax

configtxgen 명령은 하위 명령은 없지만 다양한 작업을 수행하기 위해 설정할 수 있는 플래그가 지원됩니다.

Usage of configtxgen:
  -asOrg string
        Performs the config generation as a particular organization (by name), only including values in the write set that org (likely) has privilege to set
  -channelID string
        The channel ID to use in the configtx (default "testchainid")
  -inspectBlock string
        Prints the configuration contained in the block at the specified path
  -inspectChannelCreateTx string
        Prints the configuration contained in the transaction at the specified path
  -outputAnchorPeersUpdate string
        Creates an config update to update an anchor peer (works only with the default channel creation, and only for the first update)
  -outputBlock string
        The path to write the genesis block to (if set)
  -outputCreateChannelTx string
        The path to write a channel creation configtx to (if set)
  -printOrg string
        Prints the definition of an organization as JSON. (useful for adding an org to a channel manually)
  -profile string
        The profile from configtx.yaml to use for generation. (default "SampleInsecureSolo")
  -version
        Show version information

Usage

초기 블록 생성

genesis_block.pb에 채널을 위한 genesis 블록을 작성하세요. orderer-system-channel에 SampleSingleMSPSoloV1_1 관해 작성하세요.

configtxgen -outputBlock genesis_block.pb -profile SampleSingleMSPSoloV1_1 -channelID orderer-system-channel

채널 생성 tx

SampleSingleMSPChannerlV1_1에 create_chan_tx.pb 에 대한 채널 생성 트랜잭션에 관해 작성하십시오.

configtxgen -outputCreateChannelTx create_chan_tx.pb -profile SampleSingleMSPChannelV1_1 -channelID application-channel-1

Inspect a genesis block

genesis_block.pb라는 이름의 genesis 블록의 내용을 JSON 형태로 화면에 출력하세요.

configtxgen -inspectBlock genesis_block.pb

Inspect a channel creation tx

create_chan_tx.pb라는 이름의 채널 생성 tx의 내용을 JSON 형태로 화면에 출력하세요.

configtxgen -inspectChannelCreateTx create_chan_tx.pb

Print an organization definition

configtx.yaml로부터 MSPDir과 같은 파라미터의 기반해서 조직을 정의하고 JSON형태로 화면에 출력하세요.(이 출력은 구성원 추가와 같은 채널 재구성 워크 플로우에 유용합니다)

 configtxgen  - printOrg  Org1

Output anchor peer tx

configtx.yaml를 기반으로 SampleSingleMShannelV1_1프로필에 정의되어 있는 조직 Org1의 앵커 피어들이 설정된 anchor_peer_tx.pb에 구성 업데이트 트랜잭션을 출력합니다.

configtxgen -outputAnchorPeersUpdate anchor_peer_tx.pb -profile SampleSingleMSPChannelV1_1 -asOrg Org1

configuration

configtxgen tool의 output은 대부분의 configtx.yaml의 내용에 의해 제어됩니다. 이 파일은 FABRIC_CFG_PATH에서 검색되며 반드시 configtxgen이 존재해야합니다. 이 configuration 파일은 편집 할 수 도 있고, CONFIGTX_ORDERER_ORDERERTYPE=kafka 와 같은 환경 변수를 성정하여 개별 특성을 겹쳐 쓸 수 있습니다. 많은 configtxgen 작업에서 프로필 이름을 제공해야합니다. 프로필은 단일 파일에서 여러 유사한 configuration을 표현하는 방법입니다. 예를 들어, 하나의 프로필은 3 개의 조직으로 된 채널을 정의 할 수 있고, 다른 프로필은 4 개의 조직으로 구성된 하나의 조직을 정의 할 수 있습니다. 파일의 길이에 부담을 주지 않고 이 작업을 수행하려면, configtx.yaml 앵커 및 참조 표준 YAML 기능에 따라 달라집니다. configuration의 기본 부분은 &OrdererDefaults 같은 앵커와 태그가 붙여져있으며 다음과 같은 참조가있는 프로필로 병합됩니다. 참고:configtxgen이 프로필 아래에서 작동하는 경우 환경 변수 재정의에 프로필 접두사를 포함할 필요가 없으며 프로필의 루트 요소에 대해 참조할 수 있습니다. 예를들어, <<: *OrdererDefaultsconfigtxgenCONFIGTX_PROFILE_SAMPLEINSECURESOLO_ORDERER_ORDERERTYPECONFIGTX를 지정하지 않고 단순히 프로필 세부 사항을 생략하고 접두어 다음에 CONFIGTX_ORDERER_ORDERERTYPE라는 프로필 이름과 관련된 요소가옵니다. 모든 가능한 구성 옵션에 대해서는 Fabric과 함께 제공된 configtx.yaml샘플을 참조하십시오 . 이 파일은 release artifacts tar 디렉토리의 config 안에서 찾을 수 있습니다. 또는 소스에서 빌드하는 경우이 sampleconfig폴더 아래에 이 파일이있을 수 있습니다 .

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

peer node

Description

peer node 하위 명령을 사용하여 관리자는 피어 노드를 시작하거나 피어 노드의 State를 확인할 수 있습니다.

Syntax

peer node 하위 명령의 구문은 다음과 같습니다. :

peer node start [flags]
peer node status

peer node start

Start Description

peer node start 명령을 통해 관리자는 피어 노드 프로세스를 시작할 수 있습니다.

피어 노드 프로세스는 구성 파일 core.yaml을 사용하여 구성할 수 있습니다. 구성 파일 core.yaml 은 환경 변수 FABRIC_CFG_PATH에 지정된 디렉토리에 있어야합니다. 도커 배포의 경우 core.yaml 은 피어 컨테이너 FABRIC_CFG_PATH 디렉토리에 미리 구성되어 있습니다. 원시 2진 배포의 경우 core.yaml 이 릴리스 아티팩트 배포에 포함됩니다. core.yaml 에 있는 구성 등록 정보는 환경 변수를 사용하여 겹쳐 쓸 수 있습니다. 예를 들어 CORE_PEER_MSPCONFIGPATH 환경 변수를 정의하여 peer.mspConfigPath 구성 등록 정보를 지정할 수 있습니다 . 여기서 ** CORE _ **는 환경 변수의 접두어입니다.

Start Syntax

peer node start 명령 구문은 다음과 같습니다. :

peer node start [flags]

Start Flags

peer node start 명령에는 다음과 같은 명령 특정 플래그가 있습니다. :

• --peer-chaincodedev 체인 노드 개발 모드에서 피어 노드를 시작합니다. 일반적으로 체인 코드 컨테이너는 피어에 의해 시작되고 유지 관리됩니다. 그러나 devlopment 모드에서 체인 코드는 사용자가 만들고 시작할 수 있습니다. 이 모드는 반복 개발을 위한 체인 코드 개발 단계에서 유용합니다. 체인 코드 자습서에서 개발 모드에 대한 자세한 내용을 확인하십시오 .

전역 peer 명령 플래그는 peer command 주제에서 설명한대로 적용됩니다. :

• –logging-level

peer node status

Status Description

peer node status 명령을 통해 관리자는 피어 노드 프로세스의 State를 볼 수 있습니다. 피어 구성에서 지정된 peer.address에서 실행 중이거나 CORE_PEER_ADDRESS 환경 변수로 대체된 피어 노드 프로세스의 State를 표시합니다.

Status Syntax

peer node status 명령 구문은 다음과 같습니다. :

peer node status

Status Flags

peer node status 명령은 명령 특정 플래그가 없습니다.

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

peer logging

Description

peer logging 하위 명령을 사용하여 관리자는 피어의 로그 수준을 동적으로 보고 구성 할 수 있습니다.

Syntax

peer logging 하위 명령의 구문은 다음과 같습니다. :

peer logging getlevel
peer logging setlevel
peer logging revertlevels

다른 하위 명령 옵션 (getlevel, setlevel 및 revertlevels)은 피어와 관련된 여러 로깅 작업과 관련이 있습니다.

각 피어 로깅 하위 명령은이 주제의 자체 절에서 옵션과 함께 설명됩니다.

peer logging getlevel

Get Level Description

peer logging getlevel 명령을 통해 관리자는 로깅 모듈의 현재 수준을 가져올 수 있습니다.

Get Level Syntax

peer logging getlevel 명령 구문은 다음과 같습니다. :

peer logging getlevel <module-name>

Get Level Flags

peer logging getlevel 명령은 명령 특정 플래그를 가지고 있지 않습니다.

Get Level Usage

다음은 peer logging getlevel 명령의 예입니다 .

• peer 모듈에 대한 로그 수준을 얻으려면 :

peer logging getlevel peer

2018-02-22 19:10:08.633 UTC [cli/logging] getLevel -> INFO 001 Current log level for peer module 'peer': DEBUG
2018-02-22 19:10:08.633 UTC [main] main -> INFO 002 Exiting.....

peer logging setlevel

Set Level Description

peer logging setlevel 명령을 사용하여 관리자는 제공된 모듈 이름 정규 표현식과 일치하는 모든 로깅 모듈의 현재 레벨을 설정할 수 있습니다.

Set Level Syntax

peer logging setlevel 명령 구문은 다음과 같습니다. :

peer logging setlevel <module-name-regular-expression> <log-level>

Set Level Flags

peer logging setlevel 명령은 명령 특정 플래그를 가지고 있지 않습니다.

Set Level Usage

다음은 peer logging setlevel 명령의 몇 가지 예입니다 .

• 정규 표현식 peer와 일치하는 모듈에 대한 로그 수준을 설정하려면 log level을 WARNING로 설정하십시오. :

peer logging setlevel peer warning
2018-02-22 19:14:51.217 UTC [cli/logging] setLevel -> INFO 001 Log level set for peer modules matching regular expression 'peer': WARNING
2018-02-22 19:14:51.217 UTC [main] main -> INFO 002 Exiting.....

^gossip 정규 표현식(즉, 모든 gossip/<submodule>형태의 gossip 로깅 서브 모듈)과 일치하는 모듈에 대한 로그 수준을 설정하려면 log level을 ERROR로 설정하십시오. :

peer logging setlevel ^gossip error

2018-02-22 19:16:46.272 UTC [cli/logging] setLevel -> INFO 001 Log level set for peer modules matching regular expression '^gossip': ERROR
2018-02-22 19:16:46.272 UTC [main] main -> INFO 002 Exiting.....

peer logging revertlevels

Revert Levels Description

관리자는 peer logging revertlevels 명령을 사용하여 피어가 시작 프로세스를 완료 할 때 모든 모듈의 로그 수준을 수준으로 되돌릴 수 있습니다.

Revert Levels Syntax

peer logging revertlevels 명령 구문은 다음과 같습니다. :

peer logging revertlevels

Revert Levels Flags

peer logging revertlevels 명령은 명령 특정 플래그를 가지고 있지 않습니다.

Revert Levels Usage

다음은 peer logging revertlevels 명령의 예입니다. :

peer logging revertlevels

2018-02-22 19:18:38.428 UTC [cli/logging] revertLevels -> INFO 001 Log levels reverted to the levels at the end of peer startup.
2018-02-22 19:18:38.428 UTC [main] main -> INFO 002 Exiting.....

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

peer version

Description

peer version 명령은 피어의 버전 정보를 표시합니다. 버전, Go 버전, OS / 아키텍처, 실험 기능이 켜져 있으면 체인 코드 정보를 표시합니다. 예 :

 peer:
   Version: 1.1.0-beta-snapshot-a6c3447e
   Go version: go1.9.2
   OS/Arch: linux/amd64
   Experimental features: true
   Chaincode:
    Base Image Version: 0.4.5
    Base Docker Namespace: hyperledger
    Base Docker Label: org.hyperledger.fabric
    Docker Namespace: hyperledger

Syntax

peer version 명령 구문은 다음과 같습니다. :

peer version

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

peer channel

Description

관리자는 peer channel 명령을 사용하여 관리자가 채널에 참여하거나 피어가 참여하는 채널을 나열하는 등 피어에서 채널 관련 작업을 수행 할 수 있습니다.

Syntax

peer channel 명령 구문은 다음과 같습니다. :

peer channel create       [flags]
peer channel fetch        [flags]
peer channel getinfo      [flags]
peer channel join         [flags]
peer channel list         [flags]
peer channel signconfigtx [flags]
peer channel update       [flags]

간결함을 위해, 우리는 단순히 명령 (peer), 하위 명령 (channel), 또는 하위 명령 옵션 (fetch)을 명령으로 참조하기도 합니다.

서로 다른 명령 옵션 ( create, fetch...)은 피어와 관련된 다양한 채널 작업과 관련이 있습니다. 예를 들어, peer channel join 명령을 사용하여 피어를 채널에 조인하거나 peer channel list 명령을 사용하여 피어가 조인된 채널을 표시하십시오.

각 피어 채널 하위 명령은 이 항목의 자체 섹션에 옵션과 함께 설명됩니다.

Flags

각 peer channel 명령 옵션에는 고유한 플래그 세트가 있으며 관련 하위 명령 옵션으로 설명됩니다.

모든 peer channel 명령 옵션에는 peer channel 명령 옵션에 적용할 수 있는 전역 플래그 집합도 있습니다.

전역 플래그는 다음과 같습니다.

• --cafile <string> 여기서 <string>은 피어가 통신중인 orderer의 인증 기관의 PEM으로 인코딩된 인증서 체인을 포함하는 파일에 대한 완전한 경로입니다. --tls 플래그와 함께 사용하십시오.
• --certfile <string> 여기서 <string>은 orderer와의 상호 인증에 사용되는 PEM 인코드 X.509 인증서가 들어있는 파일의 완전한 경로입니다. --clientauth 플래그와 함께 사용하십시오.
• --clientauth 이 플래그를 사용하여 orderer와의 상호 TLS 통신을 가능하게하십시오. --certfile 및 --keyfile 플래그와 함께 사용하십시오.
• --keyfile <string> 여기서 <string>은 orderer와 상호 인증을 위해 사용되는 PEM 인코딩 X.509 개인 키를 포함하는 파일에 대한 완전한 경로입니다. --clientauth 플래그와 함께 사용하십시오.
• -o, --orderer <string> 여기서 <string>은 피어가 통신하고 있는 orderer의 완전한 주소와 포트입니다. 포트가 지정되지 않으면 포트 7050으로 기본 설정됩니다.
• --ordererTLSHostnameOverride <string> 여기서 <string>은 TLS를 사용하여 --orderer 플래그로 지정된 orderer와 통신할 때 사용할 호스트 이름 대체입니다. 피어와 orderer 간의 통신의 TLS 핸드 셰이크 단계가 후속 메시지 교환 단계와 다른 호스트 이름을 사용하는 경우 이 플래그를 사용할 필요가 있습니다. --tls 플래그와 함께 사용하십시오.
• --tls 이 플래그를 사용하여 orderer와 TLS 통신을 사용 가능하게하십시오. --cafile에 의해 식별된 인증서는 TLS에서 Orderer를 인증하는 데 사용됩니다.

Usage

다음은 peer channel create 명령에 --orderer 전역 플래그를 사용하는 예제입니다.

• ./createchannel.txn 파일에 포함된 구성 트랜잭션에 의해 정의된 샘플 채널 mychannel을 만듭니다. orderer는 orderer.example.com:7050에 있습니다.

peer channel create -c mychannel -f ./createchannel.txn --orderer orderer.example.com:7050

2018-02-25 08:23:57.548 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-02-25 08:23:57.626 UTC [channelCmd] InitCmdFactory -> INFO 019 Endorser and orderer connections initialized
2018-02-25 08:23:57.834 UTC [channelCmd] readBlock -> DEBU 020 Received block: 0
2018-02-25 08:23:57.835 UTC [main] main -> INFO 021 Exiting.....

채널이 성공적으로 생성되었음을 나타내는 블록 0이 반환됩니다.

peer channel create

Create Description

관리자는 peer channel create 명령을 사용하여 새 채널을 만들 수 있습니다. 이 명령은 peer 명령을 사용하는 경우에도 피어에서 수행되지 않고 이 기능을 수행하기 위해 orderer에 연결합니다.

관리자는 채널을 작성하기 위해 명령을 사용하여 구성 갱신 트랜잭션을 Orderer에게 제출합니다. 이 트랜잭션은 새 채널을 만드는 데 필요한 구성 변경 사항을 설명합니다. 또한, 이 거래는 현재의 Orderer 구성에 따라 요구되는 조직에 의해 서명되어야합니다. 구성 트랜잭션은 configtxgen 명령에 의해 생성되고 peer channel signconfigtx 명령에 의해 서명될 수 있습니다.

Create Syntax

peer channel create 명령 구문은 다음과 같습니다. :

peer channel create [flags]

Create Flags

peer channel create 명령은 다음 명령 특정 플래그가 있습니다 :

• -c, --channelID <string> required, 여기서 <string>은 생성될 채널의 이름입니다.
• -f, --file <string> required , 여기서 <string>은 이 채널을 만드는 데 필요한 구성 트랜잭션을 포함하는 파일을 식별합니다. configtxgen 명령으로 생성할 수 있습니다.
• -t, --timeout <integer> optional , 여기서 <integer>는 채널 생성 시간 초과를 초 단위 로 지정합니다. 지정하지 않으면 기본값은 5 초입니다. 명령이 시간 초과되면 채널이 생성되거나 생성되지 않았을 수 있습니다.

전역 peer 명령 플래그는 다음과 같이 적용됩니다.

• -o, --orderer 필수
• --cafile 선택 과목
• --certfile 선택 과목
• --clientuth 선택 과목
• --keyfile 선택 과목
• --ordererTLSHostnameOverride 선택 과목
• --tls 선택 과목

Create Usage

다음은 peer channel create 명령 옵션의 예제입니다.

IP 주소에서 orderer.example.com:7050의 orderer를 사용하여 네트워크에 대한 새 채널 mychannel을 만듭니다. 이 채널을 작성하는 데 필요한 구성 업데이트 트랜잭션은 ./createchannel.txn 파일로 정의됩니다. 채널이 생성될 때까지 30 초 동안 기다리십시오.

peer channel create -c mychannel --orderer orderer.example.com:7050 -f ./createchannel.txn -t 30

2018-02-23 06:31:58.568 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-02-23 06:31:58.669 UTC [channelCmd] InitCmdFactory -> INFO 019 Endorser and orderer connections initialized
2018-02-23 06:31:58.877 UTC [channelCmd] readBlock -> DEBU 020 Received block: 0
2018-02-23 06:31:58.878 UTC [main] main -> INFO 021 Exiting.....

ls -l

-rw-r--r-- 1 root root 11982 Feb 25 12:24 mychannel.block

출력에 표시된 대로 mychannel 채널이 성공적으로 생성된 것을 볼 수 있습니다. 여기서 블록 0 (제로)이 이 채널의 블록 체인에 추가되고 피어에 반환됩니다. 이 채널은 mychannel.block이라는 로컬 디렉토리에 저장됩니다.

블록 0은 채널의 시작 구성을 제공하기 때문에 기원 블록(genesis block) 이라고도 합니다. 채널에 대한 모든 후속 업데이트는 채널의 블록 체인에 있는 구성 블록으로 캡처됩니다. 각 블록은 이전 구성을 대체합니다.

peer channel fetch

Fetch Description

peer channel fetch 명령은 클라이언트가 orderer로부터 블록을 가져올 수 있게 합니다. 블록에는 구성 트랜잭션 또는 사용자 트랜잭션이 포함될 수 있습니다.

클라이언트는 채널에 대한 읽기 액세스 권한이 있어야합니다. 이 명령은 이 기능을 수행하기 위해 orderer에 연결합니다. peer 클라이언트 명령이 사용 되더라도 peer에서는 수행되지 않습니다.

Fetch Syntax

peer channel fetch 명령 구문은 다음과 같습니다. :

peer channel fetch [newest|oldest|config|(block number)] [<outputFile>] [flags]

where

• newest 채널의 orderer가 사용할 수 있는 가장 최근 블록을 반환합니다. 이것은 사용자 트랜잭션 블록 또는 구성 블록일 수 있습니다. 이 옵션은 가장 최근 블록의 블록 번호를 반환합니다.
• oldest 채널의 orderer가 사용할 수 있는 가장 오래된 블록을 반환합니다. 이것은 사용자 트랜잭션 블록 또는 구성 블록일 수 있습니다. 이 옵션은 또한 가장 오래된 블록의 블록 번호를 반환합니다.
• config 채널의 orderer가 사용할 수있는 가장 최근의 구성 블록을 반환합니다. 이 옵션은 가장 최근의 구성 블록의 블록 번호를 반환합니다.
• (block number) 채널에 대해 요청된 블록을 반환합니다. 이것은 사용자 트랜잭션 블록 또는 구성 블록일 수 있습니다. 0을 지정하면이 채널의 기원 블록(genesis block)이 반환됩니다 (네트워크 Orderer가 계속 사용할 수있는 경우).
• <outputFile> 인출된 블록이 기록되는 파일의 이름을 지정합니다. <outputFile>이 지정되지 않으면 블록은 다음과 같은 이름의 파일에서 로컬 디렉토리에 기록됩니다.
  • <channelID>_newest.block
  • <channelID>_oldest.block
  • <channelID>_config.block
  • <channelID>_(block number).block

Fetch Flags

peer channel fetch 명령은 다음 명령 특정 플래그가 있습니다. :

-c, --channelID <string>

required, 여기서 <string>은 블록이 orderer로부터 fetch될 채널의 이름입니다.

전역 peer 명령 플래그도 적용됩니다.

• -o, --orderer 필수
• --cafile 선택 과목
• --certfile 선택 과목
• --clientuth 선택 과목
• --keyfile 선택 과목
• --ordererTLSHostnameOverride 선택 과목
• --tls 선택 과목

Fetch Usage

다음은 peer channel fetch 명령의 몇 가지 예입니다.

• newest 옵션을 사용하여 가장 최근의 채널 블록을 검색하고 mychannel.block 파일에 저장하십시오.

peer channel fetch newest mychannel.block -c mychannel --orderer orderer.example.com:7050

2018-02-25 13:10:16.137 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-02-25 13:10:16.144 UTC [channelCmd] readBlock -> DEBU 00a Received block: 32
2018-02-25 13:10:16.145 UTC [main] main -> INFO 00b Exiting.....

ls -l

-rw-r--r-- 1 root root 11982 Feb 25 13:10 mychannel.block

검색된 블록이 숫자 32이고 정보가 mychannel.block 파일에 기록되었음을 알 수 있습니다.

• (block number) 옵션을 사용하여 특정 블록 (이 경우 16 번 블록)을 검색하고 기본 블록 파일에 저장합니다.

검색된 블록이 숫자 16이고 정보가 기본 파일 mychannel_16.block에 기록되었음을 알 수 있습니다.

구성 블록의 경우 configtxlator 명령을 사용하여 블록 파일을 디코딩 할 수 있습니다. 디코드된 출력의 예는 이 명령을 참조하십시오. 사용자 트랜잭션 블록도 디코딩 할 수 있지만 이렇게하려면 사용자 프로그램을 작성해야합니다.

peer channel getinfo

GetInfo Description

peer channel getinfo 명령을 통해 관리자는 특정 채널에 대한 피어의 로컬 블록 체인에 대한 정보를 검색 할 수 있습니다. 여기에는 현재 블록 체인 높이와 현재 블록 및 이전 블록의 해시가 포함됩니다. 피어는 둘 이상의 채널에 조인 될 수 있습니다.

이 정보는 관리자가 특히 동일한 채널의 다른 피어와 비교하여 피어 블록 체인의 현재 State를 이해해야 할 때 유용합니다.

GetInfo Syntax

peer channel getinfo 명령 구문은 다음과 같습니다. :

peer channel getinfo [flags]

GetInfo Flags

다음은 peer channel getinfo 명령의 예입니다. :

• mychannel 채널에 대한 로컬 피어에 대한 정보를 얻습니다.

peer channel getinfo -c mychannel

2018-02-25 15:15:44.135 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
Blockchain info: {"height":5,"currentBlockHash":"JgK9lcaPUNmFb5Mp1qe1SVMsx3o/22Ct4+n5tejcXCw=","previousBlockHash":"f8lZXoAn3gF86zrFq7L1DzW2aKuabH9Ow6SIE5Y04a4="}
2018-02-25 15:15:44.139 UTC [main] main -> INFO 006 Exiting.....

mychannel 채널의 최신 블록이 블록 5임을 알 수 있습니다. 또한 채널 블록 체인의 가장 최근 블록에 대한 암호화 해시를 볼 수 있습니다.

peer channel join

Join Description

관리자는 peer channel join 명령을 사용하여 피어를 기존 채널에 연결할 수 있습니다. 관리자는 이 명령을 사용하여 피어에 채널 생성 블록을 제공함으로써 이를 달성합니다. 그러면 피어는 구성 및 다른 피어의 가용성에 따라 네트워크의 다른 피어 또는 순서대로 채널의 블록을 자동으로 검색합니다.

관리자는 peer channel fetch 명령 옵션을 사용하여 기존 채널에서 블록 0을 검색하여 이 명령에서 사용할 로컬 생성 블록을 만들 수 있습니다. peer channel create 명령은 새로운 채널이 생성 될 때 로컬 생성 블록을 반환합니다.

Join Syntax

peer channel join 명령 구문은 다음과 같습니다. :

peer channel join [flags]

Join Flags

peer channel join 명령은 다음 명령 특정 플래그가 있습니다 :

• -b, --blockpath <string>

required, 여기서 <string>은 채널 생성 블록을 포함하는 파일을 식별합니다. 이 블록은 peer channel fetch 명령을 사용하여 검색하거나 채널에서 블록 0을 요청 하거나 peer channel create 명령을 사용하여 검색할 수 있습니다.

이 명령은 orderer와 상호 작용하지 않으므로 전역(global) peer 명령 플래그는 적용되지 않습니다.

Join Usage

다음은 peer channel join 명령의 예입니다.

• ./mychannel.genesis.block 파일로 식별된 기원 블록(genesis block)에 정의된 채널에 피어를 참여시킵니다. 이 예에서 채널 블록은 이전에 peer channel fetch 명령에 의해 검색되었습니다.

peer channel join -b ./mychannel.genesis.block

2018-02-25 12:25:26.511 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-02-25 12:25:26.571 UTC [channelCmd] executeJoin -> INFO 006 Successfully submitted proposal to join channel
2018-02-25 12:25:26.571 UTC [main] main -> INFO 007 Exiting.....

피어가 성공적으로 채널에 가입을 요청했음을 알 수 있습니다.

peer channel list

List Description

관리자는 peer channel list 명령을 사용하여 피어가 가입된 채널을 나열 할 수 있습니다.

List Syntax

peer channel list 명령 구문은 다음과 같습니다. :

peer channel list [flags]

List Flags

peer channel list 명령은 특정 플래그가 없습니다.

이 명령은 orderer와 상호 작용하지 않으므로 글로벌(global) peer 명령 플래그는 적용되지 않습니다.

List Usage

다음은 peer channel list 명령의 예입니다.

• 피어가 가입된 채널을 나열하십시오.

peer channel list

2018-02-25 14:21:20.361 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
Channels peers has joined:
mychannel
2018-02-25 14:21:20.372 UTC [main] main -> INFO 006 Exiting.....

피어가 mychannel 채널에 가입되어 있음을 볼 수 있습니다.

peer channel signconfigtx

SignConfigTx Description

peer channel signconfigtx 명령은 관리자가 orderer에게 제출하기 전에 피어의 ID 자격 증명을 사용하여 구성 트랜잭션에 서명하는 데 도움이 됩니다. 일반적인 구성 트랜잭션에는 채널 생성 또는 채널 구성 업데이트가 포함됩니다.

관리자는 구성 트랜잭션을 설명하는 signconfigtx 명령에 입력 파일을 제공합니다. 그런 다음 명령은 피어의 공개 ID를 파일에 추가하고 피어의 개인 키로 전체 페이로드에 서명합니다. 이 명령은 로컬 MSP에 저장된 피어의 공개 및 개인 자격 증명을 사용합니다. 새 파일이 생성되지 않습니다. 입력 파일이 제 위치에서 갱신됩니다.

signconfigtx는 구성 트랜잭션에만 서명합니다. 그것을 생성하지도 않으며 orderer에게 제출하지도 않습니다. 일반적으로 구성 트랜잭션은 이 configtxgen 명령을 사용하여 이미 생성된 후 peer channel update와 같은 적절한 명령에 의해 orderer에게 제출됩니다.

SignConfigTx Syntax

peer channel signconfigtx 명령 구문은 다음과 같습니다. :

peer channel signconfigtx [flags]

SignConfigTx Flags

peer channel signconfigtx 명령은 다음 명령 특정 플래그가 있습니다. :

• -f, --file <string>

필수, 여기서 <string>은 피어를 대신하여 서명할 채널 구성 트랜잭션을 포함하는 파일을 식별합니다.

이 명령은 순서 지정자와 상호 작용하지 않으므로 글로벌(global) peer 명령 플래그는 적용되지 않습니다.

SignConfigTx Usage

다음은 peer channel signconfigtx 명령의 예입니다.

• ./updatechannel.txn 파일에 정의된 channel update 트랜잭션에 서명 하십시오. 이 예는 명령 전후의 구성 트랜잭션 파일을 나열합니다.

ls -l

-rw-r--r--  1 anthonyodowd  staff   284 25 Feb 18:16 updatechannel.tx

peer channel signconfigtx -f updatechannel.tx

2018-02-25 18:16:44.456 GMT [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-02-25 18:16:44.459 GMT [main] main -> INFO 002 Exiting.....

ls -l

-rw-r--r--  1 anthonyodowd  staff  2180 25 Feb 18:16 updatechannel.tx

updatechannel.tx 파일의 크기가 284 바이트에서 2180 바이트로 증가하여 피어가 구성 트랜잭션에 성공적으로 서명했음을 알 수 있습니다 .

peer channel update

Update Description

관리자는 peer channel update 명령을 사용하여 기존 채널을 업데이트 할 수 있습니다.

채널을 갱신하기 위해 관리자는 명령을 사용하여 필요한 채널 구성 변경 사항을 설명하는 구성 트랜잭션을 Orderer에게 제출합니다. 이 거래는 현재 채널 구성에 정의된 필수 조직에서 서명해야합니다. 구성 트랜잭션은 configtxgen 명령에 의해 생성되고 peer channel signconfigtx 명령에 의해 서명 될 수 있습니다.

갱신 트랜잭션은 명령에 의해 명령 변경자에게 권한이 부여 된 것을 확인한 다음 구성 블록을 채널의 모든 피어에 분배하는 orderer에게 전송됩니다. 이러한 방식으로 채널의 모든 피어는 채널 구성의 일관된 복사본을 유지 관리합니다.

Update Syntax

peer channel update 명령 구문은 다음과 같습니다, :

peer channel update [flags]

Update flags

peer channel update 명령은 다음 명령 특정 플래그가 있습니다. :

• -c, --channelID <string> required, 여기서 <string>은 업데이트 할 채널의 이름입니다.
• -f, --file <string> required, 여기서 <string>은 트랜잭션 구성 파일을 식별합니다. 이 파일에는 이 채널에 필요한 구성 변경 사항이 포함되어 있으며 configtxgen 명령을 사용하여 생성 할 수 있습니다.

전역 peer 명령 플래그는 다음과 같이 적용됩니다.

• -o, --orderer 필수
• --cafile 선택
• --certfile 선택
• --clientuth 선택
• --keyfile 선택
• --ordererTLSHostnameOverride 선택
• --tls 선택

Update Usage

다음은 peer channel update 명령의 예입니다.

• ./updatechannel.txn 파일에 정의된 구성 트랜잭션을 사용하여 mychannel 채널을 업데이트 하십시오. ip address의 orderer.example.com:7050에 있는 orderer를 사용하여 구성 트랜잭션을 채널의 모든 피어로 전송하여 채널 구성 사본을 갱신하십시오.

peer channel update -c mychannel -f ./updatechannel.txn -o orderer.example.com:7050

2018-02-23 06:32:11.569 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-02-23 06:32:11.626 UTC [main] main -> INFO 010 Exiting.....

• 이 시점에서  mychannel 채널이 성공적으로 업데이트되었습니다.

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