[Hyperledger Fabric v1.0] 4. OPREATION GUIDE(운영가이드): Channel Configuration(configtx)(채널 구성)

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

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

 Channel Configuration(configtx)(채널 구성)

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

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

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

Anatomy of a configuration(구성 해부)

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

구성을 위한 프로토 구조는 fabric/protos/common/configtx.proto에 저장됩니다. HeaderType_CONFIG형식의 봉투는 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;
}

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

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

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

Configuration Update(구성 업데이트)

구성 업데이트는 HeaderType_CONFIG_UPDATE 형식의 Payload 메시지로 전송됩니다. 트랜잭션의 Payload data 는 마샬링 된 ConfigUpdateEnvelope입니다. ConfigUpdateEnvelope는 다음과 같이 정의됩니다.

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

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

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

시그니처가 ConfigUpdateEnvelope 메시지의 signature_header bytes와 config_update bytes의 연결을 넘는 동안 signature_header는 표준 트랜잭션에 대해 정의 된 것과 같습니다.

ConfigUpdateEnvelope config_update 바이트는 다음과 같이 정의 된 마샬링 된 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  키와 같은 모든 키를 채울 필요는 없으며,  values또는 policies keys. 또는 정책 키 중 하나를 선택하십시오.

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가 수신되면 순서자는 다음을 수행하여 결과 CONFIG를 계산합니다.

1. channel_id 및 read_set을 확인합니다. read_set의 모든 요소는 주어진 버전에 존재해야합니다.
2. read_set의 동일한 버전에 나타나지 않는 write_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> 의 마샬링 된 프로토 메시지임을 나타내는 ConfigValue를 정의합니다. 공통된 표기법common.<MSG>, msp.<MSG>, and orderer.<MSG>는 비슷하지만 각각 fabric/protos/common/configuration.proto, fabric/protos/msp/mspconfig.proto, 그리고 fabric/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(시스템 채널 구성 순서 지정)

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

순서 매개 변수는 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,
            },
        },
    },

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

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

&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,
                    }
                },
            },
        },
    },
},

각 컨소시엄은 주문 조직의 조직 구성원과 마찬가지로 구성원 집합을 정의합니다. 각 컨소시엄은 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 ID 정보 만 인코딩하는 대신 각 조직은 AnchorPeers목록을 추가로 인코딩합니다. 이 목록은 다른 조직의 동료가 피어 가십 네트워킹을 위해 서로 연락 할 수있게합니다.

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

Channel creation(채널 생성)

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

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