9) Ledger

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

• (What's) Ledger
  • ledger는 비지니스적으로 핵심정인 자료를 저장합니다. 현재상태의 값 뿐만 아니라, 그 값이 되기까지의 히스토리도 관리하는 거죠.
  • ledger는 한글로 원장이죠? 원장은 해당 비지니스의 역사로 볼 수 있습니다. 뭐 고대문명에서도 다양한 형태로 몇천년간 원장을 다~ 관리했듯이... ledger는 인류에게 참 중요합니다.
  • 은행 계좌를 볼때, 잔액이 가장 중요합니다. 그리고 그 잔액의 히스토리도 당연 조회 할수있습니다. 이런게 바로 ledger의 실례라 볼 수 있습니다. 그래서 Hyperledger Fabric에서는 ledger의 컨셉을 현상태 값과 그 히스토리로 잡았습니다.  
• Ledgers, Facts and States
  
  • ledger는 단순한 비지니스 저장소는 아닙니다. ledger에 기록을 했다는것은 '현상태의 facts값'과 '그 히스토리 facts값'을 모두 기록 했다는것 입니다. 디지털 적으로봤을때는 하나의 object를 저장하게 된것이죠.
  • '현상태의 facts값'은 그때그때 바뀌겠지만, '그 히스토리 facts값'은 immutable입니다. 그리고 blockchain 자체가 바로 immutable한 (비지니스)facts 히스토리 라는 점! 을 명심 해야 합니다. 
• The Ledger
  
  • Hyperledger Fabric에서 ledger는 'world state' 와 blockchain 두가지로 구성되어 있다고, 누차 이야기 드립니다. 둘다 비지니스적인 자료인, facts값들을 가집니다.
  • 'world state'는 ledger상태에 관란 현재값이고, 기본적으로 key-value 형태로 존재합니다. 당연히 'world state'는 바로바로 바뀔수있습니다.
  • blockchain은 한마디로 모든 'transaction 로그'로 볼 수 있습니다. blockchain에 연결되는 block 하나하나에 transaction이 기록 됩니다. blockchain은 immutable하게 관리되기 때문에, 구조적으로 좀 특별합니다.
  • Hyperledger Fabric의 blockchain-network는 논리적으로 단 하나의 ledger가 유지된다고 생각하면 됩니다. 실질적으로는 blockchain-network에 여러게의 사본 ledger들이 각각으로 존재 하겠지만, 아시다시피 consensus를 통해~ 그 전체가 일관성이 유지됩니다. 'Distributed Ledger Technology(DLT)' 이란 용어가 바로 이렇게해서 나오게 된것입니다.
• World State
  
  • 'world-state'는 시시각각 변하는 비지니스 자료를 하나의 ledger 상태로 제공합니다. 프로그램에서는 딱 현재값이 무엇인지? 요구해야 하니까요. blockchain 전체를 다 훑어서 현재값을 구하면, 매번 매우 번거롭겠죠?

  • 

    'world-state' 는 key-value 구조인데, value는 단순값 or 복합값 을 가질수 있음. 그리고 모두 versioning 됨.

  • 'world-state'는 database으로 구현되어 있는데, database엔진 차원에서 많은 유용한 오퍼레이터가 제공 됩니다. 그리고 database엔진 으로는 몇가지가 제공되는데~ 값형태라든지, application의 쿼리방식에 따라 정하면 됩니다.
  • application가 'world-state'를 바꾸는 transaction을 날린다면, 이는 최종적으로 blockchain에 기록이 될것입니다. consensus 구현은 사실 Hyperledger Fabric SDK가 다 제공함으로, application에서 손댈껀 없습니다. 그냥 application에서는 smart-contract 작동시키고, 그 transaction 결과만 잘 받으면 됩니다. 참 좋죠? 이런 구현에 핵심은 단지 '보증 organization'의 서명을 받은 transaction만 'world-state'에 반영되도록 하는것 입니다. 
  • 그리고 또한 application는 'world-state'값의 version을 받기도 하는데, 이 version은 Hyperledger Fabric 내부적으로 해당값이 바뀔때마다 auto-increase으로 잘 관리 됩니다. 이 version을 통해서, '보증처리 할 당시' 와 현재가 매칭되는지? 꼭 따져봐야 하는거! 잘 아시죠? 혹시나 (thread-safe하지 않는 함수처럼) 동시간때에 업데이트가 되어, 예상치 못한 결과가 나오면 안되니 까요.
  • 끝으로 ledger가 만들어질 당시, 'world-state'는 빈값인데~ 이는 blockchain에 아무런 transaction이 없으니, 당연한것 입니다. 그리고 이 말을 좀더 응용해서, 결과적으로 'world-state'는 언제든지 blockchain을 기반으로 재생성 될수있습니다. 이런기능은 아주 유용한데, 예를들어 신규 peer가 추가되었을때~ 간단히 'world-state' 자동생성을 해줄수 있는것 입니다. 
• Blockchain
  
  • 이제 blockchain은 한마디로 현재 값이 되기까지의 히스토리 라고... 귀가 따갑도록 들었습니다. 즉 blockchain은 'world-state'가 바뀔때마다의 모든 이전 version을 다 가지고 있는것이죠.
  • blockchain는 상호연결된 block속의 '연속적인 log' 형태로 구조화 되어 있습니다. 연속적인 각각의 transaction이 바로 'world-state'를 '단순쿼리' or '업데이트' 했겠죠. transaction의 순서는 이미 많이 이야기 됬음으로~ 여기서 하지는 않겠습니다. 그리고 (연속적인 transaction만큼이나) block의 연속적인 측면도 중요합니다. Hyperledger Fabric에서 orderer가 바로 이 block이 처음 만들어지는거 이제 다 아시죠?ㅎ
  • 각각의 block의 header는 '자신 transaction 해쉬값' 과 (이에 대응이되는) '이전 block의 해쉬값'을 모두 가지고 있습니다. 이렇게 해서 모든 block들이 순차적으로 연결이 되는거, 다들 아실것 이십니다. 이렇게 해쉬값으로 연결이 되어서 ledger가 아주 보안적으로 안전해지는것도 잘 아실것 이십니다. blockchain-network의 특정 한 node가 변조를 할 지언정, 나머지 다른 독립적인 node들이 모두 그렇게 맞춰줄 일은 없기 때문이죠.
  • 참고적으로 blockchain은 단순 파일로 구현이 되어있는데... 사실 blockchain 데이터 자체가 작은단위의 오퍼레이션으로 구성되니, 당연한것 일지도 모르겠습니다.

  • 

    blockchain의 첫번쨰 block은 'genesis block' 이라 부릅니다.

  • B2가 가지고있는 header인 H2는, 자기 transaction 데이터 D2의 헤시값으로써~ 이전 block인 B1의 헤시값과 대응관계입니다. 이렇게 block들이 불가분하게 불변하게 연결되는것 입니다.
  • 첫번째 block은 아무 transaction도 없는 'genesis block' 라는것 입니다. 'genesis block'은 초창기 channel의 상태를 포함하는 transaction 설정을 가지고 있습니다. 
• Blocks
  
  • 그럼 한번 block에 관해서~ 자세히 알아보까요?

  • 

  • Block Header
    
    • block생성시, 작성되고~ 3가지 필드로 구성.
    • Block number : 0으로 시작하는 int값. 새 block 추가마다, 1씩 증가.
    • Current Block Hash : 현 block의 모든 transaction에 헤시값
    • Previous Block Hash : 이전 block의 헤시값
  • Block Data
    
    • 'transaction 리스트'
    • orderer가 block 만들때 작성합니다.
  • Block Metadata
    
    • 'block 작성시간' 뿐만아니라, 작성자의 '인증서'(공개키), 서명 등
    • 그 이후, block 등록자에 의해서 모든 transaction에 관한~ valid/invalid 표시도 됩니다.
    • 당연히, 메타데이터는 헤시값에 영향을 주지 않습니다.
• Transactions
  
  • 그럼 'block data'속의 transaction에 관해서도~ 알아보까요?

  • 

  • Header
    
    • 해당 transaction의 필수 메타데이터. (예: chaincode의 이름 과 version 등등)
  • Signature
    
    • client application의 서명. (private key이 사용됨으로, transaction이 변조되었는지? 확인가능한것)
  • Proposal
    
    • ledger를 변경하는 ('proposed transaction'을 생성하는) smart-contract에게 제공되는 'input 파라미터'.
  • Response
    
    • 'Read-Write set' 으로써, world-state의 변경 전/후 값.
    • smart-contract의 'output'.
    • (만약 transaction이 유효하면, ledger에 반영됨)
  • Endorsements
    
    • '보증정책'을 만족할만큼 충분한, organization부터의 '서명된 transaction response' 리스트.
    • 단 하나의 transaction에도 여러게의 endorsements가 있을수 있는것.
• World State database options
  
  • world-state는 물리적으로 database로 구현이 되어있고, ledger의 상태를 검색하기에 아주 용의하고 편리 합니다. 앞서봤듯이, world-state는 '단순값' 혹은 '복합값'이 가능하고, 이렇것들을 수용하기위해~ world-state 구현체으로 선택사항이 제공됩니다. 바로 LevelDB 및 CouchDB 옵션 입니다.
  • LevelDB가 디폴트값 이고, key-value쌍의 '단순값'일으로 적합합니다. blockchain-network상의 하나의 node에 포함된 프로세스로써 위치하게 됩니다.
  • CouchDB는 (JSON같은) 구조화된 도큐먼트 데이터에 적합니다. 왜냐면 비지니스 적으로 종종 쓰이는 데이터타입에 관해서, 다양한 '단순쿼리' 및 '업데이트'를 제공하기 때문입니다. blockchain-network상의 독립된 프로세스로 존재하고, 몰론 하나의 특정 peer-node와는 1:1 대응관계를 이룹니다.
  • Hyperledger Fabric에서는 이렇게 pluggable한 방식으로 유연성을 제공한답니다.
• Example Ledger: fabcar
• Namespaces
• Channels
  
  • (생략~)

-끝-