Hyperledger Fabric 네트워크 구축을 자유롭게 할 필요가 있어서 한 주간 찾으면서 공부했다. 공부해본 결과, 자료가 정말 없다. 이론적인 문서는 많은데 그것을 바탕으로 실제 네트워크를 구성하는데 레퍼런스가 될만한 것들이 정말 없었다. 그래도 고생하고 고생하며 노력한 끝에 이제 왠만큼 네트워크를 꾸릴 수 있게 되었다. 배운 것들을 정리한다는 생각으로 글을 써보기로 했다. 누군가에게 도움이 된다면 정말 더할나위 없을 것 같다.
다음과 같은 포스트를 작성할 예정이다.
- Network Overview
- byfn(Build Your First Network) 뜯어보기
- eyfn(Extend Your First Network) – Add New Org to Network
- Upgrade orderer from SOLO to Kafka
- No cryptogen!
Components of a Network
Hyperledger Fabric 네트워크는 다음과 같은 컴포넌트들로 구성된다.
- Ledger (channel당 하나씩 있다. 그리고 blockchain과 state database로 구성된다.)
- Smart Contract (chaincode)
- Organizations, MSP
- Peer nodes
- Ordering services
- Channel
- Fabric CA
Transaction Flow
Overview
Transaction Proposal
각각의 컴포넌트들의 역할을 전체적인 흐름에서 파악하는 것이 더 이해하기 쉽다. 먼저 Client는 Application SDK에서 transaction proposal을 Endorsing Peer에게 날리게 된다. 어떤 Peer들이 endorser들이 되는지와 transaction이 valid한지 기준은 Endorsement Policy에 의해 결정된다. SmartContract의 역할을 하는 chaincode는 endorsement policy를 정의하고있다. Policy에 정의된 endorse peer들에게 Client는 무조건 transaction proposal을 보내야하며 그들의 endorse 여부를 모아야한다.
Proposal을 받은 Endorsing Peer들은 transaction을 ledger을 업데이트 시키지않고 chaincode 실제로 돌리면서 시뮬레이션해본다. 그리고 각 Endorsing Peer들은 시뮬레이션 결과를 RW Set 형태로 나오는데 이것을 endorse 할 지 reject 할 지의 응답과 함께 Application에 돌려준다. RW Set은 transaction을 시뮬레이션 하기 이전의 world state의 상태와 시뮬레이션 했을 때 그 결과 상태 두 가지 set을 말한다.
Submit to Ordering Service
만약 transaction이 endorse되었다면 ordering service에 보내게 된다. Ordering Service는 쉽게 생각하면 endorsed transaction queue라고 보면된다. 실제로는 여러 client들이 transaction 날리는데 이것을 하나로 queueing 해주는 것이다. 현재 Hyperledger Fabric에선 SOLO, Kafka 두 가지 방식을 지원한다. SOLO 방식은 production에서는 사용하지 말라고 doc에 명시하고 있다. 왜냐하면 ordering service node가 한 명이고 fault-tolerant하지 않다.
Broadcast Block
그리고 여기서 모아진 transaction들을 block으로 만들어서 anchor peer들에게 보내준다. Anchor peer들만 organization 내에서 block을 받을 수 있다. Anchor peer가 organization 내에 peer들에게 block들을 broadcast해준다. 마지막으로 block을 받은 peer들은 block validation을 거치고 나면 ledger에 저장하고 world state를 업데이트 시킨다. 그리고 transaction 성공여부를 client에게 알려준다.
Conclusion
그래서 위와 같은 전체적인 과정을 그려보면 다음과 같은 순서로 진행이 된다. Company에서 client를 이용해서 transaction을 날리면 바로 ledger에 저장하는 것이 아니라, 우선 endorse peer에게 endorse response를 수합해서 그것이 valid 하면 비로소 block으로 만들어질 수 있다. 또한 실제에서는 Company가 여러개이고, endorsed transaction들도 여러개가 날아올테니 그것을 ordering service를 이용해서 queueing하고 block으로 만들어서 전파하게된다. 다음 포스트에는 byfn 튜토리얼을 뜯어보면서 과정 하나하나가 어떤 의미인지 포스팅해보려고 한다.
Reference
- https://medium.com/coinmonks/how-does-hyperledger-fabric-works-cdb68e6066f5
- http://hyperledger-fabric.readthedocs.io/en/release-1.1/arch-deep-dive.html
- https://hyperledger-fabric.readthedocs.io/en/master/network/network.html#