Непорозуміння щодо доступності даних: DA = випуск даних ≠ пошук історичних даних

Вступ: що саме таке доступність даних? **Можливо, перше враження більшості людей таке, що «історичні дані в певний момент можна отримати», але насправді це найбільше непорозуміння концепції DA. **Нещодавно L2BEAT Lianchuang, ініціатор Danksharding, і засновник Celestia прояснили це непорозуміння. Вони зазначили, що Доступність даних насправді має означати «випуск даних», але більшість людей розуміють DA як «Історичні дані». можна відновити", а останнє фактично пов’язане зі збереженням даних.

Наприклад, Данкрад деякий час згадував механізм примусового відходу/евакуаційного люку рівня 2. Він зазначив, що для примусового відходу Validium потрібно отримати останній стан L2 для побудови Merkle Proof, але Plasma потрібен лише останній стан L2 за 7 днів тому (це відрізняється від двох. Це пов’язано з методом визначення законного державного root користувача).

Цим Dankrad чітко зазначив, що Validium вимагає DA для забезпечення безпеки коштів користувачів, а Plasma — ні. Тут приклад використання Dankrad вказує на різницю між DA та пошуком історичних даних, а саме те, що DA має тенденцію використовувати лише нещодавно опубліковані дані. **

У L2BEAT різниця між доступністю даних DA та зберіганням даних DS ще більш посилена. Бартек з L2BEAT неодноразово підкреслював, що DA і зберігання даних/історичні дані — це дві різні речі, і користувачі можуть отримати потрібні їм дані L2 лише тому, що вузли, які надають дані, «достатньо хороші для вас». Крім того, L2BEAT також планує використовувати «чи є вузли зберігання даних із відкритими дозволами» як новий показник для оцінки Rollup на додаток до DA.

Наведені вище зауваження членів спільноти Ethereum/Ethereum Foundation вказують на те, що в майбутньому вони стандартизуватимуть концепції, пов’язані з рівнем 2, і нададуть більш детальне визначення самого рівня 2. Оскільки багато термінів, що стосуються Rollup і L2, насправді недостатньо пояснено, наприклад, як давно дані вважаються «історичними даними», деякі люди думають, що оскільки смарт-контракти можуть викликати дані минулих блоків лише в межах 256 блоків, тому дані 256 блоків ( 50 хвилин) тому вважаються «історичними даними».

Строго кажучи, «зведений пакет», згаданий Celestia та Ethereum Foundation, — це дві різні речі. Ця стаття має на меті з’ясувати різницю між концепцією DA та зберіганням даних. Від джерела DA, вибірки доступності даних і реалізації DA Rollup ми пояснимо вам, що таке доступність даних – випуск даних. **

Джерело концепції DA

Стосовно того, до чого відноситься проблема «доступності даних», **засновник Celestia Мустафа пояснив це: **DA, коли генератор блоків пропонує новий блок, як переконатися, що всі дані в блоці випущені в мережу? Якщо генератор блоків не звільняє всі дані в блоці, він не може визначити, чи містить блок неправильні транзакції.

Мустафа також зазначив, що Ethereum Rollup просто публікує дані блоків L2 у ланцюжку Ethereum і покладається на ETH для забезпечення доступності даних.

**На офіційному веб-сайті Ethereum є таке резюме про DA: **Проблему доступності даних можна підсумувати як запитання: «Як перевірити, чи доступні дані нового блоку?»... Для легких клієнти Загалом проблема доступності даних стосується перевірки доступності блоку без завантаження всього блоку.

**Офіційний веб-сайт Ethereum також чітко розрізняє різницю між доступністю та отриманням даних: **Доступність даних стосується здатності вузла завантажувати дані блоку, коли пропонується блок. Іншими словами, доступність даних актуальна, коли блок ще не досяг консенсусу... Отримання даних стосується здатності вузла отримувати історичну інформацію з блокчейну... хоча для архівування може знадобитися історичні дані блокчейну, але вузли можуть перевіряти блоки і обробляти транзакції без використання історичних даних.

**На думку учасника Celestia China та партнера W3Hitchhiker Рена Хонгі, **Layer2 заздалегідь припускає, що Ethereum достатньо безпечний і децентралізований, і секвенсор може безпечно та сміливо надсилати дані DA в Ethereum, і ці дані поширюватимуться без перешкод. До всіх повних вузлів Ethereum. Сам повний вузол L2 повинен запускати клієнт Geth, який є підмножиною повного вузла Ethereum, щоб він міг отримувати дані рівня 2 DA.

**З точки зору доктора Ці Чжоу, засновника EthStorage, визначення DA полягає в тому, що ніхто не може зберігати дані транзакцій, надіслані користувачами в мережу. Відповідна модель довіри полягає в тому, що нам потрібно довіряти лише самому протоколу L1 і не потрібно вводити інші припущення про довіру.

Ці Чжоу зазначив, що поточний метод впровадження DA в Ethereum насправді є P2P-трансляцією (протокол пліток).Кожен повний вузол завантажуватиме та поширюватиме нові блоки та зберігатиме зведені дані. Звичайно, повні вузли Ethereum не зберігатимуть історичні блоки назавжди та можуть автоматично видаляти дані за певний проміжок часу (здається, 18 днів) після того, як 4844 виходить в Інтернет. **У світі небагато архівних вузлів, які зберігають усі історичні дані. **EthStorage має намір заповнити цю прогалину в системі Ethereum і допомогти Рівню 2 створити власний ексклюзивний вузол збереження даних.

Ранні обговорення Ethereum Foundation щодо доступності даних можна знайти в твітах Віталіка та документах на github у 2017 році. У той час він вважав, що якщо ми хочемо забезпечити масштабованість/високу ефективність блокчейну, нам потрібно покращити апаратну конфігурацію повного вузла (повний вузол — це вузол, який завантажує повний блок і перевіряє його дійсність, і валідатор, який досягає консенсусу, є підмножиною повного вузла). Однак, якщо апаратна конфігурація повного вузла буде покращена, операційні витрати будуть збільшені, що призведе до централізації блокчейну.

Стосовно цього моменту** Віталік сказав, що можна розробити рішення для усунення ризиків безпеки, спричинених централізацією високопродуктивних повних вузлів. ** Він планує запровадити кодування стирання та випадкову вибірку даних для розробки протоколу, щоб легкі вузли з апаратним забезпеченням нижчого класу могли знати, що з блоком немає проблем, навіть якщо вони не знають повного блоку.

Його початкова думка насправді була пов’язана з ідеєю, згаданою в документі про біткойн. Ця ідея говорить про те, що світлові вузли не потребують отримання повного блоку, і коли виникає проблема з блоком, чесний повний вузол видасть «тривогу», щоб сповістити світловий вузол. Цю ідею можна поширити на подальші докази шахрайства, але немає ніякої гарантії, що чесні повні вузли завжди можуть отримати достатньо даних, а також не можна судити згодом про те, чи пропонент блоку приховав певні дані та не оприлюднив їх.

Наприклад, певний вузол A може видати сертифікат про шахрайство, стверджуючи, що отримав неповний блок від вузла B. Але наразі неможливо судити, чи був цей неповний блок підроблений самим А чи надісланий Б. Віталік зазначив, що цю проблему можна вирішити за допомогою DAS вибірки доступності даних (очевидно, доступність даних по суті включає проблеми з випуском даних).

Віталік надає побіжне обговорення цих проблем та їх вирішення в «Примітці про доступність даних і кодування стирання». **Він зазначив, що сертифікат DA є, по суті, «завершенням» сертифіката про шахрайство. **

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

Але, очевидно, концепцію DA не так просто пояснити, адже документ Віталіка на github виправлявся 18 разів. Записи показують, що останнє виправлення було подано 25 вересня 2018 року. Буквально напередодні, 24 вересня 2018 року, засновники Celestia Мустафа та Віталік спільно опублікували статтю, яка стане відомою в майбутньому——Докази шахрайства та доступності даних: Максимізація легкої безпеки клієнта та масштабування блокчейнів з нечесною більшістю

Цікаво, що першим автором цієї статті є Мустафа, а не Віталік (інший автор зараз є дослідником у Sui Public Chain). У статті було згадано концепцію захисту від шахрайства, пояснено принцип вибірки доступності даних DAS і приблизний дизайн комбінованого протоколу DAS + двовимірне кодування стирання + захист від шахрайства. **У документі чітко зазначено, що система захисту від DA є, по суті, необхідним доповненням до захисту від шахрайства. **

Якщо ми почнемо з точки зору Віталіка, функцію цього протоколу можна підсумувати так:

Припустімо, що загальнодоступний ланцюг має N валідаторів консенсусного вузла з висококласним апаратним забезпеченням. Їх пропускна здатність даних велика, а ефективність дуже висока. Хоча такий блокчейн має високий TPS, кількість консенсусних вузлів N відносно невелика, він відносно централізований, і ймовірність змови вузлів висока.

Однак принаймні один із N вузлів консенсусу буде чесним. **Якщо принаймні 1/N валідаторів є чесними, **перевірте, чи блок недійсний, і готові транслювати докази шахрайства, коли це необхідно, легкі вузли або чесні валідатори можуть знати, що в мережі існує проблема безпеки , і може використовувати шкідливі вузли Slash і соціальний консенсус до форків та інших методів, які використовуються для відновлення нормальної мережі.

Однак, як згадував Віталік раніше, якщо чесний повний вузол отримує блок і виявляє, що в ньому бракує певних частин, і публікує сертифікат шахрайства, важко визначити, чи автор блоку не опублікував цю частину даних, або його заблокували. Інші вузли приховували його, або вузол, який видав сертифікат про шахрайство, діяв за власною ініціативою.

Крім того, якщо більшість вузлів вступить у змову, 1/N чесних валідаторів буде ізольовано та, можливо, не зможе отримати нові блоки. Це вважається сценарієм атаки із затримкою даних. Слід зазначити, що наразі чесний вузол не знає, чи поганий стан мережі, чи інші люди змовилися приховати дані.Він також не знає, чи інші вузли також ізольовані, і важко судити, чи більшість людей змовилися приховувати дані.

Підводячи підсумок, має бути спосіб гарантувати, що чесний валідатор може отримати дані, необхідні для перевірки блоку з дуже високою ймовірністю; у той же час, має бути можливість визначити, хто бере участь у атаках на приховування даних** - це пропонент блоку, який не опублікував. Якщо даних достатньо, кажуть, що вони все ще приховуються іншими вузлами, або більшість вузлів змовляються. Очевидно, що ця модель безпеки має набагато більше гарантій, ніж «припущення чесної більшості» звичайних ланцюжків POS, а вибірка доступності даних DAS є конкретним методом реалізації.

Тепер ми припускаємо, що в мережі є багато світлових вузлів, можливо, 10 N, і кожен світловий вузол підключений до кількох валідаторів** (для зручності аналізу передбачається, що кожен світловий вузол підключений до всіх N валідаторів). Ці легкі вузли запускатимуть вибірку даних у Validator кілька разів, випадковим чином запитуючи невелику частину даних щоразу (припускаючи, що це лише 1% блоку). Згодом вони передадуть витягнуті фрагменти валідаторам, які не мають цих даних. Якщо існує достатня кількість легких вузлів і час вибірки даних досить частий, навіть якщо деякі запити можуть бути відхилені, доки на більшість із них дається відповідь, можна гарантувати, що всі валідатори зрештою отримають достатньо дані, необхідні для перевірки блоку. Це може компенсувати вплив даних, які приховуються вузлами, відмінними від пропонента блоку. **

(Джерело зображення: W3 Hitchhiker)

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

На цьому етапі ми можемо розв’язати невизначеності, що виникають поза межами пропонента блоку. **Якщо пропонент блоку бере участь у приховуванні даних, *наприклад, він не публікує достатньо даних, необхідних для перевірки блоку в блоці (після введення двовимірного кодування стирання блок містить 2k*2k фрагментів, і Відновлення вихідних даних блоку вимагає принаймні приблизно k*k фрагментів, що становить 1/4. Автор пропозиції хоче, щоб інші не змогли відновити вихідні дані, і принаймні k+1*k+1 фрагментів потрібно бути утриманим), *Зрештою це буде виявлено чесним валідатором, який передасть докази шахрайства, щоб попередити інших *****. **

За словами Віталіка та Мустафи, вони фактично об’єднали ідеї, які були запропоновані раніше, і внесли на них певні нововведення. З точки зору відправної точки та реалізації всієї концепції, очевидно, що так звана «доступність даних» стосується того, чи дані, необхідні для перевірки останнього блоку, були опубліковані пропонентом блоку та чи можуть бути перевірені за допомогою верифікатор Отримуємо. **Це стосується того, «чи дані повністю опубліковані», а не «чи можна отримати історичні дані».

Як запровадити DA of Ethereum Rollup

З попереднім висновком давайте подивимося на реалізацію DA зведеного Ethereum. Насправді це відносно ясно: **Пропонент блоку в Rollup є секвенсором, який час від часу видаватиме перевірки на Ethereum. Дані, необхідні для переходу стану рівня 2 . **Якщо бути точним, це ініціювати транзакцію за вказаним контрактом, вставити дані, задіяні в DA, у спеціальні вхідні параметри та, нарешті, записати в блок Ethereum. Оскільки Ethereum достатньо децентралізований, ви можете бути впевнені, що дані, надіслані секвенсером, будуть успішно отримані «валідатором». Але те, що виконує роль «перевірника» в різних мережах Rollup, відрізняється.

*(Секвенсор Arbitrum розміщує пакети транзакцій у контракті на Ethereum. Сам контракт не перевіряє ці дані, а лише кидає подію для прослуховування повним вузлом L2, повідомляючи останньому, що секвенсор випустив пакет транзакцій ) *

Зокрема, ZK Rollup використовує контракт Verifier на Ethereum, щоб діяти як «верифікатор». **ZKR потрібно лише опублікувати принаймні State Diff + Validity Proof, **тобто зміни стану + підтвердження дійсності. Контракт Verifier виявить підтвердження дійсності, щоб визначити, чи може воно відповідати State Diff. Після проходження верифікації L2 Block/Batch, виданий секвенсором, вважається дійсним.

(Джерело: Former Polygon Hermez White Paper)

Найбільш оптимістичний Rollup опублікує більше даних про Ethereum, оскільки він може покладатися лише на повні вузли L2 для завантаження даних і перевірки дійсності блоку. **У цьому випадку має бути розкрито принаймні цифровий підпис кожної транзакції L2 (зараз зазвичай використовуються агреговані підписи), а якщо викликається контракт, мають бути розкриті вхідні параметри.Крім того, адреса передачі транзакції та Необхідно розкрити значення nonce, щоб запобігти атакам відтворення. Зачекайте. Але порівняно з повними даними транзакцій все ще є певне скорочення.

**Порівняно з ZK Rollup вартість оптимістичного зведення DA вища, **оскільки ZK Rollup потребує лише оприлюднювати остаточні зміни стану після виконання пакету транзакцій, а також має сертифікат дійсності, використовуючи переваги простоти ZK SNARK/STARK; Optimistic Rollup може використовувати лише найбільш громіздкий метод, що дозволяє повторно виконувати всі транзакції на інших повних вузлах L2.

Раніше W3hitchhiker приблизно підрахував, що без урахування майбутніх 4844 і блобів ефект розширення ZKR може сягати в декілька разів більшого, ніж OPR, а якщо врахувати 4337 пов’язаних розумних гаманців (заміна підписів приватного ключа даними відбитків пальців і райдужної оболонки ока), ZKR переваги будуть більш очевидними, оскільки йому не потрібно публікувати двійкові дані відбитків пальців і райдужної оболонки ока в Ethereum, тоді як Optimistic Rollup це робить).

Що стосується Validium і Plasma/Optimium, вони фактично використовують рівень DA під ланцюжком Ethereum для реалізації DA. Наприклад, ImmutableX, який використовує систему перевірки дійсності, створив набір вузлів DAC (Комітет доступності даних) для публікації даних, пов’язаних з DA; Metis публікує дані DA на Memlabs, а Rooch і Manta використовують Celestia. Наразі здається, що завдяки наявності DAS і системи захисту від шахрайства, **Celestia є одним із найбільш надійних проектів рівня DA за межами Ethereum. **

посилання

5