1) Architecture Origins

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html

[(!)Note] 이번 장에서 말하는 내용은 'Hyperledger Fabric v1.0'의 초창기 'architectural proposal' 입니다. 물론 그동안 'Hyperledger Fabric'은 개념적으로 'architectural proposal'의 구현을 적절히 유지해 왔겠지만, 조금씩 변경은 되었을 것입니다. 그래서 기술적으로 정확하게 이 아키텍쳐를 파악하고 싶으신 분들은~ "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" 논문을 찾아보삼요.

• Hyperledger Fabric `아키텍쳐`는 아래와 같은 장점이 있습니다.
  • Chaincode trust flexibility (유연한 chaincode 신뢰성)
    • `아키텍쳐`로써, "chaincode의 신뢰판단" 과 "ordering의 신뢰판단" 이 분리되어 있습니다.
    • 바꿔말하면, ordering은 한 세트의 orderer-node들로 제공되고, 그들중 일부에 오류가 나더라도~ 내성이 있습니다.
    • 그리고 각 chaincode마다 `보증-node`가 다를 수 있다는것을 의미합니다.
  • Scalability (확장성)
    • `보증-node`가 orderer-node와 직교적(orthogonal:독립적?)이기 때문에, 시스템적으로 확장성이 좋아지게 된것 입니다.
    • 특히, 서로다른 chaincode가 서로다른 `보증-node`에 지정되면서~ 분산 및 병렬처리가 가능해 집니다.
    • 또한, 복잡한 "chaincode의 실행"을 orderer-node에서 돈캐어 할 수 있는것도 큰 장점입니다.
  • Confidentiality (기밀성)
    • 기밀성이 요구되어지는 "chaincode의 배포"에 용이한 `아키텍쳐`를 제공 합니다.
  • Consensus modularity (모듈성)
    • `아키텍쳐`적으로 모듈화되어, pluggable한 consensus적용이 됩니다.
• 결과적으로 본장에서는 아래와 같은 Part으로 내용을 정리합니다.
  • Part I : Hyperledger Fabric v1 아키텍쳐의 구성요소
    
    • System architecture
    • Basic workflow of transaction endorsement
    • Endorsement policies
  • Part II : Hyperledger Fabric v1 이후, 아키텍쳐의 구성요소
    
    • Ledger checkpointing (pruning)
• 1. System architecture
  
  • blockchain은 "분산 노드 시스템" 입니다.
  • (chaincode)프로그램을 돌리고, state 및 ledger 데이터를 가지고, transaction을 실행하는것 입니다.
  • chaincode에서 transaction이 호출되어지고, 보증된것만 state 및 ledger 데이터에 반영 됩니다.
  • 또한, system-chaincode라는 특정용도의 chaincode도 있습니다.
  • 1.1. Transactions
    
    • transaction은 두가지 타입으로 나눌수 있습니다.
    • deploy-transaction
      
      • deploy-transaction이란, new chaincode를 만들고 프로그램을 파라미터로 사용합니다.
      • deploy-transaction가 잘 실행되면~ blockchain에 해당 chaincode이 install 된 것 입니다.
    • invoke-transaction
      
      • invoke-transaction이란, 설치된 chaincode의 특정작업을 수행하는 놈입니다.
      • 즉, invoke-transaction는 chaincode의 한 function입니다.
      • invoke-transaction가 잘 실행되면~ state 및 ledger 가 바뀌고 결과를 리턴하게됩니다.
    • (나중에 다시 말하겠지만... deploy-transaction는 특별한 system-chaincode의 invoke-transaction 입니다.)
    • (주의 : "optimizations for query-transaction" 및 "cross-chaincode transactions" 는 논외)
  • 1.2. Blockchain datastructures
    
    • 1.2.1. State
      
      • blockchain의 최신(마지막) state는 versioned key-value-store(KVS) 형식으로 되어있습니다.
      • 이 데이터는 KVS의 put,get 으로 조작할수있습니다.
      • state를 영속성 있게 저장하고, 업데이트시 log처리도 합니다.
      • 실제 versioned KVS를 사용하면 되는데, RDBMS나 다른 솔루션은도 가능은 합니다.
        
        • 예) K -> (V X N) , K -> (⊥, ⊥) , s(k)=(v,ver) , s(k).value , s(k).version , s'(k)=(v,next(s(k).version))
      • (state는 오직 peer에 의해서만 관리되어지고, orderer 와 client 는 돈캐어)
    • 1.2.2 Ledger
      
      • ledger는 state의 변동에 성공 및 실패한 모든 transaction 이력을 제공합니다. (유/무효한 transaction)
      • ledger는 ordering에 의해 transaction의 block의 전체 정렬된 hashchain으로 구성됩니다.
      • 즉, hashchain으로 ledger의 전체 block에 순서가 부과되고, 각 block은 정렬된 transaction를 가짐으로써~ 전체 transaction이 정렬되는것 입니다.
      • ledger는 모든 peer에 보관되고, 옵션적으로 orderer 일부에도 됩니다. (PeerLedger , OrdererLedger)
      • (PeerLedger는 로컬에 유/무효한 transaction을 표시하는 bitmask를 가집니다.)
      • (OrdererLedger 내결함성 및 가용성을 위해 사용이 됩니다.)
      • ledger에 쌓인 모든 이력을 재생하면 -> 현 state가 되겠죠? ㅎㅎ
  • 1.3. Nodes
    
    • node란, blockchain에서 통신을 하는 주체라 볼수있습니다. node는 논리적 단위 임으로, 서로다른 종류의 node가 같은 물리적 서버에서 돌수있습니다.
    • 중요한 포인트는 node를 "어떻게 신뢰하는 그룹으로 도메인화"하거나, "제어를 하는 주체와 어떻게 연결"할지? 등입니다.
    • 아래와 같은 3가지 종류의 node가 있습니다.
      • 1. Client or submitting-client :
        • 실질적으로 transaction을 발생시키는 주체.
        • transaction을 '보증-node'에게 제출을 하고, transaction-proposal을 'orderer-node' 에게 전파함
      • 2. Peer :
        • transaction을 커밋하고, worlde-state 및 ledger를 유지하는 주체.
        • '보증-node' 역할도 할수있음.
      • 3. Ordering-service-node or orderer : 
        • 순차적으로 원자적으로 통신을 보증하는 주체.
    • 1.3.1. Client
      
      • client-node는 사용자의 행동을 해주는 주체입니다.
      • 항상 원하는 peer-node와 연결해서, blockchain상에서 통신을 하는것 입니다.
    • 1.3.2. Peer
      
      • peer-node는 orderer-node으로부터 block을 받고, state 및 ledger 를 관리 합니다.
      • 특별히 '보증-node' 역할을 할 수 있는데, 특정 chaincode와 관련해서 발생하는 transaction을~ 커밋되기전 보증확인 합니다.
      • 모든 chaincode는 '보증-node'를 지정하는 "보증 정책" 이 있습니다. 
      • "보증 정책"은 유효한 transaction의 조건을 정의합니다. (필요한 '보증-node'의 서명)
      • chaincode를 배포하는 특수한 transaction경우에는 system-chaincode의 "보증 정책"을 따릅니다.
    • 1.3.3. Ordering service nodes (Orderers)
      
      • orderer-node는 통신을 보증하는 역할이라 할 수 있다.
      • ordering 이라는것은 다양한 방식으로 구형될수있는데, 중앙집중식, 분산 네트워크식 등등 이다.
      • ordering 을 통해서, peer나 client는 "통신채널"을 제공 받을 수 있게 된다.
      • client는 channel에 연결을 하고, message를 전파하여~ 모든 peer에게 전달할수있다.
      • 이러한 channel은 message를 안전하고 순서화되도록, "원자적 통신"을 제공해야 합니다.
      • 분산 네트워크에서 이런 "원자적 통신"을 consensus라고 합니다.
      • 이런 "원자적 통신" 환경에서 message에 blockchain의 transaction을 담는것 입니다.
      • Partitioning (ordering service channels)
        
        • 기본적으로 ordering은 "Pub/Sub 시스템"과 유사하게, "멀티 channel"도 지원해야 합니다.
        • 즉, channel을 partition으로 생각할수있는데~ 각각에 channel 간에는 독립적 인것 입니다.
      • Ordering service API
        
        • peer는 ordering에의해 제공되는 channel에 접속을 하게 됩니다.
        • 여기서 'ordering API'는 2가지 기본적인 작업으로 구성 됩니다.
          • broadcase(blob) : client가 mesage를 channel으로 전파함. 
          • deliver(seqNo, prevHash, blob) : peer에서 호출해, seqNo+prevHash의 message를 전달함.
          • TODO : client/peer가 seqNo으로 특정 block을 때오는 API.
      • Ledger and block formation
        
        • ledger는 ordering 과정에서 나온 모든 데이터를 가지게 됩니다.
        • 간단히 말해서, deliver(seqNo, prevHash, blob) 이벤트의 hash-chain 값 같은거 입니다.
        • ordering 과정은 대부분 효율성을 위해서, transactions(blob)을 묶어서 block화 합니다.
        • 그래서 block안의 transactions(blob)은 순서화 되저 전달 됩니다.
      • Ordering service properties
        
        • ordering의 보장은 "전파된 message" 와 "전달된 message간 관계" 같은것 입니다.
        • 1. Safety (consistency guarantees)
          • ...
        • 2. Liveness (delivery guarantee)
          
          • ...
        • 요약하자면 ordering의 아래과 같은 속성을 보장하는것 입니다.
          • Agreement : ...
          • Hashchain integrity : ...
          • No skipping : ...
          • No creation : ...
          • No duplication (optional, yet desirable) : ...
          • Liveness : ...
• 2. Basic workflow of transaction endorsement
  
  • transaction의 흐름에 관해서 개략적으로 설명을 하겠습니다.
  • (모든 transaction이 deterministic라 가정하지 않습니다. 즉, non-deterministic을 허용합니다.)
  • 2.1. The client creates a transaction and sends it to endorsing peers of its choice
    
    • ...
  • 2.2. The endorsing peer simulates a transaction and produces an endorsement signature
    
    • ...
  • 2.3. The submitting client collects an endorsement for a transaction and broadcasts it through ordering service
    
    • ...
  • 2.4. The ordering service delivers a transactions to the peers
    
    • ...

  • 

• 3. Endorsement policies
  
  • 3.1. Endorsement policy specification
    • "보증 정책"이란, 말그대로~ transaction을 보증하는 조건이다.
    • 각각의 peer는 미리 셋팅된 "보증 정책"을 가지고 있다.
    • "보증 정책"은 파라미터화 될 수 있는데, 이런 파라미터는 deploy-transaction을 통해 명시될수있다.
    • "보증 정책"은 '제한된 기능'의 '검증된 정책'이어야 합니다. (종결성, 결정성, 성능 및 보안을 위해)
    • 그래서 "보증 정책"의 동적인 추가는 "종결성, 결정성, 성능 및 보안"에 매우 민감해서... 아직은 안됨니다.
  • 3.2. Transaction evaluation against endorsement policy
    
    • transaction은 정책에따라 보증된것만, 유효하다 할 수 있습니다.
    • transaction 동작시, 먼저 보증부터 받아야하죠. 앞장의 submitting-client 및 endorsing peers 간 작업같이.
    • 보증에 관한 deploy-transaction은 system-chaincode같은 "system-wide 정책"을 따라야 합니다.
    • "보증 정책"은 아래와 같은 변수를 다룹니다.
      
      • 1. 'keys' 혹은 'chaincode 아이디', 예를들어 endorsers-set.
      • 2. chaincode의 메타데이터
      • 3. 보증 요소
      • 4. 기타 등등
    • "보증 정책"을 판단은 deterministic 해야 합니다. 
    • 즉, 모든 peer가 각자 독립적으로 하고~ 모두 똑같은 방식으로 해야 한다는것 입니다.
  • 3.3. Example endorsement policies
    
    • 일반적으로 "보증 정책"은 '보증-peer'의 서명을 활용합니다.
    • 즉, chaincode에 endorsers-set을 명시하는것 입니다.
    • 예) E = {Alice, Bob, Charlie, Dave, Eve, Frank, George}
      • ...
      • ...
      • ...
    • 정책을 응용적으로 적용하는것에 유용성은 하기나름이십니다....
• 4 (post-v1). Validated ledger and PeerLedger checkpointing (pruning)
  
  • 4.1. Validated ledger (VLedger)
    
    • ...
  • 4.2. PeerLedger Checkpointing
    
    • ...

-끝-