原文はこちら
出ました！Oracle OpenWorld 2019で初めにアナウンスされ、こちらの私のブログポストでご紹介したBlockchain Tableが、Oracle CloudのDatabase as a ServiceでのOracle Database 20cのPreview Releaseのお知らせで述べられている通り、実際に出てきました。というわけで、Blockchain Tableとはなんなのか、どうして重要なのかについて解説したいと思います。
Blockchain Tableは、Oracle Databaseの中で使える、高い耐タンパ性を備えた永続化オプションを提供する、データベーステーブルの新たな特殊なタイプです。Blockchain TableではINSERTのみを行うオペレーションが行える一方で、UPDATEなどの修正は許可されておらず、削除にも制約があります。耐タンパ性を向上するために、ある行にはその前の行のハッシュが保持されており、これにより改ざんされていないことをユーザーは確認できます。また、オプションとして行の内容についてX.509証明書を利用したPKIベースの電子署名で署名することができ、これらの署名とデータ完全性は検証できるので、確実な否認防止を実現することもできます。
Blockchain Tableを用いることで、ユーザーはアプリケーション透過的に他のユーザーによる偽造、改ざんを防ぐことができます。また、データへの署名および検証により、アプリケーション提供者による内部不正も防ぐことができます（「信頼するが検証もする」）。非中央集権アプリケーションならばOracle Blockchain Platformの非中央集権化された信頼のモデルを活用できる一方で、今日におけるほとんどのアプリケーションは中央集権的な権威（銀行、エスクロー機関、取引所や交換所、行政など）を持っています。Oracle Database内のBlockchain Tableを活用することで、このような中央集権的アプリケーションを、非中央集権モデルへと変更することによる複雑さの増加ナシで、よりセキュアにすることができるのです。これこそがまさにOracle Database 20c Native Blockchain Tableの存在理由です。例を挙げれば、金融取引の履歴、監査証跡、規制対応のコンプライアンスデータ、SOX-404管理対象の金融レコード、訴訟ホールドされたデータ、証拠保全などがあります。Blockchain Tableをこれらに用いることで、アプリケーションをよりセキュアにし、データに耐改ざん性を付与することができます。
上に挙げたような例では、ブロックチェーンネットワークと非中央集権アプリケーションを構築するよりも格段に簡単にBlockchain Tableを使うことができるでしょう。この機能はOracle Databaseの一部として提供されるため、新しい基盤の導入は不要です。このテーブルを既存アプリケーションに透過的に使うこともできますし、開発者たちは既存のアーキテクチャとプログラミングモデルを保ったまま、SQLやPL/SQL、JDBCやその他のやり方でテーブルにアクセスできます。Blockchain Tableはさらに、他のテーブルと組み合わせてトランザクションやクエリを行うことができます。
一般的なデザインパターン
ひとつめのパターンは、変更されないデータ（例えばIoTデバイスから受け取ったデータ、コンプライアンスデータなど）を保持する必要があるアプリケーションの場合です。Blockchain Tableを作成し、こうしたデータを直接保存します。
ふたつめのケースでは、既存のアプリケーションが、通常のデータベーステーブル上での更新についての、耐改ざん性のある監査証跡を保持する必要がある場合です。追加でBlockchain Tableを作成し、既存のテーブルでの更新ごとにBlockchain Tableにレコードをインサートするようにアプリケーションを改修するか、あるいは既存のテーブルにトリガーを追加して更新の都度ストアドプロシージャを呼び出してBlockchain Tableにレコードを追加されるようにするかして、Blockchain Table上に監査証跡を保持するようにします。
分散したブロックチェーンネットワークを使う非中央集権アプリケーションに関わる別のシナリオもありますね。しばしばこうしたアプリケーションでは、電子医療記録（EHR）や画像、法的な合意情報や契約情報などの、大きなサイズのデータを保持する必要があります。分散ネットワーク上ではノード間で多数のメッセージがやり取りされるため、MB級やドキュメントやGB級の画像などは大きなネットワーク負荷につながります。より適切なアプローチとしてレコードのアンカリング（データのハッシュ値を取り、メタデータとともにオンチェーンに保持する）を分散台帳上で行いつつ、実データ内容はオフチェーンのデータストア、例えば耐改ざん性のあるBlockchain Table、に保持する、というものがあります。テーブルの耐改ざん性と、ブロックチェーン上のアンカリングを組み合わせることによって、データの改ざんをより一層難しくできるというわけです。
と、ここまでBlockchain Tableがどうして重要なのかについて説明してきたので、ここからはどうやって使うのかを説明していきましょう。
Blockchain Tableの作成と利用
Oracle Database 20cでは、Blockchain TableのためにDDLと有用な関数を備えた3つのPL/SQLパッケージが変更、追加されています。このあとのハンズオンを実際に試してみたい場合は、Oracle Cloud Database as a Serviceを使って、Databaseインスタンスを立ち上げて、お好みのデータベースクライアント（SQL Developerなど）で接続して実施してください。
新しいDDL
新規追加されたDDLであるCREATE BLOCKCHAIN TABLEによって、Blockchain Tableを作成するとともにいくつかのパラメーターをセットできます。以下の例のように：
CREATE BLOCKCHAIN TABLE bank_ledger (bank varchar2(128), EOD_deposit NUMBER, ...) \
NO DROP UNTIL 31 DAYS IDLE \
NO DELETE LOCKED \
HASHING USING "sha2_512" VERSION "v1“;
NO DROP UNTIL 31 DAYS IDLE \
NO DELETE LOCKED \
HASHING USING "sha2_512" VERSION "v1“;
このリリースでサポートされているデータタイプはNUMBER、VARCHAR2、RAW、JSON、BLOB、CLOB、DATEフォーマットおよび他のスカラータイプである点に留意ください。それ以外のタイプ、LONG、ADTs、TYPE、varray、OBJECTS、ROWID、BFILE、REF、Collectionsなどはサポートされていません。
上の例では3つの句が付与されていることにお気づきでしょう：
- NO DROP [UNTIL n DAYS IDLE]は必須の句です。これは、テーブルをドロップできないようにするか、あるいはテーブルがドロップできるようになるまでに必要となる一定の更新がない期間を設定するものです。nの最小値は16で、これはテーブルが自然と休眠するかもしれない、ほとんどの一般的な休暇期間の長さよりも長いです。ALTER TABLE句によってこのリテンションピリオドを変更することができます。
- NO DELETE [LOCKED] または NO DELETE UNTIL n DAYS AFTER INSERT [LOCKED] は削除ポリシーを管理する句です。真に永続する台帳のような場合のためには行の削除は禁止ができますし、あるいはn日のリテンションピリオド経過後には削除できるようにもできます。この場合もnの最小値は16です。NO DELETE（LOCKEDの有無に関わらず）またはNO DELETE UNTIL ... LOCKEDが指定された場合、この設定はあとから変更できません。LOCKEDを付けずにNO DELETE UNTILが指定された場合にはALTER TABLEでnの値を増やすことはできますが、減らすことはできません。
- HASHING USING "sha2_512" VERSION "v1“ も必須の句で、行のハッシュ計算にSHA2アルゴリズムを512bitの出力長で用いることを指定しています。将来Oracle Golden Gateや論理レプリケーションを用いて新しいDatabaseバージョン上にこのテーブルが複製された場合、新バージョンでは別のハッシュアルゴリズムやデータフォーマットバージョンがデフォルトになっているかもしれないため、確実に適切に複製されるようにこの句の指定を必須としています。
ALTER TABLEについては、Blockchain Tableでは上に挙げたものおよび制約を追加するもの以外にはほとんどの変更が許可されません。
Blockchain Tableの制約
データの変更不能性というブロックチェーンの基礎となる思想はBlockchain Tableというデータベースの実装に生かされています。Blockchain Tableでは、DMLでもダイレクトパスインサート（INSERT AS SELECTやSQL Loader）でもGolden Gate論理レプリケーションでも行を更新することはできません。さらに、以下のこともできません：
- （テーブルにセットされたパラメータ次第で）リテンションピリオド内で、あるいはいつまでも、行の削除
- カラムの追加、ドロップ、リネーム
- パーティションのドロップ
- 行の更新前トリガーのセット
- Blockchain Tableを通常のテーブルに変換（またその逆も）
これらの制約により基礎的な操作からもBlockchain Table上のデータを保護し、また、データベースユーザーにより改ざんや偽造、履歴の書き換えなどを防ぐことができます。
行のチェーン化と署名
行が追加されると、Oracleによってマネージされる隠しカラムを用いて特殊なチェーン化プロセスが実行され、耐改ざん性を確実に実現します。これは、ブロックチェーンが前のブロックの暗号学的ハッシュを現データに含めるというやり方で耐改ざん性を実現していることと同様です。以前のデータが変更されるとハッシュが異なってくるため、現データに格納されているハッシュ値と食い違いを生じます。OracleのBlockchain Tableでは、1）現在の行のユーザーカラムと隠しカラムの「行の内容」（ユーザー署名カラムは除きます） および 2）前の行の隠しハッシュカラム の組み合わせに対してSHA2-512で計算されたハッシュ値が生成されます。行追加の並列処理およびハイパフォーマンスのため、32のチェーンが保持されます。また、RAC構成の場合にはRACインスタンスごとに32チェーンが保持されます。なので、厳密に言うと、「前の」行というのは、現在の行が属するある特定のチェーン上でひとつ少ないシーケンスナンバーを持っている行、ということになります。各カラムポジションごとのメタデータヘッダとcolumn-byte-valueが要素として連結された配列に、「前の」行の隠しハッシュカラムのメタデータとcolumn-byte-valueを連結したものを対象にSHA2-512ハッシュ計算が行われます。
これにより、万一データベース防御をなんらかの手段によりバイパスし、行を変更できたとした場合でさえ、深いレベルでデータを人知れず改ざんされることから保護することができます。ハッシュチェーンの整合性は下記のPL/SQLパッケージの関数で検証することができます。さらに、以下を用いることで管理者レベルでの改ざんからも保護することができます：
- 暗号化およびDatabase Vaultを用いる
- DBAのアクセス権限外にある外部のリポジトリに暗号学的ハッシュを定期的にコピーしておく
ビルトインされた暗号学的ハッシュによる行のチェーン化に加えて、下記のPL/SQLパッケージによりPKI（X.509）証明書を登録しておき、行が追加された際にユーザー署名を付与することができます。これによりユーザーや管理者が他者になりすましたり、あるいは他の誰かが自分になりすましたのだと主張することができなくなる、否認防止の特性をもたせることができます。もちろん、このために秘密鍵のセキュリティは大前提となりますし、誰かの秘密鍵が漏洩した場合に無効化して再発行する機能も必要です。
Blockchain Table PL/SQLパッケージ
PL/SQLでBlockchain Tableを扱うために、様々な関数を備えた3つのデータベースパッケージを提供しています。
DBMS_BLOCKCHAIN_TABLE
- delete_rows()：リテンションピリオド範囲外の行を削除する（将来リリースでdelete_expired_rows()にリネームされます）
- verify_rows()：チェーンの整合性を検証します
- sign_row()：インサート済の行にユーザー署名を格納します
- get_bytes_for_row_hash()：行のSHA2-512ハッシュを計算するための行の内容データフォーマットを返却します
- get_bytes_for_row_signature()：行のハッシュを返却します
DBMS_TABLE_DATA
- get_bytes_for_column()：指定されたカラムの{column-byte-value}を返却します
- get_bytes_for_columns() ：指定された（複数）カラムの{column-byte-value}*配列を返却します
- get_bytes_for_row() ：指定された行のすべてのカラムの{column-byte-value}*配列を返却します
DBMS_USER_CERTS
- add_certificate()： “sys.user_certs$”の辞書テーブルに証明書を登録し、ユニークなGUIDを返却します
- drop_certificate()：“sys.user_certs$”テーブルから（存在していれば）指定された証明書を削除します
Viewを用いたBlockchain Tableの管理
2つのViewセットが事前定義されており、Blockchain Tableとユーザー証明書のメタデータ情報をクエリ、管理するのに役立ちます。
Blockchain Table用には：
- ALL_BLOCKCHAIN_TABLES
- DBA_BLOCKCHAIN_TABLES
- USER_BLOCKCHAIN_TABLES
- CDB_BLOCKCHAIN_TABLES
これらのViewは以下のカラム（名称は省略して記載しているので、フルの名称についてはドキュメントを参照ください）を持っています：SCHEMA_NAME（USER以外のViewに存在）、TABLE_NAME、ROW_RETENTION、ROW_RETENTION_LOCKED、TABLE_INACTIVITY_RETENTION、HASH_ALGORITHM、CON_ID（CDB Viewのみに存在）
ユーザー証明書については、以下のViewが定義されています：
- DBA_CERTIFICATES
- USER_CERTIFICATES
- CDB_CERTIFICATES
これらのViewは以下のカラムを持っています：CERTIFICATE_GUID、USER_NAME、DISTINGUISHED_NAME、CERTIFICATE（BLOB）、CON_ID（CDB Viewのみに存在）
ベストプラクティス
- 各インスタンスの各チェーンごとに、現在ハッシュと対応するシーケンスナンバーをレジャーデータベースの外部に定期的に保存し、チェーンの整合性検証を可能にしておく
- Data Guardを使っている場合には、Max Protectionモードを使うことでレジャーレコードの喪失を防ぐ（プライマリでトランザクションがコミットされる前にスタンバイDBに同期でRedoが転送されコミットされる）
- インサートされた行の、データベースによって生成されたハッシュ値について電子署名の計算を行う（DBMS_BLOCKCHAIN_TABLE.get_bytes_for_row_signature() ）
- ハッシュと署名はデータベースの外部に保存しておき、将来的にそのデータベースが依然信頼に値するかを検証できるようにしておく
Blockchain TableとBlockchain Platformの使い分け
Oracle Database Blockchain Tables | Oracle Blockchain Platform |
|
|
例えば以下のようなユースケース
| Use cases involve
|
準備はできましたか？
新たなNative Blockchain Table機能をこの20c Preview Releaseで触ってみるには？まずOracle Cloudのアカウントを用意して、Oracle Cloud Database as a ServiceでDatabase VMを作成しましょう。そしてお気に入りのデータベースクライアントでデータベースに接続し、CREATE BLOCKCHAIN TABLEしてください（必須の句は忘れずに！）。こんなに簡単です。質問などあれば通常のカスタマーサポート窓口からサポートも受けられますし、パブリックのフォーラムもありますよ。