Channel Configuration (configtx)

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/configtx.html

• Hyperledger Fabric blockchain-network에서 "공유 configuration구성"은, channel당 config-transaction의 묶음으로 저장되어 있습니다.
• 각각의 config-transaction을 바로 "configtx"라 부르기도 합니다.
• channel configuration은 아래와 같은 중요한 속성이 있습니다.
  
  • 1. Versioned(버젼) : configuration의 모든 요소들은 수정시, 버젼을 가집니다. 그리고 커밋된 configuration는 그 seq번호를 받습니다.
  • 2. Permissioned(허가) : configuration의 모든 요소들은 수정가능여부를 판단하는, 허용정책을 가집니다. 그래서 누구나 "이전 configtx"으로 정책에 따라 "new config"에 유효성을 확인할수있습니다.
  • 3. Hierarchical(상속) : configuration은 subconfiguration식으로 계층화 할수있습니다. 정책 단계화에 유용합니다.
• Anatomy of a configuration
  
  • configuration은 "HeaderType_CONFIG 타입"의 transaction 만 존재하는 block에 저장됩니다.
  • 바로 이런 block을 'config-block'이라고 합니다. (첫번째가 바로 genesis-block)
  • configuration의 "프로토 구조"는 'fabric/protos/common/configtx.proto' 경로에 저장됩니다.
  • "HeaderType_CONFIG 타입" 은 'ConfigEnvelope 메세지'를 인코딩 한것 입니다.
  • 'ConfigEnvelope 메세지'는 아래와 같습니다.
    
    • message ConfigEnvelope {
      • Config config = 1; // configuration 저장
      • Envelope last_update = 2; // 유효성 검사에만 사용 }
    • message Config {
      • uint64 sequence = 1; // configuration 커밋마다 증가
      • ConfigGroup channel_group = 2; // root그룹 및 configuration값 }
    • message ConfigGroup { 
      • uint64 version = 1;
      • map<string,ConfigGroup> groups = 2;
      • map<string,ConfigValue> values = 3;
      • map<string,ConfigPolicy> policies = 4;
      • string mod_policy = 5; }
      • // 재귀적,계층적으로 각 그룹의 값과 정책이 트리를 이룸
      • // 예) root, child1, child2, grandChild1, grandChild2, grandChild3
        • root.Groups["child1"] = child1
        • root.Groups["child2"] = child2
        • child1.Groups["grandChild1"] = grandChild1
        • child2.Groups["grandChild2"] = grandChild2
        • child2.Groups["grandChild3"] = 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; }
    • (ConfigGroup, ConfigValue, ConfigPolicy 모두 version 과 mod_policy 을 가짐)
    • (version은 수정시 증가, mod_policy는 수정에 필요한 서명을 관리.)
    • 예를들어, 특정 channel의 특정 application 관리는 아래와 같은식으로 될것같습니다.
      • 예) Channel.Groups["Application"].Policies["policy1"]
      • 예) Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]
      • 예) Channel.Policies["policy3"]
• Configuration updates
  
  • configuration의 업데이트는... "HeaderType_CONFIG_UPDATE 타입" 으로, 'ConfigUpdateEnvelope 메세지'를 마샬링 한것 입니다.
  • 'ConfigUpdateEnvelope 메세지'는 아래와 같습니다.
    
    • message ConfigUpdateEnvelope {
      • bytes config_update = 1; // ConfigUpdate 마샬링
      • repeated ConfigSignature signatures = 2; // 업데이트 인가 서명 }
    • message ConfigSignature {
      • bytes signature_header = 1;
      • bytes signature = 2; }
    • message ConfigUpdate {
      • string channel_id = 1; // 해당하는 channel id
      • ConfigGroup read_set = 2; // 기존 configuration (드물게 version 정도만 기록) 
      • ConfigGroup write_set = 3; // 신규 configuration (read_set 기록을 맞쳐줌) }
    • 예를들어, 특정 configuration의 업데이트는 아래와 같은식으로 될것같습니다.
      • 예) Channel에서 Application의 Org1을 수정하는 상황
      • Channel: (version 0)
        • Orderer (version 0)
        • Application (version 3)
          • Org1 (version 2)
      • 예) read_set
      • Channel: (version 0)
        • Application: (version 3)
      • 예) write_set
      • Channel: (version 0)
        • Application: (version 3)
          • Org1 (version 3)
  • orderer가 "HeaderType_CONFIG_UPDATE 타입"을 받게되면, 아래와 같은 단계로 처리합니다.
    • 1. 'channel_id' 와 'read_set' 을 확인 합니다. (read_set의 모든요소는 주어진 버젼에 존재 해야함)
    • 2. 'read_set'의 요소에서 업데이트된 버젼의 'write_set' 의 요소만을 "update set"으로 산출 합니다.
    • 3. "update set"의 각 요소버젼이 1씩 증가되는지? 확인합니다.
    • 4. 'ConfigUpdateEnvelope 메세지'의 서명이, 각 요소의 'mod_policy'를 만족하는지? 확인합니다.
    • 5. 현재 configuration에 "update set"을 적용하여, 새 configuration 버젼을 계산합니다.
    • 6. 'ConfigEnvelope 메세지'의 config 와 last_update 를 채워서 만듭니다.
    • 7. 해당 transaction으로 새로운 config-block을 만듭니다.
  • peer가 config-block을 받게되면, 'ConfigEnvelope 메세지'의 last_update를 활용하여~ 새 configuration 검증을 합니다.
• Permitted configuration groups and values
  
  • 유효한 ConfigGroup는 아래의 그림을 참고 하세요.

  • 

• Orderer system channel configuration
  
  • "ordering system channel'에는, 위의 "Orderer" 와 "Consortiums" 이 필요합니다.
  • ...
• Application channel configuration
  
  • "application'에는, 위의 "Application" 이 필요합니다.
  • ...
• Channel creation
  
  • orderer가 존재하지 않는 channel의 "HeaderType_CONFIG_UPDATE 타입"을 받게되면, 생성으로 간주 합니다.
    • 1. channel 생성이 수행될, consortium을 확인 합니다.
    • 2. Application 그룹에 포한된 해당 organization이 consortium에 해당하는지? 확인하고, 버젼1 로 합니다.
    • 3. consortium이 member를 가지는지 ??? 검사하고 새로운 channel도 member를 합니다 ???
    • 4. ...
    • 5. ...
    • 6. ...

-끝-