原文:"Blockchain Infrastructure Landscape: A First Principles Framing" by Trent McConaghy, July 15, 2017
分散アプリにおけるストレージ、コンピューティングおよびコミュニケーションを明らかにする
Ethereum、IPFS/Filecoin、BigchainDBはどのように補完しあっているのでしょうか?Golem、Polkadot、Interledgerは?このような質問をよく受けます。だから、私はこれらの質問に答えてみることにしました。
簡単な答え:魔法のようにすべてを行う「ブロックチェーン」という魔法のシステムはありません。分散化アプリケーションを効率的に開発するために組み合わせて利用できる優れたビルディングブロックならあります。Ethereumはその役割があり、BigchainDBも役割があり、それ以外にも多くの技術がビルディングブロックを形作っています。それを今から見ていきましょう。
背景
コンピューター処理の要素は、ストレージ、コンピューティングとコミュニケーションの三つです。メインフレーム、PC、モバイル、クラウドは共通してこれらの要素を独自の方法で実現しています。特殊なビルディングブロックがこれらの要素のトレードオフを補完する形で生まれることもあります。
たとえば、ストレージ要素にはファイルシステムとデータベースがあります。ファイルシステムはディレクトリーとファイルの階層にmp3のようなブロブを格納するためのものです。データベースは構造化メタデータを格納するためのものでSQL*1のようなクエリインタフェースを備えています。集中型のクラウドに置き換えて考えると、ブロブストレージにAmazon S3、データベースはMongoDB Atlas、プロセッシングはAmazon EC2に相当します。
この記事ではコンピューター処理の各要素のブロックとシステムの例を中心にブロックチェーンの視点で説明します。
ブロックチェーンのビルディングブロック
以下がそれぞれの要素と関連する分散化のビルディングブロックです:
- ストレージ:トークンストレージ、データベース、ファイルシステム/ブロブ
- ブロセッシング:ステートフル/ステートレスなビジネスロジック、ハイパフォーマンスコンピューティング
- コミュニケーション:データ、バリュー、ステートのネットワークを繋げる
ブロックチェーンのインフラにおけるランドスケープ
ブロックチェーン技術は以下のようにコンピューター処理の要素にマッピングすることができます。
ストレージ
基本的なコンピューター処理におけるストレージ要素は次のビルディングブロックがあります。
トークンストレージ
トークンは価値(資産や証券など)を格納します。例えばBitcoins、飛行機のマイレージ、デジタルアートの著作権などです。トークンストレージシステムは二重支出を防ぎながらバリアントとともにトークンを発行/トランスファーします。
BitcoinとZcashはトークンにフォーカスした代表的な「ピュアプレイ」システムです。 Ethereumは世界のコンピュータとなるミッションの実現のためトークンをサービスで利用しています。これらはすべてネットワークインフラストラクチャを運用するための内部インセンティブとして使われるトークンの例です。
その他のトークンはネットワーク自体に力を供給するための内部性を持ちません。より低いレベルのインフラストラクチャが実際にトークンを格納する上位ネットワークのインセンティブに使用します。Ethereumメインネットの上のGolem(GNT)のようなERC20トークンは一つの例です。IPDBネットワーク上で動作するEnvokeのIPライセンストークンももう一つの例です。
最後にほとんどのブロックチェーンシステムにトークンストレージの仕組みがあることを示すために".*"をリストしました。
データベース:データベースは構造化されたメタデータの格納に特化しています。例えばテーブル(リレーショナルデータベース)、ドキュメントストア(JSONなど)、KVS、時系列、グラフなどです。クエリ(SQLなど)を介してデータを迅速に取得することができます。
MongoDBやCassandraのような伝統的な分散型(ただし集中化された)データベースは数百テラバイト、さらにはペタバイトのデータを毎秒100万回書き込むことができます(Netflixの事例)。
SQLのようなクエリ言語は実装と仕様を分離しているため特定のアプリケーションに縛られません。SQLは何十年にもわたる標準です。同じデータベースシステムをさまざまな業界で使用することができるのはこのためです。
別の言い方をすれば、アプリケーション固有のコードを使わずBitcoinを超えてブロックチェーンのアプリケーションを一般的なものにするためにチューリング完全性を徹底する必要はありません。データベースが必要なだけです。これには単純さと規模のメリットがあります。ただし、いくつかの場面でチューリング完全性を持つ大きな意味がまだあります。これについては「分散処理」のセクションでさらに解説します。
BigchainDBは分散データベースソフトウェアです。具体的にはドキュメントストアです。MongoDB(またはRethinkDB)上に構築されているため、Mongoのクエリとスケールを継承しています。さらに分散制御、耐タンパー性、トークンサポートなどのブロックチェーン特性も備えています。IPDBはBigchainDBのガバナンス機能を持った公開ネットインスタンスです。
また、IOTAはブロックチェーン分野における時系列データベースと考えることもできます。
ファイルシステム/データブロブストレージ
これらは大きなファイル(ムービー、mp3、大規模なデータセット)を格納するためのシステムで、ディレクトリとファイルの階層構造をとります。
IPFSとTahoe-LAFSは分散型のファイルシステムで、分散型/集中型のブロブストレージをラッピングします。FileCoin、Storj、SiaやTieronは分散型ブロブストレージです。古き良きBitTorrentもそうですトークンではなくtit-for-tatスキームを使用します。 Ethereum Swarm、Dat、Swarm-JSは基本的に両方を行います。
データマーケットプレイス
これらのシステムはデータ所有者(企業など)とデータ消費者(AIスタートアップなど)を仲介します。本来ならデータベースやファイルシステムよりも高いレイヤーのものですが、データを必要とする無数のアプリケーション(AIなど)がそのようなサービスに依存するため、コアインフラストラクチャにもなります。Oceanはデータマーケットプレイスを構築することができるプロトコルとネットワークの例です。アプリケーション固有のマーケットプレイスもあります:暗号市場のEnigma Catalyst、個人データ用のDatum、 IoTストリーム用のDataBroker DAO [2]などです。
プロセッシング
次に基本的なコンピューター処理のプロセッシング要素について説明しましょう。
「スマートコントラクト」は分散型の処理を行うシステムにとって人気のある呼び方です*2。 実際にはステートレス(コンビネーショナル)ビジネスロジックとステートフル(シーケンシャル)ビジネスロジックの2つのサブセットがあります。ステートレスとステートフルは複雑さや検証可能性などにおいて根本的に違うものです。さらにHPC(ハイパフォーマンスコンピューティング)という3つ目の分散処理ブロックがあります。
ステートレス(コンビネーショナル)ビジネスロジック
内部的にステートを保持しない任意のロジックです。電気工学用語では組合せ論理回路と位置づけられます。ロジックは真理値表、回路図、または条件文を保持するコード(if / then、and、orを組み合わせたもの)として表現されます。ステートを持たないため、大きなステートレスなスマートコントラクトを検証するのは容易です。このため大規模な検証/安全なシステムを構築することができます。N個の入力と1個の出力を検証するためにO(2 ^ N)回の計算が必要です。
インターレジャープロトコル(ILP)には組み合わせ回路を明確に指定する暗号条件(クリプトコンディション:CC)プロトコルを含みます。CCはIETFを通じてインターネット標準となっているため、知っておいたほうがいい技術です。またILPは集中管理と分散管理の両方のペイメントネットワーク(例:75以上の銀行がRippleを介した取引)で普及しています。CCはJavaScript、Python、Javaなどのスタンドアロン実装があります。 BigchainDBやRippleなどのシステムはCCを使用し、組み合わせビジネスロジック/スマートコントラクトをサポートします。
BitsharesとEosはステートレスなビジネスロジックもサポートしています。
ステートフルロジックはステートレスロジックのスーパーセットであるため、ステートフルロジックをサポートするシステムは(複雑さと検証の難しさを犠牲にして)ステートレスロジックもサポートします。
BigchainDB、BitsharesとEosはイベントもサポートしています(例)。このためステートフルなビジネスロジックに近いレベルの永続性を与えます。
ステートフル(シーケンシャル)ビジネスロジック
内部的にステートを保持する任意のロジックです。つまりメモリーを保持します。または少なくとも1つのフィードバックループ(およびクロック)を備えた組み合わせ論理回路です。たとえばマイクロプロセッサには内部レジスタがあり、それに送られるマシンコード命令に従って更新されます。より一般的にはステートフルなビジネスロジックは、一連の入力を受け取り、一連の出力を返すチューリングマシンです。このようなシステムはチューリング完全システムと呼ばれています*3。
Ethereumはステートフルなビジネスロジック/スマートコントラクトを直接チェーン上で実行する最も有名なブロックチェーンシステムです。 Lisk、RChain、DFINITY、Aeternity、Tezos、Fabric、Sawtoothなど多くががこれを実装しています。実行コードが「ちょうどそこに、どこかに」というのは多くのユースケースを適用することのできる強力なコンセプトです。これこそがEthereumが立ち上がった理由です。そして、そのエコシステムが成長して、それ自身がプラットフォームである理由です。このビルディングブロックに多くの強豪が参入してくる理由でもあります。
シーケンシャルロジックは組み合わせロジックのスーパーセットであるため、これらのシステムは組み合わせロジックもサポートします。
The DAOのハッキング事件でも示されたとおり、コードの小さな間違いは重大な結果を招く可能性があります。正式な検証はチップ業界を助けたように役立ちます。 Ethereum Foundationはこれに取り組んでいます。しかしスケールには限界があります。内部変数がすべてブール値であると仮定して、組み合わせ回路の場合可能なマッピングの数は2 ^(入力数)です。シーケンシャルの場合、内部状態の数は2 ^(内部ステート変数の数)です。たとえば、3入力の組み合わせ回路を使用している場合、²³ =8のsステートの可能性を検証する必要があります。これが32ビットレジスタを持つ順序回路であれば、²²= 42億のステートを検証する必要があることになります。このように順序回路の複雑さが制限されます(仮に信頼したい場合)。 Rchainがrho calculusで行ったように、ステートフルなスマートコントラクトを信頼するもう1つのアプローチは「Correct-by-construction」です。
分散処理が必要な場合はより簡単なアプローチがあります。プロセッシングをJavaScriptやSwiftでブラウザやモバイルデバイスなどクライアントで行うのです。この方法ではクライアントでの処理を信頼する必要がありますが、手元のデバイスにおいてそれは許容されることが多いです。これを「ファットプロトコル」の代替としての「ファットクライアント」だと考えています。 このアーキテクチャはメインストリームのWeb開発者にとっては簡単です。多くのWebアプリケーションに必要なのはアプリケーションステートです。これを構築するにはJavaScriptとIPDB(js-bigchaindb-driverを使用)を使うだけです。また、アプリにブロブストレージとペイメントが必要な場合はJSクライアントバージョンのIPFS(ipfs.js)とEthereum(web3.js)を追加します。以下の図がその例となります。
ハイパフォーマンスコンピューティング(HPC)
レンダリング、機械学習、回路シミュレーション、天気予報、タンパク質フォールディングなど「重い」計算を行う処理です。ここでの計算ジョブはマシンのクラスタ(CPU、GPU、場合によってはTPU)で数時間から数週間かかることがあります。
HPCの分散処理にはいくつかのアプローチがあります:
- GolemとiEx.ecは分散型スーパーコンピュータとそれに関連するアプリの組み合わせとしてとらえています。
- Nyriadはストレージ処理としてとらえています。基本的に処理は分散ストレージ(Nyriadにも解決策があります)と隣接しています。
- TrueBitはサードパーティが計算。その計算後のチェックを行います(可能な場合は暗黙的にチェックし、質問が発生した場合は明示的にチェックします)。
- 一部の人々は単にVMまたはDockerコンテナで重い計算を実行し、その結果(最終的なVMステートまたは計算結果のみ)をアクセスが制限されたブロブストレージに格納します。次にトークン化された読み取り権限などを利用してコンテナへのアクセスを販売します。このアプローチはクライアントに結果検証をより多く要求しますが、今日使える技術で全てできることが利点です。これはTrueBitが成熟するにつれてTrueBitと自然に統合されます。
コミュニケーション
ここでは第3の基本的なコンピューティング要素のコミュニケーションについて説明します。コミュニケーションをとらえるには多くの方法があります。ここではネットワークへの接続に焦点を当てます。データ、価値、ステートの3つのレベルがあります。
データ
私たちは60年代にARPAnetを手に入れました。この成功はNPLやCYCLADESのようないくつかの同様のネットワークを生み出しました。そして新しい問題も生まれました。異なるネットワークはお互い会話ができませんでした。CerfとKahnは70年代にTCP/IPを開発して現在インターネットと呼ばれるネットワークのネットワークを作りました。 TCP/IPは現在ネットワークを接続する事実上の標準になっています。OSIは競合するプロトコルでしたが衰退していきました。しかし、皮肉なことに、そのモデルは有用であることが証明されています。したがって、長い年月が経っているにもかかわらず、TCP/IPはデータのネットワークをつなぐための分散ビルディングブロックです。
Torプロジェクトはユーザーのプライバシーを保護するためのTCP/IPオーバーレイと見なすことができます。しかし、アメリカ国防総省からの資金提供はいうまでもないことですが、集中化の側面があります。トークン化されたTorのようなプロジェクトが出現しはじめています。今しばらくお待ちください[2]。
価値
TCP/IPはネットワークをデータレベルでのみ接続します。TCP/IPではパケットを二重に使うことがあります(一度に複数の宛先に同じパケットを送ります)がそれは気にしません。しかし、ネットワークに接続して価値を送る場合はどうでしょうか?たとえばBitcoinやEthereum、あるいはSWIFT決済ネットワークからRippleのXRPネットワーク。トークンを一度に一つの宛先だけに送りたいはずです。交換機は二重支出を防ぎながらネットワークに接続する方法の一つです。しかし交換機の利用はかなり重いです。ただし暗号エスクローを使用することで、交換機の本質部分だけ抽出してスリム化し、仲介人の必要性を取り除くことができます。アリスはMalloryを介してボブに送金することができます。Malloryはファンドを送りますが、使うことはできません(そしてMalloryは永遠にファンドを留めることができないので、その場合はタイムアウトとなります)。これがインターレジャープロトコル(ILP)の本質です。双方向ペグ(サイドチェーン)とステートチャンネル(LightningとRaiden)とコンセプト的には同じです。しかし、価値のネットワーク接続に100%フォーカスしています。 ILPに加えてCosmosもあります。Cosmosはより利便性を高めるために複雑さを少し増しています。
ステート
価値をネットワークにつなぐ先は何でしょうか? あるネットワークから別のネットワークにジャンプすることができる独自のBitcoinウォレットを備えたコンピュータウイルスを想像してみてください。またEthereumメインネット内のスマートコントラクトがその状態を別のEthereumネットうあ別の互換性のあるネットに移すことができたら?またはAI DAOを1つのネットに制限するのはなぜですか?
Polkadotはこのためにあります。ステートをネットワークでつなぐ。Aeternityは価値のネットワークとステートのネットワークの間のどこかにあてはまります。
ビルディングブロックを組み合わせた事例
ここまでコンピューティングの3つの要素(ストレージ、プロセッシング、コミュニケーション)と、それぞれのビルディングブロックおよびサンプルプロジェクトを紹介してきました。
人々は組み合わせながらシステムを構築しはじめています。二つのブロックの多くの組み合わせるプロジェクトはたくさんあります。通常はIPFSとEthereumまたはIPFSとIPDBの組み合わせです。そして三つ以上のブロックを組み合わせる事例もあります。ここでいくつかの最先端の事例を紹介します。
Ujoの事例
UjoではIPFS|Swarm + IPDB + Ethereumの組み合わせで分散型音楽サービスを実現しています。IPFSまたはSwarmはファイルシステムとブロブストレージとして、IPDBとBigchainDBはメタデータの格納とクエリに、Ethereumはトークンの格納とステートフルなビジネスロジックに使用されます。
Innogyの事例
Innogyではサプライチェーン/IoTアプリケーションにIPFS + IPDB + IOTAを使用しています。IPFSはファイルシステムとブロブストレージとして、IPDBとBigchainDBはメタデータの格納とクエリに、IOTAは時系列データに使用されます。
そのほかのフレーミング
ブロックチェーンコミュニティにおける他の人たちによる他のフレーミングも紹介します。それぞれの人たちとの会話を私は大いに楽しみました。
Joel Monegroの"Fat Protocols"は各ビルディングブロックをプロトコルとして位置づけています。なかなかクールなフレーミングの方法だと思っていますが、それはビルディングブロックがネットワークプロトコルを介してのみ会話をすることとなります。別の方法もあります。ブロックは単に1つの「インポート」ステートメントまたはライブラリ呼び出しとする。
インポートを使用する理由は(a)レイテンシを短くすること:ネットワークコールに時間がかかりユーザビリティを損なう可能性がある(b)シンプルさ:ライブラリ(または埋め込みコード)の利用はネットワークでの接続、トークンの支払いなどより簡単(c)より成熟している:プロトコルスタックが誕生してきています。私たちは数十年にわたる素晴らしいUnixライブラリを持っています。PythonとJavaScriptのブロックも15年以上経過しています。
Fred Ehrsamの "Dapp Developer Stack"はWebビジネスモデルに重点を置いています。 このフレーミングも非常に有益ですが、特定のコンピューティング要素(ファイルシステムとデータベースの違いなど)のブロックをさらに区別することを目的としていません。
BigchainDBのホワイトペーパー[PDF](2016年2月に公開)図1は、このポストのスタックの初期バージョンです。以下のチャートがそれです:
この図ではプロセッシング、ファイルシステムおよびデータベースのビルディングブロックにフォーカスしています。「コンピューティングの要素」という観点からは枠組みを構成しておらず、分散処理の種類も区別していませんでした。私がこの記事はこのホワイトペーパーを書いた一年半からの私の考えの進化とも言えます。私の考えは段階的に進化していき5月22日のConcensus 2017でのトークはこの記事と非常によく似ています。そしてこの記事を書いた理由はこのトークをきちんと形にするリクエストをたくさん受けたからです :)
この図は完全集中化(左)から完全分散化(右)までのスペクトラムがあることを示しています。このような表現は既存のシステムを徐々に分権化する上で、どこが最も分散化の恩恵を受けるのか理解するのに役立ちます。
Stephan Tualの "Web 3.0 Revisited"はこの記事と精神的な部分で近いですが、よりEthereumに重点を置いています。多くのプロジェクトを類似のビルディングブロックにグループ化することでコミュニティに役立つ貢献をしています。自分の考え方ととても似ていることに喜んで驚いていました。しかしアプリケーション(メッセージング、ストレージ、コンセンサス、ガバナンスなどのブロック)を構成するブロックに「アプリ」「What」「How」の3つの要素が混ざり合っています。私にとってはブロックは「What」でなければなりません。したがって、メッセージングはアプリです(アプリケーションレベル)。ストレージはより細分化する必要があります。コンセンサスは「How」の一部です。ガバナンスも「How」です。また下位のブロックとして(ネットワーク)プロトコルがあります。私はライブラリの呼び出しと同様にブロックが互いに話すことができる方法の一つだと考えています。それにもかかわらず、私はこれが優れた記事とスタックだと思います :)
Alexander Ruppertの“Mapping the decentralized world”には約20のグループに整理され、x軸はインフラストラクチャ層からアプリケーション層まで4つの上位レベルのグループを表していて、ミドルウェアと流動性を中間レベルに位置づけています。これも素晴らしいやり方です。私はAlexのマップを手伝うことができてうれしいです。コアインフラストラクチャーに重点を置いておらず、より幅広いトレンドに焦点を当てています。これもコアインフラストラクチャに関する第一原則フレーミングです。
将来
UjoのプロジェクトではIPFSとSwarm(ブロブ)+ Ethereum(トークンとビジネスロジック)+ IPDBとBigchainDB(データベースと高速クエリ)を組み合わせて全てのメリットを享受しています。
この傾向はビルディングブロックの関係性の理解が進むにつれて増えていくと考えます。「ブロックチェーン」という大きなモノリスにすべてを詰め込むより生産的です。
このスタック自体も分散型エコシステムとともに絶えず進化するでしょう。AWSはブロブストレージ用のS3というたった一つのサービスからはじまりました。 それからプロセッシングのためのEC2が追加され、AWSのサービスは増え続けています。ここにAWSのリリースタイムラインがあります。現在AWSには50以上のブロックがあります。以下はすべてのAWSサービスの現在のスナップショットです。
AWSで起きたことが分散化の分野でも起きると予想しています。おそらく現在ある全てのAWSブロックは分散化されるでしょう。もちろんクラウド、モバイル、分散システムにはそれぞれ独自のブロックがあります。分散システムであればトークンストレージなどです。これからの将来はとても楽しみです。
ここ数年、このスタックについて私にフィードバックをくれた無数の人々に感謝します。Carly Sheridan、Troy McConaghy、Dimi de Jongheの編集協力に感謝します。最後にビルディングブロックを改善し続け、さらに興味深いアプリケーションを開発し続けている宇宙の皆様に感謝します:)
翻訳:カタパルト式スープレックスなかむらかずや
この記事はシステムの視点でブロックチェーンを解説した"Blockchain Infrastructure Landscape: A First Principles Framing"の翻訳です。これを書いたのはBigchainDBの共同創設者でCTOのTrent McConaghy氏です。
ボク自身はビットコインのような仮想通貨にはあまり興味なくって、コンピューター技術としてのブロックチェーンに興味がありました。「Ethereumに興味がある」と言っても「最近値上がりしてるよね」と答えが返ってくると(Ether [ETH]でなくってEthereumなんだけどと)ガッカリしたりして。
今はEthereumやIOTA、Polkadotなど面白い技術がたくさん出てきています。ただ、技術要素はたくさんあるのだけれど、全体的に俯瞰できるような資料があまりなかった。そんな時に出会ったのがこの記事でした。
メインフレームからクライアントサーバー型、そしてクラウドコンピューティングに移り変わりました。そして、クラウドの先にある世界。これから起きるであろう変化は本当の意味での分散型のシステムで、ブロックチェーン(またはTangleなどその次世代の仕組み)がその中心にある可能性が高いと思います。
カタパルトスープレックスなかむらかずや
関連記事
*1:[1] これらのビルディングブロックを階層化することもできます。例えばデータベースは生データ(ブロブ)ストレージが格納されるファイルシステムの上に存在します。分散データベースにはコミュニケーションが含まれます。例えば最新のデータベースのほとんどは、Ext4、XFS、GridFSなどのファイルシステムを介して、基礎となるストレージと通信します。この記事で紹介しているフレーミングはアプリケーション開発者からの視点です。
*2:[3] 私は「スマートコントラクト」という名前は好きではありません。 AIの世界から見ればスマートコントラクトはスマートではありませんし、法的意味で「コントラクト」とは何の関係もありません。 それらに法規が含まれている場合、リカーディアン・コントラクトのようにそのように言及されています。「分散プロセス」というラベルとその中の「分散型ビジネスロジック」というラベルの方が理にかなっています。しかし、「スマートコントラクト」はすでに広まってしまった名前なので、しかたありません。ラベルの上に戦うより集中すべきことがたくさんあります😀
*3:[4] 理論的には純粋な意味ではなく、実用的な意味で「チューリング完全」です。 つまり、マシンはインプットのビットとその現在の内部ステートの関数としてストリングのビットを返します。無限に実行されたり「いつ機械が止まるのか」という問題(停止問題)を解決するのは実用的です。