﻿---
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>

## 直接の答え

データ可用性とは、プロトコルが定める十分なデータが所定の期間内に公開され、想定される参加者が関連する状態を検証、導出、または再構築するために取得できることをいう。必要な対象は、取引入力、状態差分、符号化されたシェア、または別途定義されたバッチ形式であり得る。ウェブサイト、RPC エンドポイント、プロジェクト API が稼働しているというだけでは、データ可用性を意味しない。

四つの主張を分けて扱う必要がある。可用性は、プロトコルの利用者に対する適時の公開を問題にする。取得可能性は、特定の当事者が現在または将来、そのバイト列を取得できるかを問題にする。有効性は、状態遷移が規則または証明の制約に従っているかを問題にする。ファイナリティは、通常のプロトコル運用によってコンセンサスがそのコミットメントをなお置き換え得るかを問題にする。拘束力のあるコミットメント、KZG 証明、有効性証明、またはファイナライズされた包含のいずれも、それ単独で四つすべてを証明するものではない。また、一時的な可用性は恒久的なアーカイブではない。

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

## 仕組み

1. 測定の前に主張を定義する。対象となるバッチ、Blob、名前空間または符号化データ、プロトコルとバージョン、想定利用者、必要な導出・検証・退出作業、可用性・異議申立て・復旧の各期間を特定する。「完全なデータ」とは、そのプロトコルの下で作業に十分なデータであり、定義のない全取引の複製ではない。
2. 公開経路と証拠を固定する。決済チェーン、専用 DA チェーン、calldata、Blob sidecar、外部コミットメントまたは委員会証明書、ブロック・スロット・バッチの識別子、符号化と圧縮、コミットメント、それを利用するコントラクトまたはブリッジを記録する。ある場所への公開は、別の検証者がそれを確認する証拠にはならない。
3. 結び付きと再構築を独立に検証する。プロジェクトの API を使わずにバイト列を取得し、そのハッシュ、KZG その他のコミットメントと包含参照を検証する。フレーミングと消失訂正符号化を確認し、バッチを復号して状態導出に必要な入力を再現する。バイト列を得られず、有効なコミットメントだけがある状態は、再構築の成功ではない。
4. 受入れモデルを整理する。フルノードが対象をダウンロードするのか、ライトノードが認証済みシェアをサンプリングするのか、バリデーターに保管義務があるのか、データ可用性委員会が閾値証明書に署名するのかを記録する。サンプリング、消失訂正、ピアの独立性、閾値、ステーク、鍵、エクリプス攻撃に関する前提と、決済コントラクトまたはブリッジが実際に検証する内容を明示する。
5. 状態と時計を分けて追跡する。提出済み、包含済み、プロトコルの期間内で利用可能、独立クライアントが取得可能、復号または導出済み、実行上有効、安全、ファイナライズ済み、アーカイブ済みは別々の状態である。有効性証明が制約下の計算を確立しても、独立した導出や運用に必要なデータが利用不能な場合はある。
6. 保持、初期同期、経済性を測定する。プロトコル上の最低提供期間、プルーニングの挙動、アーカイブとスナップショットの提供者、新規ノードの要件、生および符号化後のバイト数、オーバーヘッド、単価、証明費用と取引費用、容量上限、補助金、代替経路の費用を記録する。一時的な DA の期限後に長期取得するには、追加の依存先が必要となる。
7. 障害を演習する。データ秘匿、選択的提供、相関またはエクリプス攻撃を受けたサンプル、委員会の機能喪失、DA の停止やフォーク、決済の再編成、フレーム欠落、アーカイブ喪失、シーケンサーの検閲、手数料急騰を試験する。実際のソフトウェア、データ、Gas を用いて、安全停止、強制包含、再試行、代替経路、再構築、退出が実行可能か確認し、コミットメント、レシート、独立アーカイブの証拠を保管する。

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

## 例

- **データ費用の単位を正しく扱う。** あるバッチが `400,000 bytes` を含み、`2,000 transactions` を処理し、単価が `$0.00002 per byte` だとする。DA データ料金は `400,000 * $0.00002 = $8 per batch`、すなわち `$8 / 2,000 = $0.004 per transaction` である。単価が 10 倍の `$0.00020 per byte` になると、費用は `$80 per batch` および `$0.040 per transaction` となり、`$0.04 per batch` ではない。実行、証明、取引オーバーヘッド、アーカイブ、余裕分の費用は含まない。
- **プロトコルの提供期間はアーカイブ保証ではない。** EIP-4844 の最低要求期間は `4,096 epochs` である。`32 slots per epoch`、`12 seconds per slot` とすれば、`4,096 * 32 * 12 = 1,572,864 seconds`、すなわち `1,572,864 / 86,400 = 18.2044444444 days` となる。これはこのモデルにおけるプロトコル上の下限であり、単一の提供者が特定の Blob を永久保存する保証ではない。
- **単純化したサンプリング確率。** あくまで簡易モデルとして、攻撃者が一様に抽出される拡張シェアの `50%` を秘匿し、認証済みサンプルを独立に復元抽出で `30` 回取ると仮定する。すべてのサンプルが秘匿領域を外す確率は `0.5^30 = 0.0000000009313225746` であり、検出確率は `99.9999999069%` となる。これは稼働中の PeerDAS その他のネットワークのサービス保証ではない。ピアの相関、偏ったサンプリング、符号化パラメーター、適応的攻撃によって結果は変わる。
- **委員会の閾値は現在の取得可能性と同じではない。** 仮想的な DA 委員会が `5-of-7` の署名を要求するとする。3 名が利用不能なら残るのは `4` 名であり、新しい閾値証明書は作成できない。`5 signatures` が付いた過去の証明書は、当時その規則に従って閾値数が証言したことを示すだけである。特定の利用者が現在バイト列を取得できること、実行が有効であること、または決済がファイナライズ済みであることは示さない。

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

## リスク

- 誤ったチェーン、バッチ、Blob、名前空間、またはプロトコルバージョンを調べる。
- コミットメントや証明書を基礎となるバイト列と混同する。
- 一つのエンドポイントから現在取得できることを、プロトコル全体の可用性とみなす。
- データ可用性を実行の有効性の証明とみなす。
- 可用性または有効性をコンセンサスのファイナリティとみなす。
- 古い、安全でない、または再編成された決済ブロックを参照する。
- データ取得前にプロトコルの保持期間が終了する。
- 単一のアーカイブ、スナップショット、インデクサー、またはプロジェクト API に依存する。
- 不正なフレーミング、圧縮、または消失訂正符号化を受け入れる。
- ハッシュ、KZG、その他のコミットメントを検証しない。
- 想定脅威モデルに対するシェアのサンプル数が不足する。
- サンプル、ピア、保管グループに相関があるのに独立と仮定する。
- エクリプス攻撃、偏ったピア選択、または選択的提供を受ける。
- 検証者と整合しない消失訂正パラメーターまたは再構築閾値を使う。
- 共謀または利用不能となるデータ可用性委員会に依存する。
- ブリッジまたは決済コントラクトが利用者の想定より弱い対象を受け入れる。
- シーケンサーによる秘匿、検閲、またはバッチフレーム欠落でデータを失う。
- DA の停止、フォーク、再編成、または互換性のないクライアント更新に遭遇する。
- 強制包含、代替経路、復旧、または退出が実際には実行できないと判明する。
- 容量、手数料急騰、オーバーヘッド、アーカイブ費用、または補助金終了を過小評価する。

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

## よくある誤解

- 有効性証明があればデータ可用性は不要になる。
- コミットメントまたは KZG 証明は、完全なバイト列を取得できたことを証明する。
- ファイナライズされた包含は、データが永久に取得可能であることを意味する。
- オンチェーン、Blob、専用 DA、サンプリングという表示があれば、自動的に同じ安全性が得られる。
- サンプル数の多さや費用の低さだけで、ある DA 設計が優れていると証明できる。

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

## 関連トピック

- [モジュラー・ブロックチェーン](/ja/crypto/modular-blockchain/)
- [ロールアップ](/ja/crypto/rollup/)
- [ZK ロールアップ](/ja/crypto/zk-rollup/)

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

## 出典

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org（参照日：2026-08-12）
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org（参照日：2026-08-12）
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（参照日：2026-08-12）
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals（参照日：2026-08-12）
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification（参照日：2026-08-12）
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification（参照日：2026-08-12）
- [Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities](https://arxiv.org/abs/1809.09044) - arXiv（参照日：2026-08-12）
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org（参照日：2026-08-12）

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