空谷に吼える

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

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

このエントリは前・後編のうちの後編です。前編は↓です。

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

前編では「Private Data Collectionの共有先Organizationを新たに追加した場合」について検証したんですが、今回は「もともとPrivate Data Collection共有先であるOrganizationの配下に新たにPeerを追加した場合」に、それまで溜まっていたPrivate Dataは追加されたPeerにも共有されるのか、を検証しました。

結果を書いておくと共有されます(Hyperledger Fabric v1.4.2での検証結果)。

検証

検証環境は前編での手順後のものを引き続き使います。なので前提および手順の意味の理解のために必ず前編を先に読んでください

新規Peerノードを追加で構成

検証対象のPrivate Data Collectionの共有先メンバーであるnw3founderに新たにPeerノードを追加で構成します。Collection共有先に参加できていることの事前確認として、追加したPeerノードから当該CollectionにPrivate Dataを保存できること、保存したレコードを読み出せることを確認します。

Peerノードの追加、Channelへの参加、ChaincodeのInstall

新しいPeerを追加して…

f:id:gakumura:20200403172940p:plain

できあがったpeer2をtest1のChannelに加えて…

f:id:gakumura:20200403173307p:plain

pbfabcarのChaincodeをInstallします。

f:id:gakumura:20200403173632p:plain

追加したPeerノードでPrivate Dataの保存をテスト:CAR48

nw3founder配下に新たに追加されたpeer2に、Private Data保存の処理を実行させます。今度はnw3founder配下のREST Proxy2に、test1 ChannelでのpdfabcarのChaincodeの呼び出しリクエストを受け取ったときにnw3founderのpeer2に実行させるように設定しています。

f:id:gakumura:20200403174034p:plain

今回はCAR48というIDでレコードの書き込みをリクエストし、Successが返ってきているので保存に成功しています。この時点で新たに追加したpeer2がPrivate Data Collectionの共有先として機能していることはわかりました。

f:id:gakumura:20200403175043p:plain

追加したPeerノードで新たに書き込んだPrivateDataの取得のテスト:CAR48

先ほど新しく書き込んだCAR48のレコードを、nw3founder配下のpeer2で読み出せることを確かめてみます。当然読み出せました。

f:id:gakumura:20200403175418p:plain

また、特に確認するほどのことでもないですが、nw3member1のpeer0でもCAR48がもちろん読み出せました。

f:id:gakumura:20200403175615p:plain

Peerノード追加前に書き込まれたPrivate Dataは、追加されたPeerにも保持されているのか?

では本題に入ります。Peerノード追加前に書き込まれていたCAR12のレコード(前編を参照)は、新たに追加されたnw3founder配下のpeer2で読み出せるのか検証です。

nw3founder配下のpeer2に、CAR12のレコード取得をリクエストしてみると、、、

f:id:gakumura:20200403180244p:plain

Yeah!! 取得できました!!

f:id:gakumura:20200403180342p:plain

「あら、(できるかもと思ってたけど)マジ?ちゃんとpeer2で実行してる?設定ミスってpeer0にリクエストしてない?」と思ったので念のためtest1 ChannelのLedgerを見に行ったところ、ちゃんとpeer2がEndorserになってたのでマジでした。

f:id:gakumura:20200403180829p:plain

推測

どうも新しく追加したPeer(今回で言うとnw3founderのpeer2)は同一Organization配下で既にPrivate Data Collectionの共有先メンバーであるPeer(今回で言うとnw3founderのpeer0とpeer1)から、Private Dataの現在断面をGossipでもらってきてるんじゃないかと推測しています。なんかしら裏付けとなるような手がかりないかな~と思ってpeer2のログを見てみたんですが、それとわかるようなログは出ていませんでした(ログレベルがINFOだったからかも)。

あとはそのCollectionに過去にPurgeされているPrivate Dataがあった場合はどうなるか(現在断面をもらってきてるとしたらPurgeされているPrivate Dataは当然共有されないはず)などもちょっと気になりますが、そのへんは前編後編の検証結果の追試を含めてどなたか試してみていただけるとありがたいです。あるいはソースコードをじっくり読めばこのへんの実装箇所が見つかるかも?

前編と後編併せての所感

というわけで、前編と後編で以下ふたつの検証結果が出ています。

  • 前編:Private Data Collectionの共有先Organizationを新たに追加した場合、新規追加されたOrganization配下のPeerには追加前に溜まっていたPrivate Dataは共有されない
  • 後編:もともとPrivate Data Collection共有先であるOrganizationの配下に新たにPeerを追加した場合、新規追加されたPeerには追加前に溜まっていたPrivate Dataが(恐らく同一Organization配下の既存PeerからGossipで取得することで)共有される

併せて眺めてみると、Organizationという単位で情報共有範囲をコントロールする、つまりコンソーシアムネットワークを前提に組織間で適切にData PrivacyをデザインできるようにするというHyperledger Fabricの設計思想通りの仕様になっているんじゃないでしょうか。

前編にも書いておきましたが、裏付けとなる情報が見つからないので、検証方法をミスっていたりして検証結果が間違いである可能性もあります。ぜひ皆さんもソースコードを読む、追試をするなどし、気づいたことなどあればコメントなどで教えて下さい~~

###追記###

情報提供をいただきまして、前編の内容に以下の追記を行っています。

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にそのように読める記述があるのでたぶんそういう仕様のはず!

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