本文へ移動
Financial Context Wiki

オプティミスティック・ロールアップ

シーケンサー receipt、L1 導出データ、unsafe/safe/finalized head、fault-proof game、canonical withdrawal、ガバナンス、fast exit をデプロイ単位で解説します。

更新日

教育目的の情報であり、プロトコル、ブリッジ、取引に関する助言ではありません。オプティミスティック・ロールアップの保証は、具体的なデプロイ、データモード、導出規則、稼働中の fault-proof game、権限、クロック、ガバナンス、出金コントラクトに依存します。各段階と資産を個別に確認してください。

端的な答え

オプティミスティック・ロールアップは、順序付けられたトランザクション列を実行し、各バッチに validity proof を添付することなく、プロトコル所定の導出データと state claim を公開します。「Optimistic」とは、適格な claim がデプロイ済み規則に従って進行し、成功した fault-proof dispute により誤りが立証されれば覆るという意味です。シーケンサーのメッセージが正しさを証明するわけでも、すべての実装で permissionless challenge や同じ出金遅延が存在するわけでもありません。

Rollup node は canonical L1 input と正確なプロトコル設定から L2 block を独立に導出します。したがって安全性は、data availability、正しい導出と実行、稼働中で健全な fault-proof system、L1 へのアクセスと finality、ガバナンス、bridge contract に依存します。state root だけではチェーンを再構築できず、無効な状態遷移にも異議を申し立てられません。

1
順序付け

シーケンサーが L2 取引を並べ、データまたはコミットメントを公開します。

仕組み

  1. デプロイを特定します。L1/L2 chain ID、Rollup 設定と fork、inbox と bridge contract、batch format と DA mode、state-claim/dispute-game contract、portal version、administrator、guardian、観測 block を固定します。stack の文書だけでは、指定チェーン上で各機能が稼働している証拠になりません。
  2. 観測状態を分類します。sequencer receipt または unsafe block は高速なローカル順序付けの約束です。L1 に公開された batch は安全に導出された safe head を支え、L1 finality は導出済み finalized head を支えます。state/output claim、解決済み dispute、実行可能な withdrawal は別々の対象とクロックです。
  3. L1 から L2 への導出パイプラインを再構築します。canonical L1 data から deposit、sequenced input、channel、batch、L1 origin、設定変更、状態遷移を検証します。blob によるデータでは、プロトコル期間中の availability と後日の archival retrieval を区別します。
  4. liveness と支配権を対応付けます。sequencer、batcher、proposer、challenger、relayer、guardian、upgrade authority を分け、forced inclusion や delayed inbox の有無、遅延、pause 条件、一般利用者が実際に呼び出せるソフトウェアを確認します。
  5. デプロイ済み fault-proof path を検証します。respected game type、proposer/challenger permission、bond、absolute prestate、proof program と VM、preimage oracle、claim depth、clock と extension、resolution rule、blacklist/pause 権限、upgrade delay を記録します。OP Stack の仕組みを Arbitrum などへ転用してはいけません。
  6. withdrawal と経済性を別々に追跡します。L2 initiation、L1 proof、claim/game dependency、maturity/finality delay、re-proving、portal check、L1 execution を追います。fast exit は別の相手との有償の流動性・信用取引であり、canonical challenge clock の短縮ではありません。
  7. 継続的に照合します。unsafe/safe/finalized block hash、L1 batch transaction、state claim、game outcome、bridge message、receipt、token contract、最終残高を突き合わせます。L1/L2 reorg、batch 欠落、dispute、pause、contract upgrade、DA migration 後は分析をやり直します。

計算例

  • 導出 payload。 batch に 10,000 件のトランザクション、1,200 KB の raw protocol input があり、圧縮後は 300 KB です。比率は 1,200 / 300 = 4.0x、削減率は 1 - 300 / 1,200 = 75%、10 進表記の平均は 300,000 / 10,000 = 30 bytes/tx です。これは encoded input payload のみを表し、L1 gas、実行の正しさ、state size、archive 保証ではありません。
  • 未計上費用控除前の contribution。 利用者の支払額は 2.4 ETH、測定した L2 execution は 0.3 ETH、L1 DA は 1.2 ETH です。残額は 2.4 - 0.3 - 1.2 = 0.9 ETH、つまり 0.9 / 10,000 = 0.00009 ETH/tx です。運用インフラ、L1 execution、proof game、refund、資本、障害、税金を含まないため、純利益ではありません。
  • dispute の局所化。 説明用 execution trace は 2^20 = 1,048,576 step です。理想的な二分探索では 1 step の特定に log2(2^20) = 20 回の選択が必要です。各説明用 round に個別の 3-hour 上限があるなら、単純な直列上限は 20 * 3 = 60 hours です。実際の protocol は固有の chess clock、並行性、extension、transaction schedule を使います。
  • withdrawal clock と高速流動性。 説明用 batch は 10 minutes 後に L1 に到達し、さらに 30 minutes 後に recognized claim が現れ、仮の challenge period が 7 days、最終 relay が 2 hours かかります。順次経過時間は 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes です。liquidity bridge は 4.97 ETH を前払いし、対象となる claim は 5 ETH、料金は 0.03 ETH、すなわち 0.03 / 5 = 0.6% ですが、canonical claim のクロックとリスクは変わりません。

リスク

  • L1、L2、chain ID、Rollup config、contract deployment の誤り。
  • unsafe な sequencer receipt を safe または final とみなす。
  • sequencer の不整合な提示、censorship、reordering、outage。
  • L1 batch publication の遅延、欠落、不正形式、無効化。
  • blob または alternative-DA data が利用不能または未保存になる。
  • derivation client、設定、fork の不一致。
  • L1 reorg により従来 safe とした導出 input が無効になる。
  • batcher、state proposer、proof participant の停止。
  • forced-inclusion/delayed-inbox path が不在、停止、または誤解される。
  • fault proof が未デプロイ、非稼働、または誤った game type に紐付く。
  • proposer/challenger role が permissioned または allowlisted である。
  • challenger が offline、censored、資金不足、または期限切れになる。
  • proof program、VM、absolute prestate、oracle、verifier の不具合。
  • clock、extension、claim position、bond、resolution accounting の誤り。
  • guardian、security council、pause、blacklist の介入。
  • 即時 upgrade、短い timelock、administrator key の侵害。
  • canonical bridge、messenger、replay、asset mapping の脆弱性。
  • withdrawal proof、maturity、re-proof、finalization、relay の失敗。
  • fast-exit の流動性、価格、経路、支払不能、counterparty risk。
  • L1 finality、L2 derived finality、claim resolution、asset receipt の混同。

よくある誤解

  • Optimistic とは、利用者がシーケンサーの表示結果を無条件に信頼することだ。
  • state root の公開だけで data availability と独立導出が実現する。
  • すべての Optimistic Rollup に稼働中の permissionless fault proof と共通の 7 日クロックがある。
  • L2 block が safe/finalized なら L2→L1 withdrawal をすぐ実行できる。
  • fast bridge は canonical challenge period を短縮し、Rollup risk だけを負う。

関連トピック

出典

ナビゲーション

Wiki を検索...