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

모든 건 공식문서를 따라간다!!!! 공식문서와 같이 보는것을 추천!!!!

환경 설정은 https://guiyum.tistory.com/113

하이퍼레저 패브릭 실습 - 1: 초기 환경 설정

1. test network 불러오기

mkdir -p $HOME/go/src/github.com/<your_github_userid>
cd $HOME/go/src/github.com/<your_github_userid>

디렉토리를 이렇게 만들고

curl -sSL https://bit.ly/2ysbOFE | bash -s

최신버전의 Fabric sample, docker image, 이진 파일을 다운받는다!!

다운로드가 다 끝나면

cd fabric-samples/test-network

test network 디렉토리로 들어가자!!

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

./network.sh down명령어를 실행해서 이전에 실행된 container와 artifact를 지우고

./network.sh up 명령어를 실행하여 네트워크를 불러온다! 이 명령으로 두 개의 peer 노드, 하나의 ordering 노드로 구성된 fabric 네트워크를 만들 수 있다. 아직 채널은 생성되지 않았다!! 명령이 성공적으로 완료되면 생성 중인 노드의 로그가 표시된다!!

Creating network "fabric_test" with the default driver
Creating volume "net_orderer.example.com" with default driver
Creating volume "net_peer0.org1.example.com" with default driver
Creating volume "net_peer0.org2.example.com" with default driver
Creating peer0.org2.example.com ... done
Creating orderer.example.com    ... done
Creating peer0.org1.example.com ... done
Creating cli                    ... done
CONTAINER ID   IMAGE                               COMMAND             CREATED         STATUS                  PORTS                                            NAMES
1667543b5634   hyperledger/fabric-tools:latest     "/bin/bash"         1 second ago    Up Less than a second                                                    cli
b6b117c81c7f   hyperledger/fabric-peer:latest      "peer node start"   2 seconds ago   Up 1 second             0.0.0.0:7051->7051/tcp                           peer0.org1.example.com
703ead770e05   hyperledger/fabric-orderer:latest   "orderer"           2 seconds ago   Up Less than a second   0.0.0.0:7050->7050/tcp, 0.0.0.0:7053->7053/tcp   orderer.example.com
718d43f5f312   hyperledger/fabric-peer:latest      "peer node start"   2 seconds ago   Up 1 second             7051/tcp, 0.0.0.0:9051->9051/tcp                 peer0.org2.example.com

이런식으로 뜨면 성공한거!!

docker ps -a

이 명령을 실행하여 컴퓨터에서 실행 중인 모든 docker 컨테이너를 나열한다. network.sh 스크립트에 의해 생성된 세 개의 노드가 표시되어야 한다!!!

 

Fabric network와 상호작용하는 각 노드 및 사용자는 네트워크에 참여하기 위해서 organization에 속해야 한다.

test network는 Org1, Org2라는 두 개의 peer organizatioon이 포함되고 또 네트워크 ordering service를 유지 관리하는 단일 orderer organization도 포함된다.

 

peer는 모든 Fabric network의 기본 구성 요소이다. 피어는 블록체인 원장을 저장하고 원장에 커밋되기 전에 트랜잭션을 검증한다. 피어는 블록체인 원장의 자산을 관리하는 데 사용되는 비즈니스 로직이 포함된 스마트 계약을 실행한다.

 

모든 Fabric network에는 ordering service도 포함된다. 피어가 트랜잭션을 확인하고 블록체인 원장에 트랜잭션 블록을 추가하는 동안에는 트랜잭션 순서를 결정하거나 새 블록을 포함시키지 않는다. 분산 네트워크에서 피어는 서로 멀리 떨어져 실행될 수 있으며 트랜잭션이 생성된 시점에 대한 공통의 view를 갖지 않을 수 있다. 트랜잭션 순서에 대한 합의는 피어에게 오버해드를 생성하는 비용이 많이 드는 프로세스이다!

 

ordering service를 사용하면 피어가 트랜잭션을 확인하고 원장에 커밋하는 데 집중할 수 있다. ordering 노드는 클라이언트로부터 승인된 트랜잭션을 수신한 후 트랜잭션 순서에 대해 합의한 다음 블록에 추가한다. 그런 다음 블록은 블록을 블록체인 원장에 추가하는 피어 노드에 배포된다!

 

sample network는 orderer 조직에서 운영하는 단일 노드 Raft ordering service를 사용한다. orderer.example.com으로 컴퓨터에 실행중인 주문 노드를 볼 수 있다!! 테스트 네트워크는 단일 노드 ordering service만 사용하지만 production network는 하나 이상의 ordering organization에서 운영하는 multiple ordering node가 있다. 다른 ordering node는 Raft 합의 알고리즘을 사용하여 네트워크를 통한 트랜잭션 순서에 동의한다!!

Organization(조직)?

하이퍼레저 패브릭 네트워크에서 참여하는 조직을 나타내는 논리적 단위. 각 피어와 오더러는 organization에 소속된다.

 

Peer?

조직 내의 노드를 타나내는 논리적 단위로서 블록체인, 상태 DB, 체인 코드를 보유한다. 피어는 Endorser(보증인) 및 Commiter(커미터)의 역할을 가지지만 성능 측면을 고려해 커미터 역할만 가진 피어만 배치할 수도 있다.

피어는 Endorser 역할을 수행할 때는 응용 프로그램(클라이언트)의 요청에 따라 트랜잭션에 대해 endorsement(보증)한다.

커미터 역할을 할 때는 트랜잭션과 실행 결과의 타당성을 확인해 블록체인과 상태 DB를 갱신한다!

 

Orderer(오더러)?

보증(Endorsement)된 트랜잭션의 결과를 블록체인과 상태 DB에 기록하는 순서를 제어한다. 오더러는 하이퍼레저 패브릭 네트워크의 모든 트랜잭션을 제어하므로 단일 장애점이 되지 않도록 이중화 구성을 해야한다. 이를 위해 분산 메시징 기술인 Apache Kafka를 사용한다. 

 

Raft 합의 알고리즘?

// 나중에 정리하면 추가할 예정!

 

2. 채널 생성

이제 컴퓨터에서 peer와 orderer 노드가 실행되고 있으므로 스크립트를 사용하여 Org1과 Org2 간의 트랜잭션을 위한 Fabric 채널을 생성할 수 있다!! 채널은 특정 네트워크 구성원 간의 private layer of communication이다. 채널은 채널에 초대된 조직에서만 사용할 수 있으며 네트워크의 다른 구성원들에게는 표시되지 않는다. 각 채널에는 별도의 블록체인 원장(blockchain ledger)이 있다. 초대된 조직은 채널 원장을 저장하고  트랜잭션을 검증하기 위해 피어를 채널에 "join" 한다!!

 

network. sh 스크립트로 Org1과 Org2 사이의 채널을 만들고 걔네들의 peer들을 채널에 join 시킬 수 있다!

./network.sh createChannel

mychannel이라는 기본 이름의 채널이 생긴다!!!

Channel 'mychannel' joined

이런 메세지가 뜨면 성공!!!

channel flag를 사용하여 사용자 지정 이름으로 채널을 만들 수 있다!!

./network.sh createChannel -c channel1

이러면 channel1이라는 이름의 채널이 생긴다!! channel2라는 이름의 채널도 만들자~~

 

3. 채널에서 체인코드 시작

채널을 만든 후에는 스마트 계약을 사용하여 채널 원장과 상호 작용할 수 있다. 스마트 계약에는 블록체인 원장의 자산을 관리하는 비즈니스 로직이 포함되어 있다!! 네트워크 구성원이 실행하는 애플리케이션은 스마트 계약을 호출하여 원장에 자산을 생성하고 해당 자산을 변경 및 전송할 수 있다! 또한 응용 프로그램은 스마트 계약을 query해 원장의 데이터를 읽는다!!

 

트랜잭션이 유효한지 확인하기 위해 스마트 계약을 사용하여 생성된 트랜잭션은 일반적으로 채널 원장에 커밋하기 위해 여러 조직에서 서명해야 한다. 다중 서명은 Fabic의 신뢰 모델에 필수적이다!! 트랜잭션에 대해 여러 승인을 요구하면 채널의 한 조직이 피어의 원장을 변조하거나 동의하지  않은 비즈니스 로직을 사용하는 것을 방지하 수 있다!! 트랜잭션에 서명하기 위해 각 조직은 해당 피어에서 스마트 계약을 호출하고 실행해야 하며, 그런 다음 트랜잭션 출력에 서명한다!! 출력이 일관되고 충분한 조직에서 서명한 경우 트랜잭션을 원장에 커밋할 수 있다!! 스마트 계약을 실행해야 하는 채널의 집합 조직을 지정하는 정책을 보증 정책이라고 하며, 이는 체인코드 정의의 일부로 각 체인코드에 대해 설정된다!

 

Fabric에서 스마트 계약은 체인코드라고 하는 패키지로 네트워크에 배포된다. Chaincode는 조직의 피어에 설치된 다음 채널에 배포되어 트랜잭션을 승인하고 블록체인 원장과 상호작용하는 데 사용할 수 있다. 체인코드를 채널에 배포하기 전에 채널 구성원은 체인코드 거버넌스를 설정하는 체인코드 정의에 동이해야 한다. 필요한 숫자 만큼의 조직이 동의하면 체인코드 정의를 채널에 커밋할 수 있고 체인코드를 사용할 준비가 된다!!

 

network.sh를 사용해 채널을 만든 후 

./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go

이 명령어를 사용하여 채널에서 체인코드를 시작할 수 있다!!

deployCC의 하위 명령어는 peer0.org1.example.com 및 peer0.org2.example.com에 asset 전송 (basic) 체인코드를 설치한 다음 채널 플래그를 사용하여 지정된 채널(지정되지 않았다면 mychannel)에 체인코드를 배포한다. 언어 플래그 -l을 사용하여 체인코드의 Go, typescript 또는 javascript 버전을 설치할 수 있다. fabric-samples 디렉토리의 asset-transfer-basic 폴더에서 assect-transfer(basic) 체인코드를 찾을 수 있다!! 

 

저 명령어를 실행할 때

+ res=1
Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image build failed: docker build failed: Error returned from build: 1 "go: inconsistent vendoring in /chaincode/input/src:

이딴 에러가 뜰 수 있는데 그러면

https://go.dev/doc/install

Download and install - The Go Programming Language

설치했었던 golang-go 삭제하고 여기 튜토리얼 대로 설치,,해보면 될수도,,!!!! 나는 그랬다!!!!

 

3. 네트워크와 상호 작용

위에서 우리는 테스크 네트워크를 불러왔다! 이제 peer CLI를 사용하여 네트워크와 상호 작용할 수 있다.

피어 CLI를 사용하면 배포된 스마트 계약을 호출하거나, 채널을 업데이트하거나, CLI에서 새 스마트 계약을 설치 및 배포할 수 있다!!

 

공식문서대로 따라왔다면 fabric-samples 디렉토리에서 bin 폴더에 peer binary를 찾을 수 있다. 다음 명령을 사용하여 해당 바이너리를 CLI 경로에 추가하자!! 얘네는 다 test-network 디렉토리에서 진행해야함!!!!!

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

또한 fabric-samples의 core.yaml 파일을 가리키도록 FABRIC_CFG_PATH를 설정해야 한다!!

export FABRIC_CFG_PATH=$PWD/../config/

이제 peer CLI를 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

CORE_PEER_TLS_FILE 및 CORE_PEER_MSPCONFIGPATH 환경 변수는 조직 폴더의 Org1 암호화 자료를 가리킨다.

체인코드의 InitLedger 함수를 호출하여 원장에 초기 에셋 목록을 집어넣을 수 있다!!

{"function":"InitLedger","Args":[]}

다음 명령을 실행하여 asset으로 원장을 초기화한다!!

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" -c '{"function":"InitLedger","Args":[]}'

chaincodeInvokeOrQuery -> Chaincode invoke successful. result: status:200

이렇게 뜨면 성공한거!! 이제 CLI에 원장을 query할 수 있다. 다음 명령을 실행해서 채널 원장에 추가된 자산 목록을 가져오자!!

peer chaincode query -C mychannel -n basic -c '{"Args":["GetAllAssets"]}'

성공했다면 아래와 같은 결과가 나온다!!

[
    {"AppraisedValue":300,"Color":"blue","ID":"asset1","Owner":"Tomoko","Size":5},
    {"AppraisedValue":400,"Color":"red","ID":"asset2","Owner":"Brad","Size":5},
    {"AppraisedValue":500,"Color":"green","ID":"asset3","Owner":"Jin Soo","Size":10},
    {"AppraisedValue":600,"Color":"yellow","ID":"asset4","Owner":"Max","Size":10},
    {"AppraisedValue":700,"Color":"black","ID":"asset5","Owner":"Adriana","Size":15},
    {"AppraisedValue":800,"Color":"white","ID":"asset6","Owner":"Michel","Size":15}
]

체인코드는 네트워크 멤버가 원장의 asset을 전송하거나 변경하려고 할 때 호출된다.

{"function":"TransferAsset","Args":["asset6","Christopher"]}

asset-transfer 체인코드를 호출하여 asset6의 소유자를 Michel -> Christopher로 변경해보자!!

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" -c '{"function":"TransferAsset","Args":["asset6","Christopher"]}'

chaincodeInvokeOrQuery -> Chaincode invoke successful. result: status:200 payload:"Michel"

이렇게 뜨면 성공!! asset-transfer 체인코드에 대한 보증 정책은 트랜잭션이 Org1과 Org2 모두에서 서명되어야 하므로 --peerAddresses 플래그를 사용하여 peer0.org1.example.com과 peer0.org2.example.com 둘 다 대상으로 지정하였다!

네트워크에 대한 TLS가 활성화되어 있기 때문에 --tlsRootCertFiles 태그를 이용하여 각 피어에 대한 TLS 인증서를 참조해한다!

 

다시 getAllAssets 함수를 호출하면 asset6의 소유자가 Christopher로 변경된 것을 확인할 수 있다!!

[
    {"AppraisedValue":300,"Color":"blue","ID":"asset1","Owner":"Tomoko","Size":5},
    {"AppraisedValue":400,"Color":"red","ID":"asset2","Owner":"Brad","Size":5},
    {"AppraisedValue":500,"Color":"green","ID":"asset3","Owner":"Jin Soo","Size":10},
    {"AppraisedValue":600,"Color":"yellow","ID":"asset4","Owner":"Max","Size":10},
    {"AppraisedValue":700,"Color":"black","ID":"asset5","Owner":"Adriana","Size":15},
    {"AppraisedValue":800,"Color":"white","ID":"asset6","Owner":"Christopher","Size":15}
]

Org1이 잘 수정된 것을 확인했으니 같은 원장을 가지고 있는 Org2에서도 에셋 변경이 잘 적용되었는지를 확인해보자!!

환경 변수를 일부 수정!!!

export CORE_PEER_TLS_ENABLED=true
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

ReadAsset 함수를 호출하여 asset6의 소유자를 확인해보자!

peer chaincode query -C mychannel -n basic -c '{"Args":["ReadAsset","asset6"]}'

위 명령어를 입력했을 때

{"AppraisedValue":800,"Color":"white","ID":"asset6","Owner":"Christopher","Size":15}

이런 결과가 뜬가면 Org2에서도 asset6의 소유자가 Christopher로 변경된 것을 확인할 수 있다.

 

네트워크 중단

테스트 네트워크 사용이 끝났으면 네트워크를 중단하자!!

./network.sh down

이 명령어를 사용하면 노드 및 체인코드 컨테이너를 중지 및 제거하고, 조직 암호화 자료를 삭제하고, Docker Registry에서 체인코드 이미지를 제거한다!! 또 이전 실행에서 체널 artifacts 및 도커 볼륨을 제거하므로 문제가 발생한 경우 ./network.sh를 다시 실행할 수 있다!!!

 

5. 인증 기관과 네트워크 연결

Hyperldeger Fabirc은 PKI(공개 키 인프라)를 사용하여 모든 네트워크 참가자의 작업을 확인한다. 모든 노드, 네트워크 관리자 및 트랜잭션을 제출하는 사용자는 신원을 확인하기 위해 공개 인증서(public certificate)와 개인 키(private key)가 있어야 한다. 네트워크의 구성원인 조직에서 인증서를 발급했음을 확인하는 유효한 신뢰 루트가 있어야 한다. network.sh 스크립트는 peer 및 ordering 노드를 만들기 전에 네트워크를 배포하고 운영하는데 필요한 모든 암호화 자료를 만든다!!

 

기본적으로 스크립트는 cryptogen tool을 사용하여 인증서와 키를 만든다. 이 tool은 개발 및 테스트용으로 제공되며 유효한 신뢰 루트가 있는 Fabric organization에 필요한 암호화 자료를 빠르게 생성할 수 있다. ./network.sh up 을 실행하면 Org1, Org2 및 Orderer Org에 대한 인증서와 키를 생성하는 cryptogen tool을 볼 수 있다!!

Generating certificates using cryptogen tool
Creating Org1 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output=organizations
org1.example.com
+ res=0
Creating Org2 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output=organizations
org2.example.com
+ res=0
Creating Orderer Org Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output=organizations
+ res=0

스크립트는 인증 기관을 이용하여 네트워크를 가져오는 옵션도 제공한다. production network에서 각 조직은 조직에 속한 ID를 만드는 CA(또는 여러 intermediate CA)를 운영한다. 조직에서 운영하는 CA에서 생성된 모든 ID는 동일한 신뢰 루트를 공유한다. (여기서 말하는 ID는 신원을 뜻함!!)

cryptogen을 사용하는 것보다 시간이 더 걸리지만 CA를 이용하여 test network를 불러오는 것은 네트워크가 프로덕션에 배포되는 방법에 대한 소개를 제공한다. CA를 배포하면 Fabric SDk에 클라이언트 ID를 등록하고 애플리케이션에 대한 인증서와 개인 키를 생성할 수도 있다!!

 

Fabric CA를 사용하여 네트워크를 시작하려면 먼저 실행중인 네트워크를 종료해야 한다.

./network.sh down
./network.sh up -ca

명령을 실행한 후 네트워크의 각 조직에 대해 하나씩 3개의 CA를 표시하는 스크립트를 볼 수 있다!

테스트 네트워크는 Fabric CA 클라이언트를 사용하여 각 조직의 CA에 노드 및 사용자 ID를 등록한다. 그런 다음 스크립트는 등록 명령을 사용하여 각 ID에 대한 MSP 폴더를 생성한다. MSP폴더에는 각 ID에 대한 인증서와 개인 키가 포함되어 있으며 CA를 운영하는 조직에서 ID의 역할과 구성원 자격을 설정한다! 다음 명령을 사용하여 Org1 admin 사용자의 MSP 폴더를 검사할 수 있다.

tree organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/

tree가 안깔려있다면 sudo apt install tree 로 깔면 된다!

organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/
└── msp
    ├── IssuerPublicKey
    ├── IssuerRevocationPublicKey
    ├── cacerts
    │   └── localhost-7054-ca-org1.pem
    ├── config.yaml
    ├── keystore
    │   └── 58e81e6f1ee8930df46841bf88c22a08ae53c1332319854608539ee78ed2fd65_sk
    ├── signcerts
    │   └── cert.pem
    └── user

admin 사용자의 인증서는 signcerts 폴더에, 개인 키는 keystore 폴더에서 찾을 수 있다.

cryptogen과 패브릭 CA 모두 각  조직의 organizations 폴더에 암호화 자료를 생성한다. organization/fabric-ca 디렉토리의 registerEnroll.sh 스크립트에서 네트워크를 설정하는 명령을 발견할 수 있다.

 

네트워크를 켤 때 일어나는 일

./networksh up 명령을 실행할 때 발생하는 일을 알아보자!!!!!!!!!!!!!!!!

• ./network.sh는 피어 조직과 오더러 조직의 인증서와 키를 만든다. 기본값으로 cryptogen이 사용되며 -ca옵션을 주면 패브릭 CA를 사용한다.
• 조직의 암호화 자료가 생성되면 network.sh가 네트워크의 노드를 가져올 수 있다. 스크립트는 피어와 오더러 노드 생성을 위해 docker 폴더의 docker-compose-test-net.yaml 파일을 사용한다. docker 폴더에는 docker-composer-e2e.yaml 파일도 있는데 이는 패브릭 CA로 네트워크 노드를 생성할 때 사용된다.
• creageChannel 서브명령을 사용하면 ./network.sh는 script 폴더에 있는 createChannel.sh 스크립트를 실행한다. createChannel 스크립트는 기본 또는 인자로 제공된 이름의 체널을 만든다. configtxgen tool을 사용하여 체널의 제네시스 블록을 만드는데 configtx/configtx.yaml 파일에 정의된 TwoOrgsApplicationsGenesis채널 프로파일을 이용한다.
• deployCC 명령어를 사용하면 ./network.sh는 deployCC.sh 스크립트를 실행하여 두 피어 모두에 asset-transfer 체인코드를 설치한 뒤 채널에 체인코드를 정의한다. 한 번 체인코드 정의가 채널에 커밋되면 피어 CLI는 init을 사용하여 체인코드를 초기하하고 원장에 초기 데이터를 넣기 위해서 체인코드가 호출된다.

---

참고 자료

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

A Blockchain Platform for the Enterprise — hyperledger-fabricdocs main documentation