하이퍼레저 패브릭 - 3: 채널에 스마트 계약 배포하기 - 1

모든 건 공식문서를 따라간다!!!!!!!!

https://guiyum.tistory.com/114

하이퍼레저 패브릭 실습 - 2: test network

들어가기 전에!!

End users는 스마트 계약을 호출하여 블록체인 원장과 상호작용 한다. Hyperldeger Fabric에서 스마트 계약은 체인코드라고 하는 패키지에 배포된다. 트랜잭션을 검증하거나 원장을 query하려는 조직은 피어에 체인 코드를 설치해야 한다. 체널에 연결된 피어에 체인코드가 설치된 후 채널 구성원은 채널에 체인코드를 배포하고 체인코드의 스마트 계약을 사용하여 채널 원장에 asset을 생성하거나 업데이트할 수 있다!!

체인코드는 Fabric chaincode lifecycle이라는 프로세스를 사용하여 채널에 배포된다. Fabric chaincode lifecycle를 사용하면 여러 조직에서 체인 코드를 사용하여 트랜잭션을 생성하기 전에 어떻게 체인코드가 동작할지에 대한 운영 방식에 동의할 수 있다. 예를 들어 보증 정책은 트랜잭션을 검증하기 위해 체인코드를 실행해야 하는 조직을 지정하는데 채널 구성원은 패브릭 체인코드 수명주기를 사용하여 체인코드 보증 정책에 동의해야 한다.

더 자세한 Fabric chaincode lifecycle은 추후 정리해서 따로 올릴거다!!!

 

네트워크 시작

앞에서 포스팅한 1, 2를 다 했다는 가정하에 시작!!

cd fabric-samples/test-network

초기 상태에서 시작하기 위해 컨테이너를 종료하고 이전에 생성된 아티팩터를 제거하고 test network를 실행하자!!

./network.sh down
./network.sh up createChannel

createChannel 명령은 Org1, Org2 두 개의 구성원이 있는 mychannel이라는 채널을 만든다. 또 각 조직에 속한 피어들을 채널에 조인(연결)시킨다.

Channel 'mychannel' joined

로그에 대충 이런 메시지가 뜨면 성공!! 이제 우리는 Peer CLI를 사용하여 다음 단계에 따라 채널에 asset-transfer (basic) 체인코드를 배포할 수 있다!!

1. 스마트 컨트랙트 패키징
2. 체인코드 패키지 설치
3. 체인코드 정의 승인
4. 채널에 체인코드 정의 커밋

 

+) 로그 라우터 Logspout 설정 (선택)

스마트 계약의 로그를 모니터링하기 위해 관리자는 logspout 도구를 사용한다. logspout은 여러 오커 컨테이너의 출력을 한 곳으로 수집하여 무슨 일이 일어나고 있는지 쉽게 볼 수 있도록 도와줘 문제를 디버그 하는데 도움이 된다! 일부 컨테이너는 스마트 계약을 시작할 목적으로 생성되고 짧은 시간 동안만 존재하기 때문에 네트워크에서 모든 로그를 수집하는 것이 좋다!

logspout을 설치/설정하기 위해 commercial-paper안에 있는 monitordocker.sh를 사용한다.

cp ../commercial-paper/organization/digibank/configuration/cli/monitordocker.sh .
# if you're not sure where it is
find . -name monitordocker.sh

이제 아래의 명령어를 사용하여 Logspout을 실행시킬 수 있다.

./monitordocker.sh fabric_test

처음에는 어떤 로그도 표시되지 않지만 우리가 체인코드를 배포하면 바뀐다!!

 

1. 스마트 컨트랙트 패키징

체인코드가 피어에 설치되기 전에 패키징해야 한다. Go, JavaScript, Typescript중 어떤 걸로 작성된 스마트 계약을 설치하느냐에 따라 다르다!!

 

• Go

체인코드를 패키징하기 전에 체인코드 디팬던시를 설치해야 한다.

fabric-samples/asset-transfer-basic/chaincode-go

이 디렉토리 안의 go.mod 파일에 디펜던시가 작성되어있다.

cd fabric-samples/asset-transfer-basic/chaincode-go
cat go.mod

 

module github.com/hyperledger/fabric-samples/asset-transfer-basic/chaincode-go

go 1.14

require (
        github.com/golang/protobuf v1.3.2
        github.com/hyperledger/fabric-chaincode-go v0.0.0-20200424173110-d7076418f212
        github.com/hyperledger/fabric-contract-api-go v1.1.0
        github.com/hyperledger/fabric-protos-go v0.0.0-20200424173316-dd554ba3746e
        github.com/stretchr/testify v1.5.1
)

cat go.mod의 결과로 이런 로그가 출력된다. go.mod 파일은 Fabric contract API를 스마트 계약 패키지로 가져온다.

vi chaincode/smartcontract.go

asset-transfer-basic/chaincode-go/chaincode/smartcontract.go를 열어 스마트 계약 시 SmartContract 타입을 정의하는 데 contract API가 어떻게 사용되는지 확인할 수 있다!! SmartContract 타입은 블록체인 원장에서 데이터를 읽고 쓰는 스마트 계약 내에 정의된 기능에 대한 트랜잭션 컨텍스트를 만드는데 사용된다.

 

이제 스마트 계약 디펜던시를 설치하자!! asset-transfer-basic/chaincode-go 디렉토리에서 아래 명령을 실행한다.

GO111MODULE=on go mod vendor

성공적으로 실행되면 vendor 폴더 안에 go packages가 설치된다!!

디펜던시를 다 설치했으므로 체인코드 패키지를 만들 수 있다. test-network로 다시 이동하여 다른 네트워크 아티팩트와 함께 체인코드를 패키징할 수 있다!!

peer CLI를 사용하여 요구된 형식으로 체인코드 패키지를 생성할 수 있다. 피어 바이너리는 fabric-samples 리포지토리의 bin 폴더에 있다!! 다음 명령을 사용하여 해당 바이너리를 CLI 경로에 추가한다!! 또한 core.yaml 파일 경로를 FABRIC_CFG_PATH로 선언한다!!

export PATH=${PWD}/../bin:$PATH
export FABRIC_CFG_PATH=$PWD/../config/

peer version

 바이너리 버전이 2.0.0 이상인지 확인한번 해주자!!

이제 peer lifecycle chaincode pacakge 명령을 사용하여 체인코드 패키지를 생성할 수 있다.

peer lifecycle chaincode package basic.tar.gz --path ../asset-transfer-basic/chaincode-go/ --lang golang --label basic_1.0

이 명령은 현재 디렉토리에 basic.tar.gz 라는 패키지를 설치한다. --lang은 체인코드 언어, --path는 스마트 컨트랙트 코드의 경로, --label은 설치된 후 체인코드를 식별할 체인코드 레이블을 지정하는 플래그이다. 레이블에 체인코드 이름과 버전을 포함하는 것이 좋다.

이제 test network의 피어에 체인코드를 설치할 수 있다!!

 

• JS

자스를 사용할 때도 Go와 유사하게 설치할 수 있다. 이건 빨리빨리 넘어가게따!!!

cd fabric-samples/asset-transfer-basic/chaincode-javascript
cat package.json
npm install

만약 npm이 안깔려있다면

https://docs.microsoft.com/ko-kr/windows/dev-environment/javascript/nodejs-on-wsl

WSL 2에 Node.js 설치

이거 보고 설치하면 됨!!

cd ../../test-network
export PATH=${PWD}/../bin:$PATH
export FABRIC_CFG_PATH=$PWD/../config/
peer lifecycle chaincode package basic.tar.gz --path ../asset-transfer-basic/chaincode-javascript/ --lang node --label basic_1.0

 

2. 체인코드 패키지 설치

asset-transfer (basic) smart contract를 패키징한 후에 피어에 체인코드를 설치할 수 있다!! 체인코드는 트랜잭션을 보증하는 모든 피어에 설치되어야 한다!! Org1과 Org2 모두에서 보증을 요구하도록 보증 정책을 설정할 것이기 때문에 두 조직에서 운영하는 피어에 체인코드를 설치해야 한다.

 

먼저 Org1 피어에 체인코드를 설치해보자!!

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051
peer lifecycle chaincode install basic.tar.gz

peer CLI을 Org1 admin 사용자로 작동하도록 다음 환경 변수를 설정한다. CORE_PEER_ADDRESS는 Org1 피어인 peer0.org1.example.com을 가르키도록 설정된다! 같은 방식으로 Org2 피어에도 체인코드를 설치하자!!

export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051
peer lifecycle chaincode install basic.tar.gz

 

3. 체인코드 정의 승인

체인코드 패키지를 설치한 후에 조직에 체인코드 정의를 승인해야 한다. 정의는 이름, 버전, 체인코드 보증 정책과 같은 체인코드 거버넌스의 중요한 매개변수가 포함된다!!!

체인코드를 배포하기전에 승인해야하는 채널 구성원 집합은 /Channel/Application/LifecycleEndorsement 방침을 적용받는다. 기본적으로 이 정책은 채널 멤버 대다수가 채널에서 체인코드를 사용하기 전에 승인할 것을 요구한다. 우리 채널에는 조직이 두 개 뿐이고 2의 과반수가 2이기 때문에 asset-transfer (basic)의 체인코드 정의를 Org1 및 Org2로 승인해야 한다!!

조직이 피어에 체인코드를 설치한 경우 조직에서 승인한 체인코드 정의에 packageID를 포함해야 한다. packageID는 피어에 설치된 체인코드를 승인된 체인코드 정의와 연결하는 데 사용되며 조직이 체인코드를 사용하여 트랜잭션을 승인할 수 있도록 한다. peer lifecycle chaincode queryinstalled 명령을 사용하여 피어를 쿼리하여 체인코드의 package ID를 찾을 수 있다!!!

peer lifecycle chaincode queryinstalled

Package ID는 체인코드 레이블과 체인코드 바이너리의 해시의 조합이다. 모든 피어는 동일한 package ID를 생성한다. 아래와 유사한 출력이 표시되어야 한다!!

Installed chaincodes on peer:
Package ID: basic_1.0:dee2d612e15f5059478b9048fa4b3c9f792096554841d642b9b59099fa0e04a4, Label: basic_1.0

우리는 체인코드를 승인할 때 package ID를 사용할 것이므로 환경변수로 저한다!! peer lifecycle caincode queryinstsalled로부터 리턴받은 package ID를 붙여넣는다!!

 export CC_PACKAGE_ID=basic_1.0:dee2d612e15f5059478b9048fa4b3c9f792096554841d642b9b59099fa0e04a4

Peer CLI를 Org2 admin으로 작동하도록 환경변수를 설정하였기 때문에 asset-transfer의 체인코드 정의를 Org2로 승인할 수 있다. chaincode는 조직 수준에서 승인되므로 명령은 하나의 피어만 대상으로 하면 된다!! 승인은 gossip을 사용하여 조직 내의 다른 피어에게 배포된다. peer lifecycle acceptformyorg 명령을 사용하여 체인코드 정의를 승인한다.

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"

--package-id 플래그는 체인코드 정의에서 패키지 식별자를 포함한다. --sequence 매개변수는 체인코드가 정의되거나 업데이트된 횟수를  추적하는 정수이다. 체인코드가 채널에 처음 배포되기 때문에 시퀀스 넘버는 1이다. asset-transfer chaincode가 업그레이드되면 시퀀스 넘버가 2로 증가한다. 제공되는 하위 수준의 API를 사용하는 경우 Fabric chaincode shim API를 사용하면 위의 명령에 --init-required 플래그를 통해 체인코드를 초기화하기 위한 Init함수 실행을 요청할 수 있다. 체인코드의 처음으로 호출된 경우 Init 함수를 대상으로 한다. --isinit 플래그를 통해 체인코드의 다른 함수를 이용하여 원장에서 상호작용할 수 있다.

--signature-policy 또는 --channel-config-policy 인수를 acceptformyorg 명령에 제공하여 체인코드 보증 정책을 지정할 수 있다. 보증 정책은 서로 다른 채널 멤버에 속한 피어가 주어진 체인코드에 대해 트랜잭션을 검증해야 하는 수를 지정한다. 여기서는 정책을 지정하지 않았으므로, asset-transfer은 기본 보증 정책을 사용한다. 기본 보증 정책은 과반수가 넘는 채널 멤버가 트랜잭션을 보증해야 한다. 채널에 새로운 조직이 추가되거나 삭제되면 보증 정책이 자동으로 업데이트되어 필요한 보증 수가 조정된다. 여기에서는 2개의 조직이 존재하므로 과반수는 2이다. 따라서 트랜잭션은 Org1과 Org2 피어 모두에서 보증되어야 한다.

체인코드 정의는 admin 권한을 가지고 있는 신원으로 승인해야 한다. 결과적으로 admin 신원이 저장된 MSP 폴더 경로를 가리키는 CORE_PEER_MSPCONFIGPATH 변수가 필요하다. 클라이언트 사용자로는 체인코드 정의를 승인할 수 없다. 승인을 오더링 서비스에 제출하면 admin의 서명을 확인한 다음 승인을 피어에 배포한다.

Org1 admin으로 교체하여 체인코드 정의를 승인하자!!

export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_ADDRESS=localhost:7051
peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"

이제 과반수가 asset-transfer 체인코드를 채널에 배포하는 것을 승인하였다. 과반수의 조직만 체인코드 정의를 승인하면 되지만 피어에서 체인코드를 시작하려면 해당 조직은 체인코드 정의를 승인해야 한다. 채널의 멤버가 체인 코드를 승인하기 전에 정의를 커밋하면 조직은 트랜잭션을 보증할 수 없다!! 결과적으로 모든 채널 멤버가 체인코드 정의를 커밋하기 전에 체인코드를 승인하는 것이 권장된다!!!

 

 

느므 길어서 다음 포스팅으로 자른다!!!!!! 다음에 계속!!!!! 채널에 체인코드 정의 커밋하는 건 다음 포스팅!!!

---

 

참고 자료

https://hyperledger-fabric.readthedocs.io/en/latest/deploy_chaincode.html

Deploying a smart contract to a channel — hyperledger-fabricdocs main documentation