[Hyperledger Fabric v1.0] 5. ARCHITECTURE(아키텍트): Read-Write set semantics(읽기-쓰기 의미 설정)

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release/readwrite.html

 Read-Write set semantics(읽기-쓰기 의미 설정)

이 문서는 읽기 - 쓰기 의미 설정에 관한 현재 구현의 세부 사항을 설명합니다.

Transaction simulation and read-write set(트랜잭션 시뮬레이션 및 읽기 - 쓰기 설정)

endorser에서 트랜잭션을 시뮬레이션하는 동안 트랜잭션에 대해 읽기 - 쓰기 세트가 준비됩니다. read set 에는 시뮬레이션 중에 트랜잭션이 읽는 고유 키 및 커밋 된 버전의 목록이 포함됩니다. write set에는 고유 키 목록 (읽기 세트에있는 키와 겹칠 수 있음)과 트랜잭션이 작성하는 새 값 목록이 포함됩니다. 트랜잭션에 의해 수행 업데이트가 키를 삭제할 경우 삭제 마커는 키 (새로운 값의 장소에) 설정되어 있습니다.

또한 트랜잭션이 키에 여러 번 값을 쓰는 경우 마지막으로 기록 된 값만 유지됩니다. 또한 트랜잭션이 키에 대한 값을 읽는 경우 트랜잭션이 읽기 전에 해당 값을 갱신하더라도 커밋 된 상태의 값이 반환됩니다. 즉, 읽기 - 쓰 기 의미론은 지원되지 않습니다.

앞에서 언급했듯이 키의 버전은 읽기 세트에만 기록됩니다. 쓰기 세트에는 고유 키 목록과 트랜잭션에 의해 설정된 최신 값이 포함됩니다.

버전을 구현하기위한 다양한 계획이있을 수 있습니다. 버전 관리 체계에 대한 최소한의 요구 사항은 주어진 키에 대해 반복되지 않는 식별자를 생성하는 것입니다. 예를 들어, 버전에 대해 단조롭게 증가하는 숫자를 사용하면 이러한 스키마 중 하나 일 수 있습니다. 현재 구현에서는 커밋 트랜잭션의 높이가 트랜잭션에 의해 수정 된 모든 키의 최신 버전으로 사용되는 블록 체인 높이 기반 버전 관리 체계를 사용합니다. 이 체계에서 트랜잭션의 높이는 튜플로 표시됩니다 (txNumber는 블록 내의 트랜잭션 높이입니다). 이 방법은 증분 번호 체계보다 많은 장점을 가지고 있습니다. 주로, 술어 b, 트랜잭션 시뮬레이션 및 유효성 검사와 같은 다른 구성 요소를 사용하여 효율적인 설계 선택을 할 수 있습니다.

다음은 가상 트랜잭션의 시뮬레이션으로 준비된 읽기 쓰기 세트의 예입니다. 단순화를 위해 그림에서 버전을 나타내는 데 필요한 증분 숫자를 사용합니다.

<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>

또한 트랜잭션이 시뮬레이션 중에 범위 쿼리를 수행하면 범위 쿼리와 그 결과가  query-info로 읽기 / 쓰기 세트에 추가됩니다.

Transaction validation and updating world state using read-write set(읽기 및 쓰기 설정을 사용하여 트랜잭션 유효성 검사 및 세계 상태 업데이트)

committer는 읽기 쓰기 세트의 읽기 세트 부분을 사용하여 트랜잭션의 유효성을 확인하고 읽기 및 쓰기 세트의 쓰기 세트 부분을 검사하여 영향을받는 키의 버전 및 값을 업데이트합니다.

유효성 검사 단계에서 트랜잭션의 읽기 세트에 있는 각 키의 버전이 월드 상태의 동일한 키에 대한 버전과 일치 할 경우, 트랜잭션이 valid한 것으로 간주됩니다. 이전의 valid 모든 트랜잭션 (동일한 트랜잭션 블록)이 커밋 (커밋 - 상태)됩니다. 읽기 - 쓰기 세트에 하나 이상의 query-info도 포함되어 있으면 추가 검증이 수행됩니다.

이 추가 검증은 쿼리 정보에 캡처 된 결과의 수퍼 범위 (즉, 범위의 합집합)에 키가 삽입 / 삭제 / 업데이트되지 않았 음을 보장해야합니다. 즉, 커밋 된 상태의 유효성 검사 중에 범위 쿼리 (시뮬레이션 중에 수행 된 트랜잭션)를 다시 실행하면 시뮬레이션시 트랜잭션이 관찰 한 것과 동일한 결과가 나타납니다. 이 확인은 트랜잭션이 커밋 중에 팬텀 항목을 관찰하면 트랜잭션이 유효하지 않은 것으로 표시되어야 함을 보장합니다. 이 팬텀 보호는 범위 쿼리 (즉, 체인 코드의 GetStateByRange 함수)로 제한되며 다른 쿼리 (즉, 체인 코드의 GetQueryResult 함수)에는 아직 구현되지 않았습니다. 다른 쿼리는 유령의 위험이 있으므로 응용 프로그램이 시뮬레이션과 유효성 검사 / 커밋 시간 사이에 결과 집합의 안정성을 보장 할 수없는 경우 주문에 제출되지 않은 읽기 전용 트랜잭션에서만 사용해야합니다.

트랜잭션이 유효성 검사를 통과하면 커미터는 쓰기 상태를 사용하여 세계 상태를 업데이트합니다. 업데이트 단계에서 쓰기 세트에있는 각 키의 경우 동일한 키에 대한 월드 상태의 값이 쓰기 세트에 지정된 값으로 설정됩니다. 또한, 세계 상태의 키의 버전이 최신 버전을 반영하도록 변경됩니다.

Example simulation and validation(시뮬레이션 및 검증의 예)

이 절에서는 예제 시나리오를 통한 의미 이해에 도움이 됩니다. 이 예제의 목적을 위해, 세계 상태에서 키 k의 존재는 튜플 (k,ver,val)로 표현되며, 여기서 ver은 값을 val로 갖는 키 k의 최신 버전입니다.

이제 세계 상태의 동일한 스냅 샷에서 시뮬레이션 된 다섯 개의 트랜잭션 T1, T2, T3, T4, T5를 고려해보십시오. 다음 스 니펫은 트랜잭션이 시뮬레이션되는 세계 상태의 스냅 샷과 이러한 각 트랜잭션이 수행하는 읽기 및 쓰기 활동의 순서를 보여줍니다.

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, .., T5 순서로 정렬되어 있다고 가정합니다 (단일 블록 또는 다른 블록에 포함될 수 있음)

1. T1은 읽기를 수행하지 않기 때문에 유효성 검사를 통과합니다. 또한, 월드 상태의 키 k1과 k2 의 튜플은 (k1,2,v1'), (k2,2,v2')로 업데이트된다.
2. T2는 선행 트랜잭션(T1)에 의해 수정 된 키 k1을 읽음으로써 검증에 실패합니다.
3. T3 passes the validation because it does not perform a read. Further the tuple of the key, k2, in the world state is updated to (k2,3,v2'')
4. T3는 읽기를 수행하지 않기 때문에 유효성 검사를 통과합니다.  또한 키의 튜플은, k2는 세계 상태 (k2,3,v2'')에 업데이트됩니다.
5. 이전 트랜잭션T1에 의해 수정 된 키 k2를 읽으므로 T4가 유효성 검사에 실패합니다.
6. T5 passes validation because it reads a key, k5, which was not modified by any of the preceding transactions
7. T5는 이전 트랜잭션 중 하나에서 수정되지 않은 키 k5를 읽으므로 유효성 검사를 통과합니다.

※ 다중 읽기 - 쓰기 세트가 있는 트랜잭션은 아직 지원되지 않습니다.