원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html

  • Private data collection definition
    • 'collection 정의'는 "하나 이상의 collection에 정책" 및 "private-data 보급제어속성" 및 "데이터 제거옵션" 등 입니다.
    • 'collection 정의'는 chaincode의 instantiation시에 channel에 배포 됩니다.
    • CLI를 통하면, 'collection 정의 파일'은 "--collections-config" 플래그으로 전달 되어 집니다.
    • SDK를 통한 방법은, "SDK documentation"를 참고 하세요.
    • 'collection 정의'는 아래와 같은 속성으로 구성 됩니다.
      • name : collection 이름
      • policy : private-data collection의 분산정책은 collection-data를 유지는 peer를 정의합니다. ...
      • requiredPeerCount : ...
      • maxPeerCount : ...
      • blockToLive : ...
      • memberOnlyRead : ...
    • 예) 
      • [ { "name": "collectionMarbles", "policy": "OR('Org1MSP.member', 'Org2MSP.member')", "requiredPeerCount": 0, "maxPeerCount": 3, "blockToLive":1000000, "memberOnlyRead": true },
      • { "name": "collectionMarblePrivateDetails", "policy": "OR('Org1MSP.member')", "requiredPeerCount": 0, "maxPeerCount": 3, "blockToLive":3, "memberOnlyRead": true } ]
  • Private data dissemination
    • private-data는 orderer에게 제출되는 transaction에 포함되지 않기 때문에, channel의 모든 peer에게 분배되는 block에도 포함되지 않느다.
    • 그래서'보증-peer'는 private-data를 지정한 타peer에게 분배하는 중요한 역할이 있다.
    • channel의 collection에 private-data의 가용성을 보장해야하는데, '보증-peer' 에 문제가 생기더라도~
    • 분배를 설정으로써, 'collection 정의'의 maxPeerCount 및 requiredPeerCount 속성으로 제어 합니다.
    • 만약 '보증-peer'가 최소한 requiredPeerCount 만큼 분배를 하지 못하면, client에게 에러를 리턴합니다.
    • 또 서로 승인한 organizatnio간에 private-data 사본을 공유하기 할땐, '보증-peer'가 타 organization의 peer에게 분배를 합니다.
    • transaction이 커밋되기 전까지는, private-data 복사본을 로컬 임시저장소에 저장해둠니다.
    • ('보증-peer'가 아니거나 기타 이유로)승인된 peer가 커밋시 임시저장소에 private-data 복사본을 가지고 있지 않으면, 
    • 해당 peer는 다른 승인된 peer에게 private-data 를 땡겨옵니다. (peer의 core.yaml에 pullRetryThreshold 동안)
    • pullRetryThreshold 사용시 고려사항은 아래와 같습니다.
      • pullRetryThreshold내에 private-data 얻어오면, transaction을 ledger에 커밋하고~ private-data를 별도의 공간에 저장함.
      • pullRetryThreshold내에 private-data 얻어오지 못하면, transaction을 blockchain에 커밋 하기만함.
      • peer가 private-data를 누락하게 되면, 향후의 transactions을 보증할수 없게 됩니다. 
      • 누락된 key에 관한 chaincode 쿼리가 감지되면, 그 결과는 에러이기 때문입니다.
    • 그럼으로 maxPeerCount 및 requiredPeerCount 속성은 private-data의 가용성을 보장하는데 아주 중요합니다.
    • 예를들어, 각각에 '보증-peer'가 커밋에 문제가 생겨도~ 다른 '보증-peer'에서 보장을 해주기 위한 중요한 속성입니다.
  • Referencing collections from chaincode
    • "shim APIs"으로 private-data를 저장하고 조회하게 됩니다.
    • 똑같은 chaincode의 데이터라도, state 나 private-data에 모두 적용할수있습니다.
    • 하지만 private-data경우, chaincode상에서 'collection 이름'을 명시 해줘야 합니다.
    • 예) GetPrivateData(collection,key) , PutPrivateData(collection,key,value)
    • How to pass private data in a chaincode proposal
      • chaincode proposal은 blockchain에 저장되기 때문에, private-data을 거기에 포함시키면 안됩니다.
      • chaincode proposal에는 'transient' 라는 필드가 있고, 여기로 안전히 private-data를 전달 할수있습니다.
      • chaincode 에서는 'transient' 필드를 "GetTransient() API" 호출을 통해 찾을 수 있습니다.
      • 참고로, 'transient' 필드는 channel transaction에도 배제되니 안전합니다.
    • Access control for private data
      • v1.3 까지만 해도, collection membership기반의 private-data 접근제어는 peer에게만 적용 되었습니다.
      • chaincode 제출자에 organization기반의 접근제어는 chaincode 로직으로 적용 해야 했습니다.
      • v1.4 에 와서는, collection 설정옵션 'memberOnlyRead'으로~ chaincode 제출자에 organization기반의 접근제어를 적용 할 수 있게 되었습니다.
      • collection 설정옵션은 앞에서 많이 설명했습니다.
    • Querying Private Data
      • private-data collection의 일반적인 channel 데이터는 "shim APIs"으로 쿼리할수있습니다.
        • 예 : GetPrivateDataByRange(collection, startKey, endKey string)
        • 예 : GetPrivateDataByPartialCompositeKey(collection, objectType string, keys []string)
      • "CouchDB" 이나 "JSON 쿼리"도 "shim APIs"으로 전달할수있습니다.
        • 예 : GetPrivateDataQueryResult(collection, query string)
      • 제약사항
        • range쿼리, rich쿼리 등에 앞서 설명한 "private-data 분배"에 따른 데이터 누락이 발생할수있습니다.
        • ...
    • Using Indexes with collections
      • (CouchDB의 인덱스 처럼) private-data collection의 인덱스도 "META-INF/statedb/couchdb/collections/<collection_name>/indexes" 라는 경로에 패키징 됩니다.
  • Considerations when using private data
    • Private data purging
      • private-data는 peer에서 정기적으로 폐기처리 합니다. 앞서 보았던, blockToLive 속성을 참고하면 됩니다.
      • 또한 peer는 커밋하기 전에 private-data를 로컬 임시저장소에 저장합니다. 이 데이터는 transaction 커밋시, 자동폐기 됩니다.
      • 그런데 transaction이 제출되지 않아, 커밋되지 않으면~ 해당 private-data는 계속 남아있게 됩니다. 
      • 이런 임시저장소의 데이터들은 peer의 transientstoreMaxBlockRetention 속성을 지정해서 폐기되도록 할 수 있습니다.
    • Updating a collection definition
      • 기존 collection을 재정의 하거나 새로운 collection을 추가하려면, chaincode를 새 버젼으로 업그래이드 하면 됩니다.
      • 새로운 collection 설정을 chaincode 업그래이드 transaction에 전달하는것 입니다.
      • 예를들면, "--collections-config" 플래그으로 CLI를 사용하는것 입니다.
      • collection 설정에는 기존의 내용도 포합되어야 합니다.
      • ...
      • collection 은 제거할수없는 blockchain에 private-data의 hash값이 있을수있어서, 삭제할수없습니다.
    • Private data reconciliation
      • v1.4에 와서, 기존의 collection에 추가된 organization의 peer는 이전에 커밋된 private-data를 가져올수있습니다.
      • 바로 private-data "reconciliation"은 (네트워크 장애누락 등) 아직 private-data 덜 받은 peer에게 적용됩니다.
      • "private-data 재조정"은 reconciliationEnabled 및 reconcileSleepInterval 속성으로 주기적으로 할 수 있습니다.
      • 이러면 peer는 정기적으로 private-data를 해당 collection의 다른 member peer로부터 가져옵니다.

-끝-

'hyperledger > fabDoc.Arch-Ref' 카테고리의 다른 글

11) Gossip data dissemination protocol  (0) 2019.08.18
10) Read-Write set semantics  (0) 2019.08.18
8) Peer channel-based event services  (0) 2019.08.18
6) Channels  (0) 2019.08.18
5) Service Discovery  (0) 2019.08.18

+ Recent posts