10) The Ordering Service

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/orderer/ordering_service.html

• What is ordering?
  • 다른 개방형 블록체인(이더리움, 비트코인) 등 에서는~ 아무 node나 transaction의 순서를 정하고, block으로 묶는 consensus에 참여를 할 수 있습니다. 왜냐면~ 높은확율적으로 ledger의 일관성을 보장하는 '확률론적(probabilistic) consensus 알고리즘'을 채택하기 때문입니다. 물론 그래서 ledger의 분기에 취약하기긴 합니다. (흔희, fork됬다고 하죠) 이 fork가 되면, blockchain-network 참여자들이 서로다른 'transaction 순서'를 가지게 되버리는 것이죠.
  • Hyperledger Fabric는 이같은 점에서 다릅니다. 바로 orderer가 'transaction 순서'를 관리하기 때문이죠. 그래서 Hyperledger Fabric을 '결정론적(deterministic) consensus 알고리즘' 채택했다고 볼수있습니다. peer가 orderer에 의해 생성된 block을 검증함으로써, 어떤 정확함이 보증되는것 입니다. 이 결과 ledger는 절때 fork되지않게 되됩니다.
  • 이외에도, orderer에서 'chaincode 실행'의 보증을 하지않고~ peer으로 분리함으로써~ 성능과 확장성을 월등하게 향상 시켰습니다. (순서화 와 실행을 한 node에서 같이하면... 병목현상이 일어났겠죠)
• Orderer nodes and channel configuration
  
  • 순서화 역활 이외에, orderer는 'channel 생성'을 할수있는 'organization 리스트' (컨소시엄) 를 관리합니다. 'orderer system channel'이라는 것이 관리되는것 입니다. 기본적으로 orderer admin관리자가 수정할수있습니다. 그리고 또한 여러게의 컨소시엄을 관리 할 수 도있다는점도~ 참고하세요.
  • orderer는 channel관한 기본 접근제어를 시행하면서, 누가 데이터를 RW 할수있는지? 누가 설정을 할수있는지? 제한 합니다. 'channel 설정' 권한자는 참고적으로, channel이나 컨소시엄을 만들때 정한 정책에 영향을 받습니다. '설정 transaction'은 orderer에 의해서 처리가 되고, 현 정책에서 실행되는 기본 접근제어형식을 알아야 합니다. 물론, orderer는 당연히 해당 요청자의 권한을 확인 하겠죠? 그래서 검증이 되면, 새로운 '설정 transaction'을 만들어서 channel의 모든 peer들에게 전달될 block으로 패키지화 합니다. 이후 peer에서는 해당 '설정 transaction'이 channel에 정의된 정책을 정말 만족하는지? 검증합니다.
• Orderer nodes and Identity
  
  • orderer를 포함한, blockchain-network 상의 모든 상호작용에는 각자의 'organization identity'(인증서+MSP)가 필요하다는거 잘 아실것 이십니다. organization들은 각자 알아서 별도의 CA를 통한 인증을 받는것이고, root-CA 일지? intermediate-CA 일지? 도 알아서 하면 되는것 입니다.
• Orderers and the transaction flow
  
  • 1단계 : Proposal
    
    • client-application는 'transaction proposal'을 부분 peer들에게 보내어서, 해당 smart-contract을 작동시키고 -> 'proposed update'를 생성하고 -> 그 결과를 보증 하도록 하게 합니다. 해당 'endorsing peers'는 'proposal response'를 client-application에게 리턴하는것이고, 결과적으로 이 '보증된 transaction'은 2단계때~ block으로 순서화 패키지화 될 것 입니다. 
  • 2단계 : Ordering and packaging transactions into blocks
    • 1단계가 끝나면,client-application은 '보증된 transaction proposal'을 많이 가지고 있을것 입니다. 
    • 이상황에서 client-application은 orderer에게 이 transaction들은 제출 합니다. 그리고 orderer는 이 transaction들로 block을 만듭니다.
    • orderer는 동시에 서로다른 client-application에서 여러 transaction을 다 받을것입니다. 그래서 blockchain-network 상의 orderer들은 함께 협업을 하게됩니다. 이 협업은 제출된 transaction들을 잘 정의된 순차적로 이어서, block으로 패키지화 하는것 입니다. 이 block이 blockchain의 바로 그 block으로 되는것입니다.
    • 한 block의 transaction갯수는 channel 설정(BatchSize:크기,BatchTimeout:허용시간)으로 정하면 됩니다.

    • 

    • 참고적으로 block에서의 transaction순서는~ 꼭 orderer가 받은순서와 일치되진 않습니다. 핵심은 orderer transaction순서를 확실하게만 정해주면 되는것이고, 차후에 peer에서 다시 이 순서에 따라~ 재검증하고 반영한다는 것에 있습니다.
    • 이 확실한 block에서의 transaction순서가 바로 Hyperledger Fabric을 다른 블록체인들과 차별화 하게 만드는것 입니다. (보통의 다른 블록체인에서는 종종 똑같은 transaction이 서로다른 block으로 각각 패키지되어, chain연결경쟁 합니다) Hyperledger Fabric는 바로 orderer가 만든 block이 유일한 최종품 입니다. transaction이 특정 한 block에 기록되면, ledger에서의 위치가 immutably 보장 됩니다. 다시 말하자면 Hyperledger Fabric에서의 최종성이란 ledger의 fork가 없다는것을 의미합니다.
    • orderer에서는 'smart-contract 실행' 및 'transaction 처리'를 전혀 하지 않는점을 주목해 보세요. orderer는 단지 '보증된 transaction'을 기계적으로 block에 패키지화 할 뿐입니다. 즉 orderer는 transaction 내용에 어떤 판단도 하지 않습니다. (channel 설정 transaction은 예외)
    • 끝으로~ orderer는 단순하지만 아주 필수적인 transaction 순서화 및 패키지화를 강력하게 한다고! 보시면 될것 같습니다.
  • 3단계 : Validation and commit
    • 3단계 에서는 orderer에서 -> peer으로 분배 및 재검증을 하게 됩니다.
    • orderer는 모든 연결된 peer들에게 block을 분배합니다. 그렇다고 모든 peer가 orderer에게 반듯이 연결되 있어야 하는것은 아닙니다. (peer는 'gossip 프로토콜'으로 다른 peer에게 block을 낙수받을 수 있습니다)
    • 각각의 peer는 분배된 block을 검증하는데, '결정론적(deterministic) fashion' 으로 ledger을 일관되게 유지합니다. 바로 channel속 각각에 peer는 '요구되는 organization들에게 보증 받았는지?' , '그 보증이 확실한것지?' , '보증당시 함께있던 다른transaction이 반영이 되면서, 해당 transaction이 유효하지 않게 되었는지?' 등을 검증하는것 입니다. 물론 block속 많은 transaction들중~ '유효하지않는 transaction'도... block에 유지됩니다. (block은 immutably 하니까요) 하지만 그 transaction에는 peer에 의해서 유효하지않는 표식이 되고, 최종적으로는 ledger에 반영되지 않겠죠.

    • 

    • 요약드리자면, orderer에서 생산된 block은 모든 ledger에 일관되게 반영 됩니다. 
    • 바로 '확실한 block의 transaction순서'만 보장이 되면, 모든 peer의 검증은 똑같은 결과가 나올것이고~ 그래서 'blockchain network'의 전체 ledger가 일관되게 업데이트 되는것 이랍니다.
• Ordering service implementations
  
  • orderer는 기본적으로 transaction을 동일하게 처리하고 각종 설정을 업테이트만 잘하면 되지만, 그럼에도 불구하고 '확실한 block의 transaction순서'를 달성하기 위한 orderer들간의 consensus 방식에 따라서... orderer를 좀 분류를 할 수 있습니다. 
  • Solo
    
    • 단 하나의 orderer-node으로 구현한 방식입니다. 그 결과로 어떤 fault-tolerant는 있을리가 없겟죠? (network가 특정결함에 강한... 어떤내성이 전혀 없다는 의미) 
    • 그래서 사실, 상용서비스 용도는 아니고~ 테스트 network 구축에 아주 요긴합니다.
    • PoC : proof of concept
  • Raft
    
    • 'Raft protocol'을 기반으로 'crash fault tolerant (CFT)'가 있는 구현 방식입니다. 'leader and follower' 모델을 기반으로 한다고 합니다. 즉, channel별로 leader-node 선출되면, 그의 결정은 follower-node에 의해 복제 되는식 입니다.
    • 비교적 이 방식으로도 서로다른 organization간 orderer를 구축하기 편한편 입니다. 
  • Kafka
    
    • (Raft와 비슷한데) Kafka역시 'leader and follower'을 사용하는 'crash fault tolerant (CFT)' 구현 방식입니다.
    • 뭐... 당연히 Apache Kafka는 ZooKeeper과 함께 구동이 되고... Fabric 초창기부터 제공이 되었는데... 아무래도 Kafka cluster 까지 관리를 해야하다보니... 옳지않다는 이야기가 많이 나온다고 하네요.ㅎㅎ
• Solo
  • (상세 설명은 생략~)
• Raft
  
  • (상세 설명은 생략~)
• Kafka
  
  • (상세 설명은 생략~)

-끝-