3) Adding an Org to a Channel

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

• Adding an Org to a Channel
  
  • 이번에는 BYFN을 확장하는 의미로써, 'hyperledger fabric' 에서 channel 에 새로운 organization을 추가하는 법을 알아보려고 합니다.
  • 우선 새로운 organization 추가 하는것에만 초점을 맞추지만, 'channel 구성' 업데이트(poilcies,batch 등) 하는것도 비슷하게 할 수 있다는점을 잘 알고 있으시면 될 것 같습니다.
  • 이러하게 'channel 관리 및 설정'을 하는 작업은, 해당 organization의 admin 담당자의 영역 인점도 유의하세요.
• Setup the Environment
  
  • 이번에도 https://github.com/hyperledger/fabric-samples 의 /first-network 를 기반으로 진행됩니다.
  • 이번에도 '스크립트 자동 실습' 과 '직접 수동 실습' 을 모두 설명해 드립니다.
• Bring Org3 into the Channel with the Script
  
  • "./eyfn.sh up" 을 쳐보면, 다 알아서 되고~ 최종적으로 Org3에서 ledger에 쿼리를 할수있습니다...
• Bring Org3 into the Channel Manually
  
  • 일단 byfn.sh 와 eyfn.sh 으로, 기존 docker를 정리하고~ 새롭게 다시 띄운뒤... /org3-artifacts 경로에서 한다.
  • 1) Generate the Org3 Crypto Material
    
    • cryptogen generate --config=./org3-crypto.yaml
    • export FABRIC_CFG_PATH=$PWD
    • configtxgen -printOrg Org3MSP > ../channel-artifacts/org3.json
    • (org3를 위한, cryptogen 및 configtxgen 수행함. -printOrg 은 Definition of an organization as JSON 임.)
    • cd .. && cp -r crypto-config/ordererOrganizations org3-artifacts/crypto-config/
    • (orderer_node와 TLS통신 같은것도 원활히 진행 할 수 있도록, 해당 'orderer MSP' 일단 가져옴.)
  • 2) Prepare the CLI Environment
    • 이런 '구성 업데이트 작업'에는 'configtxlator 바이너리' 라는 툴을 사용합니다. (stateless REST API 제공)
      
      • (블록체인 네트워크 구성 수정기능.)
      • (서로다른 데이터 포맷간 전환기능. 예 : protobuf형식<->JSON형식)
      • (두 channel간 차이점으로, '구성 업데이트' 트랜잭션 생성기능)
    • docker exec -it cli bash (우선 CLI 도커로 들어가서, 작업준비 및 부트스트랩)
    • export ORDERER_CA=/opt/.../ordererOrganizations/.../orderers/.../msp/tlscacerts/tlsca.example.com-cert.pem (orderer_node의 'local MSP'의 TSL통신 인증서)
    • export CHANNEL_NAME=mychannel
  • 3) Fetch the Configuration
    • 우선 CLI 도커으로 들어가서, 작업환경이 되었으니... 업데이트 할 channel의 '가장최신 config block' 을 가져 오는것으로 시작을 해봅시다.
    • '가장최신 config block'을 가져오는 이유는, 'channel 구성(config)'는 버져닝(versioning) 되기 때문입니다.
    • 버져닝(versioning)은 유용한데, 'channel 구성(config)' 변경의 재반복을 방지하고~ 명시적 명확해 집니다.
    • 'channel config block' 을 아래와 같은 커맨드로 가져올수있습니다.
      • peer channel fetch config channel.pb -o {orderer주소} -c {channel이름} --tls --cafile {인증서}
      • ('config_block.pb' 처럼 파일명과 확장자는 마음데로 정하면 됩니다...)
      • (.pb는 protobuf .json은 JSON)
      • (fetch 옵션에는 oldest, newest, config, {number} 가 있음)
      • (음... config하면, Received:0 과 Receive:n 둘다 찍히던데?!?!?!)
      • 커맨드시, "Received block:?" 라는 로그를 볼수있는데~ 이것이 바로 해당 `블록번호` 입니다.
    • 앞서의 BYFN의 상황에선, 아래와 같은 상황의 block으로 됩니다.
      • block 0: genesis block (아마도 genesis.block을 channel.tx로 channel create한, channel.block 일듯...)
      • block 1: Org1 anchor peer update
      • block 2: Org2 anchor peer update
  • 4) Convert the Configuration to JSON and Trim It Down
    • 이제 'configtxlator 바이너리' 으로 'channel config block' 을 좀더 다루기 편하도록, JSON화 해봅시다.
    • (무의미한 headers, metadata, creator-signatures 등등은 제거 됩니다.)
      • configtxlator proto_decode --input channel.pb --type common.Block | jq .data.data[0].payload.data.config > channel.json
      • ('jq' 라는 툴을 | (파이프) 으로 연동해서 사용함)
    • 결과적으로, '구성 업데이트 작업'에 사용할 '(JSON형식)channel config block' 를 획득하였습니다.
    • (꼭 시간을 내어서, 해당 파일을 직접 열어보시고! 내부구조가 어떤지? 공부해 보세요!!! 도움많이됩니다.)
  • 5) Add the Org3 Crypto Material
    • 지금까지는, channel의 여러 '구성 업데이트' 에서 공통적으로 하는 작업입니다.
    • 그럼, 추가할 '새로운 Org3 구성(config)'를 만들어 봅시다.
      • jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' channel.json ./channel-artifacts/org3.json > new_channel.json
      • ('jq' 툴으로 org3를 포함시킨, '새로운 channel 구성' 생성)
    • 결과적으로, channel.json 과 new_channel.json 을 확득하였습니다.
    • 이 다음으론, 아래와 같이 이 두 .json을 재인코딩 하고~ 델타를 계산해야 합니다.
      • c~lator proto_encode --input channel.json --type common.Config --output channel.pb
      • c~lator proto_encode --input new_channel.json --type common.Config --output new_channel.pb
      • c~lator compute_update --channel_id {channel이름} --original channel.pb --updated new_channel.pb --output update_org3.pb
    • 결과적으로, 'Org3 구성'을 추가하는 'channel config block' 을 획득하였습니다.
    • (기존블록에는 Org1,Org2 관련정보는 이미 있음. 그래서...)
    • (기존블록에서 Org3만 추가된 델타를 블록화 시키는것!!!)
    • 그럼 이제... 마무리 작업을 하면 됩니다. 우선, 편집을 할수있도록 준비합니다.
      • configtxlator proto_decode --input update_org3.pb --type common.ConfigUpdate | jq . > update_org3.json
    • 아까전에 제거 했던, (headers, metadata, creator-signatures 등등)을 다시 붙입니다.
      • echo '{"payload":{"header":{"channel_header":{"channel_id":"channel이름", "type":2}},"data":{"config_update":'$(cat update_org3.json)'}}}' | jq . > envelope_update_org3.json
    • 마지막 편집까지 끝이나고, 최종 'channel config block' 을 완성합니다.
      • configtxlator proto_encode --input envelope_update_org3.json --type common.Envelope --output envelope_update_org3.pb
  • 6) Sign and Submit the Config Update
    • 어어어

7) Configuring Leader Election

그럼 이미 'channel 구성'이 정해진 상황에서, 새로운 organization 추가 때, "리더선출"은 관련해서? 한번 알아봅시다.

genesis.block(channel.block) 으로 부트스트랩한 신규 peer_node는, 새로운 organization 정보를 당연히 모릅니다.

그래서 해당 peer_node는 (organization관련)'config-transaction'을 받을때 까지는, 그들의 organization간 블록 검증하지 않음으로~ '가십-프로토콜'을 사용 못하게 되는 현상이 나올것 입니다.

따라서 신규 peer_node는 orderer으로부터 블록을 받을수 있도록, 아래와 같은 '구성설정'을 꼭 해야 합니다.

1. "정적 리더 모드" 옵션 : "organization leader"으로 구성설정 

CORE_PEER_GOSSIP_USELEADERELECTION=false CORE_PEER_GOSSIP_ORGLEADER=true

(모든 peer_node에서 동일하게 해줘야 함)

2. "동적 리더 선출" 옵션 : "leader election"으로 구성설정

CORE_PEER_GOSSIP_USELEADERELECTION=true CORE_PEER_GOSSIP_ORGLEADER=false

(새로 추가된 organization의 peer_node는 membership을 볼 수 없음으로, 해당 peer_node는 정적으로... 자신을 리더선언 합니다. )

(하지만 (organization관련)'config-transaction'을 받으면, 해당 organization은 하나의 leader으로 활성화 될것입니다.)

(따라서 해당 organization의 peer_node가 최종적으로는 "리더선출"을 하기 원할 때, 사용합니다. )

이 설명은... 그럼 결국에는 leader 노드만~ orderer으로부터 정보를 받고, 나머지 애들은 가십으로만 동기화 한다는 말인가??????

-끝-