# Data Availability

Sunriseデータ可用性レイヤーは、高スループットのデータ可用性のために設計されており、アプリケーションに強化されたスケーラビリティと柔軟性を提供します。これを達成するために、SunriseはオフチェーンのBLOBデータを採用し、ブロックデータ全体ではなく、各Blobデータに対してErasure Codingを実行します。

`x/da`モジュールはこれらの機能を提供します。

## 主な特徴

SunriseのオフチェーンDA設計は、オンチェーンのセキュリティを犠牲にすることなく、比類のないスループットとコスト効率を実現します。

1. **オフチェーンのイレージャーエンコーディング** バリデーターの計算とストレージを劇的に削減します。オンチェーンには、これらのイレージャーコーディングされたデータ共有を指すメタデータURIのみがあり、完全なデータ再構築はオフチェーンで行われます。
2. **オフチェーンストレージ統合** IPFSやArweaveなどの分散型ストレージソリューションを利用して、データシャードは外部に保存されます。MsgPublishDataには、これらのイレージャーコーディングされたデータ共有を指すメタデータURIのみが含まれ、ブロブトランザクションのオンチェーンブロックサイズ要件を削減し、スケーラビリティを向上させます。

## DAの比較

|              | Sunrise             | Avail DA              | Celestia             | EigenDA   | Ethereum (EIP-4844) |
| ------------ | ------------------- | --------------------- | -------------------- | --------- | ------------------- |
| アーキテクチャ      | オフチェーンブロブを持つL1      | L1ブロックチェーン            | L1ブロックチェーン           | DAサービス    | L1ブロックチェーン（ブロブ）     |
| スループット       | 5+ MB/s             | 0.2 MB/s (4MB/ブロック)   | 1.33 MB/s (8MB/ブロック) | 15 MB/s   | 0.064 MB/s          |
| ファイナリティまでの時間 | 約4分 (7秒+240秒)       | 40秒                   | 6秒 + 10分             | 12分       | 12分                 |
| データストレージ     | オフチェーンブロブ           | オンチェーン                | オンチェーン               | 委員会ストレージ  | オンチェーンブロブ           |
| 証明メカニズム      | オフチェーンストレージによる楽観的証明 | 有効性証明 (KZG)           | 不正証明                 | 有効性証明     | 有効性証明               |
| 長期的な検索可能性    | シームレス               | ネイティブではない             | ネイティブではない            | ネイティブではない | ネイティブではない           |
| コストモデル       | 流動性による手数料の抽象化       | 直接手数料                 | 直接手数料                | 委員会手数料    | オンチェーンガス手数料         |
| コンセンサス       | プルーフ・オブ・リクイディティ     | Babe & Grandpa (NPoS) | Tendermint           | N/A       | Ghost & Casper      |

## 設計概要

### 他のDAレイヤーの設計パターン

1. **データ可用性委員会**

   データ可用性委員会（DAC）は、低コストで代替のデータ可用性レイヤーを構築するための従来の方法です。

   しかし、DACでは、クライアントが委員会によって証明されたデータ可用性が真か偽かを、ブロブデータ全体をダウンロードせずに検証することは不可能です。
2. **データ可用性サンプリング**

   データ可用性サンプリング（DAS）を採用するデータ可用性レイヤーでは、ブロックデータはイレージャーコーディングのために処理されます。その後、クライアントはブロックデータの一部をダウンロードするだけでデータ可用性を検証でき、マークルツリー構造を使用してブロック内のブロブデータの包含を検証できます。

   一般的なDASのセットアップでは、フルノードはmempool内のトランザクションデータを転送およびダウンロードする必要があります。

   ブロブデータのサイズが大きくなるにつれて、ネットワークのスループットはこれらのトランザクション転送によって制限される可能性があり、大きなブロブデータを扱うアプリケーションにとって課題となります。

### Sunriseの設計

DACとDASにおけるこれらの問題に対処するために、Sunriseは次の解決策を実装しています。

1. **オフチェーンのイレージャーエンコーディング** バリデーターの負荷を軽減するために、ブロブデータはオフチェーンプログラムでイレージャーコーディングのために処理されます。
2. **ブロブデータのシャーディング** ブロックデータ全体ではなく、各ブロブがイレージャーコーディングのために処理されます。クライアントは、データ全体をダウンロードすることなく、シャードのダウンロードを繰り返すだけで各ブロブのデータ可用性を検証できます。クライアントはまた、マークルツリー構造を使用してブロック内のブロブの包含を検証できます。
3. **外部ストレージ** ブロブデータは、IPFSやArweaveなどの分散型ストレージプラットフォームに保存されます。ブロブデータをオンチェーンに含む代わりに、MsgPublishDataはイレージャーコーディングされたデータ共有を指すメタデータURIを保持します。

   ```protobuf
   message MsgPublishData {
     option (cosmos.msg.v1.signer) = "sender";
     string sender = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
     string metadata_uri = 2;
     uint64 parity_shard_count = 3;
     repeated bytes shard_double_hashes = 4;
     string data_source_info = 5;
   }
   ```

   データ可用性は楽観的な方法で証明されます。Sunriseネットワークに十分な無効性の異議が提出された場合、バリデーターは二重ハッシュ化されたシャードデータ（`shard_double_hashes`）を使用してゼロ知識証明（ZKP）を提出し、バリデーターがシャードデータを明らかにすることなくその存在を検証できるようにします。

### 証明のライフサイクル

提出されたデータは、次のいずれかのステータスになります。

* **作成済み** → **異議申し立て期間** → **異議申し立て中** → **検証済み** / **拒否済み**
* **異議申し立て期間:** 提出後、データはこのステータスで一定期間維持されます。十分な無効性の異議が提出された場合、「異議申し立て中」に移行します。それ以外の場合は、「検証済み」になります。
* **異議申し立て中:** バリデーターはデータを検証し、証明を提出します。検証されたシャードが基準を満たす場合、「検証済み」になります。そうでない場合は、「拒否済み」になります。
* **検証済み:** メタデータURIがブロックに含まれ、外部から参照できます。
* **拒否済み:** データは無効と判断され、ブロックには含まれません。

{% @mermaid/diagram content="graph TD
A\[作成済み] --> B\[異議申し立て期間]
B -->|異議なし| C\[検証済み]
B -->|異議あり| D\[異議申し立て中]
D -->|有効| C
D -->|無効| E\[拒否済み]" %}

### 証明の流れ

{% @mermaid/diagram content="%%{init: {"theme": "default", "themeVariables": {
"background": "transparent",
"primaryColor": "#22223b",
"primaryTextColor": "#22223b",
"lineColor": "#22223b",
"textColor": "#22223b",
"actorBorder": "#22223b",
"actorTextColor": "#22223b",
"sequenceNumberColor": "#22223b",
"messageTextColor": "#22223b",
"signalColor": "#22223b"
}}}%%
sequenceDiagram
autonumber
User->>Publisher Node: ブロブデータ
Publisher Node->>Publisher Node: イレージャーコーディング
Publisher Node->>Decentralized Storage: データシャードをアップロード
Publisher Node->>Sunrise: MsgPublishData
User->>Sunrise: 必要に応じて不正チャレンジ
Sunrise->>Validator Set: 異議申し立ての投票を開始
Validator Set->>Sunrise: ゼロ知識有効性証明" %}

## ゼロ知識証明システム

### 用語と表記

* ハッシュ関数: $$H$$
* バリデーターのセット: $$V$$
* データシャードのセット: $$S\_d$$
* パリティシャードのセット: $$S\_p$$
* シャードのセット: $$S$$

$$
S = S\_d \cup S\_p
$$

### 概要

このシステムは、$$H(s\_i)$$を公開せずにデータシャードハッシュ$$H(s\_i)$$の所有を検証します。 この回路は、1つのシャード$ s \in S $用です。

1. 公開入力

   $$H\_{\text{public}}^2(s)$$
2. プライベート入力

   $$H\_{\text{private}}(s)$$
3. 回路制約

   $$
   H\_{\text{public}}^2(s) = H(H\_{\text{private}}(s))
   $$

## データ可用性の条件

### 表記

* レプリケーション係数（データシャードのみに基づく）: $$r$$
* レプリケーション係数（パリティシャードを含む場合に基づく）: $$r\_p$$

$$
r\_p = r \frac{|S\_d|}{|S\_d| + |S\_p|}
$$

* 各バリデーターが関与するシャードの数: $$n$$

$$
n = \text{ceil}\left( r\_p \frac{|S\_d| + |S\_p|}{|V|} \right) = \text{ceil} \left( r\frac{|S\_d|}{|V|} \right)
$$

### 各シャードがデータ可用性を証明するための要件

* このシャードに関与するバリデーターからのシャード`s`の有効な証明のセット: $$Z\_s$$

$$
\frac{|Z\_s|}{r\_p} \ge \frac{2}{3}
$$

* この条件を満たすシャードのセット: $$S^\text{available}$$

### データ可用性を証明するための集計の要件

$$
\begin{aligned}
\frac{|S^\text{available}|}{|S|} &\ge \frac{|S\_d|}{|S\_d| + |S\_p|} \\
\Rightarrow |S^\text{available}| &\ge |S\_d|
\end{aligned}
$$

#### パラメータの例

* 10人のバリデーター: $$v\_1 , ..., v\_{10}$$
* 20個のシャード: $$s\_1, ..., s\_{20}$$
  * 10個のデータシャード
  * 10個のパリティシャード
* $$r = 6$$
* $$r\_p = 6 \times \frac{10}{10 + 10} = 3$$
* 各バリデーターは6つのシャード証明を提出します
  * $$3 \times \frac{20}{10} = 6$$

#### ケースA：有効なシャード`s_1`

* バリデーター$$v\_1$$, $$v\_3$$および$$v\_9$$の証明には、シャード$$s\_1$$と他の5つのシャードが含まれます
* バリデーター$$v\_3$$は、証明にシャード$$s\_1$$の有効性を含めることに失敗しました
* しかし、バリデーター$$v\_1$$と$$v\_9$$は証明にシャード$$s\_1$$の有効性を含めることに成功したため、
  * $$|Z\_{s\_1}| = 2$$
  * $$\frac{|Z\_{s\_1}|}{r\_p} \ge \frac{2}{3}$$を満たします

#### ケースB：無効なシャード`s_2`

* バリデーター$$v\_2$$, $$v\_4$$および$$v\_{10}$$の証明には、シャード$$s\_2$$と他の5つのシャードが含まれます
* バリデーター$$v\_2$$と$$v\_4$$は、証明にシャード$$s\_2$$の有効性を含めることに失敗しました
* バリデーター$$v\_{10}$$のみが証明にシャード$$s\_2$$の有効性を含めることに成功したため、
  * $$|Z\_{s\_2}| = 1$$
  * $$\frac{|Z\_{s\_2}|}{r\_p} \ge \frac{2}{3}$$を満たしません

#### ケースX：シャードs\_1、s\_3-s\_11は上記の条件で有効です

* $$|S^\text{available}| = 10$$
* $$|S\_d| = 10$$
* $$|S^\text{available}| \ge |S\_d|$$を満たします

#### ケースY：上記の条件で有効なのはシャードs\_1、s\_3のみです

* $$|S^\text{available}| = 2$$
* $$|S\_d| = 10$$
* $$|S^\text{available}| \ge |S\_d|$$を満たしません

## パラメータ

| パラメータ                   | デフォルト     | 単位   | 説明                            |
| ----------------------- | --------- | ---- | ----------------------------- |
| publish\_data\_gas      | 1,000,000 | gas  | データ公開のガス代                     |
| challenge\_threshold    | 0.33      | 比率   | チャレンジ期間に入るために必要な無効性チャレンジのしきい値 |
| replication\_factor     | 5.0       | コピー  | データシャードのレプリカ数                 |
| slash\_epoch            | 120,960   | ブロック | スラッシュ判断のエポック期間（約1週間）          |
| slash\_fault\_threshold | 0.5       | 比率   | バリデーターのスラッシュを引き起こす無効な証明のしきい値  |
| slash\_fraction         | 0.001     | 比率   | スラッシュ中の投票力の削減率                |
| challenge\_period       | 4分        | 時間   | データ公開後のチャレンジ期間                |
| proof\_period           | 10分       | 時間   | チャレンジ後の証明提出期間                 |

## メッセージ

このモジュールは、さまざまなメッセージタイプを提供します。

* MsgUpdateParams：モジュールパラメータの更新（ガバナンス操作）
* MsgPublishData：メタデータURIとシャード情報を含むデータを公開
* MsgSubmitInvalidity：特定のインデックスのデータの無効性を報告
* MsgSubmitValidityProof：バリデーターから有効性証明を提出
* MsgRegisterProofDeputy：バリデーターの証明代理人を登録
* MsgUnregisterProofDeputy：証明代理人の登録を解除

## クエリ

このモジュールは、さまざまなクエリエンドポイントを提供します。

* Params：モジュールパラメータのクエリ
* PublishedData：特定のメタデータURIの公開データの詳細を取得
* AllPublishedData：すべての公開データを一覧表示
* ValidityProof：特定のバリデーターから有効性証明を取得
* AllValidityProofs：特定のメタデータURIのすべての有効性証明を一覧表示
* Invalidity：特定のメタデータURIと送信者の無効性レポートを取得
* AllInvalidity：特定のメタデータURIのすべての無効性レポートを一覧表示
* ValidatorShardIndices：特定のバリデーターのシャードインデックスを取得
* ZkpProofThreshold：特定のシャード数のZKP証明のしきい値を取得
* ProofDeputy：特定のバリデーターの証明代理人を取得

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/da)を参照してください。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ja.docs.sunriselayer.io/learn/sunrise/data-availability.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
