ヴィタリックが語るイーサリアムの未来の可能性(4):The Verge

前の読書: "イーサリアムの可能な未来に関するヴィタリック(1):マージ", "イーサリアムの可能な未来に関するヴィタリック(2):サージ", "イーサリアムの可能な未来に関するヴィタリック(3):惨劇"

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

ブロックチェーンの最も強力な機能の一つは、誰もが自分のコンピュータでノードを実行し、ブロックチェーンの正確性を検証できることです。つまり、9596個のPoW、PoSなどのコンセンサスを持つノードが新しいルールに従ってブロックを生成することに同意し、その後、完全な検証ノードの人々がそのブロックを拒否する可能性があります。このような陰謀団に属さないコイン生成者は自動的に古いルールに従い続けるオンチェーンに集まり、そのチェーンを維持し続ける一方、完全な検証を行ったユーザーはそのチェーンに従うことになります。

これはブロックチェーンと中央集権システムの重要な違いです。ただ、この特性が機能するには、完全検証ノードを実行するには、十分な人数が必要です。これはステーカーにも当てはまります（ステーカーがチェーンを検証しない場合、彼らはプロトコルルールの実行に寄与していないため）、そして一般ユーザーにも当てはまります。今日、消費者向けノートパソコン（私がこの記事を書いたときに使用したノートパソコンを含む）でノードを実行することは可能ですが、それは非常に困難です。The Vergeはこれを改善し、完全検証チェーンの計算コストを低くし、すべての携帯電話ウォレット、ブラウザウォレット、さらにはスマートウォッチがデフォルトで検証を実行できるようにします。

The Verge 2023 ロードマップ

最初、「Verge」という言葉は、ETH坊の状態保存をVerkleツリーに移行することを指していました。Verkleツリーは、よりコンパクトなプルーフを可能にするツリー構造であり、ETH坊ブロックの無状態検証を実現できます。ノードはETH坊ブロックを検証できますが、ETH坊の状態（アカウント残高、契約コード、ストレージスペースなど）をディスクに保存する必要はありません。代わりに、数百KBのプルーフデータと数百ミリ秒の余分な時間をかけてプルーフを検証する必要があります。現在、「Verge」は、ETH坊チェーンの最大リソース効率の検証を目指すより大きなビジョンを代表しており、無状態検証技術だけでなく、SNARKを使用してすべてのETH坊実行を検証することも含まれています。

SNARK検証の長期的なフォローに加えて、別の新しい問題がVerkle Treeが最適な技術であるかどうかに関連しています。Verkle Treeは量子コンピュータの攻撃を受けやすく、現在のKECCAK Merkle Patricia TreeにVerkle Treeを組み込んだ場合、将来的に再度ツリーを置き換える必要があります。Merkle Treeの自己置換方法は、Merkleブランチをスキップして直接STARKを使うことです。歴史的には、費用と技術的複雑さのため、この方法は不可能だと考えられていました。しかし、最近では、Starkwareがckcle STARKsを使用して、1秒あたり170万個のPoseidonハッシュを証明することができ、GKBなどの技術の登場により、他の「伝統的な」ハッシュ値の証明時間も急速に短縮されています。したがって、過去1年間で「Verge」はよりオープンになり、いくつかの可能性があります。

The Verge:主な目的

· 無状態クライアント：完全に検証されたクライアントとマークノードに必要なストレージスペースは数GBを超えるべきではありません。

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

この章では

· 無状態クライアント：Verkle または STARKs

· EVM実行の有効性の証明

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

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

解決しようとしている問題は何ですか?

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

これにより、完全な検証イーサリアムノードを実行できるユーザーの数が減少しました：イーサリアムのすべての状態を保存できるほどの大容量のハードディスクが手に入るようになったにもかかわらず、人々が通常購入するコンピューターには数百ギガバイトのストレージしかないことが多いからです。状態のサイズは、ノードを初めて構築するプロセスに大きな摩擦をもたらしました：ノードは状態全体をダウンロードする必要があり、これには数時間または数日かかる場合があります。これにはさまざまな連鎖反応が生じます。たとえば、これにより、ノードの作成者がノードの設定をアップグレードする難しさが大幅に増加します。技術的には、オンラインのままアップグレードを完了することができます-新しいクライアントを起動し、同期を待ち、古いクライアントを閉じて秘密鍵を転送します-しかし、実際の操作では、これは非常に複雑な技術的な問題です。

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

状態のない検証は、ノードが全状態を把握せずにブロックを検証する技術を可能にするものです。その代わりに、各ブロックには、(i) そのブロックがアクセスする特定の位置の値、コード、残高、ストレージ；(ii) これらの値が正しいことを証明する暗号化証明が付属しています。

実際には、ステートレス検証を実現するには、イーサリアムのステートツリー構造を変更する必要があります。これは、現在のMerkle Patricia Treeが、どのような暗号化プルーフスキームの実装に対しても非常に不利であること、特に最悪の場合にはそうであることが原因です。まともな"オリジナル"のMerblk分岐も、STARKに"パッケージ化"される可能性もあります。主な困難は、MPTのいくつかの弱点に起因しています。

これは16個の子ノードを持つ六分木です。つまり、サイズNの木では、証明に平均して32 （16-1） log16（N）= 120 * log2（N）バイト、または2 ^ 32項目の木では約3840バイトが必要です。二分木の場合、32 （2-1） log2（N）= 32 * log2（N）バイト、または約1024バイトだけ必要です。
コードはMerkle化されていません。これは、アカウントコードの任意のアクセス権を証明するために、コード全体を提供する必要があることを意味します。最大24000バイトまでです。

最悪の状況を以下のように計算できます：

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

分岐コストはわずかにドロップします（8*480の代わりに5*480を使用する）。これは、分岐が多い場合、その上部が繰り返し表示されるためです。しかし、1つのスロット内でダウンロードするデータ量は完全に現実的ではありません。これをSTARKでラップしようとすると、2つの問題に直面することになります：（i）KECCAKはSTARKに対して相対的に非友好的であること、（ii）330MBのデータは、KECCAKラウンド関数を500万回呼び出すことを証明しなければならず、これは最も強力なコンシューマーレベルのハードウェア以外のすべてのハードウェアにとって証明ができない可能性があります。たとえSTARKがKECCAKの効率を向上させることができたとしてもです。

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

バークルツリー

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

したがって、1つのブランチのサイズは32-1og256（N）= 4 * log2（N）バイトになることが証明されました。したがって、理論上の最大証明サイズは、30000000/2400 * 32 *（32-14 + 8）/ 8 = 130000バイト（状態ブロックの分布が均一でないため、実際の計算結果はわずかに異なりますが、1次近似値としては問題ありません）。

また、上記のすべての例で、この"最悪の場合"は最悪の場合ではありません。より悪い場合は、攻撃者が意図的に2つのアドレスを"掘り出し"、それらを木構造で共通のプレフィックスを持つ長い枝にして、そのうちの1つのアドレスからデータを読み取ることができます。これにより、最悪の場合の枝の長さが2倍になる可能性があります。しかし、このような場合でも、Verkleツリーの最悪の証明の長さは2.6MBであり、現在の最悪の検証データとほぼ一致しています。

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

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

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

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

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

Poseidonを迅速に多くのセキュリティ分析を行い、L1で展開するために十分に理解する
より "保守的な "ハッシュ関数、例えばSHA256またはBLAKEを使用します

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

ブロックチェーンの検証エリア以外の証拠の使用例

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

・メモリプール：取引がブロードキャストされると、P2Pネットワーク内のノードは取引の有効性を再ブロードキャストする前に検証する必要があります。現在の検証には署名の検証と残高の確認、および接頭辞の正しさを含む。将来的には（例えば、ネイティブアカウントの抽象化、EIP-7701の使用など）、一部のEVMコードを実行する必要がある場合があります。このコードはいくつかの状態へのアクセスを行います。ノードが状態を持たない場合、取引には状態オブジェクトの証明を添付する必要があります。

· 包含リスト：これは提案された機能で、（おそらく小規模で複雑でない）プルーフオブステークバリデータが次のブロックに取引を含めることを強制することを許可します。それに対し（おそらく大規模で複雑な）ブロックビルダーの意向に関係なく。これにより、権力者がレイテンシー取引を使用してブロックチェーンを操作する能力が弱体化します。ただし、これにはバリデータが含まれるリストの取引の有効性を検証する方法を持っている必要があります。

· ライトクライアント：ユーザーがウォレットを介してチェーンにアクセスすることを望む場合（たとえばMetamask、Rainbow、Rabbyなど）、軽量クライアント（たとえばHelios）を実行する必要があります。Heliosのコアモジュールは、ユーザーに検証済みのステートルートを提供します。完全に信頼できる体験を得るためには、ユーザーは行うすべてのRPC呼び出しに対して証明を提供する必要があります（たとえば、ETHネットワークの呼び出し要求に対して、ユーザーはすべてのステートへのアクセスを証明する必要があります）。

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

既存の研究との関連性は何ですか？

· Verkleの木

· John Kuszmaul の Verkle ツリーに関する原著論文

· スタークウェア

· ポセイドン2ペーパー

· Ajtai (格子ハードネスに基づく代替高速ハッシュ関数)

· Verkle.info

まだ何ができますか？

残りの主な作業は

EIP-4762の影響に関するさらなる分析（状態なしガスコストの変化）
移行プログラムの追加作業とテストを完了し、これは無国籍環境での実装の複雑さの主要な部分です
Poseidon、Ajtai、および他の「STARK-friendly」ハッシュ関数についてのさらなるセキュリティ分析
"保守"（または"伝統"）ハッシュをさらに開発して、BiniusやGKRに基づいたSTARKプロトコルの効率的な機能を実装する。

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

これらの"タイトル番号"以外にも、考慮すべき重要な要素がいくつかあります：

· 今では、Verkleツリーコードはかなり成熟しています。Verkle以外のコードを使用すると、デプロイが遅れ、ハードフォークが遅れる可能性が非常に高いです。それでも問題ありません、特に私たちがハッシュ関数の分析や検証器の実装に追加の時間が必要な場合、または私たちがイーサリアムに早期に取り入れたい他の重要な機能がある場合などです。

・使用ハッシュ値で状態ルートを更新する方がVerkleツリーよりも速い。これはハッシュ値に基づく方法が全ノードの同期時間をドロップできることを意味します。

· Verkle Treeは興味深い更新証明プロパティを持っています-Verkle Tree証明は更新可能です。このプロパティはmempool、含まれるリスト、および他のユースケースに役立ちますが、実装効率の向上にも役立つ可能性があります：状態オブジェクトを更新すると、最後のレイヤーを読み取る必要がなく、最後から2番目のレイヤーの証明を更新できます。

· Verkle 木はSNARKプルーフを行うのがより難しいです。証明のサイズを数千バイトに縮小し続けたい場合、Verkleプルーフはいくつかの困難をもたらすでしょう。これはVerkleプルーフの検証が大量の256ビット操作を導入するためです。これにより、プルーフシステムには多額のコストがかかるか、または256ビットのVerkleプルーフ部分を含むカスタムの内部構造が必要です。これは状態レスにとっては問題ではありませんが、さらなる困難をもたらします。

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

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

多次元ガスは、ブロックのリソース制限がより低レベルのハードウェアのリソース制限に近づくことを可能にします

もう1つの予期しないツールは、ブロックの後のスロットに状態ルート計算を遅延させることです。これにより、状態ルートを計算するために12秒の時間が得られます。つまり、最も極端な場合でも、1秒あたり60000ハッシュの証明時間は十分であると考えられます。これは再び、BLAKE3が要件をうまく満たすことができないという考えにつながります。

この方法の欠点は、ライトクライアントのレイテンシーに1つのスロットを追加することですが、このようなレイテンシーを証明生成のレイテンシーに減らすためのより巧妙な技術もあります。たとえば、証明は次のブロックを待つのではなく、任意のノードで生成された直後にネットワーク上にブロードキャストされることができます。

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

無状態問題の解決は、単一のターゲットの難易度を大幅に向上させました。もし技術的に単一のターゲットの最低バランスをドロップする手段があれば、Orbit SSFやアプリケーションレイヤーの戦略など、チームのターゲットを定める手段がより実現可能になるでしょう。

もし EOF を同時に導入すると、マルチディメンショナルなガス分析はより容易になります。これは、マルチディメンショナルなガスの主な実行の複雑さが、親呼び出しのすべてのガスを受け渡さない子呼び出しの処理に起因するためであり、EOF はこのような子呼び出しを非合法にするだけで、この問題を取ることができます（そして、本機アカウントの抽象化は、部分的なガスの主要な使用状況に対するプロトコル内の代替手段を提供します。

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

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を持っています。

· 公開入力：前の状態ルート R、後の状態ルート R'、ブロックハッシュ H

· プライベート入力：プログラムブロック本体B、プログラムブロックQがアクセスする状態のオブジェクト、実行されたプログラムブロックQ'の後の同じオブジェクト、状態の証明（メルクルブランチなど）P

· 主張1: Pは、QがRに代表される状態の一部を含んでいることを証明する有効な証拠です

· 主張2：STFをQ上で実行する場合、(i) 実行プロセスはQ内部のオブジェクトにのみアクセスします。(ii) データブロックは有効です。(iii) 結果はQ'です。

· 主张 3：もし Q' と P の情報を利用して新しい状態ルートを再計算すると、R' が得られることになります

もしそのような状況があれば、完全に検証されたエーテルブロックチェーンのEVM実行を持つことができます。これにより、クライアントのリソースがかなり低くなります。真の完全に検証されたエーテルブロックチェーンクライアントを実現するには、コンセンサスの面でも同様の作業が必要です。

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

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

· EFPSE ZK-EVM（より良い選択肢があるため、現在は使用されていません）

・Zethは、EVMをRISC-0 ZK-VMにコンパイルする仕組みです

· ZK-EVM 形式の認証プロジェクト

まだ何ができますか？

現在、電子帳簿システムの有効性の証明には、2つの問題があります。安全性と検証時間です。

安全な有効性の証明を確保するには、SNARKがEVMの計算を正しく検証し、バグがないことを確認する必要があります。セキュリティを向上させるための2つの主要な技術は、複数の検証者と形式検証です。複数の検証者は、独立した複数の有効性の証明実装を指し、複数のクライアントのように、これらの実装のいずれかがブロックを証明すれば、クライアントはそのブロックを受け入れます。形式検証には、通常数学定理を証明するために使用されるツール（例: Lean4）を使用して、有効性の証明がEVMの基礎仕様（例: EVM KセマンティクスまたはPythonで書かれたETHブロック実行仕様（EELS））を正しく実行することを証明することが含まれます。

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

· パラレル化-現在、最も速いEVM検証器は、平均して15秒以内で1つのイーサリアムブロックを証明することができます。これは、数百の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秒で証明できることを望んでいますか？それはその中間のどこに位置しますか？

・向後の互換性を壊す程度：他の面の不足はより積極的なガスコストの変化で補うことができますが、これは特定のアプリケーションのコストを不釣り合いに増やす可能性が高く、開発者にコードを書き直したり再デプロイしたりして経済的に実行可能な状態を維持することを強いるかもしれません。同様に、これら2つのツールにはそれぞれ独自の複雑さと欠点があります。

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

L1 EVM の有効性の証明を実現するために必要な中核技術は、他の2つの領域と大いに共有されています:

· L2 の有効性の証明 (例: 「ZK ロールアップ」)

・ステートレスな「STARK 二進ハッシュ証明」方法

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

さらに、L1のEVM有効性の証明は、L1のガス制限を大幅に向上させることができます。

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

解決しようとしている問題は何ですか?

もしも私たちがSNARKを使用してETHブロックを完全に検証したい場合、EVMの実行だけが証明する必要があるものではありません。私たちはまた、コンセンサスを証明する必要があります。すなわち、預金、引き出し、署名、バリデータの残高更新、ETHプルーフオブステークの他の要素など、システム内の要素です。

コンセンサス比EVMははるかに簡単ですが、その課題は、私たちにはL2 EVMの畳み込みがないため、いかなる場合でもほとんどの作業を完了する必要があることです。したがって、ETH坊コンセンサスを証明するためには、「ゼロから始める」必要がありますが、証明システム自体はその上に構築できる共有作業です。

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

ビーコンチェーンは、EVMと同様に状態遷移関数として定義されています。状態遷移関数は、主に3つの部分から構成されています：

· ECADD (BLS 署名の検証用)

· ペアリング（BLS署名の検証に使用）

· SHA256ハッシュ値（状態の読み取りと更新に使用）

各ブロックでは、各検証者に対して1〜16個のBLS12-381 ECADD（複数の集合に署名が含まれるため、1つ以上になる可能性があります）を証明する必要があります。これは部分集合事前計算技術によって補われるため、各バリデータは実質的に1つのBLS12-381 ECADDを証明する必要があると言えます。現時点では、各スロットには30000個の検証者署名があります。将来、単一スロットの確定性の実装に伴い、この状況は2つの方向に変化する可能性があります。"ブルートフォース"アプローチを取る場合、各スロットのバリデータ数は100万に増加する可能性があります。一方、Orbit SSFを採用する場合、検証者数は32768個に維持されるか、8192個に減少する可能性があります。

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

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

BLS12-381演算の主要な課題は、BLS12-381フィールドサイズと同じ曲線次数を持たない便利な曲線がないことです。これにより、任意の証明システムにかなりのコストがかかります。一方、ETHリウム向けのVerkleツリーはBandersnatch曲線で構築されており、BLS12-381自体がVerkleブランチを証明するためにSNARKシステムで使用される自己曲線となっています。比較的簡単な実装では、1秒あたり100 G1の加算を証明できます。証明速度を十分速くするには、おそらくGKRのような巧妙な技術が必要となります。

SHA256ハッシュ値の場合、最も悪い状況はエポック変換ブロックで、全バリデータのショートバランスツリーと多くのバリデータバランスが更新されます。各バリデータのショートバランスツリーは1バイトしかありませんので、1MBのデータが再度ハッシュされます。これは32768回のSHA256呼び出しに相当します。もし1000個のバリデータの残高がある閾値を上回るか下回る場合、バリデータレコードの有効残高を更新する必要があり、これには1000のMerkle分岐が必要ですので、ハッシュ値は10,000回必要となります。シャッフルメカニズムには各バリデータに90ビット必要です（したがって、11MBのデータが必要です）、ただし、これはエポックの任意のタイミングで計算できます。シングルスロット終了の場合、これらの数字は具体的な状況に応じて増減する可能性があります。シャッフルは不要になりましたが、Orbitがこの必要性を一部回復する可能性もあります。

もう一つの課題は、ブロックを検証するために公開鍵を含め、すべての検証者の状態を再取得する必要があることです。100万の検証者について、公開鍵だけを読み取るだけでも4800万バイトが必要であり、さらにMerkleの分岐が必要です。それにより、各エポックで数百万のハッシュ値が必要になります。PoSの有効性を証明する必要がある場合、現実的な方法の1つは、ある種の増分可検証計算の形式です。証明システム内に別個のデータ構造を保存し、最適化されたこの構造に対して高速な検索と更新の証明を提供できます。

要するに、多くの課題があります。これらの課題に効果的に対処するためには、ビーコンチェーンの深い再設計が必要であり、それはシングルスロットの終了に向けて行われる可能性が高いです。この再設計の特徴は、次のようなものが含まれるかもしれません:

· ハッシュ関数の変更: 「完全な」SHA256 ハッシュ関数が使用されるようになったため、各呼び出しはパディングによる 2 つの低レベルの圧縮関数呼び出しに対応します。代わりにSHA256圧縮関数を使用すると、少なくとも2倍のメリットを得ることができます。ポセイドンに切り替えれば、100倍の利益が得られ、(少なくともハッシュ値に関しては)すべての問題が解決されるかもしれません:毎秒170万ハッシュ(54MB)で、100万件の検証記録でさえ、ほんの数秒で証明に「読み込む」ことができます。

・Orbitの場合は、バリデータレコードをシャッフルして直接保存します。一定数のバリデータ（例えば8192または32768）を特定のスロットの委員会として選択した場合、これらを互いに隣接するステートに直接配置して、すべてのバリデータの公開鍵を証明に読み込むのに最小限のハッシュしか必要ありません。これにより、すべてのバランス更新を効率的に完了することができます。

・署名の集約：高性能な署名の集約ソリューションでは、ネットワーク内の異なるノードが署名のサブセットに対して中間証明を行います。これにより、証明の作業がネットワーク内の複数のノードに分散され、"最終的な証明者"の作業量が大幅に減少します。

・他の署名方式：Lamport+Merkle署名の場合、256+32のハッシュ値が必要です。32768人の署名者がいる場合、9437184個のハッシュ値が必要です。署名方式を最適化して、さらに小さな定数因子で改善することができます。Poseidonを使用すると、1つのスロット内で証明できます。しかし、実際には、再帰的集約手法を使用する方が速いです。

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

・簡潔なETHエーテルコンセンサス証明（同期委員会のみ）

· 簡潔なSP1の中のHelios

・簡潔なBLS12-381のプリコンパイル

· Halo2 に基づく BLS コレクションの署名検証

まだやるべき仕事は何があり、どう選ぶべきか:

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

主要なバランスは、操作の順序において、より漸進的な方法とより積極的な「一度に多くの変更を行う」方法の間で行われる可能性が高いです。 EVMにとっては、漸進的な方法が合理的です。なぜなら、これにより後方互換性に対する干渉が最小限に抑えられるからです。共識レイヤにとっては、後方互換性への影響は比較的少なく、ビーコンチェーンの構築方法についてより「包括的な」再考を行い、SNARKフレンドリー性を最適化するためにさまざまな詳細を検討することも有益です。

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

ETH坊 PoSを長期的に再設計する際には、STARKの友好性が最優先の考慮要素となる必要があります。特に、シングルスロットの最終性、軌道、署名方式の変更、および署名の集約に注意が必要です。

原文のリンク