Endorsement Policy내용

https://stackoverflow.com/questions/48108709/what-are-members-and-admins-in-endorsement-policy-of-hyperledger-fabric

Endorsement policies

Endorsement Policy은 트랜잭션이 적절하게 보증되는지 여부를 결정하는 방법을 피어에게 지시하는 데 사용됩니다. 피어가 트랜잭션을 수신하면 트랜잭션 유효성 검증 플로우의 일부로 트랜잭션의 체인 코드와 연관된 VSCC (유효성 검증 시스템 체인 코드)를 호출하여 트랜잭션의 유효성을 판별합니다. 보증(endorsing)이 많은 피어로부터 하나 이상의 보증(endorsement)을 포함한다는 것을 상기하십시오. VSCC는 다음 결정을 내려야합니다 :

  • 모든 보증은 유효합니다 (즉, 예상 메시지에 대한 유효한 인증서의 유효한 서명입니다)
  • 적절한 수의 보증이 있다.
  • 보증은 예상된 소스에서 나온 것입니다.

Endorsement Policy은 두 번째 및 세 번째 점을 지정하는 방법입니다.

Endorsement policy syntax in the CLI

CLI에서는 간단한 언어를 사용하여 원칙에 대한 부울 표현에 대한 정책을 표현합니다.

principal은 서명자의 신원을 확인하고 서명자가 해당 MSP 내에서 갖는 역할을 확인하는 임무를 맡은 MSP의 관점에서 설명합니다. 구성원(member) , 관리자(admin) , 클라이언트(client) 및 피어(peer)의 네 가지 역할이 지원됩니다 . principal은 MSPROLE로 설명됩니다. 여기서 MSP는 필수 MSP의 ID이며, ROLEmemberadminclient및 peer의 네 개의 문자열 중 하나입니다. 유효한 주체의 예로는 'Org0.admin'Org0 MSP의 모든 관리자 ) 또는 'Org1.member'Org1 MSP의 모든 구성원), 'Org1.client'Org1 MSP 클라이언트 ) 및 'Org1.peer'Org1 MSP의 피어 )입니다.

언어 구문은 다음과 같습니다. :

EXPR(E[, E...])

여기에서 EXPR은 두 개의 부울 표현식을 나타내는 AND 또는 OR이고 E는 principal(위에 설명 된 구문을 사용하는) 이거나 EXPR에 대한 다른 중첩 호출입니다.

예 :
  • AND('Org1.member', 'Org2.member', 'Org3.member')는 3 명의 주체(principal) 각자에게서 1 개의 서명을 요구한다.
  • OR('Org1.member', 'Org2.member')은 두 명의 주체(principal) 중 한 명에게 1 개의 서명을 요구한다.
  • OR('Org1.member', AND('Org2.member', 'Org3.member'))Org1 MSP의 멤버로부터 하나의 서명 또는, Org2 MSP의 멤버로부터 하나의 서명을, 그리고 Org3 MSP의 멤버로부터 하나의 서명을 요청합니다.

Specifying endorsement policies for a chaincode

체인 코드 배포자는 이 언어를 사용하여 지정된 정책에 대해 체인 코드의 인증을 확인하도록 요청할 수 있습니다.

Note! 인스턴스 생성시 지정되지 않은 경우 Endorsement Policy은 기본적으로 "채널에 있는 조직의 모든(any) 구성원"으로 지정됩니다. 예를 들어 'Org1' 및 'Org2'가 포함된 채널의 기본 Endorsement Policy은 'OR ('Org1.member ','Org2.member ')입니다.

-P 스위치를 사용하여 인스턴스를 생성 할 때 정책을 지정할 수 있으며 그 뒤에 정책이 옵니다.

 :

peer chaincode instantiate -C <channelid> -n mycc -P "AND('Org1.member', 'Org2.member')"

이 명령은 Org1 및 Org2 구성원이 트랜잭션에 서명해야하는 AND('Org1.member', 'Org2.member') 정책으로 chaincode mycc를 배포 합니다.

ID 분류가 활성화된 경우(Membership Service Providers (MSP) 참조) PEER 역할을 사용하여 peers에게만 보증을 제한할 수 있습니다.

 :

peer chaincode instantiate -C <channelid> -n mycc -P "AND('Org1.peer', 'Org2.peer')"

Note! 인스턴스 생성 후 채널에 추가된 새 조직은 체인 코드를 쿼리할 수 ​​있지만 (쿼리에 채널 정책 및 체인 코드에 의해 적용되는 모든 응용 프로그램 수준 검사가 정의한 적절한 권한을 가지고 있음에도 불구하고 체인 코드로 승인된 트랜잭션을 커밋 할 수는 없습니다). 새로운 조직의 보증을 통해 트랜잭션을 커밋 할 수 있도록 Endorsement Policy을 수정해야합니다(Upgrade and Invoke Chaincode 참조).


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

Channel Configuration (configtx)

Hyperledger 패브릭 블록 체인 네트워크의 공유 구성은 채널 당 하나의 컬렉션 구성 트랜잭션에 저장됩니다. 각 구성 트랜잭션은 일반적으로 더 짧은 이름 configtx로 참조 됩니다.

채널 구성에는 다음과 같은 중요한 속성이 있습니다.

  1. Versioned : 구성의 모든 요소에는 모든 수정 작업을 수행 할 수 있는 관련 버전이 있습니다. 또한 커밋된 모든 구성은 시퀀스 번호를 받습니다.
  2. Permissioned : 구성의 각 요소에는 해당 요소에 대한 수정이 허용되는지 여부를 결정하는 관련 정책이 있습니다. 이전 configtx 사본이 있고 추가 정보가 없는 사용자는 이 정책을 기반으로 새 구성의 유효성을 확인할 수 있습니다.
  3. Hierarchical : 루트 구성 그룹에는 하위 그룹이 포함되며 계층 구조의 각 그룹에는 연관된 값과 정책이 있습니다. 이러한 정책은 계층을 활용하여 하위 수준의 정책에서 한 수준의 정책을 유도합니다.

Anatomy of a configuration

구성은 다른 트랜잭션이 없는 블록에 HeaderType_CONFIG 유형의 트랜잭션으로 저장됩니다. 이러한 블록을 구성 블록(Configuration Blocks) 이라고하며 , 그 중 첫 번째 블록을 기원 블록(Genesis Block) 이라고 합니다.

구성을 위한 프로토 구조는 fabric/protos/common/configtx.proto에 저장됩니다. HeaderType_CONFIG 유형의 언벨로프(Envelope)는 Payload data 필드로 ConfigEnvelope 메시지를 인코딩합니다. ConfigEnvelope의 프로토 타입은 다음과 같이 정의됩니다 :

message ConfigEnvelope {
    Config config = 1;
    Envelope last_update = 2;
}

이 last_update 필드는 아래의 구성 업데이트 섹션에서 정의되지만 구성을 검증할 때만 필요합니다. 대신 현재 커밋된 구성은 Config 메시지를 포함하는 config 필드에 저장됩니다.

message Config {
    uint64 sequence = 1;
    ConfigGroup channel_group = 2;
}

sequence 번호는 커밋된 구성마다 하나씩 증가합니다. channel_group 필드는 구성을 포함하는 루트 그룹입니다. ConfigGroup 구조는 재귀 정의되며, 각 그룹에는 값과 정책을 포함하는 각각의 그룹의 트리를 구축합니다. 그것은 다음과 같이 정의됩니다 :

message ConfigGroup {
    uint64 version = 1;
    map<string,ConfigGroup> groups = 2;
    map<string,ConfigValue> values = 3;
    map<string,ConfigPolicy> policies = 4;
    string mod_policy = 5;
}

ConfigGroup은 재귀적 구조이므로 계층적인 배열을가집니다. 다음 예는 golang 표기법을 명확하게 표현한 것입니다 :

// Assume the following groups are defined
var root, child1, child2, grandChild1, grandChild2, grandChild3 *ConfigGroup

// Set the following values
root.Groups["child1"] = child1
root.Groups["child2"] = child2
child1.Groups["grandChild1"] = grandChild1
child2.Groups["grandChild2"] = grandChild2
child2.Groups["grandChild3"] = grandChild3

// The resulting config structure of groups looks like:
// root:
//     child1:
//         grandChild1
//     child2:
//         grandChild2
//         grandChild3

각 그룹은 구성 계층에서 수준을 정의하며 각 그룹은 관련된 값 집합 (문자열 키로 인덱싱 됨)과 정책 (문자열 키로 인덱싱 됨)을 갖습니다.

값은 다음과 같이 정의됩니다 :

message ConfigValue {
    uint64 version = 1;
    bytes value = 2;
    string mod_policy = 3;
}

정책은 다음과 같이 정의됩니다 :

message ConfigPolicy {
    uint64 version = 1;
    Policy policy = 2;
    string mod_policy = 3;
}

값, 정책 및 그룹에는 모두 version과 mod_policy가 있습니다. 요소의 version은 해당 엘리먼트가 수정 될 때마다 증가됩니다. mod_policy는 해당 요소를 수정하는 데 필요한 서명을 적용하는 데 사용됩니다. 그룹의 경우 수정은 값, 정책 또는 그룹 맵에 요소를 추가하거나 제거하는 것입니다 (또는 mod_policy 변경). 값 및 정책의 경우 수정은 값 및 정책 필드를 각각 변경합니다 (또는 mod_policy 변경). 각 요소의 mod_policy는 현재 구성 수준의 컨텍스트에서 평가됩니다. Channel.Groups["Application"]에 정의된 다음 mod 정책 예제를 고려하십시오 (여기서 golang 맵 참조 구문을 사용하므로Channel.Groups["Application"].Policies["policy1"]은 기본 Channel 그룹의 Application 그룹의 Policies 맵 policy1 정책을 참조하십시오).

  • policy1은 Channel.Groups["Application"].Policies["policy1"]에 매핑됩니다.
  • Org1/policy2Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]에 매핑됩니다.
  • /Channel/policy3은 Channel.Policies["policy3"]에 매핑됩니다.

mod_policy가 존재하지 않는 정책을 참조하는 경우 해당 항목을 수정할 수 없습니다.

Configuration updates

구성 업데이트는 HeaderType_CONFIG_UPDATE 유형의 Envelope 메시지로 제출됩니다. 트랜잭션의 Payload data는 marshaled된 ConfigUpdateEnvelope입니다. ConfigUpdateEnvelope는 다음과 같이 정의됩니다.

message ConfigUpdateEnvelope {
    bytes config_update = 1;
    repeated ConfigSignature signatures = 2;
}

이 signatures 필드에는 구성 업데이트를 인증하는 일련의 서명이 들어 있습니다. 메시지 정의는 다음과 같습니다 :

message ConfigSignature {
    bytes signature_header = 1;
    bytes signature = 2;
}

signature_header는 표준 트랜잭션에 정의된 대로 서명은 signature_header 바이트와 ConfigUpdateEnvelope 메시지의 config_update 바이트의 연결을 넘습니다.

ConfigUpdateEnvelope config_update 바이트는 다음과 같이 정의된 marshaled된 ConfigUpdate 메시지입니다 :

message ConfigUpdate {
    string channel_id = 1;
    ConfigGroup read_set = 2;
    ConfigGroup write_set = 3;
}

channel_id는 업데이트가 바인딩된 채널 ID이며, 이 재구성을 지원하는 서명의 범위를 지정하는 데 필요합니다.

read_set은 version 필드만 설정되고 다른 필드는 채워져서는 안되는 것으로 지정된 기존 구성의 하위 집합을 지정합니다. 특정 ConfigValue value 또는 ConfigPolicy policy 필드는 read_set에 절대로 설정해서는 안됩니다. ConfigGroup은 config 트리의 더 깊은 요소를 참조할 수 있도록, 맵 필드의 하위 집합을 채울 수 있습니다. 예를 들어, Application 그룹을 read_set에 포함시키려면 그 부모 (Channel 그룹)도 읽기 세트에 포함되어야하지만 Channel 그룹은 모든 키를 채울 필요가 없습니다. Orderer group 키 또는 아무 valuespolicies 키 중 하나를 선택하십시오.

write_set는 수정된 구성을 지정합니다. 구성의 계층적 특성으로 인해 계층 구조의 깊숙한 요소에 대한 쓰기는 해당 write_set 계층의 상위 수준 요소를 포함해야합니다. 그러나, 동일한 버전의 read_set에도 지정된 write_set의 요소는 read_set에서와 같이 드문드문하게 지정해야 합니다.

예를 들어, 구성이 주어진 경우 :

Channel: (version 0)
    Orderer (version 0)
    Appplication (version 3)
       Org1 (version 2)

Org1을 수정하는 구성 업데이트를 제출하려면 read_set이 다음과 같습니다 :

Channel: (version 0)
    Application: (version 3)

write_set은 다음과 같습니다.

Channel: (version 0)
    Application: (version 3)
        Org1 (version 3)

CONFIG_UPDATE가 수신되면 orderer는 다음을 수행하여 결과 CONFIG를 계산합니다.

  1. channel_id및 read_set을 확인합니다. read_set의 모든 요소는 지정된 버전에 존재해야합니다.
  2. read_set에 동일한 버전으로 나타나지 않는 write_set의 모든 요소를 ​​수집하여 업데이트 세트(update set)를 계산합니다 .
  3. 업데이트 세트의 각 요소가 요소 업데이트의 버전 번호를 정확히 1만큼 증가시키는 지 확인합니다.
  4. ConfigUpdateEnvelope에 첨부된 서명 세트가 업데이트 세트의 각 요소에 대해 mod_policy를 충족하는지 확인합니다.
  5. 업데이트 세트를 현재 구성에 적용하여 새로운 전체 버전의 구성을 계산합니다.
  6. 새 구성을 ConfigEnvelope에 기록하고 CONFIG_UPDATE를 last_update 필드로, config 필드에 인코딩된 새 구성을 증가된 sequence 값과 함께 기록합니다.
  7. 새 ConfigEnvelope를 CONFIG 유형의 Envelope에 기록하고 궁극적으로 이것을 새로운 구성 블록에 단독 트랜잭션으로 씁니다.

피어 (또는 다른 Deliver 수신자)가 이 구성 블록을 수신하면 현재 구성에 last_update 메시지를 적용하고 순서대로 계산된 config 필드에 올바른 새로운 구성이 들어 있는지 확인하여 구성이 적절하게 유효성이 검증되었는지 확인해야합니다 .

Permitted configuration groups and values

유효한 구성은 다음 구성의 서브 세트입니다. 여기서 우리는 peer.<MSG> 표기법을 사용하여 value 필드가 fabric/protos/peer/configuration.proto에 정의된 <MSG> 이름의 marshaled된 프로토 메시지임을 나타내는 ConfigValue를 정의합니다. common.<MSG>msp.<MSG> 및 orderer.<MSG>의 표기법은 비슷하지만, fabric/protos/common/configuration.proto, fabric/protos/msp/mspconfig.protofabric/protos/orderer/configuration.proto에서 정의된 메시지를 사용합니다.

키 {{org_name}}과 {{consortium_name}}은 임의의 이름을 나타내며 다른 이름으로 반복될 수 있는 요소를 나타냅니다.

&ConfigGroup{
    Groups: map<string, *ConfigGroup> {
        "Application":&ConfigGroup{
            Groups:map<String, *ConfigGroup> {
                {{org_name}}:&ConfigGroup{
                    Values:map<string, *ConfigValue>{
                        "MSP":msp.MSPConfig,
                        "AnchorPeers":peer.AnchorPeers,
                    },
                },
            },
        },
        "Orderer":&ConfigGroup{
            Groups:map<String, *ConfigGroup> {
                {{org_name}}:&ConfigGroup{
                    Values:map<string, *ConfigValue>{
                        "MSP":msp.MSPConfig,
                    },
                },
            },

            Values:map<string, *ConfigValue> {
                "ConsensusType":orderer.ConsensusType,
                "BatchSize":orderer.BatchSize,
                "BatchTimeout":orderer.BatchTimeout,
                "KafkaBrokers":orderer.KafkaBrokers,
            },
        },
        "Consortiums":&ConfigGroup{
            Groups:map<String, *ConfigGroup> {
                {{consortium_name}}:&ConfigGroup{
                    Groups:map<string, *ConfigGroup> {
                        {{org_name}}:&ConfigGroup{
                            Values:map<string, *ConfigValue>{
                                "MSP":msp.MSPConfig,
                            },
                        },
                    },
                    Values:map<string, *ConfigValue> {
                        "ChannelCreationPolicy":common.Policy,
                    }
                },
            },
        },
    },

    Values: map<string, *ConfigValue> {
        "HashingAlgorithm":common.HashingAlgorithm,
        "BlockHashingDataStructure":common.BlockDataHashingStructure,
        "Consortium":common.Consortium,
        "OrdererAddresses":common.OrdererAddresses,
    },
}

Orderer system channel configuration

Ordering 시스템 채널은 Ordering 매개 변수와 채널 생성을 위한 컨소시엄을 정의해야 합니다. Ordering 서비스를 위해서는 정확히 하나의 Ordering 시스템 채널이 있어야하며, 생성된 (또는 더 정확하게 부트스트랩 된) 첫 번째 채널입니다. Ordering 시스템 채널 기원(genesis) 구성 내에서 응용 프로그램 섹션을 정의하지 않는 것이 좋습니다. 그러나 테스트를 위해 수행할 수 있습니다. Ordering 시스템 채널에 대한 읽기 권한을 가진 회원은 모든 채널 생성을 볼 수 있으므로 이 채널의 액세스가 제한되어야합니다.

Ordering 매개 변수는 config의 다음 서브 세트로 정의됩니다.

&ConfigGroup{
    Groups: map<string, *ConfigGroup> {
        "Orderer":&ConfigGroup{
            Groups:map<String, *ConfigGroup> {
                {{org_name}}:&ConfigGroup{
                    Values:map<string, *ConfigValue>{
                        "MSP":msp.MSPConfig,
                    },
                },
            },

            Values:map<string, *ConfigValue> {
                "ConsensusType":orderer.ConsensusType,
                "BatchSize":orderer.BatchSize,
                "BatchTimeout":orderer.BatchTimeout,
                "KafkaBrokers":orderer.KafkaBrokers,
            },
        },
    },

ordering에 참여하는 각 조직에는 Orderer 그룹 아래에 그룹 요소가있습니다. 이 그룹은 해당 조직에 대한 암호화 신원 정보를 포함하는 단일 매개 변수 MSP를 정의합니다. Orderer 그룹의 Values에 따라 Orderer 노드가 작동하는 방식이 결정됩니다. 채널마다 존재하므로 orderer.BatchTimeout은 한 채널에서 다른 채널과 다르게 지정될 수 있습니다.

시작시, orderer는 많은 채널에 대한 정보가 들어있는 파일 시스템에 직면하게됩니다. orderer는 컨소시엄 그룹이 정의된 채널을 식별하여 시스템 채널을 식별합니다. 컨소시엄 그룹의 구조는 다음과 같습니다.

&ConfigGroup{
    Groups: map<string, *ConfigGroup> {
        "Consortiums":&ConfigGroup{
            Groups:map<String, *ConfigGroup> {
                {{consortium_name}}:&ConfigGroup{
                    Groups:map<string, *ConfigGroup> {
                        {{org_name}}:&ConfigGroup{
                            Values:map<string, *ConfigValue>{
                                "MSP":msp.MSPConfig,
                            },
                        },
                    },
                    Values:map<string, *ConfigValue> {
                        "ChannelCreationPolicy":common.Policy,
                    }
                },
            },
        },
    },
},

각 컨소시엄은 ordering 조직의 조직 구성원과 마찬가지로 구성원 집합을 정의합니다. 각 컨소시엄은 ChannelCreationPolicy 또한 정의합니다. 이 정책은 채널 생성 요청을 승인하는 데 적용됩니다. 일반적으로 이 값은 채널의 새 구성원이 채널 생성을 승인하도록 요구하는 ImplicitMetaPolicy로 설정됩니다. 채널 생성에 대한 자세한 내용은이 문서 뒷부분에 나와 있습니다.

Application channel configuration

애플리케이션 구성은 애플리케이션 유형 트랜잭션을 위해 설계된 채널을 위한 것입니다. 그것은 다음과 같이 정의됩니다 :

&ConfigGroup{
    Groups: map<string, *ConfigGroup> {
        "Application":&ConfigGroup{
            Groups:map<String, *ConfigGroup> {
                {{org_name}}:&ConfigGroup{
                    Values:map<string, *ConfigValue>{
                        "MSP":msp.MSPConfig,
                        "AnchorPeers":peer.AnchorPeers,
                    },
                },
            },
        },
    },
}

Orderer 섹션과 마찬가지로 각 조직은 그룹으로 인코딩됩니다. 그러나 MSP 신원 정보만 인코딩하는 대신 각 조직은 AnchorPeers의 목록을 추가로 인코딩합니다. 이 목록은 다른 조직의 피어가 피어 가십 네트워킹(peer gossip networking)을 위해 서로 접촉할 수 있게 합니다.

응용 프로그램 채널은 이 매개 변수의 결정적 업데이트를 허용하기 위해 oderer org 및 합의(consensus) 옵션의 사본을 인코딩하므로 orderer 시스템 채널 구성의 동일한 Orderer 섹션이 포함됩니다. 그러나 응용 프로그램 관점에서 이것은 크게 무시 될 수 있습니다.

Channel creation

orderer가 존재하지 않는 채널에 대해 CONFIG_UPDATE를 수신하면, orderer는 이것이 채널 작성 요청이어야한다고 가정하고 다음을 수행합니다.

  1. orderer는 채널 생성 요청이 수행될 컨소시엄을 식별합니다. 최상위 레벨 그룹의 Consortium 값을 보고 이를 수행합니다 .
  2. orderer는 Application그룹에 포함된 조직이 해당 컨소시엄에 포함된 조직의 하위 집합이며 ApplicationGroup이 version 1로 설정되어 있는지 확인합니다.
  3. orderer는 컨소시엄에 회원이 있는 경우 새 채널에도 애플리케이션 회원 (생성 컨소시엄 및 멤버가 없는 채널은 테스트에만 유용함)이 있는지 확인합니다.
  4. orderer는 ordering 시스템에서 Orderer 그룹을 가져와서 새로 지정된 멤버로 Application 그룹을 만들고 해당 mod_policy를 컨소시엄 구성에 지정된대로 ChannelCreationPolicy로 지정하여 템플릿 구성을 만듭니다. 정책은 새로운 구성 컨텍스트에서 평가되므로 ALL 구성원을 요구하는 정책에는 컨소시엄의 모든 구성원이 아닌 모든 새 채널 구성원의 서명이 필요합니다.
  5. 그러면 orderer는 CONFIG_UPDATE를 이 템플릿 구성에 대한 갱신 사항으로 적용합니다. CONFIG_UPDATEApplication 그룹 (해당 version은 1)에 수정 사항을 적용하기 때문에 구성 코드는 ChannelCreationPolicy에 대해 이러한 업데이트의 유효성을검사합니다. 채널 생성에 개별 조직의 앵커 피어 (peer peer)와 같은 다른 수정 사항이 포함되어있는 경우 요소에 해당하는 mod 정책이 호출됩니다.
  6. 새 채널 구성을 사용하는 새로운 CONFIG 트랜잭션은 ordering 시스템 채널에서 ordering을 위해 포장되어 전송됩니다. ordering 후에 채널이 생성됩니다.

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

Membership Service Providers (MSP)

이 문서는 MSP의 설정 및 모범 사례에 대한 세부 정보를 제공합니다.

멤버쉽 서비스 공급자(MSP)는 멤버십 운영 아키텍처의 추상화를 제공하는 것을 목표로하는 구성 요소입니다.

특히 MSP는 인증서 발급 및 유효성 검사 및 사용자 인증에 대한 모든 암호화 메커니즘 및 프로토콜을 추상화합니다. MSP는 자신의 신원 개념과 신원을 관리 (신원 확인) 및 인증 (서명 생성 및 검증)하는 규칙을 정의 할 수 있습니다.

Hyperledger 패브릭 블록 체인 네트워크는 하나 이상의 MSP에 의해 관리 될 수 있습니다. 이는 멤버쉽 작업의 모듈화와 다양한 멤버쉽 표준 및 아키텍처 간의 상호 운용성을 제공합니다.

이 문서의 나머지 부분에서는 Hyperledger Fabric에서 지원하는 MSP 구현의 설정에 대해 자세히 설명하고 그 사용과 관련된 모범 사례에 대해 논의합니다.

MSP 구성

MSP의 인스턴스를 설정하려면 Peer 및 Orderer 서명을 가능하게하기 위해 각 Peer 및 Orderer에게 로컬로 구성을 지정하고 Peer, Orderer, 클라이언트 ID 유효성 검사 및 각 서명 확인을 가능하게 하는 채널에서 구성을 지정해야합니다 (인증 ) 모든 채널 회원에 의해.

우선, 각각의 MSP에 대한 이름이 네트워크에 해당 MSP를 참조하기 위해 지정 될 필요 (예를 들어 msp1org2 및 org3.divA). 컨소시엄, 조직 또는 조직 부서를 대표하는 MSP의 멤버십 규칙을 채널에서 참조하는 이름입니다. 이를 MSP Identifier 또는 MSP ID 라고도합니다 . MSP 식별자는 MSP 인스턴스별로 고유해야합니다. 예를 들어, 동일한 식별자를 가진 두 개의 MSP 인스턴스가 시스템 채널 genesis에서 탐지되어야합니다. Orderer 설정은 실패합니다.

MSP의 기본 구현의 경우 ID (인증서) 유효성 검사 및 서명 확인을 허용하기 위해 일련의 매개 변수를 지정해야합니다. 이 매개 변수는 RFC5280 에 의해 추론되며 다음을 포함합니다.

  • root of trust 를 구성하는 자체 서명 (X.509) 인증서 목록
  • 이 공급자가 인증서 유효성 검사를 위해 고려하는 중간 CA를 나타내는 X.509 인증서 목록. 이러한 인증서는 신뢰의 루트에있는 인증서 중 하나만으로 인증 받아야합니다. 중간 CA는 선택적 매개 변수입니다.
  • 이 MSP의 관리자를 나타낼 수 있는 신뢰할 수있는 인증서 경로가있는 X.509 인증서 목록입니다. 이 인증서의 소유자는 이 MSP 구성 (예 : 루트 CA, 중간 CA)에 대한 변경을 요청할 수 있는 권한이 있습니다.
  • 이 MSP의 유효한 구성원이 X.509 인증서에 포함해야하는 조직 단위 목록 이것은 선택적 구성 매개 변수로, 예를 들어 여러 조직에서 동일한 신뢰 루트와 중간 CA를 활용하고 해당 구성원에 대해 OU 필드를 예약한 경우 사용됩니다
  • 나열된 (중간 또는 루트) MSP 인증 기관 중 정확히 하나에 각각 해당하는 인증서 해지 목록 (CRL) 목록 이것은 선택적 매개 변수입니다.
  • TLS 인증서 의 TLS root 를 구성하는 자체 서명 (X.509) 인증서 목록입니다 .
  • 이 공급자가 고려하는 중간 TLS CA를 나타내는 X.509 인증서 목록; 이 인증서는 TLS root of trust의 인증서 중 하나만으로 인증 받아야합니다. 중간 CA는 선택적 매개 변수입니다.

이 MSP 인스턴스의 유효한 ID는 다음 조건을 충족해야합니다.

  • 이들은 X.509 인증서의 형태로되어 있으며 신뢰할 수 있는 인증서 루트와 정확히 일치하는 하나의 인증서 경로가 있습니다.
  • CRL에는 포함되지 않습니다.
  • 또한 X.509 인증서 구조의 OU 필드에 MSP 구성의 조직 구성 단위 중 하나 이상을 나열합니다.

현재 MSP 구현에서 ID의 유효성에 대한 자세한 내용은 MSP Identity Validity Rules(MSP ID 유효성 규칙) 을 참조하십시오 .

검증 관련 매개 변수 외에도 MSP가 서명 또는 인증을 위해 인스턴스화 된 노드를 활성화하려면 다음을 지정해야합니다.

  • 노드에서 서명하는 데 사용되는 서명 키 (현재 ECDSA 키만 지원됨)
  • 노드의 X.509 인증서로,이 MSP의 확인 매개 변수 아래에 유효한 ID입니다.

MSP ID는 절대로 만료되지 않습니다. 해당 CRL에 추가하여 취소할 수 있습니다. 또한 현재 TLS 인증서 해지 시행을 지원하지 않습니다.

How to generate MSP certificates and their signing keys?

X.509 인증서를 생성하여 MSP 구성을 제공하려면 응용 프로그램에서 Openssl 을 사용할 수 있습니다. 우리는 Hyperledger Fabric에서 RSA 키를 포함한 인증서를 지원하지 않는다는 점을 강조합니다.

또는 cryptogen 도구를 사용할 수도 있습니다.이 도구의 작업 방법은 Getting Started(시작하기) 에서 설명 합니다.

Hyperledger Fabric CA 는 MSP를 구성하는 데 필요한 키와 인증서를 생성하는데도 사용할 수 있습니다.

MSP setup on the peer & orderer side

관리자는 로컬 MSP (Peer 또는 Orderer용)를 설정하려면 6 개의 하위 폴더와 파일을 포함 하는 폴더 (예 : $MY_PATH/mspconfig)를 만들어야 합니다.

  1. 관리자 인증서에 각각 해당하는 PEM 파일을 포함하는 admincerts 폴더
  2. 루트 CA의 인증서에 각각 해당하는 PEM 파일을 포함하는 cacerts 폴더
  3. (선택 사항) 중간 CA 인증서에 각각 해당하는 PEM 파일을 포함하는 intermediatecerts 폴더
  4. (선택 사항) 파일 config.yaml을 사용하여 지원되는 조직 단위 및 ID 분류를 구성합니다 (아래 각 절 참조).
  5. (선택 사항) 고려 대상 CRL을 포함할 crls 폴더
  6. 노드의 서명 키가 있는 PEM 파일을 포함 하는 keystore 폴더. 우리는 현재 RSA 키가 지원되지 않는다는 것을 강조한다.
  7. 노드의 X.509 인증서가 있는 PEM 파일을 포함하는 signcerts 폴더
  8. (선택 사항) TLS 루트 CA의 인증서에 각각 해당하는 PEM 파일을 포함하는 tlscacerts 폴더
  9. (선택 사항) 중간 TLS CA 인증서에 각각 해당하는 PEM 파일을 포함하는 tlsintermediatecerts 폴더

노드의 구성 파일 (Peer에 대한 core.yaml 파일 및 Orderer에 대한 orderer.yaml)에서 mspconfig 폴더의 경로와 노드의 MSP의 MSP 식별자를 지정해야합니다. mspconfig 폴더에 대한 경로는 FABRIC_CFG_PATH에 상대적인 것으로 예상되며 Peer에 대한 mspConfigPath 매개변수의 값으로 제공되고, Orderer는 LocalMSPDir로 제공됩니다. 노드의 MSP 식별자는 Peer에 대한 매개 변수 localMspId 및 Orderer에 대한 LocalMSPID 값으로 제공됩니다. 이러한 변수는 Peer에 대한 CORE 접두사 (예 : CORE_PEER_LOCALMSPID)와 Orderer의 ORDERER 접두사 (예 : ORDERER_GENERAL_LOCALMSPID)를 사용하여 환경을 통해 무시할 수 있습니다. Orderer 설정을 위해서는 시스템 채널의 genesis 블록을 생성하고 Orderer에게 제공해야합니다. 이 블록의 MSP 구성 요구 사항은 다음 절에서 자세히 설명합니다.

"로컬" MSP의 재구성 은 수동으로만 가능하며 Peer 또는 Orderer 프로세스가 다시 시작되어야합니다. 후속 릴리스에서는 온라인 / 동적 재구성 (노드 관리 시스템 체인 코드를 사용하여 노드를 중지 할 필요 없음)을 제공하는 것을 목표로합니다.

Organizational Units

이 MSP의 구성원이 유효한 X.509 인증서에 포함되어야하는 조직 구성 단위 목록을 구성하려면 config.yaml 파일에서 조직 구성 단위 식별자를 지정해야합니다. 다음은 그 예입니다 :

OrganizationalUnitIdentifiers:
  - Certificate: "cacerts/cacert1.pem"
    OrganizationalUnitIdentifier: "commercial"
  - Certificate: "cacerts/cacert2.pem"
    OrganizationalUnitIdentifier: "administrators"

위의 예에서는 두 개의 조직 구성 단위 식별자인 상업용(commercial) 및 관리자(administrators) 를 선언합니다. MSP ID는 이러한 조직 구성 단위 식별자 중 하나 이상을 포함하는 경우 유효합니다. 이 Certificate 필드는 특정 OU가있는 ID의 유효성을 검사해야하는 CA 또는 중간 CA 인증서 경로를 나타냅니다. 경로는 MSP 루트 폴더와 관련이 있으며 비워 둘 수 없습니다.

Identity Classification

기본 MSP 구현을 사용하면 x509 인증서의 OU를 기반으로 ID를 클라이언트 및 피어로 더 분류 할 수 있습니다. ID 는 트랜잭션을 제출하거나 피어를 쿼리하는 등의 경우 클라이언트(client) 로 분류되어야합니다. ID 는 트랜잭션을 승인하거나 커밋하는 경우 피어(peer) 로 분류되어야 합니다. 특정 MSP의 클라이언트 및 피어를 정의하려면 config.yaml 파일을 적절히 설정해야합니다. 다음은 그 예입니다.

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
  PeerOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer" 

위에서 보여준 것처럼, NodeOUs.Enable 값은 true로 설정되어 신원 분류를 가능하게합니다. 그런 다음 client (peer) 식별자는 NodeOUs.ClientOUIdentifierNodeOUs.PeerOUIdentifier) 키에 대해 다음 속성을 설정하여 정의됩니다.

  1. OrganizationalUnitIdentifier : 클라이언트 (피어)의 x509 인증서에 포함해야하는 OU와 일치하는 값으로 설정합니다.
  2. Certificate : 이를 클라이언트 (피어) ID의 유효성을 검사해야하는 CA 또는 중간 CA로 설정합니다. 필드는 MSP 루트 폴더와 관련이 있습니다. 비어있을 수 있습니다. 즉, MSP 구성에 정의 된 모든 CA에서 ID의 x509 인증서를 확인할 수 있습니다.

분류가 활성화되면 MSP 관리자는 해당 MSP의 클라이언트여야합니다. 즉, x509 인증서는 클라이언트를 식별하는 OU를 전송해야합니다. 신원은 클라이언트 또는 피어가 될 수 있습니다. 두 분류는 상호 배타적입니다. ID가 클라이언트도 아니고 피어도 아닌 경우 유효성 검사가 실패합니다.

마지막으로, 업그레이드 된 환경에서는 분류 식별을 사용하기 전에 1.1 채널 기능을 활성화해야합니다.

Channel MSP setup

시스템의 초기 단계에서 네트워크에 나타나는 모든 MSP의 확인 매개 변수를 지정하고 시스템 채널의 genesis 블록에 포함해야합니다. MSP 확인 매개 변수는 MSP 식별자, 트러스트 인증서 루트, 중간 CA 및 관리자 인증서, OU 사양 및 CRL로 구성됩니다. 시스템 genesis 블록은 설치 단계에서 orderers에게 제공되며 채널 생성 요청을 인증할 수 있습니다. 명령자는 동일한 식별자를 가진 두 개의 MSP를 포함하는 경우 시스템 genesis 블록을 거부하므로 결과적으로 네트워크의 부트 스트랩이 실패합니다.

응용 프로그램 채널의 경우 채널을 관리하는 MSP의 확인 구성 요소만 채널의 genesis 블록에 있어야합니다. 우리는 하나 이상의 피어에게 채널에 참여하도록 지시하기 전에 올바른 MSP 구성 정보가 채널의 구성 블록 (또는 가장 최근 구성 블록)에 포함되도록하는 것이 응용 프로그램의 책임 임을 강조합니다 .

configtxgen 도구를 사용하여 채널을 부트 스트랩 할 때 mspconfig 폴더에 MSP의 확인 매개 변수를 포함하고 configtx.yaml의 해당 섹션에서 해당 경로를 설정하여 채널 MSP를 구성 할 수 있습니다.

해당 MSP의 CA와 관련된 인증서 해지 목록의 알림을 포함하여 채널에서 MSP를 다시 구성 하는 작업은 MSP의 관리자 인증서 중 하나의 소유자가 config_update 개체를 만들어서 수행합니다. 그러면 관리자가 관리하는 클라이언트 응용 프로그램은 이 MSP가 나타나는 채널에 이 업데이트를 알립니다.

Best Practices

이 섹션에서는 일반적으로 충족되는 시나리오에서 MSP 구성에 대한 모범 사례를 자세히 설명합니다.

1) 단체 / 기업과 MSP 간의 매핑

조직과 MSP 간에는 일대일 매핑이 권장됩니다. 다른 매핑 유형의 매핑이 선택되면 다음 사항을 고려해야합니다.

  • 다양한 MSP를 사용하는 한 조직. 이는 관리 독립성을 이유로 또는 개인 정보 보호를 이유로 MSP로 대표되는 다양한 부서를 포함하는 조직의 경우에 해당합니다. 이 경우 피어는 단일 MSP 만 소유할 수 있으며 다른 조직의 피어가 동일한 조직의 피어로 인식되지 않습니다. 이것이 의미하는 바는 동료는 가십 조직 범위의 데이터를 통해 동일한 조직의 구성원인 피어 집합과 공유할 수 있지만 실제 조직을 구성하는 전체 제공자 집합과 공유할 수는 없습니다.
  • 단일 MSP를 사용하는 여러 조직. 이것은 유사한 회원 구성에 의해 관리되는 조직의 컨소시엄의 경우에 해당합니다. 동일한 실제 조직에 속해 있는지 여부에 관계없이 동일한 MSP에서 신원을 가진 동료에게 동료 범위의 메시지를 전파해야한다는 것을 여기에서 알아야합니다. 이것은 MSP 정의 및 / 또는 피어 구성의 세분화 한계입니다.

2) 한 조직은 서로 다른 부서 (조직 단위)를 가지고 있으며 , 서로 다른 채널에 대한 액세스 권한을 부여하려고합니다.

이것을 처리하는 두 가지 방법 :

  • 모든 조직 구성원의 구성원 자격을 수용하도록 하나의 MSP를 정의하십시오. 해당 MSP의 구성은 루트 CA, 중간 CA 및 관리자 인증서 목록으로 구성됩니다. 회원 ID에는 회원이 소속된 조직 단위 (OU) 가 포함됩니다. 정책을 정의하여 특정 OU의 구성원을 파악할 수 있으며 이러한 정책은 채널의 읽기 / 쓰기 정책 또는 체인 코드의 승인 정책을 구성 할 수 있습니다. 이 접근 방식의 한계는 가십 피어가 로컬 MSP에서 회원 자격을 가진 동료를 동일한 조직의 구성원으로 간주하여 결과적으로 조직 범위의 데이터 (예 : State)를 가십을 수 있다는 것입니다.
  • 하나의 MSP를 정의하여 각 부서를 나타냅니다 . 여기에는 각 부서에 대해 루트 CA, 중간 CA 및 관리 인증서에 대한 인증서 집합이 지정되므로 MSP간에 중복되는 인증서 경로가 없어야합니다. 이는 예를 들어 세분당 다른 중간 CA가 사용됨을 의미합니다. 여기서 단점은 하나가 아닌 하나 이상의 MSP를 관리하는 것이지만 이전 방법에서 제기된 문제를 우회하는 것입니다. MSP 구성의 OU 확장을 활용하여 각 부서에 대해 하나의 MSP를 정의 할 수도 있습니다.

3) 고객을 동일한 조직의 동료와 분리합니다.

많은 경우에 신원의 "유형"을 신원 자체에서 검색할 수 있어야합니다 (예 : clients 또는 orderers로만 활동하는 노드가 아닌, peers가 보증을 보증해야하는 경우).

이러한 요구 사항에 대한 지원은 제한적입니다.

이러한 분리를 허용하는 한 가지 방법은 clients와 peers / orderers를 위한 하나의 노드 유형에 대해 별도의 중간 CA를 작성하는 것입니다. 두 개의 서로 다른 MSP를 구성하십시오. 하나는 clients용이고 다른 하나는 peers / orderers용입니다. 이 조직이 액세스해야하는 채널은 두 MSP를 모두 포함해야하며, 인증 정책은 동료를 참조하는 MSP만 사용합니다. 결국 궁극적으로 조직이 두 개의 MSP 인스턴스에 매핑되고 peers와 clients가 상호 작용하는 방식에 어떤 영향을 미칩니다.

동일한 조직의 모든 peers가 여전히 하나의 MSP에 속하기 때문에 가십(gossip)은 크게 영향을 받지 않습니다. peers는 특정 시스템 체인 코드의 실행을 로컬 MSP 기반 정책으로 제한할 수 있습니다. 예를 들어 peers는 clients인 로컬 MSP의 admin이 요청을 서명한 경우 (최종 사용자가 요청의 출처에 있어야 함) "joinChannel" 요청만 실행합니다. peer / orderer MSP의 멤버가되는 유일한 클라이언트가 해당 MSP의 관리자가 된다는 사실을 받아들이면 이 불일치를 해결할 수 있습니다.

이 접근법과 함께 고려해야 할 또 다른 포인트는 피어가 자신의 로컬 MSP 내의 요청 발신자의 회원 자격을 기반으로 이벤트 등록 요청을 승인하는 것입니다. 분명히, 요청의 발신자가 클라이언트이기 때문에, 요청 발신자는 요청된 피어와 다른 MSP에 속하도록 항상 운명 지워지고 피어는 요청을 거부합니다.

4) 관리자 및 CA 인증서

root of trust 또는 중간 CA에 대해 MSP에서 고려한 인증서와 다른 MSP 관리 인증서로 설정하는 것이 중요합니다. 이는 구성원 구성 요소 관리의 의무를 새 인증서 발급 및 / 또는 기존 인증서 유효성 검사와 구분하는 일반적인 (보안) 방법입니다.

5) 중간 CA를 블랙리스트에 올린다.

이전 섹션에서 언급했듯이 MSP의 재구성은 재구성 메커니즘 (로컬 MSP 인스턴스의 수동 재구성 및 채널의 MSP 인스턴스에 대해 올바르게 구성된 config_update 메시지를 통해 수행)을 통해 이루어집니다. 분명히, MSP에서 고려되는 중간 CA가 더 이상 해당 MSP의 신원 확인을 위해 고려되지 않는지 확인하는 두 가지 방법이 있습니다.

  1. 신뢰할 수 있는 중간 CA 인증서 목록에 해당 중간 CA 인증서를 더 이상 포함하지 않도록 MSP를 다시 구성합니다. 로컬로 구성된 MSP의 경우 이 CA의 인증서가 해당 intermediatecerts 폴더에서 제거되었음을 의미합니다.
  2. 언급된 중간 CA의 인증서를 거부하는 root of trust에서 생성된 CRL을 포함하도록 MSP를 다시 구성합니다.

현재 MSP 구현에서 우리는 더 간단하고 더 이상 고려되지 않는 중간 CA를 블랙리스트에 올 필요가 없으므로 방법 (1) 만 지원합니다.

6) CA와 TLS CA

MSP ID의 루트 CA와 MSP TLS 인증서의 루트 CA (및 상대 중간 CA)는 서로 다른 폴더에 선언해야합니다. 이는 서로 다른 클래스의 인증서 간에 혼란을 피하기 위한 것입니다. MSP ID와 TLS 인증서 모두에 대해 동일한 CA를 재사용하는 것이 금지되어 있지는 않지만 최선의 방법은 프로덕션 환경에서 이를 피하기 위한 것입니다.


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

Updating a Channel Configuration(채널 구성 업데이트)

What is a Channel Configuration?(채널 구성이란 무엇입니까?)

채널 구성에는 채널 관리와 관련된 모든 정보가 포함됩니다. 가장 중요한 것은 채널 구성은 채널의 구성원인 조직(org)을 지정하지만 채널 액세스 정책 및 블록 배치 크기와 같은 다른 채널 전체 구성 정보도 포함합니다.

이 구성은 블록의 원장에 저장 되므로 구성(config) 블록이라고합니다. 구성 블록은 단일 구성을 포함합니다. 이 블록 중 첫 번째 블록은 "기원 블록(genesis block)"이라고하며 채널을 부트 스트랩하는 데 필요한 초기 구성을 포함합니다. 채널 구성이 변경될 때마다 새로운 구성 블록을 통해 이루어지며 최신 구성 블록은 현재 채널 구성을 나타냅니다. orderers 및 peers는 새로운 채널을 절단하고 블록 트랜잭션을 검증하는 것과 같은 모든 채널 조작을 용이하게 하기 위해 현재 채널 구성을 메모리에 유지합니다.

구성은 블록으로 저장되기 때문에 구성 업데이트는 "구성 트랜잭션(configuration transaction)"이라는 프로세스를 통해 발생합니다(프로세스가 일반 트랜잭션과 약간 다르긴하지만). 구성 업데이트는 구성을 가져 와서 사람이 읽을 수 있는 형식으로 변환하고 수정한 다음 승인을 위해 제출하는 과정입니다.

설정을 가져 와서 JSON으로 변환하는 프로세스에 대한 자세한 내용은 Adding an Org to a Channel(채널에 조직 추가)를 참조 하십시오. 이 문서에서는 구성을 편집 할 수 있는 여러 가지 방법과 서명을 가져 오는 프로세스에 중점을 둘 것입니다.

Editing a Config(구성 편집)

채널은 구성 가능하지만 무한대 아닙니다. 다른 구성 요소에는 다른 수정 정책(구성 업데이트에 서명하는 데 필요한 ID 그룹 지정)이 있습니다.

변경할 수 있는 범위를 보려면 JSON 형식으로 구성을 보는 것이 중요합니다. Adding an Org to a Channel(채널에 조직 추가) 튜토리얼은 하나를 생성합니다. 따라서 해당 문서를 살펴보면 간단히 참조할 수 있습니다. 그렇지 않은 사용자를 위해 여기에 하나를 제공합니다(가독성을 위해 이 구성을 atom 또는 Visual Studio와 같은 JSON 폴딩을 지원하는 뷰어에 배치하는 것이 도움이 될 수 있음).

{
"channel_group": {
  "groups": {
    "Application": {
      "groups": {
        "Org1MSP": {
          "mod_policy": "Admins",
          "policies": {
            "Admins": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org1MSP",
                        "role": "ADMIN"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Readers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org1MSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Writers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org1MSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            }
          },
          "values": {
            "AnchorPeers": {
              "mod_policy": "Admins",
              "value": {
                "anchor_peers": [
                  {
                    "host": "peer0.org1.example.com",
                    "port": 7051
                  }
                ]
              },
              "version": "0"
            },
            "MSP": {
              "mod_policy": "Admins",
              "value": {
                "config": {
                  "admins": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNHRENDQWIrZ0F3SUJBZ0lRSWlyVmg3NVcwWmh0UjEzdmltdmliakFLQmdncWhrak9QUVFEQWpCek1Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTVM1bGVHRnRjR3hsTG1OdmJURWNNQm9HQTFVRUF4TVRZMkV1CmIzSm5NUzVsZUdGdGNHeGxMbU52YlRBZUZ3MHhOekV4TWpreE9USTBNRFphRncweU56RXhNamN4T1RJME1EWmEKTUZzeEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVApZVzRnUm5KaGJtTnBjMk52TVI4d0hRWURWUVFEREJaQlpHMXBia0J2Y21jeExtVjRZVzF3YkdVdVkyOXRNRmt3CkV3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFNkdVeDlpczZ0aG1ZRE9tMmVHSlA5eW1yaXJYWE1Cd0oKQmVWb1Vpak5haUdsWE03N2NsSE5aZjArMGFjK2djRU5lMzQweGExZVFnb2Q0YjVFcmQrNmtxTk5NRXN3RGdZRApWUjBQQVFIL0JBUURBZ2VBTUF3R0ExVWRFd0VCL3dRQ01BQXdLd1lEVlIwakJDUXdJb0FnWWdoR2xCMjBGWmZCCllQemdYT280czdkU1k1V3NKSkRZbGszTDJvOXZzQ013Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnYmlEWDVTMlIKRTBNWGRobDZFbmpVNm1lTEJ0eXNMR2ZpZXZWTlNmWW1UQVVDSUdVbnROangrVXZEYkZPRHZFcFRVTm5MUHp0Qwp5ZlBnOEhMdWpMaXVpaWFaCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
                  ],
                  "crypto_config": {
                    "identity_identifier_hash_function": "SHA256",
                    "signature_hash_family": "SHA2"
                  },
                  "name": "Org1MSP",
                  "root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNRekNDQWVxZ0F3SUJBZ0lSQU03ZVdTaVM4V3VVM2haMU9tR255eXd3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekV1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGN4TVRJNU1Ua3lOREEyV2hjTk1qY3hNVEkzTVRreU5EQTIKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NUzVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1TNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQkJiTTVZS3B6UmlEbDdLWWFpSDVsVnBIeEl1TDEyaUcyWGhkMHRpbEg3MEljMGFpRUh1dG9rTkZsUXAzTWI0Zgpvb0M2bFVXWnRnRDJwMzZFNThMYkdqK2pYekJkTUE0R0ExVWREd0VCL3dRRUF3SUJwakFQQmdOVkhTVUVDREFHCkJnUlZIU1VBTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3S1FZRFZSME9CQ0lFSUdJSVJwUWR0QldYd1dEODRGenEKT0xPM1VtT1ZyQ1NRMkpaTnk5cVBiN0FqTUFvR0NDcUdTTTQ5QkFNQ0EwY0FNRVFDSUdlS2VZL1BsdGlWQTRPSgpRTWdwcDRvaGRMcGxKUFpzNERYS0NuOE9BZG9YQWlCK2g5TFdsR3ZsSDdtNkVpMXVRcDFld2ZESmxsZi9MZXczClgxaDNRY0VMZ3c9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
                  ],
                  "tls_root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNTVENDQWZDZ0F3SUJBZ0lSQUtsNEFQWmV6dWt0Nk8wYjRyYjY5Y0F3Q2dZSUtvWkl6ajBFQXdJd2RqRUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIekFkQmdOVkJBTVRGblJzCmMyTmhMbTl5WnpFdVpYaGhiWEJzWlM1amIyMHdIaGNOTVRjeE1USTVNVGt5TkRBMldoY05NamN4TVRJM01Ua3kKTkRBMldqQjJNUXN3Q1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRQpCeE1OVTJGdUlFWnlZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTVM1bGVHRnRjR3hsTG1OdmJURWZNQjBHCkExVUVBeE1XZEd4elkyRXViM0puTVM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDkKQXdFSEEwSUFCSnNpQXVjYlcrM0lqQ2VaaXZPakRiUmFyVlRjTW9TRS9mSnQyU0thR1d5bWQ0am5xM25MWC9vVApCVmpZb21wUG1QbGZ4R0VSWHl0UTNvOVZBL2hwNHBlalh6QmRNQTRHQTFVZER3RUIvd1FFQXdJQnBqQVBCZ05WCkhTVUVDREFHQmdSVkhTVUFNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdLUVlEVlIwT0JDSUVJSnlqZnFoa0FvY3oKdkRpNnNGSGFZL1Bvd2tPWkxPMHZ0VGdFRnVDbUpFalZNQW9HQ0NxR1NNNDlCQU1DQTBjQU1FUUNJRjVOVVdCVgpmSjgrM0lxU3J1NlFFbjlIa0lsQ0xDMnlvWTlaNHBWMnpBeFNBaUE5NWQzeDhBRXZIcUFNZnIxcXBOWHZ1TW5BCmQzUXBFa1gyWkh3ODZlQlVQZz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
                  ]
                },
                "type": 0
              },
              "version": "0"
            }
          },
          "version": "1"
        },
        "Org2MSP": {
          "mod_policy": "Admins",
          "policies": {
            "Admins": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org2MSP",
                        "role": "ADMIN"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Readers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org2MSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Writers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org2MSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            }
          },
          "values": {
            "AnchorPeers": {
              "mod_policy": "Admins",
              "value": {
                "anchor_peers": [
                  {
                    "host": "peer0.org2.example.com",
                    "port": 7051
                  }
                ]
              },
              "version": "0"
            },
            "MSP": {
              "mod_policy": "Admins",
              "value": {
                "config": {
                  "admins": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNHVENDQWNDZ0F3SUJBZ0lSQU5Pb1lIbk9seU94dTJxZFBteStyV293Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGN4TVRJNU1Ua3lOREEyV2hjTk1qY3hNVEkzTVRreU5EQTIKV2pCYk1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFZk1CMEdBMVVFQXd3V1FXUnRhVzVBYjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaCk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMElBQkh1M0ZWMGlqdFFzckpsbnBCblgyRy9ickFjTHFJSzgKVDFiSWFyZlpvSkhtQm5IVW11RTBhc1dyKzM4VUs0N3hyczNZMGMycGhFVjIvRnhHbHhXMUZubWpUVEJMTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBTUJnTlZIUk1CQWY4RUFqQUFNQ3NHQTFVZEl3UWtNQ0tBSU1pSzdteFpnQVVmCmdrN0RPTklXd2F4YktHVGdLSnVSNjZqVmordHZEV3RUTUFvR0NDcUdTTTQ5QkFNQ0EwY0FNRVFDSUQxaEtRdk8KVWxyWmVZMmZZY1N2YWExQmJPM3BVb3NxL2tZVElyaVdVM1J3QWlBR29mWmVPUFByWXVlTlk0Z2JCV2tjc3lpZgpNMkJmeXQwWG9NUThyT2VidUE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
                  ],
                  "crypto_config": {
                    "identity_identifier_hash_function": "SHA256",
                    "signature_hash_family": "SHA2"
                  },
                  "name": "Org2MSP",
                  "root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNSRENDQWVxZ0F3SUJBZ0lSQU1pVXk5SGRSbXB5MDdsSjhRMlZNWXN3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGN4TVRJNU1Ua3lOREEyV2hjTk1qY3hNVEkzTVRreU5EQTIKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NaTVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQk50YW1PY1hyaGwrQ2hzYXNSeklNWjV3OHpPWVhGcXhQbGV0a3d5UHJrbHpKWE01Qjl4QkRRVWlWNldJS2tGSwo0Vmd5RlNVWGZqaGdtd25kMUNBVkJXaWpYekJkTUE0R0ExVWREd0VCL3dRRUF3SUJwakFQQmdOVkhTVUVDREFHCkJnUlZIU1VBTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3S1FZRFZSME9CQ0lFSU1pSzdteFpnQVVmZ2s3RE9OSVcKd2F4YktHVGdLSnVSNjZqVmordHZEV3RUTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSVFEQ3FFRmFqeU5IQmVaRworOUdWVkNFNWI1YTF5ZlhvS3lkemdLMVgyOTl4ZmdJZ05BSUUvM3JINHFsUE9HbjdSS3Yram9WaUNHS2t6L0F1Cm9FNzI4RWR6WmdRPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
                  ],
                  "tls_root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNTakNDQWZDZ0F3SUJBZ0lSQU9JNmRWUWMraHBZdkdMSlFQM1YwQU13Q2dZSUtvWkl6ajBFQXdJd2RqRUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIekFkQmdOVkJBTVRGblJzCmMyTmhMbTl5WnpJdVpYaGhiWEJzWlM1amIyMHdIaGNOTVRjeE1USTVNVGt5TkRBMldoY05NamN4TVRJM01Ua3kKTkRBMldqQjJNUXN3Q1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRQpCeE1OVTJGdUlFWnlZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTWk1bGVHRnRjR3hsTG1OdmJURWZNQjBHCkExVUVBeE1XZEd4elkyRXViM0puTWk1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDkKQXdFSEEwSUFCTWZ1QTMwQVVBT1ZKRG1qVlBZd1lNbTlweW92MFN6OHY4SUQ5N0twSHhXOHVOOUdSOU84aVdFMgo5bllWWVpiZFB2V1h1RCszblpweUFNcGZja3YvYUV5alh6QmRNQTRHQTFVZER3RUIvd1FFQXdJQnBqQVBCZ05WCkhTVUVDREFHQmdSVkhTVUFNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdLUVlEVlIwT0JDSUVJRnk5VHBHcStQL08KUGRXbkZXdWRPTnFqVDRxOEVKcDJmbERnVCtFV2RnRnFNQW9HQ0NxR1NNNDlCQU1DQTBnQU1FVUNJUUNZYlhSeApXWDZoUitPU0xBNSs4bFRwcXRMWnNhOHVuS3J3ek1UYXlQUXNVd0lnVSs5YXdaaE0xRzg3bGE0V0h4cmt5eVZ2CkU4S1ZsR09IVHVPWm9TMU5PT0U9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
                  ]
                },
                "type": 0
              },
              "version": "0"
            }
          },
          "version": "1"
        },
        "Org3MSP": {
          "groups": {},
          "mod_policy": "Admins",
          "policies": {
            "Admins": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org3MSP",
                        "role": "ADMIN"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Readers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org3MSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Writers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "Org3MSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            }
          },
          "values": {
            "MSP": {
              "mod_policy": "Admins",
              "value": {
                "config": {
                  "admins": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNHRENDQWIrZ0F3SUJBZ0lRQUlSNWN4U0hpVm1kSm9uY3FJVUxXekFLQmdncWhrak9QUVFEQWpCek1Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTXk1bGVHRnRjR3hsTG1OdmJURWNNQm9HQTFVRUF4TVRZMkV1CmIzSm5NeTVsZUdGdGNHeGxMbU52YlRBZUZ3MHhOekV4TWpreE9UTTRNekJhRncweU56RXhNamN4T1RNNE16QmEKTUZzeEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVApZVzRnUm5KaGJtTnBjMk52TVI4d0hRWURWUVFEREJaQlpHMXBia0J2Y21jekxtVjRZVzF3YkdVdVkyOXRNRmt3CkV3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFSFlkVFY2ZC80cmR4WFd2cm1qZ0hIQlhXc2lxUWxrcnQKZ0p1NzMxcG0yZDRrWU82aEd2b2tFRFBwbkZFdFBwdkw3K1F1UjhYdkFQM0tqTkt0NHdMRG5hTk5NRXN3RGdZRApWUjBQQVFIL0JBUURBZ2VBTUF3R0ExVWRFd0VCL3dRQ01BQXdLd1lEVlIwakJDUXdJb0FnSWNxUFVhM1VQNmN0Ck9LZmYvKzVpMWJZVUZFeVFlMVAyU0hBRldWSWUxYzB3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnUm5LRnhsTlYKSmppVGpkZmVoczRwNy9qMkt3bFVuUWVuNFkyUnV6QjFrbm9DSUd3dEZ1TEdpRFY2THZSL2pHVXR3UkNyeGw5ZApVNENCeDhGbjBMdXNMTkJYCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
                  ],
                  "crypto_config": {
                    "identity_identifier_hash_function": "SHA256",
                    "signature_hash_family": "SHA2"
                  },
                  "name": "Org3MSP",
                  "root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNRakNDQWVtZ0F3SUJBZ0lRUkN1U2Y0RVJNaDdHQW1ydTFIQ2FZREFLQmdncWhrak9QUVFEQWpCek1Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTXk1bGVHRnRjR3hsTG1OdmJURWNNQm9HQTFVRUF4TVRZMkV1CmIzSm5NeTVsZUdGdGNHeGxMbU52YlRBZUZ3MHhOekV4TWpreE9UTTRNekJhRncweU56RXhNamN4T1RNNE16QmEKTUhNeEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVApZVzRnUm5KaGJtTnBjMk52TVJrd0Z3WURWUVFLRXhCdmNtY3pMbVY0WVcxd2JHVXVZMjl0TVJ3d0dnWURWUVFECkV4TmpZUzV2Y21jekxtVjRZVzF3YkdVdVkyOXRNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUUKZXFxOFFQMnllM08vM1J3UzI0SWdtRVdST3RnK3Zyc2pRY1BvTU42NEZiUGJKbmExMklNaVdDUTF6ZEZiTU9hSAorMUlrb21yY0RDL1ZpejkvY0M0NW9xTmZNRjB3RGdZRFZSMFBBUUgvQkFRREFnR21NQThHQTFVZEpRUUlNQVlHCkJGVWRKUUF3RHdZRFZSMFRBUUgvQkFVd0F3RUIvekFwQmdOVkhRNEVJZ1FnSWNxUFVhM1VQNmN0T0tmZi8rNWkKMWJZVUZFeVFlMVAyU0hBRldWSWUxYzB3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnTEgxL2xSZElWTVA4Z2FWeQpKRW01QWQ0SjhwZ256N1BVV2JIMzZvdVg4K1lDSUNPK20vUG9DbDRIbTlFbXhFN3ZnUHlOY2trVWd0SlRiTFhqCk5SWjBxNTdWCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
                  ],
                  "tls_root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNTVENDQWZDZ0F3SUJBZ0lSQU9xc2JQQzFOVHJzclEvUUNpalh6K0F3Q2dZSUtvWkl6ajBFQXdJd2RqRUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpNdVpYaGhiWEJzWlM1amIyMHhIekFkQmdOVkJBTVRGblJzCmMyTmhMbTl5WnpNdVpYaGhiWEJzWlM1amIyMHdIaGNOTVRjeE1USTVNVGt6T0RNd1doY05NamN4TVRJM01Ua3oKT0RNd1dqQjJNUXN3Q1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRQpCeE1OVTJGdUlFWnlZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTXk1bGVHRnRjR3hsTG1OdmJURWZNQjBHCkExVUVBeE1XZEd4elkyRXViM0puTXk1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDkKQXdFSEEwSUFCSVJTTHdDejdyWENiY0VLMmhxSnhBVm9DaDhkejNqcnA5RHMyYW9TQjBVNTZkSUZhVmZoR2FsKwovdGp6YXlndXpFalFhNlJ1MmhQVnRGM2NvQnJ2Ulpxalh6QmRNQTRHQTFVZER3RUIvd1FFQXdJQnBqQVBCZ05WCkhTVUVDREFHQmdSVkhTVUFNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdLUVlEVlIwT0JDSUVJQ2FkVERGa0JPTGkKblcrN2xCbDExL3pPbXk4a1BlYXc0MVNZWEF6cVhnZEVNQW9HQ0NxR1NNNDlCQU1DQTBjQU1FUUNJQlgyMWR3UwpGaG5NdDhHWXUweEgrUGd5aXQreFdQUjBuTE1Jc1p2dVlRaktBaUFLUlE5N2VrLzRDTzZPWUtSakR0VFM4UFRmCm9nTmJ6dTBxcThjbVhseW5jZz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
                  ]
                },
                "type": 0
              },
              "version": "0"
            }
          },
          "version": "0"
        }
      },
      "mod_policy": "Admins",
      "policies": {
        "Admins": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "MAJORITY",
              "sub_policy": "Admins"
            }
          },
          "version": "0"
        },
        "Readers": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "ANY",
              "sub_policy": "Readers"
            }
          },
          "version": "0"
        },
        "Writers": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "ANY",
              "sub_policy": "Writers"
            }
          },
          "version": "0"
        }
      },
      "version": "1"
    },
    "Orderer": {
      "groups": {
        "OrdererOrg": {
          "mod_policy": "Admins",
          "policies": {
            "Admins": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "OrdererMSP",
                        "role": "ADMIN"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Readers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "OrdererMSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            },
            "Writers": {
              "mod_policy": "Admins",
              "policy": {
                "type": 1,
                "value": {
                  "identities": [
                    {
                      "principal": {
                        "msp_identifier": "OrdererMSP",
                        "role": "MEMBER"
                      },
                      "principal_classification": "ROLE"
                    }
                  ],
                  "rule": {
                    "n_out_of": {
                      "n": 1,
                      "rules": [
                        {
                          "signed_by": 0
                        }
                      ]
                    }
                  },
                  "version": 0
                }
              },
              "version": "0"
            }
          },
          "values": {
            "MSP": {
              "mod_policy": "Admins",
              "value": {
                "config": {
                  "admins": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNDakNDQWJDZ0F3SUJBZ0lRSFNTTnIyMWRLTTB6THZ0dEdoQnpMVEFLQmdncWhrak9QUVFEQWpCcE1Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVVNQklHQTFVRUNoTUxaWGhoYlhCc1pTNWpiMjB4RnpBVkJnTlZCQU1URG1OaExtVjRZVzF3CmJHVXVZMjl0TUI0WERURTNNVEV5T1RFNU1qUXdObG9YRFRJM01URXlOekU1TWpRd05sb3dWakVMTUFrR0ExVUUKQmhNQ1ZWTXhFekFSQmdOVkJBZ1RDa05oYkdsbWIzSnVhV0V4RmpBVUJnTlZCQWNURFZOaGJpQkdjbUZ1WTJsegpZMjh4R2pBWUJnTlZCQU1NRVVGa2JXbHVRR1Y0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJCnpqMERBUWNEUWdBRTZCTVcvY0RGUkUvakFSenV5N1BjeFQ5a3pnZitudXdwKzhzK2xia0hZd0ZpaForMWRhR3gKKzhpS1hDY0YrZ0tpcVBEQXBpZ2REOXNSeTBoTEMwQnRacU5OTUVzd0RnWURWUjBQQVFIL0JBUURBZ2VBTUF3RwpBMVVkRXdFQi93UUNNQUF3S3dZRFZSMGpCQ1F3SW9BZ3o3bDQ2ZXRrODU0NFJEanZENVB6YjV3TzI5N0lIMnNUCngwTjAzOHZibkpzd0NnWUlLb1pJemowRUF3SURTQUF3UlFJaEFNRTJPWXljSnVyYzhVY2hkeTA5RU50RTNFUDIKcVoxSnFTOWVCK0gxSG5FSkFpQUtXa2h5TmI0akRPS2MramJIVmgwV0YrZ3J4UlJYT1hGaEl4ei85elI3UUE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
                  ],
                  "crypto_config": {
                    "identity_identifier_hash_function": "SHA256",
                    "signature_hash_family": "SHA2"
                  },
                  "name": "OrdererMSP",
                  "root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNMakNDQWRXZ0F3SUJBZ0lRY2cxUVZkVmU2Skd6YVU1cmxjcW4vakFLQmdncWhrak9QUVFEQWpCcE1Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVVNQklHQTFVRUNoTUxaWGhoYlhCc1pTNWpiMjB4RnpBVkJnTlZCQU1URG1OaExtVjRZVzF3CmJHVXVZMjl0TUI0WERURTNNVEV5T1RFNU1qUXdObG9YRFRJM01URXlOekU1TWpRd05sb3dhVEVMTUFrR0ExVUUKQmhNQ1ZWTXhFekFSQmdOVkJBZ1RDa05oYkdsbWIzSnVhV0V4RmpBVUJnTlZCQWNURFZOaGJpQkdjbUZ1WTJsegpZMjh4RkRBU0JnTlZCQW9UQzJWNFlXMXdiR1V1WTI5dE1SY3dGUVlEVlFRREV3NWpZUzVsZUdGdGNHeGxMbU52CmJUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJQTVI2MGdCcVJham9hS0U1TExRYjRIb28wN3QKYTRuM21Ncy9NRGloQVQ5YUN4UGZBcDM5SS8wMmwvZ2xiMTdCcEtxZGpGd0JKZHNuMVN6ZnQ3NlZkTitqWHpCZApNQTRHQTFVZER3RUIvd1FFQXdJQnBqQVBCZ05WSFNVRUNEQUdCZ1JWSFNVQU1BOEdBMVVkRXdFQi93UUZNQU1CCkFmOHdLUVlEVlIwT0JDSUVJTSs1ZU9uclpQT2VPRVE0N3crVDgyK2NEdHZleUI5ckU4ZERkTi9MMjV5Yk1Bb0cKQ0NxR1NNNDlCQU1DQTBjQU1FUUNJQVB6SGNOUmQ2a3QxSEdpWEFDclFTM0grL3R5NmcvVFpJa1pTeXIybmdLNQpBaUJnb1BVTTEwTHNsMVFtb2dlbFBjblZGZjJoODBXR2I3NGRIS2tzVFJKUkx3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
                  ],
                  "tls_root_certs": [
                    "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNORENDQWR1Z0F3SUJBZ0lRYWJ5SUl6cldtUFNzSjJacisvRVpXVEFLQmdncWhrak9QUVFEQWpCc01Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVVNQklHQTFVRUNoTUxaWGhoYlhCc1pTNWpiMjB4R2pBWUJnTlZCQU1URVhSc2MyTmhMbVY0CllXMXdiR1V1WTI5dE1CNFhEVEUzTVRFeU9URTVNalF3TmxvWERUSTNNVEV5TnpFNU1qUXdObG93YkRFTE1Ba0cKQTFVRUJoTUNWVk14RXpBUkJnTlZCQWdUQ2tOaGJHbG1iM0p1YVdFeEZqQVVCZ05WQkFjVERWTmhiaUJHY21GdQpZMmx6WTI4eEZEQVNCZ05WQkFvVEMyVjRZVzF3YkdVdVkyOXRNUm93R0FZRFZRUURFeEYwYkhOallTNWxlR0Z0CmNHeGxMbU52YlRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMElBQkVZVE9mdG1rTHdiSlRNeG1aVzMKZVdqRUQ2eW1UeEhYeWFQdTM2Y1NQWDlldDZyU3Y5UFpCTGxyK3hZN1dtYlhyOHM5K3E1RDMwWHl6OEh1OWthMQpSc1dqWHpCZE1BNEdBMVVkRHdFQi93UUVBd0lCcGpBUEJnTlZIU1VFQ0RBR0JnUlZIU1VBTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0tRWURWUjBPQkNJRUlJcjduNTVjTWlUdENEYmM5UGU0RFpnZ0ZYdHV2RktTdnBNYUhzbzAKSnpFd01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lGM1gvMGtQRkFVQzV2N25JVVh6SmI5Z3JscWxET05UeVg2QQpvcmtFVTdWb0FpQkpMbS9IUFZ0aVRHY2NldUZPZTE4SnNwd0JTZ1hxNnY1K1BobEdsbU9pWHc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
                  ]
                },
                "type": 0
              },
              "version": "0"
            }
          },
          "version": "0"
        }
      },
      "mod_policy": "Admins",
      "policies": {
        "Admins": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "MAJORITY",
              "sub_policy": "Admins"
            }
          },
          "version": "0"
        },
        "BlockValidation": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "ANY",
              "sub_policy": "Writers"
            }
          },
          "version": "0"
        },
        "Readers": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "ANY",
              "sub_policy": "Readers"
            }
          },
          "version": "0"
        },
        "Writers": {
          "mod_policy": "Admins",
          "policy": {
            "type": 3,
            "value": {
              "rule": "ANY",
              "sub_policy": "Writers"
            }
          },
          "version": "0"
        }
      },
      "values": {
        "BatchSize": {
          "mod_policy": "Admins",
          "value": {
            "absolute_max_bytes": 103809024,
            "max_message_count": 10,
            "preferred_max_bytes": 524288
          },
          "version": "0"
        },
        "BatchTimeout": {
          "mod_policy": "Admins",
          "value": {
            "timeout": "2s"
          },
          "version": "0"
        },
        "ChannelRestrictions": {
          "mod_policy": "Admins",
          "version": "0"
        },
        "ConsensusType": {
          "mod_policy": "Admins",
          "value": {
            "type": "solo"
          },
          "version": "0"
        }
      },
      "version": "0"
    }
  },
  "mod_policy": "",
  "policies": {
    "Admins": {
      "mod_policy": "Admins",
      "policy": {
        "type": 3,
        "value": {
          "rule": "MAJORITY",
          "sub_policy": "Admins"
        }
      },
      "version": "0"
    },
    "Readers": {
      "mod_policy": "Admins",
      "policy": {
        "type": 3,
        "value": {
          "rule": "ANY",
          "sub_policy": "Readers"
        }
      },
      "version": "0"
    },
    "Writers": {
      "mod_policy": "Admins",
      "policy": {
        "type": 3,
        "value": {
          "rule": "ANY",
          "sub_policy": "Writers"
        }
      },
      "version": "0"
    }
  },
  "values": {
    "BlockDataHashingStructure": {
      "mod_policy": "Admins",
      "value": {
        "width": 4294967295
      },
      "version": "0"
    },
    "Consortium": {
      "mod_policy": "Admins",
      "value": {
        "name": "SampleConsortium"
      },
      "version": "0"
    },
    "HashingAlgorithm": {
      "mod_policy": "Admins",
      "value": {
        "name": "SHA256"
      },
      "version": "0"
    },
    "OrdererAddresses": {
      "mod_policy": "/Channel/Orderer/Admins",
      "value": {
        "addresses": [
          "orderer.example.com:7050"
        ]
      },
      "version": "0"
    }
  },
  "version": "0"
},
"sequence": "3",
"type": 0
}

설정은 이 형식으로 위협적으로 보일지 모르지만 일단 그것을 공부하면 논리 구조가 있음을 알 수 있습니다.

채널 수준에서 특정 작업을 수행 할 수 있는 사람을 정의하고 구성 채널을 변경할 수 있는 사람을 변경할 권한이 있는 정책의 정의 외에도 구성 업데이트를 사용하여 수정할 수 있는 다른 종류의 기능이 있습니다. Adding an Org to a Channel(채널에 조직 추가) 과정은 채널을 조직에 추가하는 등 가장 중요한 작업 중 하나를 수행할 수 있습니다. 구성 업데이트로 변경할 수 있는 몇 가지 다른 사항은 다음과 같습니다.

  • Batch Size. 이 매개 변수는 블록의 트랜잭션 수와 크기를 지정합니다. 블록은 absolute_max_bytes보다 크거나 블록 내에  max_message_count개 이상의 트랜잭션 보다 많게 표시되지 않습니다. preferred_max_bytes 아래에 블록을 구성할 수 있으면 블록이 너무 일찍 절단되고 이 크기보다 큰 트랜잭션은 자체 블록에 나타납니다. { "absolute_max_bytes" : 102760448 , "max_message_count" : 10 , "preferred_max_bytes" : 524288 }
  • Batch Timeout. 블록을 절단하기 전에 추가 트랜잭션을 위해 첫 번째 트랜잭션이 도착한 후에 기다리는 시간입니다. 이 값을 줄이면 대기 시간이 향상되지만 블록을 너무 많이 줄이면 블록이 최대 용량까지 채우지 못해 처리량이 감소 할 수 있습니다. { "timeout" : "2s" }
  • Channel Restrictions. orderer가 할당하고자하는 총 채널 수는 max_count로 지정할 수 있습니다. 이는 주로 컨소시엄 ChannelCreation 정책이 약한 사전 제작 환경에서 유용합니다 . { "max_count" : 1000 }
  • Channel Creation Policy. 채널이 정의된 컨소시엄에 대한 새 채널의 Application 그룹에 대한 mod_policy로 설정될 정책 값을 정의합니다. 채널 생성 요청에 첨부된 시그니처 세트는 새 채널에서 이 정책의 인스턴스화와 비교하여 점검되어 채널 생성이 승인된 것입니다. 이 구성 value는 orerer 시스템 채널에서만 설정됩니다. { "type": 3, "value": { "rule": "ANY", "sub_policy": "Admins" } }
  • Kafka brokers. ConsensusTypekafka로 설정되면 brokers 목록은 시작 시 Orderer가 처음에 연결할 Kafka brokers의 일부 하위 집합 (또는 모든 가능한 집합)을 열거합니다. 기원 블록(genesis block)이 부트스트랩(bootstrapping)되는 동안 컨센서스 유형을 변경하는 것은 불가능합니다. { "brokers": [ "kafka0:9092", "kafka1:9092", "kafka2:9092", "kafka3:9092" ] }
  • Anchor Peers Definition. 각 조직(Org)에 대한 앵커 피어의 위치를 정의합니다. { "host": "peer0.org2.example.com", "port": 7051 }
  • Hashing Structure. 블록 데이터는 바이트 배열들의 배열입니다. 블록 데이터의 해시는 Merkle 트리로 계산됩니다. 이 값은 해당 Merkle 트리의 너비를 지정합니다. 당분간, 이 값은 4294967295 블록 데이터 바이트의 연결에 대한 단순한 평면 해시에 해당하는 값으로 고정됩니다. { "width": 4294967295 }
  • Hashing Algorithm. 블록 체인의 블록으로 인코딩된 해시 값을 계산하는 데 사용하는 알고리즘입니다. 특히 이것은 데이터 해시와 이전 블록 해시 필드에 영향을 줍니다. 이 필드에는 현재 하나의 유효한 값(SHA256)만 있으므로 변경해서는 안됩니다. { "name": "SHA256" }
  • Block Validation. 이 정책은 블록이 유효하다고 판단되는 서명 요구사항을 지정합니다. 기본적으로 Ordering 조직(org)의 일부 회원이 서명해야 합니다. { "type": 3, "value": { "rule": "ANY", "sub_policy": "Writers" } }
  • Orderer Address. 클라이언트가 orderer Broadcast and Deliver 기능을 호출할 수 있는 주소 목록. 피어(Peer)는 이러한 주소들 사이에서 무작위로 선택하고 블록 검색을 위해 두 주소 사이에서 장애 조치를 수행합니다. { "addresses": [ "orderer.example.com:7050" ] }

Org에 아티팩트 및 MSP 정보를 추가하는 것 처럼 프로세스를 되돌려 제거할 수 있습니다.

Note 합의 형태가 정의된 네트워크가 부트스트랩 된 후에, 그 구성 업데이트를 통해 변화시킬 수 없는 것이다.

Capability Requirements(역량 요구사항) 으로 알려진 또 다른 중요한 채널 구성(특히 v1.1의 경우)이 있습니다. 그것은 여기에서 문서를 찾을 수 있습니다.

채널의 블록 일괄 처리 크기(block batch size)를 편집하고자 한다고 가정해봅시다(단일 숫자 필드이기 때문에 가장 쉬운 변경사항 중 하나입니다). 먼저 JSON 경로를 쉽게 참조할 수 있도록 환경 변수로 정의합니다.

이것을 설정하려면 설정을 살펴보고 원하는 것을 찾은 다음 경로를 추적하십시오.

예를 들어 batch size를 찾으면 Orderervalue라는 것을 알 수 있습니다. Ordererchannel_group 아래에 있는 groups 안에 있습니다. batch size 값은 max_message_countvalue 값 아래의 매개변수를 갖습니다.

어떤 경로를 만들 것입니다 :

 export MAXBATCHSIZEPATH=".channel_group.groups.Orderer.values.BatchSize.value.max_message_count"

그런 다음 해당 속성의 값을 표시합니다 :

jq "$MAXBATCHSIZEPATH" config.jsonWich should return a value of 10 (in our sample network at least).

10의 값을 반환해야 합니다(최소한의 샘플 네트워크에서).

이제 새 batch size를 설정하고 새 값을 표시합니다.

 jq “$MAXBATCHSIZEPATH = 20” config.json > modified_config.json
 jq “$MAXBATCHSIZEPATH” modified_config.json

JSON을 수정하면 변환 및 제출할 준비가 완료됩니다. Adding an Org to a Channel(채널에 조직 추가)의 스크립트와 단계는 JSON 변환 프로세스를 안내합니다. 따라서 제출(submmitting) 프로세스를 살펴보겠습니다.

Get the Necessary Signatures

protobuf 파일을 성공적으로 생성했으면 서명을 해야 합니다. 이렇게 하려면 변경하려고 하는 모든 정책에 대한 관련 정책을 알아야합니다.

기본적으로 다음 구성을 편집합니다 :

  • A particular org (예 : 앵커 피어 변경)에는 해당 조직의 admin 서명만 있으면 됩니다.
  • The application (회원 조직이 누구인지)는 application 조직의 admin과 대다수가 서명해야 합니다.
  • The orderer 는 대부분 ordering 조직의 admin(기본값은 1명)만 필요합니다.
  • The top level channel group 은 대다수의 application 조직 admin과 orderer 조직 admin의 동의가 필요합니다.

채널의 기본 정책을 변경한 경우 이에 따라 서명 요구 사항을 계산해야합니다.

참고 : 응용 프로그램에 따라 서명 컬렉션을 스크립팅 할 수 있습니다. 일반적으로 필요한 것보다 더 많은 서명을 수집 할 수 있습니다.

이러한 서명을 얻는 실제 프로세스는 시스템을 설정한 방법에 따라 다르지만 두 가지 주요 구현이 있습니다. 현재 패브릭 명령 줄의 기본값은 "pass it along" 시스템입니다. 즉, 조직의 Admin이 구성 업데이트를 제안하면 서명해야하는 다른 사람 (일반적으로 다른 Admin)에게 업데이트를 보냅니다. 이 Admin은 서명 (또는 서명하지 않음) 한 후 다음 Admin에게 전달하며, 구성을 제출하기에 충분한 서명이있을 때까지 계속합니다.

이것은 단순성 덕분입니다. 충분한 서명이 있을 때 마지막 Admin은 config 트랜잭션을 제출하기 만하면됩니다 (Fabric에서는 peer channel update 명령이 기본적으로 서명을 포함합니다). 그러나 이 과정은 작은 채널에서만 실용적일 것입니다. 왜냐하면 "pass it along" 방법은 시간이 오래 걸릴 수 있기 때문입니다.

다른 옵션은 채널의 모든 Admin에게 업데이트를 제출하고 충분한 서명이 다시 오기를 기다리는 것입니다. 이 서명들은 함께 꿰매어 제출할 수 있습니다. 이로 인해 구성 업데이트를 만든 Admin(서명자 당 파일을 처리해야 함)에게는 다소 어려움이 있지만 Fabric 관리 응용 프로그램을 개발하는 사용자에게는 권장되는 워크 플로입니다.

설정이 원장에 추가되면 모든 것을 올바르게 추가했는지 확인하기 위해 pull 해서 JSON으로 변환하는 것이 가장 좋습니다. 이것은 최신 설정의 유용한 복사본으로도 사용됩니다.


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

Upgrading from v1.0.x(v1.0.x에서 업그레이드)

1.0.x 버전에서 패브릭 네트워크를 v1.1로 업그레이드하는 작업은 다음 단계를 수행하여 완료할 수 있습니다.

  • orderers, peers 및 fabric-ca용 바이너리를 업그레이드하십시오. 이러한 업그레이드는 병행하여 수행할 수 있습니다.
  • 클라이언트 SDK를 업그레이드하십시오.
  • v1.1 채널 기능 요구 사항을 사용합니다.
  • (선택 사항) Kafka 클러스터를 업그레이드합니다.

이 과정을 이해하는데 도움이 되도록 Upgrading Your Network Components(네트워크 구성요소 업그레이드) 튜토리얼을 만들었습니다. 이 튜토리얼을 통해 peers, orderers 업그레이드 및 기능 요구 사항 활성화를 비롯한 대부분의 주요 업그레이드 단계를 수행 할 수 있습니다.

이 튜토리얼은 Building Your First Network(BYFN) 샘플을 활용하기 때문에 특정 제한이 있습니다 (예 : Fabric CA는 사용하지 않습니다). 따라서 본 튜토리얼의 끝 부분에는 CA, Kafka 클러스터, CouchDB, Zookeeper, vendored chaincode shims 및 Node SDK 클라이언트를 업그레이드하는 방법이 나와 있습니다.

기능 요구 사항에 대한 자세한 내용을 보려면 여기를 클릭 하십시오.


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

Hyperledger Fabric 채널을 참고하세요.



이 콜랙션은 다양한 v1 특징과 요소들을 다음의 것과 같은 것을 시연하는 것을 포함합니다: 원장, 채널, 가십, SDK, Chaincode, MSP 등


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

 시스템 Chaincode 플러그인

시스템 Chaincode는 user의 Chaincode같이 분리된 Docker 컨테이너에서 실행되는 것과는 달리 피어 프로세스의 일부로 특별하게 작동하는 Chaincode입니다.

그러므로 시스템 Chaincode는 피어의 리소스에 더 많이 접근 할 수 있고, 유저 chaincode로 실행하기 어렵거나 불가능한 특징들을 실행하는 것에 사용됩니다.

시스템 Chaincode의 예시로는 Endorsing 제안의 ESCC(Endorser System Chaincode), 원장과 다른 fabric과 관련된 쿼리의 QSCC(Query System Chaincode) 마지막으론 커밋이 일어난 시점에 동시에 실행되는 VSCC(Validation System Chaincode)가 있습니다.

다른 유저 Chaincode들과는 달리, 시스템 Chaincode는 SDK나 CLI의 제안을 통해서 설치되거나 인스턴스화 되지 않습니다. 피어가 시작되는 순간에 등록되고 실행됩니다.

시스템 Chaincode가 피어와 연결되는 방법은 두가지가 있습니다.

Go 플러그인에서 정적이거나 동적으로 연결될 수 있습니다.

이번 튜토리얼은 시스템 Chaincode를 플러그인으로서 어떻게 개발하고 불러오는지를 배울 계획입니다.

플러그인 개발하기

시스템 Chaincode는 Go언어로 쓰여지고 Go 플러그인으로 불려집니다.

플러그인은 외부의 심볼와 main 패키지를 포함하고, 아래의 커맨드로 빌드합니다.

go build -buildmode=plugin

이미 존재하는 QSCC같은 Chaincode는 접근 관리 같은 전형적으로 시스템 Chaincode를 통해 실행되는 확실한 특징을 위한 탬플릿으로 취급 받습니다.

존재하는 시스템 Chaincode는 또한 로깅이나 테스팅 같은 최고의 예시로 참고할 수 있도록 취급받습니다.

- 주의 사항

임포트 된 패키지: Go 스탠다드 라이브러리는 플러그인이 반드시 호스트 어플리케이션에서 요구되는 버전과 같은 것을 포함해야합니다.

플러그인 설정하기

플러그인은 chaincode.systemPlugin 섹션에서 core.yaml로 설정 할 수 있습니다.

chaincode:
  systemPlugins:
    - enabled: true
      name: mysyscc
      path: /opt/lib/syscc.so
      invokableExternal: true
      invokableCC2CC: true

시스템 Chaincode는 반드시 chaincode.system 섹션에 core.yaml로 리스트가 될 수 있습니다.

chaincode:
  system:
    mysyscc: enable


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

Chaincode는 Go로 쓰여진 프로그램으로, Java와 같은 다른 프로그래밍 언어로 구현 가능합니다.  

ChainCode는 규정된 인터페이스를 실행합니다.

Chaincode는 Endorsing Peer Process와 격리된  안전한 Docker container에서 실행됩니다.

어플리케이션에서 제출한 트랜잭션을 통해, Chaincode는 원장 State 초기화 및 관리를 합니다.

 

Chaincode는 네트워크의 구성원으로부터 동의된 비즈니스 로직을 일반적으로 다루고, Smart Contract와 유사합니다.

Chaincode는 트랜잭션 제안에 업데이트 또는 쿼리를 하기 위해서 호출될 수 있습니다.

Chaincode에 의해 생성된 상태(state)의 범위는 해당 체인코드로 한정되며, 다른 체인코드에 의해서 직접 access할 수 없습니다.

그러나, 동일 네트워트 상에서 적절한 권한이 주어지면 체인 코드는 다른 체인코드를 호출하여 해당 상태(state) 상태에 acess할 수 있습니다.

 

 이번 섹션에선 블록체인 네트워크 Operator 관점에서 Chaincode를 알아볼 것입니다.

Operator 관점에선 Noah라고 불리는데, Noah의 관심점은, Chaincode의 생애주기 오퍼레이션에 중점을 둘 예정입니다;

이는 패키징, 설치, 인스턴스화 그리고 업그레이드 같은 블록체인 내부의 Chaincode의 operational한 생애주기입니다.

Chaincode 생애주기

Hyperledger Fabric API는 피어, Orderer 및 MSP와 같은 블록 체인 네트워크의 다양한 노드와의 상호 작용을 가능하게 합니다.

또한 인증 피어 노드에 Chaincode를 패키징, 설치, 인스턴스화 및 업그레이드 할 수있게 합니다. 

Hyperledger Fabric 언어 - 특히 SDK는,  Hypercode Fabric API의 특성을 추상화하여 응용 프로그램 개발을 용이하게하지만 Chaincode의 수명주기를 관리하는 데 사용할 수 있습니다. 또한 Hyperledger 패브릭 API는 CLI를 통해 직접 액세스 할 수 있습니다.  이 문서에서는 CLI를 사용합니다.

 

우리는 chaincode의 라이프 사이클을 관리 할 수있는 네 개의 명령 - packageinstallinstantiate, 및 upgrade 을 제공 합니다.

향후 버전에서는 Chaincode를 실제로 제거하지 않고도 Chaincode를 비활성화하고 다시 활성화하는 트랜잭션을  stop하고 start하는 트랜잭션을 추가할 것입니다. Chaincode가 성공적으로 설치되고 인스턴스화 된 후에는 Chaincode가 활성화되어 실행 중인 invoke 트랜잭션을 통해 트랜잭션을 처리 할 수 ​​있습니다. Chaincode는 설치 후 언제든지 업그레이드 할 수 있습니다.

패키징

chaincode 패키지는 다음 세 부분으로 구성됩니다.

  • ChaincodeDeploymentSpec또는 CDS에 의해 정의 된 Chaincode , 
    CDS는 코드와 이름 및 버전과 같은 기타 속성의 chaincode 패키지를 정의합니다
  • • Endorsement에 사용 된 동일한 정책에 의해 구문 적으로 설명 될 수 있고 Endorsement Policy에 설명되어있는 선택적 인스턴스 정책. 그리고
  • Chaincode를 "소유하고있는"엔티티에 의한 일련의 서명.

서명은 다음과 같은 용도로 사용됩니다.

  • Chaincode의 소유권을 확립하고,
  • 패키지의 내용을 검증 할 수 있으며,
  • 패키지 변조를 탐지 할 수 있습니다.

채널상의 Chaincode의 인스턴스 생성 트랜잭션 생성자는 Chaincode의 인스턴스화 정책에 대해 유효성이 검사됩니다.

패키지 만들기

Chaincode를 패키징하는 데는 두 가지 방법이 있습니다. 하나는 Chaincode의 소유자를 여러 명 갖고 싶어하므로 여러 ID로 서명 된 chaincode 패키지가 있어야합니다. 이 작업 과정에서는 초기에 서명 된 Chaincode 패키지 (a SignedCDS)를 생성해야하며, 서명 된 Chaincode 패키지 는 연속적으로 서명을 위해 다른 각 소유자에게 전달됩니다.

더 간단한 워크 플로우는 install 트랜잭션을 _ 행하는 노드의 ID의 서명 만 갖는 SignedCDS를 전개 할 때 사용 됩니다.

먼저 복잡한 사례를 다룰 것입니다. 그러나 아직 여러 소유자를 걱정할 필요가없는 경우 아래 Chaincode 설치 섹션으로 건너 뛸 수 있습니다 .

서명 된 chaincode 패키지를 만들려면 다음 명령을 사용하십시오.

peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out

이 -s옵션은 단순히 원시 CDS를 작성하는 것이 아니라 여러 소유자가 서명 할 수있는 패키지를 작성합니다.  이때 -s가 지정되면, -S 옵션은 다른 소유자가 로그인해야 위하여려고하는 경우에 지정해야합니다. 그렇지 않으면, 프로세스는 CDS뿐만 아니라 인스턴스화 정책 만 포함하는 SignedCDS를 작성합니다.

 

이 -S옵션은에있는 localMspid속성 의 값으로 식별되는 MSP를 사용하여 패키지에 서명하도록 프로세스에 지시합니다 core.yaml.

이 -S옵션은 선택 사항입니다. 그러나 패키지가 서명없이 작성된 경우, signpackage명령을 사용하여 다른 소유자가 서명 할 수 없습니다 .

선택적 -i옵션은 chaincode에 대한 인스턴스화 정책을 지정할 수있게합니다. 인스턴스화 정책은 승인 정책과 동일한 형식을 가지며 Chaincode를 인스턴스화 할 수있는 ID를 지정합니다. 위의 예에서 OrgA의 관리자 만이 chaincode를 인스턴스화 할 수 있습니다. 정책이 제공되지 않으면 기본 정책이 사용되며 피어의 MSP의 관리자 ID 만 Chaincode를 인스턴스화 할 수 있습니다.

패키지 서명

작성시 서명 된 Chaincode 패키지는 검사 및 서명을 위해 다른 소유자에게 양도 될 수 있습니다. 워크 플로는 Chaincode 패키지의 대역 외 서명을 지원합니다.

ChaincodeDeploymentSpec는 선택적으로 만들기 위해 공동 소유자에 의해 서명 될 수있습니다.

SignedChaincodeDeploymentSpec (또는 SignedCDS을). SignedCDS는 3 가지 요소를 포함합니다 :

  1. CDS에는 Chaincode의 소스 코드, 이름 및 버전이 들어 있습니다.
  2. Endorsement Policy로 표현 된 Chaincode의 인스턴스 정책.
  3. 배서의 수단으로 정의 된 Chaincode 소유자 목록 .

노트

이 인증 정책은 일부 채널에서 Chaincode가 인스턴스화 될 때 적절한 MSP 보안 주체를 제공하기 위해 대역 외로 결정됩니다. 인스턴스화 정책이 지정되지 않은 경우 기본 정책은 채널의 모든 MSP 관리자입니다.

각 소유자는 ChaincodeDeploymentSpec을 해당 소유자의 신원 (예 : 인증서)과 결합하고 결합 된 결과에 서명함으로써 ChaincodeDeploymentSpec을 승인합니다.

Chaincode 소유자는 다음 명령을 사용하여 이전에 작성한 서명 된 패키지에 서명 할 수 있습니다.

peer chaincode signpackage ccpack.out signedccpack.out

여기서 ccpack.outsignedccpack.out는 입력 및 출력 패키지입니다. signedccpack.out로컬 MSP를 사용하여 서명 된 패키지에 대한 추가 서명을 포함합니다.

Chaincode 설치

install 트랜잭션은 ChaincodeDeploymentSpec 또는 CDS의 형태로 정리된 포맷으로 Chaincode 소스코드를 패키징 해줍니다.

그리고 피어 노드에 설치하고 해당 Chaincode를 실행할 것입니다.

노트

Chaincode를 실행할 채널의  엔드 피어 노드에 Chaincode를 설치해야합니다 .

단순히 ChaincodeDeploymentSpec이 주어진 Install API일 때, 기본적으로 인스턴스화 정책과 빈 오너 리스트를 가지게 될 것입니다.

노트

Chaincode는 Chaincode 소유 구성원의 피어 노드를 승인하는 경우에만 설치해야 네트워크의 다른 구성원으로부터 Chaincode 논리의 기밀성을 보호 할 수 있습니다. Chaincode가없는 멤버는 Chaincode의 트랜잭션을 승인 할 수 없습니다. 즉, Chaincode를 실행할 수 없습니다. 그러나 이들은 여전히 ​​장부에 대한 트랜잭션의 유효성을 검사하고 커밋 할 수 있습니다.

Chaincode를 설치하기 위해선, SignedProposal을 시스템 Chaincode 섹션에서 설명된 lifecycle system chaincode를 전송하십시오.

예를 들어, CLI를 사용하여 Simple Asset Chaincode 섹션에 설명 된 sacc 샘플 체인 코드 를 설치하려면 명령이 다음과 같아야합니다.

peer chaincode install -n asset_mgmt -v 1.0 -p sacc

CLI는 내부적으로 sacc에 SignedChaincodeDeploySpec을 만들고, 로컬 피어에 전송합니다. 이는 LSCC에서 install 메소드로 불립니다.

인자 -p는 chaincode의 경로를 의미하고, 유저의 GOPATH에 있어야합니다.(예:GOPATH/src/sacc) CLI 섹션을 확인하시면 커맨드 옵션에 완벽한 설명이 되어 있습니다.

피어에 설치하기 위해선, SignedProposal의 서명이 로컬 MSP 관리자 중 하나여야만 합니다.

인스턴스화

instantiate 트랜잭션이 호출 (LSCC)를 작성하고 채널에 chaincode를 초기화 할 수 있습니다. 이것은 Chaincode 채널 바인딩 프로세스입니다. Chaincode는 여러 채널에 바인딩되어 각 채널에서 개별적으로 독립적으로 작동 할 수 있습니다. 즉, Chaincode를 설치하고 인스턴스화 할 수있는 다른 채널 수에 관계없이 State는 트랜잭션이 제출 된 채널과 격리되어 있습니다.lifecycle System Chaincode

instantiate 트랜잭션 생성자는 SignedCDS에 포함 된 Chaincode의 인스턴스화 정책을 충족해야하며 채널 작성자로 채널 작성자로 구성되어야합니다. 채널의 보안이 악성 엔티티가 Chaincode를 배포하거나 구성원을 속여 언 바운드 채널에서 Chaincode를 실행하는 것을 방지하는 데 중요합니다.

예를 들어 기본 인스턴스화 정책은 모든 채널 MSP 관리자이므로 Chaincode 인스턴스 생성 트랜잭션 작성자는 채널 관리자의 구성원이어야합니다. 트랜잭션 제안서가 엔도 서에 도착하면 생성자의 서명을 인스턴스화 정책과 비교하여 검증합니다. 이 작업은 장부에 커밋하기 전에 트랜잭션 유효성 검사 중에 다시 수행됩니다.

또한 인스턴스 생성 트랜잭션은 채널에서 해당 Chaincode에 대한 Endorsement Policy를 설정합니다. Endorsement Policy는 채널 구성원이 승인 한 트랜잭션 결과에 대한 증명 요구 사항을 설명합니다.

예를 들어, 인스턴스화 CLI를 사용하여 SACC chaincode와 함께 State를 john과 0으로 초기화하고, 명령은 다음과 같습니다

peer chaincode instantiate -n sacc -v 1.0 -c '{"Args":["john","0"]}' -P "OR ('Org1.member','Org2.member')"

노트

Endorsement Policy에 유의하십시오 .이 경우 모든 트랜잭션이 sacc 할 수 있도록 Org1 또는 Org2 구성원의 Endorsement가 필요합니다 . 즉, Org1 또는 Org2는 유효한 트랜잭션이되도록 sacc 에서  를 실행 한 결과에 서명해야 합니다.

성공적으로 인스턴스화 된 후에는 Chaincode가 채널의 활성 State가되며 ENDORSER_TRANSACTION 유형의 모든 트랜잭션 제안을 처리 할 준비가됩니다 . 트랜잭션은 Endorsement 피어에 도착하면서 동시에 처리됩니다.

업그레이드

체인 코드는 SignedCDS의 일부 버전을 변경하여 언제든지 업그레이드 할 수 있습니다. 소유자 및 인스턴스 정책과 같은 다른 부분은 선택 사항입니다. 그러나 체인 코드 이름은 동일해야합니다. 그렇지 않으면 완전히 다른 체인 코드로 간주됩니다.

업그레이드하기 전에 새 버전의 체인 코드를 필요한 endorser에 설치해야합니다. 업그레이드는 체인 코드의 새 버전을 채널에 바인드하는 인스턴스화 트랜잭션과 유사한 트랜잭션입니다. 체인 코드의 이전 버전에 바인딩 된 다른 채널은 여전히 ​​이전 버전과 함께 실행됩니다. 즉, upgrade트랜잭션은 한 번에 하나의 채널 (트랜잭션이 제출되는 채널)에만 영향을줍니다.

노트

체인 코드의 여러 버전이 동시에 활성화 될 수 있으므로 업그레이드 프로세스가 자동으로 이전 버전을 제거하지 않으므로 사용자는 당분간이를 관리해야합니다.

instantiate트랜잭션 과의 미묘한 차이점이 있습니다. upgrade트랜잭션은 새 정책 (지정된 경우)이 아닌 현재 체인 코드 인스턴스화 정책에 대해 검사됩니다. 이것은 현재 인스턴스화 정책에 지정된 기존 구성원 만이 체인 코드를 업그레이드 할 수 있도록하기위한 것입니다.

노트

업그레이드 중에 chaincode Init함수가 호출되어 데이터 관련 업데이트를 수행하거나 다시 초기화하므로 체인 코드를 업그레이드 할 때 State를 다시 설정하지 않도록주의해야합니다.

중지 및 시작

stopstart라이프 사이클 트랜잭션은 아직 구현되지 않았습니다. 그러나 각 endorsers에서 chaincode 컨테이너와 SignedCDS 패키지를 제거하여 체인 코드를 수동으로 중지 할 수 있습니다.  이것은 인증 피어 노드가 실행중인 각 호스트 또는 가상 시스템에서 체인 코드의 컨테이너를 삭제 한 다음 각 인증 피어 노드에서 SignedCDS를 삭제하여 수행됩니다.

참고 : 피어 노드에서 CDS를 삭제하려면 먼저 피어 노드의 컨테이너에 들어가야합니다. 이를 수행 할 수있는 유틸리티 스크립트를 제공해야합니다.
docker rm -f <container id>
rm /var/hyperledger/production/chaincodes/<ccname>:<ccversion>

Stop은 업그레이드를하기 전에 모든 피어의 채널에서 체인 코드를 중지 할 수있는 제어 된 방식으로 업그레이드를 수행하는 워크 플로에서 유용합니다.

CLI

 참고 : 우리는 Hyperledger Fabric 바이너리 용 플랫폼 특정 peer 바이너리를 배포 할 필요성을 평가하고 있습니다. 당분간, 실행중인 도커 컨테이너에서 명령을 간단히 호출 할 수 있습니다.

현재 사용 가능한 CLI 명령을 보려면 실행중인 fabric-peerDocker 컨테이너 에서 다음 명령을 실행하십시오 .

docker run -it hyperledger/fabric-peer bash 
# peer chaincode --help

아래 예제와 비슷한 출력을 보여줍니다 :

Usage:
  peer chaincode [command]

Available Commands:
  install     Package the specified chaincode into a deployment spec and save it on the peer's path.
  instantiate Deploy the specified chaincode to the network.
  invoke      Invoke the specified chaincode.
  list        Get the instantiated chaincodes on a channel or installed chaincodes on a peer.
  package     Package the specified chaincode into a deployment spec.
  query       Query using the specified chaincode.
  signpackage Sign the specified chaincode package
  upgrade     Upgrade chaincode.

Flags:
      --cafile string      Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
  -h, --help               help for chaincode
  -o, --orderer string     Ordering service endpoint
      --tls                Use TLS when communicating with the orderer endpoint
      --transient string   Transient map of arguments in JSON encoding

Global Flags:
      --logging-level string       Default logging level and overrides, see core.yaml for full syntax
      --test.coverprofile string   Done (default "coverage.cov")
  -v, --version

Use "peer chaincode [command] --help" for more information about a command.

스크립트 응용 프로그램에서의 사용을 용이하게하기 위해 peer명령은 명령 실패시 항상 0이 아닌 리턴 코드를 생성합니다.

체인 코드 명령의 예 :

peer chaincode install -n mycc -v 0 -p path/to/my/chaincode/v0
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["a", "b", "c"]}' -C mychannel
peer chaincode install -n mycc -v 1 -p path/to/my/chaincode/v1
peer chaincode upgrade -n mycc -v 1 -c '{"Args":["d", "e", "f"]}' -C mychannel
peer chaincode query -C mychannel -n mycc -c '{"Args":["query","e"]}'
peer chaincode invoke -o orderer.example.com:7050  --tls --cafile $ORDERER_CA -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'

시스템 체인 코드

시스템 체인 코드는 일반적인 체인 코드와 같은 격리 된 컨테이너가 아닌 피어 프로세스 내에서 실행된다는 점을 제외하고는 동일한 프로그래밍 모델을 사용합니다. 따라서 시스템 체인 코드는 피어 실행 파일에 내장되어 있으며 위에서 설명한 동일한 수명주기를 따르지 않습니다. 특히 설치 , 인스턴스화 및 업그레이드 는 시스템 체인 코드에 적용되지 않습니다.

시스템 체인 코드의 목적은 피어와 체인 코드 간 gRPC 통신 비용을 단축하고 관리 유연성을 절충하는 것입니다. 예를 들어, 시스템 체인 코드는 피어 이진 파일로만 업그레이드 할 수 있습니다. 또한 컴파일 된 매개 변수 의 고정 세트로 등록해야하며 Endorsement Policy 또는 Endorsement Policy 기능이 없습니다.

시스템 체인 코드는 Hyperbridger Fabric에서 시스템 통합 자에 의해 적절하게 대체되거나 수정 될 수 있도록 여러 시스템 동작을 구현하는 데 사용됩니다.

시스템 체인 코드의 현재 목록 :

  1. LSCC Lifecycle 시스템 체인 코드는 위에서 설명한 라이프 사이클 요청을 처리합니다.
  2. CSCC 구성 시스템 체인 코드는 피어 측의 채널 구성을 처리합니다.
  3. QSCC 쿼리 시스템 체인 코드는 블록 및 트랜잭션 가져 오기와 같은 원장 쿼리 API를 제공합니다.
  4. ESCC 인증 시스템 체인 코드는 트랜잭션 제안 제안서에 서명함으로써 Endorsement를 처리합니다.
  5. VSCC 유효성 검사 시스템 체인 코드는 Endorsement Policy 및 다중 버전 동시성 제어 검사와 같은 트랜잭션 유효성 검사를 처리합니다.

이러한 시스템 체인 코드, 특히 LSCC, ESCC 및 VSCC가 주 트랜잭션 실행 경로에 있으므로 수정 또는 교체 할 때는주의해야합니다. 

VSCC가 장부에 커밋하기 전에 블록의 유효성을 검사 할 때 채널의 모든 피어가 원장 분기 (비 결정 성)를 피하기 위해 동일한 유효성 검사를 계산하는 것이 중요합니다. 

따라서 VSCC가 수정되거나 대체 된 경우 특별한 주의가 필요합니다.


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

Chaincode는 Go와 Node.js로 쓰여진 프로그램입니다. 그리고 규정된 인터페이스를 실행합니다.

차후엔 자바와 같은 다른 프로그래밍 언어들도 지원할 것입니다.

Chaincode는 보안된 Docker container에 허가된 피어 프로세스와 격리되어 실행됩니다.

Chaincode는 어플리케이션에서 제출하여 트랜잭션으로 원장 State 초기화 및 관리를 합니다.

Chaincode는 전형적으로 네트워크의 구성원으로부터 동의된 비즈니스 로직을 다루고, 그래서 Smart Contract와 유사합니다.

Chaincode는 트랜잭션 제안에 업데이트 또는 쿼리를 하기 위해서 호출될 수 있습니다.

허가를 받은 State에서, Chaincode는 state에 액세스 하기 위해서 같은 Channel이나 다른 Channel에서도 또 다른 Chaincode를 호출할 수 있습니다.

만약 다른 Channel에서 호출된 Chaincode일 경우 읽기 전용으로만 접근이 가능하다는 점을 알고 계셔야합니다.

즉, 다른 Channel에서 불려진 Chaincode는 단지 쿼리일 뿐이라는 것을 의미합니다. 이는 이후의 커밋 페이즈에서 State 인증에 참여하지 않는다는 것을 의미하고 있습니다.

다음의 섹션에선, 어플리케이션 개발자의 입장에서 Chaincode를 배워볼 것 입니다.

단순한 어플리케이션의 샘플 코드와 Chaincode Shim API의 각각의 메소드의 목적을 확인하는 것을 보여드리겠습니다.

Chaincode API

각각의 Chaincode 프로그램은 아래의 Chaincode interface로 실행되어야합니다:

  • Go
  • Node.js

해당 인터페이스들의 전달받은 트랜잭션의 반응으로 메소드 콜을 발생시킵니다.

특히 Init 메소드는 Chaincode가 Instantiate나 Upgrade와 같은 트랜잭션 메소드를 어플리케이션 State에 관한 초기화를 포함하여 Chaincode가 필요한 초기화를 위해서 불려집니다.

Invoke 메소드는 Invoke 트랜잭션이 트랜잭션의 제안을 받았을 때 발생하게 됩니다.

다른 "Shim" API에 들어있는 Chaincode는 ChaincodeStubInterface 아래의 언어로 실행됩니다:

  • Go
  • Node.js

이들은 원장에 접근하거나 수정하기위해서 사용되고, Chaincode 간에 호출을 위해서 사용됩니다.

이번 튜토리얼에선, 단순한 "Asset"을 관리하는 Chaincode 어플리케이션을 실행함으로서 이러한 종류의 API 사용을 시연하겠습니다.

Simple Asset Chaincode

아래의 어플리케이션은 원장에 Asset을 Key-Value 페어로 만드는 간단한 샘플 Chaincode 입니다.

code의 디렉토리 설정하기

Go언어로 개발한 경험이 없으시다면, Go언어가 시스템에 적절하게 설정된 State로 설치되어 있어야 합니다.

지금부터, Chaincode 어플리케이션을 위한 하나의 child directory로서 $GOPATH/src/ 디렉토리를 만들겠습니다.

간단히 실행하기 위해선, 아래의 커맨드를 입력하세요.

mkdir -p $GOPATH/src/sacc && cd $GOPATH/src/sacc

코드를 써넣을 소스 코드를 만들어 보겠습니다.

touch sacc.go

시스템 하우스 관리

우선, 하우스 관리를 하면서 시작합시다. 모든 Chaincode들 처럼, Chaincode 인터페이스를 실행해주어야 합니다.

특히, Init과 Invoke 함수를 실행하셔야 합니다.

go언어에 Chaincode 의존성을 추가하십시오.

Chaincode shim package와 peer protobuf package를 임포트 할 것입니다.

다음으로, Simple Asset을 Chaincode Shim Function으로서 추가할 것 입니다.

package main

import (
    "fmt"

    "github.com/hyperledger/fabric/core/chaincode/shim"
    "github.com/hyperledger/fabric/protos/peer"
)

// SimpleAsset implements a simple chaincode to manage an asset
type SimpleAsset struct {
}

Chaincode 초기화

다음으로, Init 함수를 실행할 것입니다.

// Init is called during chaincode instantiation to initialize any data.
func (t *SimpleAsset) Init(stub shim.ChaincodeStubInterface) peer.Response {

}

해당 함수에서 이미 Chaincode 업그레이드가 이루어진다는 것을 확인하세요.

Chaincode를 작성할 때 이전의 것을 업그레이드 할 것입니다.

Init을 적절하게 수정하셔야합니다.

특히, "마이그레이션"이 없으면 아무 것도 초기화 되지 않고, 비어있는 Init 메소드를 제공합니다.

다음으로, Init 호출에서 ChaincodeStubInterface.GetStringArgs 메소드를 통해 매개변수를 돌려받습니다. 그리고 유효성을 체크합니다.

우리의 경우에, Key-Value 쌍을 기대할 수 있습니다.

// Init is called during chaincode instantiation to initialize any
// data. Note that chaincode upgrade also calls this function to reset
// or to migrate data, so be careful to avoid a scenario where you
// inadvertently clobber your ledger's data!
func (t *SimpleAsset) Init(stub shim.ChaincodeStubInterface) peer.Response {
  // Get the args from the transaction proposal
  args := stub.GetStringArgs()
  if len(args) != 2 {
    return shim.Error("Incorrect arguments. Expecting a key and a value")
  }
}

다음 단계는, 호출이 유효할 수 있도록 만들어 냈습니다, 이제 원장에 초기 State를 저장할 것입니다.

이 단계를 진행하기에 앞서, ChaincodeStubInterface.Putstate를 불러내어 Key와 Value를 인자로 전송할 것 입니다.

모든 것이 잘 되었다는 전제하에, 초기화 하는 Response 객체가 성공했을 것입니다.

 1 // Init is called during chaincode instantiation to initialize any
 2 // data. Note that chaincode upgrade also calls this function to reset
 3 // or to migrate data, so be careful to avoid a scenario where you
 4 // inadvertently clobber your ledger's data!
 5 func (t *SimpleAsset) Init(stub shim.ChaincodeStubInterface) peer.Response {
 6   // Get the args from the transaction proposal
 7   args := stub.GetStringArgs()
 8   if len(args) != 2 {
 9     return shim.Error("Incorrect arguments. Expecting a key and a value")
10   }
11 
12   // Set up any variables or assets here by calling stub.PutState()
13 
14   // We store the key and the value on the ledger
15   err := stub.PutState(args[0], []byte(args[1]))
16   if err != nil {
17     return shim.Error(fmt.Sprintf("Failed to create asset: %s", args[0]))
18   }
19   return shim.Success(nil)
20 }

Chaincode 호출

우선, Invoke 함수의 서명을 추가합니다.

// Invoke is called per transaction on the chaincode. Each transaction is
// either a 'get' or a 'set' on the asset created by Init function. The 'set'
// method may create a new asset by specifying a new key-value pair.
func (t *SimpleAsset) Invoke(stub shim.ChaincodeStubInterface) peer.Response {

}

위에서의 Invoke 함수와 함께, ChaincodeStubInterface로부터 인자를 추출해낼 필요가 있습니다.

Invoke 함수의 인자는 호출할 Chaincode 어플리케이션의 함수 이름입니다.

우리의 경우에, 간단히 두 가지의 함수를 가지고 있습니다: set & get

해당 함수들을 통해서 asset의 값을 set할 수 있고, 또한 현재 State를 리턴 받을 수 있습니다.

우리는 우선 ChaincodeStrubInterface.GetFunctionAndParameters를 함수의 이름과 매개변수를 chaincode 어플리케이션 함수에 추출하기 위해서 호출 할 것입니다.

// Invoke is called per transaction on the chaincode. Each transaction is
// either a 'get' or a 'set' on the asset created by Init function. The Set
// method may create a new asset by specifying a new key-value pair.
func (t *SimpleAsset) Invoke(stub shim.ChaincodeStubInterface) peer.Response {
    // Extract the function and args from the transaction proposal
    fn, args := stub.GetFunctionAndParameters()

}

다음으로, 우리는 함수의 이름을 set과 get과 같은 형태로 만들어 낼 것입니다. 그리고 해당되는 Chaincode 어플리케이션 함수를 적절한 Shim.success와 Shim.error 함수를 gRPC protobuf 메시지 형태로 응답하며 시리얼라이즈 출력을 하면서 호출해낼 것 입니다.

// Invoke is called per transaction on the chaincode. Each transaction is
// either a 'get' or a 'set' on the asset created by Init function. The Set
// method may create a new asset by specifying a new key-value pair.
func (t *SimpleAsset) Invoke(stub shim.ChaincodeStubInterface) peer.Response {
    // Extract the function and args from the transaction proposal
    fn, args := stub.GetFunctionAndParameters()

    var result string
    var err error
    if fn == "set" {
            result, err = set(stub, args)
    } else {
            result, err = get(stub, args)
    }
    if err != nil {
            return shim.Error(err.Error())
    }

    // Return the result as success payload
    return shim.Success([]byte(result))
}

Chaincode 어플리케이션 실행하기

씌여진 대로, 우리의 Invoke 함수를 통해서 두개의 함수를 가진 Chaincode 어플리케이션을 실행할 것입니다.

이제 해당하는 함수들을 실행합니다. 위에서 말한 것처럼, 원장에 접근하기 위해선, ChaincodeStubInterface.Putstate와 ChaincodeStubInterface.Getstate 함수를 Chaincode shim API로부터 불러들일 것 입니다.

// Set stores the asset (both key and value) on the ledger. If the key exists,
// it will override the value with the new one
func set(stub shim.ChaincodeStubInterface, args []string) (string, error) {
    if len(args) != 2 {
            return "", fmt.Errorf("Incorrect arguments. Expecting a key and a value")
    }

    err := stub.PutState(args[0], []byte(args[1]))
    if err != nil {
            return "", fmt.Errorf("Failed to set asset: %s", args[0])
    }
    return args[1], nil
}

// Get returns the value of the specified asset key
func get(stub shim.ChaincodeStubInterface, args []string) (string, error) {
    if len(args) != 1 {
            return "", fmt.Errorf("Incorrect arguments. Expecting a key")
    }

    value, err := stub.GetState(args[0])
    if err != nil {
            return "", fmt.Errorf("Failed to get asset: %s with error: %s", args[0], err)
    }
    if value == nil {
            return "", fmt.Errorf("Asset not found: %s", args[0])
    }
    return string(value), nil
}

모든 값을 가져오기

마지막으로 main 함수를 추가해야할 필요가 있습니다. 이 함수는 shim.start 함수를 불러낼 것입니다.

이제 전체 Chaincode 소스코드를 보여드리겠습니다.

package main

import (
    "fmt"

    "github.com/hyperledger/fabric/core/chaincode/shim"
    "github.com/hyperledger/fabric/protos/peer"
)

// SimpleAsset implements a simple chaincode to manage an asset
type SimpleAsset struct {
}

// Init is called during chaincode instantiation to initialize any
// data. Note that chaincode upgrade also calls this function to reset
// or to migrate data.
func (t *SimpleAsset) Init(stub shim.ChaincodeStubInterface) peer.Response {
    // Get the args from the transaction proposal
    args := stub.GetStringArgs()
    if len(args) != 2 {
            return shim.Error("Incorrect arguments. Expecting a key and a value")
    }

    // Set up any variables or assets here by calling stub.PutState()

    // We store the key and the value on the ledger
    err := stub.PutState(args[0], []byte(args[1]))
    if err != nil {
            return shim.Error(fmt.Sprintf("Failed to create asset: %s", args[0]))
    }
    return shim.Success(nil)
}

// Invoke is called per transaction on the chaincode. Each transaction is
// either a 'get' or a 'set' on the asset created by Init function. The Set
// method may create a new asset by specifying a new key-value pair.
func (t *SimpleAsset) Invoke(stub shim.ChaincodeStubInterface) peer.Response {
    // Extract the function and args from the transaction proposal
    fn, args := stub.GetFunctionAndParameters()

    var result string
    var err error
    if fn == "set" {
            result, err = set(stub, args)
    } else { // assume 'get' even if fn is nil
            result, err = get(stub, args)
    }
    if err != nil {
            return shim.Error(err.Error())
    }

    // Return the result as success payload
    return shim.Success([]byte(result))
}

// Set stores the asset (both key and value) on the ledger. If the key exists,
// it will override the value with the new one
func set(stub shim.ChaincodeStubInterface, args []string) (string, error) {
    if len(args) != 2 {
            return "", fmt.Errorf("Incorrect arguments. Expecting a key and a value")
    }

    err := stub.PutState(args[0], []byte(args[1]))
    if err != nil {
            return "", fmt.Errorf("Failed to set asset: %s", args[0])
    }
    return args[1], nil
}

// Get returns the value of the specified asset key
func get(stub shim.ChaincodeStubInterface, args []string) (string, error) {
    if len(args) != 1 {
            return "", fmt.Errorf("Incorrect arguments. Expecting a key")
    }

    value, err := stub.GetState(args[0])
    if err != nil {
            return "", fmt.Errorf("Failed to get asset: %s with error: %s", args[0], err)
    }
    if value == nil {
            return "", fmt.Errorf("Asset not found: %s", args[0])
    }
    return string(value), nil
}

// main function starts up the chaincode in the container during instantiate
func main() {
    if err := shim.Start(new(SimpleAsset)); err != nil {
            fmt.Printf("Error starting SimpleAsset chaincode: %s", err)
    }
}

Chaincode 만들기

Chaincode를 컴파일 하겠습니다.

go get -u --tags nopkcs11 github.com/hyperledger/fabric/core/chaincode/shim
go build --tags nopkcs11

오류가 없다는 전제하에, Chaincode를 테스팅 하는 다음단계로 나아가실 수 있습니다.

개발자 모드로 테스팅하기

일반적으로 Chaincode는 피어에 의해서 시작되고 관리됩니다. 그러나 개발자 모드에선 Chaincode는 사용자에 의해서 만들어지고 제작됩니다.

이 모드는 개발 도중 빠른 코딩/빌드/실행/디버그 사이클을 돌려보는 것에 매우 유용합니다.

우리는 샘플 개발자 네트워크에서 이미 만들어진 Orderer와 채널 아티팩트를 사용해서 개발자 모드를 시작할 것입니다.

마찬가지로, 사용자는 바로 Chaincode를 컴파일 하고 실행해보실 수 있습니다.

Hyperledger Fabric Sample 설치하기

앞의 과정이 문제없이 해결되셨다면, Hyperledger Sample을 설치하십시오.

Docker의 chaincode-docker-devmode 디렉토리의 fabric-samples를 복사하십시오.

cd chaincode-docker-devmode

Docker 이미지 다운로드 하기

개발자 모드를 위해선 제공된 Docker Compose 스크립트를 이용해서 4개의 Docker 이미지를 활용해야 합니다.

만약 fabric-samples 디렉토리에 복사본을 설치하셨다면 DownloadPlatform-specific Binaies의 지시를 따르시면 됩니다.

그러면, 로컬에 설치된 Docker 이미지를 가질 수 있습니다.

만약 수동으로 받아온 이미지라면 latest를 붙이셔야만 합니다.

docker images
REPOSITORY                     TAG                                  IMAGE ID            CREATED             SIZE
hyperledger/fabric-tools       latest                           b7bfddf508bc        About an hour ago   1.46GB
hyperledger/fabric-tools       x86_64-1.1.0                     b7bfddf508bc        About an hour ago   1.46GB
hyperledger/fabric-orderer     latest                           ce0c810df36a        About an hour ago   180MB
hyperledger/fabric-orderer     x86_64-1.1.0                     ce0c810df36a        About an hour ago   180MB
hyperledger/fabric-peer        latest                           b023f9be0771        About an hour ago   187MB
hyperledger/fabric-peer        x86_64-1.1.0                     b023f9be0771        About an hour ago   187MB
hyperledger/fabric-javaenv     latest                           82098abb1a17        About an hour ago   1.52GB
hyperledger/fabric-javaenv     x86_64-1.1.0                     82098abb1a17        About an hour ago   1.52GB
hyperledger/fabric-ccenv       latest                           c8b4909d8d46        About an hour ago   1.39GB
hyperledger/fabric-ccenv       x86_64-1.1.0                     c8b4909d8d46        About an hour ago   1.39GB

docker image를 발급해서 로컬 Docker Registry에 올리십시오. 아래와 같은 것을 확인하실 수 있을 것입니다.

이제 3개의 터미널을 열어 chaincode-docker-devmode 디렉토리로 모든 터미널을 이동해주십시오.

터미널1 네트워크 시작하기

docker-compose -f docker-compose-simple.yaml up

위의 커맨드는 singleSampleMSPSolo의 Orderer 정보와 함께 네트워크를 시작합니다.

그리고 피어를 개발자 모드로 실행합니다.

남은 두개의 컨테이너는 chaincode 환경과 CLI 환경을 위한 것입니다.

채널을 만들고 참여하기 위한 기능들은 CLI환경에서 제공합니다.

그렇기 때문에 바로 Chaincode 호출로 넘어갈 수 있습니다.

터미널2 빌드& 스타트 Chaincode

docker exec -it chaincode bash

입력하신 이후 아래와 같은 결과를 보실 수 있습니다.

root@d2629980e76b:/opt/gopath/src/chaincode#

Chaincode를 컴파일 하십시오.

cd sacc
go build

Chaincode를 실행하세요.

CORE_PEER_ADDRESS=peer:7052 CORE_CHAINCODE_ID_NAME=mycc:0 ./sacc

Chaincode가 피어와 함께 실행되었고, Chaincode 로그는 성공적인 등록을 피어와 마쳤을 것입니다.

이 단계에서 Chaincode가 어떤 채널과도 연관되지 않았다는 것을 아셔야합니다.

이 과정은 다음에 나올 Instantiate 커맨드에서 완료하실 수 있습니다.

터미널3 Chaincode 사용하기

비록 --peer-chaincodedev모드에 있더라도, Chaincode를 설치하셔야 chaincode 라이프 싸이클을 정상적으로 확인할 수 있습니다.

이 요구사항은 앞으로 사라질 예정입니다.

CLI 컨테이너에서 아래와 같은 명령으로 불러낼 수 있습니다.

docker exec -it cli bash
peer chaincode install -p chaincodedev/chaincode/sacc -n mycc -v 0
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["a","10"]}' -C myc

이제 a 값에 20을 할당하세요.

peer chaincode invoke -n mycc -c '{"Args":["set", "a", "20"]}' -C myc

마지막으로 쿼리 a를 실행하시고, 20이라는 값을 확인하세요

peer chaincode query -n mycc -c '{"Args":["query","a"]}' -C myc

새로운 Chaincode 테스팅하기

기본적으로, 여러분은 sacc만 마운팅하셨을 겁니다. 그러나 chaincode(chaincode 컨테이너를 의미함)에 다른 chaincode를 올림으로서 테스트해보실 수 있습니다.

이 지점 이후로 Chaincode 컨테이너로 접근 가능하실 것 입니다.

Chaincode 암호화

특정 시나리오에서는 전체 또는 부분적으로 키와 연관된 값을 암호화하는 것이 유용 할 수 있습니다. 예를 들어 개인의 주민등록번호 또는 주소가 원장에게 쓰여진 경우에 데이터가 일반 텍스트로 나타나지 않게 할 수 있습니다. 시리얼 코드 암호화는 상품 공장과 BCCSP wrapper 와 엔티티 확장을 활용하여 암호화 및 타원 곡선형 디지털 서명과 같은 암호화 작업을 수행함으로써 수행됩니다. 예를 들어 암호화하려면 chaincode의 호출자가 transient 필드를 통해 암호화 키를 전달합니다. 그러면 동일한 키가 후속 쿼리 작업에 사용되어 암호화 된 State 값을 적절히 해독 할 수 있습니다.

자세한 정보 및 샘플 은 디렉토리 내의 Encc 예제를 참조하십시오 fabric/examplesutils.go 도우미 프로그램을 확인해보십시오. 이 유틸리티는 chaincode shim API 및 Entities 확장을 로드하고 샘플 암호화 체인 코드가 활용 하는 새로운 클래스의 기능 (예 encryptAndPutStategetStateAndDecrypt)을 빌드합니다 . 따라서 체인 코드는 및 추가 된 기능 Get과 Put 함께 추가된 기능인 Encrypt와 Decript를 포함해서 기본 shim API와 결합 할 수 있습니다.

Go언어로 씌여진 Chaincode의 외부 의존성 관리

여러분의 Chaincode가 Go에서 제공하는 라이브러리에서 제공하는 패키지가 아닌 다른 패키지를 요구할 경우에, Chaincode에 패키지를 포함하실 수 있습니다.

이러한 의존성을 관리하거나 배포할 수 있는 다양한 툴이 있습니다.

governor라는 라이브러리를 이용해서 시연을 하겠습니다.

govendor init
govendor add +external  // Add all external package, or
govendor add github.com/external/pkg // Add specific external package

이렇게 임포트한 외부 의존성 파일은 vendor 디렉토리에 보관됩니다. peer chaincode package와 peer chaincode install과 같은 명령어는 Chaincode 패키지에 의존성과 관련된 코드를 포함합니다.


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

 Chaincode란 무엇입니까?

Chaincode는 프로그램입니다. Go, node.js, 그리고 마지막엔 자바와 같은 다른 프로그래밍 언어도 지원합니다.

이러한 Chaincode는 Interface로 규정되어 실행됩니다.

Chaincode는 보안된 Docker container에 허가된 피어 프로세스와 격리되어 실행됩니다.

Chaincode는 어플리케이션에서 제출하여 트랜잭션으로 원장 State 초기화 및 관리를 합니다.

Chaincode는 전형적으로 네트워크의 구성원으로부터 동의된 비즈니스 로직을 다루고, 그래서 Smart Contract로 간주됩니다.

Chaincode에서 만들어진 State는 배타적인 Chaincode이고 다른 Chaincode와 직접적으로 액세스가 가능하지 않은 범위에서 만들어집니다.

그러나, 같은 네트워크 안에서 적절한 허가를 얻은 Chaincode는 다른 Chaincode를 불러내어 State에 접근 가능 합니다.

두 개의 페르소나들

우리는 Chaincode에 두 개의 다른 관점을 제시합니다.

하나는 Chaincode for Developers라는 이름으로 어플리케이션 관점으로부터 개발자가 블록체인 어플리케이션이나 솔루션을 개발하게합니다.

두번째는 Chaincode for Operators라는 이름으로 블록체인 네트워크를 관리하는 업무를 하는 블록체인 네트워크 오퍼레이터로써의 역할을 지향합니다.

그리고 오퍼레이터로서 Hyperledger Fabric API를 설치하고, 인스턴스화 하고, Chaincode를 업그레이드 합니다. 그러나 Chaincode 어플리케이션 개발로서는 포함되지 않습니다.


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

+ Recent posts