原文のタイトル：《イーサリアムプロトコルの可能な未来、パート4：ザ・ヴァージュ》

ヴィタリック・ブテリンによるオリジナル記事

オリジナルコンピレーション:Mensh、ChainCatcher

Justin Drake氏、Hsia-wei Wanp氏、Guillaume Ballet氏、Icinacio氏、Rosh Rudolf氏、Lev Soukhanoy氏、Ryan Sean Adams氏、Uma Roy氏のフィードバックとレビューに感謝します。

ブロックチェーンの最も強力な機能の1つは、誰もが自分のコンピューターでノードを実行し、ブロックチェーンの正確性を検証できることです。つまり、9596のPoW、PoSなどのコンセンサスノードが即座にルールを変更し、新しいルールに基づいてブロックを生成しようとしても、完全な検証ノードを実行しているすべての人はそのチェーンを拒否します。この陰謀団体に属さない鋳造者は自動的に古いルールに従い続けるオンチェーンに集まり、そのチェーンを構築し続けますが、完全な検証を行ったユーザーはそのチェーンに従います。

これはブロックチェーンと中央集権システムの重要な違いです。しかし、この機能を実現するには、完全検証ノードを実行するには、十分な数の人々が実際に実現可能である必要があります。これはステークホルダーにも当てはまります（ステークホルダーがチェーンを検証しない場合、彼らはプロトコルルールの実行に貢献していません）。また、一般ユーザーにも当てはまります。今日、ノートパソコン（この記事を書いたノートパソコンを含む）でノードを実行することは可能ですが、それは困難です。The Vergeはこの状況を変え、完全検証チェーンの計算コストを低くし、すべての携帯電話ウォレット、ブラウザウォレット、さらにはスマートウォッチがデフォルトで検証するようにします。

The Verge 2023 ロードマップ

最初、"Verge"はETHの状態をVerkleツリーに移動することを意味しました-よりコンパクトな証明を可能にするツリー構造で、ETHブロックの状態を保存せずにブロックを検証できます。ノードはETHのブロックを検証できますが、ETHの状態（口座残高、契約コード、ストレージスペースなど）をディスクに保存する必要はありません。これには、数百KBの証明データと数百ミリ秒の追加時間がかかります。今日、Vergeはより大きなビジョンを表し、ETHの最大のリソース効率を実現することに焦点を当てており、状態なし検証技術だけでなく、SNARKを使用してすべてのETHの実行を検証することを含んでいます。

SNARK検証全体に対する長期的なフォローに加えて、Verkleツリーが最適なテクノロジーであるかどうかという新しい問題があります。Verkleツリーは量子コンピューターの攻撃を受けやすいため、現在のKECCAK Merkle PatriciaツリーにVerkleツリーを置き換えると、将来的に再度ツリーを置き換える必要があります。Merkleツリーの自己置換方法は、Merkleブランチをスキップし、それをバイナリツリーに配置するSTARKを直接使用することです。歴史的には、コストと技術的複雑さのために、この方法は非現実的と見なされてきました。しかし最近、Starkwareは1台のノートパソコンでckcle STARKsを使用して、1秒あたり170万個のPoseidonハッシュを証明し、GKBなどの技術の登場により、より多くの「従来の」ハッシュ値の証明時間も急速に短縮されています。したがって、過去1年間で、「Verge」はよりオープンになり、さまざまな可能性があります。

The Verge: キーポイント

• 無状態クライアント：完全な検証クライアントとマーキングノードに必要なストレージスペースは数GBを超えてはなりません。 *（長期）スマートウォッチで完全にチェーンを検証する（コンセンサスと実行）。データをダウンロードし、SNARKを検証し、完了します。

この章では

• 無状態クライアント：Verkle または STARKs
• EVM実行の有効性の証明
• コンセンサス的有効性の証明

ステートレス検証: Verkle または STARKs

私たちは何の問題を解決する必要がありますか？

現在、ETHフェンクライアントは、ブロックを検証するために数百ギガバイトの状態データを保存する必要があります。また、この量は毎年増加しています。元の状態データは年間約30 GB増加し、1つのクライアントはトリプレットを効果的に更新するために、いくつかの追加データを保存する必要があります。

これにより、完全な検証イーサリアムノードを実行できるユーザーの数が減少しました。イーサリアムの状態や数年の履歴を保存するのに十分な大きなハードディスクがどこにでもあるにもかかわらず、人々がデフォルトで購入するコンピュータには通常、数百GBまたは数千GBのストレージしかありません。状態のサイズは、ノードを最初に構築するプロセスに巨大な摩擦をもたらしました。ノードは全状態をダウンロードする必要があるため、これには数時間または数日かかる場合があります。これにより、さまざまな連鎖反応が引き起こされます。例えば、ノード作成者がノード設定をアップグレードする難易度が大幅に上がります。技術的には、停止することなくアップグレードを完了できます。新しいクライアントを起動し、同期を待って、古いクライアントを閉じて秘密鍵を転送します。しかし、実際の操作では、これは技術的に非常に複雑です。

それはどのように動作しますか？

ステートレス検証は、ノードがブロックを検証するために完全な状態を把握せずに行うことを許可する技術です。代わりに、各ブロックには証明が付属しており、次の情報が含まれています：(i) ブロックがアクセスする特定の状態の位置の値、コード、残高、ストレージ、 (ii) これらの値が正しいことを証明するための暗号化証明。

実際には、状態を持たない検証を実現するには、イーサリアムの状態ツリー構造を変更する必要があります。これは、現在のMerkle Patriciaツリーが、暗号化証明スキームを実装することに非常に不向きであるためです、特に最悪の場合には。"元の"MerkleブランチやSTARKに"包装"する可能性に関係なく、主な困難はMPTのいくつかの弱点に由来します。

1. これは16分木（つまり、各ノードに16個の子ノードがある）です。これは、サイズNの木で、証明に平均して32 （16-1） log 16（N）= 120 * log 2（N）バイト、または2 ^ 32項目の木で約3840バイトが必要です。バイナリツリーの場合、32 （2-1） log 2（N）= 32 * log 2（N）バイト、または約1024バイトが必要です。

2. コードはメルクル化されていないため、アカウントのコードへのアクセス権限を証明するには、コード全体を提供する必要があります。最大で24000バイトです。

最悪の状況は次のように計算することができます:

30000000 ガス / 2400 (冷アカウント阅读成本) * （5 * 488 + 24000) = 330000000 字节

分岐コストはわずかにドロップします（8* 480 の代わりに5* 480を使用）が、分岐が多い場合、その先端部分が繰り返し表示されるためです。しかし、1つのスロット内でダウンロードするデータ量はまったく現実的ではありません。それをSTARKで包むことを試みると、2つの問題に直面します：(i) KECCAKはSTARKに対して比較的にフレンドリーではありません。(ii) 330 MBのデータは、KECCAKラウンド関数を500万回呼び出すことを証明する必要があります。これは、最も強力な消費者向けハードウェアを除いて、すべてのハードウェアで証明できない可能性があります。たとえSTARKがKECCAKの効率を向上させることができたとしてもです。

もしも、16進数ツリーの代わりにバイナリツリーを直接使用し、コードを追加のMerkle化処理を行う場合、最悪の場合はおおよそ30000000/240032(32-14+8) = 10400000バイトになります（14は2 ^ 14ブランチの冗長ビットを引くための減算、8はコードブロックに入る証明の長さです）。注意すべきは、これにはガスのコストの変更が必要で、個々のコードブロックへのアクセスに対して料金がかかります；EIP-4762はそれを実現しています。10.4MBの容量はかなり良いですが、多くのノードにとっては、1つのスロットでダウンロードするデータがまだ多すぎます。そのため、より強力なテクノロジーを導入する必要があります。この点で、2つの主要な解決策があります：VerkleツリーとSTARKedバイナリハッシュツリー。

ヴェルクルツリー

Verkle 木は、より短い証明のために楕円曲線ベースのベクトルコミットメントを使用します。 ロック解除の鍵は、ツリーの幅に関係なく、各親子関係に対応する証明部分がわずか32バイトであることです。 プルーフツリーの幅の唯一の制限は、プルーフツリーが広すぎると、プルーフの計算効率が低下することです。 イーサリアムの提案された実装の幅は256です。

したがって、証明の単一のブランチのサイズは 32 - 1 OG 256(N) = 4× log 2(N) バイトになることが証明されました。したがって、理論上の最大証明サイズはおおよそ 30000000 / 2400 × 32× (32-14 + 8) / 8 = 130000バイトです（状態ブロックの分布が均一でないため、実際の計算結果は異なる可能性がありますが、第1近似値としては有効です）。

また、上記のすべての例で、「最悪の状況」は実際の最悪の状況ではありません。より悪い状況として、攻撃者が意図的に2つのアドレスを"採掘"し、それらがツリー内で長い共通の接頭辞を持ち、そのうちの1つのアドレスからデータを読み取ることがあります。これにより、最悪の状況下の枝の長さが2倍に延長される可能性があります。しかし、そのような状況があっても、Verkleツリーの最悪の証明の長さは2.6 MBであり、現在の最悪の状況下の検証データとほぼ一致します。

そして、私たちはこの注意事項を使用して、もう一つのことを行いました：「隣接する」ストレージスペースへのアクセスコストを非常に低くしました。これは、同じ契約の多くのコードブロックまたは隣接するストレージスロットのいずれかである場合です。EIP-4762では、隣接アクセスに対してのみ200ガスの料金がかかります。隣接アクセスの場合、最悪の場合の証明のサイズは30000000 / 200 * 32 - 4800800バイトになりますが、これはまだ公差範囲内です。安全のためにこの値を減らしたい場合は、隣接アクセスのコストをわずかに増やすことができます。

STARKed バイナリハッシュツリー

この技術の原理は明らかです：ただし、最大10.4MBの証明を取得する2分木を作成し、ブロック内の値を証明し、そしてSTARKの証拠で証明を置き換えるだけです。これにより、証明自体には証明されたデータだけが含まれ、実際のSTARKからの100-300kBの固定コストが追加されます。

ここでの主な課題は、検証時間です。上記の基本的に同じ計算を行うことができますが、バイト数ではなくハッシュ値を計算します。10.4 MBのブロックは330000個のハッシュ値を意味します。さらに、攻撃者がアドレスツリー内で長い共通の接頭辞を持つ可能性を考慮すると、最悪の場合には約660000個のハッシュ値が発生します。したがって、秒間200,000のハッシュ値を証明できれば問題ありません。

Poseidonハッシュ関数を使用している消費者向けノートパソコンでは、これらの数字がすでに01928374656574839201に達しています。Poseidonハッシュ関数はSTARKフレンドリーに設計されています。しかし、Poseidonシステムはまだ比較的未熟であり、多くの人々がそのセキュリティを信頼していません。そのため、現実的な進む道は2つあります：

1. Poseidonの大量なセキュリティ分析を迅速に行い、L1での展開のために十分に理解する
2. より「保守的な」ハッシュ関数、例えばSHA 256またはBLAKEを使用します

保守的ハッシュ関数を証明する場合、StarkwareのSTARKサークルは、この記事の執筆時点で、消費者向けノートパソコンで秒間10-30kハッシュ値を証明することしかできません。ただし、STARKテクノロジーは急速に改善されています。今日でも、GKRベースの技術によってこの速度を100-200kの範囲に向上させることが示されています。

ブロック外の証明の使用例を検証する

ブロックの検証以外にも、より効率的なステートレス検証が必要な3つの重要なユースケースがあります：

• メモリプール：トランザクションがブロードキャストされると、P2Pネットワークのノードは、トランザクションが有効かどうかを再度ブロードキャストする前に検証する必要があります。現在、検証には署名の検証、残高の十分性の確認、およびプレフィックスの正確性の確認が含まれます。将来的には（例えば、EIP-7701のようなネイティブアカウントの抽象化が使用される場合）、一部のEVMコードが実行され、一部の状態アクセスが行われる可能性があります。ノードがステートレスである場合、トランザクションはステートオブジェクトのプルーフを付属する必要があります。
• 包含リスト：これは提案された機能であり、（おそらく小規模で複雑でない）プルーフオブステークバリデータが次のブロックに取引を含めることを強制するものであり、（おそらく大規模で複雑な）ブロックビルダーの意向に関係なく行われます。これにより、権力者がレイテンシー取引を利用してブロックチェーンを操作する能力が弱体化します。ただし、これにはバリデータが含まれる取引の正当性を検証する手段が必要です。
• ライトクライアント：ユーザーがウォレットを介してチェーンにアクセスすることを望む場合（Metamask、Rainbow、Rabbyなど）、彼らは軽量クライアント（Heliosなど）を実行する必要があります。 Heliosのコアモジュールは、ユーザーに検証済みの状態ルートを提供します。しかし、完全に信頼できる体験を得るために、ユーザーは彼らが行うすべてのRPC呼び出しに対して証明を提供する必要があります（例えば、ETHネットワーク呼び出しリクエストに対して、ユーザーは呼び出し中にアクセスしたすべての状態を証明する必要があります）。

すべてのこれらのユースケースには共通点があります。それは、多くの証明が必要ですが、各証明は非常に小さいということです。したがって、STARK証明は実際には意味をなさないのです。その代わりに、最も現実的な方法は、直接Merkleブランチを使用することです。Merkleブランチのもう1つの利点は、更新可能であることです。ブロックBをルートとする状態オブジェクトXの証明が与えられた場合、子ブロックB2とその証拠が受信された場合、証明を更新してブロックB2をルートとするようにすることができます。Verkle証明もネイティブで更新可能です。

既存の研究へのリンクは何ですか:

• Verkleの木
• John Kuszmaul の Verkle ツリーに関する原著論文 *スタルクウェア *ポセイドン2紙
• Ajtai (格子硬度に基づく代替高速ハッシュ関数)
• Verkle.info

まだ何ができますか？

残りの主な作業は

1. EIP-4762の影響に関するさらなる分析（ステートレス ガス コストの変化）

2.完了したり、テストされたりした移行プログラムのさらなる作業は、どの無国籍環境実装プランの複雑性においても主要な部分です。

3. Poseidon、Ajtai、およびその他の「STARK-friendly」ハッシュ関数のより詳細なセキュリティ分析

4. "保守"（または"伝統"）ハッシュをさらに開発するための超効率なSTARKプロトコルの機能、例えばBiniusまたはGKRに基づいた視点を持っています。

また、我々はすぐに以下の3つの選択肢から1つを選択することになります：(i) Verkle 木、(ii) STARK フレンドリーハッシュ関数、および(iii) 保守的ハッシュ関数。これらの特性は次の表に大まかにまとめられています：

これ些"标题数字"以外にも、重要な考慮すべき要素がいくつかあります：

• 今、Verkleツリーコードは非常に成熟しています。Verkle以外のコードを使用すると、デプロイが遅れ、ハードフォークが遅れる可能性があります。これは問題ありません、特にハッシュ関数の分析やバリデータの実装に追加の時間が必要な場合、またはイーサリアムに早期に組み込むために他の重要な機能がある場合。
• ハッシュ値を使用して状態ルートを更新すると、Verkleツリーよりも速くなります。これは、ハッシュ値に基づく方法はフルノードの同期時間を短縮できることを意味します。
• Verkleツリーには興味深い更新証明の特性があります- Verkleツリーの証明は更新可能です。この特性は、mempool、含まれるリスト、および他のユースケースに大変便利であり、実装効率の向上にも役立つ可能性があります：状態オブジェクトが更新された場合、最後のレベルの内容を読み取る必要がなく、最後から2番目のレベルの証明を更新できます。
• Verkle 木はSNARKプルーフを生成しにくくなります。証明のサイズを数千バイトに縮小し続けたい場合、Verkleプルーフはいくつかの困難を引き起こします。これはVerkleプルーフの検証が多くの256ビット操作を導入するためです。これにより、プルーフシステムは多くのコストを要求するか、256ビットのVerkleプルーフ部分を含むカスタムの内部構造を持たなければなりません。これはステートレスにとっては問題ではありませんが、より多くの困難を引き起こします。

もし私たちがVerkle証明の更新可能性を量子安全でかつ合理的かつ効率的な方法で得たい場合、もう1つの可能性はラティスベースのMerkle木に基づく方法です。

もし最悪の場合、システムの効率が十分でないことが証明された場合、我々は予期しないツールである多次元 ガスを利用してこの不足を補うことができます：(i) calldata；(ii)計算；(iii)状態アクセスおよび可能な他の異なるリソースの個別の ガス 制限。多次元 ガスは複雑さを増加させますが、その代わりに平均と最悪の状況の比率を厳密に制限します。多次元 ガスがあれば、理論上は証明する必要がある最大ブランチ数が12500から3000のように減少する可能性があります。これにより、例えば今日のBLAKE 3でも（何とか）対応できるようになります。

多次元ガスは、ブロックのリソース制限をより基礎的なハードウェアのリソース制限に近づけることを可能にします

もう一つの予期しないツールは、ステートルートの計算レイテンシーをブロック後のスロットになります。これにより、ステートルートを計算するために12秒もの時間があり、極端な場合でも、秒間60000ハッシュの証明時間で十分であるということを意味します。これにより、再びBLAKE 3は要件をかろうじて満たすことができると考えられます。

この方法の欠点は、ライトクライアントのレイテンシーに1つのスロットを追加することですが、より巧妙な技術を使用することで、このレイテンシーを証明生成のレイテンシーにだけ減らすこともできます。例えば、証明はノードが生成された直後にブロードキャストされることがありますが、次のブロックを待つ必要はありません。

それはロードマップの他の部分とどのように相互作用しますか？

解決する01928374656574839201大幅に単一ポイントの難易度を低減しました。もし技術が単一ポイントの最低バランスをドロップすることができれば、Orbit SSFまたはアプリケーションレイヤーの戦略のようなチームポイントなど、これはより実現可能になります。

もし EOF を同時に導入すると、多次元ガス分析がより容易になります。これは、多次元ガスの主要な実行の複雑さが、親呼び出しのすべてのガスを渡さない子呼び出しの処理から生じるためであり、EOF はこのような子呼び出しを不正にするだけで、この問題を取ることができる（そしてネイティブアカウントの抽象化は、一部のガスの現在の主要な使用状況に対するプロトコル内の代替案を提供します。

状態のない検証と歴史の期限切れとの間には重要な相互作用があります。現在、クライアントは約1TBの歴史データを保存する必要があります。これらのデータは状態データの数倍です。クライアントが状態を持たない場合でも、クライアントが歴史データを保存する責任を解放しない限り、ほとんどストレージを持たないクライアントの夢は実現できません。この問題に対する最初のステップはEIP-4444であり、これは歴史データをtorrentsまたはポータルネットワークに保存することを意味します。

EVM実行の有効性の証明

私たちは何の問題を解決する必要がありますか？

ETHブロックの検証の長期的な目標は明確です-ETHブロックを以下の方法で検証できるようにする必要があります：(i)ブロックのダウンロード、またはデータの可用性サンプリングの一部分のみのダウンロード；(ii)ブロックの有効性を証明する小さな証明。これは、リソースをほとんど使用しない操作であり、モバイルクライアントやブラウザウォレット、さらには別のチェーンでも実行できます（データの可用性パートはなし）。

これを達成するには、（i）コンセンサスレイヤー（つまり、株式の証明）と（ii）実行レイヤー（つまり、EVM）にSNARKまたはSTARKプルーフを適用する必要があります。前者はそれ自体が課題であり、コンセンサスレイヤーのさらなる改善の過程で解決する必要があります（例えば、シングルスロットファイナリティに対して）。後者はEVMの実行プルーフが必要です。

それは何ですか、どのように動作しますか？

形式的には、ETHイーサリアム規格では、EVMは状態遷移関数として定義されています：前の状態Sがあり、ブロックBがあり、後の状態S' = STF(S，B)を計算しています。ライトクライアントを使用する場合、彼らは完全な状態SやS'、さらにはEを持っていません；代わりに、前の状態ルートR、後の状態ルートR'、およびブロックハッシュ値Hを持っています。

• 共通入力: pre-state root R, post-state root R', block hash H *プライベート入力：ブロック本体B、ブロックQがアクセスする状態のオブジェクト、ブロックQ'の実行後の同じオブジェクト、ステートプルーフ（メルクルブランチなど）P
• 主张 1 ：Pは、QにRが表す状態の一部を含むことを証明する有効な証拠です。
• 主張 2: もし STF が Q 上で実行される場合、(i) 実行プロセスは Q の内部オブジェクトにのみアクセスする、(ii) データブロックは有効である、(iii) 結果は Q' である
• 主张 3 ：Q' と P の情報を利用して新しい状態ルートを再計算すると、R' が得られます

もしもこのような状況が存在する場合、完全に検証されたETHブロックチェーンのEVM実行を持つ軽量クライアントを所有することができます。これにより、クライアントのリソースはかなり低くなります。真の完全検証ETHクライアントを実現するには、コンセンサスの面でも同じような作業が必要です。

EVM計算に使用される有効性の証明の実装はすでに存在し、L2で広く使用されています。一方で、EVMの有効性の証明がL1で実現可能になるためには、まだ多くの作業が必要です。

既存の研究との関連はありますか？

• EFPSE ZK-EVM（より優れた選択肢が存在するため、現在は使用されていません）
• Zeth、その動作原理はEVMをRISC-0 ZK-VMにコンパイルすることです
• ZK-EVM形式検証プロジェクト

まだ何ができますか？

今日、電子会計システムの有効性の証明は、セキュリティと検証時間の2つの分野で不十分です。

安全で有効性の証明を確保するには、SNARKがEVMの計算を確実に検証し、欠陥がないことを保証する必要があります。セキュリティを向上させるための2つの主要な技術は、マルチバリデータとフォーマル検証です。マルチバリデータは、複数の独立した有効性の証明の実装を指します。これは、複数のクライアントがあるようなもので、これらの実装の十分に大きなサブセットがブロックを証明した場合、クライアントはそのブロックを受け入れます。フォーマル検証は、数学的定理を証明するために通常使用されるツール（例：Lean 4）を使用して、有効性の証明が基礎となるEVM仕様（例：EVM KセマンティクスまたはETH坊の実行層仕様でPythonで書かれたEELS）を正しく実行することを証明することを含みます。

十分に迅速な検証時間は、どのETHブロックでも4秒未満で検証されることを意味します。今日、私たちはこの目標からはまだ遠く離れていますが、2年前よりもはるかに近づいています。この目標を達成するには、3つの方向で進展する必要があります:

• パラレリズム - 現在、最も高速なEVM検証器は、平均して15秒で1つのEthereumブロックを証明できます。これは、数百のGPU間で並列化を行い、最後にその作業をまとめることで実現されています。理論的には、計算のEVM検証器をO(log(N))の時間で証明する方法は完全にわかっています。各ステップを1つのGPUで行い、それらをまとめるための「集約ツリー」を作成します。

これを実現するには課題があります。最悪の場合でも、非常に大きなトランザクションが全体のブロックを占有している場合でも、計算の分割は順次行うことはできず、EVMやRISC-Vなどの仮想マシンのオペコードに従って行わなければなりません。仮想マシンの「メモリ」を証明の異なる部分の間で一貫させることは、実装プロセスでの重要な課題です。ただし、このような再帰的な証明を実現できれば、他に何の改善もなくとも、少なくとも証明者のレイテンシー問題は解決されますことを知っています。

• 証明システムの最適化--Orion、Binius、GRKなどの新しい証明システムは、一般的な計算の検証時間を大幅に短縮する可能性があります。
• EVM ガスのコストの他の変更 - EVM の多くの要素は最適化でき、特に最悪の場合でもプルーフオブステークにとってより有利になるようになります。もし攻撃者がブロックプロデューサーを10分間ブロックすることができる場合、通常のETHブロックを4秒でプルーフできるだけでは不十分です。必要なEVMの変更は大まかに以下のカテゴリに分類されます。

• ガスのコストの変化-操作に長い時間がかかる場合は、計算速度が比較的速い場合でも、ガスのコストが非常に高くなければなりません。EIP-7667は、この最も深刻な問題に対処するために提案されたEIPであり、（従来の）ハッシュ関数のガスコストを大幅に増加させます。なぜなら、これらの関数のオペコードとプリコンパイルは比較的安価だからです。これらのガスコストの増加を補うために、EVMオペコードのガスコストを低く抑えた証明をドロップすることで、平均スループットを維持します。

• データ構造の置換- STARKにとってより友好的な方法で状態ツリーを置換するだけでなく、トランザクションリスト、レシートツリー、およびその他の高コストの証明を置換する必要があります。 Etan Kisslingがトランザクションとレシート構造をSSZのEIPに移動させたのは、この方向に向かっての一歩です。

また、前述の2つのツール（多次元ガスおよびレイテンシーステートルート）もこの分野で役立ちます。ただし、ステートレス検証とは異なり、これらのツールを使用することは、私たちが現在必要としている作業を完了するために必要な技術を既に持っていることを意味します。これらの技術を使用しても、完全なZK-EVM検証にはさらに多くの作業が必要ですが、必要な作業量は少なくなります。

前述のポイントの一つはプルーフ・オブ・ハードウェアです：GPU、FPGA、ASICを使用してより高速にプルーフを生成します。Fabric Cryptography、Cysic、Accsealはこの分野で進展している3社です。これはL2にとって非常に有益ですが、L1の決定要因にはなりにくいです。なぜなら、L1は高度に分散化されていることが強く求められており、プルーフ生成はETHリウムユーザーの合理的な範囲内で行われるべきであり、単一企業のハードウェアのボトルネックに制限されるべきではありません。L2はより積極的なバランスを取ることができます。

これらの領域では、まだ多くの作業が必要です。

• 並列化の証明では、システムの異なる部分が「共有メモリ」（例えば、ルックアップテーブル）を共有できることを要求します。このような技術は知っていますが、実装する必要があります。
• 私たちは、最悪の場合の検証時間を最小限に抑えるために、理想的なガスコスト変動のセットを特定するために、さらなる分析が必要です。
• 私たちは証明システムの面でさらに多くの仕事をする必要があります

可能なコストは：

• セキュリティとバリデータの時間：より積極的なハッシュ関数、より複雑なプルーフシステム、またはより積極的なセキュリティ仮定またはその他のデザインアプローチを選択すると、バリデータの時間を短縮する可能性があります。
• 分散化与証明器时间：コミュニティは、対象となる証明器ハードウェアの「仕様」について合意する必要があります。証明者は大規模な実体である必要がありますか？高級なノートパソコンが1つのETHブロックを4秒で証明できることを望んでいますか？それともその中間ですか？
• 後方互換性の破壊度: 他の不足点はより積極的な ガス コスト変化によって補うことができますが、これはある種のアプリケーションのコストを不均衡に増加させ、開発者にコードの書き直しと再デプロイを余儀なくさせ、経済的実現可能性を維持するためのものです。同様に、これらのツールにはそれぞれ固有の複雑さと欠点があります。

それはロードマップの他の部分とどのように対話しますか？

実現L1 EVM 有効性の証明に必要なコア技術は、大きく他の2つの領域と共有されています：

• L2の有効性の証明(つまり、「ZKロールアップ」)
• 無状態の "STARK 二進制ハッシュ証明 "メソッド

L1での有効性証明の実現に成功すると、簡単な単一のステークが可能になります。最も弱いコンピュータ（携帯電話やスマートウォッチも含む）でもステークが可能です。これにより、他の制約（例えば32ETHの最小制限）を解決するための価値がさらに向上します。

さらに、L1 の EVM 妥当性の証明により、L1 のガス制限値を大幅に引き上げることができます。

コンセンサス的有効性の証明

私たちは何の問題を解決する必要がありますか？

もしETHブロックをSNARKで完全に検証したい場合、EVMの実行は証明する必要がある唯一の部分ではありません。我々はまた、コンセンサスを証明する必要があります。つまり、預金、引き出し、署名、検証者の残高更新、ETHブロックのプルーフオブステークなど、システム内の他の要素も含まれます。

コンセンサス比 EVM 簡単だが、直面する課題は、私たちにはL2 EVM コンボリューションがないため、どのようにしても、ほとんどの作業を完了する必要がある。したがって、任意のETH坊コンセンサスの実装は、"ゼロから"行う必要がありますが、証明システム自体は共有作業の基盤として構築できます。

それは何ですか、そしてどのように動作しますか？

ビーコンチェーンは状態遷移関数として定義され、EVMのように機能します。状態遷移関数は主に3つの部分で構成されています:

• ECADD(BLS署名の検証用)
• ペアリング（BLS署名の検証に使用）
• SHA 256ハッシュ値（状態の読み取りと更新に使用される）

各ブロックでは、バリデーターごとに1-16 BLS 12-381 ECADDを証明する必要があります(署名は複数のコレクションに含まれる可能性があるため、複数存在する可能性があります)。 これはサブセット事前計算手法で補うことができるため、バリデータごとに1つのBLS 12-381 ECADDのみを証明する必要があると言えます。 現在、スロットごとに30,000のバリデーター署名があります。 今後、シングルスロットファイナリティの実現により、この状況は2つの方向に変化する可能性があります。 「ブルートフォース」の道を歩めば、タイムスロットあたりのバリデータ数は100万に増えるかもしれません。 同時に、Orbit SSFが採用された場合、バリデーターの数は32,768にとどまるか、8,192に減少します。

BLSアグリゲーションの動作方法：検証総署名には、各参加者が1つのECADDだけでなく、1つのECMULが必要です。ただし、30000個のECADDは依然として大きな証明量です。

ペアリングに関しては、現在、各スロットには最大128の証明がありますので、128のペアリングを検証する必要があります。ElP-7549およびそれに続く修正により、各スロットを16に減らすことができます。ペアリングの数は少ないですが、コストが非常に高いです：各ペアリングの実行（または証明）時間はECADDよりも数千倍長くなります。

BLS 12-381の演算を証明する主な課題は、BLS 12-381のフィールドサイズと同じ次数の曲線が便利に存在しないことであり、これによりどの証明システムにもかなりのオーバーヘッドが発生します。一方、ETH坊向けに提案されたVerkleツリーはBandersnatch曲線を使用して構築されており、BLS 12-381自体がVerkleブランチを証明するためのSNARKシステムで使用されるサブカーブです。比較的簡単な実装では、1秒あたり100G1の加算を証明できます。証明速度を十分に高速化するには、おそらくGKRなどの巧妙な技術が必要です。

SHA 256ハッシュ値にとって、最悪のケースはエポック変換ブロックであり、各検証者のショートバランスツリーと多くの検証者バランスが更新されます。各検証者のショートバランスツリーは1バイトしかないため、1MBのデータが再ハッシュされます。これは32768回のSHA 256呼び出しに相当します。もし1000人のバリデータの残高がある閾値よりも高いか低い場合、有効残高を更新する必要があり、これには1000のMerkleブランチが必要であり、したがって約10000回のハッシュが必要です。シャッフルメカニズムは各検証者に90ビット必要です（したがって11MBのデータが必要です）、しかし、これはいつでもエポック内で計算できます。1スロットが終了する場合、これらの数値は状況に応じて変化する可能性があります。シャッフルが不要になることもありますが、Orbitがこのニーズをある程度回復する可能性があります。

別の課題は、ブロックを検証するには、公開鍵を含むすべての検証器の状態を再取得する必要があることです。100万の検証器に対して、公開鍵だけを読み取るだけで4800万バイトが必要で、さらにMerkleブランチが必要です。これには、各エポックに数百万ものハッシュ値が必要です。PoSの有効性を証明する必要がある場合、リアルなアプローチは、ある種の増分検証可能な計算の形式です：証明システム内に個別のデータ構造を保持し、その構造を効率的に検索して更新を証明できるように最適化されます。

要するに、多くの課題がある。これらの課題に最も効果的に対処するには、ビーコンチェーンを深く再設計する必要があり、これは単一スロット終了に向けての転換と同時に行われる可能性が高い。 この再設計の特徴には、次のものが含まれる可能性があります。

• ハッシュ関数の変更：現在使用しているのは「完全な」SHA 256ハッシュ関数ですので、パディングのために各呼び出しに対して2回の基本圧縮関数呼び出しが必要です。SHA 256圧縮関数に変更すると、少なくとも2倍の利益を得ることができます。Poseidonを使用すると、ハッシュ値に関するすべての問題を完全に解決できる可能性があります（少なくとも）。毎秒170万ハッシュ値（54MB）であり、100万の検証レコードでも証明を数秒で「読み取る」ことができます。
• もしOrbitの場合、シャッフルされたバリデータレコードを直接保存します：指定されたスロットの委員会として一定数のバリデータ（例：8192または32768個）を選択した場合、それらを隣り合った状態に直接配置し、最小限のハッシュですべてのバリデータの公開鍵を証明に読み込むことができます。これにより、すべてのバランス更新を効率的に完了することもできます。
• 署名の集約：高性能な署名の集約スキームには必ずある種の再帰的な証明が関わります。ネットワーク内の異なるノードは署名のサブセットに対する中間証明を行います。これにより、証明作業がネットワーク内の複数のノードに分散され、"最終的な証明者"の作業量が大幅に削減されます。 *他の署名方式：Lamport+Merkle署名の場合、256+32個のハッシュ値が必要になります。32768人の署名者に乗じると、9437184個のハッシュ値が得られます。署名方式を最適化した場合、この結果をさらに小さな定数因子で改善できます。Poseidonを使用する場合、1つのスロット内で証明できます。しかし、実際には、再帰集約方式を使用する方が速くなります。

既存の研究との関連はありますか？

• 簡潔なETH坊コンセンサス証明（同期委員会のみ） *簡潔なSP1内のヘリオス
• 簡単 BLS 12-381 の事前コンパイル
• Halo 2 に基づく BLS コレクションの署名検証

まだ何をする必要があり、どうやって選択するか：

実際には、ETH坊コンセンサスの有効性の証明を得るには数年かかる必要があります。これは、シングルスロット最終性、Orbit、署名アルゴリズムの変更、およびセキュリティ分析の実現に必要な時間とほぼ同じですが、セキュリティ分析では Poseidon のような「積極的な」ハッシュ関数を使用するために十分な信頼が必要です。したがって、最も賢明なアプローチは、これらの他の問題を解決し、同時にSTARKの友好性を考慮に入れることです。

主要なトレードオフはおそらく操作の順序に関するものであり、より進歩的なアプローチとより積極的な「一度に多くの変更」のアプローチの間で行われます。 EVMの場合、進行的なアプローチは合理的です。それにより、後方互換性への干渉を最小限に抑えることができます。共通の層にとって、後方互換性への影響は比較的小さく、ビーコンチェーンの構築方法のさまざまな詳細を「包括的に」再考し、最適な方法でSNARKフレンドリーさを最適化する利点もあります。

それはロードマップの他の部分とどのように相互作用しますか？

ETH坊 PoSを長期的に再設計する際、STARKの友好性は特に単一スロットの最終性、Orbit、署名スキームの変更、および署名の集約の観点から最優先事項とならなければなりません。