データ可用性

「信じるな、検証せよ (Don't trust, verify)」は、イーサリアムにおける一般的な格言です。この考え方は、ノードがピアから受け取ったブロック内のすべてのトランザクションを実行し、提案された変更がノード自身が独立して計算したものと正確に一致することを確認することで、受け取った情報が正しいことを独立して検証できるというものです。これは、ノードがブロックの送信者が誠実であると信頼する必要がないことを意味します。データが欠落している場合、これは不可能です。

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

前提知識

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

データ可用性の問題

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

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

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

データ可用性の解決策

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

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

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

データ可用性コミッティ

データ可用性コミッティ (DAC) は、データ可用性を提供または証明する信頼された当事者です。DACは、DASの代わりに、またはDASと組み合わせて (opens in a new tab)使用できます。コミッティに伴うセキュリティ保証は、具体的な設定によって異なります。例えば、イーサリアムはランダムにサンプリングされたバリデータのサブセットを使用して、ライト・ノードのデータ可用性を証明します。

DACは一部のValidiumでも使用されています。DACは、データのコピーをオフラインで保存する信頼されたノードのセットです。DACは、紛争が発生した場合にデータを利用可能にすることが求められます。また、DACのメンバーは、当該データが実際に利用可能であることを証明するために、オンチェーンで証明を公開します。一部のValidiumは、DACをプルーフ・オブ・ステーク (PoS) のバリデータ・システムに置き換えています。ここでは、誰でもバリデータになり、データをオフチェーンで保存できます。ただし、スマート・コントラクトに預け入れられる「保証金 (bond)」を提供する必要があります。バリデータがデータを隠蔽するなどの悪意のある行動をとった場合、保証金はスラッシングされる可能性があります。プルーフ・オブ・ステークのデータ可用性コミッティは、誠実な行動に直接インセンティブを与えるため、通常のDACよりもはるかに安全です。

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

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

イーサリアムのライト・ノードは、シンク・コミッティに割り当てられた512のバリデータのランダムなセットを信頼します。シンク・コミッティはDACとして機能し、暗号化された署名を使用して、ヘッダー内のデータが正しいことをライト・クライアントに伝えます。シンク・コミッティは毎日更新されます。各ブロック・ヘッダーは、次のブロックに署名することが期待されるバリデータをライト・ノードに通知するため、本物のシンク・コミッティを装った悪意のあるグループを信頼するように騙されることはありません。

しかし、攻撃者がどうにかして悪意のあるブロック・ヘッダーをライト・クライアントに渡し、それが誠実なシンク・コミッティによって署名されたと信じ込ませることに成功した場合はどうなるでしょうか。その場合、攻撃者は無効なトランザクションを含めることができ、ライト・クライアントはブロック・ヘッダーに要約されたすべての状態変更を独立してチェックしないため、それらを盲目的に受け入れてしまいます。これを防ぐために、ライト・クライアントは不正証明を使用できます。

これらの不正証明の仕組みは、ネットワーク上でゴシップされている無効な状態遷移を見たフル・ノードが、提案された状態遷移が特定のトランザクションのセットから生じるはずがないことを示す小さなデータを迅速に生成し、そのデータをピアにブロードキャストするというものです。ライト・ノードはそれらの不正証明を受け取り、それらを使用して不正なブロック・ヘッダーを破棄し、フル・ノードと同じ誠実なチェーンに留まることができます。

これは、フル・ノードが完全なトランザクション・データにアクセスできることに依存しています。不正なブロック・ヘッダーをブロードキャストし、さらにトランザクション・データを利用可能にしない攻撃者は、フル・ノードが不正証明を生成するのを防ぐことができます。フル・ノードは不正なブロックに関する警告を発することはできるかもしれませんが、証明を生成するためのデータが利用可能にされていないため、証明で警告を裏付けることはできません。

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

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

注: DASと不正証明は、プルーフ・オブ・ステークのイーサリアムのライト・クライアントにはまだ実装されていませんが、ロードマップに載っており、おそらくZK-SNARKベースの証明の形をとるでしょう。現在のライト・クライアントはDACの一形態に依存しています。つまり、シンク・コミッティの身元を検証し、受け取った署名付きブロック・ヘッダーを信頼します。

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

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

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

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

ゼロ知識 (ZK) ロールアップは、が状態遷移の正確性を保証するため、トランザクション・データを投稿する必要はありません。しかし、状態データにアクセスできなければZKロールアップの機能 (またはそれとの対話) を保証できないため、データ可用性は依然として問題です。例えば、オペレーターがロールアップの状態に関する詳細を隠蔽した場合、ユーザーは自分の残高を知ることができません。また、新しく追加されたブロックに含まれる情報を使用して状態の更新を実行することもできません。

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

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

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

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