イーサリアム ロールアップの将来は、実際には 2 つの主要なアプローチ (ZK とオプティミスティック) のハイブリッドです。
作者: ケルビンフィヒター
コンパイル: MK
私は最近、イーサリアム ロールアップの将来は実際には 2 つの主要なアプローチ (ZK とオプティミスティック) のハイブリッドであると確信しています。この投稿では、私が思い描いているものの基本的なアーキテクチャを説明し、これが今後の最善の道であると考える理由を説明したいと思います。
ZK またはオプティミスティック ロールアップの性質について議論することにあまり多くの時間を費やすつもりはありません。この投稿は、読者がこれらの仕組みをすでに十分に理解していることを前提としています。専門家である必要はありませんが、少なくともそれらが何であるか、およびそれらが高レベルでどのように機能するかを知っておく必要があります。ロールアップについて説明しようとすると、この投稿は非常に長くなるでしょう。全体として、読んで楽しんでください。
楽観的なロールアップから始める
ハイブリッド ZK/オプティミスティック ロールアップは、オプティミズムの Bedrock アーキテクチャに非常によく似たオプティミスティック ロールアップとして開始されました。 Bedrock はイーサリアムとの最大限の互換性 (「EVM 同等」) を目指しており、通常のイーサリアム クライアントとほぼ同一の実行クライアントを実行することでこれを実現します。 Bedrock は、イーサリアムの今後のコンセンサス/実行クライアント分離モデルを使用し、EVM への差異を大幅に削減します (いくつかの変更は常に必要になりますが、これは管理できます)。これを書いている時点では、Bedrock Geth の差分は +388 -30 コミットです。
他の優れたロールアップと同様に、オプティミズムはイーサリアムからブロック/トランザクション データを取得し、コンセンサス クライアント内でこのデータを何らかの決定論的な方法で並べ替えて、このデータを実行のために L2 実行クライアントにフィードします。このアーキテクチャは、「理想的なロールアップ」パズルの前半を解決し、EVM 相当の L2 を提供します。
もちろん、イーサリアムオプティミズムの内部で何が起こっているのかを証明可能な方法で伝える方法の問題も解決する必要があります。この機能がなければ、契約は楽観主義の状態に基づいて意思決定を行うことができません。これは、ユーザーが Optimism に入金することはできますが、資産を引き出すことはできないことを意味します。場合によっては単方向ロールアップが実際に役立つ場合もありますが、一般的には双方向ロールアップの方が便利です。
ロールアップの状態に対するコミットメントを与え、そのコミットメントが正しく生成されたことを証明することで、イーサリアムにロールアップの状態を伝えることができます。これを言い換えると、「ロールアップ プログラム」が正しく実行されたことを証明しているということになります。 ZK とオプティミスティック ロールアップの唯一の本当の違いは、この証明の形式です。 ZK ロールアップでは、プログラムが正しく実行されていることを明示的に ZK 証明する必要があります。 Optimistic Rollup では、約束について主張しますが、明確な証明はありません。他のユーザーがあなたの主張に異議を唱え、最終的に誰が正しいかを判断する反復ゲームを強制することができます。
Optimistic Rollup チャレンジ ゲームについては、あまり詳しく説明しません。このゲームの最新技術は、プログラム (Geth EVM + Optimism の場合は一部の周辺部分) を MIPS のような単純なマシン アーキテクチャにコンパイルすることであることは注目に値します。これを行うのは、オンチェーンでプログラムのインタープリターを構築する必要があり、EVM インタープリターよりも MIPS インタープリターを構築する方がはるかに簡単であるためです。 EVM も移動ターゲットであり (定期的なアップグレード フォークがあります)、証明したいプログラムを完全にはカバーしていません (EVM 以外のものも含まれています)。
シンプルなマシン アーキテクチャ用のオンチェーン インタープリターを構築し、いくつかのオフチェーン ツールを作成したら、完全に機能するオプティミスティック ロールアップが完成します。
ZKロールアップに変換
全体として、少なくとも今後数年間は楽観的なロールアップが主流になると思います。 ZK ロールアップが最終的にはオプティミスティック ロールアップを超えるだろうと考える人もいますが、私はこれは間違っているのではないかと考えています。現在のオプティミスティック ロールアップは比較的シンプルで柔軟性があるため、時間の経過とともに ZK ロールアップに変換できると思います。それを実現するモデルを見つけることができたとしても、既存の Optimistic システムに単純に展開して、それを 1 日で作業できる ZK システムと呼ぶことができるのであれば、柔軟性に欠け、より脆弱なモデルを展開する強い動機は実際にはありません。
したがって、私の目標は、既存の最新の Optimistic システム (Bedrock など) を ZK システムにシームレスに変換できるように、アーキテクチャと移行パスを作成することです。これは単に可能であるだけでなく、現在の zkEVM アプローチを超えた方法で実現できると私は考えています。
上で説明した Bedrock スタイルのアーキテクチャから始めます。 Bedrock に L2 プログラムをアサートするチャレンジ ゲーム (EVM とそれを ZK ロールアップに変えるための追加機能の実行) がある方法を (簡単に) 説明したことに注意してください。
全体として、今後数年間は楽観的なロールアップが主流になると思います。 ZKロールアップは最終的にはオプティミスティックロールアップを超えるという意見がありますが、これは間違っているのではないかと思います。オプティミスティック ロールアップは比較的シンプルで柔軟性があるため、時間の経過とともに ZK ロールアップに変換できると思います。この移行が起こるモデルを理解できれば、柔軟性が低く、問題が発生しやすい ZK システムを導入する強い動機は実際にはありません。
したがって、私の目標は、既存の最新の Optimistic システム (Bedrock など) を ZK システムにシームレスに変換できるアーキテクチャと移行パスを作成することです。これは、この移行を実現するだけでなく、今日の zkEVM アプローチを超えた方法で移行を実現する方法であると私は信じています。
先ほど説明した Bedrock スタイルのアーキテクチャから始めます。 Bedrock に、L2 プログラム (EVM といくつかの追加機能を実行する MIPS プログラム) の実行の正当性を主張できるチャレンジ ゲームがある方法を (簡単に) 説明したことに注意してください。このアプローチの主な欠点の 1 つは、ユーザーが誤ったプログラム結果の提案を検出して異議を申し立てるまでに一定の期間を置く必要があることです。これにより、資産引き出しプロセスにかなりの時間が追加されます (Optimism メインネットでは現在 7 日)。
ただし、私たちの L2 は単純なマシン (MIPS) 上で実行される単なるプログラムです。このような単純なマシンに対して ZK 回路を構築することは完全に可能です。この回路を使用して、L2 プログラムが正しく実行されたことを明確に証明できます。現在の Bedrock コードベースに変更を加えることなく、Optimism の有効性証明の発行を開始できます。実にシンプルなことです。
なぜこの方法が優れているのか
簡単なメモ: このセクションでは「zkMIPS」と呼んでいますが、実際には一般的な「単純な」zkVM を指すために使用しています。
なぜこの方法が優れているのか
簡単なメモ: このセクションでは「zkMIPS」と呼んでいますが、実際には一般的な「単純な」zkVM を指すために使用しています。
zkMIPS は zkEVM よりも単純です
zkEVM の代わりに zkMIPS (または zk[他のマシン名を挿入]) を構築する大きな利点は、ターゲット マシンのアーキテクチャがシンプルで静的であることです。 EVM は頻繁に変更されます。ガス価格が変更され、オペコードが調整され、追加または削除されます。そして MIPS-V は 1996 年以来変わっていません。 zkMIPS をターゲットにすることで、固定された問題空間に取り組むことになります。 EVM が更新されるたびに回路を変更したり、場合によっては再監査したりする必要はありません。
zkMIPS は zkEVM よりも柔軟です
もう 1 つの重要な論点は、zkMIPS が zkEVM よりも柔軟であるということです。 zkMIPS を使用すると、クライアント コードをより柔軟に変更して、さまざまな最適化やユーザー エクスペリエンスの向上を実現できます。クライアントのアップデートに回線のアップデートを同梱する必要はなくなりました。 Ethereum だけでなく、あらゆるブロックチェーンを ZK ロールアップに変換するために使用できるコア コンポーネントを作成することもできます。
あなたの質問は証明時間に変わります
ZK 証明時間は、制約の数と回路サイズの 2 つの軸に沿ってスケールされます。 (EVM のような複雑なマシンではなく) MIPS のような単純なマシンの回路に焦点を当てることで、回路のサイズと複雑さを大幅に削減することができました。ただし、制約の数は実行される機械命令の数によって異なります。各 EVM オペコードは複数の MIPS オペコードに分割されます。これは、全体的な証明時間と同様に、制約の数が大幅に増加することを意味します。
しかし、校正時間を短縮することは、Web2 分野に深く根ざした問題です。 MIPS マシン アーキテクチャが近い将来変更されないことを考えると、後の段階での EVM の変更を心配することなく、回路と証明プログラムを高度に最適化できます。明確に定義されたプログラムを最適化できるハードウェア エンジニアの採用人数は、刻々と変化する zkEVM ターゲットを構築および監査するための採用人数より少なくとも 10 倍 (100 倍ではないにしても) 大きいと私は確信しています。 Netflix のような企業には、おそらく多くのハードウェア エンジニアがトランスコーディング チップの最適化に取り組んでおり、興味深い ZK の課題に取り組むための多額の VC 資金を喜んで受け入れるでしょう。
このような回線の初期保証期間は、7 日間のオプティミスティック ロールアップ引き出し期間を超える場合があります。この校正時間は時間の経過とともに減少するだけです。 ASIC と FPGA を導入することで、証明時間を大幅に短縮できます。静的な目的を使用すると、より最適な証明者を構築できます。
最終的には、このサーキットのプルーフタイムは現在の 7 日間のオプティミスティック ロールアップの出金期間よりも短くなり、オプティミスティックのキャンセルを検討するためのチャレンジ プロセスを開始できるようになります。 7 日間プルーフを実行するのは依然としてコストが高すぎる可能性があるため、もう少し待ったほうがよいかもしれませんが、それでもポイントは変わりません。両方の証明システムを同時に実行することもできるため、すぐに ZK 証明の使用を開始でき、何らかの理由で証明プログラムが失敗した場合は、オプティミスティック証明にフォールバックできます。準備ができたら、アプリケーションに対して完全に透過的な方法で ZK プルーフに簡単に移行できます。これほどの柔軟性とスムーズな移行パスを提供するシステムは他にありません。
他の重要な問題に集中できます
ブロックチェーンの実行は困難な作業であり、大量のバックエンド コードを記述するだけではありません。 Optimism で行っていることの多くは、便利なクライアント側ツールを通じてユーザーと開発者のエクスペリエンスを向上させることに重点を置いています。また、プロジェクトとの対話、問題点の理解、インセンティブの設計といった「ソフト」面の対応にも多くの時間とエネルギーを費やしました。ブロックチェーン ソフトウェアに費やす時間が増えれば増えるほど、他のことについて考える時間が減ります。いつでもより多くの人を雇用しようとすることはできますが、組織は直線的に拡大するものではなく、新規雇用するたびに社内コミュニケーションの負担が増大します。
ZK 回路の作業は既存の実行チェーンに追加できるため、コア プラットフォームの構築とソフトウェアの証明に並行して取り組むことができます。また、回路を変更せずにクライアントを変更できるため、クライアントと認証チームを分離できます。このアプローチを採用したオプティミスティックロールアップは、実際のオンチェーンアクティビティの点でZK競合他社よりも数年先を行く可能性があります。
いくつかの結論
いくつかの結論
率直に言って、zkMIPS 証明器が時間の経過とともに大幅に最適化できると仮定すると、このアプローチに重大な欠点は見当たりません。アプリケーションに対する唯一の実際の影響は、さまざまなオペコードのガスコストを、それらのオペコードによって追加される証明時間を反映するように調整する必要がある可能性があることです。この証明者を適切なレベルに最適化することが本当に不可能である場合、私は敗北を認めます。この証明器を最適化することが実際に可能であれば、zkMIPS/zkVM アプローチは現在の zkEVM アプローチよりもはるかに優れていると思われるため、後者は完全に時代遅れになる可能性があります。これは過激な発言のように思えるかもしれませんが、少し前までは、単一ステップの楽観的な失敗証明は完全に複数ステップの証明に置き換えられました。
このアプローチについて私が明らかに間違っていると思われる場合は、お気軽に私に連絡してその理由を教えてください。
全てのコメント