データ可用性

最終編集者: @HiroyukiNaito(opens in a new tab), 2024年4月1日

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

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

前提知識

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

データ可用性問題

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

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

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

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

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

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

DASは、EIP-4844が実装された後、ロールアップオペレータがトランザクションデータを取得できることを確実にするために使われます。イーサリアムノードでは、上述した冗長性スキームを使い、ブロブで提供されるトランザクションデータをランダムにサンプリングし、すべてのデータが存在することを確認します。同じ手法を採用することで、ブロック生成者がすべてのデータをライトノードへ使用可能にしていることを保証できます。同様に、プロポーザー/ビルダーセパレーション(PBS)では、ブロックビルダーはブロック全体を処理することのみが求められ、他のバリデータはデータ可用性サンプリングを用いて検証します。

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

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

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

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

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

イーサリアムのライトノードでは、同期委員会に割り当てられたバリデータのランダムなセットである512台を信頼します。同期委員会は、暗号署名を使用してヘッダー内のデータが正しいことをライトノードに通知するデータ可用性員会(DAC)として振る舞います。同期委員会は毎日更新されます。同期委員会は、暗号署名を使用してヘッダー内のデータが正しいことをライトノードに通知するデータ可用性員会(DAC)として振る舞います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考文献

back-to-top ↑