--- title: "Layer 2ネットワーク" description: "Layer 2の実行、データ可用性、状態検証、決済、ファイナリティ、シーケンサー、ガバナンス、ブリッジ、手数料、実行可能な退出をデプロイ単位で解説します。" 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. # Layer 2ネットワーク > 教育目的の情報であり、投資または取引の助言ではありません。Layer 2という名称は、安全性、ファイナリティ、データ可用性、ガバナンス、ブリッジの支払能力、退出可能性を保証するものではありません。対象デプロイと現在のオンチェーン設定を確認してください。 ## 端的な答え Layer 2とは、ベースチェーン外で処理を実行または調整しつつ、検証、データ可用性、決済、退出の強制執行のうち定義された部分をベースチェーンに依存するプロトコルです。この呼称に統一規格はありません。十分なデータを公開し、フォールトプルーフまたは妥当性証明で状態遷移を強制するロールアップと、Validium、ステートチャネル、サイドチェーン、マルチシグブリッジ、取引所内の台帳では、すべてがL2を名乗っていても信頼前提が異なります。 個別のデプロイについては、L1コントラクトが実際に何を受け入れるか、導出データがどこにあるか、誰がトランザクションを順序付けるか、無効な状態をどう排除するか、ブロックがいつsafeまたはfinalizedになるか、誰がアップグレードや一時停止を行えるか、運営者の協力なしで利用者が退出できるかを確認します。確認の速さと手数料の安さは有用ですが、それだけでセキュリティの継承を立証するものではありません。 ## 仕組み 1. システムの同一性を固定します。L1とL2のチェーンID、ジェネシスとフォーク、ロールアップスタックとバージョン、決済およびブリッジのコントラクト、プロキシ実装、証明またはゲームの種類、データ可用性モード、シーケンサー、ブロック参照を記録します。ウェブサイト名とL2という語は発見用のメタデータであり、認証には使えません。 2. アーキテクチャを独立した軸で分類します。実行環境、順序付けモデル、状態検証方式、データの所在、決済チェーン、カストディ経路を記録します。オプティミスティックロールアップ、妥当性ロールアップ、Validium、チャネル、サイドチェーンは、これらの軸を異なる形で組み合わせます。実行エンジンがEVM互換でも、安全性が同じになるわけではありません。 3. 状態処理の流れを再構成します。利用者の送信、シーケンサーによる順序付け、L2実行、バッチ符号化、データ公開、状態コミットメント、フォールトプルーフの異議申立てまたは妥当性証明の検証、L1への取り込み、L1ファイナリティまで追跡します。独立したソフトウェアが、プロトコル所定の入力から主張されたL2状態を導出できることを確認します。 4. 可用性とライブネスを分けます。データがL1 calldataまたはblob、外部DAシステム、委員会のどこにあるかを特定し、保持と復旧の前提を確認します。シーケンサー停止、強制取り込み、代替送信、提案者または証明者の停止、メッセージ中継、具体的なエスケープまたは出金経路を検証します。 5. 時計と状態ラベルを分けます。シーケンサー確認済みまたはunsafeのブロックはデータ公開より先になり、safeのブロックはL1ファイナリティより先になり得ます。証明の受理、紛争解決、出金の成熟、ブリッジの解放には、それぞれ独立した条件が加わる場合があります。一律の確認回数や7日ルールではなく、対象デプロイの定義を使います。 6. 統制と経済性を把握します。プロキシ管理者、アップグレード遅延、セキュリティ評議会とガーディアンの権限、一時停止状態、手数料スカラー、gasトークン、バッチ容量、手数料受取人を確認します。L2実行、L1またはDAへの公開、運営者課金、ブリッジ手数料、送付先gas、待機コストを別々に記帳します。見積価格は約定保証ではありません。 7. 利用者の結果を照合します。正確なトークンコントラクトと表現、送付元の引落し、送付先の入金、レシート状態、状態ルートとメッセージルート、safeおよびfinalizedのブロックハッシュ、残存承認、実行可能な償還または市場退出を確認します。アップグレードのたびに設定を再確認し、ロールアップの証明システムからブリッジの安全性を推定してはいけません。 ## 計算例 - **バッチの経済性。** あるバッチに `2,000` 件のトランザクションがあり、圧縮後の平均が `160 bytes`、固定フレームが別に `20,000 bytes` なら、合計は `340,000 bytes` です。`$0.00002/byte` ではデータ費用が `$6.80`、固定の証明・決済費用 `$4.00` を加えた合計は `$10.80`、つまり `$0.0054/transaction` です。トランザクションが `200` 件しかなければ、同じ前提で `52,000 bytes`、データ費用 `$1.04`、合計 `$5.04`、つまり `$0.0252/transaction` になります。バッチ化が平均費用を下げるのは、ここで仮定したサイズ、稼働率、手数料のもとだけです。 - **容量と実現スループット。** 仮想的なL2が `60,000,000 gas` を `2 seconds` ごとに許容するなら、gas容量は `30,000,000 gas/second` です。利用者操作1件が `120,000 gas` なら機械的な上限は `250 operations/second`、実現稼働率が `72%` なら `180 operations/second` です。これはファイナリティ、分散性、エンドツーエンドのスループットを示す値ではなく、データ、証明、シーケンサーの制約が先に効くこともあります。 - **3つの状態時計と出金条件。** OP型の説明用タイムラインでは、トランザクションが `12:00 UTC` にシーケンサー確認され、L1への公開後の `12:07` にバッチがsafeとなり、それを含むL1ブロックが `12:20` にfinalizedとなります。ブリッジ出金が `14:00` に証明され、例示的な成熟期間が `7-day` なら、最短の解放時刻は翌週の `14:00` ですが、ゲーム、一時停止、L1の状態に左右されます。`12:20` のL2トランザクションのファイナリティとブリッジ解放は同じ事象ではありません。 - **ブリッジ後の実行可能価値。** 利用者が `1,000 USDC` を入金し、プロトコル手数料 `2 USDC` の控除後にL2で `998 USDC` を受け取り、送付元gas費用 `$7.50` は別に支払ったとします。受取トークンの約定可能な買値が `$0.995`、価格インパクトが `0.20%`、退出gas費用が `$3` なら、正味退出価値は `998 * 0.995 * (1 - 0.002) - 3 = $988.02398` です。`$1,000` に対する不足は `$11.97602`、すなわち `1.197602%` です。L2という呼称だけでなく、トークンの同一性、ブリッジ上の請求権、流動性が重要です。 ## リスク - 誤ったL1、L2、チェーンID、デプロイ、フォーク、プロトコルバージョンを使う。 - L2というマーケティング上の呼称を標準化された安全分類とみなす。 - サイドチェーン、Validium、チャネル、カストディ型台帳をロールアップと混同する。 - 偽のRPC、エクスプローラー、ブリッジ、トークン、コントラクトアドレスを信頼する。 - シーケンサーによる検閲、矛盾した応答、停止、非公開順序付けの悪用。 - バッチデータまたは導出データの欠落や遅延。 - 外部DAまたは委員会によるデータ秘匿、障害、共謀。 - 無効な状態コミットメント、または証明システム、ゲーム、検証器の不具合。 - 提案者、証明者、異議申立人、中継者のライブネス障害。 - L1の混雑、検閲、再編成、ファイナリティ遅延。 - unsafe、safe、finalized、証明済み、出金可能の各状態を混同する。 - 強制取り込みまたは退出経路が停止され、高コストになり、あるいは利用不能になる。 - プロキシを即時アップグレードできる、または利用者の退出猶予が不十分である。 - 管理者、ガーディアン、セキュリティ評議会の鍵が侵害される。 - ブリッジのエスクロー、トークン対応付け、小数桁、表現形式が破綻する。 - 見積りからデータ、実行、運営者、ブリッジ、送付先の費用が漏れる。 - 容量、レート制限、混雑、スリッページ、gasトークン不足。 - EVM互換を、opcode、precompile、安全規則まで同一だと誤認する。 - L2間メッセージで、より弱いファイナリティ、ブリッジ、依存関係の前提が合成される。 - ウォレット上の成功、高TPS、低手数料を安全性や経済的ファイナリティと取り違える。 ## よくある誤解 - Layer 2を名乗るネットワークはすべて、Ethereumの安全性を全面的に継承する。 - シーケンサー確認は、L1に裏付けられたファイナリティと同じである。 - 妥当性証明またはフォールトプルーフが、データ可用性と検閲を自動的に解決する。 - ロールアップの証明システムが、すべてのブリッジトークンとアプリケーションも保証する。 - 低手数料または高TPSが、分散性、支払能力、実行可能な退出を証明する。 ## 関連トピック - [ロールアップ](/ja/crypto/rollup/) - [データ可用性](/ja/crypto/data-availability/) - [ロールアップのエスケープハッチ](/ja/crypto/rollup-escape-hatch/) ## 出典 - [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org（参照日: 2026-08-12） - [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org（参照日: 2026-08-12） - [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org（参照日: 2026-08-12） - [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org（参照日: 2026-08-12） - [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（参照日: 2026-08-12） - [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification（参照日: 2026-08-12） - [Transaction finality](https://docs.optimism.io/op-stack/transactions/transaction-finality) - Optimism Documentation（参照日: 2026-08-12） - [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification（参照日: 2026-08-12） Source: https://wiki.fcontext.com/ja/crypto/layer2/index.mdx