vitalik：イーサリアムプロトコルはサージ段階でどのように発展するべきですか

注：この記事は、イーサリアムの創設者であるVitalikが最近公開した一連の記事の第2部「The Future of the Ethereum契約」です。イーサリアムプロトコルの可能性のある先物、パート2：サージ「、最初の部分は、Bitchain Visionの以前のレポートに示されています」Ethereum Posで他に何を改善できるかDeng Tongによって編集された。

当初、イーサリアムのロードマップには2つのスケーリング戦略がありました。

それらの1つは「シャード」です：各ノードは、チェーン内のすべてのトランザクションではなく、トランザクションのごく一部を検証および保存する必要があります。これは、他のピアツーピアネットワーク（BitTorrentなど）がどのように機能するかでもあるため、ブロックチェーンを同じように機能させることができます。

もう1つは2層プロトコルです。ネットワークはイーサリアムの上にあり、ほとんどのデータとコンピューティングをメインチェーンから遠ざけながら、セキュリティから完全に利益を得ることができます。「レイヤー2プロトコル」とは、2015年のステータスチャネル、2017年のプラズマ、2019年のロールアップを指します。ロールアップは、状態チャネルやプラズマよりも強力ですが、多くのオンチェーンデータ帯域幅が必要です。

幸いなことに、2019年までに、Sharding Researchは「データの可用性」の大規模な検証の問題に取り組んでいます。その結果、2つのパスがマージされ、ロールアップ中心のロードマップがありました。これは、今日でもイーサリアムのスケーリング戦略です。

サージ、2023ロードマップ版。

ロールアップ中心のロードマップは、単純な分業を提案しています。イーサリアムL1は、強力で分散化された基礎層になることに焦点を当てていますが、L2は生態系スケールを支援するタスクを引き受けます。これは社会全体の繰り返しのパターンです：裁判所システム（L1）は非常に高速かつ効率的ではなく、契約と財産権を保護するためですが、起業家（L2）はこれに基づいて固体基礎層を構築し、人間を連れて行く必要があります。（比phor的および文字通り）火星。

今年、ロールアップ中心のロードマップは大成功を収めました。EthereumL1データ帯域幅はEIP-4844 BLOBSを通じて大幅に増加し、複数のEVMロールアップがフェーズ1にあります。各L2が独自の内部ルールを備えた「フラグメント」として機能する非常に不均一で多様化した破片の実装が現実になりました。しかし、私たちが見たように、この道に行くことには独自の課題があります。したがって、現在、私たちの使命は、イーサリアムL1を際立たせる堅牢性と分散化を保持しながら、ロールアップ中心のロードマップを完成させ、これらの問題を解決することです。

サージ：重要な目的

100,000+ TPSのL1+ L2

L1の分散化と堅牢性を維持します

少なくとも一部のL2は、イーサリアムのコア属性を完全に継承します（信頼せず、オープン、検閲耐性）

L2間の最大相互運用性。イーサリアムは、34種類のブロックチェーンではなく、エコシステムのように感じるはずです。

スケーラビリティのトライアド

スケーラビリティ不可能な三角形は、2017年にブロックチェーンの3つのプロパティの間に緊張があると考えているアイデアです：分散化（より具体的にはノードの低コスト）、スケーラビリティ（より具体的には、多数のトランザクションを処理）、セキュリティ（より具体的には、攻撃者は、単一のトランザクションを失敗させるために、ネットワーク全体のほとんどのノードを破壊する必要があります）。

トライアドジレンマは定理ではなく、トライアドジレンマを導入する投稿には数学的証拠が付いていないことは注目に値します。それはヒューリスティックな数学的議論を与えます：分散型フレンドリーなノード（消費者ラップトップなど）が1秒あたりのnトランザクションを検証できる場合、k*nトランザクションを1秒間に処理するチェーンがあり、（i）各トランザクションは確認できます。 1/kのノードによって、攻撃者はいくつかのノードを破壊して悪いトランザクションを駆動できることを意味します。この記事の目的は、トライアドを壊すことが不可能であることを示すことではありません。トライアドを壊すことは難しいことを示すことです。

長年にわたり、一部の高性能チェーンは、多くの場合、ソフトウェアエンジニアリングスキルを使用してノードを最適化することにより、インフラストラクチャレベルで巧妙な対策を講じずにトライアドを解決したとしばしば主張してきました。これは常に誤解を招くものであり、そのようなチェーンでノードを実行することは、イーサリアムよりも常にはるかに困難です。この投稿では、なぜこれが起こるのか（なぜL1クライアントソフトウェアエンジニアリングがイーサリアム自体を拡大できないのか）の多くの微妙さを調査します。

しかし、データ可用性サンプリング（DAS）とスナークの組み合わせは、トライアドを解決します：これにより、クライアントは一定のデータが利用可能であること、および一定の数の計算手順が正しく実行されるかどうかを確認できますが、そのデータのごく一部のみがダウンロードされ、計算量がはるかに少ないことを確認できます。スナークは信頼できません。データの可用性サンプリングには微妙な少数派の信頼モデルがありますが、非スケーラブルなチェーンが持っている基本的なプロパティを保持しており、攻撃の51％でさえ、ネットワークに悪いブロックを受け入れるように強制することはできません。

トライアドを解決する別の方法は、プラズマアーキテクチャです。これは、巧妙なテクニックを使用して、インセンティブ化された互換性のある方法でユーザーにデータの可用性を監視する責任を推進しています。2017年から2019年にかけて、コンピューティングを拡大するために必要なのは詐欺の証拠だけで、Plasmaのセキュリティ機能は非常に限られていましたが、Snarkの主流化により、プラズマアーキテクチャは以前よりも幅広いユースケースに適しています。

DASのさらなる進歩

どんな問題を解決したいですか？

2024年3月13日の時点で、Dencunのアップグレードがライブになったとき、Ethereumブロックチェーンには12秒ごとに約125 kbの「ブロブ」があり、期間ごとに約375 kbのデータが利用可能な帯域幅でした。トランザクションデータがチェーンに直接投稿されると仮定すると、ERC20の伝送は約180バイトであるため、イーサリアムのロールアップの最大TPSは次のとおりです。

375000 / 12/180 = 173.6 TPS

EthereumのCallData（理論的最大値：スロットあたり3,000万ガス /バイトあたり16ガス=スロットあたり1,875,000バイト）を追加すると、これは607 TPSになります。Peerdasの場合、BLOBカウントターゲットを8-16に増やすことが計画されています。これにより、463-926 TPSのコールダタが得られます。

これは、Ethereum L1よりも大幅に改善されていますが、それで十分ではありません。よりスケーラビリティが必要です。私たちの中期目標はスロットあたり16 MBで、シンクデータ圧縮の改善と組み合わせると、約58,000 TPSが得られます。

Peerdasとは何ですか？それはどのように機能しますか？

Peerdasは、「1次元サンプリング」の比較的単純な実装です。Ethereumの各BLOBは、253ビットプライムドメインの4096次多項式です。多項式の「株式」を放送します。各シェアは、8192座標の合計セットから取られた隣接する16の座標で16の評価で構成されています。BLOBは、8192の評価の4096によって復元できます（現在推奨されているパラメーターを使用して：128のサンプルのうち64件）。

Peerdasは、各クライアントに小さな量子ネットワークを聴くことで動作します。そこでは、Ith SubnetがBLOBのIthサンプルをブロードキャストし、グローバルP2Pネットワークのピアを尋ねることで他のサブネットに必要なものを要求しますさまざまなサブネットを聞いてください）。SubnetDasのより保守的なバージョンは、サブネットメカニズムのみを使用しており、追加のリクエストピア層がありません。現在の推奨事項は、ステークの証明に参加しているノードがSubnetDasを使用し、他のノード（つまり、「クライアント」）がPeerdasを使用することです。

理論的には、1Dサンプリングをかなり拡張できます。ブロブカウントの最大値を256に増やすと（ターゲットは128）、16 MBのターゲットに到達しますが、データの可用性サンプリングはノードサンプルごとに16のみです* 128ブロブ*サンプルあたりBLOBあたり512バイト=スロットあたり1 MBのデータ帯域幅。これは私たちの許容範囲内にあります：それは実現可能ですが、帯域幅が制限されたクライアントがサンプリングできないことを意味します。これを最適化することができます。これは、塊の数を減らして塊のサイズを増やすことで最適化できますが、これにより再構築がより高価になります。

そのため、最終的にはさらに一歩進んで2Dサンプリングを行いたいと考えています。これは、BLOB内でランダムにサンプルするだけでなく、BLOB間もサンプリングします。KZGで約束された線形プロパティは、冗長にエンコードされた新しい「仮想ブロブ」リストによってブロック内のブロブセットを「拡張」するために使用されます。

2Dサンプリング：A16Z

重要なことに、計算上約束されたスケーリングには塊が必要ないため、スキームは分散ブロックビルディングに基づいています。実際にブロックを構築するノードは、BLOB KZGの約束が必要であり、BLOBの可用性を確認するためにDASに依存する必要があります。1D DASは、分散ブロック構造に本質的に友好的です。

既存の研究とのつながりは何ですか？

データの可用性を紹介する元の記事（2018）：https://github.com/ethereum/research/wiki/a-note-on-data-abailability-and-erasure-coding

フォローアップペーパー：https://arxiv.org/abs/1809.09044

DAS、パラダイムのための通訳ポスト：https://www.paradigm.xyz/2022/08/das

KZGは2Dの可用性を約束しました：https://ethresear.ch/t/2d-data-abailability-with-cate-commitments/8081

peerdas on ethresear.ch：https://ethresear.ch/t/peerdas-a-simpler-das-approach-usingバトルテスト-p2p-components/16541と論文：https://eprint.iacr.org/2024/1362

EIP-7594：https://eips.ethereum.org/eips/eip-7594

ethresear.chのsubnetdas：https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

2Dサンプリングにおける回復可能性の微妙な違い：https://ethresear.ch/t/nuances-of-data-recoverability-in-data-abailability-sampling/16256

他に何をする必要があり、どのようなトレードオフを比較検討する必要がありますか？

次のステップは、Peerdasの実装と展開を完了することです。それ以来、PeerdasのBLOBカウントを増やすことは徐々に努力し、ネットワークを慎重に観察し、セキュリティのためのソフトウェアを改善します。同時に、DASおよびDASの他のバージョンの形式化と、フォーク選択ルールのセキュリティなどの問題との相互作用について、より多くの学術作業を行うことを望んでいます。

今後、2D DASの理想的なバージョンを見つけ、そのセキュリティ機能を証明するために、さらに多くのことをする必要があります。また、最終的にKZGから、信頼できるセットアップなしで量子に耐性のある代替品に移行したいと考えています。現時点では、どの候補者が分散ブロックビルディングに友好的であるかはわかりません。技術的にはスタークのハッシュサイズはo（log（n） * log（log（n）））であるため、行と列を再構築するための有効性の証明を生成するために再帰的なスタークを使用する高価な「強力な」手法でさえも十分ではありません（攪拌付き））、スタークは実際にはスポット全体とほぼ同じ大きさです。

長期的には、現実の道は次のとおりです。

理想的な2D DASツール。
1D DASに固執し、シンプルさと堅牢性のためにサンプリング帯域幅の効率を犠牲にし、低いデータキャップを受け入れます。
（ハードピボット）DAをあきらめ、私たちが焦点を当てるメインティア2アーキテクチャとしてプラズマを完全に受け入れます。

スコープを比較検討することで、これらを見ることができます。

L1で実行を直接拡張することを決定したとしても、この選択は残っていることに注意してください。これは、L1が多数のTPSを処理する場合、L1ブロックが非常に大きくなり、顧客が正しいことを確認するための効率的な方法が必要になるため、ロールアップをサポートする同じ手法を使用する必要があります。 -EVMおよびDAS）およびL1。

ロードマップの残りの部分とどのように相互作用しますか？

データ圧縮が実装されている場合（以下を参照）、2D DASの需要が減少するか、少なくとも遅延し、プラズマが広く使用されている場合、2D DASの需要はさらに減少します。DASは、分散ブロック構築プロトコルとメカニズムに対する課題も提示します。DASは、分散再建に理論的に友好的ですが、リスト提案とその周辺を含むフォーク選択メカニズムと実際に組み合わせる必要があります。