[하이퍼레저 공식문서]Tutorials - Adding an Org to a Channel

Adding an Org to a Channel(채널에 조직 추가하기)

[Note]
이 설명서의 버전과 일치하는 하이퍼레저 패브릭 샘플 및 사전 요구 사항 (왼쪽의 목차 맨 아래에 있음)에 설명 된대로 적절한 이미지와 바이너리를 다운로드했는지 확인하십시오. 특히, fabric-samples 폴더의 버전에는 eyfn.sh ( "첫 번째 네트워크 확장") 스크립트와 관련 스크립트가 포함되어야합니다.

이 튜토리얼은 BYFN (Building Your First Network) 튜토리얼의 확장 기능으로 BYFN에서 자동 생성 한 애플리케이션 채널 (mychannel) 에 새로운 조직 – Org3 –을 추가하는 방법을 보여줍니다. 앞서 언급 한 유틸리티의 사용법 및 기능을 포함하여 BYFN에 대한 강력한 이해를 전제로 합니다.

여기서 새로운 조직의 통합에만 초점을 맞추지만 다른 채널 구성 업데이트 (예 : 수정 정책 업데이트 또는 배치 크기 변경)를 수행 할 때 동일한 접근 방식을 채택 할 수 있습니다. 일반적으로 채널 구성 업데이트의 프로세스와 가능성에 대한 자세한 내용은 채널 구성 업데이트를 참조하십시오. 여기에 설명 된 것과 같은 채널 구성 업데이트는 일반적으로 체인 코드 또는 응용 프로그램 개발자가 아닌 조직 관리자의 책임입니다.

[Note]
계속하기 전에 자동화 된 byfn.sh 스크립트가 시스템에서 오류없이 실행되는지 확인하십시오. 바이너리 및 관련 도구 (cryptogen, configtxgen 등)를 PATH 변수로 내 보낸 경우 정규화 된 경로를 통과하지 않고 그에 따라 명령을 수정할 수 있습니다.

Setup the Environment(환경 설정)

로컬fabric-samples의  first-network 하위 디렉토리의 루트에서 작동 할 것입니다. 지금 해당 디렉토리로 변경하십시오. 또한 사용하기 쉽도록 몇 개의 여분의 터미널을 열고 싶을 것입니다.

먼저,  byfn.sh 스크립트를 사용하여 정리하십시오. 이 명령은 활성 또는 비활성 docker 컨테이너를 제거하고 이전에 생성 된 아티팩트를 제거합니다. 채널 구성 업데이트 작업을 수행하기 위해 패브릭 네트워크를 중단 할 필요는 없습니다. 그러나이 자습서에서는 알려진 초기 State에서 작동하려고합니다. 따라서 다음 명령을 실행하여 이전 환경을 정리하십시오.

./byfn.sh -m down

이제 기본 BYFN 아티팩트를 생성하십시오.

./byfn.sh -m generate

CLI 컨테이너 내에서 스크립트 실행을 사용하여 네트워크를 시작하십시오.

./byfn.sh -m up

BYFN의 깨끗한 버전이 컴퓨터에서 실행되었으므로 두 가지 다른 경로를 사용할 수 있습니다. 첫째, Org3을 네트워크로 가져 오기 위해 config 트랜잭션 업데이트를 수행하는 주석 처리 된 스크립트를 제공합니다.

또한 동일한 프로세스의 "수동"버전을 보여 주며 각 단계를 보여주고 그 결과를 설명합니다 (이 수동 프로세스 전에 네트워크를 중단시키는 방법을 보여주기 때문에 스크립트를 실행 한 다음 각 프로세스를 볼 수도 있습니다 단계).

Bring Org3 into the Channel with the Script(스크립트로 Org3을 채널에 가져오기)

당신은  first-network에 있어야합니다. 스크립트를 사용하려면 다음을 실행하십시오.

./eyfn.sh up

여기에 나오는 결과는 읽을 가치가 있습니다. Org3 암호 자료가 추가되고, 구성 갱신이 작성되고 서명 된 다음 체인 코드가 설치되어 Org3가 원장 조회를 실행할 수 있습니다.

모든 것이 잘 진행되면 다음 메시지가 표시됩니다.

========= All GOOD, EYFN test execution completed ===========

eyfn.sh 는  ./byfn.sh -m -up 대신 다음을 실행하여 동일한 Node.js 체인 코드 및  byfn.sh와 같은 데이터베이스 옵션과 함께 사용할 수 있습니다.

./byfn.sh up -c testchannel -s couchdb -l node

그리고:

./eyfn.sh up -c testchannel -s couchdb -l node

이 프로세스를 면밀히 살펴보고자하는 사람들에게 나머지 문서는 채널 업데이트를위한 각 명령과 그 기능을 보여줍니다.

Bring Org3 into the Channel Manually(Org3을 채널에 수동으로 가져오기)

[Note]
아래에 설명 된 수동 단계에서는 cli 및 Org3cli 컨테이너의 CORE_LOGGING_LEVEL이 DEBUG로 설정되어 있다고 가정합니다.
cli 컨테이너의 경우 first-network 디렉토리의 docker-compose-cli.yaml 파일을 수정하여이를 설정할 수 있습니다. 예 :

cli:
  container_name: cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    #- CORE_LOGGING_LEVEL=INFO
    - CORE_LOGGING_LEVEL=DEBUG

Org3cli 컨테이너의 경우 first-network 디렉토리의 docker-compose-org3.yaml 파일을 수정하여 이를 설정할 수 있습니다. 예 :

Org3cli:
  container_name: Org3cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    #- CORE_LOGGING_LEVEL=INFO
    - CORE_LOGGING_LEVEL=DEBUG

eyfn.sh스크립트를 사용 했다면 네트워크를 중단시켜야합니다. 이것은 다음을 발행하여 수행 할 수 있습니다.

./eyfn.sh down

이렇게하면 네트워크가 중단되고 모든 컨테이너가 삭제되며 Org3을 추가하기 위해 수행 한 작업이 취소됩니다.

네트워크가 다운되었을 때 다시 켭니다.

./byfn.sh -m generate

그리고나서,

./byfn.sh -m up

이렇게하면 네트워크를 eyfn.sh스크립트 를 실행하기 전과 동일한 State로 되돌릴 수 있습니다.

이제 Org3을 수동으로 추가 할 준비가되었습니다. 첫 번째 단계에서는 Org3의 암호 자료를 생성해야합니다.

Generate the Org3 Crypto Material(Org3 Crypto Material 생성)

다른 터미널에서,  first-network의  org3-artifacts 서브 디렉토리로 변경하십시오.

cd org3-artifacts

여기서 관심있는 두 개의 yaml 파일이 있습니다 : org3-crypto.yaml및  configtx.yaml 먼저 Org3 용 암호 자료를 생성하십시오.

../../bin/cryptogen generate --config=./org3-crypto.yaml

이 명령은 새로운 암호화  yaml 파일 (– org3-crypto.yaml –)을 읽고  cryptogen을 활용하여 Org3 CA 및이 Org에 바인딩 된 두 명의 피어에 대한 키와 인증서를 생성합니다. BYFN 구현과 마찬가지로이 암호 자료는 현재 작업 디렉토리 (이 경우에는  org3-artifacts) 내에 새로 생성 된 crypto-config  폴더에 저장됩니다.

이제 configtxgen 유틸리티를 사용하여 JSON에서 Org3 특정 구성 자료를 인쇄하십시오. 도구에서 현재 디렉토리에서 가져올 configtx.yaml  파일을 찾도록 명령하여 명령을 시작합니다.

export FABRIC_CFG_PATH=$PWD && ../../bin/configtxgen -printOrg Org3MSP > ../channel-artifacts/org3.json

위의 명령은 JSON 파일 (– org3.json –)을 만들고 이를  first-network의 루트에있는  channel-artifacts 하위 디렉토리로 출력합니다. 이 파일에는 Org3에 대한 정책 정의와 기본 64 형식으로 제공되는 세 가지 중요한 인증서 인 관리 사용자 인증서 (나중에 Org3의 관리자로 작동해야 함), CA 루트 인증서 및 TLS 루트가 포함되어 있습니다 증명. 다음 단계에서는이 JSON 파일을 채널 구성에 추가합니다.

하우스 키핑의 마지막 부분은 Orderer Org의 MSP 자료를 Org3 crypto-config 디렉토리로 이식하는 것입니다. 특히, 우리는 Ord3 엔티티와 네트워크의 Ordering Node 사이의 보안 통신을 허용하는 Orderer의 TLS 루트 인증서와 관련이 있습니다.

cd ../ && cp -r crypto-config/ordererOrganizations org3-artifacts/crypto-config/

이제 채널 구성을 업데이트 할 준비가되었습니다 ...

Prepare the CLI Environment(CLI 환경 준비)

업데이트 프로세스는 구성 변환기 도구 - configtxlator를 사용합니다. 이 도구는 SDK와 독립적 인 State 비 저장 REST API를 제공합니다. 또한 Fabric 네트워크의 구성 작업을 단순화하기 위해 CLI를 제공합니다. 이 도구를 사용하면 서로 다른 데이터 표현 / 형식 (이 경우 protobufs와 JSON)을 손쉽게 변환 할 수 있습니다. 또한이 도구는 두 채널 구성 간의 차이점을 기반으로 구성 업데이트 트랜잭션을 계산할 수 있습니다.

먼저 CLI 컨테이너에 exec하십시오. 이 컨테이너는 BYFN crypto-config  라이브러리로 마운트되어 두 개의 원래 피어 조직과 Orderer Org의 MSP 자료에 액세스 할 수 있습니다. 부트 스트랩 된 ID는 Org1 관리자 사용자입니다. 즉, Org2 역할을 수행하려는 모든 단계에서 MSP 관련 환경 변수를 내 보내야합니다.

docker exec -it cli bash

이제  jq도구를 컨테이너에 설치하십시오. 이 도구는  configtxlator도구가 반환 한 JSON 파일과 스크립트 상호 작용을 허용합니다.

apt update && apt install -y jq

변수 ORDERER_CA및 CHANNEL_NAME변수 내보내기 :

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem  && export CHANNEL_NAME=mychannel

변수가 올바르게 설정되었는지 확인하십시오.

echo $ORDERER_CA && echo $CHANNEL_NAME

Fetch the Configuration(구성 가져오기)

이제 CLI 컨테이너에는  ORDERER_CA와 CHANNEL_NAME 이라는 두 가지 주요 환경 변수가 있습니다. 채널 ( mychannel)에 대한 가장 최근의 config 블록을 가져 오십시오.

config의 최신 버전을 가져와야하는 이유는 채널 구성 요소의 버전이 지정 되었기 때문입니다. 버전 관리는 여러 가지 이유로 중요합니다. 구성 변경이 반복되거나 재생되는 것을 방지합니다 (예 : 이전 CRL이있는 채널 구성으로 되돌릴 경우 보안 위험이 있음). 또한 동시성을 확보하는 데 도움이됩니다 (예를 들어, 새로운 Org가 추가 된 후 채널에서 Org를 제거하려는 경우, 버전 관리는 제거하려는 Org가 아닌 두 Org를 모두 제거하지 못하게합니다).

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

이 명령은 바이너리 protobuf 채널 구성 블록을  config_block.pb에 저장합니다. 이름과 파일 확장명의 선택은 임의적입니다. 그러나 표현되는 객체의 유형과 인코딩 (protobuf 또는 JSON)을 모두 식별하는 규칙을 따르는 것이 좋습니다.

peer channel fetch 명령을 실행하면 터미널에 상당한 양의 출력이 발생합니다. 로그의 마지막 행이 중요합니다.

2017-11-07 17:17:57.383 UTC [channelCmd] readBlock -> DEBU 011 Received block: 2

이것은  mychannel에 대한 가장 최근의 구성 블록이 실제로는 genesis 블록이 아니라 블록 2라는 것을 알려줍니다. 기본적으로  peer channel fetch config 명령은 대상 채널 (이 경우 세 번째 블록)에 대한 가장 최근의 구성 블록을 반환합니다. 이것은 BYFN 스크립트가  Org1및  Org2의 두 조직에 대한 앵커 피어를 두 개의 개별 채널 업데이트 트랜잭션에 정의했기 때문입니다.

결과적으로 다음과 같은 구성 순서가 있습니다.

• 블록 0 : genesis block
• 블록 1 : Org1 앵커 피어 업데이트
• 블록 2 : Org2 앵커 피어 업데이트

Convert the Configuration to JSON and Trim It Down

이제  configtxlator도구를 사용하여이 채널 구성 블록을 JSON 형식 (사람이 읽고 수정할 수 있음)으로 디코딩 할 것입니다. 우리가 만들고자하는 변경과 관련이없는 모든 헤더, 메타 데이터, 작성자 서명 등을 제거해야합니다. 우리는 jq 도구를 사용하여이를 수행합니다.

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

이로 인해 first-network  내부의  fabric-samples폴더에 있는 JSON 객체 ( config.json)가 축소되어 구성 설정 업데이트의 기준이 됩니다.

잠시 시간을 내어 선택한 텍스트 편집기 (또는 브라우저)에서이 파일을 여십시오. 이 튜토리얼을 끝내고 나면 기본 구성 구조와 다른 종류의 채널 업데이트를 확인할 수 있으므로이 튜토리얼을 공부하는 것이 좋습니다. 채널 구성 업데이트에서 자세히 설명합니다.

Add the Org3 Crypto Material(Org3 Crypto Material 추가)

[Note]
이 시점까지 수행 한 단계는 구성 업데이트의 종류에 관계없이 거의 동일합니다. 시도 할 수있는 가장 복잡한 채널 구성 업데이트 중 하나이기 때문에이 자습서에 조직을 추가하기로 결정했습니다.

jq 도구를 다시 사용하여 Org3 구성 정의 ( org3.json)를 채널의 응용 프로그램 그룹 필드에 추가하고 출력 이름을 지정합니다.  modified_config.json

jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json

이제 CLI 컨테이너 내에 두 개의 JSON 파일 ( config.json 와 modified_config.json)이 있습니다. 초기 파일에는 Org1 및 Org2 자료 만 들어 있고, 수정 된 파일에는 세 개의 Org가 모두 들어 있습니다. 이 시점에서이 두 JSON 파일을 다시 인코딩하고 델타를 계산하기 만하면됩니다.

먼저 , config.json을  config.pb라는 protobuf로 다시 변환하십시오.

configtxlator proto_encode --input config.json --type common.Config --output config.pb

그런 다음  modified_config.json을 modified_config.pb로 인코딩합니다.

configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb

이 새로운 proto – org3_update.pb – Org1 및 Org2 자료에 대한 Org3 정의 및 상위 레벨 포인터를 포함합니다. Org1 및 Org2에 대한 광범위한 MSP 자료 및 수정 정책 정보는 해당 채널의 기원 블록에 이미 있기 때문에 무시할 수 있습니다. 따라서 두 구성 사이에 델타 만 있으면됩니다.

채널 업데이트를 제출하기 전에 몇 가지 마지막 단계를 수행해야합니다. 먼저이 객체를 편집 가능한 JSON 형식으로 디코딩하고  org3_update.json이라고 부릅니다.

configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json

이제 우리는 엔코딩 된 업데이트 파일 ( – org3_update.json –)을 봉투 메시지(an envelope message)로 포장해야합니다. 이 단계는 이전에 제거한 헤더 필드를 되돌려줍니다. 이 파일의 이름은  org3_update_in_envelope.json입니다.

echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat org3_update.json)'}}}' | jq . > org3_update_in_envelope.json

제대로 구성된 JSON org3_update_in_envelope.json 을 사용하여 마지막으로 configtxlator  도구를 활용하고 Fabric이 필요로하는 본격적인 protobuf 형식으로 변환합니다. 마지막 업데이트 개체 이름을  org3_update_in_envelope.pb로 지정합니다.

configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb

Sign and Submit the Config Update(구성 업데이트 서명 및 제출)

이제 CLI 컨테이너 내에 protobuf 바이너리 (– org3_update_in_envelope.pb –)가 있습니다. 그러나 구성을 원장에 기록하려면 필요한 관리 사용자의 서명이 필요합니다. 채널 응용 프로그램 그룹의 수정 정책 (mod_policy)은 기본값 인 "MAJORITY"로 설정됩니다. 즉, 기존 org 관리자의 대다수가 서명해야합니다. Org1과 Org2라는 두 개의 조직 만 있고 두 개의 대다수가 두 개이므로 두 가지 모두 서명해야합니다. 두 서명이 없으면 Ordering Service는 정책을 이행하지 못하여 트랜잭션을 거부합니다.

먼저이 업데이트를 Org1 Admin으로 서명하십시오. CLI 컨테이너는 Org1 MSP 자료로 부트 스트랩되므로 peer channel signconfigtx 명령을 실행하기 만하면됩니다.

peer channel signconfigtx -f org3_update_in_envelope.pb

마지막 단계는 Org2 Admin 사용자를 반영하도록 CLI 컨테이너의 ID를 전환하는 것입니다. Org2 MSP와 관련된 네 가지 환경 변수를 내보내서이 작업을 수행합니다.

[Note]
조직간에 설정 트랜잭션을 서명하거나 다른 작업을 수행하는 것은 실제 패브릭 작업을 반영하지 않습니다. 단일 컨테이너는 전체 네트워크의 암호 자료로 마운트되지 않습니다. 오히려 구성 업데이트는 Org2 Admin에 검사 및 승인을 위해 대역 외로 안전하게 전달되어야합니다.

Org2 환경 변수를 내 보냅니다.

# you can issue all of these commands at once

export CORE_PEER_LOCALMSPID="Org2MSP"

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp

export CORE_PEER_ADDRESS=peer0.org2.example.com:7051

마지막으로 peer channel update  명령을 실행합니다. Org2 Admin 서명이이 호출에 첨부되어 수동으로 protobuf에 다시 서명 할 필요가 없습니다.

[Note]
ordering service 에 대한 다가오는 업데이트 호출은 일련의 체계적인 서명 및 정책 검사를 거치게됩니다. 따라서 Order 노드의 로그를 스트리밍하고 검사하는 것이 유용 할 수 있습니다. 다른 쉘에서 docker logs -f orderer.example.com 명령을 실행하여 표시하십시오.

업데이트 호출 보내기 (Send the update call):

peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

업데이트가 성공적으로 제출 된 경우 다음과 비슷한 메시지 요약 표시가 나타납니다.

2018-02-24 18:56:33.499 UTC [msp/identity] Sign -> DEBU 00f Sign: digest: 3207B24E40DE2FAB87A2E42BC004FEAA1E6FDCA42977CB78C64F05A88E556ABA

구성 트랜잭션의 제출도 보실 수 있습니다 :

2018-02-24 18:56:33.499 UTC [channelCmd] update -> INFO 010 Successfully submitted channel update

성공적인 채널 업데이트 호출은 채널의 모든 피어 (peer)에게 새로운 블록 (블록 5)을 반환합니다. 기억한다면 블록 0-2는 초기 채널 구성이고 블록 3과 4는 mycc 체인 코드의 인스턴스 생성과 호출입니다. 이와 같이, 블록 5는 현재 채널 상에 정의 된 Org3을 갖는 가장 최근의 채널 구성으로서 기능한다.

peer0.org1.example.com에 대한 로그를 검사하십시오.

docker logs -f peer0.org1.example.com

새 구성 블록을 가져오고 내용을 검사하려면 데모 프로세스를 수행하십시오.

Configuring Leader Election(리더 선출 구성)

[Note]
이 섹션은 초기 채널 구성이 완료된 후 조직을 네트워크에 추가 할 때 리더 선택 설정을 이해하기 위한 일반적인 참조로 포함됩니다. 이 샘플의 기본값은 peer-base.yaml 의 네트워크에있는 모든 피어에 대해 설정된 동적 리더 선거 입니다.

새로 가입 한 피어는 채널 구성 업데이트에 추가되는 조직에 대한 정보가 포함되지 않은 창 블록으로 부트 스트랩됩니다. 따라서 새로운 동료는 소셜을 조직에 추가 한 구성 트랜잭션을 얻을 때까지 소속 조직의 다른 동료가 전달한 블록을 확인할 수 없기 때문에 가십을 활용할 수 없습니다. 따라서 새로 추가 된 피어는 Ordering Service에서 블록을 수신 할 수 있도록 다음 구성 중 하나를 가져야합니다.

1. 정적 리더 모드를 사용하려면 피어를 조직 리더로 구성합니다.

CORE_PEER_GOSSIP_USELEADERELECTION=false
CORE_PEER_GOSSIP_ORGLEADER=true

2. 역동적 인 리더 선거를 사용하려면 리더 선거를 사용하도록 피어를 구성합니다.

CORE_PEER_GOSSIP_USELEADERELECTION = true 
CORE_PEER_GOSSIP_ORGLEADER = false

Join Org3 to the Channel(채널에 Org3 가입)

이 시점에서 채널 구성이 새로운 조직 인 – Org3 –을 포함하도록 업데이트되었습니다. 조직에 연결된 피어가 이제  mychannel에 참여할 수 있습니다.

먼저, Org3 피어 및 Org3 관련 CLI 컨테이너를 시작하십시오.

새 터미널을 열고 Org3 도커 컴포즈  first-network에서 시작 :

docker-compose -f docker-compose-org3.yaml up -d

이 새로운 작성 파일은 초기 네트워크에서 연결되도록 구성되었으므로 두 피어 및 CLI 컨테이너는 기존 피어 및 Order 노드로 해결할 수 있습니다. 이제 세 개의 새 컨테이너가 실행되면서 Org3 관련 CLI 컨테이너로 exec하십시오.

docker exec -it Org3cli bash

초기 CLI 컨테이너에서했던 것처럼 ORDERER_CA 와  CHANNEL_NAME의 두 가지 주요 환경 변수를 내 보냅니다.

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem && export CHANNEL_NAME=mychannel

변수가 올바르게 설정되었는지 확인하십시오.

echo $ORDERER_CA && echo $CHANNEL_NAME

이제  mychannel의 제네시스 블록을 요청하는 ordering service로 보냅니다. ordering service는 성공적인 채널 업데이트 결과로이 통화에 첨부 된 Org3 서명을 확인할 수 있습니다. Org3이 채널 구성에 성공적으로 추가되지 않은 경우 Ordering Service는이 요청을 거부해야합니다.

[Note]
다시 말하지만, ordering node의 로그를 스트리밍하여 서명 / 검증 논리 및 정책 점검을 표시하는 것이 유용 할 수 있습니다.

이 블록을 검색 하려면 다음 peer channel fetch 명령을 사용하십시오.

peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

채널의 원장 (즉, genesis block)의 첫 번째 블록을 원한다는 것을 나타 내기 위해 0을 전달합니다.  peer channel fetch config 명령을 단순히 전달하면 블록 5를 수신하게됩니다. Org3이 정의 된 업데이트 된 구성입니다. 그러나 우리는 다운 스트림 블록으로 원장을 시작할 수 없습니다 - 블록 0부터 시작해야합니다.

peer channel join 명령을 실행하고 genesis 블록– mychannel.block을 전달합니다.

peer channel join -b mychannel.block

Org3에 대해 두 번째 피어에 가입하려면  TLS 및  ADDRESS 변수를 내보내고  peer channel join command 명령을 다시 실행하십시오.

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org3.example.com/peers/peer1.org3.example.com/tls/ca.crt && export CORE_PEER_ADDRESS=peer1.org3.example.com:7051

peer channel join -b mychannel.block

Upgrade and Invoke Chaincode(체인코드 업그레이드)

퍼즐의 마지막 부분은 체인 코드 버전을 증가시키고 Org3을 포함하도록 Endorsement Policy를 업데이트하는 것입니다. 업그레이드가 다가오고 있음을 알고 있으므로 체인 코드의 버전 1을 설치할 필요가 없습니다. 우리는 Org3이 Endorsement Policy의 일부가 될 새 버전에만 관심이 있으므로 체인 코드의 버전 2로 바로 넘어갈 것입니다.

Org3 CLI에서 :

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

Org3의 두 번째 피어에 체인 코드를 설치하려면 환경 변수를 수정하고 명령을 다시 실행하십시오. 두 번째 설치는 endorsors 역할을하거나 다른 방식으로 원장과 인터페이스 할 동료 (예 : query )에만 체인 코드를 설치하기 만하면되므로 두 번째 설치는 필수 사항이 아닙니다. 피어는 여전히 유효성 검증 논리를 실행하고 체인 코드 컨테이너를 실행하지 않고 커미터로 작동합니다.

이제 원래 CLI 컨테이너로 돌아가서 Org1 및 Org2 피어에 새 버전을 설치하십시오. Org2 관리자 ID로 채널 업데이트 호출을 제출 했으므로 컨테이너는 여전히  peer0.org2를 대신하여 작동합니다.

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

peer0.org1 ID로 전환 :

export CORE_PEER_LOCALMSPID="Org1MSP"

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp

export CORE_PEER_ADDRESS=peer0.org1.example.com:7051

그리고 다시 설치하십시오 :

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

이제 체인 코드를 업그레이드 할 준비가되었습니다. 기본 소스 코드를 수정하지 않았으므로 단순히 mychannel 에 – mycc – 라는 체인 코드에 대한 Endorsement Policy에 Org3을 추가하는 것입니다.

[Note]
체인 코드의 인스턴스화 정책을 만족하는 모든 ID는 업그레이드 호출을 발행 할 수 있습니다. 기본적으로 이러한 ID는 채널 관리자입니다.

위의 명령에서  v플래그를 사용하여 새 버전을 지정하고 있음을 알 수 있습니다. 정책에 Org3을 추가하여 승인 정책이 -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')" 로 수정되었음을 알 수 있습니다. 마지막 관심 영역은 생성자 요청 ( c 플래그로 지정)입니다.

인스턴스화 호출과 마찬가지로 체인 코드를 업그레이드하려면  init 메소드를 사용해야합니다. chaincode가 인수를  init 메소드에 전달해야한다면 여기에서해야합니다.

업그레이드 호출은 채널의 원장에 새로운 블록 (블록 6)을 추가하고 Endorsement 단계에서 Org3 피어가 트랜잭션을 실행할 수있게합니다. Org3 CLI 컨테이너로 다시 돌아가서  a의 값에 대한 쿼리를 실행하십시오. 대상 피어에 대해 체인 코드 이미지를 작성해야하고 컨테이너를 시작해야하기 때문에 시간이 조금 걸릴 것입니다.

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

Query Result: 90의 응답을 확인해야합니다.

이제  10을  a에서  b로 이동하기위한 호출을 실행하십시오.

peer chaincode invoke -o orderer.example.com:7050  --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'

마지막으로 한 번 쿼리 :

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

이 chaincode’s world state 업데이트를 정확하게 반영하여  Query Result: 80의 응답을 확인해야합니다.

Conclusion(결론)

채널 구성 업데이트 프로세스는 실제로 상당히 복잡하지만 다양한 단계에 대한 논리적 인 방법이 있습니다. 최종 게임은 protobuf 바이너리 형식으로 표현 된 델타 트랜잭션 객체를 형성 한 다음 채널 구성 업데이트 트랜잭션이 채널의 수정 정책을 충족하도록 필요한 수의 관리자 서명을 획득하는 것입니다.

configtxlator 및  jq 도구는 계속 증가하는  peer channel  명령과 함께이 작업을 수행하는 기능을 제공합니다.

http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html