元のソース: Delphi Digital
原文の編集: The Way of DeFi
キーポイント
元のソース: Delphi Digital
原文の編集: The Way of DeFi
キーポイント
イーサリアムは、スケーラブルな統合決済層とデータ可用性層を構築する唯一の主要プロトコルです
ロールアップはイーサリアムのセキュリティを活用しながら計算を拡張します
すべての道は集中型ブロック生成、分散型トラストレスブロック検証、検閲耐性のあるエンドゲームにつながる
MEV は現在、最前線であり中心的存在です - その害を軽減し、中央集権化の傾向を防ぐために多くの設計が計画されています
導入
Danksharding は、複数の最先端の研究手段を組み合わせて、イーサリアムのロールアップ中心のロードマップに必要なスケーラブルなベースレイヤーを提供します
生きているうちにダンクシャーディングを達成したいと思っています
導入
パート I – ダンクシャーディングへの道
1) 生データのシャード設計 – 独立したシャード提案者
2) データの入手可能性のサンプリング
3) KZGの取り組み
4) KZG の約束と不正防止
8) Danksharding
5) プロトコル内での提案者と構築者の分離
6) 検閲禁止リスト (crList)
7) 2次元KZGスキーム
9) ダンクシャーディング – 正直な多数派の検証
10) ダンクシャルディング – 再建
11) Danksharding – プライベートランダムサンプリングによる悪意のある多数決セキュリティ
12) ダンクシャーディング – 重要なポイント
13) ダンクシャーディング – ブロックチェーンのスケーラビリティの限界
14) 生のダンクシャルディング (EIP-4844)
15) 多次元 EIP-1559
パート II – 歴史と状態管理
1) 合計通話データ制限によって通話データのガスを削減します (EIP-4488)
5) Verkle Tries
2) クライアントでの履歴データの実行を制限する (EIP-4444)
3) 履歴データの復元
4) 弱ステートレス
2) MEV-Boost
6) 状態が期限切れになる
パート III – すべては MEV です
1) 現在の MEV サプライチェーン
3) 委員会主導の MEV 平滑化
4) 単一スロットの決定論
5) 単一の秘密リーダー選挙
1) 統合されたクライアント
導入
2) 統合されたコンセンサス
結論的な考え
導入
ヴィタリックが今日生まれた人は3000歳まで生きる確率が50〜75%であり、永遠に生きたいと願っていると言って以来、私はマージのタイムラインに懐疑的でした。しかし、これは冗談として受け止めましょう。いずれにせよ、私たちはイーサリアムの野心的なロードマップにまだ期待する必要があります。これはすぐに読めるものではありません。イーサリアムの野心的なロードマップを幅広く微妙に知りたい場合は、1 時間集中していただければ、数か月の作業を節約できます。長期的に従うべきイーサリアム研究の方向性は数多くありますが、最終的にはすべてが 1 つの包括的な目標、つまり分散型検証を犠牲にすることなく計算をスケールすることに当てはまります。
ヴィタリックの有名な「
エンドゲーム
「一つの記事。彼は記事の中で、規模を達成するにはある程度の集中化が必要であることを認めています。ブロックチェーンではこの「C」という単語は恐ろしいものですが、これは事実です。私たちが必要としているのは、分散型でトラストレスな検証を通じてこの権限を維持することだけです。ここに妥協はありません。
専門家が L1 以上のモジュールを構築します。イーサリアムはシンプルな分散検証により依然として非常に安全であり、ロールアップは L1 からセキュリティを継承しています。その後、イーサリアムは決済とデータの可用性を提供し、ロールアップの拡張を可能にします。ここでのすべての研究は、最終的に、チェーンの完全な検証をこれまで以上に簡単にしながら、これら 2 つの役割を最適化することを目指しています。
以下は、~43531756765713534 回出現するいくつかの単語を省略する用語集です。
DA – データの可用性
DS–Danksharding
DAS – データ可用性サンプリング
PBS – 提案者と構築者の分離
PDS – 生のダークシャーディング
PoW - 作業証明
PoS – プルーフ・オブ・ステーク
パート I: ダンクシャーディングへの道
イーサリアムがロールアップ中心のロードマップに移行したことをもう聞いたことがあると思います。シャーディングは不要になり、イーサリアムはデータを大量に消費するロールアップ用に最適化されます。これは、データシャーディング (イーサリアムの計画) または大きなブロック (セレスティアの計画) を通じて実現されます。
コンセンサス層はシャーディングされたデータを解釈しません。やるべきことは 1 つあり、データが利用可能であることを確認することです。
ロールアップ、不正行為、ZK プルーフなどの基本的な概念と、DA が重要な理由についてはすでに理解していると思います。よく知らない場合、または復習が必要な場合は、Can が最近発行した Celestia に関するレポートで説明されています。
生データのシャード設計 - 独立したシャード プロポーザー
ここで説明する設計は古いものですが、貴重なシナリオです。簡単にするために、これを「シャーディング 1.0」と呼びます。
64 のシャード ブロックのそれぞれには独立した提案者と委員会があり、バリデーターのセットから順番に交代します。彼らは、シャード データが利用可能であることを独自に検証します。元々、これは DAS ではなく、データを完全にダウンロードするために各シャードのバリデータ セットの大部分に依存していました。
この設計により、不必要な複雑さが生じ、ユーザー エクスペリエンスが低下し、攻撃ベクトルが生じます。シャード間でバリデーターをシャッフルするのは難しいです。
非常に厳密な同期の前提を導入しない限り、単一スロット内で投票が行われることを保証するのは困難です。ビーコン ブロックの提案者は、個々の委員会の投票をすべて集める必要があるため、遅延が発生する可能性があります。
DSは全然違いますよ。バリデーターは DAS を実行して、すべてのデータが利用可能であることを確認します (個別のシャード委員会はもう必要ありません)。専門のビルダーが、ビーコン ブロックとすべてのシャード データを一緒に確認した大きなブロックを作成します。したがって、DS が分散型を維持するには PBS が必要です (大きなブロックを一緒に構築するとリソースが大量に消費されます)。
データ可用性のサンプリング
ロールアップは大量のデータを公開しますが、ノードがこのデータのすべてをダウンロードすることは望ましくありません。これは、高いリソース要件を意味し、それによって分散化が損なわれることになります。
代わりに、DAS を使用すると、ノード (ライト クライアントでも) がすべてをダウンロードすることなく、すべてが利用可能であることを簡単かつ安全に検証できます。
簡単な解決策 - そのブロック内の多数のランダムなチャンクをチェックするだけです。全員が署名するなら、私も署名します。しかし、すべての ETH を Sifu に渡すトランザクションを見逃したらどうなるでしょうか?資金はもはや安全ではありません。
賢い解決策 - 最初にデータを消去します。リードソロモン符号を使用してデータを拡張します。これは、データが多項式として補間され、その後他の多くの場所で評価されることを意味します。これは一度に完了するので、分解してみましょう。
数学が理解できない人のために簡単に説明しましょう。 (本当にひどい計算にはならないと約束します。パートを書くためにカーン アカデミーのビデオをいくつか見なければなりませんでしたが、今では理解できました)。
多項式は、cxk 形式の任意の有限数の項を合計する式です。次数は最高の指数です。たとえば、2 x3+6 x2+2 x-4 は 3 次多項式です。 d 次の任意の多項式を、その多項式上の任意の d+1 座標から再構築できます。
では、具体的な例を挙げてみましょう。以下に 4 つのデータ チャンク (d0 ～ d3) があります。これらのデータのチャンクは、特定の点での多項式 f(X) の評価にマッピングできます。たとえば、f(0) = d0 です。これで、これらの評価を実行する最小次多項式が見つかりました。これは 4 つのチャンクであるため、3 次多項式を見つけることができます。次に、このデータを拡張して、同じ多項式に沿って 4 つの評価 (e0 から e3) を追加できます。
重要な多項式のプロパティを思い出してください。元の 4 つのデータ チャンクだけでなく、任意の 4 つの点から多項式を再構築できます。
DAS に戻ります。ここで必要なのは、消去符号化されたデータの 50% (4/8) が利用可能であることを確認することだけです。これから、ブロック全体を再構築できます。
したがって、攻撃者は、データが利用できないときに DAS ノードを騙して、データが利用可能であると思わせるために、ブロックの 50% 以上を隠す必要があります。
無作為サンプルが多数成功した後でも、利用可能な確率は 50% 未満になります。消去符号化データのサンプリングに 30 回成功した場合、50% 未満が利用できる確率は 2 ～ 30 です。
KZGのこだわり
OK、ランダムなサンプルを大量に作成しました。それらはすべて利用可能です。しかし、別の疑問があります。データ消去コーディングは正しいのでしょうか?それ以外の場合は、ブロック作成者がブロックを拡張するときに 50% のゴミを追加しただけで、私たちはそのゴミをサンプリングしたのかもしれません。この場合、実際にはデータを再構築することはできません。
通常、Merkle ルートを使用して大量のデータをコミットするだけです。これは、コレクションに特定のデータが含まれていることを証明する場合に効果的です。
ただし、すべての元のデータと拡張データが同じ低次の多項式上にあることも知っておく必要があります。マークルのルーツはこれを正当化するものではありません。したがって、このスキームを使用する場合は、何かが間違って行われた場合に備えて、詐欺の証明も必要になります。
開発者は次の 2 つの方向で取り組んでいます。
Celestia は詐欺防止の道を進んでいます。誰かが、ブロックが誤って消去符号化されている場合、詐欺の証拠を提出して全員に警告することを認識する必要があります。これには、標準的な正直ないくつかの仮定と共時性の仮定が必要です (つまり、誰かが私に不正行為の証拠を送ってくることに加えて、私は接続されていて、有限の時間内にそれを受信すると仮定する必要もあります)。
Ethereum と Polygon Avail は、KZG Commitments (別名 Kate Commitments) という新しいルートを採用しています。これにより、不正行為の証明に関する正直者少数派および同期セキュリティの前提が削除されます (ただし、それらはまだ再構築する必要があり、これについてはすぐに説明します)。
他の解決策も存在しますが、積極的には追求されていません。たとえば、ZK 証明を使用できます。残念ながら、それらは（現時点では）計算上非現実的です。ただし、今後数年間で改善されると予想されているため、KZG は量子耐性を持たないと約束しているため、将来的にはイーサリアムが STARK に切り替わる可能性があります。
KZG コミットメントに戻ります。これは多項式コミットメント スキームです。
コミットメント スキームは、単に、ある値を証明可能にコミットするための暗号化された方法です。最も分かりやすい例えは、鍵のかかった箱に手紙を入れて他の人に渡すことです。手紙は一度中に入ると変更できませんが、鍵で開けて証明することができます。あなたがコミットすることは約束であり、鍵は証拠です。
私たちの場合、すべての元のデータと拡張データを X、Y グリッドにマッピングし、それらを通過する最小次数の多項式を見つけます (このプロセスはラグランジュ補間と呼ばれます)。この多項式は証明者が約束するものです。
重要なポイントは次のとおりです。
「多項式」f(X) があります。
証明者は多項式 C(f) に「コミットメント」をします
これは、信頼できるセットアップによる楕円曲線暗号化に依存します。この仕組みの詳細については、Bartek による素晴らしい投稿を参照してください。
この多項式 y = f(z) の「評価」について、証明者は「証明」 π(f,z) を計算できます。
コミットメント C(f)、証明 π(f,z)、任意の位置 z、および z における多項式の評価 y が与えられると、検証者は f(z) = y であることを確認できます。
説明: 証明者はこれらの部分を検証者に提供し、検証者はある時点での評価 (評価が基礎となるデータを表す) がコミットされた多項式に正しく基づいていることを確認できます。
これは、すべての評価が同じ多項式に基づいているため、元のデータが正しくスケーリングされていることを証明します。
検証者は多項式 f(X) を必要としないことに注意してください。
重要なプロパティ - これには、コミットメント サイズが O(1)、証明サイズが O(1)、検証時間が O(1) です。コミットメントと証明生成は証明者であっても O(d) でのみスケールされます。ここで d は多項式の次数です
説明: n (X の値の数) が増加しても (つまり、より大きなシャード BLOB でデータセットが増加した場合)、約束と証明は同じサイズのままであり、検証には継続的な努力が必要です。
どちらも C(f) にコミットし、π(f,z) がペアフレンドリー曲線上の単なる楕円曲線要素であることを証明します (これには BL12-381 が使用されます)。この場合、それらはそれぞれわずか 48 バイトです (非常に小さい)
したがって、大量の元のデータと拡張データ (多項式の複数の評価を表す) を提出する証明者はまだ 48 バイトしかなく、証明もわずか 48 バイトです
TLDR – 拡張性が高い
次に、KZG ルート (多項式コミットメント) はマークル ルート (ベクトル コミットメント) に似ています。
元のデータは、位置 f (0) ～ f (3) で計算された多項式 f (X) であり、次に、f (4) ～ f (7) で多項式を計算することによって拡張します。すべての点 f (0) から f (7) が同じ多項式上にあることが保証されます。
結論: DAS を使用すると、消失符号化されたデータが利用可能かどうかを確認できます。 KZG の取り組みは、元のデータが適切にスケーリングされており、それらすべてを約束していることを証明しています。
よくやった、今日の代数はここまでだ。
KZG の約束と不正防止
KZG がどのように機能するかを理解したところで、一歩下がって 2 つのアプローチを比較してみましょう。
KZG の欠点 - KZG はポスト量子セキュアではなく、信頼できるセットアップが必要です。これらは心配ありません。 STARK はポスト量子の代替手段を提供しますが、信頼できるセットアップ (オープンな参加) には正直な参加者が 1 人だけ必要です。
KZG の利点 - 不正防止セットアップよりもレイテンシが低く (ただし、前述したように、GASPER はとにかく高速ファイナリズムにはなりません)、同期性と正直さに関する固有の少数の前提を導入することなく、正しい消去コーディングを保証します。
ただし、イーサリアムがブロック再構築のためにこれらの前提を依然として再導入していることを考えると、実際にはそれらを削除するわけではありません。 DA 層は常に、ブロックが最初に提供されたシナリオを計画する必要がありますが、その後、ブロックを元に戻すためにノードが相互に通信する必要があります。この再構成には 2 つの仮定が必要です。
データをサンプリングする十分なノード (ライトまたはフル) があるため、データを元に戻すのに十分です。これはかなり弱く、避けられない正直な少数派の仮定であるため、大きな問題ではありません。
同期性の仮定を再導入する - 同期を取り戻すには、ノードは一定期間通信できる必要があります。
Ethereum バリデーターは PDS でシャード BLOB を完全にダウンロードし、DS では DAS (割り当てられた行と列のダウンロード) のみを実行します。 Celestia では、ブロック全体をダウンロードするためにバリデーターが必要です。
どちらの場合でも、再構築には共時性の仮定が必要であることに注意してください。ブロックが部分的にしか利用できない場合、完全なノードは他のノードと通信してブロックを元に戻す必要があります。
楕円曲線暗号の（比較的わかりやすい）入門書–Vitalik
楕円曲線ペアリングの探索
KZG 多項式のコミットメント
信頼できる設定はどのように機能しますか?
プロトコル内の提案者と構築者の分離
今日のコンセンサス ノード (マイナー) とマージされたノード (バリデータ) は 2 つの役割を果たします。彼らは実際のブロックを構築し、それを検証する他のコンセンサスノードに提案します。マイナーは前のブロックに基づいて「投票」し、マージ後、検証者はブロックが有効か無効かについて直接投票します。
PBS はそれらを分離し、新しいプロトコル内ビルダーの役割を明示的に作成します。プロのビルダーがブロックを組み立て、提案者 (検証者) に入札してブロックを選択します。これは MEV の集中力との戦いです。
Vitalik の「Endgame」の記事を思い出してください。すべての道は、トラストレスで分散型の検証による集中型のブロック生成につながります。 PBSがこれをまとめた。ネットワークの稼働性と検閲耐性を提供するには誠実なビルダーが必要です (効率的な市場には 2 人必要です)。ただし、バリデータ セットには誠実な過半数が必要です。 PBS は、検証者の分散化をサポートするために提案者の役割を可能な限り単純化します。
建設業者は、引き出し可能な MEV とともに優先料金チップを受け取ります。効率的な市場では、競争力のある建築業者は、ブロックから抽出できる最大の価値 (強力なハードウェアなどの償却コストを差し引いたもの) で入札します。すべての価値は分散型バリデーターセットに浸透します - まさに私たちが望むものです。
正確な PBS 実装はまだ議論中ですが、2 スロット PBS は次のようになります。
ビルダーは入札でブロックヘッダーをコミットします
ビーコン ブロック提案者は、落札ブロック ヘッダーと入札を選択します。たとえ製作者がボディの製作に失敗したとしても、入札者は無条件で落札することになる
証明委員会がヘディング勝ちを確認
ビルダーが優勝ボディを発表
独立した立会人委員会が優勝団体を選出します（優勝した建設業者が同意しない場合は欠席投票となります）
提案者は、標準の RANDAO メカニズムを使用してバリデーターのセットから選択されます。次に、委員会がブロックヘッダーを確認するまで完全なブロック本体が公開されないコミット公開スキームを使用します。
commit-reveal はより効率的であり (数百の完全なブロック ボディを送信すると、p2 p 層の帯域幅を圧倒する可能性があります)、MEV の盗用も防止します。ビルダーが完全なブロックを送信した場合、別のビルダーはそれを見て、その戦略を理解し、マージし、より良いブロックを迅速に公開できます。さらに、成熟した提案者は、使用された MEV 戦略を検出し、構築者を補償することなくそれを複製できます。この MEV 盗用のバランスがとれると、マージ ビルダーとプロポーザーが奨励されることになるため、これを回避するために commit-reveal を使用します。
提案者が勝者のブロックヘッダーを選択した後、委員会はフォーク選択ルールを確認して修正します。次に、優勝したビルダーは、優勝した完全な「ビルダー ブロック」ボディを公開します。期限内に釈放されれば、次の委員会が証言することになる。期限内に公開できなかった場合でも、提案者に全額の入札額を支払います (すべての MEV と手数料を失います)。この無条件の支払いにより、提案者は建設業者を信頼する必要がなくなります。
この「2 スロット」設計の欠点は遅延です。マージされたブロックは固定の 12 秒になるため、新しい仮定を導入したくない場合は、完全なブロック時間 (2 つの 12 秒スロット) を取得するには 24 秒が必要です。研究は進行中ですが、スロットあたり 8 秒 (ブロック時間 16 秒) が安全な妥協点のように思えます。
検閲抵抗リスト (crList)
残念ながら、PBS では建設業者に取引を確認する高い能力が与えられています。もしかしたら、建設業者はあなたのことが気に入らないので、あなたの契約を無視しているのかもしれません。もしかしたら、彼らはとても良い仕事をしているので、他の建築業者はみんな諦めているのかもしれません。あるいは、あなたが本当に気に入らないからブロックに高値で入札しているだけなのかもしれません。
crLists はこの機能をチェックします。正確な実装はやはりオープンな設計空間ですが、「ハイブリッド PBS」が人気のようです。提案者は、mempool 内で確認できるすべての適格なトランザクションのリストを指定し、ビルダーは (ブロックがいっぱいでない限り) それらを含めることを強制されます。
提案者は、すべての適格なトランザクションを含む crList と crList のダイジェストを公開します。
ビルダーは提案されたブロック本体を作成し、それを見たということを証明する crList ダイジェストのハッシュを含む入札を送信します。
提案者は落札したビルダーの入札とブロックヘッダーを受け入れます（まだ本体を見ていません）。
ビルダーはブロックを公開し、crList からのすべてのトランザクションが含まれていること、またはブロックがいっぱいであることの証明を含めます。そうしないと、フォーク選択ルールはブロックを受け入れません。
証明者は公開された本文の正当性をチェックします
ここには解決すべき重要な問題がまだ残っています。たとえば、ここで主流の経済戦略は、提案者に空のリストを提出させることです。レビュー作成者であっても、最高額の入札が行われていればオークションに勝つことができます。この問題やその他の問題を解決するためのアイデアはいくつかありますが、ここでの設計が確定したものではないことを強調しておきます。
2次元KZGスキーム
KZG の約束により、データにコミットし、データが正しくスケーリングされたことを証明できることがわかりました。ただし、イーサリアムの実際の動作を簡略化してみました。単一の KZG コミットメントですべてのデータがコミットされるわけではありません。単一のブロックで多くの KZG コミットメントが使用されます。
すでに専用のビルダーがいるのですから、彼らに巨大な KZG コミットを作成させてみてはいかがでしょうか?問題は、これを再構築するには強力なスーパーノードが必要であることです。初期ビルドのスーパーノード要件は許容できますが、ここでは前提条件の再構築を避ける必要があります。再構築を処理するにはリソースの少ないエンティティが必要ですが、それを多くの KZG コミットに分割することでこれが可能になります。手元にあるデータの量を考慮すると、再構成はかなり一般的であるか、この設計における基本的な想定である可能性さえあります。
再構築を容易にするために、各ブロックには m 個の KZG コミットメントでエンコードされた m 個のシャード BLOB が含まれます。これを単純に行うと、大量のサンプリングが発生します。すべてのシャード BLOB が利用可能になるまで (m*k サンプル、k は BLOB あたりのサンプル数)、各シャード BLOB に対して DAS を実行します。
代わりに、イーサリアムは 2D KZG スキームを使用します。ここでもリードソロモンコードを使用して、m 件のコミットメントを 200 万件のコミットメントにスケールします。
追加の KZG コミットメントを 0 ～ 255 (ここでは 256 ～ 511) と同じ多項式に拡張することで、これを 2D スキームにします。ここで必要なのは、上記のテーブルを DAS して、すべてのシャードのデータの可用性を確保することだけです。
利用可能なデータの 75% 以上という 2D サンプリング要件 (以前は 50% と比較) は、サンプル サイズをもう少し固定することを意味します。前に、単純な 1D スキームでの DAS のサンプルが 30 個であると述べましたが、使用可能なブロックを再構築する同じ確率的オッズを保証するには、75 個のサンプルが必要になります。
シャーディング 1.0 (1D KZG コミットメント スキームを使用) に必要なサンプルはわずか 30 個ですが、1920 個のサンプルの完全な DA を確認したい場合は、64 個のシャードをサンプリングする必要があります。各サンプルは 512 B であるため、次のものが必要です。
(512 B x 64 スライス x 30 サンプル) / 16 秒 = 60 KB/秒の帯域幅
Danksharding
事実上、バリデーターはすべてのシャードを個別にチェックすることなく、単純にシャッフルされます。
2D KZG コミットメント スキームを使用した構成ブロックにより、完全な DA のチェックが簡単になりました。単一の均一ブロックの 75 サンプルのみが必要です。
(512 B x 1 ブロック x 75 サンプル) / 16 秒 = 2.5 KB/秒の帯域幅
PBS は元々、バリデーター セットに対する MEV の集中を軽減するために設計されました。しかし、Dankrad は最近この設計を利用し、これによりはるかに優れたシャーディング構造である DS が解放されることに気づきました。
DS は専用のビルダーを活用して、ブロックとシャードのより緊密な統合を強制するビーコン チェーンを作成します。現在、ブロック全体を共同で作成する建設者、提案者、委員会がいます。 DS は PBS なしでは実現できません。通常のバリデーターは、ロールアップ データ BLOB でいっぱいのブロックの巨大な帯域幅を処理できません。
シャーディング 1.0 には 64 の独立した委員会と提案者が含まれているため、各シャードは個別に利用できない場合があります。ここでのより緊密な統合により、DA を一度に確保できるようになります。データは依然として舞台裏で「シャーディング」されていますが、実用的な観点から見ると、ダンクシャーディングはより大きなブロックのように感じられ始めており、これは素晴らしいことです。
ダンクシャーディング – 正直な多数派の検証
検証者の証明データは次のように入手できます。
これは、バリデーターの正直な大多数に依存しています。単一のバリデーターとして、列と行の可用性だけでは、ブロック全体が利用可能であると統計的に確信するには十分ではありません。正直に言って、ほとんどの人がどちらだと言うかによって異なります。分散型検証は重要です。
これは、前に説明した 75 個のランダム サンプルとは異なることに注意してください。プライベート ランダム サンプリングは、リソースに乏しい個人が簡単に可用性を確認できる方法です (たとえば、DAS ライト ノードを実行すると、ブロックが利用可能であることがわかります)。ただし、バリデーターは引き続き行と列のアプローチを使用して、可用性を確認し、ブロックの再構築をガイドします。
ダンクシャーディング - リファクタリング
単一の行または列の 50% が利用可能である限り、サンプリング検証ツールはそれを簡単に完全に再構築できます。行/列で失われたブロックを再構築するとき、それらのブロックを直交するラインに再割り当てします。これは、他のバリデーターが必要に応じて、交差する行と列から欠落しているブロックを再構築するのに役立ちます。
ここで使用可能なブロックを再構築するための安全な仮定は次のとおりです。
ブロックを再構築するのに十分なデータを集合的に保持できるように、サンプル リクエストを実行するのに十分なノード
それぞれのブロックをブロードキャストするノード間の同期の仮定
では、ノードは何個あれば十分なのでしょうか?概算では、個別のインスタンスは約 64,000 個です (これまでに 380,000 個以上)。これは、同じバリデーターによって実行されるノード間のクロスオーバーがないと仮定した非常に悲観的な計算でもあります (これは、ノードが 32 個の ETH インスタンスに制限されているのとは大きく異なります)。 2 つ以上の行と列をサンプリングすると、クロスオーバーによりそれらをまとめて取得できる可能性が高くなります。これは二次関数的にスケールし始めます。バリデーターが 10 または 100 個のバリデーターを実行している場合、64,000 は桁違いに少なくなる可能性があります。
オンライン バリデーターの数が異常に少なくなり始めた場合は、シャード データ BLOB 数を自動的に減らすように DS を設定できます。したがって、安全性の仮定は安全レベルまで引き下げられます。
Danksharding – プライベートランダムサンプリングによる悪意のある多数決セキュリティ
DS の検証はブロックを証明するために誠実な多数決に依存していることがわかりました。私個人としては、ほんの数行と列をダウンロードしただけでは、ブロックが利用可能であることを証明することはできません。しかし、プライベートなランダムサンプリングを使えば、誰も信頼することなく、その保証を得ることができます。前述したように、ノードはここで 75 個のランダム サンプルをチェックします。
これはネットワークの観点から解決するのが非常に難しい問題であるため、DS には当初、プライベート ランダム サンプリングは含まれません (PSA: ここで実際にあなたの助けが得られるかもしれません!)。
攻撃者が匿名化を解除すると、少数のサンプリングされたノードになりすますことができるため、「プライベート」が重要であることに注意してください。彼らは要求した正確なブロックを返し、残りを保持することができます。したがって、独自のサンプリングだけからすべてのデータが利用できるかどうかはわかりません。
ダンクシャーディング – 重要なポイント
素敵な名前に加えて、DS は非常にエキサイティングでもあります。イーサリアムの統合決済とDAレイヤーのビジョンをついに実現します。このビーコン ブロックとシャーディングの緊密な結合は、基本的にシャーディングされていないように見せかけます。
実際、なぜそれが「シャーディング」とみなされるのかを定義してみましょう。 「シャーディング」の唯一の名残は、バリデーターがすべてのデータをダウンロードする責任を負わないことです。それだけです。
したがって、これが本当にシャーディングを続けているのかどうか疑問に思っている人は、頭がおかしいわけではありません。この区別が、PDS (これについてはすぐに説明します) が「シャード」とみなされない理由です (名前に「シャード」が含まれていますが、確かに、混乱を招くのは承知しています)。 PDS では、各バリデーターがすべてのシャード BLOB を完全にダウンロードして、その可用性を証明する必要があります。その後、DS はサンプリングを導入するため、各バリデーターはその一部のみをダウンロードします。
幸いなことに、最小限のシャーディングは、シャーディング 1.0 よりもシンプルな設計を意味します (非常に高速に配信されますよね?)。簡単に言うと、次のものが含まれます。
シャーディング 1.0 仕様と比較して、DS 仕様のコードはおそらく数百行少なくなります (クライアント側では数千行少なくなります)。
シャード委員会のインフラストラクチャはなく、委員会はメインチェーンにのみ投票する必要があります
個々のシャード BLOB の確認は追跡されません。それらはすべてメイン チェーンで確認されるか、追跡されません。
この素晴らしい結果として、データの統合料金市場が生まれます。異なる提案者によって作成された異なるブロックを使用して 1.0 をシャーディングすると、これが拡散します。dAMMシャード委員会の廃止により、贈収賄防止も強化されます。 DS バリデーターは、エポックごとにブロック全体に 1 回投票するため、データはバリデーター セット全体の 1/32 (エポックごとに 32 スロット) によって即座に確認されます。シャード 1.0 バリデーターもエポックごとに 1 回投票しますが、シャードごとに独自の委員会が再編成されます。したがって、各シャードはバリデーターセットの 1/2048 (1/32 を 64 シャードに分割) によってのみ確認されます。
前述のように、ブロックを 2D KZG コミットメント スキームと組み合わせると、DAS の効率も向上します。シャーディング 1.0 では、すべてのシャードの完全な DA をチェックするために 60 KB/秒の帯域幅が必要です。 DS は 2.5 KB/秒しか必要としません。
DS には、別の興味深い可能性が存在します。ZK ロールアップと L1 イーサリアム実行の間の同期呼び出しです。すべてが同じビーコン チェーン ブロック内で生成されるため、シャード BLOB からのトランザクションを確認して、すぐに L1 に書き込むことができます。シャーディング 1.0 では、個別のシャード確認によりこの可能性が排除されます。これにより、モビリティの共有に役立つエキサイティングなデザイン空間が可能になります（例:
）などは非常に価値があります。
モジュラーベースレイヤーは適切に拡張します。分散化が進むと、拡張性も高まります。これは私たちが今日見ているものとは根本的に異なります。 DA レイヤーにノードを追加すると、データ スループットを安全に向上させることができます (つまり、ロールアップが上に存在する余地が広がります)。
ブロックチェーンのスケーラビリティにはまだ限界がありますが、今日見たものよりも桁違いに改善することができます。安全でスケーラブルな基本層により、その上で実行を急増させることができます。データ ストレージと帯域幅の改善により、時間の経過とともにデータ スループットも向上します。
ここで想定されている DA スループットを超えることは確かに可能ですが、この最大値がどこに到達するかを言うのは困難です。明確な境界線はありませんが、いくつかの仮定が不快に感じられる領域があります。
Proto-danksharding (EIP-4844)
データ ストレージ - これは DA とデータの取得可能性に関するものです。コンセンサス層の役割は、データの取得可能性を無期限に保証することではありません。これは、セキュリティ上の前提条件を満たしながら、ダウンロードしたい人が誰でも十分な期間利用できるようにすることを目的としています。その後、それはどこにでもダンプされます。履歴は N 信頼仮定の 1 であり、物事の大局的な計画ではそれほど多くのデータを話しているわけではないので、これは快適です。スループットが数桁増加するため、数年以内にこれは厄介な領域に入る可能性があります。
Verifier - DAS には、ブロックを共同で再構築するのに十分なノードが必要です。そうしないと、攻撃者は待機して、受信したクエリにのみ応答する可能性があります。提供されたこれらのクエリがブロックを再構築するのに十分でない場合、攻撃者は残りを保持することができ、運が悪いです。スループットを安全に高めるには、DAS ノードを追加するか、データ帯域幅の要件を増やす必要があります。これは、ここで説明するようなスループットの問題ではありません。ただし、スループットがこの設計よりも数桁増加する場合、これは不快になる可能性があります。
ビルダーがボトルネックではないことに注意してください。 32 MB のデータに対して KZG プルーフを迅速に生成する必要があるため、少なくとも 2.5 GBit/s の帯域幅を備えた GPU または適度に強力な CPU が必要です。いずれにせよ、これは特殊な役割であり、ビジネスコストは無視できます。
DS は素晴らしいですが、忍耐が必要です。 PDS は私たちを乗り越えるように設計されています。DS に必要な上位互換性手順を (上海ハード フォーク向けの) 加速されたタイムラインで実装し、その間に桁違いのスケーリングを提供します。ただし、実際にはデータ シャーディングは実装されていません (つまり、バリデーターはすべてのデータを個別にダウンロードする必要があります)。
現在のロールアップでは、ストレージに L1 "calldata" が使用されており、オンチェーン上に永久に存在します。ただし、ロールアップに必要な DA は妥当な期間のみであるため、興味のある人は誰でもダウンロードするのに十分な時間があります。
EIP-4844 では、BLOB をサポートする新しいトランザクション形式が導入されており、将来のデータ ストレージにはロールアップが使用される予定です。 BLOB は大量のデータ (約 125 KB) を伝送し、同様の量の呼び出しデータよりもはるかに安価です。データ BLOB は 1 か月後にノードから削除されるため、ストレージ要件が軽減されます。これは、DA セキュリティの前提を満たすのに十分な時間です。
現在のイーサリアム ブロックは通常、平均約 90 KB (そのうち通話データは約 10 KB) です。 PDS は、1 か月後に削除される BLOB の DA 帯域幅 (目標 ~1 MB、最大 ~2 MB) のロックを解除します。これらはノード上で永続的に影響を与えるものではありません。
BLOB は 4096 個のフィールド要素のベクトルであり、各フィールド要素は 32 バイトです。 PDS ではブロックごとに最大 16 個が許可されますが、DS では 256 個まで増加します。
PDS DA 帯域幅 = 4096 x 32 x 16 = ブロックあたり 2 MiB、ターゲットは 1 MiB
DS DA 帯域幅 = 4096 x 32 x 256 = ブロックあたり 32 MiB、ターゲットは 16 MiB
データ BLOB を運ぶためのトランザクション形式
DS に必要なすべての実行層ロジック
DS に必要なすべての実行/コンセンサス相互検証ロジック
BLOB に対する KZG の取り組み
DS に必要なすべての実行層ロジック
DS に必要なすべての実行/コンセンサス相互検証ロジック
BeaconBlock 認証と DAS BLOB 間のレイヤー分離
PBS
DS に必要な BeaconBlock ロジックのほとんど
BLOB の独立したガス価格の自動調整 (指数関数的な価格設定ルールを備えた多次元 EIP-1559)
DS はさらに次のように付け加えます。
データ収集システム
2D KZG スキーム
各ブロック内のシャード データの特定部分の可用性を検証するための、各バリデーターに対する Proof of Escrow または同様のプロトコル内要件 (おそらく 1 か月程度)
これらのデータ BLOB は実行チェーン上の新しいトランザクション タイプとして導入されますが、実行側に追加の要件を課すものではないことに注意してください。 EVM は、BLOB にアタッチされたコミットメントのみを調べます。 EIP-4844 を使用して行われた実装層の変更も DS と上位互換性があるため、これに関して追加の変更は必要ありません。 PDS から DS にアップグレードするには、コンセンサス層を変更するだけで済みます。
データ BLOB は、PDS のコンセンサス クライアントによって完全にダウンロードされます。これで、BLOB は Beacon ブロック本体で参照されますが、完全にはエンコードされていません。コンテンツ全体を本文に埋め込む代わりに、BLOB のコンテンツは「サイドカー」として個別に伝播されます。各ブロックには PDS に完全にダウンロードされた BLOB サイドカーがあり、DS バリデーターを使用してその上で DAS を実行します。
以前に、KZG 多項式コミットメントを使用して BLOB をコミットする方法について説明しました。ただし、KZG を直接使用する代わりに、EIP-4844 は実際に使用するもの、つまりバージョン付きハッシュを実装します。これは、0x01 バイト (このバージョンを表す) に、KZG の SHA256 ハッシュの最後の 31 バイトが続きます。
これは、EVM の互換性と上位互換性を容易にするために行われます。
EVM の互換性 – KZG コミットメントは 48 バイトですが、EVM はより自然に 32 バイト値を使用します
前方互換性 - KZG から他のもの (STARK は量子耐性に使用できます) に切り替えた場合でも、これらの約束は 32 バイトのままで済みます。
PDS は最終的にカスタム データ レイヤーを作成します。データ BLOB には、個別の変動ガス価格と制限を備えた独自の料金市場があります。したがって、一部のNFTプロジェクトがL1で大量のサルの土地を販売したとしても、ロールアップデータのコストは上がりません（証明決済コストは上がりますが）。これは、今日のロールアップの主なコストはデータを L1 に公開すること (プルーフではない) であることを認めています。ガス料金市場は変わりませんが、データ BLOB が新しい市場として追加されます。BLOB 料金はガスで請求されますが、独自の EIP-1559 メカニズムに基づいて可変量調整されます。ブロックあたりの BLOB の長期平均数は、目標と同じである必要があります。
実際には、計算用と DA 用の 2 つのオークションが並行して実行されています。これは有効です
リソースの価格設定
巨大な飛躍。
興味深いデザインをいくつかご紹介します。たとえば、現在のガスと BLOB の価格設定メカニズムを線形 EIP-1559 から新しい指数関数的な EIP-1559 メカニズムに変更することが合理的である可能性があります。現在の実装では、実際には平均して目標ブロック サイズに達しません。現在、基本料金が完全に安定していないため、ブロックごとに観測された平均ガス使用量が目標を平均約 3% 上回っています。
パート II: 歴史と状態管理
ここでいくつかの基本を簡単に要約します。
歴史 — チェーン上で起こったすべてのこと。高速アクセスは必要ないため、ハードドライブに貼り付けることができます。長期的には、N 人中 1 人が正直に考えます。
状態 - すべての当座預金残高、スマートコントラクトなどのスナップショット。 (現時点では) フルノードはすべて、トランザクションを検証するためにこれを必要とします。 RAM には大きすぎますし、ハード ドライブは遅すぎます。SSD 内にあります。高スループットのブロックチェーンは、その状態を私たちの平均的な人がラップトップに保存できる量をはるかに超えて膨張させます。毎日のユーザーが状態を保持できない場合、完全に検証できないため、分散化に別れを告げます。
Calldata Gas コストの削減と Calldata の合計制限 (EIP-4488)
EIP-4488 には 2 つの主要コンポーネントがあります。
PDS は DS への重要な足がかりであり、多くの最終要件をチェックします。適切な期間内に PDS を実装すると、DS のスケジュールを早めることができます。
より簡単なバンドエイドの実装は EIP-4488 です。それほどエレガントではありませんが、それでも料金に関する緊急事態は解決されます。残念ながら、DS の実装プロセスにはステップが実装されていないため、避けられない変更はすべて後で必要になります。 PDS が期待よりも少し遅くなりそうだと感じ始めた場合は、すぐに EIP-4488 に合格し (数行のコード変更だけです)、約 6 か月後に PDS を実装するのが合理的かもしれません。具体的なスケジュールはまだ決まっていない。
EIP-4488 には 2 つの主要コンポーネントがあります。
通話データのコストをバイトあたり 16 ガスからバイトあたり 3 ガスに削減
ブロックごとに 1 MB の呼び出しデータの制限と、トランザクションごとにさらに 300 バイトが追加されます (理論上の最大値は約 1.4 MB)。
最悪のケースを防ぐために制限を追加する必要があります。呼び出しデータでいっぱいのブロックは 18 MB に達しますが、これはイーサリアムが処理できる容量をはるかに超えています。 EIP-4488 はイーサリアムの平均データ容量を増加させますが、このコールデータ制限 (3,000 万ガス / コールデータ バイトあたり 16 ガス = 1.875 MB) により、そのバースト データ容量は実際にはわずかに減少します。
EIP-4488 の持続的な負荷は、PDS よりもはるかに高くなります。これは、これが依然として calldata と BLOB (1 か月後に削除できるデータ) であるためです。 EIP-4488 は歴史的な成長を大幅に加速し、ノード実行のボトルネックになります。 EIP-4444 が EIP-4488 とともに実装された場合でも、実行負荷履歴は 1 年後にのみ削除されます。 PDS に対する持続的な負荷が低いことが明らかに望ましいです。
実行クライアントで履歴データをバインドする (EIP-4444)
EIP-4444 クライアントが 1 年以上古い履歴データ (ヘッダー、本文、レシート) をローカルで削除することを選択できるようにします。クライアントは、これらのプルーニングされた履歴データを p2p レイヤーで提供することを停止する必要があります。履歴をプルーニングすることで、ユーザーのディスク ストレージ要件 (現在数百ギガバイト、さらに増加中) を削減できます。devp2pこれはすでに重要ですが、EIP-4488 が実装されると (歴史が大幅に成長するため)、ほぼ必須になります。いずれにせよ、これが比較的早く完了することを願っています。最終的には何らかの形で履歴の有効期限が必要になるため、これに対処する良い機会となります。
チェーンの完全な同期には履歴が必要ですが、新しいブロックの検証には履歴は必要ありません (状態のみが必要です)。したがって、クライアントがチェーンの最上位に同期すると、JSON-RPC 経由で明示的に要求された場合、またはピアがチェーンの同期を試みた場合にのみ履歴データが取得されます。 EIP-4444 が実装されたので、これらに対する代替ソリューションを見つける必要があります。
クライアントは現在のものを使用できなくなります。
「完全同期」を実行します。代わりに、ジェネシスブロックと見なされる弱い主観性チェックポイントから「チェックポイント同期」を実行します。
弱い主観性は追加の仮定ではないことに注意してください。いずれにしても、それは PoS への移行に固有のものです。リモート攻撃の可能性があるため、これは効果的に弱い主観性チェックポイントを使用して同期する必要があります。ここでの前提は、クライアントが無効または古い弱い主観性チェックポイントから同期しないことです。このチェックポイントは、履歴データの削除を開始する期間内 (つまり、ここでは 1 年以内) である必要があります。そうしないと、P2P レイヤーは必要なデータを提供できなくなります。
また、軽量同期戦略を採用するクライアントが増えるにつれて、ネットワーク上の帯域幅の使用量も削減されます。
履歴データの取得
EIP-4444 では 1 年後に履歴データをプルーニングするのは良いように思えますが、PDS は BLOB をより速く (約 1 か月後) プルーニングします。これらすべてをノードに保存して分散した状態に保つように要求することはできないため、これらは絶対に必要です。
EIP-4488 – 長期的にはスロットあたり約 1 MB が含まれる可能性があり、年間約 2.5 TB のストレージが追加されます
DS – スロットあたり最大 16 MB を目標としており、年間最大 40 TB のストレージを追加します
個人および団体のボランティア
しかし、データはどこに行ったのでしょうか?もう必要ないのでしょうか？はい、ただし、履歴データの損失はプロトコルに対するリスクではなく、単一のアプリケーションに対するリスクであることに注意してください。したがって、イーサリアムコアプロトコルの仕事は、すべてのコンセンサスデータを永久に維持することではありません。
では、誰がそれを保管するのでしょうか？潜在的な貢献者は次のとおりです。
個人および団体のボランティア
エクスプローラー (etherscan.io など)、API プロバイダー、その他のデータ サービスをブロックします。
TheGraph のようなサードパーティのインデックス作成プロトコルは、クライアントが過去のデータやマークル証明に対してサーバーに料金を支払うことができるインセンティブ市場を生み出すことができます。
ポータル ネットワーク (現在開発中) のクライアントはチェーン履歴のランダムな部分を保存でき、ポータル ネットワークは自動的にデータ要求をそれを所有するノードに送信します。
たとえば、ビットトレント。ブロックからの BLOB データを含む 7 GB ファイルが毎日自動的に生成され、配布されます。
Rollup などのアプリケーション固有のプロトコルでは、アプリケーションに関連する履歴の部分をノードに保存することが要求される場合があります。
長期データ ストレージの問題は、前に説明した 1/N の信頼仮定により、比較的単純です。ブロックチェーンのスケーラビリティが究極の限界に達するまでには、まだ何年もかかります。
弱い無国籍者
さて、履歴管理はうまく処理できましたが、状態はどうなるのでしょうか?実は現状の問題はイーサリアムのTPS向上における主なボトルネックとなっている。
フルノードは、状態前のルートを取得し、ブロック内のすべてのトランザクションを実行し、状態後のルートがブロック内で提供されたものと一致することを確認します。これらのトランザクションが有効かどうかを知るには、現在、手元にある状態が必要です。検証はステートフルです。
国家のない時代が到来します - 私たちは機能するために国家を必要としません。イーサリアムは「弱ステートレス」を目指しています。これは、ブロックを検証するために状態は必要ありませんが、ブロックを構築するには状態が必要であることを意味します。検証は純粋な関数になります。完全に分離されたブロックを与えてください。それが機能するかどうかを教えてください。基本的には次のようなものです。
PBS のため、ビルダーが引き続き状態を必要とすることは許容されます。いずれにしても、ビルダーはより集中化された高リソースのエンティティになります。分散型バリデーターに焦点を当てます。ステートレス性が弱いと、ビルダーの作業が増加し、バリデータの作業が大幅に減ります。これは大きなトレードオフです。
あなたは目撃者とともにこの魔法のような無国籍の処刑を達成します。これらは、ビルダーが各ブロックに組み込み始める正しい状態アクセスの証明です。実際には、ブロックを検証するために状態全体が必要なわけではありません。必要なのは、読み取られた状態、またはそのブロック内のトランザクションの影響を受けた状態だけです。ビルダーは、トランザクションの影響を受ける状態の一部を特定のブロックに含め始め、監視を介してその状態に正しくアクセスしたことを証明します。
例を挙げてみましょう。アリスはボブに 1 ETH を送金したいと考えています。このトランザクションでブロックを検証するには、次のことを知る必要があります。
取引前 - アリスは 1 ETH を持っています
アリスの公開鍵 - 署名が正しいことがわかります
アリスのノンス - トランザクションが正しい順序で送信されたことがわかります
トランザクションの実行後 - ボブは 1 ETH を獲得し、アリスは 1 ETH を失いました
弱くステートレスな世界では、建設者は前述の目撃データをブロックに追加し、その正確性を証明します。バリデーターはブロックを受け取り、実行し、それが有効かどうかを判断します。それだけです！
バリデーターの観点から見た場合の意味は次のとおりです。
今日のスケーリングにおける重大なボトルネックである、状態を保持するための膨大な SSD 要件はなくなりました。
証人データと証明書もダウンロードするため、帯域幅要件が増加します。これは Merkle-Patricia ツリーのボトルネックですが、中程度であり、Verkle の試みのボトルネックではありません。
Verkle Tries
完全に検証するには、引き続きトランザクションを実行します。ステートレス性は、現時点ではイーサリアムのスケーリングにおけるボトルネックではないことを認めています。
また、弱いステートレス性により、イーサリアムは実行スループットに対して自ら課した制約を緩和することができ、ステートの肥大化はもはや差し迫った懸念事項ではなくなります。ガス制限を約 3 倍に増やすことが合理的である可能性があります。
いずれにせよ、ほとんどのユーザーの実行は L2 上で行われますが、L1 スループットの向上は、ユーザーにとっても依然として有益です。ロールアップは、DA (シャードへの公開) と決済 (L1 実行が必要) にイーサリアムに依存します。イーサリアムが DA レイヤーを拡張するにつれて、プルーフ発行の償却コストがロールアップコストに占める割合が大きくなる可能性があります (特に ZK ロールアップの場合)。
これらの証言が実際にどのように機能するかについては説明しません。イーサリアムは現在、状態を表すためにマークル-パトリシアツリーを使用していますが、必要なマークル証明は大きすぎて、これらの証人にとって実用的ではありません。
イーサリアムは Verkle に頼って状態の保存を試みます。 Verkle 証明ははるかに効率的であるため、実行可能な証人として弱くステートレスにすることができます。
まず、マークル ツリーがどのようなものかを確認してみましょう。すべてのトランザクションはハッシュ化されます。下部にあるこれらのハッシュは「リーフ」と呼ばれます。すべてのハッシュは「ノード」と呼ばれ、その下の 2 つの「子」ノードのハッシュです。結果として得られる最終ハッシュは「マークル ルート」です。
これは、ツリー全体をダウンロードせずに、含まれるトランザクションを証明するのに便利なデータ構造です。たとえば、トランザクション H4 が含まれていることを確認したい場合、必要なのはマークル証明の H12、H3、および H5678 のみです。ブロックヘッダーから H12345678 が得られます。したがって、ライトクライアントはフルノードにこれらのハッシュを要求し、ツリー内のルートに基づいてハッシュ化されます。結果が H12345678 であれば、H4 がツリー内にあることが証明されました。
ただし、木の深さが深いほど、底までの道が長くなるため、それを証明するにはより多くのアイテムが必要になります。したがって、効率的な証明には浅くて広いツリーが好ましいと思われます。
問題は、各ノードの下にさらに多くの子を追加してマークル ツリーの幅を広げようとすると、非常に非効率になることです。ツリーに登るにはすべての兄弟を一緒にハッシュする必要があるため、マークル証明のためにさらに多くの兄弟ハッシュを受け取る必要があります。これにより、プルーフサイズが巨大になります。
ここで効率的なベクトル Promise が登場します。マークル ツリーで使用されるハッシュは実際にはベクトル コミットメントであることに注意してください。実質的には 2 つの要素のみに対するコミットです。したがって、ベクトルコミットメントが必要なので、それを検証するためにすべての兄弟を受け取る必要はありません。それができたら、ツリーの幅を広くし、深さを減らすことができます。このようにして、有効な校正サイズを取得し、提供する必要がある情報の量を削減します。
Verkle トライはマークル ツリーに似ていますが、単純なハッシュの代わりに効率的なベクトル コミットメント (そのため「Verkle」という名前) を使用して子にコミットします。したがって、基本的な考え方は、各ノードが多数の子を持つことができるが、証明を検証するためにすべての子を必要とするわけではないということです。幅に関わらず一定の大きさである証です。
実際、これらの可能性の 1 つの良い例を以前に取り上げました。KZG コミットメントはベクトル コミットメントとしても使用できます。実際、これはイーサリアム開発者が当初ここで使用する予定だったものです。それ以来、彼らは同様の任務をペダーセンに依頼した。これらは楕円曲線 (この場合はバンダースナッチ) に基づいており、それぞれ 256 個の値を送信します (2 つよりもはるかに優れています!)。
では、なぜ可能な限り広い深さのツリーを持たないのでしょうか?これは、非常にコンパクトなプルーフを持っているバリデーターにとって最適です。ただし、証明者が証明を計算できる必要があり、証明の範囲が広ければ広いほど困難になるという実際的なトレードオフがあります。したがって、これらの Verkle の試みは、256 の値幅の両極端の間に位置します。
ステータスの有効期限が切れます
弱いステートレス性はバリデーターのステートインフレ制約を取り除きますが、ステートは魔法のように消えるわけではありません。トランザクションコストは限られていますが、状態を増加させることでネットワークに恒久的な税金を課します。状態の増大は、依然としてネットワークに永続的な影響を及ぼします。根本的な問題を解決するには、何かを行う必要があります。
ここで状態が終了します。長期間（1 年や 2 年など）非アクティブな場合は、ブロックビルダーが運ぶ必要のあるものさえ削減されます。アクティブなユーザーは何も気付かず、不要になった役に立たない状態は破棄できます。
期限切れステータスを復元する必要がある場合は、証明を提示して再アクティブ化するだけです。これは、1 of N のストレージの仮定に戻ります。誰かがまだ完全な履歴 (ブロック エクスプローラーなど) を持っている限り、必要なものをその人から入手できます。
ステートレス性が弱いと、基本層での即時の状態有効期限の必要性が弱まりますが、特に L1 スループットが増加するため、長期的には良いことになります。これは、高スループットのロールアップにとってより便利なツールです。 L2 状態は桁違いに速い速度で増加し、高性能ビルダーさえも足を引っ張ってしまいます。
パート III - MEV
PBS は DS を安全に実装するために必要ですが、実際にはもともと MEV の集中力に対抗するために設計されたものであることを思い出してください。今日のイーサリアム研究では繰り返し傾向が見られるでしょう。MEV は現在、暗号経済学の最前線であり中心となっています。
MEV を使用したブロックチェーンの設計は、セキュリティと分散化を維持するために重要です。基本的なプロトコルレベルのメソッドは次のとおりです。
有害な MEV を可能な限り最小限に抑える (例: 単一スロットのファイナリティ、単一のシークレット リーダー選挙)
残りの部分 (MEV-Boost、PBS、MEV スムージングなど) を民主化する
残りは簡単に取得してバリデーター間で伝達できる必要があります。それ以外の場合は、複雑な検索機能と競合できないため、バリデータ セットを一元化します。これは、結合された MEV がバリデーター報酬のより高いシェアを持つという事実によってさらに悪化します (ステーキング発行はマイナーに与えられるインフレ率よりもはるかに低い)。無視することはできません。
今日の MEV サプライチェーン
本日の一連の流れは以下の通りです。
MEV-Boost
ここではマイニングプールがビルダーの役割を果たします。 MEV Seeker は、Flashbot を介してトランザクション バンドル (およびそれぞれの入札) をプールに中継します。マイニング プール オペレーターは完全なブロックを集約し、ブロック ヘッダーを個々のマイナーに渡します。マイナーは、PoW を通じてフォーク選択ルールに重みを与えることでこれを証明します。
Flashbot は、スタック全体の垂直統合を防ぐためにここにいます。これは検閲やその他の厄介な外部性への扉を開くことになります。 Flashbot が登場したとき、マイニングプールはすでに MEV を抽出するために商社と独占契約を結び始めていました。代わりに、Flashbot により、MEV 入札を集約し、(MEV-geth を実装することで) 垂直統合を回避する簡単な方法が提供されました。
イーサリアムの合併後、マイニングプールは消滅します。私たちは、自宅でも合理的に機能できるバリデーターノードへの扉を開きたいと考えています。そのためには、専用のビルド ロールを担う人を見つける必要があります。ホームバリデーターノードは、定量化された給与を持つヘッジファンドほど MEV を捕捉するのが得意ではない可能性があります。チェックしないままにすると、一般の人が競争できない場合、バリデータ セットが集中化されます。適切に構造化されていれば、プロトコルは MEV の収益を毎日のバリデーター ステーキング報酬にリダイレクトできます。
残念ながら、協定内の PBS は合併の準備ができていませんでした。 Flashbots は再び、踏み台となるソリューションである MEV-Boost を提供します。
マージされたバリデーターは、デフォルトでパブリック メモリプール トランザクションを実行クライアントに直接受け取ります。これらをパッケージ化してコンセンサスクライアントに提供し、ネットワークにブロードキャストできます。 (イーサリアムのコンセンサスクライアントと実行クライアントがどのように連携するかを理解する必要がある場合は、パート IV で説明します)。
しかし、先ほど説明したように、バリデーターは MEV を抽出する方法を知らないため、Flashbot は別のオプションを提供します。 MEV-boost はコンセンサス クライアントにプラグインされ、特殊なブロック構築をアウトソーシングできるようになります。重要なのは、独自の実行クライアントをフォールバックとして使用するオプションがまだあるということです。
MEV Seekers は、現在と同じように機能し続けます。彼らは特定の戦略 (統計的裁定取引、アトミック裁定取引、サンドイッチなど) を実行し、バンドルに入札します。次に、ビルダーは、目にしたすべてのバンドルと、あらゆるプライベート注文ストリーム (Flashbots Protect からなど) を最適な完全なブロックに集約します。ビルダーは、MEV-Boost へのリレーを介してブロック ヘッダーをバリデーターに渡すだけです。 Flashbots はリレーラーとビルダーを実行する予定であり、時間をかけて分散化する予定ですが、他のビルダーをホワイトリストに登録するのは時間がかかる可能性があります。
MEV-Boost では、バリデータがリレーラーを信頼することを要求します。コンセンサス クライアントはブロック ヘッダーを受信し、署名してから、ブロック本文を表示します。中継者の目的は、検証者が構築者を直接信頼する必要がないように、本体が有効で存在することを提案者に証明することです。プロトコル内 PBS の準備が完了すると、その間に MEV-Boost によって提供されたコンテンツが組み込まれます。 PBS は同様の権力分立を提供するため、構築者の分散化が容易になり、提案者が誰かを信頼する必要がなくなります。。
委員会主導の MEV 平滑化
PBS はまた、別の素晴らしいアイデアへの扉を開きました --
委員会主導の MEV 平滑化
MEV を抽出する機能はバリデータ セットの集中力ですが、配布も同様であることがわかります。ブロックごとの MEV 報酬のばらつきが大きいため、報酬を平準化するために多くのバリデーターをプールする動機になります (今日のマイニング プールで見られるように、ここでは程度は低いですが)。
デフォルトでは、実際のブロック提案者にビルダーの全額が支払われます。 MEV スムージングは代わりに、支払いを多くのバリデーターに分散します。検証委員会は提案されたブロックをチェックし、これが本当に最高入札額のブロックであるかどうかを証明します。すべてがうまくいけば、ブロックは進行し、報酬は委員会と提案者の間で分割されます。
これにより、別の問題である範囲外の贈収賄も解決されます。たとえば、提案者は、自分たちの支払いを委任者から隠すために、次善のブロックを提出したり、帯域外の賄賂を直接受け取ったりするよう奨励される可能性があります。この証明により提案者を確認することができます。
プロトコル内 PBS は MEV スムージングの前提条件です。建設業者の市場と提出された明確な入札を理解する必要があります。ここには未解決の研究上の疑問がいくつかありますが、これは分散型バリデーターを確保するために再び重要となる刺激的な提案です。
単一スロットのトランザクションのファイナリティ
速いファイナリティは素晴らしいです。最大 15 分間待つことは、UX またはクロスチェーン通信にとって最適ではありません。さらに重要なのは、これにより MEV の再組み立ての問題が発生することです。
統合されたイーサリアムはすでに現在よりも強力な証拠を提供しています。何千人ものバリデーターが各ブロックをマイナーと競合し、おそらく投票せずに同じブロックの高さでマイニングしていることを証明しています。そうなると再編の可能性は極めて低くなるだろう。ただし、これはまだ真のトランザクションのファイナリティではありません。最後のブロックにファット MEV が含まれていた場合、バリデーターを騙してチェーンを再編成し、自分たちのためにそれを盗もうとする可能性があります。
ここでは基本的なメカニズムについてはあまり詳しく説明しません。シングル スロット ファイナリティはイーサリアムのロードマップのかなり先まで開発されており、非常にオープンな設計空間です。ここ現在のコンセンサスプロトコル (スロットファイナリティなし) では、イーサリアムは各スロットを証明するためにバリデーターの 1/32 のみを必要とします (現在約 380,000 のうち約 12,000)。この種の投票を単一スロット内の BLS 署名で集約された完全なバリデーター セットに拡張するには、より多くの作業が必要になります。これにより、数十万の投票が 1 つの検証に凝縮されます。
ヴィタリックさんは
ここ
いくつかの興味深いソリューションを詳しく説明します。
単一シークレットリーダー選挙 (SSLE)
SSLE は、合併後に直面することになる別の MEV 攻撃ベクトルにパッチを当てようとします。
ビーコンチェーン検証者のリストと今後のリーダー選挙のリストは公開されており、匿名化を解除して IP アドレスをマッピングするのは簡単です。おそらくここで問題がわかるでしょう。
より高度なバリデーターは、トリックを使用して自分自身をよりうまく隠すことができますが、小規模なバリデーターは、doxx やその後の DDOSd に対して特に脆弱です。これは MEV に簡単に使用できます。
あなたがブロック n の提案者で、私がブロック n+1 の提案者であるとします。あなたの IP アドレスが分かれば、安価に DDOS を実行して、タイムアウトしてブロックの生成に失敗するようにすることができます。これでスロットの MEV をキャプチャし、報酬を 2 倍にすることができます。これは、EIP-1559 の柔軟なブロック サイズ (ブロックあたりの最大ガスはターゲット サイズの 2 倍) によってさらに悪化するため、本来 2 ブロックであるはずのトランザクションを 2 倍の長さの 1 つのブロックに詰め込むことができます。
パート IV - 合併
統合されたクライアント
まあ、誤解のないように言っておきますが、私は冗談でした。私は実際、イーサリアムの合併は比較的早く起こったと考えています（願っています）。
私たちは皆この話題について話しているので、少なくとも簡単な紹介をする義務があると感じています。
統合されたクライアント
現在、すべてを処理するモノリシック クライアント (Go Ethereum、Nethermind など) を実行しています。具体的には、フル ノードは次の操作を同時に実行します。
実行 - ブロック内のすべてのトランザクションは、有効性を保証するために実行されます。状態前のルートを取得し、すべての操作を実行し、結果の状態後のルートが正しいことを確認します。
コンセンサス - 最も多くの作業を実行する最も重い (最も高い PoW) チェーン (つまり、Satoshi コンセンサス) 上にいることを確認します。
フルノードは最も重いチェーンだけでなく、最も重い有効なチェーンにも従うため、これらは分割できません。これが、これらがライト ノードではなくフル ノードである理由です。 51% 攻撃が発生した場合でも、フル ノードは無効なトランザクションを受け入れません。
ビーコン チェーンは現在、PoS をテスト実行するためのコンセンサスのみを実行しています。実行は含まれません。最終的な合計難易度は最終的に決定され、その時点で現在のイーサリアム実行ブロックがビーコン チェーン ブロックにマージされてチェーンが形成されます。
ただし、フル ノードはバックグラウンドで 2 つの個別のクライアントを実行し、相互運用できます。
実行クライアント (別名「Eth1 クライアント」) - 現在の Eth 1.0 クライアントは実行の処理を継続します。これらはブロックを処理し、メモリ プールを維持し、状態を管理および同期します。 PoWの部分が切り取られていました。
コンセンサス クライアント (別名「Eth2 クライアント」) - PoS コンセンサスの処理を継続する現在のビーコン チェーン クライアント。彼らはチェーンの先頭を追跡し、噂話をし、ブロックを証明し、バリデーターの報酬を獲得します。
クライアントはビーコン チェーン ブロックを受信し、クライアント実行トランザクションを実行します。すべてがうまくいけば、コンセンサス クライアントがチェーンに従います。選択した実行クライアントとコンセンサス クライアントを組み合わせて使用することができ、そのすべてが相互運用可能になります。クライアントが相互に通信するための新しいエンジン API が導入されます。
または：
合併後のコンセンサス
マージされたイーサリアムは、コンセンサスを得るために、Casper FFG (ファイナリティ ツール) と LMD GHOST (フォーク選択ルール) を組み合わせた GASPER に移行しました。ここでの TLDR は、セキュリティではなく、コンセンサスを優先する活発性です。
結論は
違いは、セキュリティに優しいコンセンサス アルゴリズム (Tendermint など) は、必要な投票数 (ここではバリデーターの 2/3 に設定) を取得できない場合に停止することです。有利なチェーンの活性化 (例: PoW + ナカモトのコンセンサス) はいずれにしても楽観的な台帳を構築し続けますが、十分な投票がなければファイナリティに達することはできません。今日のビットコインとイーサリアムは決して最終決定されていません。十分な数のブロックがなければ再組織化は行われないと考えているだけです。
ただし、イーサリアムは十分な投票があれば定期的なチェックポイントを通じてファイナリティも達成します。 32 個の ETH インスタンスはそれぞれ 1 つのバリデーターであり、すでに 380,000 を超えるビーコン チェーン バリデーターが存在します。エポックは 32 のスロットで構成され、すべてのバリデーターが特定のエポック内のスロットを分割して証明します (スロットあたり最大 12,000 プルーフを意味します)。次に、フォーク選択ルール LMD Ghost は、これらの証明に基づいてチェーンの現在のヘッドを決定します。新しいブロックはスロット (12 秒) ごとに追加されるため、エポックは 6.4 分になります。通常、必要な投票が得られた 2 エポック (つまり、64 スロット、ただし最大 95 が必要な場合もあります) 後にファイナリティが達成されます。
