Delphi Digital: 業界で最も完全なイーサリアム上級ガイド

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

Delphi Digital: 業界で最も完全なイーサリアム上級ガイド

DAOrayaki

2022-06-20 14:00

本文约24141字，阅读全文需要约97分钟

この記事を当然のことと考えるべきではありません。イーサリアムの野心的なロードマップを幅広く微妙に知りたい場合は、1 時間お時間をいただければ、数か月の作業を節約できます。

著者: ジョン・シャルボノー

原題: The Hitchhiker's Guide to Ethereum

核心点:

イーサリアムは、スケーラブルな統合決済層とデータ可用性層の構築を目的とした唯一の主要プロトコルです
ロールアップはイーサリアムのセキュリティを活用しながら計算をスケールアップします
すべての道は、集中化されたブロック生成、分散化されたトラストレスブロック検証、および検閲への抵抗という最終目標につながります。
イニシエーターとビルダーの分離や弱い無国籍などのイノベーションは、セキュリティや分散化の目標を犠牲にすることなくスケーラビリティを達成できる権力の分離 (構築と検証) をもたらします。
現在、MEV は最前線であり中心的存在です - 設計の多くは、その害を軽減し、集中化の傾向を防ぐように計画されています
Danksharding は、最先端の研究に対する複数のアプローチを組み合わせて、イーサリアムのロールアップ中心のロードマップに必要なスケーラブルなベースレイヤーを提供します
目次

ヴィタリック氏が、今日生まれた人は西暦3000年まで生きる確率が50～75％で、永遠に生きたいと願っていると述べて以来、私は合併のタイミングについてかなり懐疑的だった。しかし、何ということでしょう、楽しみましょう。この機会にイーサリアムの野心的なロードマップを詳しく見てみましょう。

イーサリアムの研究には追跡すべきことがたくさんありますが、それらはすべて、分散型検証を犠牲にすることなく計算をスケーリングするという 1 つの包括的な目標に結びついています。

ヴィタリックには有名な「終盤」の格言がありますが、聞いたことがあるかどうかはわかりません。同氏は、イーサリアムのスケーリングにはある程度の集中化が必要であることを認めた。ブロックチェーンにおいて、集中化を表す C の文字は恐ろしいものですが、それは現実です。私たちが必要なのは、分散型でトラストレスな検証によってこの力を制御することだけです。ここには妥協はありません。

プロはL1以降に追加します。イーサリアムはシンプルな分散型検証により信じられないほどの安全性を維持しますが、ロールアップは L1 からセキュリティを継承します。その後、イーサリアムは決済とデータの可用性を提供し、ロールアップの拡張を可能にします。ここでのすべての研究は最終的に、これら 2 つの役割を最適化すると同時に、ブロックチェーンの完全な検証をこれまでより簡単にすることを目的としています。

次の用語が約 7 ～ 859 回繰り返されます。

DA – データの可用性データの可用性
DAS – データ可用性サンプリングデータ可用性サンプリング
PBS – 提案者と構築者の分離開始者と構築者の分離
PDS – プロトダンクシャーディングネイティブダークシャーディング
DS – イーサリアムシャーディング設計のダンクシャーディング
PoW – Proof of Work ワークロードの証明
PoS – プルーフ・オブ・ステークの誓約証明

第1部ダンクシャーディングへの道

イーサリアムがロールアップ中心のロードマップに移行したことを聞いたことがあると思います。実行シャードはもうありません - イーサリアムは代わりに、大量のデータを必要とするロールアップを最適化します。これは、データシャーディング (イーサリアムの計画の一部) またはより大きなブロック (セレスティアの計画) を通じて実現されます。

コンセンサス層はシャーディングされたデータを解釈しません。ジョブは 1 つだけで、データが利用可能であることを確認します。

ロールアップ、不正行為、ZK 証明などの基本的な概念と、DA (データ可用性) が重要な理由を理解していることを前提とします。よく知らない場合、または復習が必要な場合は、Can の最近の Celestia レポートを参照してください。

オリジナルのデータシャーディング設計 - 独立したシャーディング提案

ここで説明されているデザインは時代遅れですが、背景を知るために一見の価値があります。簡単にするために、これを「シャーディング 1.0」と呼びます。

64 のシャードにはそれぞれ、バリデーターのセットからローテーションされる個別の提案と委員会があります。彼らは、シャードのデータが利用可能であることを独自に検証します。最初は DAS (データ可用性サンプリング) ではありません。データを完全にダウンロードするには、各シャードのバリデーターセットの正当な大多数に依存します。

この設計により、不必要な複雑さが生じ、ユーザーエクスペリエンスが低下し、攻撃のベクトルが生じます。シャード間でバリデータを再編成することは危険を伴う可能性があります。

また、非常に厳密な同期前提を導入しない限り、単一スロット内で投票が行われることを保証することも困難です。ビーコンブロックの提案には、個々の委員会の投票をすべて集める必要があり、遅れる可能性があります。

(元のデータシャーディング設計では、各シャードは委員会の投票によって確認されます。投票は常に 1 つのスロットで行われるわけではなく、シャードは最大 2 エポックまで確認できます)

DS（ダンクシャルディング）とは全く違います。バリデーターは DAS を実施し、すべてのデータが利用可能であることを確認します (個別のシャード委員会はもう必要ありません)。専用のビルダー (Builder) は、Beacon ブロックとすべての断片化されたデータを使用して、大きなブロックを作成し、それを確認します。したがって、DS が分散型を維持するには PBS (提案と構築者の分離) が必要です (その大きなブロックを一緒に構築するのはリソースを大量に消費します)。

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

ロールアップは大量のデータを公開しますが、すべてのデータをダウンロードするためにノードに負担をかけたくありません。これは、高いリソース割り当てを意味し、それによって分散化が損なわれることになります。

代わりに、DAS を使用すると、ノード (ライトクライアントでも) がすべてのデータをダウンロードすることなく、すべてのデータが利用可能であることを簡単かつ安全に検証できます。

単純な解決策 - ブロックからランダムな部分をチェックするだけです。問題なければ署名だけして終了です。しかし、取引を逃して、ETH をすべて悪者に流出させてしまったらどうなるでしょうか?これは安全でしょうか（さふ）。
賢い解決策 - 最初にデータを消去コード化します。データはリードソロモンコードを使用して展開されます。これは、データが多項式として補間され、他の場所で評価できることを意味します。これは少し複雑なので、分解してみましょう。

数学のことは心配しないでください。ここは短期集中コースです。 (ここでの数学はそれほど怖くないと約束します。これらの部分を書くためにカーンアカデミーのビデオをいくつか見る必要がありましたが、今では私でも理解できます)。

多項式は、の形式の有限数の項を加算した式です。用語の数は最高のインデックスを表します。たとえば、 + + - 4 は 3 次多項式です。多項式上の任意の座標から任意の次数多項式を再構築できます。

次に、具体的な例を見てみましょう。以下に 4 つのデータブロック (to) があります。これらのデータブロックは、特定の点での多項式の値にマッピングできます。たとえば、=。次に、これらの値を満たす最小次数多項式を見つけます。これは 4 つのデータブロックであるため、3 次の多項式を求めることができます。次に、同じ多項式にある 4 つの値 ( から ) を追加することで、このデータを拡張できます。

重要な多項式の特性を思い出してください。元の 4 つのチャンクだけでなく、任意の 4 つの点から多項式を再構築できます。

DAS に戻ります。ここで必要なのは、消去符号化されたデータの 50% (4/8) が使用可能であることを確認することだけです。これから、データブロック全体を再構築できます。

したがって、攻撃者は、データが利用できないときに DAS ノードを騙して利用できるようにするには、データブロックの 50% 以上を隠蔽する必要があります。

ランダムなサンプリングが何度も成功した後は、データの 50% 未満が利用できる確率は非常に低くなります。消去符号化されたデータのサンプリングに 30 回成功した場合、そのデータが使用できる確率は 50% 未満です。

KZGのこだわり

OK、ランダムなサンプルを大量に作成しました。それらはすべて利用可能です。しかし、まだ疑問があります - データ消去は正しくコーディングされていますか?そうでなければ、ブロック生成者がブロックを拡張するときに 50% のゴミを追加しただけで、サンプリングは時間の無駄だったのかもしれません。この場合、実際にはデータを再構築することはできません。

通常、Merkle ルートを使用して大量のデータをコミットするだけです。これは、セットに一部のデータが含まれていることを証明するのに役立ちます。

ただし、すべての元のデータと拡張データが同じ低次の多項式上にあることも知っておく必要があります。メルケル首相はそれを証明できない。したがって、このスキームを使用する場合は、起こり得る間違いを防ぐために不正行為の証明も必要になります。

(マークルルートを使用すると、データとデータの拡張にコミットメントを行うことができますが、それらが同じ低次の多項式に該当するかどうかはわかりません)

開発者は、次の 2 つの方向でこの問題を解決できます。

Celestia は不正防止の道を進んでいます。この計画では誰かが監視する必要があり、ブロックが誤って消去符号化されている場合は、詐欺の証拠を提出して全員に警告します。これには、標準的な正直な少数派の仮定と共時性の仮定が必要です（つまり、誰かが私に不正行為の証拠を送ってくることに加えて、私がオンラインにいて有限の時間内にそれを受け取るだろうとも仮定する必要があります）。
Ethereum と Polygon Avail は、KZG コミットメント (別名 Kate コミットメント) という新しい道を歩んでいます。これにより、正直な少数派と共時性の仮定が削除され、不正行為の証明が安全に保たれます (ただし、それらはまだ存在しており、すぐに説明するように、再構成に使用されます)。

他の解決策もないわけではありませんが、あまり求められていません。たとえば、ZK プルーフを使用できます。残念ながら、それらは（現時点では）計算上非現実的です。ただし、今後数年間で改善されると予想されているため、KZGは量子耐性を持たないと約束しているため、将来的にはイーサリアムがSTARKに切り替わる可能性があります。

(皆さんはポスト量子 STARK の準備ができていないと思いますが、皆さんの次世代はそれを気に入るはずです)

KZG コミットメントに戻ります。これらは多項式コミットメントスキームです。

コミットメントスキームは、ある値へのコミットメントを証明可能にするための暗号化された方法にすぎません。最も分かりやすい例えは、鍵のかかった箱に手紙を入れて、それを他の人に渡すことです。手紙は一度入ったら変更できませんが、鍵で開けて証明することはできます。あなたは手紙にコミットします、そして鍵は証拠です。

私たちの場合、すべての元のデータと拡張データを X、Y グリッドにマッピングし、それらに適合する最小次数の多項式を見つけます (このプロセスはラグランジュ補間と呼ばれます)。この多項式は証明者が約束したものです。

(KZG コミットメントを使用すると、データとデータ拡張子に関するコミットメントを作成し、それらが同じ低次の多項式に当てはまることを証明できます)

いくつかの重要なポイント:

まず多項式があります
この多項式に対する証明者のコミットメント
これは、楕円曲線暗号の信頼できるセットアップに依存しています。これがどのように機能するかについては、Bartek からの素晴らしいスレッドがあります。
この多項式の任意の値について、証明者は証明を計算できます。
人間の言葉で言うと、証明者はこれらのフラグメントを任意の検証者に渡し、検証者は特定の点の値 (ここでの値は背後のデータを表します) が提出された多項式上に正しく配置されていることを確認できます。
すべての値が同じ多項式上にあるため、これにより元のデータへの拡張が正当化されます。
注: 検証者は多項式を使用する必要はありません。
重要なプロパティ — 準拠するコミットメントのサイズ、証明サイズ、および検証時間。証明者にとっても、コミットメントと証明の生成の複雑さはだけです。ここで、は多項式の次数です。
率直に言うと、(値の数が) 増加しても (つまり、データセットがシャードサイズとともに増加しても)、コミットメントとプルーフのサイズは一定のままで、検証に必要な作業量は一定です。
Promise と Proof は両方とも、ペアリングフレンドリーカーブ上の単なる楕円曲線要素です (ここでは BLS12-381 が使用されています)。この場合、それらはそれぞれわずか 48 バイトです (非常に小さい)。
したがって、証明者の大量の元データと拡張データ (多項式上の多くの値として表される) に対するコミットメントは依然としてわずか 48 バイトであり、証明もわずか 48 バイトになります。
簡単に言うと: 適度に拡張できる

ここで、KZG ルート (多項式コミットメント) はマークルルート (ベクトルコミットメント) に似ています。

元のデータは to での多項式の値であり、 to での多項式を評価することによってそれを拡張します。すべての点から同じ多項式上にあることが保証されます。

一言で言えば、DAS を使用すると、消去符号化されたデータが利用可能かどうかを確認できます。 KZG は、元のデータが正しくスケーリングされていることを証明し、すべてのデータを保証することを約束します。

さて、すべての代数はここで終わります。

KZG プロミスと不正防止

KZG がどのように機能するかを理解したところで、一歩下がって 2 つのアプローチを比較してみましょう。

KZG の欠点は、ポスト量子安全ではないことと、信頼できる初期化が必要なことです。これは心配する必要はありません。 STARK はポスト量子の代替手段を提供しますが、信頼できる初期化 (オープンな参加) には正直な参加者が 1 人だけ必要です。

KZG の利点は、不正防止セットアップよりもレイテンシが低いことです (ただし、前述したように、GASPER ではいずれにしても最終結果が速くありません)。不正防止に導入されることなく適切なコード消去が保証されます。固有の同期性と誠実性いくつかの仮定があります。

ただし、イーサリアムがブロックの再構築においてこれらの前提を依然として再導入していることを考えると、実際にはそれらを削除するわけではありません。 DA 層は常に、最初はブロックが利用可能であると想定する必要がありますが、その後、ブロックを元に戻すためにノードが相互に通信する必要があります。この再構成には 2 つの仮定が必要です。

データを結合するのに十分な能力を備えた、データをサンプリングする十分なノード (軽いまたは重い) がある。これはかなり弱く、避けられない正直な少数派の仮定であり、心配する必要はありません。
同期性の仮定が再導入されます。ノードは再構築される前に、一定の時間内に通信する必要があります。

Ethereum バリデーターは PDS (ネイティブダークシャーディング) でシャードデータを完全にダウンロードしますが、DS では DAS (指定された行と列のダウンロード) のみを実行します。 Celestia では、ブロック全体をダウンロードするためにバリデーターが必要です。

どちらの場合も、再構築には同期の仮定が必要であることに注意してください。ブロックが部分的にしか利用できない場合、完全なノードは他のノードと通信してそれらを結合する必要があります。

Celestia がデータ全体のダウンロードをバリデーターに要求することから、DAS のみを実行するように移行したい場合は、KZG のレイテンシの利点が有効になります (ただし、この移行は現在計画されていません)。次に、KZG コミットメントも実装する必要があります。不正行為の証明を待つということは、ブロック間隔を大幅に長くすることを意味し、バリデーターが誤ってエンコードされたブロックに投票する危険も高くなります。

KZG コミットメントがどのように機能するかをより深く理解するには、次の記事を読むことをお勧めします。

楕円曲線暗号の（比較的わかりやすい）基礎
Vitalikによる楕円曲線ペアリングの探索
Dankrad による KZG 多項式のコミットメント
Vitalik による信頼できる初期化の原則

プロトコル内でのイニシエーターとビルダーの分離

現在のコンセンサスノード (マイナー) とマージされたコンセンサスノード (検証者) は異なる役割を果たします。実際のブロックを構築し、検証のために他のコンセンサスノードに送信します。マイナーは前のブロックに「投票」し、マージ後、バリデーターはブロックが有効か無効かについて直接投票します。

PBS (イニシエーターとビルダーの分離) はこれらを分離し、新しいプロトコル内ビルダーロールを明示的に作成します。専任のビルダーがブロックを組み立て、オリジネーター (検証者) がブロックを選択するよう入札します。これは、MEV の集中力に対抗します。

Vitalik の「最終段階」を振り返ると、すべての道はトラストレスで分散型の検証を伴う集中型のブロック生成につながります。 PBS はさらに一歩進んでいます。ネットワークの有効性と検閲耐性を提供するには誠実なビルダーが必要です (2 人いるとより効果的です) が、バリデーターセットには誠実な過半数が必要です。 PBS は、バリデーターの分散化をサポートするために、イニシエーターの役割を可能な限りシンプルにします。

建設業者は優先料金チップと、引き出すことができる MEV を受け取ります。効率的な市場では、競争力のある建築業者は、ブロックから抽出できる最大の価値 (高価なハードウェアなどの償却コストを差し引いたもの) で入札するでしょう。すべての価値は分散されたバリデーターのセットに少しずつ伝わります。これはまさに私たちが望んでいることです。

正確な PBS 実装はまだ議論中ですが、2 スロット PBS は次のようになります。

ビルダーは入札中にヘッダーをブロックすることを約束します
ビーコンブロックの発信者は、勝者のブロックヘッダーと入札を選択します。製作者がブロック本体の製作に失敗した場合でも、入札者には無条件で落札代金が支払われます。
認証者委員会が勝者のブロックヘッダーを確認する
建設者は落札の主題を明らかにする
別の立会人委員会が優勝団体を選出します（優勝した建設者が団体を提示しない場合は、その存在がないことを証明するために投票します）。

イニシエーターは、標準の RANDAO メカニズムを使用してバリデーターグループから選択されます。次に、ブロックヘッダーが委員会によって確認されるまで全体が公開されないコミットメント開示戦略を使用します。

プロミス開示はより効率的であり (何百もの完全なブロックボディを送信すると、p2p 層の帯域幅を圧倒する可能性があります)、MEV の盗難も防止します。ビルダーが完全なブロックを送信すると、別のビルダーがそれを見て、その戦略を理解し、組み込んで、より優れたブロックを迅速に公開できます。さらに、高度なイニシエーターは、使用されている MEV 戦略を検出し、ビルダーを補償することなくそれを複製できます。この MEV の盗用がバランスをとる力になると、製造業者と開発者の合併を促すことになるため、これを避けるために当社はコミットメント開示戦略を採用しています。

開始者が勝者のブロックヘッダーを選択した後、それは委員会によって確認され、フォーク選択ルールで強化されます。次に、優勝したビルダーは、優勝した完全な「ビルダーブロック」ボディを公開します。期限内に公表されれば、次の委員会がそれを認定することになる。期限内に公開できなかった場合でも、発信者に全額を支払わなければなりません (そしてすべての MEV と手数料を失います)。この無条件の支払いにより、開始者は構築者を信頼する必要がなくなります。

この「デュアルスロット」設計の欠点は遅延です。マージされたブロックは固定の 12 秒になるため、新たな仮定を導入しなければ、完全なブロック時間 (12 秒スロット 2 つ) には 24 秒が必要になります。 8 秒のスロット (16 秒のブロック時間) はセキュリティ上の妥協のように思えますが、研究は進行中です。

検閲抵抗リスト (crList)

残念なことに、PBS は建設業者に取引を検討するための多大な能力を与えました。たぶん、建設業者はあなたのことが気に入らなかったので、あなたの契約を無視したのかもしれません。もしかしたら、他のビルダーがあまりにうまく機能するので断念するかもしれません。あるいは、あなたが気に入らないためにブロックの価格を高く設定しているのかもしれません。

crLists はこれを防ぎます。具体的な実装はやはりオープンな設計空間ですが、「ハイブリッド PBS」が最も人気があるようです。ビルダーは、mempool 内で確認できるすべての適格なトランザクションのリストを指定します。ビルダーは、(ブロックがいっぱいでない限り) ブランケットトランザクションを受け入れることを強制されます。

イニシエーターは、対象となるすべてのトランザクションを含む crList と crList ダイジェストを公開します。
ビルダーは提案されたブロック本体を作成し、それを見た証拠として crList ダイジェストのハッシュを含む入札を送信します。
開始者は落札者の入札とブロックヘッダーを受け入れます (ブロック本体はまだ見ていません)。
ビルダーは、crList にすべてのトランザクションが含まれていること、またはブロックがいっぱいであることの証明を含めて、ブロックを公開します。そうしないと、ブロックはフォーク選択ルールによって受け入れられません。
証人 (認証者) は公開されたプリンシパルの有効性をチェックします

ここには解決すべき重要な問題がまだいくつかあります。たとえば、有力な経済戦略の 1 つは、開始者が空のリストを提出することです。そうすれば、精査されるべき建築業者であっても、最高値で入札すれば競売に勝つことができる。これを回避する方法はあります (または他の方法もあります)。ここでの設計が盤石ではないことを強調したいだけです。

2D KZG 戦略

KZG コミットメントによってどのようにデータにコミットし、データが正しくスケーリングされていることを証明できるかを確認しました。ただし、これはイーサリアムが実際に行うことを簡略化したものです。 1 つの KZG コミットメントですべてのデータがコミットされるわけではありません。ブロックは多くの KZG コミットメントを使用します。

すでに専用のビルダーがいるのですから、彼らに巨大な KZG コミットを作成させてみてはいかがでしょうか?問題は、これをリファクタリングするには強力なスーパーノードが必要であることです。初期ビルドではスーパーノード要件を受け入れることができますが、リビルドについては想定を避ける必要があります。再構築を処理するには共通のエンティティが必要なので、KZG コミットメントを複数の共有に分割しても問題ありません。手元にあるデータの量を考慮すると、再構成はかなり一般的であるか、この設計の基礎となる前提となっている可能性があります。

再構築を容易にするために、各ブロックは m 個の KZG コミットメントにエンコードされた m 個のシャードデータで構成されます。賢くない場合は、これを行うと大量のサンプリングが行われることになります。各シャードチャンクに対して DAS を実行して、それが利用可能であることを確認することになります (m*k 個のサンプルが必要です。k はチャンクあたりのサンプル数です)。

したがって、イーサリアムは 2D KZG 戦略を使用します。ここでもリードソロモンコードを使用して、m 件のコミットメントを 200 万件のコミットメントにスケールします。

0 ～ 255 と同じ多項式にある追加の KZG コミットメント (ここでは 256 ～ 511) を拡張することで、これを 2D ポリシーにします。ここで必要なのは、上のテーブルで DAS を実行して、すべてのシャードデータの可用性を確保することだけです。

2D サンプリングでは (前述の 50% ではなく) 75% のデータが利用可能である必要があります。これは、より固定された数のサンプルを抽出する必要があることを意味します。 1D 戦略の以前の単純なバージョンでは 30 個のサンプルが必要ですが、ここでは、使用可能なブロックを再構築する確率が一貫していることを確認するために 75 個のサンプルが必要になります。

シャーディング 1.0 (1D KZG コミットメント戦略に対応) に必要なサンプルは 30 個だけですが、64 個のシャードをサンプリングする必要があり、完全なチェックには 1920 個のサンプルが必要です。各サンプルは 512 B なので、次のようになります。

(512 B x 64 スライス x 30 サンプル) / 16 秒 = 60 KB/秒の帯域幅

実際には、検証者はすべてのシャードを個別にチェックするのではなく、ランダムに選択されます。

2D KZG 戦略を使用してブロックをマージすると、完全な DA 検証が非常に簡単になります。単一のマージされたブロックから選択する必要があるサンプルは 75 個だけです。

(512 B x 1 ブロック x 75 サンプル) / 16 秒 = 2.5 KB/秒の帯域幅

Danksharding

PBS was initially designed to blunt the centralizing forces of MEV on the validator set. However, Dankrad recently took advantage of that design realizing that it unlocked a far better sharding construct – DS.

DS leverages the specialized builder to create a tighter integration of the Beacon Chain execution block and shards. We now have one builder creating the entire block together, one proposer, and one committee voting on it at a time. DS would be infeasible without PBS – regular validators couldn’t handle the massive bandwidth of a block full of rollups’ data blobs:

PBS は元々、検証グループにおける MEV の集中力を回避するために設計されました。しかし、Dankrad は最近この設計を利用し、より優れたシャーディングスキームである DS (Danksharding) を考案しました。

DS は専用のビルダーを利用して、ビーコンチェーン実行ブロックとシャード間のより緊密な統合を実現します。現在、ブロック全体を作成する構築者、提案者、および投票を行う委員会が存在します。 DS は PBS なしでは実現できません。通常のビルダーは、無数のロールアップブロックを含むブロックを満たすための巨大な帯域幅を確保できません。

シャーディング 1.0 には 64 の独立した委員会とイニシエーターが含まれており、各シャードが独立して問題を提起できるようになります。このより緊密な統合により、完全なデータ利用可能 (DA) を一度に確保できるようになります。データは依然としてブラックボックス内で「シャード化」されていますが、実用的な観点から見ると、シャードがよりデータの塊のように感じられるようになり、これは素晴らしいことです。

Danksharding - 正直多数の検証

検証者がデータが信頼できることをどのように証明するかを見てみましょう。

これには、大多数の正直なバリデーターに依存する必要があります。単一のバリデーターとしては、列と行が利用可能ですが、ブロック全体が利用可能であるという統計的な信頼性を得るには十分ではありません。その結論を導き出すには、正直な多数決が必要です。分散型検証は重要です。

これは、前に説明した 75 個のランダムサンプルとは異なることに注意してください。プライベートランダムサンプリングは、プロビジョニングが少ない個人でも可用性を簡単にチェックできることを意味します (たとえば、DAS ライトノードを実行でき、ブロックが利用可能であることがわかります)。ただし、バリデーターは引き続き行と列のアプローチを使用して可用性を確認し、ブロックの再構築をガイドします。

ダンクシャルディング - 再構築

単一の行または列の 50% が利用可能である限り、サンプリングされた検証ツールによって簡単に完全に再構築されます。特定の行/列で欠落しているブロックを再構築するとき、それらのブロックは直交するライン上に再分配されます。これは、他のバリデーターが必要に応じて、交差する行と列から欠落しているブロックを再構築するのに役立ちます。

ここで使用可能なブロックを再構築するための安全な仮定は次のとおりです。

サンプルリクエストを実行するノードが十分にあるため、集合的にブロックを再構築するのに十分なデータが得られます。
それぞれのブロックシャードをブロードキャストしているノード間の同期の仮定

では、ノードは何個あれば十分なのでしょうか?大まかに見積もると、64,000 個の個別のインスタンスが必要になります (これまでに 380,000 個以上)。これは、同じバリデーターによって実行されるノードのクロスオーバーがないことを前提とした非常に保守的な計算でもあります (ノードは 32 ETH インスタンスに制限されているため、実際には当てはまりません)。 2 行 2 列を超えるサンプリングを行うと、クロスオーバーによりまとめて取得される可能性が高くなります。これは二次関数的にスケールし始めます。たとえば、バリデーターが 10 または 100 個のバリデーターで実行されている場合、64,000 の要件は桁違いに減少する可能性があります。

オンラインバリデーターの数が非常に少なくなり始めた場合、シャードブロックの数を自動的に減らすように DS を設定できます。したがって、セキュリティの前提条件は安全なレベルまで引き下げられます。

Danksharding - プライベートランダムサンプリングによる悪意のある多数決セキュリティ

DS の検証は、ブロックを証明するために正直な多数決に依存していることがわかります。私個人としては、複数のランクをダウンロードすることでブロックが使用可能であることを証明することはできません。ただし、プライベートなランダムサンプリングを使用すると、誰も信頼することなくこの保証を得ることができます。これは、前に説明したノードが 75 個のランダムサンプルを検査したときに起こることです。

これはネットワークの観点から解決するのが非常に難しい問題であるため、DS には当初プライベートランダムサンプリングは含まれません (PSA: あなたなら彼らを助けることができるかもしれません!)。

攻撃者が匿名化を解除すると、少数のサンプリングされたノードになりすますことができるため、「プライベート」が重要であることに注意してください。彼らは要求したデータの正確な部分だけを返し、残りは差し控えることができます。したがって、すべてのデータが独自のサンプリングから提供されたものであるかどうかはわかりません。

ダンクシャルディング - 重要な概要

DS は名前が良いだけでなく、非常にエキサイティングです。統合された決済と DA レイヤーというイーサリアムのビジョンがついに実現します。このビーコンブロックとシャードの緊密な結合により、実際のブロックをシャーディングしないという効果が得られます。

実際、なぜ「シャード」とみなされるのかを定義してみましょう。ここでの唯一のシャーディングは、バリデーターがすべてのデータをダウンロードする責任を負わないという単純な事実です。他には何もありません。

したがって、これが本当のシャーディングなのかどうか疑問に思っている人は、頭がおかしいわけではありません。これが、PDS (これについてはすぐに説明します) が「シャード」とみなされない理由です (名前に「シャード」が含まれていますが、はい、紛らわしいことは承知しています)。 PDS では、各バリデーターがすべてのブロックを完全にダウンロードして、その可用性を証明する必要があります。その後、DS はサンプリングを導入したため、個々の検証者はその一部のみをダウンロードします。

シャーディングを最小限に抑えるということは、シャーディング 1.0 よりも設計がシンプルになることを意味します (つまり、配信が速くなりますよね?)。簡略化されたコンテンツには次のものが含まれます。

シャーディング 1.0 仕様と比較して、DS 仕様ではコードが数百行少ない (クライアント側では数千行少ない) 可能性があります。
インフラストラクチャとしてのシャード委員会は不要になり、委員会はメインチェーンに投票するだけで済みます。
個々のシャード BLOB の確認を追跡する必要はありません。シャード BLOB はすべてメインチェーンで確認されるか、または確認されません。

この素晴らしい結果として、データの統合料金市場が生まれます。シャーディング 1.0 では、さまざまな作成者がさまざまなブロックを作成することで、これらすべてが断片化されます。

ディシャーディング委員会も贈収賄に対して効果的に抵抗しています。 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 イーサリアム実行の間の同期呼び出しです。すべてが同じビーコンチェーンブロック内で生成されるため、シャードブロックからのトランザクションを確認して即座に L1 に書き込むことができます。シャーディング 1.0 では、個別のシャード確認によりこの可能性がなくなりました。これにより、共有流動性 (例: dAMM) などにとって非常に価値のあるエキサイティングな設計空間が残ります。

ダンクシャーディング—ブロックチェーン拡張の制約

モジュラーレイヤーは適切にスケールします。分散化が進むと、スケールも大きくなります。これは私たちが今日見ているものとは根本的に異なります。 DA 層にノードを追加すると、データスループットを安全に向上させることができます (つまり、ロールアップを許可する余地が広がります)。

ブロックチェーンのスケーラビリティにはまだ限界がありますが、現在と比べて桁違いに改善することができます。安全でスケーラブルな基本層により、実装を迅速に拡張できます。データストレージと帯域幅の改善により、時間の経過とともにデータスループットも向上します。

この記事で想定されている DA スループットを超えることは確かに可能ですが、この最大値がどこに該当するかを言うのは困難です。明確なレッドラインはありませんが、特定の仮定をサポートすることが困難になり始める区間を列挙することはできます。

データストレージ - これは DA とデータの取得可能性に関するものです。コンセンサス層の役割は、データを無期限に取得できることを保証することではありません。その役割は、データをダウンロードしようとする人がセキュリティの前提条件を満たすことができる十分な期間データを利用できるようにすることです。その後、それはどこにでもダンプされます。これは快適です。なぜなら、履歴は N 個の信頼仮定のうちの 1 つであり、実際にはそれほど多くのデータや大規模な計画について話しているわけではないからです。ただし、スループットが増加すると、不快な領域に入る可能性があります。
Validator - DAS には、ブロックを共同で再構築するのに十分なノードが必要です。そうしないと、攻撃者は何もせずに、受け取ったクエリにのみ応答する可能性があります。提供されたこれらのクエリがブロックを再構築するのに十分でない場合、攻撃者は残りのクエリを差し控えることができ、我々は死んでしまいます。スループットを安全に高めるには、DAS ノードを追加するか、データ帯域幅の要件を増やす必要があります。ここで説明するスループットの場合、これは問題ではありません。それでも、この設計に比べてスループットが数桁増加すると、不快になる可能性があります。

ビルダーがボトルネックではないことに注意してください。 32MB のデータに対して KZG 証明を迅速に生成する必要があるため、少なくとも 2.5GBit/s の帯域幅を備えた GPU または適度に強力な CPU が必要になります。いずれにせよ、これは専門的な役割であり、彼らにとってビジネスコストは無視できます。

ネイティブダンクシャーディング (EIP-4844)

DS は素晴らしいですが、忍耐が必要です。 PDS は私たちを乗り越えるためにここにいます。PDS は、移行中に桁違いのスケーリングを提供するために、必要な上位互換性の手順をタイトなスケジュール (上海のハードフォークを対象とする) で実装しました。ただし、実際にはデータシャーディングは実装されていません (つまり、バリデーターはすべてのデータを個別にダウンロードする必要があります)。

今日のロールアップは、ストレージに L1 呼び出しデータを使用します。これはチェーン上で永久に存続する可能性があります。ただし、ロールアップに必要な DA は短期間だけであるため、興味のある人なら誰でもダウンロードする時間は十分にあります。

EIP-4844 では、新しい BLOB を保持するトランザクション形式が導入されており、将来のデータストレージにはロールアップが使用されます。 BLOB は大量のデータ (約 125 KB) を伝送し、同様の量の呼び出しデータよりもはるかに安価です。データ BLOB は 1 か月後にノードから削除され、ストレージ要件が軽減されます。これにより、DA のセキュリティの前提条件を満たすのに十分な時間が確保されます。

拡張コンテキストの場合、現在のイーサリアムブロックは一般的に平均約 90 KB (コールデータはそのうちの約 10 KB) です。 PDS は、1 か月後に BLOB がプルーニングされるため、より多くの DA 帯域幅 (目標 ~1MB、最大 ~2MB) を解放します。常にノードに負担をかけるわけではありません。

BLOB は、それぞれ 32 バイトの 4096 個のフィールド要素のベクトルです。 PDS ではブロックあたり最大 16 個の BLOB が許可されますが、DS ではこれが 256 個に増加します。

PDS DA 帯域幅 = 4096 x 32 x 16 = ブロックあたり 2 MiB、ターゲットは 1 MiB

DS DA 帯域幅 = 4096 x 32 x 256 = ブロックあたり 32 MiB、ターゲットは 16 MiB

各ステップは桁違いの拡張です。 PDS ではデータを完全にダウンロードするためにコンセンサスノードが依然として必要なため、保守的です。 DS は、データの保存と伝播の負荷をバリデータ間で分散します。

DS への途中で EIP-4844 によって導入されたいくつかの利点を次に示します。

BLOB を含むトランザクション形式のデータ
BLOB に対する KZG の取り組み
DS に必要なすべての実行層ロジック
DS に必要なすべての実行/コンセンサス相互検証ロジック
ビーコンブロック検証と DAS BLOB 間のレイヤー分離
DS に必要なほとんどのビーコンブロックロジック
BLOB の独立したガス価格の自動調整 (インデックス価格設定ルールを備えた多次元 EIP-1559)

DS は将来的に次の機能も追加する予定です。

PBS
DAS
2D KZG 戦略
各バリデーターがブロックごとのシャードデータの特定部分の可用性を検証できるようにする、保管証明または同様のプロトコル内要件 (約 1 か月)

これらのデータ BLOB は、エグゼキューターチェーン上の新しいトランザクションタイプとして導入されますが、エグゼキューターに追加の負担を課すものではないことに注意してください。 EVM は、データブロックに関連付けられたコミットメントのみを調べます。 EIP-4844 によって導入された実装層の変更も DS と上位互換性があるため、これ以上の変更は必要ありません。 PDS から DS へのアップグレードには、コンセンサス層の変更のみが必要です。

PDS では、データブロックはコンセンサスクライアントによって完全にダウンロードされます。データブロックは参照されるようになりましたが、ビーコンブロック本体で完全にはエンコードされていません。コンテンツ全体を本文に埋め込む代わりに、BLOB のコンテンツは「サイドカー」として個別に伝達されます。各ブロックには BLOB サイドカーがあり、PDS に完全にダウンロードされた後、DS バリデーターによって DAS (データ可用性サンプリング) がダウンロードされます。

KZG 多項式コミットメントを使用して BLOB にコミットする方法については以前に説明しました。ただし、KZG を直接使用する代わりに、EIP-4844 は実際に使用するもの、つまりバージョン付きハッシュを実装します。これは、単一の 0x01 バイト (バージョンを表す) と、それに続く KZG の SHA256 ハッシュの最後の 31 バイトです。

EVM の互換性と上位互換性のためにこれを行います。

EVM の互換性 - KZG の約束は 48 バイトですが、EVM はより自然に 32 バイトの値を使用します
上位互換性 - KZG から他のもの (量子耐性の STARK など) に切り替えた場合でも、Promise は 32 バイトのままで済みます。

多次元 EIP-1559

PDS は最終的に、オーダーメイドのデータレイヤーを作成します。データブロックには、独立した変動ガス価格と制限を持つ独自の料金市場が設定されます。したがって、一部のNFTプロジェクトがL1で大量のサルの土地を販売したとしても、ロールアップデータのコストは上昇しません（証明決済コストは上昇しますが）。これは、今日のロールアッププロジェクトの主なコストは、(校正ではなく) データを L1 に公開することにあることを示しています。

ガス料金市場は変更されておらず、データブロックが新しい市場として追加されました。

BLOB 料金はガスで請求されますが、独自の EIP-1559 メカニズムに従って調整される可変金額です。ブロックあたりの BLOB の長期平均数は、指定された目標と同じである必要があります。

ここには実際には 2 つの並列オークションがあります。1 つは計算用、もう 1 つは DA 用です。これは、効率的なリソース価格設定にとって大きな前進です。

いくつかの興味深いデザインが見られます。たとえば、現在のガスとブロブの価格設定メカニズムを線形 EIP-1559 から新しい指数関数的 EIP-1559 メカニズムに変更することが合理的である可能性があります。現在の実装では、平均して目標のブロックサイズに達しません。現在の基本料金の安定性は低く、その結果、ブロックごとに観測されたガス使用量は平均で目標を約 3% 上回っています。

第 2 部歴史と状態管理

基本概念を簡単に要約します。

歴史 – チェーン上でこれまでに起こったすべてのこと。高速アクセスは必要ないため、ハードドライブに直接保存できます。これは、長期的には N 個の正直な仮定のうちの 1 つです。
状態 - すべての当座預金残高、スマートコントラクトなどのスナップショット。 (現時点では) フルノードはトランザクションを検証するためにこのデータを持っている必要があります。 RAM には大きすぎますが、ハードドライブは遅すぎます。SSD にうまく収まります。高スループットのブロックチェーンにより、この状態は、一般の人がラップトップで維持できる速度よりもはるかに速く、急速に成長することができます。日常のユーザーがその状態を保持できない場合、それを完全に検証することはできず、分散化は問題外です。

つまり、これらのデータは非常に大きくなる可能性があるため、ノードを実行することが困難になり、必要に応じてノードがこのデータを維持する必要があります。ノードを実行するのが難しすぎる場合、私たち一般人は実行しません。これはひどいことなので、このようなことが起こらないようにする必要があります。

通話データのガスコストの削減と通話データの合計制限 (EIP-4488)

PDS は DS への良い一歩であり、最終要件の多くを満たします。妥当な期間内に PDS を実施することで、DS のスケジュールを前倒しすることが可能になります。

より簡単に実装できる修正は EIP-4488 です。あまりエレガントではありませんが、それでも現在の料金の緊急性は解決されます。残念ながらDSには手順が記載されていないので、必然的に後から追加されることになります。 PDS が期待よりも遅いと感じ始めた場合は、EIP-4488 (わずか数行のコード変更) をすぐに通過し、6 か月後に PDS を開始するのが合理的かもしれません。時間は自由です。

EIP-4488 には 2 つの主要コンポーネントがあります。

通話データのコストをバイトあたり 16 ガスからバイトあたり 3 ガスに削減
Calldata の制限をブロックあたり 1MB に増やし、さらにトランザクションあたり 300 バイトを追加します (理論上の最大値は合計約 1.4MB)。

最悪の事態を防ぐには、制限を増やす必要があります。呼び出しデータでいっぱいのブロックは 18MB に達しますが、これはイーサリアムが処理できる量をはるかに超えています。 EIP-4488 はイーサリアムの平均データ容量を増加させますが、このコールデータ制限 (コールデータバイトあたり 3,000 万ガス/16 ガス = 1.875MB) により、バーストデータ容量は実際にはわずかに減少します。

EIP-4488 の継続的な負荷は、PDS よりもはるかに高くなります。これは、依然として呼び出しデータとデータブロックであるためです (1 か月後には削除できます)。 EIP-4488 を使用すると、成長率は大幅に増加しますが、ノードの実行にボトルネックも発生します。 EIP-4444 が EIP-4488 と同時に実装されたとしても、1 年後の実行ペイロード履歴が減少するだけです。 PDS の持続負荷が低いほど好ましいのは明らかです。

実行クライアントの履歴データを修飾する (EIP-4444)

EIP-4444 を使用すると、顧客は 1 年以上古い履歴データ (ヘッダー、本文、レシートを含む) をローカルで削除することを選択できます。これは、クライアントがそのようなプルーニングされた履歴データを p2p 層で提供することを停止することを規定しています。履歴データをプルーニングすると、ユーザーのディスクストレージ要件 (現在数百ギガバイト、さらに増え続けています) を削減できます。

これはすでに重要ですが、EIP-4488 が実装される場合、基本的には必須になります (履歴データが大幅に増加するため)。これが比較的短期間で完了することを期待しています。最終的には何らかの形で履歴の有効期限が必要になるため、今がそれに対処する良い時期です。

履歴はチェーンの完全な同期には必要ですが、新しいブロック (状態のみ) の検証には必要ありません。したがって、クライアントがチェーンの最上位に同期すると、JSON-RPC 経由で明示的に要求された場合、またはピアがチェーンの同期を試みた場合にのみ履歴データが取得されます。 EIP-4444 が実装されたので、これらに対する代替ソリューションを見つける必要があります。

クライアントは、現在のように devp2p と「完全同期」を行うことはできません。その代わりに、クライアントはジェネシスブロックとして認識される、主観性の低いチェックポイントから「チェックポイント同期」を行うことになります。

弱い主観性は追加の仮定ではないことに注意してください。これは PoS への移行に伴い避けられないものです。リモート攻撃の可能性があるため、同期には事実上弱い主観性チェックポイントを使用する必要があります。ここでの前提は、クライアントが無効または古い主観性の弱いチェックポイントから同期しないことです。このチェックポイントは、履歴データのプルーニングを開始する期間内 (ここでは 1 年以内) に存在する必要があります。そうしないと、P2P レイヤーは必要なデータを提供できなくなります。

また、軽量同期戦略を採用する顧客が増えているため、ネットワーク上の帯域幅の使用量も削減されます。

履歴データを復元する

EIP-4444 では 1 年後に履歴データがプルーニングされますが、PDS ではより速く (約 1 か月後) BLOB がプルーニングされます。ノードにすべてのデータを保存し、分散されたままにすることを要求することはできないため、これらは必要なアクションです。

EIP-4488 - おそらく長期的にはソケットあたり約 1MB が必要となり、年間約 2.5TB のストレージが追加されます
PDS - ソケットあたり最大 1MB を目標としており、年間最大 2.5TB のストレージを追加します
DS - ソケットあたり最大 16 MB を目標としており、年間最大 40 TB のストレージを追加します

しかし、データはどこに行ったのでしょうか?まだ必要ですか？はい、ただし、履歴データの損失はプロトコルに対するリスクではなく、個々のアプリケーションに対するリスクであることに注意してください。したがって、イーサリアムコアプロトコルの作業には、これらすべてのコンセンサスデータを永続的に維持することは含まれるべきではありません。

では、このデータは誰が保管するのでしょうか?潜在的な貢献者は次のとおりです。

個人および団体のボランティア
エクスプローラー (etherscan.io など)、API プロバイダー、およびその他のデータサービスをブロックします。
TheGraph などのサードパーティのインデックス作成プロトコルは、クライアントがマークル証明付きの履歴データに対してサーバーに料金を支払うインセンティブのあるマーケットプレイスを作成できます。
ポータルネットワーク (現在開発中) のクライアントはチェーン履歴のランダムな部分を保存でき、ポータルネットワークはデータリクエストをデータを所有するノードに自動的に送信します。
たとえば、BitTorrent は、毎日のブロックの BLOB データを含む 7GB ファイルを自動的に生成して配布します。
特定のアプリケーションプロトコル (ロールアップなど) では、アプリケーションに関連する履歴の一部をノードに保存することが要求される場合があります。

長期データ保管問題は、前に説明したように、N 信頼の前提条件の 1 つであるため、比較的簡単な問題です。この問題がブロックチェーンのスケーラビリティの究極の限界になるまでには、何年もかかります。

弱い無国籍性

さて、履歴の管理についてはうまくいきましたが、状態についてはどうでしょうか?実はこれが現時点でイーサリアムのTPSを向上させる上での主なボトルネックとなっています。

フルノードは、状態前のルートを取得し、ブロック内のすべてのトランザクションを実行し、状態後のルートがブロック内で提供されたものと一致することを確認します。これらのトランザクションが有効かどうかを知るためには、現時点では手元の状態を確認する必要があります。

ステートレス化 - 役割を果たすために手元にある国家を必要としません。イーサリアムは「弱ステートレス」を目指して取り組んでいます。これは、ブロックを検証するために状態は必要ありませんが、ブロックを構築するためには状態が必要であることを意味します。検証は純粋な関数になります。完全に分離されたブロックを与えてください。それが機能するかどうかを教えてください。基本的には次のようになります。

PBS のため、ビルダーは引き続き状態を必要としますが、これは許容範囲内です。いずれにしても、ビルダーはより集中化された高構成のエンティティになります。私たちはバリデーターの分散化に重点を置いています。ステートレス性が弱いと、ビルダーの作業が少し増え、検証者の作業が大幅に減ります。お得です。

この魔法のような無国籍の処刑を実現するために、私たちは証人を利用します。証人は正しい状態アクセスの証明であり、ビルダーはこれらの証明をすべてのブロックに含め始めるでしょう。実際には、ブロックを検証するために状態全体が必要なわけではありません。必要なのは、読み取られた状態、またはそのブロック内のトランザクションの影響を受けた状態だけです。ビルダーは、特定のブロック内のトランザクションによって影響を受ける状態の一部を組み込み始め、証人を使用してそれらの状態に正しくアクセスしたことを証明します。

例を挙げてみましょう。アリスはボブに 1 ETH を送金したいと考えています。このトランザクションのブロックを検証するには、次のことを知る必要があります。

取引前 - アリスは 1 ETH を持っています
アリスの公開鍵 - 署名が正しいことがわかります
アリスのノンス - トランザクションが正しい順序で送信されたことがわかります
トランザクションの実行後、ボブは 1 ETH を獲得し、アリスは 1 ETH を失いました

弱くステートレスな世界では、建設者は前述の目撃データをブロックに追加し、その正確性を証明します。バリデーターはブロックを受け取り、実行し、それが有効かどうかを判断します。それで大丈夫です。

バリデーターの観点から見ると、次のような影響があります。

今日のスケーリングにとって重大なボトルネックとなっている、状態を維持するために必要な膨大な SSD 要件はなくなりました。
証人のデータと証拠もダウンロードするため、帯域幅の要件が少し増加します。これはマークル-パトリシアツリーのボトルネックですが、Verkle Tryes が遭遇する種類のボトルネックではなく、大きな問題ではありません。
完全に検証するには、引き続きトランザクションを実行します。ステートレス性は、現時点ではイーサリアムのスケーリングにおけるボトルネックではないという事実を認めています。

また、弱いステートレス性により、イーサリアムは実行スループットに対して自ら課した制約を緩和することができ、ステートの肥大化はもはや差し迫った懸念事項ではなくなります。ガス制限を 3 倍にするのが合理的かもしれません。

この時点で、ほとんどのユーザーの実行は L2 で行われますが、L1 スループットの向上はユーザーにとっても有益です。ロールアップは、DA (シャードへの公開) と決済 (L1 実行が必要) をイーサリアムに依存します。イーサリアムが DA レイヤーを拡張するにつれて、プルーフ発行の償却コストがロールアップコストのより大きな割合を占める可能性があります (特に ZK ロールアップの場合)。

ヴァークル・トライズ (ヴァークル・トライズ)

これらの証人がどのように機能するかを意図的に省略しました。イーサリアムは現在、状態を保存するためにマークル-パトリシアツリーを使用していますが、必要なマークル証明が大きすぎるため、これらの証人を実行できません。

イーサリアムは Verkle に頼って状態を保存しようとします。 Verkle 証明ははるかに効率的であるため、弱い無国籍性を達成するための実行可能な証人として使用できます。

まず、マークルツリーがどのようなものかを確認してみましょう。すべてのトランザクションはハッシュから始まります。下部にあるこれらのハッシュは「リーフ」と呼ばれます。すべてのハッシュ値は「ノード」と呼ばれ、以下の 2 つの子ノードのハッシュ値になります。結果として得られるハッシュは「マークルルート」です。

このデータ構造は、ツリー全体をダウンロードせずにトランザクションの整合性を証明するのに非常に役立ちます。たとえば、トランザクション H4 が含まれていることを確認したい場合は、マークル証明の H12、H3、および H5678 が必要です。ブロックヘッダーから H12345678 が得られます。したがって、軽量クライアントはフルノードにこれらのハッシュを要求し、ツリー内のルートに従ってそれらを一緒にハッシュすることができます。結果が H12345678 であれば、H4 がツリー上にあることが証明されました。

ただし、ツリーが深くなるほど、一番下までのルートが長くなるため、正当化するためにより多くのアイテムが必要になります。したがって、効率的な証明には、浅くて幅の広いツリーの方が適しています。

問題は、各ノードの下にさらに多くの子を追加してマークルツリーの幅を広げようとすると、非常に非効率になることです。ツリー全体にアクセスするには、すべてのピアノードのハッシュ値を一緒にハッシュする必要があるため、マークル証明のためにピアノードのより多くのハッシュ値を受け入れる必要があります。これにより、証明のサイズが膨大になります。

これが効率的なベクトルの約束の役割です。マークルツリーで使用されるハッシュは実際にはベクトルコミットメントであることに注意してください。これらは 2 つの要素にしか実質的にコミットできない単なる悪いコミットメントです。したがって、検証するためにすべてのピアを受信する必要がないベクトルコミットメントが必要です。これができたら、ツリーの幅を広くし、深さを減らすことができます。これにより、効率的な校正サイズを実現し、提供する必要がある情報の量を減らすことができます。

Verkle トライはマークルツリーに似ていますが、単純なハッシュではなく効率的なベクトルコミットメント (そのため「Verkle」という名前) を使用して子をコミットします。したがって、基本的な考え方は、各ノードが多数の子を持つことができるが、証明を検証するためにすべての子を必要とするわけではないということです。これは幅に関わらず大きさが一定である証です。

実際、この可能性の良い例を以前に取り上げました。KZG コミットメントはベクトルコミットメントとしても使用できます。実際、これはイーサリアム開発者が当初ここで使用する予定だったものです。彼らは後に、同様の役割を達成するためにペダーセン氏の取り組みに目を向けた。これは楕円曲線 (ここではバンダースナッチを指します) に基づいており、256 の値 (2 つよりもはるかに優れています!) が約束されています。

それでは、できるだけ幅の広い、深さ 1 のツリーを構築してみてはいかがでしょうか。検証者にとっては非常にコンパクトな証明が得られるため、これは非常に便利です。ただし、検証者はこの証明を計算できる必要があり、範囲が広ければ広いほど困難になるという実際的なトレードオフがあります。したがって、Verkle 試行は 1 ～ 256 の値の幅の 2 つの極端な値の間に位置します。

ステータスが期限切れになりました

弱いステートレス性はバリデーターからステートインフレーション制約を取り除きますが、ステートは魔法のように消えるわけではありません。トランザクションコストには上限がありますが、状態を増加させることでネットワークに恒久的な税金を課します。状態の増大は、依然としてネットワークに永続的な影響を及ぼします。この根本的な問題を解決するために何かをする必要があります。

だからこそ、状態の有効期限が必要なのです。長期間 (1 年や 2 年など) 非アクティブな場合は、ブロックビルダーが含めていたであろうものも含めて廃止されます。アクティブユーザーは何も変化に気付かず、不要になった重い状態を破棄できます。

期限切れステータスを復元する必要がある場合は、証明を提示して再アクティブ化するだけです。これは、N 個のストレージ想定の 1 つにフォールバックします。誰かがまだ完全な履歴 (ブロックエクスプローラーなど) を持っている限り、必要なものをその人から入手できます。

ステートレス性が弱いと、基本層での状態有効期限の当面の必要性が弱まりますが、特に L1 スループットが増加するため、長期的には良いことになります。高スループットのロールアップの場合、これはより便利なツールになります。 L2 状態は非常に速い速度で増加するため、高構成ビルダーでも足を引っ張ることになります。

パート 3 全ては MEV のせいです

PBS は DS (ダンクシャルディング) を安全に実装するために必要な条件ですが、その本来の設計は実際には MEV の集中力に対抗することを目的としていることに注意してください。今日のイーサリアム研究では繰り返し傾向が見られるでしょう。MEV は現在、暗号経済学の最前線であり中心となっています。

ブロックチェーンを設計する場合、MEV を考慮することがセキュリティと分散化を維持するための鍵となります。基本的なプロトコルレベルのメソッドは次のとおりです。

有害な MEV を可能な限り軽減します (例: 単一スロットのファイナリティ、単一のシークレットリーダー選択)
残りの部分 (MEV-Boost、PBS、MEV スムージングなど) を民主化する

残りは簡単に取得してバリデーター間で伝達できる必要があります。そうしないと、洗練された検索者と競合できなくなり、バリデータグループが集中化されてしまいます。これは、合併後のバリデーター報酬に占める MEV の割合がはるかに高くなったことによってさらに悪化します (ステーキング発行はマイナーに与えられるインフレよりもはるかに低い)。これは無視できません。

今日の MEV サプライチェーン

今日の一連の流れはこんな感じです。

ここではマイニングプールがビルダーの役割を果たします。 MEV Seeker は、Flashbot を介してトランザクションのバンドルを (それぞれの入札とともに) マイニングプールに転送します。マイニングプールオペレーターは完全なブロックを集約し、ブロックヘッダーを各マイナーに渡します。マイナーは PoW を使用してブロックを証明し、フォーク選択ルールに重みを付けます。

Flashbot は、スタック全体の垂直統合を防ぐためにここにいます。これは、検閲やその他の厄介な部外者への扉を開くことになります。 Flashbot が誕生したとき、

ETH

DAOrayaki

作者文库