3) Process and Data Design

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

• Process and Data Design
  • 이번장에선 PaperNet에서 '기업어음'이 어떤식으로 처리되고, 연관된 데이터 구조에 관해서 알아봅시다. 
  • 특히, application 및 smart-contract 개발에 아주 중요한 두가지 개념 위주로 설명 하겠습니다.
• Lifecycle
  
  • 앞서 말했듯이, 중요한 두가지 개념이 있습니다. 바로 states 와 transaction 입니다.
  • states는 모델링된 데이터의 '값상태'라 볼수있고, transaction은 라이프사이클 상의 '상태전이'라 볼수있습니다.
  • 그래서 '기업어음'의 라이프사이클을 아래와 같이 다이어그램화 할수있습니다.

  • 

    '기업어음'은  issued, trading, redeemed '상태값'이있고, issue, buy, redeem으로 '상태전이' 함.

  • 바로 Hypledger Fabric에선 'smart-contract 로직'을 통해, '기업어음'의 states가 변화합니다.
• Ledger state
  
  • 원장에는 각 '기업어음'의 정형화된 형식에 '상태값'을 가집니다. 그리고 states는 다양한 값들로 구성할수있는것이 중요합니다. (그래서 state가 스칼라 아닌 벡터로 표현할수있다고 하네요.)
  • states는 key/value으로 표현되는데, JSON처럼 한값을 복수값으로 구성할수있습니다.
  • 참고적으로 각각의 state별로, '구성값들의 형식'이 똑같을 필요도 없고~ 시간별로 똑같은 필요도 없습니다.
  • Hyperledger Fabric 원장은 똑같은 자산에 관해서 서로다른형식을 지원하기 때문이고, 새로운 구성값의 추가도 유연하게 잘 지원 합니다.
• State keys
  
  • 한 state는 특정 구성값의 조합으로 유니크 해질수 있는데, 이 조합값을 'state key'라 할수있습니다.
  • 이 'state key'가 바로 '기업어음'의 '유니크 ID'로 사용되겠죠?
  • 만약에 유니크한 조합이 없으면, UUID를 쓰면 됩니다.
• Multiple states
  
  • PaperNet의 '기업어음'은 원장의 'state 벡터'형태로 저장된다고 배웠습니다.
  • 이 때문에 원장에서 서로다른 '기업어음'을 쿼리 할 수 있게되는것 입니다. (특정 구성값 조건절 쿼리)
  • 이런 쿼리검색을 원활히 하려면, '기업어음'을 논리적인 단위로 미리 그룹핑 해둬야 겠죠?
  • 당연, 이 논리적 컨테이너는 '기업어음'이 발행되거나 바뀔때마다~ 인덱스 비용이 발생할것입니다.
  • Logical representation
    
    • 아래와 같이 '기업어음'을 단일 리스트 그려보았습니다.

    • 

    • '발행 transaction'으로 신규 '기업어음'을 추가할수있고, '구매 상황 transaction'으로 수정할수도있습니다.
    • 참고적으로 이런 리스트의 이름은 DNS작명을 참고하는것이 편리합니다.
  • Physical representation
    
    • '기업어음' 단일 리스트는 아래와 같이 개별 state집합으로 구현하면 됩니다.
    • (각각의 '복합 key'는 리스트 각 항목과 대응되고, 이 '복합 key'으로 유니크 및 쿼리를 잘 합니다.)

    • 

    • '복합 key'는 '리스트 이름' + '발행자' + '번호' 로 이어지는이, 이렇게하면 두가지 이점이 있다고 합니다.
      
      • 1) 원장의 'state 벡터'를 파악할수있다고 합니다. (스포츠팬들 옷색깔만으로 어떤 파악을 하듯...)
      • 2) Hyperlegder Fabric은 '동시적 제어 메커니즘'을 사용하여 원장을 업데이트 함으로... '분리된 state 벡터'으로 '기업어음'을 유지하는것은~ 공유된 state의 충돌을 크게 줄입니다. 
      • 이런 충돌은 transaction의 재처리 및 application의 복잡성 및 성능에 악영향을 미칩니다.
      • 이런점으로 'state 벡터'의 이 물리적 구조가 아주 중요하고, state를 꼭 분리해야만 하는것 입니다.
• Trust relationships
  
  • 네트워크 참여자로 발행인, 거래인, 평가인 등등에 서로다른 이해관계의 비지니스 파트너들이 있습니다.
  • 그리고 그들간 transaction을 위해서는 서로의 싸인이 필요하겠죠. 이것이 바로 Hyperledger Fabric에서의 '보증정책'에 대응됩니다.
  • '보증정책'은 'state key' 및 chaincode 에 각 적용을 할수있습니다.
  • 그래서 이결과, 어떤 namespace 판단을 통해서~ 어떤 organization이 어떤 권한을 할지? 정할수있게되는것 입니다.

-끝-