データ可用性

「信頼するな、検証せよ」は、イーサリアムでよく使われる格言です。この考え方は、あなたのノードで独自に検証できることを指しています。情報が正しいのかどうかをピアから受け取ったブロックのトランザクションを全て実行することで、提案された変更がノードによって個別に計算された変更と正確に一致することを保証することが可能です。これにより、ノードがブロックの送信者が正直であると信頼する必要がないことを意味します。データが欠落している場合は、信頼することができまません。

データ可用性とは、ユーザーがブロックを検証するために必要なデータが、すべてのネットワーク参加者にとって実際に利用可能であるという確信度を指します。イーサリアムのレイヤー1上のフルノードの場合、これは比較的シンプルです。フルノードは各ブロックの全データのコピーをダウンロードしますが、このダウンロードを可能にするためには、データが利用可能で_なければなりません_。データが欠落しているブロックは、ブロックチェーンに加えられることはなく、破棄されます。これは「オンチェーンデータ可用性」であり、モノリシックブロックチェーンの機能です。フルノードでは、すべてのトランザクションを自分でダウンロードして実行するため、だまされて無効なトランザクションを受け入れることはありません。ただし、モジュラー型のブロックチェーン、レイヤー2ロールアップ、ライトノードの場合では、データ可用性の状勢がより複雑になり、より高度な検証手順が必要になります。

前提条件

ブロックチェーンの基礎、特にコンセンサスメカニズムについて、十分に理解しておく必要があります。また、このページでは、読者がブロック、トランザクション、ノード、スケーリングソリューション、その他の関連トピックに精通していることを前提としています。

データ可用性の問題

データ可用性問題とは、すべてのノードがすべてのデータをダウンロードすることなく、有効なトランザクションのセットを表すブロックチェーンが追加されたことを要約された形式のいくつかのトランザクションデータからネットワーク全体を証明する必要があることを指します。ブロックを個別に検証するには完全なトランザクションデータが必要になりますが、すべてのノードがすべてのトランザクションデータをダウンロードする必要があると、スケーリングの障壁になります。データ可用性問題に対する解決策としては、自分自身でデータをダウンロードして保存しないネットワーク参加者に対して、完全なトランザクションデータが検証のために利用可能であることを十分に保証する状態を目指すことです。

ライトノードとレイヤー2ロールアップは、強力なデータ可用性の保証を必要としながらも、トランザクションデータを自身でダウンロードして処理することができないネットワーク参加者の重要な例です。トランザクションデータのダウンロードを避けることでライトノードは軽量になり、ロールアップは効果的なスケーリングソリューションになることができます。

データ可用性は、ブロックを検証するために状態データをダウンロードして保存する必要のない、将来の「ステートレス」なイーサリアムクライアントにとっても重要な懸念事項です。ステートレスクライアントは、データが_どこかで_利用可能であり、かつ正しく処理されていることを、依然として確認する必要があります。

データ可用性のソリューション

データ可用性サンプリング(DAS)

データ可用性サンプリング (DAS) は、各ノードに過度な負担をかけずに、ネットワークでデータが取得可能であることを確認する方法です。各ノード (非ステーキングノードを含む) は、すべてのデータからランダムに選択された小さなサブセットをダウンロードします。サンプルのダウンロードが成功することで、すべてのデータが取得可能であることを高い信頼性をもって確認できます。これは、データセットに冗長な情報を加えて拡張するデータイレイジャーコーディングに依存しています(これは、データに対して_多項式_として知られる関数を適合させ、追加の点でその多項式を評価することによって行われます)。これにより、必要に応じて冗長データから元のデータを復元できます。このデータ作成の結果、元のデータが_いずれかでも_利用できなくなると、拡張されたデータの_半分_が失われてしまいます! 各ノードがダウンロードするデータサンプルの量は、実際に利用可能なデータが半分未満の_場合に_、各クライアントがサンプリングしたデータフラグメントの少なくとも1つが欠落している可能性が_極めて_高くなるように調整できます。

DASは、完全なダンクシャーディングが実装された後、ロールアップオペレーターがトランザクションデータを利用可能にすることを保証するために使用されます。イーサリアムノードでは、上述した冗長性スキームを使い、ブロブで提供されるトランザクションデータをランダムにサンプリングし、すべてのデータが存在することを確認します。同じ手法を採用することで、ブロック生成者がすべてのデータをライトノードへ使用可能にしていることを保証できます。同様に、プロポーザー/ビルダー分離(PBS)の下では、ブロック全体を処理する必要があるのはブロックビルダーだけで、他のバリデータはデータ可用性サンプリングを使用して検証します。

データ可用性委員会

データ可用性委員会 (DAC) は、データ可用性を提供もしくは証明する信頼できる当事者です。 DACは、DASの代わり、またはDASと組み合わせて (opens in a new tab)使用することができます。この委員会が持つ安全性の保証は、具体的な設定によって異なります。例えばイーサリアムでは、ランダムにサンプリングされたバリデータのサブセットを使い、ライトノードのデータ可用性を証明します。

DACは一部のバリディアムでも使われています。 DACは、データのコピーをオフラインに保存する信頼できるノードの集合です。紛争が発生した場合、データを取得可能にすることがDACに求めらます。 DACのメンバーはまた、当該データが実際に利用可能であることを証明するために、オンチェーンでアテステーションを公開します。一部のバリディアムでは、DACの代わりに、プルーフ・オブ・ステーク（PoS）のバリデータシステムを導入しています。ここでは、誰でもバリデータになって、オフチェーンでデータを保存できます。ただし、バリデータとなるためには、スマートコントラクトに対して担保となる「ボンド」を預け入れる必要があります。バリデータがデータを秘匿するなどの悪意の行為が発生した場合、預け入れられたボンドを没収することができます。プルーフ・オブ・ステークのデータ可用性委員会は、正直な行動に直接インセンティブが働くため、通常のDACよりもさらに安全になっています。

データ可用性とライトノード

ライトノードは、ブロックデータをダウンロードすることなく、受信したブロックヘッダーの正当性を検証する必要があります。この軽量であることの代償として、フルノードのようにローカルでトランザクションを再実行してブロックヘッダーを独自に検証できないことがあります。

イーサリアムのライトノードは、_同期委員会_に割り当てられた512人のバリデータからなるランダムなセットを信頼します。同期委員会は、暗号署名を使用してヘッダー内のデータが正しいことをライトノードに通知するデータ可用性員会(DAC)として振る舞います。同期委員会は毎日更新されます。各ブロックヘッダーは、_次の_ブロックに署名することが期待されるバリデータがどれであるかをライトノードに警告するため、ライトノードが本物の同期委員会になりすました悪意のあるグループを信用するように騙されることはありません。

しかし、攻撃者が何らかの方法で悪意のあるブロックヘッダーをライトクライアントに渡し、それが誠実な同期委員会によって署名されたものだと信じ込ませることに_成功した_場合はどうなるでしょうか？このケースでは、攻撃者は無効なトランザクションを含め、ライトクライアントはブロックヘッダーに要約されているすべての状態変更を個別にチェックしないため、それらを盲目的に受け入れてしまう可能性があります。これを防ぐために、ライトノードでは、不正証明を使うことができます。

この不正証明は、次のように機能します。ネットワーク上でゴシップされている無効な状態遷移を認識したフルノードは、提案された状態遷移が特定のトランザクションのセットにおいて発生する可能性がありえないことを明示した小さなデータを素早く生成し、データをピアにブロードキャストします。ライトノードでは、これらの不正証明を取得して無効なブロックヘッダーを破棄するために使用します。これにより、フルノードと同じ正直なチェーン上に確実に存在することができます。

これは、完全なトランザクションデータにアクセスできるフルノードに依存しています。無向なブロックヘッダーをブロードキャストし、そのトランザクションデータ使用させることに失敗した攻撃者は、フルノードが不正証明を生成することを阻止する可能性もありえます。フルノードは無効なブロックに対して警告を出せるかもしれませんが、証明を生成するためのデータが使用可能になっていないため、その警告を証明で裏付けることができません！

このデータ可用性問題の解決策がDASです。ライトノードは、すべての状態データに対する非常に少量なチャンクをランダムにダウンロードして、そのサンプルを検証することで全てのデータセットが使用可能であることを確認します。 N個のランダムなチャンクをダウンロードした後に、完全なデータ可用性を誤って仮定してしまう実際の確率は計算できます(100個のチャンクの場合、その確率は10^-30 (opens in a new tab)であり、つまり信じられないほど低い確率です)。

このシナリオでさえも、ほんの数バイトを保留する攻撃において、ランダムにデータリクエストを行うクライアントでは、気付くことが出来ない可能性があります。イレイジャーコーディングでは、提案された状態変化をチェックするために使用するデータの小さな欠落を再構築することで解決します。その後、再構築されたデータを使い不正証明を構築し、ライトノードが不正なヘッダーを受け入れるのを防ぎます。

注: DASと不正証明は、プルーフオブステークのイーサリアム・ライトクライアントにはまだ実装されていませんが、ロードマップには含まれており、ZK-SNARKベースの証明という形をとる可能性が最も高いです。現在のライトクライアントでは、DAC形式に依存しています。このDAC形式では、同期委員会のIDを検証し、受信した署名付きブロックヘッダーを信頼します。

データ可用性とレイヤー2ロールアップ

などのレイヤー2スケーリングソリューションは、トランザクションをオフチェーンで処理することで、トランザクションコストを削減し、イーサリアムのスループットを向上させます。ロールアップトランザクションは圧縮され、イーサリアムへバッチでポストされます。バッチは、イーサリアム上の一つのトランザクション内で、数千もの個別のオフチェーントランザクションを表します。この圧縮により、ベースレイヤーの混雑状態が軽減され、ユーザーの料金が削減されます。

しかし、イーサリアムに投稿された「要約」トランザクションを信頼できるのは、提案された状態変更が独立して検証でき、すべての個別のオフチェーントランザクションを適用した結果であることが確認できる場合に限られます。ロールアップオペレータがこの検証に対してトランザクションデータを入手可能にしていなければ、ロールアップオペレータは、不正なデータを送信することができます。

オプティミスティック・ロールアップは、圧縮されたトランザクションデータをイーサリアムに投稿し、独立した検証者がデータを確認できるように一定期間(通常は7日間)待機します。検証者が問題を特定した場合、不正証明を生成し、それを使用してロールアップに対して異議申立ができます。これにより、チェーンがロールバックされ、無効なブロックが除外されます。これは、データが入手可能でないとできません。現在、オプティミスティック・ロールアップがトランザクションをL1に投稿する方法は2つあります。一部のロールアップは、オンチェーンに永続的に存在するCALLDATAとして、データを永続的に利用可能にします。 EIP-4844の実装に伴い、一部のロールアップはトランザクションデータをより安価なブロブストレージに投稿しています。これは永続ストレージではありません。独立した検証者は、データがイーサリアムレイヤー1から削除される約18日前までにブロブへクエリを実行し、異議申立を提起しなければなりません。データ可用性は、イーサリアムプロトコルによって、その短い一定の窓口期間内においてのみ保証されます。それ以降は、イーサリアムエコシステム内の他のエンティティの責任になります。どのノードでもDAS、すなわちブロブデータの小さなランダムサンプルをダウンロードすることで、データ可用性を検証できます。

ゼロ知識(ZK)ロールアップは、が状態遷移の正当性を保証するため、トランザクションデータを投稿する必要がありません。ただし、データ可用性に対して依然として問題があります。なぜなら、状態データにアクセスできない場合、ゼロ知識ロールアップの機能（またはロールアップとのやりとり）を保証することができないからです。具体的には、オペレータがロールアップの状態に関する詳細を公開しない場合、ユーザーは自分の残高を確認できません。さらに、新たに追加されたブロックに含まれる情報を用いて、状態アップデートを実行することもできません。

データ可用性とデータ検索可能性

データ可用性は、データの取り出し可能性とは異なる概念です。フルノードが特定のブロックに関連付けられたトランザクションの完全なセットにアクセスし、検証できることを保証するのがデータ可用性です。データが永久にアクセス可能である必要はありません。

データ検索可能性とは、ノードがブロックチェーンから_過去の情報_を取得する能力のことです。この履歴データは、新しいブロックの検証には不要です。ジェネシスブロックからフルノードを同期する場合、または特定の履歴に対するリクエストを処理する場合にのみ必要になります。

イーサリアムのコアプロトコルでは、主に、データの取り出し可能性についてではなく、可用性について取り上げています。データ検索可能性は、サードパーティが運営する少数のアーカイブノードによって提供されるか、Portal Network (opens in a new tab)などの分散型ファイルストレージを使用してネットワーク全体に分散させることができます。