10) Read-Write set semantics

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

• Transaction simulation and read-write set
  
  • '보증-peer'가 transaction을 처리할때, 'read-write set' 기반으로 처리한다.
  • 'read set'은 "유니크 key" 와 "해당 version"을 가지고 있다.
  • 'write set'은 "유니크 key" 와 "새 value"를 가지고 있다. (key 삭제엔, value로 'delete marker'를 함)
  • ;
  • 만약 transaction이 특정 key에 여러번 value를 쓰면, 마지막 값으로 유지될것 입니다.
  • transaction이 특정 key를 읽으면, 그전에 커밋된 값이 리턴될것 입니다.
  • 즉, write 하는 값을 read 하는것은 지원안되는거 같습니다.
  • 다시한번 정리하자면, 'read set'에는 key와 그 version이 있고~ 'write set'에는 key와 최종value가 있습니다.
  • ;
  • 버젼을 하는 식에는 다양한 스키마가 있습니다.
  • 'versioning scheme'는 최소한 주어진 key에 관해서, 중복적이지 않은 식별자로 해야 합니다.
  • 예를들면, 단순 증가값으로 versioning을 하는것도 한 방법 입니다.
  • 지금의 방식은 blockchain의 height를 기반으로 하는 'versioning scheme'를 사용하고 있습니다.
  • 커밋하는 transaction의 height가 해당 key의 최종 version으로 사용되어지는것 입니다.
  • 이런 현 스키마에서는 transaction의 height는 tuple로 표현 됩니다. (txNumber) (block안 transaction의 height)
  • 이 스키마는 "단순 증가값 스키마"보다 장점이 많은데, 주로 다른 컴포넌트와 효율적인 설계가 되도록 하게 합니다.
  • ;
  • 아래와 같은 'read-write set'을 참고하세요. (보기쉽게 "단순 증가값 스키마"를 예로 함)
    • <TxReadWriteSet><NsReadWriteSet name="chaincode1">
      • <read-set>
        • <read key="K1", version="1">
        • <read key="K2", version="1">
      • </read-set>
      • <write-set>
        • <write key="K1", value="V1">
        • <write key="K3", value="V2">
        • <write key="K4", isDelete="true">
      • </write-set>
    • </NsReadWriteSet> <TxReadWriteSet>
  • 추가적으로, 만약 transaction이 range쿼리를 한다면~ 그 결과는 'query-info' 라고 추가됩니다.
• Transaction validation and updating world state using read-write set
  
  • 'committer' 는 transaction의 검증을 위해서 'read set' 을 확인하고, value와version 업데이트로 'write set' 을 사용합니다.
  • ;
  • 검증단계에서, 각각에 key의 version이 'read set' 과 'world state' 가 일치하면~ 해당 transaction은 유효하다 판단합니다.
  • 왜냐하면, 모든 이전의 유효한 transaction이 커밋되었을 것으로 가정하기 떄문입니다.
  • 추가적인 검증은 'read-write set'에 'query-info' 가 추가되어 있을경우 이루어 지게됩니다.
  • ;
  • 추가적인 검증은 'query-info' 에 추가된 상위범위의 결과에 inserted/deleted/updated 된 key가 없는지? 확인해야 합니다.
  • 반대로 말하자면, range쿼리를 재실행 하여도 똑같은 결과가 나와야 되는것 입니다.
  • 즉, transaction에서 '정체모를 item'이 나오는지 확인해서~ 무효하다 판단을 할 수 있어야 한다는것 입니다.
  • 이런 '정체모를 item' 제약은 range쿼리에서 제한되고, 아직 다른 쿼리에는 아직 구현되지 않았습니다.
    • 예 : GetStateByRange , 예 : GetQueryResult 
  • 다른 쿼이에서는 이렇게 '정체모를 item' 위험이 있음으로, read-only transaction을 사용해야 합니다.
  • 즉, application에서 "simulation" 과 "검증/커밋" 사이에 안적적인 결과를 보장 할 수 없기 때문입니다.
  • ;
  • transaction이 검증을 통과하면, committer는 'world state'를 업데이트 하기위해~ 'write set' 을 사용합니다.
  • 업데이트 단계에서, 'write set'의 각각에 ket에 value가 'world state'에 반영 됩니다. 
  • 그러면서 물론 해당 version도 바뀌게 됩니다.
• Example simulation and validation
  
  • 예제로써 5개의 transaction이 있고, 각각의 transaction이 처리되면서~ world state의 변화를 보면 됩니다.
    • World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5)
    • T1 -> Write(k1, v1'), Write(k2, v2')
    • T2 -> Read(k1), Write(k3, v3')
    • T3 -> Write(k2, v2'')
    • T4 -> Write(k2, v2'''), read(k2)
    • T5 -> Write(k6, v6'), read(k5)
  • T1은 검증통과, world state 를 (k1,2,v1'), (k2,2,v2') 으로 업데이트. 
  • T2은 검증실패. 왜냐하면 Read(k1)이 수정되었기 때문.
  • T3은 검증통과, world state 를 (k2,3,v2'') 으로 업데이트. 
  • T4은 검증실패. 왜냐하면 Read(k2)이 수정되었기 때문.
  • T5은 검증통과. 왜냐하면 Read(k5)이 수정되지 않았기 때문.

-끝-