---
title: "オプティミスティック・ロールアップ"
description: "シーケンサー receipt、L1 導出データ、unsafe/safe/finalized head、fault-proof game、canonical withdrawal、ガバナンス、fast exit をデプロイ単位で解説します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<a id="answer"></a>

## 端的な答え

オプティミスティック・ロールアップは、順序付けられたトランザクション列を実行し、各バッチに 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 だけではチェーンを再構築できず、無効な状態遷移にも異議を申し立てられません。

<a id="mechanism"></a>

## 仕組み

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 後は分析をやり直します。

<a id="example"></a>

## 計算例

- **導出 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 のクロックとリスクは変わりません。

<a id="risks"></a>

## リスク

- 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 の混同。

<a id="misconceptions"></a>

## よくある誤解

- 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 だけを負う。

<a id="related"></a>

## 関連トピック

- [Fault proof](/ja/crypto/fraud-proof/)
- [データ可用性](/ja/crypto/data-availability/)
- [Rollup](/ja/crypto/rollup/)

<a id="sources"></a>

## 出典

- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org（参照日：2026-08-13）
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification（参照日：2026-08-13）
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification（参照日：2026-08-13）
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification（参照日：2026-08-13）
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification（参照日：2026-08-13）
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification（参照日：2026-08-13）
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs（参照日：2026-08-13）

Source: https://wiki.fcontext.com/ja/crypto/optimistic-rollup/index.mdx