Offchain Labs Lianchuang: 実用的な観点から、なぜ Arbitrum は最終的に Optimistic Rollup を選択したのでしょうか?

Offchain Labs 共同創設者、Ed Felten 著

編集者: ルフィ、フォーサイトニュース

Arbitrum は、Optimistic Rollup を使用した Ethereum スケーリング プロトコルです。なぜ Arbitrum が Optimistic を選択したのか、また Arbitrum が ZK 証明に移行すると予想しているのか、という質問がよくあります。以前にもこの質問に回答したことがありますが、それはほぼ 2 年前のことです。これは私の現在の個人的な意見であり、他の人が同意しないかもしれません。

私はシステムの設計に関しては実用主義を強く信じています。 1 つの技術的アプローチに夢中になり、それを何としても適用するのではなく、どのアプローチがユーザーと開発者のニーズに最も適しているかを考える必要があります。最善のアプローチは時間の経過とともに変わる可能性があり、その場合は喜んで変更します。

私たちは実用的な考慮から Optimistic for Arbitrum を選択しましたが、それでも Optimistic 証明の方が ZK 証明よりも優れた選択肢であり、ユーザーと開発者のニーズをよりよく満たすことができると信じています。簡単に言うと、Optimistic は ZK よりも安価で、シンプルで、柔軟性が高いです。以下でこれらの主張のそれぞれについて説明します。

そうは言っても、状況が変化し、ZK がより良い選択肢になるのであれば、Arbitrum は変更されるべきだと思います。しかし、それがすぐに起こるとは予想していません。

楽観的な低コスト

楽観的証明の利点は、正直な当事者の証明コストが常にゼロであることです。一般的な状況では、真実の陳述のみが発行され、異議を申し立てることはできないため、証拠は必要ありません。課題が存在する場合、その解決にはある程度のコストがかかります。しかし、不正な当事者はすべてチャレンジに負け、チャレンジの費用を支払うために使用できる賭け金の取り分を失います。

オプティミスティック プロトコルは、複数の当事者による実行に依存しているため、実行結果に関する公開された主張を確認できます。言い換えれば、チェーンにはノードが必要です。しかし、重要な目的を持つチェーンには、チェーンのアクティビティをサポートするために、ユーザーまたはインフラストラクチャプロバイダーによって実行される多数の通常のノードがあります。これらのノードは当然、Optimistic プロトコルの監視塔として機能します。

対照的に、ZK では、公開されたクレームごとに暗号証明を生成する必要があり、その証明はレイヤー 1 で検証される必要があります。 ZK の研究者は時間の経過とともに、これらの証明を生成するコストを削減してきましたが、ゼロにはなりませんでした。

実際、ZK 証明のコストはオプティミスティック実行に比べてかなり高くなります。スマート コントラクトがビット単位の AND 演算を実行する場合、Optimistic システムの各バリデーターはビット単位の AND 演算のみを実行します。 ZK 証明者は、ビット単位の AND 命令を実行し、その後、ビット単位の AND 命令の結果を証明するために、コストのかかる多数の暗号操作を実行する必要があります。アリスとボブが果物を買いに行き、アリスがブドウを買い、ボブがブドウとスイカを買った場合、アリスの費用は常にボブの費用よりも低くなります。

Optimistic Rollup と ZK Rollup では、通常のノードはチェーンの進化履歴を理解するためにすべてのトランザクションを実行する必要があるため、この部分は変わりません。

したがって、Optimistic の方がコストが低くなります。

楽観的なほうがシンプルです

ソフトウェア エンジニアリング、特にセキュリティ エンジニアリングでは、シンプルであるほど優れています。複雑化するとセキュリティ リスクが増大し、すべてが遅くなり、難しくなります。

Optimistic の証明が ZK の証明よりも簡単であることは疑いの余地がありません。楽観的な証明は開発者に簡単に理解されますが、ZK 証明は複雑な数学と、ほとんどの人が理解できない難解で微妙な暗号定理に依存しています。暗号学を教える教授でさえ、ZK 証明システムを理解するのに苦労するはずです。

楽観的なほうが柔軟性が高い

証明はどの L2 にも必要です。しかし、ユーザーと開発者が望んでいるのは証拠だけではありません。彼らは、Optimistic システム上に、より簡単かつ迅速に構築できる新しい機能を求めています。

良い例は、開発者が Rust や C++ などの汎用言語を使用してスマート コントラクトを作成し、これらのプログラムを WASM 仮想マシンで実行できるようにする Arbitrum Stylus です。これらは EVM コントラクトと同じチェーン上にあり、完全に構成可能です。 Stylus のような機能は構築が難しく、2 つの仮想マシンを 1 つのシームレスなシステムに統合する必要があります。

このような機能を Optimistic システムに組み込むことができる理由の 1 つは、Optimistic の実装で標準のプログラミング言語とツールを使用できるため、ソフトウェアの開発が容易になるためです。対照的に、ZK では、ZK 回路を手動で構築するか、中間コンパイラを使用してすべてを 1 つの回路にまとめる、さまざまなプログラミング ツールが必要です。カスタム ツールやプログラミング方法は常に時間がかかり、使用が煩わしいため、システム開発全体の進行が遅くなります。

Optimistic システムのシンプルなパフォーマンスは、より優れた柔軟性とより迅速な進化につながります。

ファイナライズ時間は同じです

オプティミスティック ロールアップと ZK ロールアップがいつ完成するのかよく尋ねられますが、答えはそれらは同じです。

取引は、その結果が完全に確実であり、契約の参加者全員が知っている場合に最終的なものとなります。ロールアップ チェーンは、オプティミスティック チェーンであっても ZK チェーンであっても、2 つの段階で動作します: まず、シーケンサーがチェーンに到達したトランザクション シーケンスを発行して記録します。次に、実行決済層が実行されたトランザクションの結果を計算して証明します。トランザクションを 1 つずつ順番に実行します。ファイナリティは、トランザクションがトランザクション シーケンス内で確定した位置にあるときに達成されます。この時点で、トランザクションの結果は確定したトランザクション シーケンスによって完全に決定され、誰もがその結果を知っています。

ファイナリティは証明者ではなく、イーサリアムに公開されたシーケンサーの出力 (Optimistic プロセスと ZK プロセスでも同じ) によって決定されるため、Optimistic システムと ZK システムは最終的な動作がまったく同じになります。

クロスチェーン通信時間

ZK が固有の利点を持っているのは、クロスチェーン通信のレイテンシー、つまり、あるチェーン上のコントラクトが信頼なしに別のチェーン上のコントラクトにメッセージを送信するのにかかる時間です。

代替可能資産 (ETH またはトークン) のクロスチェーン転送は通常、高速ブリッジング サービスを通じて実行され、その操作はオプティミスティック証明や ZK 証明に依存しないため、一般のユーザーにはクロスチェーン資産転送時間の違いはわかりません。

他のタイプのクロスチェーン メッセージの場合、ZK チェーンはオプティミスティック チェーンよりも速くその状態を親チェーン (つまり L2 イーサリアム) にチェックポイントできるため、ZK の方が高速になる可能性があります。これは、送信チェーンが ZK プルーフを使用している場合、資産転送以外のユースケースではトラストレス クロスチェーン メッセージングが高速になることを意味します。

この違いがどれほど重要であるかは正確には不明です。現在、クロスチェーンアクティビティの大部分は資産の転送であり、ユーザーエクスペリエンスはそれほど変わりません。

### 結論は

私にとって、答えは明らかです。Optimistic の利点 (低コスト、シンプルさ、柔軟性) は、ZK の利点 (非資産転送クロスチェーン機能の速度) よりも顕著です。

これが、Arbitrum が依然として楽観的な証明を使用している理由です。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)