著者: protolambda、OP Labs 研究員編集者: Frank、Foresight News最も強力で安全な相互運用可能なレイヤー 2 ネットワークを作成するために、Optimism Collective はさまざまな手段を通じて分散化を追求しています。OP Stack の今後のフェールセーフ システムは、技術的な分散化に向けた大きな一歩となるでしょう。OP Stack のオープンソースとモジュラー設計は、L2 エコシステムの社会的分散化に向けて前例のない段階を生み出しています。この記事では、社会的分散化の原則、L2 アーキテクチャがどのようにしてこの原則を拡張して証明の多様性とクライアントの多様性を含めることができるかについて探り、Optimism Collective がこのアーキテクチャを活用してフェールセーフ システムを構築する方法について説明します。### イーサリアムからインスピレーションを受けた「社会的分散化」イーサリアム プロトコルは、特に広範囲の貢献者が堅牢な分散型ネットワークの構築に参加できるようにするソリューションのオプションを提供することで、社会的分散化の恩恵を受けています。ノード ソフトウェアの場合、これはクライアントの多様性を意味します。クライアントが増えれば増えるほど、単一障害点がバリデータ ネットワークに与える影響は少なくなります。Layer1 のコア開発者は、この貢献モデルを「バザール」と表現します。これは、騒がしく一見混沌としているように見えますが、非常に効率的で動的です。プロトコル開発に根本的にオープンなアプローチを採用することで、最も幅広い貢献者が参加してプロトコルを改善できます。Optimism Collective は、社会的分散化に対するイーサリアムのアプローチを実装および反復する独自の立場にあります。OP Stack は、MIT ライセンスの下でオープン仕様とオープンソース ソフトウェアを提供することで社会的分散化を実現し、Optimism Collective は、それを反復するスーパー チェーンを作成することで社会的分散化を達成できます。### L2 アーキテクチャのより詳細な理解イーサリアムには、L1 のオープン仕様と、コンセンサス層と実行層を分離するモジュール型クライアント アーキテクチャがあります。OP-Stack は同じアーキテクチャを L2 に実装します。コンセンサス層は、L1 を追跡し、実行入力をエクスポートする 2 つのクライアントである op-node と Magi によって強化されています。実行層は、op-geth、op-erigon、および op-reth によってサポートされています。ただし、L2 アーキテクチャでは、このスタックに新しいレイヤー、つまり証明レイヤーが追加されます。これは、L2 の出力を L1 に安全にブリッジする層です。L1 と L2 の両方でコンセンサスと実行を確保するには複数のクライアントを使用することがベスト プラクティスであるのと同様に、L2 の検証層についても、複数の認証方法を使用することで最適なセキュリティを確保できます。異なるクライアントを持つバリデーターが合意に達する方法と同様に、オンチェーン証明書のクォーラムは、L2 状態の主張がさまざまな方法で検証されていることを示し、完全な失敗につながるエラーの可能性を大幅に低減します。現在、証明には、アテステーション、エラー証明 (不正証明とも呼ばれる)、およびゼロ知識有効性証明の 3 つの一般的なタイプがあります。後者の 2 つは、L2 状態遷移を同期形式で表現し、入力として L1 データと L2 の前状態が与えられた場合にその実行を証明するという点で共通のパターンを共有します。### 証明システムのコンポーネントを分離して証明の多様性を実現するシステムがさらに独立したコンポーネントに分解できることを示します。* 同期 L2 状態遷移を定義する「プログラム」。* プログラムを実行および検証するための「仮想マシン」(VM)。* L1 データと L2 事前状態を入力として受け取る「事前画像オラクル」。現在のゼロ知識証明の多くは依然としてこれらのコンポーネントを緊密に結合し、単一の L1 トランザクション データ上で実行される ZK-EVM を作成します。ただし、OP スタックはそれらを分離して複雑さを分離し、クライアントの多様性を可能にし、全体をより強力にします。インタラクティブな障害証明では、仮想マシン トレースに二分ゲームを追加してオンチェーン証明を検証します。一方、仮想マシン ベースのゼロ知識証明では、実行を計算してフォールドし、有効性証明を提供します。 (Optimism ZK RFP に応じて Risc0 と O(1)-Labs が設計している仮想マシンベースのゼロ知識証明を参照してください)。プログラムでは、実際の状態遷移を「クライアント」、入力取得（L1 データおよび L2 事前状態）を「サーバー」として定義します。このプログラムは、通常のブロックチェーン ノードと同様に、仮想マシンを使用せずにサーバー/クライアントから独立して実行され、多くのコードを共有します。たとえば、Go op-program クライアントは op-geth から op-node のフォークと EVM をインポートすることによって構築されますが、サーバーは L1 および L2 Ethereum RPC からデータを取得します。### FPVMの機能概要フォールトプルーフ仮想マシン (FPVM) は、OP スタックのフォールトプルーフ スタックのモジュールの 1 つです。この VM は、正しいインターフェイス (特にプレイメージ オラクルに関連するインターフェイス) を提供すること以外、イーサリアムまたは L2 に固有のものは何も実装していません。FPVM 内で実行される Fault Proofing Program (FPP) クライアントは、L2 状態変換部分を表現します。この分離により、仮想マシンは最小限に保たれます。Ethereum プロトコルへの変更 (EVM オペコードの追加など) は仮想マシンに影響しません。代わりに、プロトコルが変更された場合、FPP を更新して新しい状態遷移コンポーネントをノード ソフトウェアにインポートすることができます。同じゲーム コンソールで新しいバージョンのゲームをプレイするのと同様に、L1 構成証明システムを更新して、次のことを証明できます。さまざまなプログラム。仮想マシンは低レベルの命令の実行を担当し、FPP をシミュレートする必要があります。仮想マシンの要件は低くなります。プログラムは同期的に実行され、すべての入力は同じプレイメージ オラクルを通じてロードされますが、これらすべては依然として L1 EVM チェーンで証明される必要があります。これを行うには、一度に 1 つの命令のみを証明できます。二分ゲームにより、完全な実行トレースを証明するタスクが 1 つの命令のみに減ります。命令の証明は FPVM ごとに異なる場合がありますが、通常は Cannon と同様に見え、次のように命令を証明します。* この命令を実行するために、仮想マシンはスレッド コンテキストの命令サイクルに似たものをシミュレートします。命令はメモリから読み取られて解釈され、レジスタ ファイルとメモリに何らかの変更が発生する可能性があります。* プリイメージオラクルやメモリ割り当てなどの基本的なプログラム実行時のニーズをサポートするために、実行では Linux システム コールのサブセットもサポートされます。読み取り/書き込みシステム コールにより、プリイメージ オラクルとの対話が可能になります。プログラムは、プリイメージを取得するリクエストとしてハッシュを書き込み、それを一度にチャンク単位で読み取ります。最初の FPVM である Cannon は、この方法で MIPS 仮想マシンを実装しました。仮想マシンの詳細については、関連ドキュメントと大砲の仕様を参照してください。 FPVM と FP プログラム間のインターフェイスは標準化され、仕様に文書化されています。### FPVM から ZKVM へ失敗証明は状態遷移証明の唯一のタイプではありません。ZK 有効性証明は、高速クロスチェーンブリッジングの可能性があるため、魅力的なオプションです (ZK 有効性証明にはオンチェーンチャレンジゲームがないため、紛争ウィンドウがありません)。高度な Ethereum スタックをサポートし、さまざまなクライアント実装をホストするには、仮想マシンとプログラムを分離する必要があります。これは、最小限の RISC-V (Risc0 による) または MIPS (O(1) Labs による) 仮想マシンが障害防止で使用されるのと同じプログラムをホストできることを証明するために、ZK RFP プロジェクトが採用したアプローチです。ZK-VM をサポートするには、プリイメージ オラクルが非対話的にデータをロードできるようにするためにいくつかの小さな調整が必要ですが、仮想マシンを汎用化することで、OP スタックの変更に直面しても ZK はより将来性があることが証明されます。### 外部貢献者の機会OP Stack は、証明からゼロ知識証明まで、追加の仮想マシンとプログラムのオプション、および追加の独立した証明システムを歓迎します。クライアントの多様性と同様に、証明の多様性も集団的な取り組みです。現在進行中の OP スタックのプルーフ レイヤーへの追加には次のものがあります。* RISC-V FPVM「Asterisc」はprotolambdaによって開発され、Go言語で書かれています。* Base および OP Labs の貢献者によって構築された Magi および op-reth に基づく Rust FP プログラム。* Risc0 によって構築された zeth (ZK-reth ブランチ) に基づく Rust ZK プログラム。大砲、オペプログラム、二分ゲーム、そしてオープンソース コミュニティの無限の創造性が進化するにつれて、テストの実装やバグ報奨金プログラムへの参加を通じてスタックに貢献する機会がさらに多くなるでしょう。
OPスタックによって開始されるフェイルセーフシステムの解釈：イーサリアムに触発され、技術的な分散化に向けた大きな一歩
著者: protolambda、OP Labs 研究員
編集者: Frank、Foresight News
最も強力で安全な相互運用可能なレイヤー 2 ネットワークを作成するために、Optimism Collective はさまざまな手段を通じて分散化を追求しています。
OP Stack の今後のフェールセーフ システムは、技術的な分散化に向けた大きな一歩となるでしょう。OP Stack のオープンソースとモジュラー設計は、L2 エコシステムの社会的分散化に向けて前例のない段階を生み出しています。
この記事では、社会的分散化の原則、L2 アーキテクチャがどのようにしてこの原則を拡張して証明の多様性とクライアントの多様性を含めることができるかについて探り、Optimism Collective がこのアーキテクチャを活用してフェールセーフ システムを構築する方法について説明します。
イーサリアムからインスピレーションを受けた「社会的分散化」
イーサリアム プロトコルは、特に広範囲の貢献者が堅牢な分散型ネットワークの構築に参加できるようにするソリューションのオプションを提供することで、社会的分散化の恩恵を受けています。
ノード ソフトウェアの場合、これはクライアントの多様性を意味します。クライアントが増えれば増えるほど、単一障害点がバリデータ ネットワークに与える影響は少なくなります。
Layer1 のコア開発者は、この貢献モデルを「バザール」と表現します。これは、騒がしく一見混沌としているように見えますが、非常に効率的で動的です。プロトコル開発に根本的にオープンなアプローチを採用することで、最も幅広い貢献者が参加してプロトコルを改善できます。
Optimism Collective は、社会的分散化に対するイーサリアムのアプローチを実装および反復する独自の立場にあります。OP Stack は、MIT ライセンスの下でオープン仕様とオープンソース ソフトウェアを提供することで社会的分散化を実現し、Optimism Collective は、それを反復するスーパー チェーンを作成することで社会的分散化を達成できます。
L2 アーキテクチャのより詳細な理解
イーサリアムには、L1 のオープン仕様と、コンセンサス層と実行層を分離するモジュール型クライアント アーキテクチャがあります。
OP-Stack は同じアーキテクチャを L2 に実装します。
コンセンサス層は、L1 を追跡し、実行入力をエクスポートする 2 つのクライアントである op-node と Magi によって強化されています。
実行層は、op-geth、op-erigon、および op-reth によってサポートされています。
ただし、L2 アーキテクチャでは、このスタックに新しいレイヤー、つまり証明レイヤーが追加されます。
これは、L2 の出力を L1 に安全にブリッジする層です。L1 と L2 の両方でコンセンサスと実行を確保するには複数のクライアントを使用することがベスト プラクティスであるのと同様に、L2 の検証層についても、複数の認証方法を使用することで最適なセキュリティを確保できます。
異なるクライアントを持つバリデーターが合意に達する方法と同様に、オンチェーン証明書のクォーラムは、L2 状態の主張がさまざまな方法で検証されていることを示し、完全な失敗につながるエラーの可能性を大幅に低減します。
現在、証明には、アテステーション、エラー証明 (不正証明とも呼ばれる)、およびゼロ知識有効性証明の 3 つの一般的なタイプがあります。後者の 2 つは、L2 状態遷移を同期形式で表現し、入力として L1 データと L2 の前状態が与えられた場合にその実行を証明するという点で共通のパターンを共有します。
証明システムのコンポーネントを分離して証明の多様性を実現する
システムがさらに独立したコンポーネントに分解できることを示します。
現在のゼロ知識証明の多くは依然としてこれらのコンポーネントを緊密に結合し、単一の L1 トランザクション データ上で実行される ZK-EVM を作成します。ただし、OP スタックはそれらを分離して複雑さを分離し、クライアントの多様性を可能にし、全体をより強力にします。
インタラクティブな障害証明では、仮想マシン トレースに二分ゲームを追加してオンチェーン証明を検証します。一方、仮想マシン ベースのゼロ知識証明では、実行を計算してフォールドし、有効性証明を提供します。 (Optimism ZK RFP に応じて Risc0 と O(1)-Labs が設計している仮想マシンベースのゼロ知識証明を参照してください)。
プログラムでは、実際の状態遷移を「クライアント」、入力取得（L1 データおよび L2 事前状態）を「サーバー」として定義します。このプログラムは、通常のブロックチェーン ノードと同様に、仮想マシンを使用せずにサーバー/クライアントから独立して実行され、多くのコードを共有します。
たとえば、Go op-program クライアントは op-geth から op-node のフォークと EVM をインポートすることによって構築されますが、サーバーは L1 および L2 Ethereum RPC からデータを取得します。
FPVMの機能概要
フォールトプルーフ仮想マシン (FPVM) は、OP スタックのフォールトプルーフ スタックのモジュールの 1 つです。
この VM は、正しいインターフェイス (特にプレイメージ オラクルに関連するインターフェイス) を提供すること以外、イーサリアムまたは L2 に固有のものは何も実装していません。FPVM 内で実行される Fault Proofing Program (FPP) クライアントは、L2 状態変換部分を表現します。
この分離により、仮想マシンは最小限に保たれます。Ethereum プロトコルへの変更 (EVM オペコードの追加など) は仮想マシンに影響しません。
代わりに、プロトコルが変更された場合、FPP を更新して新しい状態遷移コンポーネントをノード ソフトウェアにインポートすることができます。同じゲーム コンソールで新しいバージョンのゲームをプレイするのと同様に、L1 構成証明システムを更新して、次のことを証明できます。さまざまなプログラム。
仮想マシンは低レベルの命令の実行を担当し、FPP をシミュレートする必要があります。仮想マシンの要件は低くなります。プログラムは同期的に実行され、すべての入力は同じプレイメージ オラクルを通じてロードされますが、これらすべては依然として L1 EVM チェーンで証明される必要があります。
これを行うには、一度に 1 つの命令のみを証明できます。二分ゲームにより、完全な実行トレースを証明するタスクが 1 つの命令のみに減ります。
命令の証明は FPVM ごとに異なる場合がありますが、通常は Cannon と同様に見え、次のように命令を証明します。
最初の FPVM である Cannon は、この方法で MIPS 仮想マシンを実装しました。仮想マシンの詳細については、関連ドキュメントと大砲の仕様を参照してください。 FPVM と FP プログラム間のインターフェイスは標準化され、仕様に文書化されています。
FPVM から ZKVM へ
失敗証明は状態遷移証明の唯一のタイプではありません。ZK 有効性証明は、高速クロスチェーンブリッジングの可能性があるため、魅力的なオプションです (ZK 有効性証明にはオンチェーンチャレンジゲームがないため、紛争ウィンドウがありません)。高度な Ethereum スタックをサポートし、さまざまなクライアント実装をホストするには、仮想マシンとプログラムを分離する必要があります。
これは、最小限の RISC-V (Risc0 による) または MIPS (O(1) Labs による) 仮想マシンが障害防止で使用されるのと同じプログラムをホストできることを証明するために、ZK RFP プロジェクトが採用したアプローチです。
ZK-VM をサポートするには、プリイメージ オラクルが非対話的にデータをロードできるようにするためにいくつかの小さな調整が必要ですが、仮想マシンを汎用化することで、OP スタックの変更に直面しても ZK はより将来性があることが証明されます。
外部貢献者の機会
OP Stack は、証明からゼロ知識証明まで、追加の仮想マシンとプログラムのオプション、および追加の独立した証明システムを歓迎します。クライアントの多様性と同様に、証明の多様性も集団的な取り組みです。
現在進行中の OP スタックのプルーフ レイヤーへの追加には次のものがあります。
大砲、オペプログラム、二分ゲーム、そしてオープンソース コミュニティの無限の創造性が進化するにつれて、テストの実装やバグ報奨金プログラムへの参加を通じてスタックに貢献する機会がさらに多くなるでしょう。