BigchainDBとは?

by 阿部 玲

BigchainDB

「ブロックチェーンデータベース」として知られるBigchainDBですが、その一言を聞いてもピンとこないと方も多いのではないかと思います。そもそも、どのブロックチェーンもデータを管理しているので、ある意味データベースとしても捉える事ができます。
そういったなか…

  • BigchainDBは他のブロックチェーンを名乗っているシステムとどう差別化されているのか?
  • 一般的なデータベースとどう違って、どう使い分ければいいのか?
  • 実際このようなシステムに意味があるのか、それとも何でもブロックチェーン化する流行りに乗っかっているだけなのか?

このような疑問を解くための観点から、これからの記事においてBigchainDBの主な構造や機能をこの紹介して行きたいと思います。

BigchainDBってどんなブロックチェーン?

BigchainDBは「もの」に対する所有権のトランザクションを承認・実行・記録する、分散環境においてそれらを不正や改竄を防ぐ形でconsensusプロトコルを活用して実行するなど、基本的には一種のブロックチェーンとカテゴライズできる機能を取りそろえています。どういうタイプのブロックチェーンであるのかというと、permissioned blockchain、事前に認証された参加者により設立されるネットワークになっています。それに伴い、consensusにproof-of-workを利用する必要もなく、cryptoeconomic incentive layerは存在しない、いわゆるDistributed Ledgerとも呼ばれるシステムです。

そういう意味ではHyperledger FabricやR3 Cordaに近いと言えます。ただ、smart contractとして定義したロジックを実行する処理エンジンを持たなく、簡単な条件定義により制限された形のトランザクションのみ実行可能になっています。表現力に関しては、例えばマルチシグネチャーのトランザクションが記述できる程度です。computeにおいての汎用性・複雑性を削り、遣り取りするデータに対する汎用性のみを保った、データの処理ではなくより遣り取りのvalidationと記録に重点を置いたシステムです。

データモデルに関していうと、BigchainDBはEthereumのようなアカウントモデルを活用して最新ステートを維持するモデルではなく、Bitcoinなどの仮想通貨でよく採用されるUTXOモデルを元にアセットを管理しています。ある意味、Ethereum上で実装されたERC-20やERC-721に相当する機能を提供するもので、それをスループットがボトルネックとなるパブリックなブロックチェーンでなくpermissionedな環境でより性能重視で実装したソリューションです。

一言でまとめると、ある固定の通貨やトークンではなく自由に定義できるデータを取引するためのブロックチェーン、そのやり取りを性能よく永続化してくれるDBMSという位置付けになっているかと思います。

BigchainDBってどんなDBMS?

外向けのインターフェイスとしては、ユーザが自分のアカウントに紐付いたアセットを登録し、そのアセットの所有権をアカウント間で引き渡すためのトランザクションを発行する事ができます。ただ、一般的なCRUDオペレーションではなく、アセットとトランザクションそれぞれを作成をするためのAPIのみが設けられています。なぜかというと、冒頭でも触れましたが、KVS/RDBMSでよく使われる最新ステートを維持するアカウント形式ではなく、UTXO形式に個々のステートアップデートをイベントしてログにアペンドしていくシステムであるからです。データベース分野で言えば、MySQLが内部に持つbinlogに近いとも言えます。その上、distributed ledgerとしての役割が成り立つよう、トランザクションの作成時にdouble-spendingなどが行われていないか、validationを行なっています。

データを永続化するためにはバックエンドで従来のドキュメントストアを活用しており、もともとRethinkDBが使われていましたが、現在最新のv2版からそこがMongoDBに切り替わりました。
その理由は後ほど解説します。ちなみに、ブロックチェーンがバックエンドで既存のDBを活用するアプローチは珍しくなく、Ethereumも内部でステートをLevelDBにおいて永続化しています。

データは基本的にそのままバックエンドのMongoDBに書き込まれるので、BigchainDBが扱うフォーマットはJSONです。冒頭に述べたようにAPIとしてはアセットとトランザクションの作成しかなく、非常にシンプルであるため、それを表現するためのDSLも特に提供されていません。ただ、永続化されたデータはMongoDBのクエリインテーフェイスで直接読み取りにいく事は可能です。

API自体は多数言語のクライアントライブラリが用意されているうえ、もしsmart contractが実行できるプラットフォームから使いたい場合はoracle API経由でアクセスする事も可能です。データプライバシーに関しては直接サポートされておらず、開発者側から選択肢として提案されているのが、JSONの内容を独自で暗号化してから書き込むか、BigchainDBでメタデータのみを管理し、実データはoff-chainのストレージに置く事です。一方、前者の場合MongoDBのクエリ・検索機能が使えなくなるのが欠点で、後者の場合は新たなデータストレージが必要となるため、より複雑なシステムになってしまいます。したがって、プライベートデータを扱うにはまだまだ不便が多いシステムです。

システムアーキテクチャーとしては、BigchainDBはクラスター構成を構築できる分散データベースになっています。そこで、DBMSとしての技術選定をする際にまず気になるはずなのがCAPにおいての性質だと思います。

これに関しての説明をするにあたって、まずBigchainDBの歴史をたどる必要があります。BigchainDBは元々のv1.0時代の設計では、ストレージバックエンドとして使っていたRethinkDBのレプリケーション機能をそのまま活用していました。いわゆる、RethinkDBのCAP性質やパフォーマンスをそのまま引き継いでいたわけです。そこでコミュニティーに懸念されたのが、RethinkDBクラスタの一つのノードに侵入され、データを改竄されたり削除されたら、その変更がクラスター内で自動的にレプリケーションされるので、BigchainDBのAPIさえ回避すればブロックチェーンの謳い文句になっている不変性が保証できない事です。流石にそれではブロックチェーンデータベースと呼ぶのもマーケティングにすぎなくなってしまうので、v2.0でアーキテクチャーが根本的に見直されました。そもそもRethinkDBの開発がMongoDBの流行りにより破綻し、そのタイミングでバックエンドがMongoDBに切り替えられました。また、ただRethinkDBのクラスタをMongoDBと入れ替えたのではなく、MongoDBのシングルノードを各BigchainDBノードのストレージバックエンドとして扱うようになりました。

Screen Shot 2018-11-06 at 15.54.36.png (390.1 kB)

そして、データのレプリケーションにおいてはbyzantine fault-tolerantであるTendermintというコンセンサスプロトコルを通じて、データがフル同期される仕組みになりました。Tendermintはどういうプロトコルなのか後ほど解説しますが、ここで重要なポイントはTendermint自体はvertical scalabilityしか提供していない事、horizontal scalabilityを確保するには独自でshardingレイヤーを考える必要がある事です。そして、この面に関してBigchainDBの開発者はまだ仕掛かり中・検討中との事で、そこから進捗の報告が公開されていません。( https://blog.bigchaindb.com/bigchaindb-2-0-is-byzantine-fault-tolerant-5ffdac96bc44 ) という事で、Tendermintが処理できる1000tps規模のスループットは担保できる一方、それ以上どうスケールするのかが未定だという事です。 もちろん、これは一般的なDBMSのパフォーマンスには程遠い数字ですので、採用する際は自分のユースケースにおいて十分なのか検討する事が大事だと思います。

最後に対故障性に触れたいと思います。ドキュメンテーションにおいては、まず対故障性に関して一般的な対策がいくつか挙げられています。各クラスターノードを地理的に異なるリージョンに構築したり、ホスティングを異なるクラウドプロバイダーに分散したり、consortium型のブロックチェーンとしてそれぞれのノードを自立した組織に運営させたりすることが手段として提案されています。このような構成にした場合、ネットワークの性能がDBのパフォーマンスにどう影響するのかは残念ながら述べられていませんので、気になる点ではあります。

それはさておき、最後にさらに興味深い対策が一点挙げられています。OSやサーバソフト自体のバグや脆弱性に対して対故障性を向上させるよう、クラスターのノードをあえて異なるOSバージョン、異なる言語において実装されたサーバのバージョンなどを使用して運用する事が推奨されています。実際異なる言語で実装されたサーバはまだ存在しなく、OSも現在Ubuntu以外はサポートされていなかったり、現段階でこのような運用をするのは不可能なようですが、少なくとも将来可能になるのであれば、評価すべき点だと思います。ちなみに、これを実現可能にするのがレプリケーションの中心となっているTendermintのプロトコルですので、ここだけは流石にバージョンを合わせないと無理ではないのかと思われます。それが理由なのか、BigchainDBのサーバは固定のTendermintのバージョンに紐づけられており、バージョンをランタイムにチェックする機能も実装されています。 ( http://docs.bigchaindb.com/en/latest/diversity.html )

DBMS観点からまとめると、BigchainDBは全ノードにおいてデータを同期的にフルレプリケーションするCP系のログストレージといったところでしょうか。スループットはPoWを活用するブロックチェーンよりかはもちろん高いのですが、一般的なDBMSの分野で言えばパフォーマンスやスケーラビリティがまだまだ懸念点となるソリューションです。

BigchainDBの競合になるものとは?

ブロックチェーンを活用したデータストレージというと、他に競合らしきシステムが多数存在しますが、似ているようで結局直接競合ではないものも多く見受けられます。

例えば、大半は既存のストレージアーキテクチャーにcrypto-incentiveレイヤーを設けてpublic blockchainとして運用するというアプローチを取っていて、解決しようとしている問題から異なるものになります。 FileCoin、StorJ、IPDB、 IPFS、Maidafeなどがこのカテゴリーの具体的な例として挙げられます。

また、管理するデータの形式やAPIの観点から異なるソリューションもいくつか存在します。IPFSはファイルストレージ、BluzelleはNoSQL KVS、WolkはSQLをサポートするRDBMS、OrbitDBはカウンターやログストレージなど様々なデータ構造をサポートしていたり、それぞれ用途が違うインターフェイスからシステムが設計されています。

API的にBigchainDBと同様のものを提供しているメジャーなプロダクトは現時点で調査したところ見当たりませんでしたが、tokenの取引を標準化したERC-20やERC-721を実装しているpermissionedブロックチェーンが一番近いものになるのかと思います。

*前日AmazonがQLDB (Amazon Quantum Ledger Database)を発表しました。技術的な詳細はまだ情報が少ないのですが、多分BigchainDBに近いシステムだと予想できるかと思いますので、競合になる可能性が高いと思います。

BigchainDBの実用性について

BigchainDBの導入を検討する際は、用途によって評価や検証項目が異なると思いますが、全般的に下記のようなポイントが印象として残りました。

良い点

  • crypto-economyを伴うpublicブロックチェーンのソリューションより導入しやすそう
  • オープンソースである
  • ドキュメンテーションがしっかりしている
  • MongoDBのクエリエンジンが使える
  • 多数言語のクライアントライブラいが用意されている
  • コミュニティーがアクティブ(githubにバグフィックスのPRを上げたら即座にマージされました)

懸念点

  • feature completeである一方、まだbeta版、さらに正式リリースがTendermintの正式リリースに依存している
  • インストール手順が複雑、Kubernetes templateは存在するがhelm chartにまとめてほしい
  • 実際手順通りにKubernetes上でクラスタを作成しても、うまく動かなかった(まだ細かいバグが色々残っている印象)
  • 1000tpsで足りなかったら使えない、horizontal scalabilityが今後どうなるのか読めない
  • データプライバシーがサポートされていない
  • githubに118のopen issuesが残っている
  • 開発チームがOceanProtocolの開発に専念する事になり、BigchainDBの開発がIPDB Foundationという組織に任され、それ以来あまり進んでない雰囲気

そして、導入に適している要件として思い浮かぶのは

  • ERC-20やERC-721と同様のロジックを実行したい
  • それを自分で実装したくない
  • publicでない環境で実行したい
  • crypto-incentiveレイヤーはいらない

上記のような要件が揃っていれば、実際BigchainDBの導入を検討してみても良いかもしれません。

Contact

お問い合わせ

Contact