🌅
Sunrise日本語
  • Home
    • 👋Sunrise
  • 📜Learn
    • 🌆Sunrise
      • Proof of Liquidity
      • DA Fee Abstraction
      • Data Availability
      • Gauges Voting
      • Liquidity Pool
      • Liquidity Incentive
      • Swap
      • TokenConverter
      • Fee
      • Lockup Account
    • 💴$RISE
      • Allocations
    • 🏦Gluon
    • 💴$GLU
    • 🎓Thesis
      • App chain thesis
      • Interoperability
  • 🛠️Build
    • Client
    • L2 Blockchains
      • Rollkit
        • Sunrise Data
        • Rollkit L2 Chain
      • OP Stack
        • Sunrise Data
        • OP Stack L2 Chain
    • Validators
      • Proof of Data Availability
      • Self Delegation
  • 🏗️Run a Sunrise Node
    • Networks
    • Types of Nodes
      • Consensus
        • Full Consensus Node
        • Validator Node (Genesis)
        • Validator Node
        • Setup Cosmovisor
      • IBC Relayers
    • Resources
      • Upgrade
      • Environment
  • 🏗️Run a Gluon Node
    • Networks
    • Node
      • Validator Node
  • 🔗Links
    • GitHub
    • Discord
    • X (Twitter)
    • Medium
    • dev.to
  • 📓Deprecated (UnUniFi)
    • IBC Channels
    • Security
    • CosmWasm
      • Tutorial
      • Create Project
    • IYA Strategy
      • Interface
      • External CosmWasm chain with IBCHooks
      • External EVM chain with Axelar
    • Frontend
      • Cosmos Client TS
    • Resources
    • Setup ununifid
    • ununifid
      • Basic Commands
      • Module Commands
        • wasm
    • Build a Node
    • Build a Validator Node
    • Setup Cosmovisor
    • Mainnet Upgrades
    • IBC Relayer
GitBook提供
このページ内
  • Sunrise v2の主な特徴
  • 他のDAレイヤーの設計パターン
  • データ可用性委員会
  • データ可用性サンプリング
  • Sunriseの設計
  • 証明のフロー
  • Sunrise v2の利点
  • ゼロ知識証明の仕様
  • 用語と表記
  • 概要
  • ゼロ知識証明システム
  • データ可用性の条件
  • 表記
  • 各シャードがデータ可用性を証明するための要件
  • データ可用性を証明するための集計要件
  • 各バリデーターに対するスラッシング条件
  • オンチェーンDA証明とオフチェーンDA証明の比較
  • データ破損耐久性
  • Txメンプールスケーラビリティ
  • データ取得可能性制御
  • バリデーター負荷軽減
  • 偽陽性DA証明耐性
  1. Learn
  2. Sunrise

Data Availability

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

Sunrise v2の主な特徴

Sunrise v2のいくつかの強化により、スループット、分散化、長期的なデータ取得可能性が向上します:

  • オフチェーンイレージャーエンコーディング: BLOBデータはオフチェーンでイレージャーコード化され、バリデーターの計算負荷とストレージ負荷を最小限に抑えます。

  • オフチェーンストレージ統合: IPFSやArweaveなどの分散型ストレージソリューションを活用し、データシャードは外部に保存されます。MsgPublishDataにはこれらのイレージャーコード化されたデータシェアを指すメタデータURIのみが含まれ、Blobトランザクションのオンチェーンブロックサイズ要件を削減し、スケーラビリティを向上させます。

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

データ可用性委員会

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

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

データ可用性サンプリング

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

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

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

Sunriseの設計

DACとDASのこれらの問題に対処するために、Sunrise v2は次のソリューションを実装しています:

  1. オフチェーンイレージャーエンコーディング:Blobデータはバリデーターの負荷を軽減するためにオフチェーンプログラムでイレージャーコーディングのために処理されます。

  2. BLOBデータシャーディング:ブロック全体のデータではなく各BLOBデータがイレージャーコーディングのために処理されます。クライアントはデータ全体をダウンロードすることなく、シャードをダウンロードする作業を繰り返すだけで各BLOBデータのデータ可用性を検証できます。クライアントはまた、マークルツリー構造を使用してブロック内のBLOBの包含を検証できます。

  3. 外部ストレージ:Blobデータは、IPFSやArweaveなどの分散型ストレージプラットフォームに保存されます。オンチェーンにblobデータを含めるのではなく、MsgPublishDataはイレージャーコード化されたデータシェアを指すメタデータURIを保持します。

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;
}

証明のフロー

提出されたデータは次のいずれかのステータスを持ちます

  1. CHALLENGE_PERIOD

  2. CHALLENGING

  3. VERIFIED

  4. REJECTED

  • CHALLENGE_PERIOD 提出された後、一定期間このステータスのままとなります。閾値を超えるMsgInvalidityでシャードが提出された場合、CHALLENGINGに変わります。そうでなければ、VERIFIEDになります。

  • VERIFIED データのMetadataUriはブロックに取り込まれ、外部から参照できるようになります。

  • REJECTED データはバリデーターの検証の結果、無効であると判断されました。データはブロックに取り込まれません。

Sunrise v2の利点

  • ネットワークスループットの向上: オンチェーンストレージの必要性を減らすことで、より大きなブロックサイズが達成可能になります。

  • データ取得可能性の向上: データをオフチェーンに保存することで、柔軟で長期的なデータ保持が可能になります。

  • ネットワーク分散化の改善: バリデーターの負荷を軽減することで、Sunriseはより分散化されたネットワーク構造をサポートします。

sequenceDiagram
    autonumber
    User ->> Publisher Node: BLOB data
    Publisher Node --> Publisher Node: Erasure coding
    Publisher Node ->> Decentralized Storage: Upload data shards
    Publisher Node ->> Sunrise: MsgPublishData
    Sunrise ->> Validator Set: Start Vote Extension
    Validator Set ->> Sunrise: Vote Data Availability
    Publisher Node ->> Sunrise: Fraud Challenge if it is needed
    Validator Set ->> Sunrise: Zero Knowledge Validity Proof if challenge is submitted

ゼロ知識証明の仕様

用語と表記

概要

ゼロ知識証明システム

公開入力

秘密入力

回路制約

データ可用性の条件

表記

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

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

パラメータ例

    • 10データシャード

    • 10パリティシャード

  • 各バリデーターは6シャードの証明を提出します

ケースA: 有効なシャード s_1

ケースB: 無効なシャード s_2

ケースX: シャード s_1、s_3-s_11 は上記の条件で有効

ケースY: シャード s_1、s_3 のみが上記の条件で有効

各バリデーターに対するスラッシング条件

オンチェーンDA証明とオフチェーンDA証明の比較

オンチェーンDA証明
オフチェーンDA証明

データ破損耐久性

〇

〇

Txメンプールスケーラビリティ

×

〇

データ取得可能性制御

×

〇

バリデーター負荷軽減

×

〇

偽陽性DA証明耐性

〇

〇※

例

Celestia、Avail、EigenDA、Sunrise V1

Sunrise V2、Walrus、0G

データ破損耐久性

オンチェーンとオフチェーンの両方のDA証明において、_データ破損耐久性_はシステムがデータの破損を検出および防止する能力を指します。

CelestiaやSunrise V1のようなオンチェーン証明は、データが直接オンチェーンに保存されるため、データの耐久的な可用性を確保し、データの改ざんや損失はバリデーターによって即座に検出されます。

オフチェーン証明(例えば、Sunrise V2)は外部システム(IPFSやArweaveなど)に依存しますが、イレージャーコーディングとゼロ知識証明を通じてデータの整合性を検証することで、同様の耐久性を達成することができます。

Txメンプールスケーラビリティ

_トランザクションメンプールスケーラビリティ_はオンチェーンDAシステムにおける主要な制限です。BLOBデータのサイズが大きくなるにつれて、一時的に保留中のトランザクションを保持するトランザクションメンプールが過負荷になり、スループットとスケーラビリティを制限する可能性があります。

オフチェーンDAシステムでは、大量のデータを外部に保存し、必要なハッシュやメタデータのみをオンチェーンに保存することで、この制限が軽減されます。これにより、メンプールを混雑させることなくより大きなスケーラビリティと大量のデータを処理する能力が可能になります。

データ取得可能性制御

オンチェーンDAシステムでは、_データ取得可能性_はしばしばコンセンサスメカニズムに結びついており、これはデータがコンセンサス(例えば、不正証明や有効性証明)に必要な限り利用可能である必要があることを意味します。しかし、コンセンサスが確定すると、長期的なデータ取得可能性は常に保証されるわけではありません。

Sunrise V2のようなオフチェーンDAシステムは、データが分散型ストレージシステム(IPFSやArweaveなど)に保存されるため、データ取得可能性に対してより柔軟な制御を提供します。これにより、データのより長期的な保持とデータがアクセス可能である期間の制御が向上します。

バリデーター負荷軽減

オンチェーンDA証明は、バリデーターが直接オンチェーンでデータ可用性を検証する責任を負うため、バリデーターに_より重い負荷_をかけます。トランザクションサイズが大きくなるにつれて、バリデーターの計算およびストレージ要求が増加し、分散化を制限する可能性があります。

対照的に、オフチェーンDA証明は、データストレージと取得を外部システムにアウトソーシングすることで、バリデーターの負荷を大幅に軽減します。バリデーターはイレージャーコーディングとゼロ知識証明を通じてデータシャードの可用性を検証するだけでよく、これにより処理とストレージの要件が軽減されます。

偽陽性DA証明耐性

_偽陽性DA証明_とは、実際にはデータが利用可能でない場合に、システムが誤ってデータが利用可能であると証明する状況を指します。

CelestiaやSunrise V1のようなシステムで使用されるオンチェーンDA証明は、すべてのデータが直接オンチェーンに保存され検証されるため、データが利用可能でない場合に誤って主張することが困難であり、偽陽性に対する強い耐性を持っています。

Sunrise V2などのオフチェーンDA証明では、ゼロ知識証明やイレージャーコーディングなどの暗号学的コミットメントの使用により、偽陽性耐性が維持されます。シャードデータのダブルハッシュ値を検証することで、バリデーターはデータセット全体を保存または直接アクセスする必要なく、データが確かに利用可能であることを確保できます。

ただし、_オフチェーンストレージソリューション_や_ネットワークレイテンシー_が偽陽性証明の機会を導入する可能性があるエッジケースが存在する可能性がありますが、これらは慎重な設計と検証プロセスの冗長性によって最小化されます。

前へDA Fee Abstraction次へGauges Voting

最終更新 1 か月前

データ可用性は楽観的な方法で証明されます。不正証明がSunriseネットワークに提出された場合、バリデーターはダブルハッシュされたシャードデータ(shard_double_hashes)を使用してゼロ知識証明(ZKP)を提出し、それを明らかにすることなくシャードデータの存在を検証できます。この統合はを通じて行われます。

CHALLENGING データが無効である可能性があります。バリデーターはデータが有効であることを検証し、証明を提出します。検証されたシャードが基準を満たせばVERIFIEDになり、そうでなければREJECTEDになります。 タリー方法はで説明されています。

ハッシュ関数: HHH

バリデーターの集合: VVV

データシャードの集合: SdS_dSd​

パリティシャードの集合: SpS_pSp​

シャードの集合: SSS

S=Sd∪Sp S = S_d \cup S_pS=Sd​∪Sp​

このシステムは H(si)H(s_i)H(si​) を露出することなく、データシャードハッシュ H(si)H(s_i)H(si​) の所有を検証します

回路は1つのシャード s∈Ss \in Ss∈S に対するものです。

H_public2(s)H\_{\text{public}}^2(s)H_public2(s)

H_private(s)H\_{\text{private}}(s)H_private(s)

Hpublic2(s)=H(Hprivate(s)) H_{\text{public}}^2(s) = H(H_{\text{private}}(s))Hpublic2​(s)=H(Hprivate​(s))

レプリケーション係数(データシャードのみに基づく): rrr

レプリケーション係数(パリティシャードを含む): rpr_prp​

rp=r∣Sd∣∣Sd∣+∣Sp∣ r_p = r \frac{|S_d|}{|S_d| + |S_p|}rp​=r∣Sd​∣+∣Sp​∣∣Sd​∣​

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

n=ceil(rp∣Sd∣+∣Sp∣∣V∣)=ceil(r∣Sd∣∣V∣) n = \text{ceil}\left( r_p \frac{|S_d| + |S_p|}{|V|} \right) = \text{ceil} \left( r\frac{|S_d|}{|V|} \right)n=ceil(rp​∣V∣∣Sd​∣+∣Sp​∣​)=ceil(r∣V∣∣Sd​∣​)

このシャードに関与するバリデーターからのシャード s に対する有効な証明の集合: ZsZ_sZs​

∣Zs∣rp≥23 \frac{|Z_s|}{r_p} \ge \frac{2}{3}rp​∣Zs​∣​≥32​

この条件を満たすシャードの集合: SavailableS^\text{available}Savailable

∣Savailable∣∣S∣≥∣Sd∣∣Sd∣+∣Sp∣⇒∣Savailable∣≥∣Sd∣\begin{aligned} \frac{|S^\text{available}|}{|S|} &\ge \frac{|S_d|}{|S_d| + |S_p|} \\ \Rightarrow |S^\text{available}| &\ge |S_d| \end{aligned}∣S∣∣Savailable∣​⇒∣Savailable∣​≥∣Sd​∣+∣Sp​∣∣Sd​∣​≥∣Sd​∣​

10バリデーター: v∗1,...,v∗10v*1 , ..., v*{10}v∗1,...,v∗10

20シャード: s∗1,...,s∗20s*1, ..., s*{20}s∗1,...,s∗20

r=6r = 6r=6

rp=6×1010+10=3r_p = 6 \times \frac{10}{10 + 10} = 3rp​=6×10+1010​=3

3×2010=63 \times \frac{20}{10} = 63×1020​=6

バリデーター v1v_1v1​、v3v_3v3​ および v9v_9v9​ の証明にはシャード s1s_1s1​ と他の5シャードが含まれています

バリデーター v3v_3v3​ はその証明内でシャード s1s_1s1​ の有効性を含めることに失敗しました

しかしバリデーター v1v_1v1​ と v9v_9v9​ はその証明内でシャード s1s_1s1​ の有効性を含めることに成功しました、そのため

∣Z_s1∣=2|Z\_{s_1}| = 2∣Z_s1​∣=2

これは ∣Z_s1∣rp≥23\frac{|Z\_{s_1}|}{r_p} \ge \frac{2}{3}rp​∣Z_s1​∣​≥32​ を満たします

バリデーター v∗2v*2v∗2、v4v_4v4​ および v∗10v*{10}v∗10 の証明にはシャード s2s_2s2​ と他の5シャードが含まれています

バリデーター v2v_2v2​ と v4v_4v4​ はその証明内でシャード s2s_2s2​ の有効性を含めることに失敗しました

バリデーター v_10v\_{10}v_10 だけがその証明内でシャード s2s_2s2​ の有効性を含めることに成功しました、そのため

∣Z_s2∣=1|Z\_{s_2}| = 1∣Z_s2​∣=1

これは ∣Z_s2∣rp≥23\frac{|Z\_{s_2}|}{r_p} \ge \frac{2}{3}rp​∣Z_s2​∣​≥32​ を満たしません

∣Savailable∣=10|S^\text{available}| = 10∣Savailable∣=10

∣Sd∣=10|S_d| = 10∣Sd​∣=10

これは ∣Savailable∣≥∣Sd∣|S^\text{available}| \ge |S_d|∣Savailable∣≥∣Sd​∣ を満たします

∣Savailable∣=2|S^\text{available}| = 2∣Savailable∣=2

∣Sd∣=10|S_d| = 10∣Sd​∣=10

これは ∣Savailable∣≥∣Sd∣|S^\text{available}| \ge |S_d|∣Savailable∣≥∣Sd​∣ を満たしません

関与するシャードに対するバリデーター v からの有効な証明の集合: ZvZ_vZv​

📜
🌆
ABCI 2.0の投票拡張
ゼロ知識証明の仕様