ヴィタリック：イーサのThe Verge段階における主要目標

著者：ヴィタリック（イーサリアム創設者）; コンパイル：デン・トン（Golden Finance）

注：この記事は、イーサリアムの創設者であるヴィタリックが最近発表した「イーサリアムプロトコルの未来、その4：イーサリアムプロトコルの可能な未来、Possible futures of the Ethereum protocol, part 4: The Verge"を参照。パート3については、"Vitalik: Ether's The Scourge phaseの主要目標" を参照。"、パート2については"Vitalik: The Surgeフェーズにおいてイーサネット・プロトコルはどのように進化すべきか"、パート1については"EtherのPoSで他に改善できること"を参照してください。以下はパート4の全文です：

Justin Drake氏、Hsiao-wei Wang氏、Guillaume Ballet氏、Ignacio氏、Josh Rudolf氏、Lev Soukhanov氏、Ryan Sean Adams氏、Uma Roy氏のフィードバックとレビューに感謝します。

ブロックチェーンの最も強力な特徴の1つは、誰でも自分のコンピュータ上でノードを実行し、チェーンが正しいかどうかを検証できることです。たとえオンチェーンコンセンサス（PoW、PoS......）を実行しているノードの95％が直ちにルール変更に同意し、新しいルールに従ってブロックの生成を開始したとしても、完全に検証されたノードを実行している全員がそのチェーンを拒否するでしょう。 そのようなグループに属さないステークホルダーは自動的に収束し、古いルールに従ったチェーンを構築し続け、完全に検証されたユーザーはそれに従うことになります。

これがブロックチェーンと中央集権型システムの重要な違いだ。しかし、この機能を維持するためには、完全に検証されたノードを運営することが、重要な数の人々にとって現実的に実現可能である必要があります。これは、プレッジャー（プレッジャーがチェーンを検証しなければ、プロトコルのルール実施に実際には貢献しないため）と一般ユーザーの両方に当てはまる。今日、消費者向けのノートパソコン（この記事を書くのに使ったものも含む）でノードを動かすことは可能だが、そうするのは難しい。 The Vergeは、すべてのモバイルウォレット、ブラウザウォレット、さらにはスマートウォッチがデフォルトでそれを行うように、チェーンを完全に検証する計算コストを非常に安価にすることで、それを変えることを目指している。

The Verge、ロードマップ2023。

もともと「The Verge」は、イーサリアムのステートストアをVerkleツリー（よりコンパクトな証明を可能にするツリー構造）に移行するというアイデアに言及していました。これにより、イーサブロックのステートレス検証が可能になる。ノードは、ハードドライブ上にイーサ状態（アカウント残高、コントラクトコード、ストレージ......）がなくてもイーサブロックを検証できますが、数百キロバイトの証明データと、証明の検証に数百ミリ秒の余分な時間がかかります。今日、Vergeは、ステートレス検証技術だけでなく、すべてのイーサの実行を検証するためのSNARKの使用も含む、イーサチェーンの最大限のリソース効率の検証を可能にすることに焦点を当てた、より大きなビジョンを表しています。

チェーン全体のSNARK検証に対する長年の焦点に加え、もう1つの新たな疑問は、Verkleツリーが最良の技術であるかどうかに関連しています。 Verkleツリーは量子コンピューターによる攻撃に対して脆弱であるため、現在のKECCAK Merkle PatriciaツリーをVerkleツリーに置き換えると、後でまた置き換える必要があります。 メルクル木の自然な代替案は、2分木のSTARKメルクル分岐をそのまま使うことだ。歴史的には、これはオーバーヘッドと技術的複雑さのために実現不可能と考えられてきた。しかし最近では、StarkwareがCircle STARKを使ってラップトップで1秒間に170万個のPoseidonハッシュを証明するのを見ましたし、GKRのような技術のおかげで、より「伝統的な」ハッシュを証明する時間は急速に短縮されています。

その結果、Vergeはこの1年で、可能性に対してよりオープンになりました。

Verge：主な目標

ステートレスクライアント：完全に検証されたクライアントと誓約ノードは、数GB以上のストレージを必要としません。

• （長期的に）スマートウォッチでチェーン（コンセンサスと実行）を完全に検証する。いくつかのデータをダウンロードし、SNARKを検証して完了です。

• ステートレス検証：

• EVM実行の妥当性の証明

• コンセンサスの妥当性の証明

ステートレス検証：バークレーかSTARKsか

私たちはどのような問題を解決しようとしているのか？

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

このため、完全に検証されたイーサノードを実行できるユーザーの数が減ります。ハードディスクはイーサのすべての状態、さらには何年もの履歴を保存するのに十分な容量がありますが、人々がデフォルトで購入するコンピュータには、数百ギガバイトのストレージしかないことがよくあります。ノードが全状態をダウンロードする必要があるため、数時間から数日かかることもあります。ノードはすべての状態をダウンロードする必要があり、それには数時間から数日かかることもある。例えば、誓約者が誓約の設定をアップグレードすることが難しくなります。新しいクライアントを起動し、同期されるのを待ち、古いクライアントをシャットダウンしてキーを転送する - ダウンタイムなしでこれを行うことは技術的には可能ですが、実際にはこれは技術的に複雑です。

それは何であり、どのように機能するのでしょうか?

ステートレス認証は、ノードが完全な状態を持たずにブロックを検証できるようにする技術です。その代わりに、各ブロックは、(i)ブロックがアクセスする状態の特定の場所（コード、残高、ストレージなど）の値、および(ii)これらの値が正しいという暗号学的証明を含む証人を運びます。

ステートレス認証を実用的に実装するには、イーサネットのステートツリー構造を変更する必要があります。これは、現在のMerkle Patriciaツリーが、特に最悪のシナリオにおいて、どのような暗号証明スキームの実装に対しても極めて不親切であるためです。これは「オリジナルの」Merkleブランチにも、STARKでMerkleブランチを「ラップ」する可能性にも当てはまります。

• これは16進数の木です（つまり、各ノードは16個の子を持ちます）。これは平均して、サイズNのツリーの証明は32*(16-1)*log16(N) = 120*log2(N)バイト、つまり232アイテムのツリーでは約3840バイトになることを意味します。バイナリツリーの場合は、32*(2-1)*log2(N) = 32*log2(N)バイト、つまり約1024バイトだけです。

• コードはメルケル化されていません。これは、アカウントコードへのアクセスを提供するには、最大長24000バイトの完全なコードを提供する必要があることを意味します。

最悪のシナリオは次のように計算できます:

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

分岐が多い場合、分岐の先頭が繰り返されるため、分岐コストはわずかに低くなります(8*480ではなく5*480)。しかし、それでも、1つのスロットでダウンロードされるデータ量は完全に非現実的です。(i)KECCAKはSTARKに対して不親切である。(ii)330MBのデータは、KECCAKラウンド関数への500万回の呼び出しを証明しなければならないことを意味する。これは、STARKがKECCAKをより効率的に証明することができたとしても、1つの方法である。

もしSTARKがKECCAKをより効率的に証明できたとしても、それは1つの方法です。

16進ツリーをバイナリツリーに置き換え、Merkelizeコードを追加するだけで、最悪のシナリオはおよそ30,000,000 / 2,400 * 32 * (32 - 14 + 8) = 10,400,000バイト～214ブランチ（8は証明の葉までの長さ）になります。このためには、個々のコードの塊にアクセスするために課金されるGasコストを変更する必要があることに注意してください; EIP-4762はこれを行います。 10.4メガバイトの方がはるかに良いですが、それでも多くのノードで1つのスロットでダウンロードするにはデータが多すぎます。そこで、より強力な技術を導入する必要がある。これを行うには、2つの主要なソリューションがあります：VerkleツリーとStarkedバイナリハッシュツリーです。

Verkleツリー

Verkleツリーは、楕円曲線ベースのベクトルコミットメントを使って証明を短くします。鍵は、各親子関係に対応する証明の断片が、木の幅に関係なく、わずか32バイトであることです。ツリーの幅に関する唯一の制限は、ツリーの幅が広すぎると、証明の計算効率が低下することである。イーサネットの推奨実装幅は256です。

したがって、証明の1つの分岐のサイズは32*log256(N) = 4*log2(N)バイトになります。理論的な最大証明サイズは、約30,000,000/2,400*32*(32-14+8)/8 = 1,300,000バイトになります(ステートブロックの不均等な分布のため、実際には計算が若干異なりますが、これは第一段階としてうまく機能します)。

追加の警告として、上記のすべての例において、この「最悪のケース」のシナリオは最悪のケースではないことに注意してください。この場合、ワーストケースの枝の長さは約2倍長くなる。しかし、その注意点を考慮しても、Verkleツリーは約2.6MBのワーストケースの証明を与え、これは今日のワーストケースのコールデータとほぼ一致します。

私たちはまた、この注意書きを別のことに使用します。「隣接する」ストレージ、つまり同じコントラクトからのコードの多くのブロック、または隣接するスロットにアクセスするのを非常に安価にします。 EIP-4762は隣接の定義を提供し、隣接アクセスは200ガスで課金されます。隣接アクセスの場合、ワーストケースのプルーフサイズは30,000,000/200*32 = 4,800,800バイトとなり、これはまだほぼ許容範囲内である。セキュリティのためにこの値を小さくしたい場合は、隣接アクセスのコストを少し増やせばよい。

スタードバイナリハッシュツリー

ここでのテクニックはかなり自明です：バイナリツリーを作り、証明する必要があるブロック内の値の最大10.4MBの証明を取り、その証明をその証明のSTARKで置き換えます。これは、証明自体が証明されるデータのみを含み、さらに実際のSTARKの～100～300kBの固定オーバーヘッドを含むという事実につながります。

ここでの主な課題は証明時間です。バイトを数える代わりにハッシュを数えることを除けば、上記と基本的に同じ計算を行うことができます。 10.4MBのブロックは33万ハッシュを意味します。攻撃者が長い共通接頭辞を持つアドレスをツリーから「採掘」する可能性を加えると、実際の最悪のシナリオは約66万ハッシュになる。ですから、1秒あたり約20万ハッシュを証明できれば、それでいいのです。

これらの数値は、STARKに親和性を持たせるために特別に設計されたPoseidonハッシュ関数を使用したコンシューマー向けラップトップで達成されています。しかし、Poseidonは比較的未熟なので、多くの人はまだそのセキュリティを信用していません。

• すぐにPoseidonのセキュリティ分析をたくさん行い、L1に配備するためにPoseidonに慣れる

• 2つの現実的な方法があります。p>SHA256やBLAKEのような、より「保守的な」ハッシュ関数を使う

執筆時点では、StarkwareのSTARKプローバは、保守的なハッシュ関数を証明したい場合、消費者向けのラップトップでは、1秒間に約10～30kのハッシュ値しか証明できません。消費者向けラップトップで毎秒30kハッシュ。しかし、STARK技術は急速に進歩している。今日でさえ、GKRベースの技術は、それを～100～200kの範囲まで増加させる可能性を示しています。

検証ブロック以外の使用例

検証ブロックの他に、より効率的なステートレス検証のための3つの重要な使用例があります:

• メモリプール：トランザクションがブロードキャストされるとき、p2pネットワークのノードはトランザクションを再ブロードキャストする前に、そのトランザクションが有効であることを検証する必要があります。今日、検証には署名の検証だけでなく、残高が十分かどうか、乱数が正しいかどうかのチェックも含まれる。将来的には（例えば、EIP-7701のようなネイティブなアカウント抽象化を使用する）、状態アクセスを実行するEVMコードの実行が必要になるかもしれない。ノードがステートレスである場合、トランザクションはステートオブジェクトの証明を伴う必要があります。

• Inclusion Lists:これは提案されている機能で、（潜在的に小規模で複雑でない）公平性の証明検証者が、（潜在的に大規模で複雑な）ブロック構築者の希望に関係なく、次のブロックにトランザクションを含めるよう強制できるようにするものです。これにより、強力なプレーヤーが取引を遅らせることでブロックチェーンを操作する能力を低下させることができる。しかし、そのためにはバリデーターが包含リストの取引の正当性を検証する方法を持つ必要がある。

• ライトクライアント：ユーザーがウォレット（メタマスク、レインボー、ラビィ...など）を使ってチェーンにアクセスできるようにしたい場合。中央集権的な参加者を信頼せずにチェーンにアクセスしたい場合は、ライトクライアント（Heliosなど）を実行する必要があります。ヘリオスのコア・モジュールは、検証済みのステート・ルートをユーザーに提供する。

これらすべてのユースケースの共通点の1つは、かなり多くの証明を必要とするが、その1つ1つは小さいということです。そのため、STARK証明はあまり意味がありません。代わりに、Merkleブランチを直接使うのが最も現実的です。 ブロックBをルートとするステートオブジェクトXの証明が与えられたとき、その証人を含むサブブロックB2を受け取れば、ブロックB2をルートとするように証明を更新できる。 ヴァークル証明自体も更新可能です。

既存の研究との関連は？

ヴァークル・ツリー：https://vitalik.eth.limo/general/2021/06/18/verkle.html

ジョン・クスマウル（John Kuszmaul）氏の元のバークルツリー論文：https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

スタークウェア証明データ：https://x.com/StarkWareLtd/status/1807776563188162562

ポセイドン2号論文：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、その他の「STARKフレンドリー」ハッシュ関数のセキュリティ分析

• 例えばBiniusやGKRのアイデアに基づいた、「保守的な」（あるいは「伝統的な」）ハッシュ関数に対する超効率的なSTARKプロトコルのさらなる開発。

私たちはまもなく、次の3つの選択肢のうちどれを選ぶべきかの決定点を得ることになるでしょう：(i)Verkle木、(ii)STARKフレンドリーなハッシュ関数、(iii)保守的なハッシュ関数。これらの特性は、おおよそ次の表にまとめることができます。

これらの「ヘッダー番号」以外にも、いくつか重要な考慮事項があります:

• ヴァークル・ツリーのコードはかなり成熟しています。Verkle以外のものを使用すると、おそらくハードフォークによってデプロイを遅らせることになるでしょう。特に、ハッシュ関数の解析やプローバーの実装に余分な時間が必要な場合や、Etherに早急に盛り込みたい他の重要な機能がある場合は、おそらく問題ないでしょう。

• 状態のルートを更新するためにハッシュを使用することは、Verkle木を使用するよりも高速です。これは、ハッシュベースのアプローチがノード全体の同期時間を短縮することを意味します。

• V バークルツリーには、次のような興味深い特徴があります。ウィットネス更新プロパティ - Verkleツリーのウィットネスは更新可能です。このプロパティは、メモリプール、コンテントメントリスト、その他のユースケースで有用であり、実装をより効率的にするのにも役立ちます。ステートオブジェクトを更新すると、最後のレベルを読む必要さえなく、証人の最後のレベルを更新できます。

• バークルの木は、SNARKによる証明がより困難です。Verkleの証明は、証明サイズを数キロバイトまで縮小したい場合、いくつかの困難が生じます。これは、Verkle証明の検証では256ビットの操作が大量に発生するため、証明システムに大量のオーバーヘッドを持たせるか、Verkle証明に使用する256ビット部分を含む独自のカスタム内部構造を持たせる必要があるためです。

Verkle証人の更新可能性を量子安全でかなり効率的な方法で行いたい場合、もう1つの可能なルートは格子ベースのMerkleツリーです。

証明システムが最悪のシナリオで十分に効率的でない場合、多次元ガス（(i)calldata、(ii)computation、(iii)state access、および潜在的に他の異なるリソースに対する別々のガス制限）を使用することで、これを補うことができます。制限。多次元ガスは複雑さを加えるが、その代わりに平均的なケースと最悪のケースの比率をより厳しく制約する。多次元ガスでは、理論的に証明されるべき分岐の最大数は、30,000,000 / 2400 = 12,500から3000に減少するかもしれません。 これは、BLAKE3が今日でも（かろうじて）十分であり、それ以上の証明の改善はないでしょう。

多次元ガスは、ブロックのリソース制約を、基礎となるハードウェアの制約をより忠実に再現することを可能にします。

もう1つの「帽子から取り出したウサギ」は、ステートルート計算をブロックの後のスロットまで遅延させるという提案です。これは、最も極端なケースでも、約60,000ハッシュ/秒の証明時間で十分であることを意味します。

この手法の欠点は、ライトクライアントの待ち時間が一定時間長くなることですが、この待ち時間を証明生成の待ち時間だけに短縮する、より賢いバージョンの手法もあります。たとえば、ノードが証明を生成するとすぐに、次のブロックを待つ代わりに、その証明をネットワーク全体にブロードキャストすることができます。

ロードマップの他の部分とどのように相互作用するのでしょうか？

ステートレス問題を解決することで、個別の誓約の利便性が大幅に向上します。個々の誓約の最低残高を減らすことができる技術（たとえば、Orbit SSFやアプリケーション層のポリシー（たとえば、分隊の誓約））が利用可能になれば、この価値はさらに高まります。

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

もう1つの重要な相乗効果は、ステートレス検証と履歴の有効期限です。今日、クライアントはテラバイト近い履歴データを保存しなければなりません。このデータは状態データの数倍です。クライアントがステートレスであっても、履歴を保存する責任からクライアントを解放しない限り、クライアントにほとんどストレージがないという夢は実現できません。この方向への第一歩はEIP-4444であり、これはトレントまたはポータルネットワークに履歴データを保存することも意味する。

EVM 実装の妥当性の証明

私たちはどのような問題を解決しようとしているのでしょうか?

イーサネット ブロック検証の長期的な目標は明確です。(i) ブロック、おそらくはブロックのほんの一部をダウンロードし、データの可用性をサンプリングし、(ii) ブロックが有効であることの証明のごく一部を検証することによって、イーサネット ブロックを検証できるようにすることです。これは、モバイルクライアント、ブラウザウォレット内、あるいは（データ可用性の部分を除けば）別のチェーンで行うことも可能な、非常にリソース集約的な操作になるでしょう。

これを実現するには、(i)コンセンサス層（つまり衡平性の証明）と(ii)実行層（つまりEVM）のSNARKまたはSTARK証明が必要です。前者はそれ自体が課題であり、コンセンサスレイヤーのさらなる改良（例えば、シングルスロットの最終決定性）で対処されるべきである。後者はEVMの実行を証明する必要があります。

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

正式には、イーサネットの仕様では、EVMは状態遷移関数として定義されています：ある事前状態S、ブロックBがあり、事後状態S'=STF(S, B)を計算しています。ユーザーがライトクライアントを使用している場合、彼らはSとS'、あるいは完全なBを持っていません。代わりに、彼らは事前状態のルートR、事後状態のルートR'、およびブロックハッシュHを持っています。: disc;">

存在すれば、Ether EVMの実行を完全に検証できる軽いクライアントを持つことができます。この場合、クライアントのリソースはかなり少なくなります。真の完全検証イーサネットクライアントを得るためには、コンセンサス側にも同じことをする必要があります。

EVM計算のための有効性の証明の実装はすでに存在し、L2で多用されています。しかし、EVMの有効性の証明をL1に適用できるようにするには、まだやるべきことがたくさんあります。

既存の研究との関連は？

EC PSE ZK-EVM（より良い代替手段が存在するため、現在は非推奨）:https://github.com/privacy-scaling-explorations/zkevm- Circuits

RISC-0にコンパイルされたEVMをコンパイルすることで動作するZeth。RISC-0 ZK-VM にコンパイルされます: https://github.com/risc0/zeth

RISC-0 ZK-VM に EVM をコンパイルすることで動作する Zeth: https://github.com/risc0/zeth

ZK-EVM形式検証プロジェクト: https://verified-zkevm.org/

他に何をすべきか、何を量る必要があるか？

今日、EVMの妥当性の証明は、セキュリティと証明時間という2つの点で不十分です。

安全な有効性の証明には、SNARK が実際に EVM の計算を検証し、そこにエラーがないことを保証する必要があります。セキュリティを向上させる2つの主なテクニックは、複数の証明者と形式的検証です。複数のプローバとは、あたかも複数のクライアントが存在するかのように、独立に記述された複数の有効性証明実装を持ち、それらの実装の十分なサブセットがそのブロックを証明した場合、クライアントにブロックを受理させることを意味する。形式的な検証では、数学の定理を証明するために一般的に使用されるツール（Lean4など）を使用して、妥当性の証明がPythonで書かれたEVM仕様の正しい実装のみを入力として受け入れることを示します。

十分速い証明時間とは、どのイーサネットブロックも4秒未満で証明できることを意味します。今日、私たちは2年前に考えていたよりもずっと近づいていますが、その目標にはまだほど遠い状態です。そこに到達するためには、3つの面で前進する必要があります。strong>並列化 - 現在最速のEVMプローバーは、平均的なイーサブロックを～15秒で証明できます。これは、何百ものGPU間で並列化し、最終的にそれらの作業を集約することで実現します。理論的には、O(log(N))時間で計算を証明できるEVM証明器を作る方法を正確に知っています: 1つのGPUに各ステップを実行させ、次に「集約ツリー」を実行します:

これを実装するのは困難です。最悪の場合（つまり、非常に大きなトランザクションがブロック全体を占有する場合）でも機能するように、計算された分割はトランザクション単位ではできません。実装上の重要な課題として、VMの "メモリ "が証明の異なる部分で一貫していることを保証する必要があります。しかし、この再帰的な証明ができれば、他の軸に改善がなくても、少なくとも証明者の待ち時間の問題は解決されたことになります。

• Proof System Optimisation -- オリオン。証明システムの最適化 -- Orion、Binius、GKR、およびその他の新しい証明システムによって、汎用コンピューティングの証明時間がまた大幅に短縮されるかもしれません。

• EVMのガスは他の変更を消費する --EVMの多くは、特に最悪のケースにおいて、証明者にとってより使いやすいように最適化することができます。平均的なEtherブロックを4秒で証明するだけでは不十分で、もし攻撃者が証明者の時間を10分も奪うようなブロックを構築できるのであれば。必要なEVMの変更は、主に2つのカテゴリーに分けることができます。 演算の証明に長い時間がかかる場合、計算が比較的高速であっても、ガスコストは高くなるはずです。 EIP-7667は、この点で最も深刻な問題に対処するために提案されたEIPです。比較的安価なオペコードやプリコンパイルとして公開されている（従来の）ハッシュ関数のGasコストを大幅に増加させます。これらのガスコストの増加を補うために、比較的安価なEVMオペコードを証明するガスコストを削減し、平均スループットを同じに保つことができます。

• データ構造の置き換え --ステートツリーをSTARKにより適した代替物に置き換えることに加えて、トランザクションリスト、レシートツリー、および証明にコストがかかるその他の構造を置き換える必要があります。 Ethan KisslingのEIPは、トランザクションとレシート構造をSSZに移動させる([1] [2] [3])。

これに加えて、前のセクションで述べた2つの「帽子から取り出したウサギ」(多次元ガスと遅延状態根)も、ここで役立ちます。しかし、現在必要なことを行うのに十分なテクニックがあることを意味するステートレス検証とは異なり、これらのテクニックを使用しても、完全なZK-EVM検証にはより多くの作業が必要になることは注目に値します。

上記で言及されていないことの1つに、証明ハードウェアがあります：GPU、FPGA、ASICを使用して証明をより高速に生成することです。 Fabric Cryptography、Cysic、Accsealの3社がこれを推進しています。レイヤー1では高度に分散化された状態を維持することが強く望まれており、プルーフ生成は相当数のサブセットの能力の範囲内でなければならないことを意味するからだ。イーサネット・ユーザーは、一企業のハードウェアでボトルネックに遭遇することはないはずだ。レイヤー2は、より根本的なトレードオフを可能にします。

• Parallel proofs require proof systems where different parts of the proof can "share memory「(ルックアップテーブルなど)。これを行うためのテクニックはわかっていますが、実装する必要があります。

• ワーストケースの証明時間を最小化するための、理想的なガスコストのバリエーションセットを見つけるには、さらに分析が必要です。

• 私たちは、証明システム

ここで考えられるトレードオフは以下の通りです。strong>セキュリティと証明者の時間：ハッシュ関数を使用した肯定的な選択、より複雑または肯定的なセキュリティの仮定を持つ証明システム、またはその他の設計上の選択は、証明者の時間を短縮する可能性があります。

ロードマップの残りの部分とどのように相互作用するのでしょうか?

• Level 2の有効性の証明（「ZKロールアップ」）。"ZKロールアップ"）

• "STARKバイナリハッシュ証明 "ステートレス方式

レイヤー1での有効性の証明の実装に成功したことで、以下のことが可能になりました。究極に簡単な個人の誓約：最も弱いコンピューター（携帯電話やスマートウォッチを含む）でも誓約を行うことができる。これにより、個人誓約のその他の制限（最低32ETHなど）に対処する価値がさらに高まります。

さらに、L1のEVM有効性証明は、L1のGas制限を大幅に改善することができます。

Consensus Validityの証明

私たちはどのような問題を解決しようとしているのでしょうか？

SNARKでイーサブロックを完全に検証できるようにしたいのであれば、証明する必要があるのはEVMの実行だけではありません。また、コンセンサスも証明する必要があります。コンセンサスとは、入出金、署名、ベリファイアの残高更新、およびEtherのプルーフ・オブ・エクイティの他の要素を処理するシステムの一部です。

コンセンサスはEVMよりもはるかにシンプルですが、レイヤー2のEVMアグリゲートがないという課題に直面しています。その結果、イーサネット・コンセンサスの証明の実装は、証明システム自体はその上に構築できる共有作業であるにもかかわらず、「ゼロから」行う必要があります。

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

ビーコンチェーンは、EVMのような状態伝達関数として定義されます。

• ECADD (BLSシグネチャの検証用)

• ペアリング (BLSシグネチャの検証用)

• ビーコンチェーンは、EVMのように状態伝達関数として定義されます。

• SHA256ハッシュ(状態の読み取りと更新のため)

各ブロックにおいて、各検証者(署名が複数のアグリゲートに含まれる可能性があるため、おそらく1つ以上)に対して1-16のBLS12-381 ECADDを証明する必要があります。これはサブセット事前計算技術で補うことができるので、各検証者はBLS12-381 ECADDであると言える。現在、タイムスロットあたりの検証者の署名数は約3万である。将来的には、単一スロットの最終的な決定性に関して、(こちらの注を参照)のどちらかの方向に変わる可能性がある。もし "ロバスト "路線を取るのであれば、タイムスロットあたりの検証者数は100万人まで増加する可能性があります。

BLSアグリゲーションがどのように機能するか。アグリゲーション署名を検証するには、ECMULではなく、各参加者のECADDだけが必要です。しかし、30,000のECADDを証明するのはまだ大変です。

ペアについては、現在、スロットごとに最大128の証明があり、これは128のペアを検証する必要があることを意味します。EIP-7549とさらなる変更により、これはスロットあたり16に減るかもしれません。ペアの数は少ないが、コストは非常に高い。各ペアの実行（または証明）には、ECADDの何千倍もの時間がかかる。

BLS12-381演算の証明における主な課題の1つは、BLS12-381フィールドサイズに等しい曲線次数を持つ便利な曲線が存在しないことであり、これはどの証明システムにもかなりのオーバーヘッドを追加します。一方、イーサネット用に提案されたVerkleツリーはBandersnatch曲線を使用して構築されており、BLS12-381自体がSNARKシステムでVerkleブランチを証明するための自然な曲線となっている。かなり単純な実装であれば、1秒間に約100G1の追加を行うことができます。これを十分に高速に証明するには、GKRのような巧妙なテクニックが必要になることはほぼ間違いないでしょう。

SHA256ハッシュの場合、現在の最悪のシナリオはエポック遷移ブロックであり、このブロックではバリデータショートバランスツリー全体と多数のバリデータバランスが更新されます。バリデータショートバランスツリーはバリデータ1つにつき1バイトしかないので、 約1MBのデータが再ハッシュされることになる。これは32,768回のSHA256呼び出しに相当する。1000人のバリデータの残高がしきい値を上回ったり下回ったりした場合、バリデータの有効残高を更新する必要がある。メルクル機構は1バリデータあたり90ビットを必要とするが（したがって11MBのデータ）、これはエポック中いつでも計算できる。単一エポック最終の場合、これらの数値は詳細に応じて再度増減することができる。トラックはある程度シャッフルの必要性を回復するかもしれませんが、シャッフルは不要になります。

もう1つの課題は、ブロックを検証するために、バリデータの状態（公開鍵を含む）をすべて読み取る必要があることです。100万のバリデータとMerkle分岐の場合、公開鍵を読み取るだけで4800万バイトかかります。これには、1周期あたり数百万のハッシュが必要です。効率的なルックアップのために最適化された別のデータ構造を証明システムに保存し、この構造への更新を提供します。

まとめると、多くの課題があります。

これらの課題を最も効果的に解決するには、ビーコンチェーンを深く再設計する必要がありそうです。

• ハッシュ関数の変更:現在、「完全な」SHA256ハッシュ関数を使用することができます。"SHA256ハッシュ関数を使用しているため、パディングにより、各呼び出しは基礎となる圧縮関数への2回の呼び出しに対応します。少なくとも、SHA256圧縮関数に切り替えることで2倍の利得を得ることができます。Poseidonに切り替えると、約100倍の利得が得られ、（少なくともハッシュに関しては）すべての問題が完全に解決される。「これは数秒で証明できます。

• Orbitの場合、スクランブルされた検証者レコードを直接保存します。あるスロットの委員会として、ある数の検証者（例えば、8,192や32,768）を選んだ場合、それらを直接隣の状態に入れ、最小のハッシュ量が、すべての検証者の公開鍵を証明に読み込むのに必要なハッシュ量になるようにします。を証明に読み込む。これにより、すべてのバランス更新を効率的に行うこともできる。

• 署名集約: 高性能な署名集約スキームは、実際には、署名のサブセットの中間証明がネットワーク内の個々のノードによって実行される、ある種の再帰的証明を含むことになります。これにより、証明の負荷がネットワーク内の多くのノードに自然に分散され、「最終的な証明者」の作業負荷がはるかに小さくなります。

• 他の署名スキーム: Lamport+Merkle署名では、署名を検証するために256+32のハッシュが必要である。署名スキームを最適化すれば、小さな定数ファクターでこれをさらに改善できる。Poseidonを使えば、これは1スロットで証明できる範囲内である。しかし実際には、再帰的な集約スキームを使えば、これはずっと速くなります。

既存の研究とのつながりは？

イーサネットのコンセンサス証明（同期委員会のみ）：https://github.com/succinctlabs/eth-proof-of-consensus

クリーン、SP1内のヘリオス：https://github.com/succinctlabs/sp1-helios

Clean, pre-compiled BLS12-381: https://blog.succinct.xyz/succinctshipsprecompiles/

Halo2ベースのBLS集合署名検証：https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

他に何が必要か？何を計量する必要があるのか？

現実には、イーサネットのコンセンサスの妥当性を証明するまでには何年もかかるだろう。これは、Poseidonのような「急進的な」ハッシュ関数を使用するのに十分な自信を持つために、シングルスロットの最終性、軌道、署名アルゴリズムの変更、潜在的なセキュリティ分析を達成するために必要なタイムラインとほぼ同じです。したがって、これらの他の問題に対処するのが最も理にかなっており、その際にSTARK-friendlinessを念頭に置く必要があります。

主なトレードオフは、イーサネットコンセンサスレイヤーを改革するためのより漸進的なアプローチと、より積極的な「一度に多くの変更を行う」アプローチとの間の、操作の順序にあると思われます。EVMの場合、漸進的なアプローチは、後方互換性へのダメージを最小限に抑えることができるため、理にかなっている。コンセンサスレイヤーについては、後方互換性はそれほど問題ではなく、ビーコンチェーンの構築方法の詳細をより「全体的」に再考することで、SNARKとの親和性を最適化できるという利点があります。

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

STARKフレンドリーさは、イーサネットのProof-of-Stakeコンセンサスの長期的な再設計の主要な焦点となる必要があります。