티스토리 뷰

Blockchain/Hyperledger Fabric

[Hyperledger Fabric v1.4]Operations Guides: Channel Configuration (configtx)

miiingo 2019. 2. 27. 17:43
반응형

해당 글은 Hyperledger Fabric 페이지의 공식 문서를 번역 및 정리한 자료입니다.

원본 사이트 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/configtx.html?highlight=system%20channel


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는 ConfigEnvelope 메시지를 Payload data 필드로 인코딩 합니다. ConfigEnvelope의 프로토 타입은 다음과 같이 정의됩니다.

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

last_update 필드는 아래의 Updates to configuration(구성 업데이트) 섹션에서 정의되어 있지만 구성을 읽을 경우가 아닌, 검증할 때만 필요합니다. 대신 현재 커밋된 구성은 Config 메시지를 포함하는 config 필드에 저장됩니다.

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

sequence 번호는 각 구성이 커밋될 때마다 하나씩 증가합니다. channel_group 필드는 구성을 포함하는 root 그룹입니다. ConfigGroup 구조는 재귀적으로 정의되며 각 그룹에는 값(values)과 정책(policies)이 포함된 그룹 트리가 만들어집니다. 그것은 다음과 같이 정의됩니다. :

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

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

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

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가 있습니다. 요소(Element)의 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/policy2는 Channel.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;
}

서명이 ConfigUpdateEnvelope 메시지의 signature_header 바이트와 config_update 바이트의 연결을 넘는 동안 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은 구성 트리의 더 깊은 요소를 참조 할 수 있도록 맵 필드의 하위 집합을 가질 수 있습니다. 

예를 들어 Application그룹을 read_set에 포함시키려면 해당 부모(Channel 그룹)도 read set에 포함되어야하지만 Channel 그룹은 Orderer Group 키와 같이 모든 키를 채울 필요는 없으며, values 또는 policies 키 중 하나를 선택해도 됩니다.

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

예를 들어, 다음과 같이 주어진 구성에서 :

Channel: (version 0)
    Orderer (version 0)
    Application (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의 모든 요소를 ​​수집하여 업데이트 세트를 계산합니다 .
  3. 업데이트 세트의 각 요소가 요소 업데이트의 버전 번호를 정확히 1만큼 증가시키는 지 확인합니다.
  4. ConfigUpdateEnvelope에 첨부된 서명 세트가 업데이트 세트의 각 요소에 대한 mod_policy를 충족시키는지 확인합니다.
  5. 업데이트 세트를 현재 구성에 적용하여 새로운 전체 구성 버전을 계산합니다.
  6. 새로운 구성을 ConfigEnvelope에 기록합니다. 여기에는 last_update 필드로 CONFIG_UPDATE가 포함되고 config 필드에 인코딩된 새로운 구성이 증가된 sequence 값과 함께 기록됩니다.
  7. 새로운 ConfigEnvelope를 CONFIG 유형의 Envelope에 기록하고 궁극적으로 이것을 새로운 구성 블록에 유일한 트랜잭션으로 씁니다.

피어(또는 다른 Deliver 수신자)가 이 구성 블록을 수신하면 현재 구성에 last_update 메시지를 적용하고 순서 계산된(orderer-computed) 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.proto 및 fabric/protos/orderer/configuration.proto에 정의된 메시지를 사용합니다.

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

&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(Orderer 시스템 채널 구성)

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

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에 따라 ordering 노드의 기능이 결정됩니다. 채널별로 존재하므로 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 조직의 조직 구성원과 마찬가지로 구성원(members) 집합을 정의합니다. 각 컨소시엄은 또한 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 identity 정보만 인코딩하는 대신 각 조직은 AnchorPeers의 목록을 추가로 인코딩합니다. 이 목록은 다른 조직의 peer가 peer 가십 네트워킹을 위해 서로 접촉할 수있게 합니다.

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


Channel creation(채널 생성)

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


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


반응형
저작자표시 비영리 동일조건

'Blockchain > Hyperledger Fabric' 카테고리의 다른 글

[Hyperledger Fabric v2.0 Alpha] What’s new in the v2.0 Alpha  (0) 2019.04.15
[Hyperledger Fabric v1.4] Orderer System Channel 설정  (0) 2019.02.28
[Hyperledger Fabric v1.4] Operations Guides: Identity Mixer MSP configuration generator (idemixgen)  (0) 2019.02.11
[Hyperledger Fabric v1.4] Operations Guides: MSP Implementation with Identity Mixer  (0) 2019.02.11
[Hyperledger Fabric v1.4] Tutorials: Using Private Data in Fabric  (0) 2019.01.31
댓글
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG more
«   2024/04   »
일 월 화 수 목 금 토
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
글 보관함