Доступність даних

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

Доступність даних означає впевненість користувача в тому, що дані, необхідні для перевірки блоку, дійсно доступні для всіх учасників мережі. Для повних вузлів на першому рівні Ethereum це відносно просто; повний вузол завантажує копію всіх даних у кожному блоці — дані мають бути доступними, щоб завантаження стало можливим. Блок із відсутніми даними буде відхилено, а не додано до блокчейну. Це "ончейн-доступність даних" і є особливістю монолітних блокчейнів. Повні вузли неможливо змусити приймати недійсні транзакції, оскільки вони самостійно завантажують і виконують кожну транзакцію. Однак для модульних блокчейнів, зведень рівня 2 і легких клієнтів ситуація з доступністю даних є складнішою, що вимагає більш досконалих процедур перевірки.

Передумови

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

Проблема доступності даних

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

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

Доступність даних також є критичною проблемою для майбутніх клієнтів Ethereum "без стану", яким не потрібно завантажувати та зберігати дані стану для перевірки блоків. Клієнти без стану все одно мають бути впевнені, що дані доступні де-небудь і що вони були оброблені правильно.

Рішення щодо доступності даних

Вибірка для перевірки доступності даних (DAS)

Вибірка для перевірки доступності даних (DAS) — це спосіб перевірки мережею доступності даних без надмірного навантаження на окремі вузли. Кожен вузол (включно з вузлами, що не беруть участь у стейкінгу) завантажує невеликий, випадково вибраний фрагмент загальних даних. Успішне завантаження вибірок з високою впевненістю підтверджує, що всі дані доступні. Це ґрунтується на кодуванні з виправленням помилок, яке розширює певний набір даних надлишковою інформацією (це робиться шляхом підбору функції, відомої як поліном, до даних і обчислення цього полінома в додаткових точках). Це дає змогу за потреби відновити вихідні дані з надлишкових. Наслідком такого створення даних є те, що якщо будь-які з вихідних даних недоступні, половина розширених даних буде відсутня! Кількість вибірок даних, що завантажуються кожним вузлом, можна налаштувати так, щоб було надзвичайно ймовірно, що принаймні один із фрагментів даних, відібраних кожним клієнтом, буде відсутнім, якщо насправді доступно менше половини даних.

DAS використовуватиметься для того, щоб оператори зведень робили дані своїх транзакцій доступними після впровадження повного Danksharding. Вузли Ethereum будуть випадковим чином відбирати дані транзакцій, надані в блобах, використовуючи описану вище схему надлишковості, щоб переконатися, що всі дані існують. Цей самий метод можна також використовувати, щоб гарантувати, що виробники блоків роблять усі свої дані доступними для захищених легких клієнтів. Аналогічно, у разі розділення пропонента та конструктора тільки конструктор блоків повинен буде обробляти весь блок — інші валідатори будуть виконувати перевірку за допомогою вибірки для перевірки доступності даних.

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

Комітети з доступності даних (DAC) — це довірені сторони, які забезпечують або підтверджують доступність даних. Комітети з доступності даних (DAC) можна використовувати замість DAS або в поєднанні з нимopens in a new tab. Гарантії безпеки, які надають комітети, залежать від конкретної конфігурації. Наприклад, Ethereum використовує випадково вибрані підмножини валідаторів для підтвердження доступності даних для легких вузлів.

DAC також використовуються деякими валідіумами. DAC — це довірений набір вузлів, що зберігає копії даних поза мережею. У разі суперечки DAC зобов’язаний надати доступ до даних. Члени DAC також публікують ончейн-атестації, щоб довести, що зазначені дані дійсно доступні. Деякі валідіуми замінюють DAC системою валідаторів на основі доказу частки володіння (PoS). Тут будь-хто може стати валідатором і зберігати дані поза мережею. Однак вони повинні надати «заставу», яка вноситься в смарт-контракт. У разі зловмисної поведінки, як-от утримання даних валідатором, застава може бути конфіскована. Комітети з доступності даних на основі доказу частки володіння значно безпечніші за звичайні DAC, оскільки вони безпосередньо стимулюють чесну поведінку.

Доступність даних і легкі вузли

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

Легкі вузли Ethereum довіряють випадковим наборам із 512 валідаторів, які були призначені до комітету синхронізації. Комітет синхронізації діє як DAC, який за допомогою криптографічного підпису сигналізує легким клієнтам про правильність даних у заголовку. Щодня комітет синхронізації оновлюється. Кожен заголовок блоку сповіщає легкі вузли про те, які валідатори повинні підписати наступний блок, тому їх неможливо обманом змусити довіряти зловмисній групі, яка видає себе за справжній комітет синхронізації.

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

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

Це залежить від того, чи мають повні вузли доступ до повних даних транзакцій. Зловмисник, який транслює поганий заголовок блоку, а також не надає доступ до даних транзакцій, зможе перешкодити повним вузлам генерувати докази шахрайства. Повні вузли могли б попередити про поганий блок, але вони не змогли б підкріпити своє попередження доказом, оскільки дані для генерації доказу не були надані!

Рішенням цієї проблеми доступності даних є DAS. Легкі вузли завантажують дуже маленькі випадкові фрагменти повних даних стану та використовують ці вибірки для перевірки доступності повного набору даних. Фактичну ймовірність неправильного припущення про повну доступність даних після завантаження N випадкових фрагментів можна обчислити (для 100 фрагментів імовірність становить 10^-30opens in a new tab, тобто неймовірно мало).

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

Примітка: DAS і докази шахрайства ще не реалізовані для легких клієнтів Ethereum на основі доказу частки володіння, але вони є в плані розвитку і, найімовірніше, будуть реалізовані у формі доказів на основі ZK-SNARK. Сьогоднішні легкі клієнти покладаються на одну з форм DAC: вони перевіряють ідентичність комітету синхронізації, а потім довіряють отриманим підписаним заголовкам блоків.

Доступність даних і зведення рівня 2

Рішення для масштабування рівня 2, такі як , знижують вартість транзакцій і збільшують пропускну здатність Ethereum шляхом обробки транзакцій поза мережею. Транзакції зведень стискаються та публікуються в Ethereum пакетами. Пакети являють собою тисячі окремих транзакцій поза мережею в одній транзакції в Ethereum. Це зменшує перевантаження на базовому рівні та знижує комісії для користувачів.

Однак довіряти «зведеним» транзакціям, опублікованим в Ethereum, можна лише в тому випадку, якщо запропоновану зміну стану можна незалежно перевірити та підтвердити, що вона є результатом застосування всіх окремих транзакцій поза мережею. Якщо оператори зведень не нададуть дані транзакцій для цієї перевірки, вони можуть надіслати в Ethereum некоректні дані.

Оптимістичні зведення публікують стислі дані транзакцій в Ethereum і чекають певний час (зазвичай 7 днів), щоб незалежні верифікатори могли перевірити дані. Якщо хтось виявить проблему, він може згенерувати доказ шахрайства та використати його, щоб оскаржити зведення. Це призведе до відкату ланцюжка та пропуску недійсного блоку. Це можливо лише за умови доступності даних. Наразі існує два способи, якими оптимістичні зведення публікують дані транзакцій на рівні 1. Деякі зведення роблять дані постійно доступними як CALLDATA, які постійно знаходяться в мережі. Після впровадження EIP-4844 деякі зведення замість цього публікують дані своїх транзакцій у дешевшому сховищі блобів. Це не постійне сховище. Незалежні верифікатори повинні зробити запит до блобів і висунути свої оскарження протягом ~18 днів, перш ніж дані будуть видалені з рівня 1 Ethereum. Протокол Ethereum гарантує доступність даних лише протягом цього короткого фіксованого вікна. Після цього відповідальність лягає на інші суб’єкти екосистеми Ethereum. Будь-який вузол може перевірити доступність даних за допомогою DAS, тобто завантажуючи невеликі випадкові вибірки даних блобів.

Зведення з нульовим розголошенням (ZK) не потребують публікації даних транзакцій, оскільки гарантують правильність переходів стану. Однак доступність даних все ще є проблемою, оскільки ми не можемо гарантувати функціональність ZK-зведення (або взаємодіяти з ним) без доступу до даних його стану. Наприклад, користувачі не можуть дізнатися свої баланси, якщо оператор приховує деталі про стан зведення. Крім того, вони не можуть виконувати оновлення стану, використовуючи інформацію, що міститься в новому доданому блоці.

Доступність даних у порівнянні з можливістю їх вилучення

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

Можливість вилучення даних — це здатність вузлів отримувати історичну інформацію з блокчейну. Ці історичні дані не потрібні для перевірки нових блоків, вони потрібні лише для синхронізації повних вузлів із первинного блоку або для обслуговування конкретних історичних запитів.

Основний протокол Ethereum насамперед пов’язаний із доступністю даних, а не з можливістю їх вилучення. Можливість вилучення даних може бути забезпечена невеликою кількістю архівних вузлів, що керуються третіми сторонами, або може бути розподілена по всій мережі з використанням децентралізованого файлового сховища, такого як Portal Networkopens in a new tab.