hyperledger/fabDoc.Tutorials
2) Building Your First Network
바이수
2019. 6. 22. 17:26
원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/build_network.html
- Building Your First Network
- BYFN은 (각자 2개의 peer_node를 가지는) 2개의 organization으로 구성된, Hyperledger Fabric 블록체인 네트워크 예제입니다.
- orderer_node는 그냥 기본적인 "Solo" 타입으로 진행됩니다.
- Install prerequisites
- 'Prerequisites' 와 'Install Samples, Binaries and Docker Images' 는 당연히 각자 환경에 맞게~ 잘 준비하셈.
- https://github.com/hyperledger/fabric-samples 의 /first-network 를 기반으로 진행됩니다.
- Want to run it now?
- 기본적으로 /first-network 에서 '실행 스크립트(byfn.sh)'가 아주 잘 제공됩니다.
- 아무것도 몰라도, byfn.sh 으로 Docker기반의 'Hyperledger Fabric 블록체인 네트워크'를 띄울순있게 됩니다.
- 이 뿐만 아니라~ peer를 channel에 참여시키고, chaincode를 배포하고, 실행 transaction도 일으킬수있습니다.
- (그럼 한번, 아래와 같이... byfn.sh 실행법을 간단히 살펴 보아욯)
- 1) Generate Network Artifacts
- "./byfn.sh generate" 을 쳐보면, cryptogen 및 configtxgen 으로 생성하는 각종파일을 생성해줍니다.
- (물론, 직접 cryptogen 및 configtxgen으로 '인증서'-'키'-'genesis block' 등등을 만드실순 아시죠?)
- 2) Bring Up the Network
- "./byfn.sh up" 을 쳐보면, orderer 및 peer 및 cli 등의 Docker가 띄게 됩니다.
- (물론, 직접 docker-compose.xml 을 작성하여 띄워보는것이 훨신 좋겠죠?)
- 3) Bring Down the Network
- "./byfn.sh down" 을 쳐보면, 띄웠던 Docker를 내립니다. 참 쉽죠?
- 이렇게 byfn.sh 으로 빠르게 'Hyperledger Fabric 블록체인 네트워크'를 구성해볼수있는것 입니다.
- (그럼 한번, 이제 cryptogen 및 configtxgen 그리고 docker-compose.xml 을 직접 살펴 보아욯)
- Crypto Generator
- 'cryptogen 툴' 은 '인증서 및 키' 등등의 'Hyperledger Fabric 블록체인 네트워크'에 필요한 다양한 파일들을 생성하는 바이너리 입니다.
- How does it work?
- crypto-config.yaml 을 작성하면 됨.
- 'blockchain-network 체계' 와 '각 organization 정보' 및 '각 organization 구성정보' 로 '인증서 및 키' 생성.
- 각각에 organization 에는 그들의 '구성 Node'를 묶을수있도록, 각각에 'Root CA 인증서' 제공되니~ 안심.
- 각 organization별, 유니크 'CA 인증서' 통해~ 각 구성원들은 자신의 '자격 증명(Certificate Authority)' 함.
- 모든 transaction 및 communication 은 각 Node의 private-key로 싸인되고 public-key로 검증된다고 봄.
- Configuration Transaction Generator
- 'configtxgen 툴' 은 '1.orderer genesis block', '2.channel설정 트랜잭션파일', '3.anchor-peer설정 트랜잭션파일' 을 생성하는 바이너리 입니다.
- 1) 'orderer 블록'은 '오더링 서비스'를 위한 'genesis block' 입니다.
- 2) 'channel설정 트랜잭션파일'은 channel이 만들어질때, 전체 orderer에게 전달 됩니다.
- (말그대로 transaction을 일으키는 파일 이였단 말인가?!?!?!)
- 3) 'anchor-peer설정 트랜잭션파일'은 channel의 org에 anchor-node를 지정하게 됩니다.
- (말그대로 transaction을 일으키는 파일 이였단 말인가?!?!?!)
- How does it work?
- configtx.yaml 을 작성하면 됨.
- 'blockchain-network 구성' 을 정의하는 내용으로 볼 수 있는데...
- 1) Organization
- 'Orderer Org' : 특정조직의 channel MSP 와 Policies(Node에 읽기/쓰기 권한 정책) 를 정의.
- 'Peer Org' : 특정조직의 channel MSP 와 Policies 와 AnchorPeers 를 정의.
- 2) Capabilities
- Channel : // TODO
- Orderer : // TODO
- Application : // TODO
- 3) Channel
- 특정 Channel를 정의.
- 4) Orderer
- 특정 OrdererType 및 Address 및 Batch 및 Kafka 및 Policies 및 Organization 등을 정의.
- 5) Application
- Organization : 특정 Application에 참여는 조직들을 정의.
- Policies : 읽기/쓰기 권한 정책(?) 정의.
- Capabilities : // TODO
- 6) Profiles
- 'genesis block' 혹은 'channel' 을 위 정의를 기반으로 '프로파일 정의'를 하면 됨.
- 예) '오더링 서비스:Solo' 를 위한 'genesis block' 생성엔, 하나로 정의.
- 예) '오더링 서비스:Raft' 를 위한 'genesis block' 생성엔, 여러게의 orderer 및 etcdraft 으로 정의.
- 예) '오더링 서비스:kafka' 를 위한 'genesis block' 생성엔, 여러게의 kafka-broker 으로 정의.
- 1) Organization
- 각 'Orderer&Peer Org'의 channel MSP를 정의 하고, 'genesis block'에 이 정보가 저장 되는 것.
- (이렇게 함으로써 모든 '오더링 서비스'를 통한 통신에서 'digital identity'가 검증되는것!)
- Run the tools
- 그럼... cryptogen 와 configtxgen 을 직접 실행 해 보는것을 간단히 아래와 같습니다.
- Manually generate the artifacts
- cryptogen generate --config=./crypto-config.yaml
- export FABRIC_CFG_PATH=$PWD
- configtxgen -profile TwoOrgsOrdererGenesis -channelID byfn-sys-channel -outputBlock ./channel-artifacts/genesis.block
- configtxgen -profile SampleMultiNodeEtcdRaft -channelID byfn-sys-channel -outputBlock ./channel-artifacts/genesis.block
- configtxgen -profile SampleDevModeKafka -channelID byfn-sys-channel -outputBlock ./channel-artifacts/genesis.block
- Create a Channel Configuration Transaction
- export CHANNEL_NAME=mychannel
- configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
- configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP
- configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP
- Start the network
- 그럼... 본적격인 블록체인 네트워크를 띄우는것은~ docker compose를 황용해서,
- docker-compose -f docker-compose-cli.yaml up -d 와 같이 하면 되는것 입니다.
- Create & Join Channel
- peer channel create -o orderer.example.com:7050 -c $CH_NA -f ./channel-artifacts/channel.tx
- peer channel join -b mychannel.block
- Update the anchor peers
- peer channel update -o orderer.example.com:7050 -c $CH_NA -f ./channel-artifacts/Org1MSPanchors.tx
- Install Chaincode
- peer chaincode install -n mycc -v 1.0 -p github.com/chaincode/chaincode_example02/go/
- peer chaincode install -n mycc -v 1.0 -l node -p /opt/.../github.com/chaincode/.../node/
- peer chaincode install -n mycc -v 1.0 -l java -p /opt/.../github.com/chaincode/.../java/
- Instantiate Chaincode
- peer chaincode instantiate -o orderer.example.com:7050 -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"
- peer chaincode instantiate -o orderer.example.com:7050 -C $CHANNEL_NAME -n mycc -l node -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"
- peer chaincode instantiate -o orderer.example.com:7050 -C $CHANNEL_NAME -n mycc -l java -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"
- -P 옵션을 통해서, 'endorsement 정책'을 해당 chaincode 에 지정 할 수 있다.
- Query
- peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'
- Invoke
- peer chaincode invoke -o orderer.example.com:7050 -C $CHANNEL_NAME -n mycc --peerAddresses peer0.org1.example.com:9051 -c '{"Args":["invoke","a","b","10"]}'
- What’s happening behind the scenes?
- ...
- What does this demonstrate?
- 이런 동작이 무엇을 보여주는것 일까요?
- 보셧던것 처럼, chaincode는 반듯이! peer에 install 되어있어야 합니다. (ledger를 읽고/쓰기 위해서~)
- 그리고 init 등의 transaction으로 'chaincode프로세스 컨테이너'가 띄면서, 읽고/쓰는 수행을 합니다.
- 즉, transaction이 'chaincode프로세스 컨테이너'의 출발로 볼수있습니다.
- channel의 모든 peer는 ledger의 복제를 유지하고, 블록체인의 불변성을 이룹니다. (chaincde를 install 하지않은 peer도 ledger복제는 됨)
- 마지막으로, 해당 channel에 instantiate된 chaincode의 특정version은, 새로운 peer에 install하고 바로 사용 할 수 있습니다.
- How do I see these transactions?
- ...
- How can I see the chaincode logs?
- ...
- Understanding the Docker Compose topology
- ...
- Using CouchDB
- 데이터베이스를 CouchDB으로 할 수 있는데, JSON으로 데이터 모델링하여~ 풍부하고 복잡한 쿼리를 지원 함.
- ...
- Why CouchDB
- CouchDB는 하나의 (document-oriented)NoSQL 솔루션이다.
- 'document field' 는 단순한 key-value 이거나 list 혹은 map 등도 지원한다.
- (물론, key/composite-key/key-range 정도의 쿼리는 LevelDB도 지원 한다)
- CouchDB '전체 블록체인 데이터'를 대상으로 non-key 같은 풍부한 쿼리도 지원한다.
- 내부적으로 데이터는 JSON으로 모델링 되어있고, 쿼리 가능하다.
- ;
- 또한, CouchDB는 보안성과 안정성도 더 좋다.
- transaction 요소의 개별적인 필터링 및 마스킹을 통해서, 'document field' 레벨별 보안이 가능하고,
- (필요한 경우) 읽기전용 권한만 인가 할수도있다.
- ;
- 게다가, CouchDB는 'CAP정리' 에서 'AP타입'(Availability and Partition Tolerance) 이다. // TODO : 링크?
- 참고로, 리플리케이션(replication)은 master-master 모델을 사용한다. (Eventual Consistency)
- 물론 fabric peer에서는 특별히 리플리케이션(replication)을 하지않기 때문에~ 쓰기의 '일관성' 및 '내구성' 이 보장 됩니다. (그럼 오히려 'C타입' ???)
- CouchDB 외에도 'CP타입'(Consistency and Partition Tolerance) 이 추가될 예정이라고 합니다.
- (이렇게 되면, application에서 신경쓰지 않아도~ '일관성'이 보장되겠죠?)
- A Note on Data Persistence
- 지속적인 데이터를 가지는것은 '컨테이너 프로세스'에게 필요 합니다.
- 하나의 방법으로 docker 호스트의 디렉토리를 마운트 시키는 것이 있습니다.
- ...
- Troubleshooting
- ...
-끝-