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

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

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

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

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

Існує аналогічний приклад в Оптимістичний Rollup (OPR)ситуація, де Еліс подає твердження на Ethereum, але жоден з учасників OPR не може викликати це, оскільки транзакційні дані недоступні, тому вони не можуть перерахувати або викликати твердження.

Для протидії вищезазначеним сценаріям обидві моделі OPR та ZKR вимагають від операторів надсилати всі деталі транзакцій Ефіріумяк 'calldata'. Це допомагає їм уникнути проблеми з DA в короткостроковій перспективі, оскільки кількість транзакцій у rollups зростає, обсяг даних, який потрібно надіслати, також зростатиме, обмежуючи масштабування, яке можуть запропонувати ці rollups.

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

Як це впливає на блокчейн сьогодні?

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

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

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

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

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

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

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

Давайте трохи глибше зануримося у проблему за допомогою прикладу. Припустимо, що виробник блоків Еліса складає блок В з транзакціями tx1, tx2, …, txn. Давайте припустимо, що tx1 - це зловмисна транзакція. Якщо tx1 транслюється, будь-який повний вузол може перевірити, що вона є зловмисною, і надіслати це легкому клієнту як доказ шахрайства, хто одразу ж знатиме, що блок неприйнятний. Однак, якщо Еліса хоче приховати tx1, вона розкриває заголовок і всі транзакційні дані, за винятком tx1. Повні вузли не можуть перевірити правильність tx1.

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

Так що ми робимо з цим?

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

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

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

Вау, отже, отже це все?

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

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

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

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

Так як працюють ці рішення?

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

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

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

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

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

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

Вищерозмірний код знищення та зобов'язання KZG - не єдині способи вирішення проблеми DA. Є інші шляхи, які ми пропустили тут, наприклад Закодовані дерева Меркла, Кодове Дерево з Інтерлівінгом, ПТ, а також підходи на основі STARK, але кожен має свої переваги й недоліки.

У Avail ми працюємо над рішенням доступності даних за допомогою зобов'язань KZG. У наступних повідомленнях ми розглянемо деталі впровадження, як ви можете використовувати це сьогодні і як ми маємо намір трансформувати простір проблеми DA. Для отримання додаткової інформації про Avail, слідкуйте за нами на Twitter та приєднуйтесь до нас Discord сервер.

Відмова від відповідальності:

1. Ця стаття була опублікована з [GateКоманда Avail]. Усі авторські права належать оригінальному автору [Команда Avail]. Якщо є зауваження до цього повторного друку, будь ласка, зв'яжіться з [GateGate Learn команду, і вони оперативно займуться цим.

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

3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.