Доступность данных

Sunrise v2 разработан для обеспечения высокой пропускной способности данных, предлагая улучшенную масштабируемость и гибкость для приложений. Для достижения этого Sunrise принимает данные BLOB вне цепочки и выполняет Erasure Coding для каждого Blob-данных, а не для всего блока данных.

Основные характеристики Sunrise v2

Несколько усовершенствований в Sunrise v2 повышают пропускную способность, децентрализацию и возможность долгосрочного извлечения данных:

Кодирование со стиранием вне цепочки: данные BLOB кодируются со стиранием вне цепочки, что минимизирует вычислительную и накопительную нагрузку на валидаторы.
Интеграция офчейн-хранилища: используя децентрализованные решения для хранения, такие как IPFS и Arweave, фрагменты данных хранятся снаружи. MsgPublishData включает только URI метаданных, указывающий на эти закодированные стиранием общие данные, что снижает требования к размеру блока в цепочке для транзакций Blob и повышает масштабируемость.

Шаблоны проектирования других слоев DA

Комитет по доступности данных

Комитет по доступности данных (DAC) — это традиционный метод создания альтернативного уровня доступности данных с низкими затратами.

Однако в DAC клиенты не могут проверить, является ли подтвержденная комитетом доступность данных истинной или ложной, без загрузки всех данных BLOB.

Выборка доступности данных

В слоях доступности данных, которые принимают выборку доступности данных (DAS), данные блока обрабатываются для кодирования стирания. Затем клиенты могут проверить доступность данных, только загрузив часть данных блока, и могут проверить включение данных BLOB в блок, используя структуру дерева Меркла.

В типичной настройке DAS полные узлы должны передавать и загружать данные транзакций в пределах мемпула.

По мере роста размеров данных BLOB пропускная способность сети может быть ограничена этими транзакционными передачами, что создаст проблемы для приложений, обрабатывающих большие данные BLOB.

Дизайн Sunrise

Для решения этих проблем в DAC и DAS в Sunrise v2 реализованы следующие решения:

Кодирование стирания вне цепочки блоков: данные больших двоичных объектов обрабатываются для кодирования стирания в программе вне цепочки блоков, чтобы снизить нагрузку на валидатор.
Шардинг данных BLOB: не все данные блока, а каждый BLOB-данные обрабатываются для Erasure Coding. Клиенты по-прежнему могут проверить доступность данных для каждого BLOB-данного, только повторяя загрузку шардов, без загрузки всех данных. Клиенты также могут проверить включение BLOB в блок, используя структуру Merkle Tree.
Внешнее хранилище: данные BLOB-объектов хранятся на децентрализованных платформах хранения, таких как IPFS и Arweave. Вместо того, чтобы хранить данные BLOB-объектов в цепочке, MsgPublishData содержит URI метаданных, указывающий на закодированные стиранием общие данные.
Копировать
```
message MsgPublishData {
  option (cosmos.msg.v1.signer) = "sender";
  string sender = 1;
  string metadata_uri = 2;
  repeated bytes shard_double_hashes = 3;
}

message Metadata {
  uint64 shard_size = 1;
  uint64 shard_count = 2;
  repeated string shard_uris = 3;
}
```
Доступность данных подтверждается с помощью Optimistic way. Если доказательство мошенничества отправляется в сеть Sunrise, валидаторы отправят доказательства с нулевым разглашением (ZKP) с использованием дважды хэшированных данных шарда ( shard_double_hashes), что позволяет валидаторам проверять наличие данных шарда, не раскрывая их. Эта интеграция выполняется с помощью Vote Extension ABCI 2.0 .

Преимущества Sunrise v2

Увеличение пропускной способности сети: большие размеры блоков достигаются за счет сокращения потребностей в хранении данных в цепочке.
Улучшенная возможность извлечения данных: хранение данных вне сети обеспечивает гибкое и долгосрочное хранение данных.
Улучшенная децентрализация сети: за счет снижения нагрузки на валидатор Sunrise поддерживает более децентрализованную структуру сети.

Спецификация для доказательства с нулевым разглашением

Термины и обозначения

Функция хэширования:
Набор валидаторов:
Набор фрагментов данных:
Набор четных сегментов:
Набор осколков:

Обзор Эта система проверяет наличие хэша фрагмента данных

не подвергая

Zero-Knowledge Proof System

Схема рассчитана на один осколок

Общественные мнения

Частные вклады

Ограничения цепи

Состояние доступности данных

Обозначения

Фактор репликации (основан только на фрагментах данных): r
Фактор репликации (на основе включения сегментов четности): rp

Количество шардов, с которыми работает каждый валидатор: н

Требования к каждому сегменту для подтверждения доступности данных

Набор действительных доказательств для шарда `s`от валидаторов, задействованных в этом шарде:

Спецификация для доказательства с нулевым разглашением

Термины и обозначения

Функция хэширования:

HH H

Множество валидаторов:

VV V

Множество шардов данных:

SdS_d Sd

Множество шардов паритета:

SpS_p Sp

Множество всех шардов:

SS S

Объединение множеств шардов данных и паритета:

S=Sd∪SpS = S_d \cup S_p S=Sd∪Sp

Обзор

Описание: Эта система проверяет наличие хэша шарда данных, не раскрывая содержимое шарда. Формула:

H(si)H(s_i) H(si)

Система доказательства с нулевым разглашением

Эта схема предназначена для одного шарда. Обозначение:

s∈Ss \in S s∈S

Публичные входные данные

Хэш публичного ключа (в квадрате):

Hpublic2(s)H_{\text{public}}^2(s) Hpublic2(s)

Приватные входные данные

Хэш приватного ключа:

Hprivate(s)H_{\text{private}}(s) Hprivate(s)

Ограничения схемы

Связь публичного и приватного ключей через хэш:

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

Условие доступности данных

Обозначения

Коэффициент репликации (шарды данных):

rr r

Коэффициент репликации (включая паритет):

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

Количество шардов, в которых участвует каждый валидатор:

n=⌈rp⋅∣Sd∣+∣Sp∣∣V∣⌉=⌈r⋅∣Sd∣∣V∣⌉n = \lceil r_p \cdot \frac{|S_d| + |S_p|}{|V|} \rceil = \lceil r \cdot \frac{|S_d|}{|V|} \rceil n=⌈rp⋅∣V∣∣Sd∣+∣Sp∣⌉=⌈r⋅∣V∣∣Sd∣⌉

Требования для доказательства доступности данных

Множество валидных доказательств для шарда sss:

ZsZ_s Zs

Условие:

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

Множество шардов, удовлетворяющих условию:

SavailableS_{\text{available}} Savailable

Требования для подтверждения доступности данных

Отношение доступных шардов ко всем шарам:

∣Savailable∣∣S∣≥∣Sd∣∣Sd∣+∣Sp∣\frac{|S_{\text{available}}|}{|S|} \geq \frac{|S_d|}{|S_d| + |S_p|} ∣S∣∣Savailable∣≥∣Sd∣+∣Sp∣∣Sd∣

Минимальное количество доступных шардов:

∣Savailable∣≥∣Sd∣|S_{\text{available}}| \geq |S_d| ∣Savailable∣≥∣Sd∣

Пример параметров

Количество валидаторов: v1∗,…,v10∗v^*_1, \dots, v^*_{10}v1∗,…,v10∗
Количество шардов: s1∗,…,s20∗s^*_1, \dots, s^*_{20}s1∗,…,s20∗
Количество шардов данных: 10
Количество паритетных шардов: 10
Коэффициент репликации:
r=6r = 6 r=6
Коэффициент репликации с учетом паритета:
rp=6⋅(10+10)10=3r_p = \frac{6 \cdot (10 + 10)}{10} = 3 rp=106⋅(10+10)=3

Примеры случаев

Случай A: валидный шард

Валидаторы, включающие s1s_1s1 в свои доказательства: v1,v3,v9v_1, v_3, v_9v1,v3,v9
Количество валидных доказательств:
∣Zs1∣=2|Z_{s_1}| = 2 ∣Zs1∣=2

Условие выполнено:

∣Zs1∣rp≥23\frac{|Z_{s_1}|}{r_p} \geq \frac{2}{3} rp∣Zs1∣≥32

Случай B: невалидный шард

Валидаторы, включающие s2s_2s2 в свои доказательства: v2,v4,v10v_2, v_4, v_{10}v2,v4,v10
Количество валидных доказательств:
∣Zs2∣=1|Z_{s_2}| = 1 ∣Zs2∣=1

Условие не выполнено:

∣Zs2∣rp≥23\frac{|Z_{s_2}|}{r_p} \geq \frac{2}{3} rp∣Zs2∣≥32

Сравнение ончейн- и офчейн-аттестаций доступности данных

Характеристика

Ончейн

Офчейн

Устойчивость к повреждению данных

✓

Масштабируемость мемпула транзакций

✗

✓

Контроль извлекаемости данных

✗

✓

Снижение нагрузки на валидаторов

✗

✓

Устойчивость к ложным положительным DA

✓

✓※

Повреждение данных Устойчивость

Как в аттестациях DA как в сети, так и вне ее, устойчивость к повреждению данных относится к способности системы обнаруживать и предотвращать повреждение данных.

Подтверждение в цепочке, например, Celestia или Sunrise V1 , гарантирует постоянную доступность данных, поскольку они хранятся непосредственно в цепочке, а валидаторы могут немедленно обнаружить любое вмешательство или потерю данных.

Подтверждение вне блокчейна (например, Sunrise V2 ) опирается на внешние системы (например, IPFS или Arweave ), но все равно может обеспечить аналогичную надежность, проверяя целостность данных с помощью стирающего кодирования и доказательств с нулевым разглашением .

Масштабируемость Tx Mempool

Масштабируемость транзакционного пула памяти является основным ограничением в системах DA на цепочке. По мере роста размера данных BLOB транзакционный пул памяти, который временно хранит ожидающие транзакции, может стать перегруженным, что ограничит пропускную способность и масштабируемость.

В системах DA вне цепочки это ограничение смягчается за счет хранения больших объемов данных снаружи, при этом только необходимые хэши или метаданные хранятся в цепочке. Это обеспечивает большую масштабируемость и возможность обработки больших объемов данных без перегрузки мемпула.

Контроль извлекаемости данных

В системах DA на цепочке извлечение данных часто связано с механизмом консенсуса, что означает, что данные должны оставаться доступными до тех пор, пока они необходимы для консенсуса (например, доказательства мошенничества или доказательства действительности). Однако долгосрочное извлечение данных не всегда гарантируется после завершения консенсуса.

Системы DA вне цепочки, такие как Sunrise V2 , обеспечивают более гибкий контроль над возможностью извлечения данных, поскольку данные хранятся в децентрализованных системах хранения (например, IPFS или Arweave ). Это позволяет хранить данные дольше и лучше контролировать, как долго данные остаются доступными.

Снижение нагрузки валидаторов

Подтверждение DA в цепочке накладывает большую нагрузку на валидаторов, поскольку они отвечают за проверку доступности данных непосредственно в цепочке. По мере роста размеров транзакций увеличиваются требования к вычислительным ресурсам и ресурсам хранения валидаторов, что потенциально ограничивает децентрализацию.

Напротив, аттестация DA вне цепочки значительно снижает нагрузку на валидаторов за счет аутсорсинга хранения и извлечения данных во внешние системы. Валидаторам нужно только проверить доступность фрагментов данных с помощью кодирования стирания и доказательств с нулевым разглашением , что облегчает их требования к обработке и хранению.

Ложноположительная аттестация DA

Ложноположительная аттестация DA относится к ситуациям, когда система неверно подтверждает, что данные доступны, хотя на самом деле это не так.

Подтверждение подлинности данных в цепочке, используемое такими системами, как Celestia и Sunrise V1 , имеет высокую устойчивость к ложным срабатываниям, поскольку все данные хранятся и проверяются непосредственно в цепочке, что затрудняет ложные утверждения о доступности данных, когда это не так.

В аттестации DA вне цепочки (например, Sunrise V2 ) устойчивость к ложноположительным срабатываниям поддерживается за счет использования доказательств с нулевым разглашением и криптографических обязательств, таких как кодирование стирания . Проверяя дважды хэшированные значения данных шарда, валидаторы могут гарантировать, что данные действительно доступны, без необходимости хранить или напрямую обращаться ко всему набору данных.

Тем не менее, все еще могут быть пограничные случаи, когда решения для хранения данных вне сети или задержка в сети могут создавать возможности для ложноположительных подтверждений, хотя они сводятся к минимуму благодаря тщательному проектированию и избыточности в процессе проверки.

PreviousАбстракция платы DA NextГолосование по датчикам

Last updated 3 months ago

Доступность данных

Основные характеристики Sunrise v2

Кодирование со стиранием вне цепочки: данные BLOB кодируются со стиранием вне цепочки, что минимизирует вычислительную и накопительную нагрузку на валидаторы.
Интеграция офчейн-хранилища: используя децентрализованные решения для хранения, такие как IPFS и Arweave, фрагменты данных хранятся снаружи. MsgPublishData включает только URI метаданных, указывающий на эти закодированные стиранием общие данные, что снижает требования к размеру блока в цепочке для транзакций Blob и повышает масштабируемость.

Шаблоны проектирования других слоев DA

Комитет по доступности данных

Выборка доступности данных

В типичной настройке DAS полные узлы должны передавать и загружать данные транзакций в пределах мемпула.

Дизайн Sunrise

Для решения этих проблем в DAC и DAS в Sunrise v2 реализованы следующие решения:

Кодирование стирания вне цепочки блоков: данные больших двоичных объектов обрабатываются для кодирования стирания в программе вне цепочки блоков, чтобы снизить нагрузку на валидатор.
Шардинг данных BLOB: не все данные блока, а каждый BLOB-данные обрабатываются для Erasure Coding. Клиенты по-прежнему могут проверить доступность данных для каждого BLOB-данного, только повторяя загрузку шардов, без загрузки всех данных. Клиенты также могут проверить включение BLOB в блок, используя структуру Merkle Tree.
Внешнее хранилище: данные BLOB-объектов хранятся на децентрализованных платформах хранения, таких как IPFS и Arweave. Вместо того, чтобы хранить данные BLOB-объектов в цепочке, MsgPublishData содержит URI метаданных, указывающий на закодированные стиранием общие данные.
Копировать
```
message MsgPublishData {
  option (cosmos.msg.v1.signer) = "sender";
  string sender = 1;
  string metadata_uri = 2;
  repeated bytes shard_double_hashes = 3;
}

message Metadata {
  uint64 shard_size = 1;
  uint64 shard_count = 2;
  repeated string shard_uris = 3;
}
```
Доступность данных подтверждается с помощью Optimistic way. Если доказательство мошенничества отправляется в сеть Sunrise, валидаторы отправят доказательства с нулевым разглашением (ZKP) с использованием дважды хэшированных данных шарда ( shard_double_hashes), что позволяет валидаторам проверять наличие данных шарда, не раскрывая их. Эта интеграция выполняется с помощью Vote Extension ABCI 2.0 .

Преимущества Sunrise v2

Увеличение пропускной способности сети: большие размеры блоков достигаются за счет сокращения потребностей в хранении данных в цепочке.
Улучшенная возможность извлечения данных: хранение данных вне сети обеспечивает гибкое и долгосрочное хранение данных.
Улучшенная децентрализация сети: за счет снижения нагрузки на валидатор Sunrise поддерживает более децентрализованную структуру сети.

Спецификация для доказательства с нулевым разглашением

Термины и обозначения

Функция хэширования:
$H$
Набор валидаторов:
$V$
Набор фрагментов данных:
$S_d$
Набор четных сегментов:
$S_p$
Набор осколков:
$S$

S = S_d \cup S_p

Обзор Эта система проверяет наличие хэша фрагмента данных

H(s_i)

не подвергая

H(s_i)

Zero-Knowledge Proof System

Схема рассчитана на один осколок

H(s_i)

Общественные мнения

H_{public}^2(s)

Частные вклады

H_{private}(s)

Ограничения цепи

H_{public}^2(s) = H(H_{private}(s))

Состояние доступности данных

Обозначения

Фактор репликации (основан только на фрагментах данных): r
Фактор репликации (на основе включения сегментов четности): rp
$n = \lceil r_p \cdot \frac{|V|}{|S_d| + |S_p|} \rceil = \lceil r \cdot \frac{|V|}{|S_d|} \rceil$
$r_p = r \cdot \frac{|S_d| + |S_p|}{|S_d|}$

Количество шардов, с которыми работает каждый валидатор: н

n = \lceil r_p \cdot \frac{|V|}{|S_d| + |S_p|} \rceil = \lceil r \cdot \frac{|V|}{|S_d|} \rceil

Требования к каждому сегменту для подтверждения доступности данных

Набор действительных доказательств для шарда `s`от валидаторов, задействованных в этом шарде:

Спецификация для доказательства с нулевым разглашением

Термины и обозначения

Функция хэширования:

HH H

Множество валидаторов:

VV V

Множество шардов данных:

SdS_d Sd

Множество шардов паритета:

SpS_p Sp

Множество всех шардов:

SS S

Объединение множеств шардов данных и паритета:

S=Sd∪SpS = S_d \cup S_p S=Sd∪Sp

Обзор

Описание: Эта система проверяет наличие хэша шарда данных, не раскрывая содержимое шарда. Формула:

H(si)H(s_i) H(si)

Система доказательства с нулевым разглашением

Эта схема предназначена для одного шарда. Обозначение:

s∈Ss \in S s∈S

Публичные входные данные

Хэш публичного ключа (в квадрате):

Hpublic2(s)H_{\text{public}}^2(s) Hpublic2(s)

Приватные входные данные

Хэш приватного ключа:

Hprivate(s)H_{\text{private}}(s) Hprivate(s)

Ограничения схемы

Связь публичного и приватного ключей через хэш:

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

Условие доступности данных

Обозначения

Коэффициент репликации (шарды данных):

rr r

Коэффициент репликации (включая паритет):

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

Количество шардов, в которых участвует каждый валидатор:

Требования для доказательства доступности данных

Множество валидных доказательств для шарда sss:

ZsZ_s Zs

Условие:

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

Множество шардов, удовлетворяющих условию:

SavailableS_{\text{available}} Savailable

Требования для подтверждения доступности данных

Отношение доступных шардов ко всем шарам:

∣Savailable∣∣S∣≥∣Sd∣∣Sd∣+∣Sp∣\frac{|S_{\text{available}}|}{|S|} \geq \frac{|S_d|}{|S_d| + |S_p|} ∣S∣∣Savailable∣≥∣Sd∣+∣Sp∣∣Sd∣

Минимальное количество доступных шардов:

∣Savailable∣≥∣Sd∣|S_{\text{available}}| \geq |S_d| ∣Savailable∣≥∣Sd∣

Пример параметров

Количество валидаторов: v1∗,…,v10∗v^*_1, \dots, v^*_{10}v1∗,…,v10∗
Количество шардов: s1∗,…,s20∗s^*_1, \dots, s^*_{20}s1∗,…,s20∗
Количество шардов данных: 10
Количество паритетных шардов: 10
Коэффициент репликации:
r=6r = 6 r=6
Коэффициент репликации с учетом паритета:
rp=6⋅(10+10)10=3r_p = \frac{6 \cdot (10 + 10)}{10} = 3 rp=106⋅(10+10)=3

Примеры случаев

Случай A: валидный шард

Валидаторы, включающие s1s_1s1 в свои доказательства: v1,v3,v9v_1, v_3, v_9v1,v3,v9
Количество валидных доказательств:
∣Zs1∣=2|Z_{s_1}| = 2 ∣Zs1∣=2

Условие выполнено:

∣Zs1∣rp≥23\frac{|Z_{s_1}|}{r_p} \geq \frac{2}{3} rp∣Zs1∣≥32

Случай B: невалидный шард

Валидаторы, включающие s2s_2s2 в свои доказательства: v2,v4,v10v_2, v_4, v_{10}v2,v4,v10
Количество валидных доказательств:
∣Zs2∣=1|Z_{s_2}| = 1 ∣Zs2∣=1

Условие не выполнено:

∣Zs2∣rp≥23\frac{|Z_{s_2}|}{r_p} \geq \frac{2}{3} rp∣Zs2∣≥32

Сравнение ончейн- и офчейн-аттестаций доступности данных

Характеристика

Ончейн

Офчейн

Устойчивость к повреждению данных

✓

Масштабируемость мемпула транзакций

✗

✓

Контроль извлекаемости данных

✗

✓

Снижение нагрузки на валидаторов

✗

✓

Устойчивость к ложным положительным DA

✓

✓※

Повреждение данных Устойчивость

Масштабируемость Tx Mempool

Контроль извлекаемости данных

Снижение нагрузки валидаторов

Ложноположительная аттестация DA

PreviousАбстракция платы DA NextГолосование по датчикам

Last updated 3 months ago