空谷に吼える

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

Oracle Blockchain Platformのリッチヒストリーデータベースの機能強化

Hyperledger Fabricベースのブロックチェーン基盤であるOracle Blockchain Platformには、独自の機能としてそのブロックチェーン台帳のデータをブロックチェーン外部のOracleデータベースに複製する機能(→リッチヒストリーデータベース機能)が備わっています。

で、このリッチヒストリーデータベース機能について、最近のアップデートで機能強化が入り、ブロックチェーン側から複製できるデータの種類が増え、業務的な観点だけでなく、Chaincodeの開発やらHyperledger Fabricのお勉強の観点からもさらに使い勝手がよくなりました。

さらに、複製先のOracleデータベースのテーブルとして、Blockchain Tableを利用可能になりました。これにより、ブロックチェーン台帳上のデータだけでなく、リッチヒストリーデータベースによって複製されたデータベース上のデータについても、耐改ざん性および証跡性を備えたかたちで保持できることになります。ついでにChannelごとに複製先のデータベース(のインスタンス)を選べるようにもなっています。

このエントリではリッチヒストリーデータベース機能について、また、これら機能強化について紹介していきます。

そもそもOracle Blockchain Platformとは

そもそもOracle Blockchain Platformってなによ?という方は、まずは以下の概要説明のスライドをざっと読むとわかりやすいと思います。なお、以下、記事中のスライド画像は、すべてこの概要説明のスライドからの引用です。

www2.slideshare.net

www2.slideshare.net

リッチヒストリーデータベース機能とは

前述の通り、リッチヒストリーデータベース機能は、ブロックチェーン台帳のデータをOracleデータベース上に複製する機能です。ブロックチェーンが苦手とする複雑な参照処理(集計、分析)をそれらを大得意とするリレーショナルデータベース側で 行えるようにすること、および②ブロックチェーン(からの複製)のデータとその他のシステムのデータとのデータ統合を容易にすることで、より高度なデータ活用を迅速に実現できるようにする、というのがこの機能の主な目的です。

f:id:gakumura:20210112222432p:plain
リッチヒストリーデータベース機能

仕組みとしては、まずHyperledger Fabricの台帳分割単位であるChannelごとにリッチヒストリーデータベースの対象とするかのON/OFFができるようになっています。複製対象としたChannelについてはデータベース側に複数の切り口のテーブルを作成し、それらテーブルにそのChannelのデータを複製していきます。

f:id:gakumura:20210112231518p:plain
対象のHLFチャネルごとにテーブルを作成し複製

この機能は、複製対象のChannelのBlockchain部(に保存されているBlockとその中のTransactions)を過去から最新まで読んでいき、その内容のトランザクションデータを順次データベース側に反映していくような動きになっています。したがって、機能を有効にした時点より以前に発生していたトランザクションデータについてもデータベース側に取り込まれます。また、どこまで複製してきたかのチェックポイントもデータベース上に保持しており、動き出して以降に発生したトランザクションについては差分のみが反映されていきます(いちいちgenesis blockから最新までの全量取ってきたりはしていないので安心してください)。

画像にあるように、以下State、History、Transaction Detailsの3つの切り口のデータがそれぞれのテーブルに格納されます。なお、作成されるテーブルは実はあともうひとつ、Latest Hightテーブルというものがあるんですが、これは上述のどこまで複製してきたかのチェックポイントを保持しているだけのテーブルで、通常気にしなくてよいので省略しています。

State

台帳の(というかHyperledger FabricのLedgerの)World State/State DBと対応するテーブルです。Keyおよび現在のValueから成る行を保持しています。

f:id:gakumura:20210112235416p:plain
Stateテーブル

History

台帳上のあるKeyに対してのValueの変遷という切り口での履歴、およびその際の更新トランザクションを保持しているテーブルです。

f:id:gakumura:20210112235628p:plain
Historyテーブル

過去バージョンの(あるBlock No./Transaction No.時点での)Stateを参照したいなどいった場合に使うことになります。

Transaction Details ←New!!

こちらが機能強化によって追加されたテーブルで、トランザクションの履歴を保持しています。HistoryのほうがStateの過去~現在バージョンという切り口の履歴だったのに対し、こちらは単純にそのChannle上で発生したトランザクションの記録を持っています。Hyperledger FabricのLedgerのうち、Blockchain部にあるTransactionsのデータをほぼそのまま取り込んだものと考えるとわかりやすいです。

f:id:gakumura:20210113000709p:plain
Transaction Detailsテーブル①

f:id:gakumura:20210113000738p:plain
Transaction Detailsテーブル②

トランザクションの発行者、Endorserの識別情報(証明書情報)が保持されている他、Chaincodeに渡した入力値とChaincodeからの返却値など、Chaincodeの開発、テストに際しとても有用な情報も利用可能です。また、Hyperledger Fabricの整合性保護のための独特なデータ項目であるRWSetが視えるようになっているのが、開発時に問題が発生した際のデバッグはもちろん、Hyperledger Fabricのお勉強観点でも非常に有用なポイントです。

リッチヒストリーデータベース in Blockchain Tables ←New!!

リッチヒストリーデータベース機能についてここまで説明してきましたが、機能強化により複製先のOracleデータベースのテーブルとしてBlockchain Tableを利用することができるようになっています。Blockchain Tableとはなにかについては↓のエントリで紹介しているので参照ください。

gakumura.hatenablog.com

複製先に通常のテーブルを使っていた場合には、データベース上の複製データは更新(UPDATE)や削除(DELETE)に特に制約がありません。そのため、データベース上の複製データを単体でなんらかの証跡として扱うことは難しく、そのような用途には複製元のブロックチェーン台帳上のデータを参照する必要があると考えられます。

しかし複製先にBlockchain Tableを用いることで、データベース上の複製データにも複製されてきて以降、更新や削除をできないという意味での耐改ざん性を持たせられ、また、更新や削除されていないということを(ハッシュチェーンの検証により)証明可能になります。これにより、ブロックチェーン台帳上のデータを参照せずとも、データベース上の複製データを(少なくともその組織内部および監査者にとっては)単体で信頼に足る情報、証跡として扱うことが可能になります。

設定方法

リッチヒストリーデータベースの設定箇所に以下のようなBlockchain Tableを使うかどうか?のセクションが追加されています。

f:id:gakumura:20210227172241p:plain
Blockchain Tableを利用する設定

これを有効にすることで、リッチヒストリーデータベース機能が複製先のデータベースで前述のテーブルを自動的に作成する際に、通常のテーブルではなくBlockchain Tableとして作成するようになります。この設定はChannelごとに指定が可能です。なお、Blockchain Tableに対応していないバージョンのデータベースに対して有効にするともちろんエラーが起きるので注意しましょう。

なお、Table Retention Daysはテーブルに何日間新しい行のINSERTがない場合にテーブルを削除(DROP)できるようにするかの設定で、0または15以上が指定可能です。0を指定すると期間に依らずずっと削除不可になります。Row Retention Daysは行がINSERTされたあと何日後に削除(DELETE)できるようにするかの設定です。こちらも0または15以上が指定可能で、0を指定するとずっと削除不可になります。

対象のテーブル

有効にした場合、前述のリッチヒストリーデータベース機能が作成し複製データを格納していくState、History、Transaction Details(とLatest Height)のテーブルのうち、HistoryとTransaction DetailsのみがBlockchain Tableを利用します。これはState(およびLatest Height)テーブルはリッチヒストリーデータベース機能によりINSERT以降、行の更新が入るからですね。一方、HistoryとTransaction Detailsは履歴を追記していくタイプのテーブルなので、行われるのはINSERTのみなためBlockchain Tableに対応可能というわけです。

Channelごとの接続先データベース選択 ←New!!

上述のBlockchain Table対応と同時に、Channelごとに接続先データベースを設定できるようにもなりました。これまではインスタンス全体で単一のデータベースに対してしかリッチヒストリーデータベース機能を構成できなかったんですが、この機能強化により、Channelごとに別々のデータベースに対してデータを複製することができるようになりました。

例えば、Channel Aは分析用のデータベースX上の通常のテーブルにデータを複製し、Channel Bは監査証跡保存用のデータベースY上のBlockchain Tableにデータを複製し…といったようなことも可能になっています。

まとめと次回予告

というわけでOracle Blockchain Platformの付加価値のひとつ、ちょう便利かつパワフルなリッチヒストリーデータベース機能をかんたんに紹介しました。

次回はリッチヒストリーデータベース機能を使うと実際こんな感じの情報がデータベース上で視えて面白い&わかりやすいよ、というエントリを予定しています。

その他参考情報