空谷に吼える

ブロックチェーン/DLTまわりのなにかしらを書いていく所存

Private Data Collectionの新規共有先として追加されたOrg配下のPeerにはそれまでに溜まっていたPrivate Dataレコードも共有されるのか検証してみた

###追記###

情報提供をいただきました。v1.4で追加されたreconciliationEnabledのフラグをTrueに設定すると、新規共有先として追加されたOrg配下のPeerにも既存Private Dataレコードが共有されるようになる模様です。

わたし自身では実機で検証できていないですが、(ドキュメント)https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html?highlight=reconciliationenabled#private-data-reconciliationにそのように読める記述があるのでたぶんそういう仕様のはず!

###追記ここまで###

↓のついーとで述べている疑問がタイトルのやつなんですが、特にリプライで情報が寄せられなかった&ググってみてもわかんなかったので検証しました。結論を書いておくと、共有されないです(Hyperledger Fabric v1.4.2での検証結果)。

検証

楽をするためにOracle Blockchain Platform(OBP)を使って検証していきます。なお、この検証時のOBPのベースとなっているHyperledger Fabric(HLF)のバージョンはv1.4.2です。素のHLFを使っても(少なくともHLFバージョンが同じであれば)同じ結果が得られるはずです。

  • 検証環境は「nw3founder」と「nw3member1」というふたつのOrganizationから成るFabricネットワークです。
  • それぞれのOrganizationはPeer0、Peer1のふたつのPeerを持っています(都合4つのPeerが存在しています)。
  • 両Organization、およびすべてのPeerが「test1」のChannelに参加/所属しています。
  • 検証にあたって使ったPrivate Dataを用いるChaincodeは以下novkovskiiさんの記事にある、改造版fabcar.goをそのまま使っています。 qiita.com

片方のOrgだけでPrivate Dataを保持している状態を構成

ひとまず片方のOrganizationの配下のPeerだけが保持するようにPrivate Data Collectionを構成します。そこにPrivate Dataを保存したうえで、もう一方のOrganization側のPeerでは当該Private Dataが読みだせないことを確認していきます。

ChaincodeのInstantiate

事前にすべてのPeerに検証用Chaincode(pdfabcar)をインストールしてあります。検証用のPrivate Data Collectionの定義を登録しつつ、ChaincodeをInstantiateします。ここで片方のOrganization(nw3founder)側だけにPrivate Data Collectionが保持されるよう、OR('nw3founder.member')とCollectionのPolicyを定義しています。

f:id:gakumura:20200402171158p:plain

なお、ちょっと操作がわかりづらいのですが↑のようにCollection定義入力欄に記入してから「Add New Collection」ボタンを押すことで↓のように反映されます。その後にInstantiateボタン押下しましょう。

f:id:gakumura:20200402175425p:plain

PrivateDataの保存:CAR12

当該Private Data Collection(collectionCars)を持っているはずのnw3founder配下のpeer0に、PrivateData保存の処理を実行(Endorsement)させ、トランザクションとして台帳に反映させていきます。なお検証には直接関係ないですがこの際クライアントはnw3founder配下のIdentityを使っています。

OBP付属のREST Proxyを経由してREST APIから呼び出すことにします。nw3founder配下のREST Proxy1が、test1 ChannelでのpdfabcarのChaincodeの呼び出しリクエストを受け取ったときにnw3founderのpeer0に実行させるように設定しています。

f:id:gakumura:20200402203017p:plain

Postmanから以下のようにREST APIでChaincodeを呼び出しています。CAR12というIDのレコードの書き込みをリクエストし、Successが返ってきているので保存に成功しています。

f:id:gakumura:20200402180224p:plain

ちなみに、OBPのコンソールから当該Channel(test1)のLedgerを見てみても、以下のようにトランザクションがVALIDになっていることが確認できます。なお、このようにPrivateDataに保存するためのデータ(⇨一部のChannel参加者には見られたくないデータ)をふつうの引数としてChaincodeに渡すとトランザクション内容に含まれてブロックチェーンに保存されるため、Channel参加者全員に見えてしまいます。実践ではふつうの引数ではなく、ブロックチェーンに残らないTransientMapで渡すようにしましょう。

f:id:gakumura:20200402180439p:plain

PrivateDataの取得のテスト:CAR12

まずは先ほどcollectionCarsのCollectionに書き込んだCAR12のPrivateDataを、nw3founder配下のpeer0で読み出せるか試してみます。期待通り先ほど保存したデータが取得できました。

f:id:gakumura:20200402203438p:plain

では今度は、Private Data Collectionの共有先ではないはずの、nw3member1配下のpeer0で試してみます。ここではnw3member1配下のREST Proxy 1を経由しています(クライアントはnw3member1配下のIdentityを使っています)。すると"Failed to get state for CAR12"と、レコードの取得に失敗した旨が返ってきました。nw3memberのpeer0からは当該Private Dataは読み出せないはずなので想定どおりです。

f:id:gakumura:20200402204420p:plain

両方のOrgがPrivate Dataを保持している状態に変更

先ほどのPrivate Data Collectionの定義を変更し、両方のOrganization配下のPeerがPrivate Data Collectionを保持するようにします。そのうえで新たにPrivate Dataを保存し、それが両方のOrganization配下のPeerで読み出せることを確認します。

ChaincodeのUpgrade

Private Data Collectionの定義を変更するためにChaincodeをUpgrade(再Instantiate)します。変更点はCollectionのPolicyをOR('nw3founder.member', 'nw3member1.member)にして両方のOrganizationが含まれるようにしていることのみです。

f:id:gakumura:20200402205502p:plain

PrivateDataの保存:CAR24

Private Data Collectionの共有先に加わったはずのnw3member1配下のpeer0にPrivate Data保存の処理を実行させます。今度はCAR24というIDのレコードの書き込みをリクエストし、Successが返ってきているので保存に成功しています。この時点でPrivate Data Collectionの共有先追加自体はできていることがわかりました。

f:id:gakumura:20200402210710p:plain

共有先追加後、新たに書き込んだPrivateDataの取得のテスト:CAR24

新しく書き込んだCAR24のレコードを読み出せるか試してみます。まずはnw3founder配下のpeer0にリクエストを投げたところ、以下のように無事取得できました。

f:id:gakumura:20200402211048p:plain

そしてもちろんnw3member1配下のpeer0でも取得できます。

f:id:gakumura:20200402211208p:plain

共有先追加前に書き込まれたPrivate Dataは、新しい共有先のPeerにも保持されているのか?

というわけで本題に入ります。共有先追加前に書き込んでおいたCAR12のレコードは、nw3member1配下のpeer0で読み出せるのか検証です。先ほどCAR24が読み出せたクエリの条件をCAR12に変えてリクエストしてみると、、、

f:id:gakumura:20200402211606p:plain

Oh…無情の"Failed to get state for CAR12"。。。

f:id:gakumura:20200402211908p:plain

というわけであとからPrivate Data Collectionの共有先のOrganizationを追加した場合、そのCollectionにそれまでに溜まっていたPrivate Dataのレコードは新規追加された共有先のOrganization配下のPeerは共有されないみたいです。なるほどね~~

これが試した結果なんですが、冒頭に書いていた通り、裏付けとなる情報も見つからないし、なんか検証方法をミスっていたりするかもしれないので気づいたことなどあればコメントなどで教えて下さい~~

後編に続く

なお、この検証は続きものになりました。このエントリが前後編のうちの前編にあたり、後編は↓です。前編では「Private Data Collectionの共有先Organizationを新たに追加した場合」について検証したんですが、後編では「もともとPrivate Data Collection共有先であるOrganizationの配下に新たにPeerを追加した場合」に、それまで溜まっていたPrivate Dataは追加されたPeerにも共有されるのか、を検証しました。前後編通しての考察も載せています。

Private Data Collectionの共有先のOrg配下にPeerを追加した場合、そのPeerにはそれまでに溜まっていたPrivate Dataレコードも共有されるのか検証してみた - 空谷に吼える