空谷に吼える

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

Hyperledger Fabricの新LTSバージョンであるv2.5がリリースされたので変更点をまとめてみる

Hyperledger Fabric ブロックチェーン

2023/3/31付で新しいLTS（Long Time Support）バージョンであるHyperledger Fabric v2.5がリリースされました。🎉🎉🎉めでたい🎉🎉🎉ですね。ひとつ前のLTS版であるv2.2は2020/7/6付リリースだったのでおおよそ2年半ぶりくらいのLTSリリースということになります。

リリースノートはこちら、ドキュメントも既に公開されておりWhat's newはこちらにあります。なおv2.2系からv2.5系へのアップグレードはスムーズにできるそうです。

A simple in-place upgrade from the prior LTS (Fabric v2.2.x) release is possible.

先行してv2.5での性能ベンチマーク結果も公開されています。わりと現実的なセットアップで約1500～3000TPSの結果が出ており、やるじゃんという印象。ただし前バージョンでの比較情報はないので速くなっているかというのはわかりません。また、性能面についてはドキュメントにもパフォーマンスチューニングで気にすべきポイントまとめがv2.5から新たに追加されています。

で、このポストでは↑のWhat's newに記載されているv2.0～v2.5での機能変更についてまとめておきます。ただし執筆時点でv2.2までしか実際には触れていないので基本的に情報はドキュメントやリリースノートなどの机上ベースです。今後実際に触ってみてなにか気づいたことがあれば更新しておきます。

なおv1.x→v2.0での変更点については以下にまとめているので気になる方はどうぞ。

gakumura.hatenablog.com

変更点

【v2.5~】Private Dataのヒストリーを含めた削除（Purge）操作が可能に

「Private DataはこれまでもDeleteはできたけど、Private DataのHistoryも含めてPurgeできるようになったよ」「そのPrivate DataにアクセスできるすべてのPeerから完全にPrivate Dataを削除する必要がある場合は、DelPrivateDataのChaincode APIではなくPurgePrivateDataのAPIを使ってね」 とのことです。

…なんですが、以前のバージョンのドキュメントでもPrivate DataはPurgeできるという記載があります。

Purging private data

For very sensitive data, even the parties sharing the private data might want — or might be required by government regulations — to periodically “purge” the data on their peers, leaving behind a hash of the data on the blockchain to serve as immutable evidence of the private data.

In some of these cases, the private data only needs to exist on the peer’s private database until it can be replicated into a database external to the peer’s blockchain. The data might also only need to exist on the peers until a chaincode business process is done with it (trade settled, contract fulfilled, etc).

To support these use cases, private data can be purged if it has not been modified for a configurable number of blocks. Purged private data cannot be queried from chaincode, and is not available to other requesting peers.

で、v2.5のドキュメントには以下の記載が追加されていました。

However, when private data is simply deleted from state, the history of the private data remains in the peer’s private database so that it can be returned in block events and returned to other peers that are catching up to the current block height.

詳細はコードを読みこまなければならずで未確認ですが、↓ってことかな？

  • 以前のバージョンでも、一定Block後に自動で消える設定の場合の削除ではPurge（Historyも含めて削除）されていた
  • 一方で、DelPrivateDataのChaincode APIを使い手動で削除する場合には（少なくとも即座に）Historyまで含めて消されるわけではなく、Eventや現在Block Heightに追いついていないPeerのためにHistoryは残っていた
  • v2.5で追加されたPurgePrivateDataのChaincode APIを使うと、手動で削除する場合もHistoryまで含めて削除される

ちょっと不明瞭な部分がありますが、いずれにせよ今後はPrivate Dataを手動で削除するときには基本的にDelPrivateDataではなくPurgePrivateDataを使う、としたほうがわかりやすそうです。

【v2.5~】バイナリとDockerイメージのマルチアーキテクチャサポート

  • バイナリとDockerイメージがamd64およびarm64をサポート
  • 最大のポータビリティのため、リリースバイナリは静的リンクされるように
  • 動的リンクされるバイナリを使うDockerイメージは、ベースイメージがAlpineからUbuntuに

とのことです。

【v2.4~】PeerのFabric Gatewayサービスと新しいモデルのクライアントSDKの追加

開発者観点で言うとこれが一番大きい（嬉しい）変更でしょう。

Fabric GatewayというサービスがPeerノードの一部として新たに提供されるようになっています。このFabric Gatewayの追加により、これまでクライアントSDK、すなわちクライアントアプリケーション側で行っていたトランザクション周りのあれやこれやをPeer側に担わせることができるようになりました。

  • 信頼するPeer（通常、自身のOrganization配下のいずれかのPeer）にトランザクションの実行を委任することで、Peer側でEndorsement収集とOrdering Serviceへの送信をやってくれる
  • これによりクライアントアプリケーションから他OrgのPeerやOrdering Serviceへの接続は不要に
  • あるトランザクションにどのようなEndorsementが必要かもFabric Gatewayがインテリジェントに判断して対応してくれる
    • chaincode-level、private data collection、state-basedのEndorsement Policyを利用している場合もOK

↑のFabric Gatewayの便利なサービスに対応した新たなモデルのクライアントSDKとして、Hyperledger Fabric Gateway Client SDKもGo、Node.js、Java版がそれぞれリリースされています。以前の高レベルクライアントAPIのリリースにもまして、クライアントアプリケーションの実装がより楽になりそうです。Gateway Client SDKの詳細については↓から参照できます。

hyperledger.github.io

【v2.4~】PeerノードのChannelからの離脱（Unjoin）が可能に

ChannelからPeerノードを離脱させることができるようになりました。離脱とともにStateやBlockなどのリソースが削除されます。

他のPeerとの役割分担の変更、整理をしたいなどといった場面であるPeerをあるChannelから離脱させるといったことが可能になります。テストや開発環境でも積もったChannelのお掃除ができて便利ですね。

【v2.4~】Package IDを確認するコマンドが追加

Chaincodeのパッケージを一意に識別するPackage IDを、Peerにインストールしなくてもpeer lifecycle chaincode calculatepackageidのコマンドで確認できるようになったそうです。「このパッケージインストール済だっけ…？」「このパッケージとあのパッケージは中身同一なんだっけ…？」とかのときに使うっぽい。

【v2.3~】OrdererのChannel管理にSystem Channelが不要に

以前のバージョンでは新規のネットワークを構成するのに最初にSystem Channelという役割を持ったChannelを作り、そのChannelにはすべてのOrdererが参加していなければならなかったんですが、そのSystem Channelが不要になったとのことです。Ordererはシンプルに自身がOrderingを担当するChannelにだけ参加すれば良いことになりました。

プライバシーとスケーラビリティ上のメリット、運用のシンプル化といったメリットがあります。地味ですが、コンソーシアムの在り方によってはここでのプライバシー上のメリットが重要になることもありそうです。

【v2.3~】台帳のスナップショット（Ledger Snapshot）機能の追加

あるPeerの持っているあるChannelのStateのスナップショットを取り、そのスナップショットをベースに新しいPeerをそのChannelにJoinさせられるようになりました。この場合、新しいPeerのほうではそのChannelのBlockをgenesisから最新まで処理して現在Stateを得るのではなく、スナップショット時点のStateをスタート地点とし、したがって現在Stateまで早く追いつけます。

  • 新しいPeerがChannelに加わるのに必要な時間が大幅に削減できる
  • 新しいPeerはスナップショットまでのBlockを持たないので、ストレージが節約できる

といったメリットがあります。

ストレージの節約効果に関してはLedger Proningの変形みたいな感じですね。前述のPeerのChannel離脱と合わせて使えば、離脱→スナップショットからの再参加で古いBlockを捨ててストレージリソースを節約する、といった使い方ができそう。

一方で、過去Blockを持っていないPeerではそれが必要となるHistory系のクエリは使えなくなりますね。留意点や制約の詳細についてはこちらのドキュメントに記載があります。