Optimism アーキテクチャ
Optimism は EVM 等価のオプティミスティック・ロールアップ・プロトコルで、Ethereum のスケーリングを目的としています。Ethereum のスケーリングとは、ネットワークが処理できる有用なトランザクション数を増やすことを意味します。オプティミスティック・ロールアップ はレイヤー 2 のスケーラビリティ手法で、セキュリティや分散性を犠牲にせずに Ethereum の計算・ストレージ容量を拡張します。EVM 等価性 は、Ethereum イエローペーパーで定義された状態遷移関数への完全な準拠を指します。
オプティミスティック・ロールアップは、複数のトランザクションを単一のトランザクションにまとめ、Ethereum ネットワーク上のスマートコントラクトで検証します。このプロセスは「ロールアップ」と呼ばれ、個々のトランザクションが大きなトランザクションに統合されて Ethereum に送信されます。「オプティミスティック」という名称は、トランザクションが有効であると仮定し、反証が出るまでそのまま処理を進めることで、より高速かつ効率的に処理できることに由来します。
全体アーキテクチャ
op-node + op-geth
ロールアップノードはバリデータモードまたはシーケンサーモードで動作できます。
- バリデータ(検証者): Ethereum ノードを実行するのと同様に、ローカルで L2 トランザクションをシミュレートし、レート制限はありません。また、バリデータ は シーケンサー の作業を検証し、出力ルート を再計算してシーケンサーが提出したものと比較します。不一致があれば、バリデータ は フォルト・プルーフ を実行できます。
- シーケンサー: シーケンサー は特権的なアクターで、L2 ユーザーから受け取ったトランザクションを L2 ブロックにまとめ、データ可用性プロバイダー(バッチャー 経由)へ送信します。また、出力ルート を L1 に提出します。現在のスタックではシーケンサーは 1 つだけであり、OP スタックが非分散的であると批判される点です。
op-batcher
バッチ送信者(バッチャー)は、L2 のシーケンサーデータを L1 に送信し、検証者が利用できるようにします。
op-proposer
プロポーザーは L2 出力チェックポイントを Ethereum 上の L2 出力オラクルコントラクトに生成・送信します。ファイナライズ期間が経過すると、このデータに基づいて出金が可能になります。
バッチャーとプロポーザーはどちらも状態を L1 に送信しますが、なぜ分離されているのでしょうか? バッチャーはトランザクションデータをバッチ単位で L1 に集約・送信し、プロポーザーは L2 の状態を表すコミットメント(出力ルート)を送信して L2 アカウント状態の ビューを確定させます。これらを分離することで、並行して処理でき、効率が向上します。
contracts-bedrock
L2 が L1 とやり取りするための各種コントラクト:
- OptimismPortal: L1 の状態でスマートコントラクト呼び出しとして発生した L2 トランザクションのフィード。
- Batch inbox: バッチ送信者がトランザクションバッチを送信する L1 アドレス。
- L2 output oracle: 出金やフォルト・プルーフで使用するために L2 出力ルート を保存するスマートコントラクト。
デポジットの方法
出金の方法
Optimism ドキュメントへのフィードバック
OP スタックの理解は、いくつかの要因により難しいことがあります。その一つは、コードやドキュメントで同じコンポーネントが微妙に異なる名前で複数回言及される点です。例えば、"op-batcher" と "batch‑submitter"、"verifiers" と "validators" が混同され、各コンポーネントの正確な機能が分かりにくくなります。
もう一つの課題は、アーキテクチャが進化し続けるため、設計要素が時間とともに廃止されることです。ドキュメントが常に最新の変更を反映しているとは限らず、古い情報や不正確な情報に基づいてシステムを理解しようとすると、さらなる混乱を招きます。
これらの課題を克服するには、利用可能なすべてのドキュメントを注意深くレビューし、概念を一貫させ、OP スタックの変更やアップデートに常に追随することが重要です。追加の調査や他のユーザー・開発者との協働が必要になることもありますが、複雑なシステムを正しく理解し、効果的に活用するためには不可欠です。