Доступність даних є одним із основних вузьких місць у розширенні блокчейна.
**Автор: **zer0kn0wledge.era
Складач: Kate, Marsbit
Примітка: ця стаття надіслана @expctchaos Twitter, який є дослідником @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/ Тож у сьогоднішньому дописі ми хочемо зосередитися на порівнянні між ланцюжками #EigenDA і DA L1 @eigenlayer, такими як @CelestiaOrg або @AvailProject
10/ Давайте припустимо зведення на основі Ethereum і використання Celestia для DA (він же Celestium)
Таким чином, контракти L2 на Ethereum перевіряють докази дійсності або докази шахрайства, як зазвичай, а DA надає Celestia
11/ На @CelestiaOrg і @AvailProject немає смарт-контрактів або обчислень, лише дані гарантовано доступні
12/ Але давайте подивимося ближче
На @CelestiaOrg дані передачі публікуються в Celestia за допомогою сортувальника L2, верифікатор Celestia підписує корінь Merkle доказу DA, а потім надсилається до мостового контракту DA на Ethereum для перевірки та зберігання
13/ Порівняно зі зберіганням DA в ланцюжку, це значно знижує вартість наявності сильної гарантії DA, а також забезпечує гарантії безпеки від Celestia (а не централізованого DAC)
14/ Зменшення вартості змінить правила гри в усьому зведеному полі, оскільки вартість даних викликів, згенерованих шляхом публікації даних в Ethereum L1, становить 80-90% вартості зведеного
Щоб дізнатися більше про вартість даних виклику, перегляньте публікацію нижче 👇
15/ Але що, в біса, сталося на #Celestia?
Блоки даних, опубліковані в @CelestiaOrg (по суті, як необроблені дані), поширюються через мережу P2P, а консенсус щодо блоку даних досягається за допомогою консенсусу Tendermint
16/ Кожен повний вузол #Celestia повинен завантажити весь blob даних. Це відрізняється для легких вузлів, які можуть використовувати вибірку доступності даних (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 slashing і забезпечує економічну безпеку DA
44/ Отже, більша участь зацікавлених сторін у #EigenDA означає більшу безпеку. Зменшення вимог до вузлів також сприяє кращій децентралізації
45/ Кодування стирання є важливим механізмом, який забезпечує вибірку доступності даних. Кодування стирання розширює блоки шляхом створення додаткових копій даних. Додаткові дані створюють надмірність, забезпечуючи сильніші гарантії безпеки для процесу вибірки
46/ Однак вузли можуть спробувати неправильно закодувати дані, щоб порушити роботу мережі. Щоб захиститися від цієї атаки, вузлам потрібен спосіб перевірити правильність кодування - це те, де потрібні докази.
47/ Ethereum, @eigenlayer і @AvailProject використовують схему підтвердження дійсності, щоб переконатися, що блоки правильно закодовані. Ідея подібна до доказів дійсності, які використовує zk rollup. @eigenlayer обговорював це раніше в цій темі
48/ Кожного разу, коли генерується блок, верифікатор повинен взяти на себе зобов’язання щодо даних, перевірених вузлом за допомогою підтвердження KZG, щоб довести, що блок правильно закодований
49/ Хоча створення зобов’язань для доказів KZG вимагає більших обчислювальних витрат для виробників блоків, коли блоки невеликі, створення зобов’язань не приносить значних накладних витрат. Однак це змінилося...
50/… оскільки блоки стають більшими, тягар зобов’язань доказу KZG стає набагато вищим
Таким чином, тип вузла, відповідального за створення цих зобов’язань, може мати вищі вимоги до обладнання
51/ З іншого боку, @CelestiaOrg реалізує захист від шахрайства для кодування стирання. Тому вузлам #Celestia не потрібно перевіряти, чи блоки правильно закодовані. вони за замовчуванням це правильно
52/ Перевага полягає в тому, що виробникам блоків не потрібно виконувати дорогу роботу зі створення зобов’язань із кодом стирання
Але є компроміс, оскільки світлові вузли повинні чекати деякий час, перш ніж припустити, що блок правильно закодований, і завершити його на їхню думку
53/ Основна відмінність між захищеними від шахрайства та надійними схемами кодування полягає в компромісі між накладними витратами вузла для створення зобов’язань та затримкою для легких вузлів
54/ Ця таблиця гарно узагальнює порівняння
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Як працюють рішення щодо доступності даних і чим вони відрізняються?
**Автор: **zer0kn0wledge.era
Складач: Kate, Marsbit
Примітка: ця стаття надіслана @expctchaos Twitter, який є дослідником @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/ Тож у сьогоднішньому дописі ми хочемо зосередитися на порівнянні між ланцюжками #EigenDA і DA L1 @eigenlayer, такими як @CelestiaOrg або @AvailProject
10/ Давайте припустимо зведення на основі Ethereum і використання Celestia для DA (він же Celestium)
Таким чином, контракти L2 на Ethereum перевіряють докази дійсності або докази шахрайства, як зазвичай, а DA надає Celestia
11/ На @CelestiaOrg і @AvailProject немає смарт-контрактів або обчислень, лише дані гарантовано доступні
12/ Але давайте подивимося ближче
На @CelestiaOrg дані передачі публікуються в Celestia за допомогою сортувальника L2, верифікатор Celestia підписує корінь Merkle доказу DA, а потім надсилається до мостового контракту DA на Ethereum для перевірки та зберігання
13/ Порівняно зі зберіганням DA в ланцюжку, це значно знижує вартість наявності сильної гарантії DA, а також забезпечує гарантії безпеки від Celestia (а не централізованого DAC)
14/ Зменшення вартості змінить правила гри в усьому зведеному полі, оскільки вартість даних викликів, згенерованих шляхом публікації даних в Ethereum L1, становить 80-90% вартості зведеного
Щоб дізнатися більше про вартість даних виклику, перегляньте публікацію нижче 👇
15/ Але що, в біса, сталося на #Celestia?
Блоки даних, опубліковані в @CelestiaOrg (по суті, як необроблені дані), поширюються через мережу P2P, а консенсус щодо блоку даних досягається за допомогою консенсусу Tendermint
16/ Кожен повний вузол #Celestia повинен завантажити весь blob даних. Це відрізняється для легких вузлів, які можуть використовувати вибірку доступності даних (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 slashing і забезпечує економічну безпеку DA
44/ Отже, більша участь зацікавлених сторін у #EigenDA означає більшу безпеку. Зменшення вимог до вузлів також сприяє кращій децентралізації
45/ Кодування стирання є важливим механізмом, який забезпечує вибірку доступності даних. Кодування стирання розширює блоки шляхом створення додаткових копій даних. Додаткові дані створюють надмірність, забезпечуючи сильніші гарантії безпеки для процесу вибірки
46/ Однак вузли можуть спробувати неправильно закодувати дані, щоб порушити роботу мережі. Щоб захиститися від цієї атаки, вузлам потрібен спосіб перевірити правильність кодування - це те, де потрібні докази.
47/ Ethereum, @eigenlayer і @AvailProject використовують схему підтвердження дійсності, щоб переконатися, що блоки правильно закодовані. Ідея подібна до доказів дійсності, які використовує zk rollup. @eigenlayer обговорював це раніше в цій темі
48/ Кожного разу, коли генерується блок, верифікатор повинен взяти на себе зобов’язання щодо даних, перевірених вузлом за допомогою підтвердження KZG, щоб довести, що блок правильно закодований
49/ Хоча створення зобов’язань для доказів KZG вимагає більших обчислювальних витрат для виробників блоків, коли блоки невеликі, створення зобов’язань не приносить значних накладних витрат. Однак це змінилося...
50/… оскільки блоки стають більшими, тягар зобов’язань доказу KZG стає набагато вищим
Таким чином, тип вузла, відповідального за створення цих зобов’язань, може мати вищі вимоги до обладнання
51/ З іншого боку, @CelestiaOrg реалізує захист від шахрайства для кодування стирання. Тому вузлам #Celestia не потрібно перевіряти, чи блоки правильно закодовані. вони за замовчуванням це правильно
52/ Перевага полягає в тому, що виробникам блоків не потрібно виконувати дорогу роботу зі створення зобов’язань із кодом стирання
Але є компроміс, оскільки світлові вузли повинні чекати деякий час, перш ніж припустити, що блок правильно закодований, і завершити його на їхню думку
53/ Основна відмінність між захищеними від шахрайства та надійними схемами кодування полягає в компромісі між накладними витратами вузла для створення зобов’язань та затримкою для легких вузлів
54/ Ця таблиця гарно узагальнює порівняння