楽観的なロールアップ: イーサリアム スケーリングの現在と将来

原作者: オフチェーンラボ

最近、ZK Rollup が汎用スマート コントラクト システムの将来であると考えられているという話をよく聞きます。私たちは同意しません。この記事ではその理由を説明します。これは、数百の dapps、数十万のユーザー、数百万のトランザクションを含む、オープンで安全な EVM 互換の L2 チェーンの実行から学んだ実践的な教訓に基づいています。

私たちが Arbitrum をオプティミスティック ロールアップ (OR) として構築したのは、OR が安全で無条件に信頼できる EVM 互換の L2 に対するユーザーの現実のニーズを満たす最良の方法であると信じているからです。システム固有のスケーラビリティとコスト上の利点のため、ZK ではなく Optimistic Rollup を選択しましたが、現在でも同じ選択をするでしょう。その理由を知りたい場合は、読み続けてください。

マイケル・ジョンソン - 元々はリンゴとオレンジとして Flickr に投稿されました - それらは比較しません、CC BY 2.0、https://commons.wikimedia.org/w/index.php?curid=4289506)

等！この投稿はどれくらいの長さですか?

はい、この投稿は長く、ところどころ多少専門的です。人々がオンチェーンに求めるものは単純ですが、これらの利点を提供するために必要なテクノロジーについて話すには、いくつかの詳細を掘り下げる必要があります。技術コミュニティが私たちの視点を理解してくれることを願っています。

記事全体を読みたくない場合は、ここに簡単な概要を示します。

1. 人々は、セキュリティ、保証された進捗状況、可視性、高速なプロパティを提供する無条件に信頼できるチェーンを望んでおり、低コストと既存のツールとの互換性を望んでいます。

2. ZK ロールアップと比較して、オプティミスティック ロールアップを使用してこれらのプロパティを提供する方法を詳しく調べました。

3. ZK のオフチェーンコストは非常に高いため、Optimistic はユーザーが望む属性を低コストで提供できます。

4. ZK 証明は非常に高価であるため、ZK プロトコルに完全に参加するには、専用のハードウェアや大規模な並列処理が必要となり、ネットワークが効果的に集中化されます。

5. ZK が主張する利点は、Optimistic Rollup システムに適用されるか、重要なセキュリティ機能や使いやすさ機能を犠牲にする必要があるかのいずれかです。

6. 複雑な暗号証明を計算するよりもコードの実行の方がはるかに安いため、運用コストの点ではオプティミスティック ロールアップが勝ちます。

ゼロから始めます

まずはイーサリアムから始めましょう。 Ethereum ユーザーは、スマート コントラクトをデプロイまたは操作するためのトランザクションを作成します。イーサリアムのトランザクションはいくつかの異なる方法で見ることができます。一方で、それは不透明なデータであると考えることもできます。しかし、その内容を見ると、トランザクションはもちろんそれをはるかに超えたものであり、情報を記録したり、資産を移動したりするなど、スマート コントラクトに対して何かを行うためのリクエストです。

トランザクションがイーサリアムに投稿されると、2 つの重要なことが起こります。まず、イーサリアムが一連の注文されたトランザクションに関して合意を達成することが含まれています。次に、イーサリアムはこれらのトランザクションを実行し、その結果の状態更新を計算します。

ロールアップ: Optimistic と ZK の共通点

すべての Ethereum ノードにすべてのトランザクションを実行させるにはコストがかかります。ロールアップは、この負荷を大幅に軽減できるスケーリング ソリューションの一種です。トランザクションの実際の実行はイーサリアム上では行われず、レイヤー 2 (「L2」) エリアに移動されます。

しかし、待ってください - ロールアップはイーサリアムによって保証されるはずです。これは、たとえトランザクションが L2 で発生したとしても、トランザクション実行の正確性を何らかの方法で保証するためにイーサリアムが必要であることを意味します。では、イーサリアムはどのようにしてロールアップステータスへの承認を獲得したのでしょうか?

端的に言えば、答えは「証拠」です。 Rollup は独自の証明を使用してイーサリアムに対してその正当性を証明し、トランザクションを実行しなくても検証できます。

ロールアップ: オプティミスティックと ZK の違い

これらの証明は、実際に実行せずにイーサリアムがロールアップ状態を検証できるようにするという、非常に魔法のように思えます。これらの証明がどのようなものなのか、実際にどのように実装されるのか疑問に思われるかもしれません。ここがさまざまなロールアップと異なる点です。

ZK ロールアップは有効性の証明を使用します。 ZK は、当事者が特定の状態で終了する有効なチェーンを知っているという簡潔な暗号証明を発行する当事者に依存します。これには、検証者がチェーンを実行して検証を構築する方法を認識し、一連の複雑な暗号化操作を実行して検証を構築する必要があります。証明はオンチェーンの L1 コントラクトによってチェックされます。 ZK 証明は簡潔であり、検証コストはイーサリアム トランザクションで実行できるほど十分に安価です。

オプティミスティック ロールアップでは、不正行為の証明という別の種類の証明が使用されます。名前が示すように、Optimistic Rollups は楽観的であり、更新された状態をイーサリアムに公開するときに、プルーフを公開する必要がまったくありません。特定のトランザクションの実行の正しい結果に関する主張を含むロールアップ ブロックは誰でも公開できます。他のノードも同じトランザクションを実行し、最初のノードの要求に同意しない場合はチャレンジを発行できます。効果的な紛争プロトコルは、あらゆる意見の相違を解決し、正しい当事者が異議申し立てに勝つことを保証します。すべての当事者には、正しい要求のみを発行し、誤った要求には異議を唱えないという強いインセンティブがあるため、通常の場合、すべてのノードはすべてのトランザクションを実行するだけで、証明コードを呼び出す必要はありません。プロセス全体は L1 コントラクトによって管理されます。

では、どのタイプのロールアップが優れているのでしょうか?以下では、ZK とオプティミスティック ロールアップをいくつかの側面で比較し、Arbitrum のようなオプティミスティック ロールアップが本質的によりスケーラブルであるのに対し、将来はオプティミスティックであると考える理由を説明します。

楽観的ロールアップと ZK: コスト

おそらく、Optimistic Rollup と ZK の最も重要な違いはコストです。

オプティミスティック ロールアップでは、ノードはコントラクトを単に実行するだけで済みます。たとえば、コントラクトが追加操作を実行する場合、ノードはその追加操作を実行します。

一方、ZK は、証明に加算演算を含めるために数百または数千の高価な楕円曲線演算を必要とする複雑な暗号証明を生成する必要があります。 ZK は、すべての契約のすべての指示に対してこの料金を負担します。実行だけでなく、すべての命令に対して複雑な暗号証明を生成する必要があることは、ZK にとって本質的なコスト上のデメリットであり、それが大きなデメリットとなります。

ZK の支持者は、証明を作成するのに必要なのは 1 つの当事者のみであるのに対し、オプティミスティック ロールアップではシステムに多数のノードが必要であると主張することがあります。ただし、大規模なチェーンを実行している場合は、使用する検証システムに関係なく、多くのノードが存在します。実際のチェーンでは、非変化呼び出しイベント ログの提供、ユーザーへのトランザクション データの表示、L1 への資金引き出しに必要なデータのユーザーへの提供などを行うために、多くのノードが必要になります。オプティミスティック ロールアップ チェーンのセキュリティは、これらのノードがすでに実行する必要があること、つまりトランザクションを実行し、チェーンの正しい状態を追跡することを実行することに依存しています。

一方、ZK が高価な楕円曲線を構築すると、非常に大きな追加コストがかかることがわかります。 ZK で大規模な証明を実行するには、専用のハードウェアか大規模並列処理、またはその両方が必要ですが、高価です。

結論: Optimistic Rollup システムには、本質的に大きなコスト上の利点があります。

オプティミスティック ロールアップと ZK: EVM の互換性

Arbitrum を構築する際に私たちが考慮した重要な点は、EVM との互換性でした。 Arbitrum は EVM と完全な互換性があり、同じ RPC インターフェイスを備え、EVM と同じバイトコードを受け入れます。実際には、これは、イーサリアム用に書かれたコードはそのまま Arbitrum 上で実行できることを意味します。

私たちは 1 年以上にわたって EVM 互換のオープンなチェーン (テストネットを含む) を実行してきましたが、真に準拠することがいかに難しいかを学びました。最初の 95% の互換性は難しいことではありませんが、実際には十分ではありません。より良いものを実現するには、多大な労力と、邪魔にならない製品アーキテクチャの両方が必要です。

ZK システムは互換性の点で幅広い範囲で動作します。これをレガシーツールとみなし、カスタム言語を学ぶことを奨励する人もいます。

しかし、一部の ZK システムは互換性を持たせる努力をしていません。もちろん、互換性を気にしない開発者やユーザーにとっては問題ありません。

私たちは、EVM が客観的に史上最高であると主張しているわけではありません。私たちが考えているのは、EVM をすでに使用している開発者、コード、開発者ツールの数を考慮すると、EVM には多くの実用的な利点があるということです。 Ethereum にデプロイされたプロジェクトを考えてみましょう。ロールアップまで拡張したい場合は、コードを新しい言語で書き直し、新しいセキュリティ監査を依頼し、複数のコード ベースを維持する必要がありますが、これは面倒でエラーが発生しやすいものです。しかし、まだコードを書いていない新しいプロジェクトであっても、EVM の互換性は、それらのプロジェクトが EVM の周りに存在するコード、ツール、人材プールを活用できるため、大きな利点となります。

いくつかの ZK プロジェクトが EVM 互換バージョンに取り組んでいますが、その曖昧な主張にもかかわらず、ZK ロールアップ中に EVM コントラクトを実行できるようにするコードがこれまでにリリースされたことは知りません。既存の暫定システムには重大な非互換性があります。たとえば、EVM 互換性を主張する ZK システムは、ADDMOD、SMOD、MULMOD、EXP、SELFDESTRUCT、および CREATE2 オペコードの実装に失敗し、XOR、AND、および OR のサポートの削除が検討されており、標準のトランザクション形式をサポートしていません。あらゆるプリコンパイルをサポートし、場合によってはトランザクション内のコントラクト呼び出しの数を制限します。 ZK モデルには根本的な非互換性があるようです。これにより、最適な場合でも、オプティミスティック ロールアップが達成する完全な互換性が有効にならずに、ZK EVM 互換性が詳細な印刷ページに付属することが保証されます。

現在、アプリケーション固有の ZK システムの例がいくつか存在することを明確にしておきます (Zcash、ZKSync 1.0、Loop など)。実際、これらのシステムの中には非常にうまく機能するものもあります。主要な違いは、これらが微調整されており、ZK 実装に適した特定のアプリケーション向けに特別に最適化されているということです。現在存在しないのは、互換性のある方法で EVM から ZK への移行を実装できる汎用コンパイラです。これに取り組んでいると主張するチームもいくつかありますが、利用可能なユーザー定義の ZK-EVM コントラクトのコスト証明の公開コードやベンチマークはありません。私たちの知識と公開されているすべてのデータに基づいて、そのコストは法外に高いと考えています。

結論: Optimistic だけが、最低コストで完全な EVM 互換性をサポートしています。

楽観的なロールアップと ZK: 無条件の信頼による可視性と圧縮性

Arbitrum を設計する際の重要な特性の 1 つは、無条件の信頼の可視性です。つまり、無条件の信頼による可視性とは、一元化することなく誰もがオンチェーンのコンテンツを表示またはアクセスできることを意味します。重要なのは、これは誰もが状態のスナップショットを閲覧できることを意味するだけでなく、チェーンの完全な履歴、つまり現在の状態に至るまでの経緯を誰でも閲覧できることを意味するということです。 UtilityChain を使用すると、中央集中型のデータ プロバイダーに依存することなく、非変更呼び出しをサポートし、イベント履歴を検索し、すべてのトランザクションを表示できるノードを誰でも実行できます。信頼できない可視性がこれを可能にします。

率直に言って、一部の ZK システムはあまり目立たず、完全なブロックチェーン機能を提供していないという事実を周囲に伝えようとしています。 「圧縮」についての話を聞いたら、注意深く聞いてください。彼らは、オンチェーン コンテンツをより効率的にエンコードしていると言っていますか (Arbitrum はこれを実行しており、Nitro リリースではさらに改善される予定です)。それとも、中央集中型データプロバイダーが後で共有しようとしない限り、オンチェーン履歴の一部は決して利用できないと言っているのでしょうか?

ZK 証明は、証明者が有効なチェーンを知っていることを証明するだけであることを思い出してください。証明だけではチェーンが何であるかはわかりません。証明を検証するのに十分なデータがあったとしても、チェーンの歴史を再構築するのに十分なデータはおそらくありません。

たとえば、アリスがボブに 1 ETH のトランザクションを継続的に送信し、ボブがチャーリーに 1 ETH のトランザクションを継続的に送信するとします。その後、アリスは以前より 1 ETH 減り、ボブの残高は変わっておらず、チャーリーは以前より 1 ETH 増えているという証明を検証します。

しかし何が起こった？アリスはボブにお金を払いましたか?ボブはチャーリーにお金を払いましたか?おそらくアリスはチャーリーに直接お金を払うでしょう。おそらく、アリスはETHを燃やし、チャーリーは他の誰かによって支払われたのでしょう。もしかしたら、ボブではなくダイアナが仲介者なのかもしれません。ボブは証拠を得るためにブロックチェーンに注目しますが、一部の ZK ロールアップではチェーンの可視性が提供されず、違いが分かりません。

多くのスマート コントラクト アプリケーションでは、チェックポイントを認識する以上のことが必要になります。彼らは連鎖を理解する必要があります。何が起こったのか、どのようにして最終状態に到達するのかを知る必要があります。 ZK ロールアップは、オプティミスティック ロールアップよりも優れた「圧縮」を誇ることがありますが、実際にはチェーンのデータを非表示にして、それが圧縮ではないことを証明者だけが認識できるようにします。つまり、重要なデータが削除されます。 ZK プロバイダーがオンチェーン履歴を公開する「必要がない」と言っている場合、彼らが実際に言っているのは、チェーンの可視性を保証できないということです。オンチェーンの可視性の保証を放棄することは、私たちが喜んで行う妥協ではありません。

結論: Optimistic Rollup システムは、最小限のコストで無条件の信頼による可視性を提供します。

楽観的なロールアップと ZK: 無条件の信頼、タイムリーな終了

ロールアップを検討する際の重要な要件は、ロールアップが無条件に信頼できるタイムリーな最終結果を提供するかどうかです。つまり、これは、トランザクションを送信した後、トランザクションの結果を自分自身と他の人に迅速かつ確実に知らせる必要があり、誰もそれを変更したり取り消したりしてはいけないことを意味します。

当社は、タイムリーなファイナリティを実現する最善の方法は、トランザクションの順序を実行から分離することであると考えています。ソートにより提案されたトランザクションの最終シーケンスが生成され、実行ではそのシーケンスでトランザクションの実行が試行されます。クォーラムのようにトランザクションの実行が決定的である場合、結果はトランザクションのシーケンスの決定的な関数であるため、トランザクションが完了する順序で結果を確定するのに十分です。トランザクションの順序を誰もが知っていれば、誰でも簡単に結果を判断できます。

シーケンスを終了するには、誰もがトランザクションを自分で実行して無条件の信頼を持って結果を知ることができるように、十分な情報を備えたシーケンスを L1 チェーンに公開する必要があります。理想的なロールアップは、順次トランザクション データをできるだけ頻繁に L1 チェーンに公開することです。

オプティミスティック ロールアップ システムでは、L1 チェーンへの公開のオーバーヘッドは最小限です。実際、Arbitrum は通常、シリアル化されたトランザクション データを 1 分程度ごとに L1 チェーンに公開し、ユーザーに迅速な最終結果を提供し、誰もそれらを元に戻せないことを保証します。取引。新しいオプティミスティック ロールアップ結果アサーションは 1 時間ごとに作成されますが、シーケンスはすでに完了しており、実行は決定的であるため、最終結果の速度が低下することはありません。

原則として、ZK システムは同様の方法で動作できます。つまり、トランザクションの順序 (L1 に公開されることが多い) と、後で行われる検証を分離し、場合によっては有効性の証明を提供します。ただし、この方法で動作する ZK ロールアップでは、基本的にオプティミスティック ロールアップ システムで公開されるデータを L1 チェーンに投稿する必要があるため、上で説明した (いわゆる) 「圧縮」技術はいずれも利用できません。これらの「圧縮」技術が機能するためには、同じ L1 トランザクション内で L2 トランザクションのバッチが発行されるたびに、一連の L2 トランザクションの有効性をリアルタイムで検証する必要があります。

したがって、宣伝されている「圧縮」技術を使用しようとする ZK Rollup には 2 つの選択肢が残されています。

1) シリアル トランザクションと実行証明を 1 分ごとに公開します。これにより速度は維持されますが、ZK-Proof をチェーンの外部で毎分生成し、L1 チェーンで検証する必要があります。実装に応じて、オンチェーンで ZK プルーフを発行するコストは 500,000 ガスから 500 万ガスの間と推定されます。

2) 逐次トランザクションとプルーフを 1 時間ごとに公開します。これにより、ZK プルーフ チェックのコストが妥当になりますが、ファイナリティ時間が 1 時間に延長されます。ユーザーが ZK オペレーターにトランザクションを送信し、オンチェーンで公開されてから数時間以内に、ユーザーは自分のトランザクションが含まれるかどうかさえ保証できませんが、オペレーターのメッセージを信頼するだけです。

ZK システムを構築している場合、これら 2 つのオプションは受け入れられないことがわかります。1 つ目はコストが高すぎ、2 つ目はタイムリーな最終結果が得られません。そのため、最終的には Optimistic Rollup バージョンと同じシーケンサーを使用し、基本的に同じデータを ZK バージョンの Arbitrum でオンラインで公開することになります。

ZK は数時間のデータを 1 つのタイム ノードに圧縮できると誰かが自慢しているのを聞いたら注意してください。長期間の終了時に 1 つのデータ ポイントのみを公開する場合は、その期間中に終了を提供しなかったことを意味します。

結論: 実際的な考慮事項により、オプティミスティック ロールアップ システムと ZK システムは、タイムリーに同じ方法でファイナライズを処理する必要があります。

楽観的なロールアップと ZK: 無条件の信頼の活力

無条件の信頼のダイナミズムは、誰でもシステムを強制的に進歩させることができることを意味します。 (無条件の信頼のセキュリティ特性により、この進行状況が正しいことが保証されます。)

最適化されたロールアップにより、どのノードでも正しい実行を宣言できます。請求を行うには、ノードがオンチェーントランザクションを実行し、ステークをデポジットするだけで済みます。ステークは、プロトコルによって請求が確認されると返金されます。

ZK システムでは、チェーンの状態を進めるために必要な ZK プルーフの 1 つを任意のノードが作成して発行できることが進行に必要です。これには、誰でも簡単に利用できるハードウェアとソフトウェアを使用する必要があります。したがって、専用のハードウェアを構築または購入する必要はなく、大規模な並列コンピューティングを実行することもできません。一般的なデバイス上で適切な ZK 証明を構築する方法が必要です。このサービスを提供しない ZK プロバイダー、またはそのシステムのプルーフを生成するコードをリリースする ZK プロバイダーは、進行中の無条件の信頼を提供せず、システムの生存保証もありません。彼らのシステムは集中化されており、特別に装備された当事者だけが進歩を強制できるからです。 (主要な ZK ロールアップ プロバイダーがその証明を一般ユーザーに実行可能にするかどうかは不明です。)

結論: 楽観的なロールアップ システムでは、無条件の信頼によって進捗を得ることが容易になります。

ZK 対 楽観的ロールアップ: ブリッジング

ZK Rollup が利点を持っている領域の 1 つは、イーサリアムへのブリッジとしてです。オプティミスティック ロールアップ システムでは、ロールアップから L1 への資金移動に 1 週​​間の遅延が見込まれますが、ZK ロールアップでは、ZK プルーフが L1 に発行された後すぐに勃起することができます。実際には、オプティミスティック ロールアップ ユーザーは高速ブリッジング サービスを利用して、L2 資金を低レイテンシの L1 資金に交換できるため、これに大きな違いはありません。したがって、ZK の利点は主に、ユーザーがブリッジング サービスによって請求される少額の料金の支払いを回避できることです (これらのサービスは価格で互いに競合します)。これは単なる理論上の話ではありません。現在、Arbitrum からの即時引き出しを提供できるリアルタイムの高速ブリッジ サービスが数多く存在します。

重要なのは、ZK ロールアップのブリッジングの利点はかなり狭いということです。L2 からイーサリアムへのブリッジングにのみ機能します。かつて（2019 年頃）、ロールアップでは 1 つまたは 2 つのライブ DAPP がゆっくりと展開されると多くの人が考えていました。このような世界では、ロールアップ ユーザーは常に L1 と L2 の間を行き来することになります。しかし、それは私たちが住んでいる世界ではありません。 Arbitrumには、Defiの隅々に何百ものdAppがある繁栄したエコシステムがあり、多くのユーザーがArbitrumとの架け橋を築き、そこに長期間滞在しています。また、ユーザーは複数のチェーンを飛び越えるので、イーサリアムだけに行くわけではありません。また、他の L1 とサイドチェーンも使用するため、このダイレクト ブリッジの場合、ZK ロールアップはオプティミスティック ロールアップよりも利点がありません。

要約する

要約する

オプティミスティック ロールアップと ZK システムを比較すると、オプティミスティック ロールアップ システムが明らかに勝者であると考えられます。 Optimistic ははるかに安価で、EVM および既存のツールと完全な互換性があります。実際の唯一の欠点は、高速ブリッジング サービスがないと L1 ブリッジングが非常に遅いことです。 ZK のその他の想定される利点には、チェーンの可視性や高速性を犠牲にする必要がありますが、それがユーザーが望むトレードオフであるとは考えません。

このどれもが変わる可能性はありません。 ZK プルーフの EVM 互換のコントラクト実行は、依然としてオプティミスティック ロールアップ実行よりも大幅にコストが高くなります。また、保証された進捗、オンチェーンの可視性、分散化を達成するための要件も変わりません。状況が変化した場合、当社はいつでも Arbitrum を ZK ベースの実行に切り替えることに前向きですが、そうはならないと考えています。

最後に、慎重に結論を述べます。人々は、Arbitrum が現在提供しているものと、ZK システムが将来提供するものを比較する傾向があります。しかし、この比較は無意味です。なぜなら、現在存在するシステムを比較すると、一般的にスマート コントラクトのオープンな展開をサポートしているのは Arbitrum のような Optimistic Rollup だけだからです。あるいは、将来のシステムを比較する場合は、将来の Arbitrum システムと将来の ZK システムを比較する必要があります。私たちは常に Arbitrum を改善しています。たとえば、今後の Nitro リリースには、コストの削減と、オンチェーン データの最適化されたロスレス圧縮が含まれています。私たちは Arbitrum を改善し、コストを理論上の限界まで下げるためにたゆまぬ努力を続けています。この投稿で示したように、現在存在するシステムとそれぞれの理論的制約を考慮すると、Optimistic Rollup が明らかに勝者であると考えています。