Vitalik：Ethereum Protocolの可能性のある未来

著者：イーサリアムの創設者であるVitalik

注：この記事は、イーサリアムの創設者であるVitalikが最近公開した一連の記事の4番目の部分です。Ethereum Protocolの可能性のある先物、パート4：The Verge“。見る “Vitalik：scourge段階の重要な目的」、2番目の部分を参照してください」Vitalik：イーサリアムプロトコルはサージ段階でどのように発生するべきですか」、最初の部分を参照してください」Ethereum Posで他に何を改善できるか」。

ジャスティン・ドレイク、フシアオ・ウェイ・ワン、ギヨーム・バレエ、イグナシオ、ジョシュ・ルドルフ、レヴ・スーハノフ、ライアン・ショーン・アダムス、ウマ・ロイのフィードバックとレビューに感謝します。

ブロックチェーンの最も強力な機能の1つは、誰でも自分のコンピューターでノードを実行し、チェーンが正しいことを確認できることです。オンチェーンコンセンサス（POW、POS …）を実行しているノードの95％が、新しいルールに従ってルールを変更し、ブロックの生産を開始することにすぐに同意したとしても、完全に検証されたノードを実行している全員がチェーンの受け入れを拒否します。そのようなグループに属さない利害関係者は、自動的に収束し、古いルールに従って継続し続けるチェーンを構築し続け、完全に検証されたユーザーがチェーンに従います。

これは、ブロックチェーンと集中システムの重要な違いです。ただし、この機能を維持するには、完全に検証されたノードを実行することは、重要な数の人々にとって実際に実行可能である必要があります。これは、両方のステーカーに適用されます（ステイカーが検証チェーンを持っていないかのように、実際にはプロトコルルールの施行に貢献していません）と通常のユーザーに適用されます。今日、この記事を書くために使用されるものを含む、ノードは消費者ラップトップで実行できますが、そうすることは困難です。Vergeの目的は、これを変更することを目的としており、完全な検証チェーンのコンピューティングコストを非常に低くするため、すべてのモバイルウォレット、ブラウザウォレット、さらにはスマートウォッチでさえデフォルトで行います。

Verge、2023ロードマップ。

最初に、「Verge」とは、Ethereum State StorageをVerkle Treesに転送するというアイデアを指します。これは、イーサリアムブロックのステートレス検証を可能にするよりコンパクトな証明を可能にするツリー構造です。ノードは、ハードドライブでイーサリアム状態（アカウント残高、契約コード、ストレージなど）なしでイーサリアムブロックを検証できますが、証明を検証するために数百キロバイトの証明データと数百ミリ秒の余分な時間を費やすことができます。今日、Vergeは、Stateless Verificationテクノロジーだけでなく、Snarkを使用したすべてのEthereum実行を検証することも含まれるEthereum Chainの最大のリソース効率検証を達成することに焦点を当てたより大きなビジョンを表しています。

チェーン全体のスナーク検証に長期的に焦点を当てたことに加えて、別の新しい質問は、Verkleの木が最良の技術であるかどうかに関連しています。Verkleの木は量子コンピューターに対して脆弱であるため、現在のKeccak Merkle Patriciaの木をVerkleの木に置き換えると、後でこれらの木を再び交換する必要があります。マークルツリーの自然な代替品は、バイナリツリーのスタークマークルブランチを使用することに直接ジャンプすることです。歴史的に、これはオーバーヘッドと技術的な複雑さのために実行不可能と見なされてきました。しかし、最近、Starkwareはラップトップで1秒あたり170万人のポセイドンハッシュを証明しました。

したがって、過去1年間、Vergeはよりオープンになり、複数の可能性があります。

Verge：重要な目的

ステートレスクライアント：クライアントとステーキーノードが数GB以上のストレージスペースを必要としないことを完全に確認します。

（長期）スマートウォッチの包括的な検証チェーン（コンセンサスと実行）。いくつかのデータをダウンロードし、スナークを確認し、終了します。

この記事では、次のコンテンツが強調表示されています。

ステートレス検証：VerkleまたはStarks
EVM実行の有効性の証明
コンセンサスの妥当性の証明

ステートレス検証：VerkleまたはStarks

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

今日、イーサリアムのクライアントは、ブロックを検証するために何百ものGB州データを保存する必要があり、この数は毎年増加し続けています。生の状態データは年間約30 GB増加し、個人のクライアントは、トライを効果的に更新できることに加えて、いくつかの追加データを保存する必要があります。

これにより、完全に検証されたイーサリウムノードを実行できるユーザーの数が減ります。ハードドライブは、すべてのイーサウム状態を保存するのに十分な大きさです。州のサイズは、初めてノードをセットアップするプロセスに大きな問題を引き起こす可能性があります。ノードは、数時間または数日かかる場合がある状態全体をダウンロードする必要があります。これにより、さまざまな鎖反応が生じます。たとえば、これにより、ステーカーがステークの設定をアップグレードすることがより困難になります。技術的には、これはダウンタイムなしで行うことができます – 新しいクライアントを起動し、同期するのを待ってから、古いクライアントを閉じてキーを転送します – しかし、実際には、これは技術的に複雑です。

それは何であり、どのように機能しますか？

ステートレス検証は、ノードが完全な状態を持たずにブロックを検証できるようにする手法です。代わりに、各ブロックには証人が付属しています。これには、（i）ブロックがアクセスする状態の特定の場所（コード、バランス、ストレージなど）、および（ii）これらの値の暗号化された証明はあります。正しい。

ステートレス検証の実際の実装には、イーサリアムの状態の木構造を変更する必要があります。これは、現在のMerkle Patricia Treeが、特に最悪のシナリオで、パスワードスキームの証明スキームを実装するのに非常に友好的であるためです。これは、「オリジナルの」マークルブランチと、スタークのマークルブランチを「包む」可能性に当てはまります。主な難しさは、MPTの2つの弱点に起因しています。

これは六角形です（つまり、各ノードには16の子ノードがあります）。これは、平均して、サイズnのツリーの証明には、32*（16-1）*log16（n）= 120*log2（n）バイト、または232アイテムのツリーの約3840バイトがあることを意味します。バイナリツリーの場合、32*（2-1）*log2（n）= 32*log2（n）バイト、つまり約1024バイトのみが必要です。
このコードはメルケル化されていません。つまり、最大長の24,000バイトの完全なコードを提供するには、アカウントコードへのアクセスが必要であることを意味します。

最悪のケースを次のように計算できます。

30,000,000ガス / 2,400（「コールド」アカウント読み取りコスト） *（5 * 480 + 24,000）= 330,000,000バイト

ブランチのコストはわずかに低く（8*480ではなく5*480）、多くのブランチがある場合、ブランチの上部が繰り返されるためです。それでも、1つのスロットでダウンロードされたデータの量は完全に非現実的です。Starkでそれを包み込もうとする場合、2つの問題があります。（i）KeccakはStarkに比べて友好的ではありません（ii）330 MBのデータは、Keccakラウンド関数に500万の呼び出しを証明する必要があることを意味します。 Keccakをより効率的に証明できることをStarkにすることができたとしても、最も強力な消費者ハードウェア以外にすべてのハードウェアで証明できないことがたくさんあります。

ヘキサグラムをバイナリツリーに置き換えてメルケライズコードを追加するだけで、最悪の場合は約30,000,000 / 2,400 * 32 *（32-14 + 8）= 10,400,000バイト〜114のブランチであり、そのうち8個は長さの入力されています。葉）。これには、個々のコードブロックにアクセスするためにガスコストを変更する必要があることに注意してください。10.4 MBの方がはるかに優れていますが、多くのノードでは、1つのスロットでダウンロードするにはまだデータが多すぎます。そのため、より強力なテクノロジーを紹介する必要があります。これを行うには、2つの主なソリューションがあります。つまり、Verkle TreeとStarked Binary Hash Treeです。

Verkle Tree

Verkle Treesは、楕円曲線に基づいてベクトルコミットメントを使用して、より短い証明を作成します。重要なのは、ツリーの幅に関係なく、各親子関係の対応する証明フラグメントはわずか32バイトであるということです。木の幅の唯一の制限は、ツリーが広すぎると、証明の計算効率が低下することです。Ethereumの推奨される実装幅は256です。

したがって、証明内の単一の分岐のサイズは32*log256（n）= 4*log2（n）バイトになります。理論的には、最大証明サイズは約30,000,000/2,400*32*（32-14+8）/8 = 1,300,000バイトになります（状態ブロックの不均一な分布により、実際には数学的な計算がわずかに異なりますが、これは非常に良いものです）。

追加の警告として、上記のすべての例で、この「最悪のケース」は最悪のケースではないことに注意してください。最悪のケースは、攻撃者が故意に2つのアドレスを「鉱山」してツリープレフィックスに長い公開され、そのうちの1つは、最悪の枝の長さを約2回延長することができます。しかし、そのような警告があっても、Verkleの木は約2.6 MBの最悪の証明を提供します。これは、今日の最悪のコールデータとほぼ一致しています。

また、この警告を使用して別のことを行います。「隣接する」ストレージへのアクセスを非常に安価にします。同じ契約の多くのコードブロック、または隣接するストレージスロットです。EIP-4762は隣接の定義を提供し、隣接アクセスには200ガス料金のみが請求されます。隣接するアクセスの場合、最悪の証明サイズは30,000,000/200*32 = 4,800,800バイトになりますが、これはまだ依然として許容範囲内にあります。セキュリティのためにこの価値を減らしたい場合は、隣接するアクセスのコストをわずかに増加させることができます。

星付きバイナリハッシュツリー

ここでのテクニックは非常に自明です。バイナリツリーを作成し、ブロック内の値を証明する必要があるという最大10.4-4-4-4-MBの証明を取り、その証明の厳しいものに証明を置き換えます。これにより、証明自体に証明されたデータのみに加えて、実際のスタークの固定オーバーヘッドが含まれていることがわかります。

ここでの主な課題は、時間を証明することです。バイトを計算するのではなく、ハッシュ値を計算することを除いて、基本的に上記と同じ計算を行うことができます。10.4 MBブロックは、330,000のハッシュを意味します。攻撃者がツリーに長いパブリックプレフィックスを持つアドレスを「鉱山」する可能性を追加すると、実際の最悪の場合は約660,000のハッシュになります。したがって、1秒あたり約200,000のハッシュを証明できれば、それは問題ありません。

これらの数字は、消費者のラップトップで到達し、Poseidon Hash機能を使用して、Starkの親しみやすさのために特別に設計されています。しかし、ポセイドンは比較的未熟であるため、多くの人々はまだその安全を信頼していません。したがって、2つの現実的なパスがあります。

Poseidonで多くのセキュリティ分析を迅速に実行し、L1に展開するためにそれに精通してください
Sha256やBlakeなど、より「保守的な」ハッシュ機能を使用します

執筆時点では、StarkwareのStark Proverは、保守的なハッシュ機能を証明したい場合、消費者ラップトップで1秒あたり約10〜30kのハッシュしか証明できません。ただし、Starkテクノロジーは急速に進歩しています。今日でも、GKRベースのテクノロジーは、それを約100〜200kの範囲に増やす可能性を示しています。

検証ブロック以外のユースケースを目撃します

検証ブロックに加えて、より効率的なステートレス検証を可能にする他の3つの重要なユースケースがあります。

メモリプール：トランザクションがブロードキャストされている場合、P2Pネットワークのノードは、再ロードキャスト前にトランザクションが有効であることを確認する必要があります。今日、検証には、署名の検証だけでなく、残高が十分であり、乱数が正しいことを確認することも含まれます。将来（たとえば、EIP-7701などのネイティブアカウントの抽象化を使用）、これには、州のアクセスを実行するEVMコードを実行することが含まれる場合があります。ノードがステートレスの場合、トランザクションは状態オブジェクトの証明を備えた証明を必要とします。
リストを含める：これは、（おそらく大規模で複雑な）ブロックビルダーの希望に関係なく、（おそらく小さくて単純な）証明証明の検証装置が次のブロックにトランザクションを封じ込めることを可能にする提案された機能です。これにより、強力な参加者がトランザクションを遅らせることでブロックチェーンを操作する能力が低下します。ただし、これには、バリッターが含まれているリストのトランザクションの妥当性を検証する方法が必要です。
ライトクライアント：集中参加者を信頼せずに、ユーザーにウォレット（例：メタマスク、レインボー、ラビーなど）を介してチェーンにアクセスしてもらいたい場合は、軽いクライアント（Heliosなど）を実行する必要があります。Core Heliosモジュールは、ユーザーに検証済みのステータスルートを提供します。ただし、完全に信頼のないエクスペリエンスを獲得するには、ユーザーが作成する個々のRPCコールごとに証明を提供する必要があります（たとえば、ETH_CALLリクエストの場合、ユーザーは通話中にアクセスしたすべての状態の証明が必要です）。

これらすべてのユースケースが一般的であることの1つは、かなり多くの証拠が必要であるが、それぞれの証明が小さいことです。したがって、Starkは、実際には意味がないことを証明しています。Merkleブランチのもう1つの利点は、それらが更新されていることです。ブロックBに根ざした状態オブジェクトXの証明を考えると、ブロックB2をルートとして受け取る場合、その証明を更新できます。Verkleの証明自体も最新です。

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

Verkle Tree：https://vitalik.eth.limo/general/2021/06/18/verkle.html

ジョン・クスマールのオリジナルのヴェルクルの木の紙：https://math.mit.edu/research/highschool/primes/materials/2018/kuszmaul.pdf

Starkware Proofデータ：https://x.com/starkwareltd/status/18077776563188162562

poseidon2紙：https://eprint.iacr.org/2023/323

ajtai（グリッドの硬度に基づく代替高速ハッシュ関数）：https://www.wisdom.weizmann.ac.il/~oded/col/cfh.pdf

Verkle.info：https://verkle.info/

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

行うべき残りの主なタスクは次のとおりです。

EIP-4762の結果のより多くの分析（ステートレスガスコストの変更）
より多くの作業完了とテスト移行手順。これは、ステートレスのEIPの複雑さの大部分を占めています
Poseidon、Ajtai、およびその他の「厳しい」ハッシュ機能のセキュリティ分析
さらに、BiniusやGKRに基づいたアイデアなど、「保守的」（または「従来の」）ハッシュ関数のための超効率的なスタークプロトコルをさらに開発します。

すぐに、次の3つのオプションのどれを選択するかを決定します。（i）Verkle Tree、（ii）Starkフレンドリーなハッシュ関数、および（iii）保守的なハッシュ関数。それらのプロパティは、次のように大まかに要約できます。

これらの「タイトル番号」に加えて、他の重要な考慮事項がいくつかあります。

今、Verkleツリーコードは非常に成熟しています。Verkle以外のものを使用すると、実際には展開が遅れます。とにかくハッシュ関数分析やプローバーの実装を行うために余分な時間が必要な場合、およびできるだけ早くイーサリアムに含めたい他の重要な機能がある場合は、これは大丈夫かもしれません。
ハッシュで状態ルートを更新するのは、Verkle Treesを使用するよりも速いです。これは、ハッシュベースのアプローチが完全なノードの同期時間を短縮できることを意味します。
vErkleツリーには、興味深い証人の更新プロパティがあります– Verkle Tree Witnessが更新されています。このプロパティは、メモリプールに役立ち、リストやその他のユースケースを含むことができます。また、効率を達成するのに役立つ場合があります。状態オブジェクトを更新すると、最後のレベルを読むことなく最後から2番目のレベルで目撃者を更新できます。
ヴェルクルの木は、スナークによって証明するのが難しいです。証明サイズを数キロバイトまでずっと縮小したい場合、Verkleの証明はいくつかの困難をもたらす可能性があります。これは、Verkle Proofの検証が多数の256ビット操作を導入するためです。これには、証明システムに多くのオーバーヘッドまたはそれ自体がVerkle Proofの256ビット部品を含むカスタム内部構造を持つ必要があります。

もう1つの可能なアプローチは、Verkleが目撃したUpdateabilityを量子に安全でかなり効率的な方法で行うことを望む場合、メッシュベースのMerkleツリーです。

システムが最悪の場合に十分に効果的でないことが証明されている場合、私たちは別の「帽子のウサギ」であるこの欠点を補うことができます。それは多次元ガスです。 iii）状態およびおそらく他の異なるリソースには、個別のガス制限があります。多次元ガスは複雑さを追加しますが、それを引き換えに、平均シナリオと最悪のシナリオの比率をより厳密に制限します。多次元ガスの場合、証明する理論的最大枝の数は、30,000,000 / 2400 = 12,500から3000に減少する場合があります。これにより、Blake3（ほとんど）が今日でも十分になります。

多次元ガスにより、ブロックリソースの制限により、基礎となるハードウェアリソースの制限がリソースの制限に近いことが複製されます。

別の「呼吸」は、ブロックの後まで状態ルート計算を遅らせる提案です。これにより、状態ルートを計算するために12秒が完全になります。つまり、最も極端な場合でも、約60,000のハッシュ/2秒の証明時間しか十分であり、使用範囲内で私たちをBlake3にかろうじて置くことを意味します。

このアプローチのマイナス面は、このレイテンシを生成レイテンシを実証するために減らすことができるテクノロジーにはよりスマートなバージョンがありますが、1つの期間に軽いクライアントの遅延を増加させることです。たとえば、任意のノードが証明を生成する限り、次のブロックを待つのではなく、ネットワーク上に証明をブロードキャストできます。

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

ステートレスの問題を解決することで、個別の誓約の利便性が大幅に向上します。Orbit SSFやSquad Stakesなどのアプリケーション層ポリシーなど、個々の利害関係の最小バランスを減らすことができる技術が利用可能になると、これはより価値が高くなります。

EOFが同時に導入されると、多次元ガスが簡単になります。これは、実行のための多次元ガスの重要な複雑さは、親の呼び出しを完全なガスに渡さない子供の呼び出しを処理することであり、EOFは単にそのような子供の呼び出しを違法にするためです（そして、ネイティブアカウントの抽象化は、電流内の一部を提供します。主要なユースケースのガスサブコールプロトコルの代替品）。

もう1つの重要な相乗効果は、ステートレスの検証と歴史的期限切れの相乗効果です。今日、顧客は履歴データのほぼテラバイトを保存する必要があります。クライアントがステートレスであっても、クライアントのストレージ履歴の責任を軽減できない限り、クライアントのストレージがほとんどないという夢は実現できません。この点での最初のステップはEIP-4444です。これは、急流またはポータルネットワークに履歴データを保存することも意味します。