---
title: "データ可用性委員会（DAC）のリスク"
description: "DACの証言、q-of-n受入れ規則、実際のデータ保有と取得、相関する障害領域、鍵のローテーション、保持、代替経路、退出リスクを検証優先で解説するガイド。"
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.

# データ可用性委員会（DAC）のリスク

> 教育目的に限られ、投資またはセキュリティ上の助言ではありません。DAC証明書がコントラクトの規則を満たしていても、データ保管、取得、ガバナンス、代替経路、復旧、退出は失敗する可能性があります。

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

## 直接の答え

データ可用性委員会とは、限られた範囲のメンバーで構成され、その署名または証言がオフチェーンのデータ可用性に関する主張を受け入れるプロトコル規則を満たし得る集合である。証明書が示すのは、設定されたキーセットと閾値が、その規則に従って特定の署名対象を受け入れたことだけである。各署名者が完全なバイト列を取得したこと、耐久性のある複製を保持したこと、現在利用者に提供していること、実行を検証したこと、または決済をファイナライズしたことを独立に証明するものではない。

安全性とライブネスは異なる。コントラクトが `q-of-n` の署名を受け入れる場合、別の検査で阻止されない限り、有効な鍵を `q` 個支配すれば、利用不能な対象でも受入れ規則を満たせる可能性がある。署名する意思があり到達可能なメンバーが `q` 名未満なら、通常は新しい証明書を作成できず、更新は停止するか、文書化された代替経路を使う。実際の復旧には、誠実な署名前検査、独立した複製、保持期間、提供能力、鍵とガバナンスの履歴、実行可能な再構築・退出ソフトウェアも必要となる。

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

## 仕組み

1. デプロイを固定する。チェーン、プロトコルのモードとバージョン、決済コントラクトと可用性検証コントラクト、バッチとデータ対象、符号化、コミットメント、キーセット、閾値 `q`、メンバー数 `n`、必須署名者、有効化、満了、失効、ガバナンス権限を特定する。
2. 正確な署名対象と受入れロジックを再構築する。ドメイン、チェーンとコントラクトへの結び付き、バッチ識別子、コミットメントまたは状態ルート、満了、署名者ビットマップまたは集約、リプレイ防止、コントラクトが実際に行う閾値計算を検証する。メンバーのロゴやAPI応答は受入れ規則ではない。
3. 各メンバーに対し、署名前に完全な対象を取得し、コミットメントと符号化を検証し、復号し、独立した状態導出または利用者の退出に必要なデータを保存するよう求める。メンバーが何を証言するのか、これらの検査が実施されたことをプロトコルが証明できるかを記録する。
4. 名称を数えるのではなく、独立した障害領域を整理する。法人、実質的支配、クラウドのアカウントとリージョン、DNSとネットワーク、ソフトウェアとデータベースの構成、鍵の保管、ストレージ基盤、運用、法域を特定する。一つの制御基盤の背後にあるミラーやエンドポイントは独立したメンバーではない。
5. 保有と取得を試験する。運営者のAPIを使わず、複数のメンバーから最近および過去のバッチを取得し、ハッシュとルートを検証し、状態または出金証明を再構築し、保持期間と送信能力を測定する。証明書の作成、現在の取得可能性、実行の有効性、コンセンサスのファイナリティ、アーカイブの耐久性を区別する。
6. ライフサイクルと復旧を演習する。メンバーと鍵のローテーション、過去のキーセット、満了と失効、閾値未満の可用メンバー、閾値分の鍵の侵害、選択的提供、運営者停止、完全データ公開への切替え、凍結またはエスケープモード、強制包含、独立アーカイブ、実際の退出に必要なGasと時間を検証する。
7. 受け入れられた署名者ビットマップ、証明書の遅延、取得成功率、バイト列の完全性、保存期間、キーセットと閾値の変更、アップグレード、一時停止、代替経路の容量を監視する。証明書、データ、コントラクト状態をアーカイブし、証明書は受け入れられていても独立した取得または復旧が機能しなくなった場合は、エクスポージャーの追加を止める。

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

## 例

- **閾値のライブネスと安全性は同じではない。** 単純化した `5-of-7` 委員会では、2名が利用不能でも `5` 名の署名者が残り、新しい証明書を作成できる。3名が利用不能なら残るのは `4` 名であり、`4 < 5` のため、文書化された代替経路が適用されない限り証明書の作成は停止する。一方、受け入れられる鍵を `5` 個支配すれば閾値規則を満たせる。証明書は、それでも現在バイト列を取得できることや実行が有効であることを証明しない。
- **独立オンラインモデル。** IIDの簡易モデルに限り、`7` 名の各メンバーが `0.95` の確率で独立に利用可能であり、証明書には少なくとも `5` 名が必要と仮定する。このとき `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570` であり、モデル上の停止確率は `1 - 0.9962429570 = 0.0037570430` となる。クラウド、ソフトウェア、運営者、法的主体、鍵に共通の依存関係があれば、この二項分布による推定は無効になる。
- **保存複製と提供能力は別である。** あるバッチが `120 MB` だとする。完全かつ独立した7つの複製は `120 * 7 = 840 MB` を保存する。実際に永続保存したメンバーが3名だけなら、5個の鍵が署名していても保存量は `120 * 3 = 360 MB` にすぎない。その対象を `100 clients` に1回ずつ提供すると `120 * 100 = 12,000 MB` を送信するため、署名数は複製数でも送信容量の尺度でもない。
- **再構築閾値。** 単純化した対象に `1,024 records` があり、それを `16 chunks` に分割し、各チャンクが `64 records`、所定の復旧閾値が `12 chunks` だとする。11チャンクから見えるのは `11 * 64 = 704 records` だが、`11 < 12` なので、この規則では対象を再構築できない。有効な委員会証明書は欠けたチャンクの代わりにはならず、復旧閾値も変更しない。

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

## リスク

- 誤ったチェーン、コントラクト、デプロイ、バッチ、またはプロトコルバージョンを調べる。
- 誤った署名対象、ドメイン、コミットメント、または満了を再構築する。
- チェーン、コントラクト、バージョン、または過去のキーセットをまたぐリプレイを受け入れる。
- 無効、古い、満了済み、または失効済みのキーセットを使う。
- `q`、`n`、必須署名者、ビットマップ、または集約署名を読み違える。
- 署名者またはコントラクトの検証実装の不具合を悪用される。
- 完全なデータ取得、完全性検査、永続保存の前に署名する。
- 不完全、不正な形式、または誤って符号化されたデータを受け入れる。
- 閾値分の鍵の侵害または共謀によって安全性を失う。
- 署名可能なメンバーが閾値未満となりライブネスを失う。
- 相関する法人、クラウド、リージョン、または運営者を独立と数える。
- DNS、TLS、ソフトウェア、データベース、またはストレージの制御基盤を共有する。
- エクリプス攻撃、選択的提供、または非公開ゲートウェイへの依存に陥る。
- 署名後、または退出期間の終了前にデータを削除またはプルーニングする。
- メンバー交代または鍵のローテーションによって過去の取得ができなくなる。
- ガバナンスがメンバーを置換し、閾値を下げ、または遅延を迂回する。
- 古い、安全でない、または再編成された決済コミットメントを参照する。
- 有効性証明またはファイナライズ済みのルートを、現在のデータ取得可能性とみなす。
- 代替経路、凍結、強制包含、または退出が実行不能だと判明する。
- 保存、送信、復旧、代替経路、手数料、容量の費用を過小評価する。

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

## よくある誤解

- 委員会のメンバーが多ければ、独立した障害領域も自動的に増える。
- `q` 個の署名は、公開取得できる耐久的な完全複製が `q` 個存在することを証明する。
- 有効性証明があれば、DACのデータ可用性を検証する必要はない。
- 過去の有効な証明書は、現在の取得可能性と恒久的なアーカイブを保証する。
- 誠実または公式のメンバーが1名いれば、すべての利用者が常に退出できる。

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

## 関連トピック

- [データ可用性](/ja/crypto/data-availability/)
- [ロールアップ](/ja/crypto/rollup/)
- [ファイナリティ](/ja/crypto/finality/)

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

## 出典

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org（参照日：2026-08-13）
- [Validium](https://ethereum.org/developers/docs/scaling/validium/) - Ethereum.org（参照日：2026-08-13）
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation（参照日：2026-08-13）
- [starkex-data-availability-committee](https://github.com/starkware-libs/starkex-data-availability-committee) - StarkWare Industries Ltd.（参照日：2026-08-13）
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs（参照日：2026-08-13）
- [SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol) - Offchain Labs（参照日：2026-08-13）

Source: https://wiki.fcontext.com/ja/crypto/data-availability-committee-risk/index.mdx