[Hyperledger Fabric v1.1] 6. Architecture Reference: Read-Write set semantics

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

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

Read-Write set semantics

 트랜잭션 시뮬레이션 및 읽기 - 쓰기 세트

endorser 에서 트랜잭션을 시뮬레이션하는 동안 트랜잭션에 대해 읽기 - 쓰기 세트가 준비됩니다. 읽기 집합에는 시뮬레이션 중에 트랜잭션이 읽는 고유 키 및 커밋 된 버전의 목록이 포함됩니다. 쓰기 세트에는 고유 키 목록 (읽기 세트에있는 키와 중복 될 수 있음)과 트랜잭션이 작성하는 새 값 목록이 들어 있습니다. 트랜잭션에 의해 수행 된 갱신이 키를 삭제하는 것이면 키의 h 제 표시자가 (새 값 대신에) 설정됩니다.

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

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

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

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

<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 validation and updating world state using read-write set

커미터는 읽기 쓰기 세트의 읽기 세트 부분을 사용하여 영향을받는 키의 버전과 값을 업데이트하기 위해 읽기 쓰기 세트의 쓰기 세트 부분과 트랜잭션의 유효성을 검사합니다.

유효성 검사 단계에서 트랜잭션의 읽기 세트에있는 각 키의 버전이 전 세계 상태의 동일한 키에 대한 버전과 일치 할 경우 트랜잭션이 유효한 것으로 간주됩니다. 이전의 모든 유효한 트랜잭션 (이전의 동일한 트랜잭션 블록)이 커밋 (커밋 - 상태)됩니다. 읽기 - 쓰기 세트에 하나 이상의 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. 앞의 트랜잭션 (T1)에 의해 수정 된 키 k1을 읽음으로써 T2의 유효성 검사에 실패합니다.
3. T3은 읽기를 수행하지 않기 때문에 유효성 검사를 통과합니다. 또한, 세계 상태에서 키의 튜플은 (k2,3, v2 '')로 업데이트되고,
4. 이전 트랜잭션 T1에 의해 수정 된 키 k2를 읽으므로 T4가 유효성 검사에 실패합니다.
5. T5는 앞선 트랜잭션에 의해 수정되지 않은 키 k5를 읽으므로 유효성 검사를 통과합니다.

Note : 여러 읽기 / 쓰기 세트가있는 트랜잭션은 아직 지원되지 않습니다.