Доступность данных — одно из основных узких мест в расширении блокчейна.
**Автор: **zer0kn0wledge.era
Составлено: Кейт, Marsbit
Примечание: эта статья взята из Twitter @expctchaos, который является исследователем @ChaosDAO.Содержание оригинального твита организовано MarsBit следующим образом:
0/ Доступность данных (DA) является основным узким местом масштабирования
К счастью, @CelestiaOrg, @AvailProject и @eigenlayer изменят игру DA и обеспечат новые уровни масштабируемости.
Но как это работает и чем #EigenDA отличается от DA 15, таких как #Celestia и #Avail?
1/ Если вы не знакомы с проблемами доступности данных, ознакомьтесь с моим сообщением ниже, где я подробно описываю ситуацию с доступностью данных 👇
2/ В целом существует два основных типа решений для обработки данных.
🔷Ончейн DA
🔷Вне сети DA
3/ А «чистая проверка достоверности» означает, что обработка данных может осуществляться вне сети без каких-либо гарантий, потому что поставщики услуг данных вне сети могут отключиться в любое время...
4/ …#StarkEx, #zkPorter и #Arbitrum Nova являются примерами сценариев проверки, которые полагаются на DAC, группу известных третьих лиц, гарантирующих доступность данных.
5/ С другой стороны, #EigenDA, @CelestiaOrg и @AvailProject — это то, что мы могли бы назвать универсальным решением DA.
Однако между EigenDA и двумя другими решениями есть некоторые отличия.
6/ Если вы хотите узнать, как работает @CelestiaOrg, перейдите по ссылке ниже.
7/ Я уже рассказывал об @AvailProject в прошлом, поэтому, чтобы узнать больше, ознакомьтесь с ним здесь.
8/ Если вам нужно освежить в памяти @eigenlayer, загляните в тему ниже 👇
9/ Итак, в сегодняшней статье мы хотим сосредоточиться на сравнении цепочек @eigenlayer #EigenDA и DA L1, таких как @CelestiaOrg или @AvailProject.
10/ Давайте предположим, что накопитель основан на Ethereum и использует Celestia для DA (он же Celestium).
Таким образом, контракты L2 на Ethereum, как обычно, проверяют подтверждение действительности или доказательство мошенничества, а DA предоставляется Celestia.
11/ На @CelestiaOrg и @AvailProject нет смарт-контрактов или вычислений, гарантированно доступны только данные
12/ Но давайте посмотрим повнимательнее
На @CelestiaOrg данные tx публикуются в Celestia с помощью сортировщика L2, верификатор Celestia подписывает корень Merkle доказательства DA, а затем отправляется в бридж-контракт DA на Ethereum для проверки и хранения.
13/ По сравнению с хранением DA в сети, это значительно снижает стоимость надежной гарантии DA, а также предоставляет гарантии безопасности от Celestia (а не централизованного DAC).
Сокращение затрат изменит правила игры во всем поле объединения, поскольку стоимость данных вызовов, сгенерированных путем публикации данных в Ethereum L1, составляет 80-90% стоимости объединения.
Для получения дополнительной информации о стоимости calldata, ознакомьтесь с постом ниже 👇
15/ Но что, черт возьми, произошло на #Селестии?
Блобы данных, отправленные в @CelestiaOrg (по сути, как необработанные данные), распространяются через сеть P2P, и консенсус относительно блоба данных достигается с помощью консенсуса Tendermint.
Каждый полный узел #Celestia должен загрузить весь большой двоичный объект данных. Это отличается для легких узлов, которые могут использовать выборку доступности данных (DAS) для обеспечения доступности данных.
17/ Для получения дополнительной информации о DAS и световых узлах, пожалуйста, ознакомьтесь с сообщением ниже.
18/ Мы также вернемся к DAS позже в этой теме, но сейчас основное внимание уделяется полным узлам.
Итак, вернемся к @CelestiaOrg, которая продолжает вести себя в стиле L1, полагаясь на широковещательную рассылку и консенсус по большим двоичным объектам данных.
19/ Таким образом, он предъявляет высокие требования к полным узлам сети (128 МБ/с при загрузке и 12,5 МБ/с при загрузке).
Тем не менее, @CelestiaOrg изначально стремилась к средней пропускной способности (1,4 МБ/с), что кажется низким, учитывая требования к полному узлу.
20/ Однако сеть может масштабировать пропускную способность, добавляя легкие узлы. Чем больше легких узлов выборки данных, тем больше может быть размер блока при условии обеспечения безопасности и децентрализации
21/ С другой стороны, у @eigenlayer другая архитектура, нет собственного консенсуса и нет одноранговой сети.
Так как же это работает?
Во-первых, узел EigenDA должен перераспределить $ETH в контракте @eigenlayer. Таким образом, узлы #EigenDA являются подмножеством валидаторов Ethereum.
22/ После получения большого двоичного объекта данных покупатель DA (например, накопительный пакет, также известный как диспергатор) затем кодирует его с помощью кода стирания и создает обязательство KZG…
23/…где размер доказательства зависит от коэффициента избыточности кода стирания и публикует приверженность KZG смарт-контракту #EigenDA
24/ Закодированное обязательство KZG, распространяемое диспергатором на узлы #EigenDA
После получения обязательства KZG эти узлы сравнивают его с обязательством KZG смарт-контракта EigenDA и подписывают подтверждение после подтверждения.
25/ После этого диспергатор собирает эти подписи одну за другой, генерирует агрегированную подпись и публикует ее в смарт-контракте #EigenDA, а смарт-контракт проверяет подпись
26/ Но если узел #EigenDA просто подписывает доказательство, утверждая, что он сохранил закодированный блок данных в этом рабочем процессе, а смарт-контракт EigenDA проверяет только правильность агрегированной подписи, как мы можем быть уверены, что узел EigenDA действительно сохранил данные?
27/ #EigenDA использует метод условного депонирования для достижения этой цели.
Но давайте сделаем шаг назад и посмотрим на эту сцену, где становится важным
28/ Давайте предположим, что некоторые ленивые валидаторы не выполняют возложенные на них задачи (например, проверяют доступность данных)
Вместо этого они делают вид, что выполнили работу, и подписывают конечный результат (ложно сообщая о доступности данных, когда они недоступны).
29/ Концептуально доказательство содержания под стражей похоже на доказательство мошенничества:
Любой может отправить доказательство (ленивый валидатор) смарт-контракту #EigenDA, которое будет проверено смарт-контрактом.
29/Ленивый валидатор обрезается, если валидация прошла успешно (поскольку это объективно приписываемая ошибка)
30/ Как насчет консенсуса?
@CelestiaOrg использует Tendermint в качестве консенсусного протокола, который имеет завершенность в один слот. То есть, как только блок проходит консенсус #Celestia, он готов. Это означает, что финализация в основном такая же быстрая, как и время блока (15 секунд).
31/ @AvailProject использует композицию протокола для достижения окончательности. BABE — это механизм производства блоков с вероятностной завершенностью, а GRANDPA — конечный гаджет. В то время как GRANDPA может выполнять блоки в одном слоте, он также может выполнять несколько блоков за раунд.
32/ Поскольку @eigenlayer представляет собой набор смарт-контрактов на Ethereum, он также наследует то же время завершения, что и Ethereum (12–15 минут) для данных, которые необходимо перенаправить в накопительный контракт для подтверждения доступности данных.
33/ Однако, если накопительный пакет вообще использует @eigenlayer, это может быть сделано быстрее, в зависимости от используемого механизма консенсуса и т. д.
Кроме того, промежуточное программное обеспечение, защищенное валидаторами повторного стейкинга @eigenlayer, ориентированными на обеспечение быстрых расчетов, такими как EigenSettle, может обеспечить надежные гарантии экономической безопасности, позволяя предварительно подтвердить окончательность. Тем не менее, жесткие гарантии окончательности по-прежнему исходят от Ethereum L1.
34/ Время пересмотреть концепции выборки доступности данных
В большинстве блокчейнов узлам необходимо загружать все данные транзакций, чтобы проверить их доступность. Проблема заключается в том, что при увеличении размера блока увеличивается и количество узлов данных, которые необходимо проверить.
35/ Выборка доступности данных (DAS) — это метод, который позволяет легким узлам проверять доступность данных, загружая лишь небольшую часть блочных данных.
36/ Это обеспечивает безопасность легких узлов, чтобы они могли проверять недействительные блоки (только DA и консенсус) и позволяет блокчейну масштабировать доступность данных без увеличения требований к узлу.
37/ Для DAS требуется как минимум один честный полный узел и достаточное количество легких клиентов.
38/ Но как обеспечить безопасность легких узлов?
Традиционные легкие клиенты имеют более слабые предположения о безопасности по сравнению с полными узлами, поскольку они проверяют только заголовки блоков.
Поэтому легкие клиенты не могут определить, был ли недействительный блок создан нечестным большинством производителей блоков.
39/Облегченные узлы с выборкой доступности данных повышены в плане безопасности, потому что, если уровень DA выполняет только согласование и доступность данных, они могут проверить, создаются ли недопустимые блоки.
40/ И @CelestiaOrg, и @AvailProject будут иметь выборку доступности данных, поэтому их легкие узлы будут иметь безопасность с минимальным доверием.
41/ Это отличается от Ethereum и @eigenlayer.
Ethereum с #EIP4844 не имеет выборки доступности данных, поэтому его легкие клиенты не будут иметь безопасность с минимальным доверием.
42/ Поскольку Ethereum также имеет свою среду смарт-контрактов, легким клиентам также необходимо проверять выполнение (путем мошенничества или доказательства действительности), а не полагаться на большинство предположений о честности.
43/ Легкий клиент @eigenlayer (если нет DAS), если он поддерживается, будет полагаться на честное большинство узлов рестейкинга.
Таким образом, безопасность #EigenDA в основном основана на наборе валидаторов Ethereum, наследующем примитив слэшинга Ethereum и обеспечивающем экономическую безопасность DA.
44/ Таким образом, большее участие заинтересованных сторон в #EigenDA означает большую безопасность. Снижение требований к узлам также способствует лучшей децентрализации.
45/ Кодирование стирания является важным механизмом, позволяющим производить выборку доступности данных. Erasure coding расширяет блоки за счет создания дополнительных копий данных. Дополнительные данные создают избыточность, обеспечивая более надежные гарантии безопасности процесса отбора проб.
46/ Однако узлы могут попытаться неправильно закодировать данные, чтобы нарушить работу сети. Чтобы защититься от этой атаки, узлам нужен способ проверить правильность кодировки — вот тут-то и приходят доказательства.
47/ Ethereum, @eigenlayer и @AvailProject используют схему доказательства валидности, чтобы убедиться, что блоки правильно закодированы. Идея аналогична доказательствам достоверности, используемым zk rollup. @eigenlayer обсуждал это ранее в этой теме
48/ Каждый раз, когда генерируется блок, верификатор должен фиксировать данные, проверенные узлом, используя доказательство KZG, чтобы доказать, что блок закодирован правильно.
49/ Хотя создание обязательств для доказательств KZG требует больших вычислительных затрат для производителей блоков, когда блоки небольшие, создание обязательств не требует больших затрат. Однако это изменило...
50/… по мере того, как блоки становятся больше, бремя подтверждения KZG становится намного выше
Следовательно, тип узла, ответственного за создание этих обязательств, может иметь более высокие требования к оборудованию.
51/ С другой стороны, @CelestiaOrg внедряет доказательства мошенничества для кодирования стирания. Поэтому узлам #Celestia не нужно проверять правильность кодирования блоков. они по умолчанию это правильно
52/ Преимущество заключается в том, что производителям блоков не нужно выполнять дорогостоящую работу по созданию обязательств с закодированным стиранием.
Но есть компромисс, потому что легкие узлы должны ждать некоторое время, прежде чем предположить, что блок правильно закодирован, и завершить его в своем представлении.
53/ Основное различие между защищенными от мошенничества и надежными схемами кодирования заключается в компромиссе между накладными расходами узла на создание обязательств и задержкой для легких узлов.
54/ Эта таблица хорошо подытоживает сравнение
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Как работают решения для обеспечения доступности данных и чем они отличаются?
**Автор: **zer0kn0wledge.era
Составлено: Кейт, Marsbit
Примечание: эта статья взята из Twitter @expctchaos, который является исследователем @ChaosDAO.Содержание оригинального твита организовано MarsBit следующим образом:
0/ Доступность данных (DA) является основным узким местом масштабирования
К счастью, @CelestiaOrg, @AvailProject и @eigenlayer изменят игру DA и обеспечат новые уровни масштабируемости.
Но как это работает и чем #EigenDA отличается от DA 15, таких как #Celestia и #Avail?
1/ Если вы не знакомы с проблемами доступности данных, ознакомьтесь с моим сообщением ниже, где я подробно описываю ситуацию с доступностью данных 👇
2/ В целом существует два основных типа решений для обработки данных.
3/ А «чистая проверка достоверности» означает, что обработка данных может осуществляться вне сети без каких-либо гарантий, потому что поставщики услуг данных вне сети могут отключиться в любое время...
4/ …#StarkEx, #zkPorter и #Arbitrum Nova являются примерами сценариев проверки, которые полагаются на DAC, группу известных третьих лиц, гарантирующих доступность данных.
5/ С другой стороны, #EigenDA, @CelestiaOrg и @AvailProject — это то, что мы могли бы назвать универсальным решением DA.
Однако между EigenDA и двумя другими решениями есть некоторые отличия.
6/ Если вы хотите узнать, как работает @CelestiaOrg, перейдите по ссылке ниже.
7/ Я уже рассказывал об @AvailProject в прошлом, поэтому, чтобы узнать больше, ознакомьтесь с ним здесь.
8/ Если вам нужно освежить в памяти @eigenlayer, загляните в тему ниже 👇
9/ Итак, в сегодняшней статье мы хотим сосредоточиться на сравнении цепочек @eigenlayer #EigenDA и DA L1, таких как @CelestiaOrg или @AvailProject.
10/ Давайте предположим, что накопитель основан на Ethereum и использует Celestia для DA (он же Celestium).
Таким образом, контракты L2 на Ethereum, как обычно, проверяют подтверждение действительности или доказательство мошенничества, а DA предоставляется Celestia.
11/ На @CelestiaOrg и @AvailProject нет смарт-контрактов или вычислений, гарантированно доступны только данные
12/ Но давайте посмотрим повнимательнее
На @CelestiaOrg данные tx публикуются в Celestia с помощью сортировщика L2, верификатор Celestia подписывает корень Merkle доказательства DA, а затем отправляется в бридж-контракт DA на Ethereum для проверки и хранения.
13/ По сравнению с хранением DA в сети, это значительно снижает стоимость надежной гарантии DA, а также предоставляет гарантии безопасности от Celestia (а не централизованного DAC).
Для получения дополнительной информации о стоимости calldata, ознакомьтесь с постом ниже 👇
15/ Но что, черт возьми, произошло на #Селестии?
Блобы данных, отправленные в @CelestiaOrg (по сути, как необработанные данные), распространяются через сеть P2P, и консенсус относительно блоба данных достигается с помощью консенсуса Tendermint.
17/ Для получения дополнительной информации о DAS и световых узлах, пожалуйста, ознакомьтесь с сообщением ниже.
18/ Мы также вернемся к DAS позже в этой теме, но сейчас основное внимание уделяется полным узлам.
Итак, вернемся к @CelestiaOrg, которая продолжает вести себя в стиле L1, полагаясь на широковещательную рассылку и консенсус по большим двоичным объектам данных.
19/ Таким образом, он предъявляет высокие требования к полным узлам сети (128 МБ/с при загрузке и 12,5 МБ/с при загрузке).
Тем не менее, @CelestiaOrg изначально стремилась к средней пропускной способности (1,4 МБ/с), что кажется низким, учитывая требования к полному узлу.
20/ Однако сеть может масштабировать пропускную способность, добавляя легкие узлы. Чем больше легких узлов выборки данных, тем больше может быть размер блока при условии обеспечения безопасности и децентрализации
21/ С другой стороны, у @eigenlayer другая архитектура, нет собственного консенсуса и нет одноранговой сети.
Так как же это работает?
Во-первых, узел EigenDA должен перераспределить $ETH в контракте @eigenlayer. Таким образом, узлы #EigenDA являются подмножеством валидаторов Ethereum.
22/ После получения большого двоичного объекта данных покупатель DA (например, накопительный пакет, также известный как диспергатор) затем кодирует его с помощью кода стирания и создает обязательство KZG…
23/…где размер доказательства зависит от коэффициента избыточности кода стирания и публикует приверженность KZG смарт-контракту #EigenDA
24/ Закодированное обязательство KZG, распространяемое диспергатором на узлы #EigenDA
После получения обязательства KZG эти узлы сравнивают его с обязательством KZG смарт-контракта EigenDA и подписывают подтверждение после подтверждения.
25/ После этого диспергатор собирает эти подписи одну за другой, генерирует агрегированную подпись и публикует ее в смарт-контракте #EigenDA, а смарт-контракт проверяет подпись
26/ Но если узел #EigenDA просто подписывает доказательство, утверждая, что он сохранил закодированный блок данных в этом рабочем процессе, а смарт-контракт EigenDA проверяет только правильность агрегированной подписи, как мы можем быть уверены, что узел EigenDA действительно сохранил данные?
27/ #EigenDA использует метод условного депонирования для достижения этой цели.
Но давайте сделаем шаг назад и посмотрим на эту сцену, где становится важным
28/ Давайте предположим, что некоторые ленивые валидаторы не выполняют возложенные на них задачи (например, проверяют доступность данных)
Вместо этого они делают вид, что выполнили работу, и подписывают конечный результат (ложно сообщая о доступности данных, когда они недоступны).
29/ Концептуально доказательство содержания под стражей похоже на доказательство мошенничества:
Любой может отправить доказательство (ленивый валидатор) смарт-контракту #EigenDA, которое будет проверено смарт-контрактом.
29/Ленивый валидатор обрезается, если валидация прошла успешно (поскольку это объективно приписываемая ошибка)
30/ Как насчет консенсуса?
@CelestiaOrg использует Tendermint в качестве консенсусного протокола, который имеет завершенность в один слот. То есть, как только блок проходит консенсус #Celestia, он готов. Это означает, что финализация в основном такая же быстрая, как и время блока (15 секунд).
31/ @AvailProject использует композицию протокола для достижения окончательности. BABE — это механизм производства блоков с вероятностной завершенностью, а GRANDPA — конечный гаджет. В то время как GRANDPA может выполнять блоки в одном слоте, он также может выполнять несколько блоков за раунд.
32/ Поскольку @eigenlayer представляет собой набор смарт-контрактов на Ethereum, он также наследует то же время завершения, что и Ethereum (12–15 минут) для данных, которые необходимо перенаправить в накопительный контракт для подтверждения доступности данных.
33/ Однако, если накопительный пакет вообще использует @eigenlayer, это может быть сделано быстрее, в зависимости от используемого механизма консенсуса и т. д.
Кроме того, промежуточное программное обеспечение, защищенное валидаторами повторного стейкинга @eigenlayer, ориентированными на обеспечение быстрых расчетов, такими как EigenSettle, может обеспечить надежные гарантии экономической безопасности, позволяя предварительно подтвердить окончательность. Тем не менее, жесткие гарантии окончательности по-прежнему исходят от Ethereum L1.
34/ Время пересмотреть концепции выборки доступности данных
В большинстве блокчейнов узлам необходимо загружать все данные транзакций, чтобы проверить их доступность. Проблема заключается в том, что при увеличении размера блока увеличивается и количество узлов данных, которые необходимо проверить.
35/ Выборка доступности данных (DAS) — это метод, который позволяет легким узлам проверять доступность данных, загружая лишь небольшую часть блочных данных.
36/ Это обеспечивает безопасность легких узлов, чтобы они могли проверять недействительные блоки (только DA и консенсус) и позволяет блокчейну масштабировать доступность данных без увеличения требований к узлу.
37/ Для DAS требуется как минимум один честный полный узел и достаточное количество легких клиентов.
38/ Но как обеспечить безопасность легких узлов?
Традиционные легкие клиенты имеют более слабые предположения о безопасности по сравнению с полными узлами, поскольку они проверяют только заголовки блоков.
Поэтому легкие клиенты не могут определить, был ли недействительный блок создан нечестным большинством производителей блоков.
39/Облегченные узлы с выборкой доступности данных повышены в плане безопасности, потому что, если уровень DA выполняет только согласование и доступность данных, они могут проверить, создаются ли недопустимые блоки.
40/ И @CelestiaOrg, и @AvailProject будут иметь выборку доступности данных, поэтому их легкие узлы будут иметь безопасность с минимальным доверием.
41/ Это отличается от Ethereum и @eigenlayer.
Ethereum с #EIP4844 не имеет выборки доступности данных, поэтому его легкие клиенты не будут иметь безопасность с минимальным доверием.
42/ Поскольку Ethereum также имеет свою среду смарт-контрактов, легким клиентам также необходимо проверять выполнение (путем мошенничества или доказательства действительности), а не полагаться на большинство предположений о честности.
43/ Легкий клиент @eigenlayer (если нет DAS), если он поддерживается, будет полагаться на честное большинство узлов рестейкинга.
Таким образом, безопасность #EigenDA в основном основана на наборе валидаторов Ethereum, наследующем примитив слэшинга Ethereum и обеспечивающем экономическую безопасность DA.
44/ Таким образом, большее участие заинтересованных сторон в #EigenDA означает большую безопасность. Снижение требований к узлам также способствует лучшей децентрализации.
45/ Кодирование стирания является важным механизмом, позволяющим производить выборку доступности данных. Erasure coding расширяет блоки за счет создания дополнительных копий данных. Дополнительные данные создают избыточность, обеспечивая более надежные гарантии безопасности процесса отбора проб.
46/ Однако узлы могут попытаться неправильно закодировать данные, чтобы нарушить работу сети. Чтобы защититься от этой атаки, узлам нужен способ проверить правильность кодировки — вот тут-то и приходят доказательства.
47/ Ethereum, @eigenlayer и @AvailProject используют схему доказательства валидности, чтобы убедиться, что блоки правильно закодированы. Идея аналогична доказательствам достоверности, используемым zk rollup. @eigenlayer обсуждал это ранее в этой теме
48/ Каждый раз, когда генерируется блок, верификатор должен фиксировать данные, проверенные узлом, используя доказательство KZG, чтобы доказать, что блок закодирован правильно.
49/ Хотя создание обязательств для доказательств KZG требует больших вычислительных затрат для производителей блоков, когда блоки небольшие, создание обязательств не требует больших затрат. Однако это изменило...
50/… по мере того, как блоки становятся больше, бремя подтверждения KZG становится намного выше
Следовательно, тип узла, ответственного за создание этих обязательств, может иметь более высокие требования к оборудованию.
51/ С другой стороны, @CelestiaOrg внедряет доказательства мошенничества для кодирования стирания. Поэтому узлам #Celestia не нужно проверять правильность кодирования блоков. они по умолчанию это правильно
52/ Преимущество заключается в том, что производителям блоков не нужно выполнять дорогостоящую работу по созданию обязательств с закодированным стиранием.
Но есть компромисс, потому что легкие узлы должны ждать некоторое время, прежде чем предположить, что блок правильно закодирован, и завершить его в своем представлении.
53/ Основное различие между защищенными от мошенничества и надежными схемами кодирования заключается в компромиссе между накладными расходами узла на создание обязательств и задержкой для легких узлов.
54/ Эта таблица хорошо подытоживает сравнение