У чому проблема з доступністю даних?

! [У чому проблема з доступністю даних?] (https://piccdn.0daily.com/202310/25080444/tnfnxd82p4sv8fpe.jpg!webp)

Як у блокчейн-мережі ноди гарантують, що всі дані для нового запропонованого блоку доступні?

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

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

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

Наприклад, припустимо, Аліса є оператором ZK-Rollup. Вона надала ZK-Proof на Ethereum і пройшла верифікацію. Якби вона не надала всі дані про транзакції в Ethereum, користувачі зведеного рахунку все одно могли б не мати уявлення про баланс свого поточного рахунку, незважаючи на її доказ, який підтверджує, що всі зміни станів, зроблені в зведенні, були дійсними. Через характер нульового розголошення поданий доказ не може розкрити інформацію про поточний стан.

У випадку з Optimistic Rollup є аналогічний приклад, коли Аліса подає твердження щодо Ethereum, але учасники OPR не можуть перерахувати або оскаржити претензію, оскільки дані про транзакції недоступні.

У відповідь на вищесказане, як OPR, так і ZKR розроблені таким чином, щоб вимагати від операторів надсилати всі деталі транзакції в Ethereum як «calldata». Хоча це дозволяє їм уникнути проблем із DA в короткостроковій перспективі, зі збільшенням кількості транзакцій у зведенні зростає і обсяг даних, які потрібно надіслати, обмежуючи обсяг масштабування, який можуть забезпечити ці зведення.

Що ще гірше, недоступність даних – це помилка, яку не можна однозначно віднести. Це означає, що учасники не можуть довести іншим вузлам, що певний блок даних відсутній. Це пов’язано з тим, що Боб може транслювати, що в блоці, надісланому Алісою, відсутні дані, але Чарлі може надати дані Алісі, коли вона запитує його.

Як проблеми з доступністю даних впливають на поточні блокчейни?

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

Блок можна розділити на дві основні частини:

• Заголовок блоку: Невеликий заголовок блоку містить резюме та метадані, пов’язані з транзакціями, що містяться в блоці.
• Тіло блоку: містить всі дані про транзакції та формує основну частину блоку.

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

Може існувати інший тип вузла, який не має (або не хоче витрачати) ресурси для перевірки кожної транзакції. Швидше, вони в першу чергу зацікавлені в тому, щоб зрозуміти поточний стан блокчейну і те, чи включені в ланцюжок деякі транзакції, пов’язані з ними. В ідеалі, ці легкі клієнти також повинні бути захищені від підміни ланцюгами, що містять недійсні транзакції. Насправді цього можна досягти, використовуючи так званий доказ шахрайства. Ці лаконічні повідомлення показують, що певний блок містить недійсні транзакції. Будь-яка повна нода може надати такий доказ шахрайства, тому легким клієнтам не потрібно довіряти конкретній повній ноді, щоб бути чесними. Їм просто потрібно переконатися, що вони добре підключені до мережі пліток, яка гарантує, що якщо є доказ шахрайства заголовка блоку, вони його отримають.

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

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

Розглянемо це питання глибше на прикладі. Скажімо, блок-продюсер Аліса будує блок B, що містить транзакції tx 1, tx 2 、…、 txn. Припустимо, tx 1 - це шкідлива транзакція. Якщо транслюється tx 1, будь-який повний вузол може переконатися, що він шкідливий, і відправити цю інформацію як доказ шахрайства легкому клієнту, який відразу зрозуміє, що блокування неприйнятне. Однак, якщо Аліса хоче приховати tx 1, вона розкриває лише заголовок і всі дані про транзакції, крім tx 1. Повний вузол не може перевірити правильність tx 1.

Можна подумати, що простим рішенням було б, щоб усі легкі клієнти випадковим чином вибирали транзакції, і якщо вони виявлять, що їхня вибірка доступна, вони можуть бути впевнені, що блок доступний. Однак, якщо легкий вузол просять запитати будь-яку транзакцію випадковим чином, ймовірність того, що легкий клієнт зробить запит tx 1, дорівнює 1/n. В результаті Алісі майже завжди вдасться обманом змусити легкого клієнта прийняти шкідливу транзакцію. Іншими словами, більшість легких клієнтів підробляють. У зв’язку з неатрибутивним характером, повний вузол ніяк не може довести, що tx 1 недоступний. На жаль, збільшення розміру вибірки не робить ситуацію кращою.

Отже, як вирішити цю проблему?

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

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

Якщо ми змусимо блок-продюсера стерти транзакції tx 1, tx 2 、…、 txn, то для приховування однієї транзакції йому потрібно приховати n+ 1 фрагментів, тому що будь-яких n фрагментів достатньо для побудови всього набору транзакцій. У цьому випадку невелика кількість запитів може дати легкому клієнту високий ступінь впевненості в тому, що вихідні дані дійсно доступні.

Ого, так це все?

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

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

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

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

Отже, як працюють ці рішення?

Останнім часом поліноміальні обіцянки викликали новий інтерес до блокчейн-простору. Ці поліноміальні зобов’язання, особливо зобов’язання KZG/Kate постійного розміру для поліномів, можуть бути використані для розробки схеми чистої доступності даних (DA), яка не потребує доказів шахрайства. У двох словах, проміс KZG дозволяє нам зафіксувати многочлен за допомогою одного елемента еліптичної групи кривих. Крім того, схема дозволяє довести, що в певній точці i значення многочлена φ дорівнює φ(i), використовуючи свідчення постійного розміру. Ця схема зобов’язань є обчислювально зобов’язуючою та гомоморфною, що дозволяє нам вміло обходити докази шахрайства.

Ми змушуємо виробників блоків упорядковувати необроблені дані про транзакції у двовимірну матрицю розміром n x m. Він використовує поліноміальну інтерполяцію для розширення розміру n кожного стовпця до стовпця розміру 2 n. Кожен рядок цієї розширеної матриці генерує поліноміальне зобов’язання і посилає ці зобов’язання як частину заголовка блоку. Схематичне зображення блоку наведено нижче.

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

! [У чому проблема з доступністю даних?] (https://piccdn.0daily.com/202311/17064433/5gjxe19ptk6oa203.png!webp)

Схематичне зображення блоку

Більш детальні частини цього сценарію, а також подальша оптимізація та оцінка витрат виходять за рамки цієї статті. Однак ми хотіли б зазначити, що хоча тут ми говоримо про 2D-схему, аналогічні гарантії можуть бути надані і за допомогою 1D-схеми з меншим розміром блокового заголовка, але ціною зниженого паралелізму та легкої ефективності дискретизації клієнтів. Ми розглянемо це питання більш детально в наступній статті.

Які ще є альтернативи? Що буде далі?

Високорозмірне стирання коду та зобов’язання KZG – не єдиний спосіб вирішення проблем доступності даних. Тут ми пропустили кілька інших підходів, таких як кодування дерев Меркла, кодування перемежованих дерев, методи на основі FRI та STARK, але кожен з них має свої переваги та недоліки.

В Avail ми використовуємо зобов’язання KZG для розробки рішень для забезпечення доступності даних. У наступній статті ми розглянемо деталі реалізації, як нею користуватися та як ми плануємо змінити проблему доступності даних. Щоб дізнатися більше про Avail, слідкуйте за нами у Twitter

Twitter — це соціальна мережа, що походить зі Сполучених Штатів. 27 жовтня 2022 року Маск завершив придбання Twitter і об’єднав його з новоствореною компанією «Х». Згідно з попереднім повідомленням Маска в Twitter, він створить додаток «все включено», і згадав, що покупка Twitter може прискорити це бажання.

і приєднуйтесь до нашого сервера Discord.

Твіттер:

Ворожнечу:

Слідкуйте за Modular 101 у Twitter за номером @Modular 101