導入
現在大学で、コンピュータサイエンスの勉強を行っていて、特に、改ざんに対処するデータベースに興味を持っています。
ひとえに、改ざんに対処するデータベースと言っても、BFTデータベースや、BFDデータベース、台帳型データベースなど、様々な種類があります。
- BFTデータベースとは、Byzantine Fault Torelanceデータベースの略で、ビザンチン故障に耐性があるデータベースです。
- BFDデータベースは、Byzantine Fault Detectionデータベースの略で、ビザンチン故障を検知するデータベースです。
- 台帳型データベースは、ビザンチン故障を限定的に検知するデータベースです。
以下の表で具体例と共にまとめています。
種類 | 具体例 |
---|---|
BFTデータベース | HRDB1 [SOSP'07], Byzantium2 [EuroSys'11], Hyperledger Fabric3 [EuroSys'17], Basil4 [SOSP'21], etc. |
BFDデータベース | Scalar DL5 [VLDB'22] |
台帳型データベース | Oracle Blockchain Table, Amazon QLDB, LedgerDB6 [VLDB'20], etc. |
改ざんに対処するデータベースへの理解を深めるため、台帳型データベースのOracle Blockchain Tableと、Amazon QLDBを調査したので、本記事で概要、考察、及び比較を紹介したいと思います。
この二つのデータベースを選んだ理由としては、大手ベンダーから製品が出ていて、製品に関する詳細な資料が存在し、そして安価または無料で試すことができるため実際にデータベースを操作しながら、理解を深めることができると思ったからです。
Oracle Blockchain Table
概要
まずOracle Blockchain Tableに関してOracleによる紹介を引用します。
ブロックチェーン表は、挿入操作のみできる追加専用の表です。行の削除は、禁止または時間に基づいて制限されます。ブロックチェーン表内の行は、特殊なシーケンシングおよび連鎖のアルゴリズムによって改ざん防止状態になっています。ユーザーは、行が改ざんされていないことを確認できます。行メタデータの一部であるハッシュ値は、行の連鎖および検証に使用されます。
簡単に言いますと、Oracle Blockchain Tableは、データベースにはデータを追加することのみ許されていて、データベース内のデータを更新したり、削除することが出来ません。そしてデータベース内では行単位でハッシュチェーンが構成されており、それらを用いてデータが改ざんされていないかどうかを検証することが出来ます。
問い合わせ言語
問い合わせ言語はSQLです。ただし更新、削除などの操作に一部制限があります。
もしユーザが行の更新を行うアプリケーションを開発したい場合、例えば、行に行のバージョンに対応する列を付与し、その列の値を更新するごとに1ずつ増やしていくというような追加作業が必要になります。
データモデル
データモデルは、通常のOracleデータベース同様、リレーション型です。
改ざん検知について
PL/SQLまたはAPIを用いて、タイムスタンプで指定した範囲内の行に対して、改ざんが行われていないかどうか検証を行います。
検出方法としては、ハッシュチェーンを使用しています。
各行のハッシュ値を再計算し、行に格納されているハッシュ値と比較することで、改ざんを検出しています。
Amazon QLDB
概要
まずAmazon QLDBに関してAmazonによる紹介を引用します。
Amazon QLDB は新しい種類のデータベースで、台帳のようなアプリケーションを自分で構築するという複雑な開発作業を行う必要がありません。QLDB では、データの変更履歴はイミュータブルであり、変更、更新、削除はできません。また、暗号化を使用して、アプリケーションのデータに意図しない変更が行われていないことを簡単に確認できます。QLDB では、イミュータブルトランザクションログ (ジャーナル) を使用します。ジャーナルは追加専用であり、コミットされたデータを含む、一連のシーケンスおよびハッシュチェーンされたブロックで構成されます。
Oracle Blockchain Tableと同様に、Amazon QLDBもデータベースにはデータを追加することのみ許されていて、データベース内のデータを更新したり、削除することが出来ません。ただし、あくまでも内部的に追記型になっているだけで、後述のようにデータベースとしては更新・削除のインタフェースを備えています。そしてデータベース内のデータが改ざんされていないかどうかを検証することが出来る機能を持っています。
問い合わせ言語
問い合わせ言語として、PartiQLを使用しています。PartiQLはSQLに似た言語で、他にはAmazon DynamoDBで用いられています。
Blockchain Tableと異なり、更新、削除などの操作を制限していません。
ユーザが更新、削除を実行しても、内部ではデータは消えておらず、更新、削除によって生成されたデータの新しいバージョンが、追加されていくといった仕様になっています。
データモデル
データモデルはドキュメント型の、Amazon lonを使用しています。
改ざん検知方法
AWSコンソールまたはAPIを用いて、台帳内のドキュメントリビジョンと呼ばれるドキュメントのバージョンを指定して、改ざんが行われていないかどうか検証を行います。
Amazon QLDBはハッシュチェーン、マークルツリーの両方を実装していますが、主に検出手段として用いているのは、マークルツリーです。
別途保存しておいたマークルツリーのルートハッシュと再計算したルートハッシュを比較することで、改ざんを検出しています。
Oracle Blockchain TableとAmazon QLDBの比較
通常の操作
通常の操作(データの挿入、更新、削除)に関しては、Amazon QLDBの方が使いやすかったです。
その理由としては、Oracle Blockchain Tableでは更新、削除が制限されているので行の更新や最新の値を参照するためにはアプリケーションで追加の対応を必要とする一方、Amazon QLDBはそうした対応を必要とせずに通常のデータベースと同じように扱えたからです。
改ざん検出
データの検証については、Oracle Blockchain Tableの方が利便性が高いと感じました。
Oracle Blockchain Tableは複数の行を対象にハッシュチェーンを用いて検証を行います。
Amazon QLDBは単一のドキュメントのバージョンまたは単一トランザクションを対象にマークルツリーを用いて検証を行います。
Amazon QLDBではAWSコンソールで単一のドキュメントのバージョンを対象に、APIを用いると単一トランザクションを対象にして検証を行えますが、Oracle Blockchain Tableでは、検証対象の範囲を単一の行から、テーブル全体までタイムスタンプによって柔軟に選択できること、かつPL/SQLで検証を実行できるので、検証機能に関しては、Oracle BlockChain Tableの方が利便性が高いと感じました。
改ざん検出に関するOracle Blockchain Table、Amazon QLDBの共通の限界
Oracle Blockchain Table, Amazon QLDBなどの台帳型データベースは単一の管理ドメイン7によって管理されているので、データベースプロバイダによる改竄や、ハッシュチェーン、マークルツリーを丸ごと改竄するような大規模な改ざんに対しては検知することが出来ません。
例えば大規模な改ざんへの対策として、テーブルや台帳のダイジェストを第三者機関に送信し、保存してもらい、改ざん検証時にそのダイジェストを比較に用いるということが考えられますが、第三者機関に送信する前にデータに改ざんが行われると意味がありません。
またデータベースのプログラム自体に改ざんがあった場合も対処できないと考えています。
導入で言及したBFDデータベースやBFTデータベースは管理ドメインを2つ以上持つため、管理ドメイン間で比較を行うことによって、上記の改ざんにも完全に対処することが出来ます。
比較まとめ
比較要素 | Oracle Blockchain Table | Amazon QLDB |
---|---|---|
問い合わせ言語 | SQL | PartiQL |
データモデル | リレーション型 | ドキュメント型 |
改ざん検出手段 | ハッシュチェーン | マークルツリー |
改ざん検出対象 | 複数のレコード | ドキュメントの単一のバージョン |
デジタル署名 | あり | なし |
システム環境 | クラウド/オンプレミス | クラウド |
調査した感想
Oracle Blockchain TableやAmazon QLDBを調べる上で、ところどころ細かい説明が無い部分があり、自分で補足しながら考えなければならないところもあり、調査しずらく感じました。
内容を自分で補足しながら調査したり、実際にプロダクトを使用し調査することができたのは今後、改ざんに対処するデータベースを研究する上でためになりました。
次は近年の研究成果であるBFTデータベースのBasilや、BFDデータベースであるScalar DLについて勉強しようと思っています。
ここまで読んでいただきありがとうございました。
-
B. Vandiver, H. Balakrishnan, B. Liskov, and S. Madden. 2007. Tolerating Byzantine Faults in Transaction Processing Systems Using Commit Barrier Scheduling. In SOSP. 59–72. ↩
-
R.Garcia,R.Rodrigues,andN.Preguiça.2011.Efficient Middleware for Byzantine
Fault Tolerant Database Replication. In EuroSys. 107–122. ↩ -
E.Androulaki,A.Barger,V.Bortnikov,C.Cachin,K.Christidis,A.DeCaro,D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukolić, S. Weed Cocco, and J. Yellick. 2018. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. In EuroSys. 1–15. ↩
-
F. Suri-Payer, M. Burke, Z. Wang, Y. Zhang, L. Alvisi, and N. Crooks. 2021. Basil: Breaking up BFT with ACID (Transactions). In SOSP. 1–17. ↩
-
Hiroyuki Yamada and Jun Nemoto. 2022. Scalar DL: Scalable and Practical Byzantine Fault Detection for Transactional Database Systems. In PVLDB. 1324-1336. ↩
-
Xinying Yang, Yuan Zhang, Sheng Wang, Benquan Yu, Feifei Li, Yize Li, and
Wenyuan Yan. 2020. LedgerDB: A Centralized Ledger Database for Universal
Audit and Verification. In PVLDB. 3138–3151. ↩ -
管理ドメインとは、一つの組織や管理機関が管理する、ノードとネットワークの集合。 ↩