OP Stack + ゼロ知識証明 = L2の終局ゲーム？

撰文：Bill Qian、Yongxin Song、Bonan Yuan，Cypher Capital

Layer2の終局ゲーム

現在のLayer2レースは非常に激しい競争を繰り広げており、前にはArbitrum、Optimism、Baseなどのoptimistic rollupがあり、後にはScroll、zkSync、Starkenet、Scroll、Polygon zkEVM、Taiko、LineaなどのZero Knowledge Proof（ZKP）rollupがあります。一見、Layer2の競争は多様に見えますが、実際にはすべてがエンジニアリングの原理において、オフチェーン計算とオンチェーン証明のアプローチを使用しています。optimisticのfraud ProofでもZKPの回路証明でも、エンジニアリング実践における核心的な違いは、オンチェーン証明の方法の違いにあります。他の原理は実際には大同小異です。そこで、Optimismは特別な道を選びました。それはモジュラーLayer2であり、論理的にLayer2のさまざまなコンポーネントを分離します。OPstackがLayer2の各モジュールの結合を実現した後、非常に論理的に思えるアイデアが開かれました。それはZKP on OP Stackです。OP StackのchallengerをOptimistic ProofからZero Knowledge Proofに変更することで、OpStackはさまざまな証明をサポートする汎用Layer2アーキテクチャになります！

ZKP on OP Stack

すべての議論の始まりは、OptimismのRFPから来ています。https://github.com/ethereum-optimism/ecosystem-contributions/issues/61。

以下に、このRFPが提起した問題と発展方向を紹介します。

意図：Optimismの誤り証明プログラムを証明するための零知識証明を実現すること（Golangコンパイラがサポートする命令セットを通じて）

実現方法：OPチェーンに零知識証明（ZKP）を実装することは、L2とL1間の安全で低遅延の通信を実現する前提です。命令セットをサポートする零知識証明は、Optimismの誤り証明プログラムを証明でき、任意のOP Stackのブロックチェーンを含みます。ISAの標準実行トレースに基づいて、故障証明プログラムは追加の要件を導入します。

具体的には、故障証明プログラムは「予測オラクル」の概念を導入し、特別なシステムコールを使用して外部データをプログラムにロードします。各故障証明仮想マシンは、特定のメモリ位置にデータのハッシュを配置し、システムコールを実行し、そのハッシュの原像をメモリにロードするメカニズムを実装する責任があります。予測オラクルは初期入力をプログラムに導入するためにも使用されます。詳細については、故障証明プログラムのドキュメント内の「予測オラクル」セクションを参照してください。

簡単に言えば、この提案はOP Stackの高度なモジュール化特性を利用して、元々は楽観的証明（Optimistic Proof）に基づく誤り証明方式を、零知識証明を利用して切り替えることを目指しています。さらに特化すると、現在OPはGETHをMIPSにコンパイルしてMini Gethにしているため、OP Stackの零知識証明はZKMipsとして理解できます。つまり、Mips仮想マシンに基づく零知識証明です。

なぜZKPなのか？

現在、OP Stackは順調に動いているのではないでしょうか。楽観的証明に基づくOptimismとArbitrumは、非常に良いコミュニティサポートと開発者サポートを得ています。OP Stackはなぜ零知識証明を探求する必要があるのでしょうか。筆者はここにいくつかの理由があると考えています。

• OP StackはLayer2のモジュールを高度に抽象化しており、ZKPを導入することは異なる誤り証明方式を導入するだけであり、OPが楽観的証明を放棄することを意味するわけではありません。OP Stackを使用する開発者は、異なる証明方式を自由に選択できます。

• 楽観的証明（Optimistic Proof）に基づくOptimismとArbitrumは、現在も誤り証明をサポートしていません。本質的にOPとARBは、証明不可能な単一のチェーンです。

• 楽観的証明の7日間の最終確認速度は、実際に非常に遅いです。ZKPのLayer2が市場を占めると、ZKPの30分の証明速度は顕著な優位性を形成し、最終的にユーザーはより高い安全性を持つZKP Layer2を選択するでしょう。

したがって、OptimismがZKPをサポートするのは時間の問題です。大胆な推測をすると、将来的にOP Stackは楽観的証明と零知識証明の2つの誤り証明システムをサポートするでしょう。OP Stackは汎用のLayer2アーキテクチャであり、継続的に進化しています。OP Stackがなぜ異なる証明システムの切り替えを実現できるのかを理解するために、以下ではOP Stackを詳細に分解します。

OP Stackの核心モジュール

(この図はOptimismのGitHubからの引用です)

OP Stackにおいて重要なモジュールは以下の通りです：

• op-node

• op-geth

• op-batcher

• op-proposer

• op-program

• Cannon

• op-challenger

これらのモジュールはすべて独立したプログラムであり、HTTPの標準インターフェースを介して通信します。これは、開発者がOP Stack内の特定の機能を変更したい場合、特定のモジュールを変更するだけで自分のLayer2をカスタマイズできることを意味します。以下の章では、各OP StackモジュールとOP Stack全体のアーキテクチャを具体的に紹介します。

op-node

op-nodeはOP Stackの最も重要なモジュールです。一方では、Sequencerとしてop-nodeはブロックチェーンのコンセンサスクライアントの実装を含み、EthereumのLighthouseやPrysmに類似して、ユーザーが提出したトランザクションを順序付けます。もう一方では、rollup driverとしてop-nodeはL1ブロックのデータからLayer2のチェーンを派生させる責任があります。

Sequencerはユーザーのトランザクションを収集して順序付けた後、op-batcherによってバッチが生成され、バッチャーがバッチをL1に提出する前に、Rollupネットワーク内の遅延を低減するために、SequencerはLayer2のブロックを事前に生成し、P2PでRollupネットワーク内に広めることができます。L2で直接生成されたブロックはunsafeと見なされ、バッチがL1に提出されて推導されるまでsafeとは見なされませんが、通常の状況下（ブロック再編成や詐欺などがない場合）では、L2で直接生成されたブロックとL1から推導されたブロックは同じです。Binanceなどの取引所は、一定のLayer2ブロックを待った後、トランザクションが確定したと見なします。これは、バッチがL1に提出されるのを待つ必要がないため、エラーの確率が非常に低いことを示しています。

L2ブロックの推導プロセスはdriverが担当し、driverはL1のヘッドブロックとL2チェーンの同期プロセスを継続的に追跡し、L1から入金トランザクション、L2トランザクションデータ、および対応するレシートを取得し、ペイロード属性を生成します。ペイロード属性は実行エンジンに渡され、L2ブロックが計算されます。L2ブロックは完全にL1チェーンのブロックに依存しており、L2バッチを含むL1ブロックが生成されるたびに、L2チェーンが延長されます。さらに、L1ブロックが再編成されると、L2ブロックも再編成されます。

op-geth

op-gethはOP Stackの実行クライアントの実装であり、go-ethereumにわずかな修正を加えてOP Stackのニーズに適応させています。コンセンサスクライアントop-nodeはEngine APIを介して実行クライアントop-gethを駆動し、ペイロード属性を利用してop-gethは出力情報を計算し、L2ブロックを生成します。

op-batcher

バッチャーはバッチ提出者であり、主に2つのタスクを含みます。一つはL2シーケンサーのデータをバッチに圧縮すること、もう一つはバッチをL1に提出し、検証者がデータを利用して検証できるようにすることです。

バッチャーはDA層にバッチトランザクションを提出し、トランザクションには1つ以上のチャネルフレームが含まれます。チャネルは一連のシーケンサーのバッチで構成され、より高い圧縮率を得るために使用されます。具体的には、バッチャーは現在zlibを使用してデータを圧縮しています。チャネルのサイズがバッチャートランザクションが収容できる上限を超える可能性があるため、チャネルは1つ以上のチャネルフレームに分割され、1つのバッチャートランザクションには1つ以上のチャネルフレーム（異なるチャネルからのものも含む）が含まれることができます。

source: Optimism

この設計はバッチャーに非常に高い柔軟性を提供し、将来的にはOP Stackがバッチャーを利用して複数のサイナーを並行して使用することをサポートするでしょう。

op-proposer

op-proposerはop-gethが実行したL2ブロックから生成された新しい状態のコミット（現在はOutput Merkle Root形式）をL1に提出する責任があります。Output Rootはすぐには有効にならず、争議期間が終了するまで最終的なものとは見なされません。

以上がOP Stackで実現された部分であり、以下のFault Proof関連モジュールの内容はまだ完成しておらず、文書の規範に基づいて論じられています。

OP Fraud Proofは3つのコンポーネントで構成されています：

• プログラム：与えられたRollup Inputs（L1バッチトランザクションデータ）のコミットと争議を無状態で検証します（PreImageOracleが提供するInputsを使用して同じ計算プロセスを再現します）。

• VM：無状態のプログラムとInputsが与えられた場合、任意の命令を追跡します（したがって状態を持つ）、L1で証明します。

• インタラクティブ争議ゲーム：争議を単一の命令に二分し、VMがこの基本ケースを解決します。

op-program

op-programはProgramの参照実装であり、op-nodeとop-gethの基盤の上に開発され、L2状態遷移に関する主張を検証する無状態のミドルウェアとして機能します。

L2状態の主張を検証するために、プログラムは最初にL1データを最終化されたL2状態に適用し、最新のL2状態を再構築します。このプロセスはop-nodeの作業に似ています。違いは、op-nodeはRPCからデータを取得し、状態変化をディスクに適用するのに対し、プログラムはPre Image Oracleからデータを取得し、状態変化をメモリに適用します。プログラムはオラクルからデータをストリーミングで読み取り、EOFまたは事前に定義された終了条件に達するまでストリーミング状態変化を行います。L2状態を再構築した後、状態と主張が同じかどうかに基づいて検証結果を返します。

Cannon

CannonはVMの実装であり、2つの主要なコンポーネントを含みます：

• オンチェーン MIPS.sol：単一のMIPS命令の実行を検証するためのEVM実装。

• オフチェーン mipsevm：任意のMIPS命令の証明を生成するためのGo実装。

オンチェーン部分では、MIPS.solはbig-endian 32-bit MIPS命令セットを実装し、Linuxカーネルの最小サブセットをシミュレートし、Goプログラムをサポートしますが、並行関連のシステムコールは含まれていません。

オフチェーン部分では、mipsevmはGo言語でMIPS.solの実行プロセスをシミュレートします。

• それはGoコードです

• …EVMを実行します

• …MIPSマシンをエミュレートします

• …コンパイルされたGoコードを実行します

• …EVMを実行します

簡単に言えば、CannonはEVM上でMIPSを使用してMINI Geth（GETHのMIPSコンパイル）を実行することを意味します。つまり、ETHのGolangバージョンです。

op-challenger

op-challengerは争議ゲームに関連するプロセスを処理する責任があります。

挑戦は、最初にtx実行後の状態ルートを選択し、質疑を発出します。その後、txは複数の命令に分解され、各命令の実行後に新しい状態が生成され、S1、S2、… Snの状態シーケンスが形成されます。

効率を向上させるために、挑戦の両者は交互にステップを実行する必要があり、AttackとDefendの2つのカテゴリに分かれます。

• Attack：争議の前の状態を入力として、争議状態を出力として期待します。DAGには前の状態のコミットが必要です。

• Defend：争議状態を入力として、争議後の状態を出力として期待します。DAGには後の状態のコミットが必要です。

例えば、1-9999の命令があり、S1-S10000の状態シーケンスが生成されると仮定します。最初に5000番目の状態を検証し、同じであればattack stepを行い、左に二分します。異なればdefend stepを行い、右に二分します。

最終的に二分法を通じて争議を単一の命令の前後の状態に固定し、VMに単一の命令の状態検証を処理させます。

モジュールの作業フロー

正常フロー（Challengeを含まない）

source: Cypher Capital

1. ユーザーはトランザクションを提出します。L2 RPCを介してL2に提出するか、L1に直接提出します（op-batcherをバイパスでき、より強い検閲耐性を持ち、緊急脱出装置としても機能します）。

2. op-nodeが起動したRPCサーバーがトランザクションを受信し、順序付けてop-batcherとop-gethに送信します。

3. op-batcherはシーケンスされたtxを圧縮し、バッチを生成してDA層（L1）に提出します。

4. op-gethはシーケンスされたtxを実行し、実行後の新しい状態をop-proposerに渡します。

5. op-proposerはL2の出力ルートをL1に送信し、L2状態のコミットとして保存します。争議期間が終了すると、状態は最終的なものと見なされます。

6. op-node内のdriverはL1からトランザクションデータやその他の情報を取得し、canonical L2ブロックを導出します。L1で最終化されたブロックから導出されたL2ブロックは最終化されたものと見なされ、L1で確認されたが最終化されていないバッチtxから導出されたL2ブロックはsafeと見なされます。遅延を低減するために、L2で直接生成されたL2ブロックはP2Pで事前に広められ、unsafeと見なされます。

Challengeフロー

source: optimism

1. ユーザーはインタラクティブな争議ゲームを開始します。

2. Cannon（VM）はMIPS仮想マシン上でop-program（Goで記述）を実行し、各ステップの実行状態の変化を追跡します。

3. op-programはPreImageOracleが提供するRollup Inputsのコミットを使用してL2状態の計算プロセスを再現し、実行トレースを記録し、無状態で争議を検証します。

4. op-challengerは二分法を使用して争議を単一の命令に特定します。

5. Cannonはその命令の前後の状態変化に対して証明を生成し、L1上のスマートコントラクトMIPS.solで検証します。

OP Stack+ZKP

上記のフローの説明に基づいて、Challengeモジュールは他のモジュールとの結合度が非常に低く、基本的なトランザクションフローへの影響も少なく、詐欺行為が発生した場合（2021年12月OP Mainnetが立ち上がって以来、まだ発生していません）にのみChallengeモジュールの介入が必要です。

現在のOptimismの7日間の退出確認時間を短縮し、OP Stackにより多くのモジュール化の選択肢を提供するために、OptimismはZKP技術を積極的に受け入れ、Optimismのfault proof programを証明し、著名なISAをサポートするZKPをOP Stackにもたらすことを希望しています。O(1) LabsとRisc-0チームの提案はFoundation Mission（RFP）アプリケーションを通過しました。

O(1) Labsの提案

source: O(1) Labs

O(1) LabsはMina Protocolの開発チームであり、Mina Protocolで採用されているKimchiをMIPS VMの証明システムとして使用する計画であり、いくつかの小さな変更を加えています。

Kimchiは、現在、内部積引数スタイルの多項式コミットメントスキームを使用して構成されたHalo2に似たPLONKishシステムです。従来のチューリングマシンベースの命令セットを使用した検証可能な計算をサポートします。

Kimchiのバックエンドは交換可能であり、現在の実装はPasta曲線を使用した内部積引数ベースの多項式コミットメントスキーム（Pasta-IPA）で定義されており、EVMで使用される暗号学的体系とは互換性がなく、EVM上での検証コストが高くなります。したがって、O(1) LabsはPasta-IPAをbn128曲線を使用したKZGコミットメントスキーム（bn128-KZG）に変更する計画であり、EVMの既存のプリコンパイルを使用でき、効率が向上します。

元々の入力fault proof MIPSシステムの入力は現在bn128-kzg Kimchiシステムに入力され、ZK-Prove実行パスに送られます。pre-imageシステムコールはOP StackのCannonを引き続き使用し、最終的な証明はL1上のスマートコントラクトに送信され、検証が通過した後にL1の状態が更新されます。

RISC Zeroの提案

RISC Zeroチームは、現在実装されているGroth16バックエンドに基づくRISC-V ISAのzkVM（一般的な暗号タスクのための加速コプロセッサを追加）を引き続き使用し、Rethに基づくEthereum ZKクライアントを修正してOptimismにさらに適応させ、zkVM内でL1-L2の導出ロジックを実装してトランザクションシーケンスがOptimismシーケンサーによって生成されたことを証明します。

ZKクライアントはzkVMゲストプログラムとホストライブラリの2つの部分で構成されており、OP Labsの提案におけるop-programとcannonに類似しています。zkVMゲストプログラムは状態遷移を計算し、ホストライブラリは計算データ遷移に必要なデータを取得し、zkVMゲストプログラムの実行を調整し、トランザクション実行状態遷移のzkpを生成します。

|------------------------|------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------| | | O(1) Labs | RISC Zero | | パフォーマンス | Optimismブロックのための44B MIPS命令ステップ | Optimismブロックのための\<2B zkVMサイクル | | レイテンシ | パラレル化なしでOptimismブロックのための2日 | パラレル化ありでOptimismブロックのための10-20分 | | 複雑さ | Kimchi：35kloc変更5-10kloc | ZKPフレームワーク：Rust zkVMの10kloc：Rustの54kloc | | ロバスト性 | MinaはKimchiによって2年間保護されています。 | 広範な自動テスト | | セキュリティ | kzg-bn128ベースのEVMフレンドリーなsnarkシステムは信頼されたセットアップを必要とします。 | zkVMは信頼されたセットアップを必要としないSTARKベースの証明を発行します。オンチェーン検証はSTARKからSNARKへの変換に基づいています。 | | OP Stack互換性 | 根本的な変更なし | 変更なし |

OP StackのZKP可能性探究

現在、ZKMというチームがZKMIPsのEVMを実現しており、EVMをMIPs命令セットに翻訳し、零知識証明を行っています。現在のフィードバックは非常に遅いですが、使用可能です。https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156

MinaとRisc0が比較的成熟した開発経験を持っていることを考慮すると、OP StackがZKPをサポートするのは時間の問題だと信じる理由があります。しかし同時に、OP StackのZKP開発が遅れて開始され、ネイティブサポートがないことを考慮すると、将来の性能は依然として予測できません。

OP Stack、Layer2の汎用アーキテクチャ

OP Stackはその優れたコード実装、寛容なオープンソースプロトコル、モジュール化されたアーキテクチャ設計により、多くの著名なチームに採用されています。唯一の批判は、採用されているOptimistic Rollup技術の決定性時間が長すぎることと、技術の先進性がZK Rollupに劣ることです。現在、第三者の専門チームの力を借りて、OP StackはZKPの未来に向けた試みを始めました。現在OP StackがまだFault Proofをサポートしていないことを考慮すると、OP StackはFault Proof段階をスキップし、直接ZK Proofを使用してより迅速な決定性とより高い安全性を得る可能性があります。

将来のLayer2開発者にとって、OP Stackは汎用のLayer2アーキテクチャとなり、開発者は自分のLayer2を起動する際に、アプリケーションに必要な安全性と実効性に基づいて、楽観的証明または零知識証明を柔軟に選択できます。楽観的証明に基づくLayer2はより安価になる一方で、零知識証明に基づくLayer2はより安全になると予想されます。

reference: https://blog.oplabs.co/building-a-fault-proof-system/