---
title: "モジュラー型ブロックチェーンのアーキテクチャ"
description: "実行、順序付け、データ可用性、コンセンサス、決済、証明、ブリッジ、ガバナンス、アーカイブの分担を依存関係から分析します。"
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.

# モジュラー型ブロックチェーンのアーキテクチャ

> 教育目的の情報であり、プロトコル、ブリッジ、セキュリティに関する助言ではありません。モジュラーという名称だけでシステムの保証は決まりません。対象バージョンと資産について、導入済みの各コンポーネント、データ経路、証明、時間軸、管理者、ブリッジ、復旧経路を確認してください。

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

## 直接の答え

モジュラー型ブロックチェーンのアーキテクチャとは、システムが責務をどう割り当てるかを分析する方法であり、標準化された製品分類ではありません。実行、トランザクションの順序付け、状態コミットメント、証明または異議申立て、データ公開とコンセンサス、決済、ブリッジ、ガバナンス、長期アーカイブは、一つのプロトコルにまとめることも、複数のシステムに分けることも、複数の提供者で重複させることもできます。一つのレイヤーが複数の責務を担い、一つの責務が複数のレイヤーに依存する場合もあります。

したがって有用な問いは、プロジェクトが「モジュラー」かどうかではなく、どのコンポーネントが何を検証し、誰が制御し、停止時に何が起こり、利用者が状態や資産を独立して復旧できるかです。シーケンサーのレシートはデータ可用性でもファイナリティでもありません。有効性証明はデータを提供せず、決済チェーン上のコミットメントは永続的な検索可能性を証明しません。決済を共有しても、ロールアップ間の同期的コンポーザビリティは生まれません。

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

## 仕組み

1. 導入済みシステムを固定します。実行チェーンと決済チェーンのID、プロトコルバージョン、仮想マシン、コントラクト、ブリッジと資産のアドレス、データ可用性方式、運営者、管理者、観測ブロックまたは時刻を記録します。マーケティング上の分類を実際の構成の代わりにしません。
2. 責任分担表を作ります。トランザクションの受付と順序付け、決定論的実行、状態コミットメントと証明またはフォールト争議、DA公開とそのコンセンサス、決済での受理とファイナリティ、ブリッジとクロスドメインメッセージ、アップグレードと一時停止、履歴保存を分けます。一つの責務を一つのレイヤーに無理に当てはめず、重複も記録します。
3. 一つのトランザクションとバッチを端から端まで追跡します。署名済み入力、シーケンサーまたはローカルのレシート、順序どおりの実行、エンコード・圧縮したバッチ、calldata・Blob・外部DAへの公開、状態主張と証明または争議、決済ファイナリティ、最後にメッセージまたは引き出しの実行です。各境界でハッシュ、バージョン、レシート、時間軸を保存します。
4. 検証対象と信頼仮定を特定します。データコミットメントと実データ、プロトコル期間中の可用性と後日の検索可能性、実行の有効性とコンセンサスファイナリティ、ブリッジ会計と資産流動性を区別します。各対象を誰が再実行、証明、異議申立て、検閲、アップグレード、一時停止、秘匿できるかを明記します。
5. 容量と手数料の台帳を再構築します。生データと圧縮後のバイト数、バッチ充足率、DA価格、証明と決済の共通費用、実行・運営手数料、ブリッジgasと流動性手数料を測定します。バッチ平均配賦額は利用者の実際の請求額でも、トランザクションを一件追加する限界費用でもありません。
6. 通常時のスループットだけでなく障害を演習します。シーケンサー、バッチ投稿者、証明者、チャレンジャー、DAサービス、決済RPC、ブリッジリレーを停止し、混雑時やアップグレード境界で強制取り込み、独立導出、データ復元、証明または異議申立て、再試行、退出、アーカイブ復旧を試します。
7. 正規の証拠と照合します。実行レシートと状態ルートを、バッチコミットメント、DAへの取り込み、証明または争議ゲームの状態、決済ファイナリティ、ブリッジメッセージ、最終資産残高と突き合わせます。再編成、パラメータ変更、コントラクトのアップグレード、DA移行の後には依存関係を再点検します。

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

## 計算例

- **バッチ費用と圧縮。** バッチに `5,000` 件のトランザクション、`2,400 KB` の生入力があり、圧縮後は `300 KB` です。圧縮率は `2,400 / 300 = 8.0x`、バイト数の減少は `87.5%` です。DA費用が `0.020 ETH`、共有する証明・決済費用が `0.005 ETH` なら、共有平均費用は `(0.020 + 0.005) / 5,000 = 0.000005 ETH/tx` です。実行・運営費用の `0.000020 ETH/tx` を加えると、総平均は `0.000025 ETH/tx` です。これは配賦額であり、保証された請求額ではありません。
- **サンプリングモデルの境界。** 教材用モデルで攻撃者がshareの `25%` を秘匿し、クライアントが復元抽出による独立一様サンプルを `20` 回取るとします。秘匿shareを一度も引かない確率は `0.75^20 = 0.003171211939 = 0.3171211939%`、検出確率は `99.6828788061%` です。ピア間の相関、適応的なデータ提供、消失訂正符号、実際のプロトコルのサンプリング規則により、この単純モデルは成立しない場合があります。
- **委員会の安全性と活性。** `5-of-7` のDA委員会は、利用不能なメンバーが最大 `2` 人なら新しい閾値証明を作れます。`3` 人が利用不能なら残るのは `4 < 5` 人です。署名だけを考える教材用規則では、権限を持つ署名者 `5` 人を支配すれば閾値を満たせます。それでも証明書は、耐久性のあるコピーが五つ存在すること、利用者が現在データを取得できること、実行と決済が有効であることを証明しません。
- **複数の時間軸と高速退出。** 教材上の暫定確認が `2 seconds` 後、バッチ公開が `8 minutes` 後、さらに `13 minutes` 後に決済がファイナライズされる場合、正確な経過時間は `21 minutes 2 seconds` です。楽観的引き出しに仮定上の `7 days` が加わるなら、合計は `10,101 minutes 2 seconds` です。高速ブリッジが `0.15%` の料率で `10,000 USDC` を扱うと、手数料は `15 USDC`、受取額は `9,985 USDC` です。高速化はプロトコルの時間軸を短くするのではなく、ブリッジ、流動性提供者、再編成に関する仮定を追加します。

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

## リスク

- 実際の責務またはレイヤー境界を誤認する。
- シーケンサーによる検閲、並べ替え、停止。
- 強制取り込みが利用不能、許可制、または遅すぎる。
- バッチ投稿者または状態提案者の停止。
- 集中型証明者の障害または証明の滞留。
- 稼働中で適格かつ十分な資金を持つフォールトチャレンジャーがいない。
- 争議ゲームの時間軸、bond、オラクル、検証ロジックの障害。
- 有効性回路、証明システム、検証鍵の不具合。
- 必要な可用期間中のデータ秘匿。
- 相関したサンプリング、エクリプス、ネットワークビューの障害。
- DA委員会の閾値共謀または鍵侵害。
- プロトコル上利用可能だったデータに耐久性のある独立アーカイブがない。
- 決済レイヤーの再編成またはファイナリティの誤分類。
- ブリッジ、メッセンジャー、リプレイ、宛先実行の障害。
- 高速ブリッジの債務超過、在庫不足、不利な価格設定。
- 管理者、マルチシグ、セキュリティ評議会の侵害。
- 即時アップグレード、非互換バージョン、不十分な退出猶予。
- DA手数料急騰、Blob混雑、バッチ縮小、補助金終了。
- 状態、データ、証明、コントラクト、クライアントのバージョン不一致。
- 非同期クロスドメインの順序、部分完了、コンポーザビリティの障害。

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

## よくある誤解

- モジュラー型アーキテクチャはモノリシック設計より必ず分散化されている。
- 有効性証明はデータ可用性と履歴検索を置き換える。
- Ethereumで決済すれば、すべてのコンポーネントがEthereumの全セキュリティ特性を受け継ぐ。
- シーケンサーの成功表示は、決済の完了と引き出し可能性を意味する。
- TPSの向上、DA共有、決済共有は、低コストと同期的コンポーザビリティを保証する。

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

## 関連トピック

- [レイヤー2](/ja/crypto/layer2/)
- [データ可用性](/ja/crypto/data-availability/)
- [ロールアップ](/ja/crypto/rollup/)

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

## 出典

- [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org（参照日：2026-08-13）
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org（参照日：2026-08-13）
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org（参照日：2026-08-13）
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org（参照日：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）
- [LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts](https://arxiv.org/abs/1905.09274) - arXiv（参照日：2026-08-13）

Source: https://wiki.fcontext.com/ja/crypto/modular-blockchain/index.mdx