データ可用性

最終編集者: @HiroyukiNaito(opens in a new tab), Invalid DateTime

トラストレスであることは、パブリックブロックチェーンにおける大前提であると言えます（「信頼せず、検証せよ」）。イーサリアムにおいて信頼性の前提を引き下げる方法のひとつに、データの可用性に関するルールの強制的な適用があります。ブロックを生成するユーザーは各ブロックのデータを公開しなければならず、これをイーサリアムのコンセンサスに参加するノードがローカルで保存するのです。

イーサリアムネットワーク上のすべてのノードは、他のノードから受け取ったブロック内のトランザクションを実行することで、ブロック生成者が提案した変更が、各ノードにおいて独立して計算されたものと正確に一致することを確認することができます。これにより各ノードは、ブロック生成者の誠実性を信頼する必要を伴わずに、新たな情報が正当なものであることを確認できます。この確認は、データが欠落していると実行できません。

ブロックチェーンにおいてデータの可用性が重要な理由は、参照可能なデータで再現できない物は存在しないと見なされるためです。検証するノードは、ブロックデータにアクセスすることで、各ノードにおけるイーサリアムのワールドステートを用いてトラストレスにトランザクションを再生し、各ブロックの正確性を独立して検証することができます。

前提知識

ブロックチェーンの基礎、特にコンセンサス・メカニズムをよく理解している必要があります。さらに、ブロック、トランザクション、ノード、スケーリングソリューション、およびその他の関連トピックについての知識が必要です。

データの可用性とは何か？

データの可用性とは、ブロック提案者が当該ブロックに関するすべてのトランザクションデータを公開し、このトランザクションデータをネットワークの他の参加者も利用可能であることを保証することです。イーサリアムのトランザクションは、ブロックで処理されます。複数のブロックをチェーンでつなぐことで、「ブロックチェーン」が作られます。

各ブロックは、主に以下の 2 つのパーツで構成されます：

ブロックヘッダー：タイムスタンプ、ブロックハッシュ、ブロック番号など、ブロックに関する一般的な情報（メタデータ）を含む部分です。
ブロックボディ：当該ブロックの一部として処理された実際のトランザクションを含む部分です。

ブロック生成者が新しいブロックを提案する場合、（ブロックボディ内の）トランザクションデータを含むブロック全体を公開しなければなりません。コンセンサスに参加している各ノードは、それを受けて、このブロックのデータをダウンロードし、トランザクションを再実行することで、新規ブロックの正当性を確認します。トランザクションを検証する他のノードが存在しなければ、ブロック提案者がブロックに悪意のトランザクションを紛れ込ませることが可能になります。

データの可用性に関する問題点

データの可用性に関する問題は、「新たに生成されたデータの参照可能性をどのように検証できるか」という問いに要約できます。イーサリアムでは、フルノードがブロックデータにアクセスできるという前提によりセキュリティを確保しているため、データが参照可能であることが死活的に重要です。

ブロックの生成者がすべてのデータを提供せずにブロックを提案する場合、このブロックは無効なトランザクションを含んだままでファイナリティに達してしまうかもしれません。仮に適切なブロックであったとしても、検証に必要なデータがすべて参照できない場合、イーサリアムネットワークのユーザーおよび機能に対して悪影響を及ぼします。

データの可用性に関する問題は同時に、ロールアップをはじめとするスケーリング・ソリューションに関する議論においても重要です。スケーリングのためのプロトコルは、イーサリアムメインネット以外でトランザクションを実行することで、スループットを増大させます。しかし、これらのプロトコルがイーサリアムを通じてセキュリティを確保するためには、トランザクションデータをメインネットに送信して、メインチェーン以外で実行された処理の正確性を誰もが検証できるようにしなければなりません。

データの可用性とライトクライアント

データの可用性に関する従来の考え方では、検証を行うノードにおけるトランザクションデータの可視性について議論を進めてきましたが、最近は、ライトクライアントにおけるデータの可用性を検証する方法に焦点を当てる傾向が強まっています。ライトクライアントにおけるデータの可用性の問題は、ブロック全体をダウンロードせずにブロックの可用性を検証できるか、という点にあります。

イーサリアムにおけるライトクライアントとは、最新のブロックヘッダーのみに同期し、フルノードに対して他の情報をリクエストするノードです。ライトクライアントは、ブロック全体をダウンロードしないため、トランザクションを検証したり、イーサリアムのセキュリティ向上に貢献することはできません。

しかし、ライトクライアントがブロックをダウンロードしないでもデータの可用性を証明できる方法についての研究が進められています。ライトクライアントがブロックの可用性を検証できるようになれば、可用性がないブロックについて他のノードに警告を発することで、イーサリアム全体のセキュリティ向上に貢献することができます。

これに関連して、ステートレスのイーサリアムにおいてデータの可用性を検証可能にするためのメカニズムについても研究が進められています。ステートレス・クライアント・コンセプト(opens in a new tab) は、提案中のイーサリアムのバージョンであり、検証を行うノードはブロックを検証する前に状態データを保存する必要がなくなります。

ステートレス性により、イーサリアムのセキュリティ、スケーラビリティ、および長期的なサステナビリティが向上できると期待されています。ノードを検証するためのハードウェア要件を引き下げることで、より多くのバリデータがネットワークに参加できるようになるため、悪意のアクターからネットワークを保護できるようになります。

データの可用性と取り出し可能性の違いとは？

データの可用性は、データの取り出し可能性とは異なる概念です。データの可用性とは、チェーンに追加するために処理中であるブロックのトランザクションデータを、ノードがダウンロードできる機能を指します。つまり、データの可用性が問題になるのは、コンセンサスに達していないブロックを対象とする場合です。

一方、データの取り出し可能性とは、ブロックチェーンにおける過去の情報をノードが取り出すことができる機能を指します。ブロックチェーンの履歴は、過去のブロックおよび、過去のイベントに関する情報が保存されているレシートにより構成されます。過去のブロックチェーンデータは、アーカイブ化のために必要となる場合がありますが、各ノードは、この履歴なしでブロックチェーンを検証し、トランザクションを処理することができます。

イーサリアムのコアプロトコルでは、主に、データの取り出し可能性についてではなく、可用性について取り上げています。イーサリアムでは、処理済みのすべてのトランザクションを永遠に保存することはありません。そうすると、フルノードにおけるストレージ要件が厳格化され、イーサリアムの分散化にとって有害だからです。

幸いなことに、データの取り出し可能性は、データの可用性よりもはるかに解決しやすい問題です。過去のブロックチェーンデータを取り出すためには、履歴情報を保存している正直なノードがひとつ存在すればよいからです。さらに、ブロックチェーン・エクスプローラーなどの組織は、アーカイブデータを保存して、他のユーザーからのリクエストに基づいて提供するというインセンティブを持っています。

データの取り出し可能性に関するソリューションの詳細(opens in a new tab)

データの可用性が重要である理由

ブロックチェーンのセキュリティ

データの可用性は、ブロックチェーンのセキュリティを維持する上で死活的に重要であり、可用性が存在しなければ、「データ秘匿による攻撃」が一般化してしまうでしょう。データ隠し持ち攻撃とは、ブロックの生成者が、当該ブロックを構築するために用いたトランザクションデータを共有せずにブロックを公開するものです。

データ隠し持ち攻撃が発生した場合、フルノードは、イーサリアムのワールドステートに対するアップデートが適切であるかを検証することが不可能になります。これにより、悪意のブロック提案者は、プロトコルのルールをかいくぐり、イーサリアムネットワークにおいて無効な状態遷移を実行させることができます。

フルノードにおけるブロックデータの可視性が重要なのは、ライトクライアントをはじめとする他のネットワーク参加者におけるネットワーク状態の検証がフルノードに依存しているためです。ライトクライアントは、フルノードとは異なり、ブロックヘッダーのみを確認し、ブロックボディはダウンロードしません。このため、データ可用性に関するルールは、フルノードがブロックを検証可能であり、チェーンの不正利用を防止できることを保証するのです。

分散型のスケーラビリティ

イーサリアムでは、分散化とセキュリティを犠牲にすることなく、処理能力のスケーラビリティを実現することを目標としています。ブロックチェーンのアーキテクチャにおけるモノリシックな限界により、分散型のスケーラビリティを実現するにはデータの可用性が非常に重要になります。

データの可用性と L2 のスケーリング

ロールアップなどのL2 のスケーリング・ソリューションは、イーサリアムのメイン実行レイヤー以外でトランザクションを処理することで、ネットワークのスループットおよびレイテンシーにおけるスケーラビリティを実現します。オフチェーンのトランザクションは、圧縮されたデータがバッチでイーサリアムに投稿されるため、オフチェーンで数千件のトランザクションが実行される場合でも、イーサリアムは提出された各バッチに関連した1 件のトランザクションをオンチェーンで処理すればよいのです。これにより、ベースレイヤーにおける処理の混雑を軽減し、ユーザーの手数料を引き下げられると同時に、トランザクションの処理速度を高めることができます。

しかし、イーサリアムがロールアップのセキュリティを保証するには、オフチェーンで実行されるトランザクションの正当性を検証するメカニズムが必要になります。ここで、データの可用性が重要になってきます。

オプティミスティック・ロールアップの場合、圧縮されたトランザクションデータはcalldataとしてイーサリアムに送信されます。これにより、すべてのユーザーがロールアップの状態を検証でき、トランザクションの正当性を保証することができます。トランザクションが無効である場合、検証者は、参照できるトランザクションデータを用いて<不正証明を構築し、異議を申し立てることができます。

ゼロ知識 (ZK) ロールアップでは、ゼロ知識有効性証明を用いて状態遷移の正当性を保証できるため、トランザクションデータを投稿する必要はありません。ただし、状態データにアクセスできない場合、ゼロ知識ロールアップの機能（またはロールアップとのやりとり）を保証することはできません。

具体的には、オペレーターがロールアップの状態に関する詳細を公開しない場合、ユーザーは自分の残高を確認できません。さらに、新たに追加されたブロックに含まれる情報を用いて、状態アップデートを実行することもできません。

ブロックチェーンにおけるデータ可用性システムの種類

オンチェーンにおけるデータの可用性

データの可用性に関する問題に対する標準的な解決策は、ブロック生成者に対し、すべてのトランザクションデータをオンチェーンで公開させ、検証するノードにこのデータをダウンロードさせるという方法です。オンチェーンにおけるデータの可用性は、データの可用性、トランザクションの実行、およびコンセンサスを 1 つのレイヤーで管理するという「モノリシックなブロックチェーン」の特徴だと言えます。イーサリアムのプロトコルでは、ネットワーク全体において冗長的に状態データを保存することで、各ノードは、トランザクションを再現し、状態アップデートを検証し、無効な状態遷移をフラッグするために必要なデータにアクセスすることができます。

しかし、オンチェーンにおけるデータの可用性を維持する場合、スケーラビリティのボトルネックが発生します。モノリシックなブロックチェーンでは、各ノードがすべてのブロックをダウンロードし、同じトランザクションを再生する必要があるため、処理速度が低下する場合が多いためです。さらに、フルノードに対して常に増化する状態の保存を要求するため、分散化という目標に反したトレンドとも言えます。イーサリアムの状態が加速度的に増化する場合、検証者はより高性能のマシンに投資しなければならず、最終的には検証ノードを実行するユーザーの数が減少するでしょう。

オフチェーンにおけるデータの可用性

オフチェーンのデータ可用性システムは、データの保存場所をブロックチェーン外に移動させます。ブロックの生成者は、トランザクションデータをオンチェーンで公開するのではなく、当該データの可用性を証明する暗号化されたコミットメントを提供します。これは、モジュラー型ブロックチェーン(opens in a new tab)で用いられている方法であり、ブロックチェーンは、トランザクションの実行やコンセンサスといった一部のタスクを管理する一方で、その他のタスク（データの可用性など）は他のレイヤーで処理させます。

スケーリングを実現する多くのソリューションでは、データの可用性をコンセンサスや実行と分離するというモジュラー型のアプローチを採用しており、ノードの要件を強化することなくブロックチェーンのスケーラビリティを実現する上で最適の方法だと考えられています。例えば、バリディウムやプラズマでは、オフチェーンのストレージを使用してオンチェーンで投稿されるデータの量を軽減しています。

オフチェーンにおけるデータの可用性は、効率性の向上をもたらすものの、分散化、セキュリティ、およびトラストレス性といった事項に対しては悪影響を及ぼします。例えば、バリディウムやプラズマにおける参加者は、ブロックの生成者が提案したブロックに無効なトランザクションを含めていないことを信頼する必要があります。ブロックの生成者は悪意の行為（つまり、無効な状態遷移）を行う可能性があり、状態データを秘匿することで、悪意のトランザクションに対する異議申立の試みを無効化しようとすることができます。

オフチェーンのデータストレージに伴う様々な問題により、一部のスケーリング・ソリューションでは、イーサリアムのような親ブロックチェーン上でトランザクションデータを保存しています。例えば、オプティミスティック・ロールアップやゼロ知識ロールアップでは、トランザクションデータを保存せず、イーサリアムメインネットをデータ可用性レイヤーとして使用します。

データ可用性の問題点を解決するソリューションには、どのようなものがあるか？

すでに述べたように、データの可用性に関する問題とは、新たに提案されたブロックにおけるトランザクションデータが検証可能かという点に関わっています。この問題に対する解決策は、データの可用性を保証するためのメカニズムを提供するものです。

データ可用性サンプリング（DAS）

データ可用性サンプリング（DAS）とは、暗号化メカニズムを使ってデータの可用性を保証するものです。 Das により、ブロックチェーンの各ノードは、ブロック全体をダウンロードせずに提案されたブロックのデータ可用性を検証することができます。

DAS システムでは、各ノードが対象ブロックから小規模なチャンクを複数回サンプリングしてデータの可用性を検証します。対象ブロックの異なる部分を多くのノードが同時にサンプリングすることで、統計的に高い確実性に基づいて可用性を検証することができます。

DAS は、イーサリアムをはじめとするブロックチェーンに適用した場合、ライトクライアントもチェーンのセキュリティおよび機能性を保証するために貢献できるようになります。ライトクライアントも高価なハードウェアを導入せずに検証を実行できるため、イーサリアムネットワーク上のあらゆるユーザーが検証作業に参加することができます。

データ可用性サンプリングに関する詳細。(opens in a new tab)

データ可用性証明

データ可用性サンプリングを通じて、対象ブロックの可用性を統計的に保証することができるものの、悪意のノードがデータを秘匿する可能性を完全に消し去ることはできません。 DAS のテクニックは、当該ブロックにおける大部分のデータの可用性を証明するだけであり、ブロック全体の可用性を保証しません。そして、ブロックの生成者がトランザクションデータのごく一部を秘匿するだけでも、多くの被害が発生しうるのです。

私たちはこの問題を解決するために、データ可用性サンプリングとイレイジャーコード(opens in a new tab)を組み合わせることで、「データ可用性証明」というプロセスを開発しました。イレイジャーコーディングとは、ブロックに冗長な部分を追加することで、データセットを二重化する技術です。これにより、本来のデータセットが失われた場合も、イレイジャーコードを用いて元々のデータを再構築することができます。

ブロックチェーンにイレイジャーコードを実装することで、データセット全体のごく一部のみを用いてブロックに含まれるトランザクション全体を再構築することができるため、データの可用性を向上させることができます。このシステムでは、悪意のブロック生成者がデータ隠し持ち攻撃を実行するには、ブロック全体の 50%以上を隠し持つ必要があります。イレイジャーコードを実装しない場合、ブロック生成者は全体のうちわずか 1%のデータを秘匿するだけで悪意の行動が可能でした。

イレイジャーコーディングを実行したブロックの場合、ライトクライアントは、ブロック全体のデータがネットワーク上で公開済みであるという統計的な確証を得ることができます。さらに、ライトクライアントは、フルノードに依存せずに、ブロックが可用性を持たないという警告を受け取ることができます。

データ可用性証明の詳細。(opens in a new tab)

データ可用性委員会（DAC）

ピュア・バリディアムでは、ブロックの生成者はトランザクションデータをオフチェーンで保存するため、ブロックチェーンはある程度一元化されます。これにより、ブロックの生成者は無効なトランザクションを公開でき、トランザクションデータを秘匿することでロールアップの真の状態を隠すことができるため、ブロックチェーンの分散性やセキュリティが低下します。

一部のバリディアムでは、ブロック生成者に対して、トランザクションデータを信頼できるユーザーで構成されたデータ可用性委員会（DAC）で保存するように指示することで、この問題を解決しようと試みています。この DAC は、オフチェーンのデータのコピーをオフラインで保存した上で、紛争が発生した場合にはこのデータを提供することが義務付けられています。 DAC のメンバーはさらに、当該データが実際に提供可能であることを証明するために、オンチェーン上で誓約を公開します。

データ可用性委員会（DAC）の詳細。(opens in a new tab)

プルーフ・オブ・ステークを用いたデータ可用性委員会

データ可用性委員会（DAC）は、バリディウムの従来のアプローチよりも優れていますが、信頼を前提にするという問題点は解消されていません。つまり、DAC がブロック生成者と結託してトランザクションデータを秘匿しようとした場合には、問題が解決できません。多くの場合 DAC の構成メンバーは少数であるため、共謀のリスクや、外部アクターが DAC を乗っ取る可能性が高まります。

一部のバリディアムでは、DAC の代わりに、プルーフ・オブ・ステーク（PoS）のバリデータシステムを導入しています。このシステムでは、すべてのユーザーがバリデータとなり、オフチェーンでデータを保存することが可能になります。ただし、バリデータとなるためには、スマートコントラクトに対して担保となる「ボンド」を預け入れる必要があります。バリデータがデータを秘匿するなどの悪意の行為が発生した場合、預け入れられたボンドを没収することができます。

プルーフ・オブ・ステークを用いた DAC は、通常の DAC よりもセキュリティが大幅に強化されます。この方法は、許可なし、信頼なしであるだけでなく、正直な行動を促すためのインセンティブがうまく設計されています。

プルーフ・オブ・ステークを用いた DAC の詳細。(opens in a new tab)

イーサリアムと今後のデータ可用性

ロールアップでは、オフチェーンでの処理を通じてスループットの規模を拡大することができますが、この規模は、基盤となるブロックチェーンのデータスループットにより制限されます。イーサリアムをデータ可用性レイヤーとして使用してロールアップを行うには、イーサリアムにおけるデータストレージおよび処理の能力を強化する必要があります。

シャーディングは、イーサリアムの実行レイヤーにおいてデータのスループットを向上させるために提案されている方法です。シャーディングでは、イーサリアムのネットワークを一定数のサブチェーンに分割し、各サブチェーンごとに専用のバリデータを割り振ります。

バリデータは、割り当てられたシャードに対してのみフルノードを実行する必要があり、他のシャードについては軽量クライアントとして実行すればよくなります。シャーディングでは、データを保存するジョブが異なるシャードに分割されるため、ロールアップに使用できるデータ領域を拡大することができます。

しかし、このようなデータのシャーディングは同時に、「特定のシャードを担当するバリデータたちが悪意を持ち、無効な状態遷移を処理しはじめたらどうなるのか」という新たな問題を生み出します。このような問題が発生しうるのは、現在とは異なり、特定のトランザクションデータにフルノードがアクセスするのが不可能になるためです。データのシャーディングを実装するには、各ノードが、ブロックをダウンロードすることなく、他のシャードにおけるデータの可用性を検証できるシステムを構築する必要があり、これを実現できなければシャーディングの目的を達成することはできません。

この問題を解決するために、イーサリアムではダンクシャーディング(opens in a new tab)などの新たなスケーリングソリューションが提案されています。これは、データ可用性をサンプリングすることで、ブログのコンテンツ全体をネットワークが確認したことを検証するというアプローチです。このシステムでは、各ノードにおいてすべてのコンテンツを直接ダウンロードし、検証するという負荷を軽減することができます。

参考文献

back-to-top ↑