Стан доказу шахрайства в ETH L2

1. Передмова

1.1. Майбутній напрямок оптимістичного Rollup

У вересні 2024 року Віталік виділив необхідність поліпшення стандарту Rollup та заявив:

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

Незалежно від того, чи я інвестував, чи ви мійдруг, ми повинні досягти першої стадії, інакше ні.

Система "фаз" Rollup - це фреймворк для оцінки рівня безпеки на грубому рівні від фази 0 до фази 2. У сучасних Rollup-рішеннях лише Arbitrum і Optimism досягли фази 1, більшість інших оптимістичних Rollup-рішень залишаються на фазі 0.

У цьому випадку виникло кілька проблем:

Звідки пройшло вже три роки з моменту введення Optimistic Rollup, але жоден проект не досяг найвищого етапу 2?
Коли можна очікувати досягнення Optimistic Rollup до фази 2?

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

1.2. Порівняння оптимістичного Rollup та ZK Rollup

Як всім відомо, швидкість ETH мережі повільна, а комісія за транзакцію висока. Дослідники та розробники ETH спільноти намагаються вирішити цю проблему. Після дослідження рішень, таких як Шардинг та плазма, спільнота вирішила, що Rollup є основним шляхом до досягнення масштабованості. Тому з'явилися рішення, такі як Arbitrum, Optimism та zkSync. За даними L2Beat, наразі працює приблизно 40 Rollup, а інші рішення, такі як Validium та Optimium, використовують alt-DA для досягнення більшої масштабованості, загалом їх близько 41. Крім того, очікується запуск приблизно 80 нових Rollup ланцюгів.

(Поточний стан L2 | Джерело:L2Beat)

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

Але це правда? Якщо пропонент обробки угоди в Rollup є зловживанням, що буде? Зловживник може змінити баланс Еліс, перевести його на свій рахунок і вивести його на Ethereum, що фактично означає крадіжку коштів Еліс.

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

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

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

**Зведення ZK **ZK Rollup вимагає не тільки валідатори для подання кореня стану, але й доказу ZK для перевірки правильності обчислення кореня стану. Якщо валідатори надішле неправильний корінь стану, доказ ZK не зможе пройти валідацію контракту валідації L1, запобігаючи поданню шкідливого кореня стану.
**Оптимістичний Роллап **Optimistic Rollup дозволяє валідаторам, які визначені без додаткових гарантій, відправляти корені стану на ETH-блокчейн на умові, що вони є чесними. Однак, якщо надісланий корінь стану неправильний, будь-хто може підняти сумнів та заборонити використання цього кореня стану в процесі виводу коштів. Сумніваючийся повинен надіслати докази до ETH-блокчейну, щоб підтвердити, що корінь стану є неправильним - це називається доказ шахрайства (Fraud Proof).

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

1.3. Чому потрібне доказ шахрайства?

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

Якщо не існує потужного механізму доказу шахрайства, то Optimistic Rollup не може повністю успадкувати безпеку Ethereum. Наприклад, у поточній системі дозволених валідаторів Arbitrum, якщо всі валідатори узгоджуються, вони можуть вкрасти всі кошти з мостового контракту. Так само, на Rollup на основі OP Stack, таких як Base, через те, що на Основній мережі ще не реалізовано механізму бездозвільного доказу неполадок, окремий злоякісний валідатор також може вкрасти кошти.

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

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

1.4. Крок до етапу 2: "Видалення підстраховуючих коліс"

Система доказу шахрайства відіграла ключову роль у процесі реалізації «фази 2» Optimistic Rollup. Фреймворк фаз, запропонований Віталіком, в даний час експлуатується L2Beat для оцінки рівня безпеки Rollup.

В екосистемі ETH Workshop цей етап часто порівнюють з навчанням їзді на велосипеді. Етап 0 Rollup, який найбільше покладається на припущення про довіру, порівнюється з триколісним велосипедом з тренувальними колесами, тоді як Phase 2 Rollup, який повністю успадковує безпеку ETH Square, порівнюється з двоколісним транспортним засобом зі знятими тренувальними колесами.

Нижче наведено детальні критерії для кожної з фаз 0-2:

Як зазначалося вище, для досягнення першої або другої фази Optimistic Rollup вирішальним є відповідна система доказу шахрайства та викликів. З урахуванням цих вимог, система доказу шахрайства, що задовольняє вимогам фази 2, повинна мати наступні характеристики:

Система працює добре, не має відомих дефектів і має функцію "1 з N".
Це система без ліцензії, в якій будь-хто може подати докази.
Якщо виявлені вразливості в системі доведені, то їх слід довести у блокчейні.

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

2. доказ шахрайства - Концепція та помилки

2.1. Як здійснюється доказ шахрайства?

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

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

доказ шахрайства та сумніви в протоколі, як правило, включають наступні кроки:

валідатори (провідники) регулярно надсилають до мережі ETH вихідні дані (або заяви) з коренем стану L2.
Якщо валідатори (чи суперечники) не погоджуються з цим виводом, вони порушують запитання.
Пропонент та сумнівник визначають розбіжність через процес, що називається двійковим або розчленувальним, уточнюють її до рівня інструкцій або рівня Блок (ZK Rollup).
质疑者在у блокчейні提交доказ шахрайства，证明不正确的部分。通常像 Arbitrum 和 Optimism 这样的协议会在у блокчейні执行可疑的指令以进行验证。
Якщо доказ шахрайства через перевірку, неправильний вивід буде вилучено або замінено. Згідно з протоколом, оскаржувач може бути покараний, а оскаржувач може отримати винагороду.

2.2. Поширені неправильні уявлення: доказ шахрайства та сумніви не будуть ланцюгом Відкат.

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

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

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

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

2.3. Реальний приклад: сумніви Kroma у квітні 2024 року

Через конкретний приклад сумніву можна бачити, що увесь ланцюжок Rollup не буде відкатуватися, лише корінь виводу буде замінено або видалено. На даний момент єдиний відомий успішний приклад сумніву на Основній мережі відбувся в квітні 2024 року з Kroma, який є гібридним Rollup на основі OP Stack з використанням ZK доказу несправності.

Kroma - це Stack based Rollup OP з власною системою ZK Fault Proof та безліцензійними валідаторами. 1 квітня 2024 року виникла проблема з джерелом L1 сортувальника Kroma, що призвело до створення неправильного Блоку сортувальником. Крім того, валідатори, які спостерігали за цією ситуацією, подали неправильний кореневий вивід. Впродовж короткого часу після подачі кореневого виводу, 12 осіб, які сумніваються, підняли сумніви щодо цього виводу.

Один з критиків успішно викликав функцію proveFault та видалив неправильний вивід.

Спірники успішно виконують функцію proveFault | Джерело:etherscan

Це перший успішний випадок суперечки на Основній мережі в історії Ethereum Rollup. Це також перший випадок успішної перевірки та суперечки недійсних доказів у середовищі Основної мережі після приблизно трьох років з моменту запуску першого оптимістичного Rollup (Arbitrum) у травні 2021 року. Докладний опис суперечки можна знайти у статті, написаній Kroma. У цьому випадку ланцюг Kroma не виконував Відкат, лише видалив невірний вихідний корінь.

Відмова від відповідальності: доказ шахрайства чи доказ несправності?

доказ шахрайства також відомий як доказ шахрайства. Зокрема, у ланцюгах Optimism і OP Stack використовується термін "доказ шахрайства", тоді як у проектах Arbitrum, Cartesi, L2Beat тощо використовується термін "доказ шахрайства".

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

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

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

3. Хакерська атака! - Використання механізму доказу шахрайства

3.1. Розробка протоколу економічних суперечок

Кожен Optimistic Rollup має свій власний механізм доказу шахрайства та спірних питань, щоб захистити кошти користувачів. Спільна мета цих механізмів полягає в тому, що «якщо є принаймні один чесний учасник, то протокол може залишатися безпечним». Доказ шахрайства - це доказ того, що передбачена функція переходу стану виконується правильно, і через процес перевірки в результаті переможе чесний учасник.

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

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

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

Отже, у цьому розділі спочатку ми розглянемо наступне Вектор атаки, а потім дослідимо, як кожний протокол реагує на ці напади:

Через атаку, спричинену вразливістю у грі, що стала предметом суперечок;
затримка атаки, продовження часу виведення коштів для користувачів більше 7 днів;
Сибіл-атака, яка витрачає кошти та ресурси чесних учасників;
Атака, спровокована валідаторами L1;
Зловживання доказами шахрайства, запущені через вразливість у віртуальній машині.

Увага: всі обговорені вектори атаки відомі публіці і не впливають на безпеку будь-якої основної мережі.

Наступні розділи розглянуть протоколи та їх відповідні особливості наступним чином:

3.2. Вектор атаки #1：利用经济争议游戏

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

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

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

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

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

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

3.2.1. Вектор атаки #1-1: затримка атаки

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

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

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

Однак потрібно враховувати деякі фактори. Якщо зловмисник не боїться розрізання коштів і все ж намагається провести атаку затримки, що робити?

Цей вектор атаки досить складний. Тому й система доказу шахрайства Arbitrum наразі працює в ліцензованій структурі.

Механізм доказу шахрайства, який застосовується в Arbitrum One і Arbitrum Classic, використовує модель гілок. Замість простого дозволу учасникам сумніватися у неправильних заявах, кожен учасник може подати свою вважану за правильну заяву, приклавши певну кількість коштів, і розглядати їх як «форк ланцюга». Заяви також можуть бути розглянуті як контрольні точки стану ланцюга.

Модель гілки Arbitrum

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

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

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

Оскільки кожне запитання може зайняти до 7 днів, зловмисник може продовжити затримку протоколу до 7 * (N-1) днів.

Відкладена атака для Arbitrum Classic | Джерело: [L2Beat Medium] (https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

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

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

3.2.2. Вектор атаки #1-2: Сибіл-атака (атака на вичерпання ресурсів)

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

Зазвичай, вказаний Вектор атаки може статися у неліцензованій системі за допомогою наступних двох способів:

Постійно надсилає неправильний вивід. Припустимо, що фонди атакуючого Боба перевищують загальну суму чесних учасників (захисників) Еліс, Чарлі та Девіда. У цьому випадку Боб постійно надсилає неправильний корінь виводу. Чесні учасники Еліс, Чарлі та Девід відповідатимуть, оплачуючи газовий збір та заставу, і при певному пороговому значенні кошти чесних учасників будуть вичерпані раніше, ніж у Боба. У цей момент Боб надсилає ще один неправильний вивід, оскільки в мережі не залишилося чесних учасників з залишковими коштами, цей вивід врешті-решт підтвердиться без будь-яких сумнівів. Таким чином, Боб може вкрасти кошти з оптимістичного rollup.
Направте декілька сумнівів щодо чесного виведення. Навпаки, зловмисний учасник може атакувати чесного учасника, подаючи декілька сумнівів. Так само атака буде тривати, поки чесний учасник не витратить всі кошти, призначені для газу та застави, після чого зловмисний нападник подасть неправильний вивід та вкраде кошти користувачів змісту.

Для того щоб запобігти такій атакі, необхідно раціонально спроектувати переваги захисника над нападником. У всіх випадках захисник повинен мати достатньо переваги над нападником. Один з способів досягнення цього - ретельне проектування застави; оскільки Сібільська атака пов'язана з загальною сумою коштів, доступних кожному учаснику, якщо заставу встановлено належним чином, можна визначити, що "система безпечна в тому випадку, якщо загальні кошти нападника не перевищують N-кратно загальних коштів захисника".

Ще одним відомим методом запобігання атакам Сібіл є впровадження протоколу, який спротивляється Сібіл. У наступних розділах ми подальше розглянемо Картезі Дейв.

Давайте подивимося, як кожен протокол вирішує ці затримки та атаки Сібіл через свій власний дизайн.

3.3. Рішення № 1: Економічна гра конфліктів

1) Арбітраж BoLD

На основі моделі гілок Arbitrum Classic, BoLD вводить наступні три елементи для запобігання вразливостям затримки атаки:

Усі до всіх механізмів сумніву. У BoLD сумнів більше не проводиться парами, але має місце одночасне володіння всіх систем учасників, які можуть заставити гроші на гілці, з якою вони згодні. Це запобігає затримці вектора атаки, що виникає від попереднього один на один сумніву, і забезпечує неможливість декількох незалежних сумнівів щодо однієї й тієї самої суперечки.
Докази з правильними станами, які запобігають зловживанню двійковим діленням (історичні зобов'язання). Проблема в Arbitrum Classic полягає в тому, що зловмисники можуть зловживати двійковим діленням, намагаючись наміряно затримати і позначити суперечливу частину як безсуперечну. Для цього BoLD вимагає подання доказів, які разом з коренем стану перевіряють, що корінь стану був правильно обчислений під час двійкового ділення, щоб гарантувати відсутність зловмисного ділення.

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

Отже, якщо зловмисник хоче декілька разів розділити чесні заяви в BoLD, він повинен подати кілька заяв.

Однак, генерація цього підтвердження вимагає від валідаторів використання значних обчислювальних ресурсів. Внутрішньо, генерація цього підтвердження вимагає генерації хешу для всіх станів у двійковому пошуку, що в Arbitrum зазвичай оцінюється на близько 270 хешів (приблизно 1,18 x 10²¹). Щоб вирішити цю проблему, BoLD розподіляє сумнів на три рівні, зменшуючи кількість необхідних обчислень хешу до 226 (приблизно 6,71 x 10⁷).

(Цей графік припускає, що загалом є 269 інструкцій, фактичні дані можуть відрізнятися)

Обмежити час застейкати механізмом годинника.

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

Припустимо, що два учасники подали різні заяви. У кожного учасника є таймер (шаховий годинник) з часом 6,4 днів. Коли настає черга учасника подати подвійку або доказ, таймер починає відлік і зупиняється після завершення завдання учасником.

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

Завдяки цим механізмам Arbitrum BoLD ефективно обмежує затримки, спричинені запитаннями. Максимальна тривалість запитання становить два тижні, а максимальна додаткова затримка, яку користувач може зазнати, становить приблизно один тиждень.

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

Arbitrum обчислює цю суму в економічному документі BoLD. Основною причиною затримки протоколу є перевірка валідаторів L1. У разі атаки затримки сценарій буде наступним:

Нападник підтверджує наявне заяву N на Arbitrum перед тим, як подати заяву N', яка не відповідає їй.
Захисник намагається відправити транзакцію, але через те, що L1 валідатори перевіряють суперечну транзакцію захисника, операція не вдалася.
У зв'язку з припущенням BoLD, що перевірка не може тривати більше 7 днів, це може призвести до остаточного підтвердження N затримка не більше одного тижня.

Прибуток атакуючого походить з можливого витрати часу користувача, який сумнівається у виведенні виведення. У найгіршому випадку всі кошти у Arbitrum знаходяться в одному виведенні, і витрати часу користувача обчислюються наступним чином, припускаючи, що TVL Arbitrum One становить 154 мільярди доларів США, APY - 5%:

Вартість можливості = 15,400,000 x (1.051/52 - 1) = 14,722,400 доларів США

Оскільки неправильна декларація може призвести до таких високих витрат, учасники BoLD зобов'язані вносити подібний заставний депозит. Наразі заставний депозит для подання декларації в BoLD становить 3600 ETH, що приблизно дорівнює 940 мільйонам доларів.

Це робиться для запобігання атакування системи через затримку, яке може призвести до значних втрат. Оскільки атакування втратить свій заставний депозит у випадку спростування, вони можуть зазнати втрати від 14,7 мільйонів доларів, але втрати коштів становитимуть близько 9,4 мільйонів доларів. Тому BoLD стримує атаки затримкою, вимагаючи, щоб заставний депозит був порівняний з можливими втратами у найгіршому випадку.

Проте застава в розмірі 3600 ETH не встановлена лише через атаку затримки. Щоб захистити від атаки Сібіла, Arbitrum BoLD забезпечує безпеку системи, поки загальні кошти нападника не стануть на 6,5 рази більше, ніж загальні кошти оборонця, що і є підставою для визначення розміру застави в розмірі 3600 ETH.

З точки зору атаки Сібіл, на Arbitrum BoLD можуть виникнути наступні сценарії атаки. Система сумніву BoLD складається з трьох рівнів, користувачі повинні заблокувати кошти, щоб надіслати свої правильні заяви.

Припустимо, що чесний учасник Аліса подає дійсне заяву на суму X ETH. Зловмисний учасник Боб, який має 3600 ETH, може створити кілька зловмисних заяв. В такому випадку Алісі потрібно заблокувати Y ETH на нижньому рівні для кожної заяви Боба.

У моделі розгалуження Arbitrum заблокування коштів означає погодження стану ланцюжка від генезису до заявлення. Ця функція дозволяє учасникам переміщати забезпечені ними кошти з заявлення A на його дочірні заявлення A' та A''. Таким чином, Еліс переміщує свої початково заставлені X ETH на нижчий рівень та блокує Y ETH для кожного злоякісного заявлення Боба.

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

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

Arbitrum називає цей показник відношення ресурсів. Це показує ступінь переваги чесного учасника над зловмисними учасниками. Це співвідношення показується через відношення плати за газ (G) та заставної суми (S), яку повинен сплатити кожен учасник, як показано нижче:

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

（Верховний рівень вартості застави та співвідношення ресурсів Arbitrum BoLD | Джерело:Desmos)

Згідно з цією діаграмою, коли співвідношення ресурсів становить 100, зверху потрібна застава перевищує 1 мільйон ETH (понад 4 трильйони доларів). Хоча вищі співвідношення ресурсів зробили б систему більш безпечною щодо запобігання Сібіл-атакам, застава стала настільки високою, що майже ніхто не може брати участь в системі, що робить її нічим не відмінною від централізованої системи з одними валідаторами, які подають заяви.

Таким чином, у BoLD відношення ресурсів становить 6.5, що робить верхню заставу 3600 ETH, а першого та другого рівнів заставу відповідно становлять 555 ETH та 79 ETH.

Загалом, BoLD через розрахунок відношення ресурсів та встановлення суми застави забезпечує, що захисник має на 6.5 разів більше переваг, ніж нападник, щоб запобігти атакам Sybil.

2) Картезі Дейв

Dave від Cartesi вперше запропонував у грудні 2022 року у статті під назвою "Турнір несанкційного розгляду", що була опублікована раніше, ніж перша Біла книга BoLD. Його метою є збереження переваги обчислювальних ресурсів та фінансових активів чесних учасників порівняно з атакуючими. Структура Dave схожа на BoLD і має дві ключові особливості:

Запобігайте зловживанням поділу, обчислюючи підтвердження правильного стану (історичні зобов'язання).

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

У структурі чемпіонату використовується механізм запитань один на один.

Спроби Дейва не є одноразовими, а проводяться у формі турніру, як показано на наступному малюнку.

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

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

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

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

Td = 7 x log2(1 + NA) (днів)

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

Td = 7 x [log2(1 + NA)]L (днів)

Де LLL означає кількість рівнів у кожному сумніві. Якщо, як показано на рисунку, є сім зловмисних заяв і L = 2, повне вирішення сумніву може зайняти до 9 тижнів, користувачам доведеться дочекатися затримки затримки ще 2 місяці. Якщо кількість рівнів або кількість зловмисних заяв збільшується, затримка може тривати кілька місяців.

Cartesi має на меті використовувати Доказ із нульовим розголошенням (ZK) для вирішення цієї проблеми, докладне обговорення буде проведено у розділі 4 "Можливі покращення".

3) Оптимістичне доведення помилок (Optimism Fault Proof, OPFP)

OPFP є неліцензований протокол з питань якості, який зараз застосовується на Основній мережі OP і має наступні особливості:

Всі механізми сумніву щодо паралельних запитів, які використовують дерево гри

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

OPFP архітектура гри виправданості та процесу розбиття навпіл дерева | Джерело: Файл оптимізму

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

Ця структура дозволяє подвоєння. Наприклад, якщо один валідатори не погоджується з кореневими заявами (Нода 1), вони подадуть заяву на Нода 2, Нода 2 відповідає Нода 23 у дереві, оскільки вона є середньою точкою між Нода 16 та Нода 31. Подавач Нода 1 потім перевірить стан L2 Нода 23, якщо погоджується, то подасть Нода 6 (Нода 27); якщо не погоджується, то подасть Нода 4 (Нода 19), і цей процес триватиме до виявлення розбіжностей.

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

Повна архітектура грального дерева OPFP | Джерело: Файл оптимізму

У використанні OPFP дерево гри є вкладеною структурою, верхнє дерево обробляє двійкове розбиття на рівні Блоку, а нижні піддерева обробляють двійкове розбиття на рівні інструкцій.

У відміну від BoLD або Dave, OPFP не змушує виконувати правильний розподіл на основі історичних обіцянок, оскільки створення та надання таких обіцянок поза блокчейном/у блокчейні є дорогим.

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

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

Цікаво, кожен учасник має дозвіл на 3,5 дні замість 7 днів, що означає, якщо ніхто не ставить під сумнів вихідні дані, то вони будуть остаточно затверджені протягом 3,5 днів.

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

Процес виведення коштів користувача в «Щасливому шляху» | Джерело: Блог OP Labs

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

Це виносить на поверхню питання: чи можливо, що користувачів буде затримано з зняття коштів на OPFP на більш як тиждень, аналогічно до ситуації з BoLD? Відповідь - "так". На відміну від BoLD або Дейва, Optimism надає користувачам можливість відповідати на питання, що базується на унікальних особливостях протоколу.

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

Аліса подала заявку на визначення правильного кореня стану.
Боб подав протест, а Аліса вжила заходів для захисту своєї початкової заяви.
Коли Боб майже вичерпав свій термін (3,5 дня), він поставив під сумнів своє заявлення.

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

Заява про хвилювання безвідповідальністю від Optimism Fault Proof | Джерело:L2Beat

Хоча це не заважає вирішенню сумнівів, воно справді представляє собою певну ситуацію, а саме "подання невірного заявлення, але не розривання Маржа", з точки зору стимулювання цю ситуацію слід уникати.

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

Ми можемо уявити сценарій, в якому цей механізм використовується для затримки атаки. Припустимо, що чесний учасник Еліс подає правильний вихідний сигнал, і з моменту подання Еліс починається таймер сумнівів. Зловмисний учасник Боб подає неправильний вихідний сигнал за 1 секунду до закінчення таймера сумнівів. Згідно з правилами OPFP, час Боба продовжується на 3 години. Еліс відповість, а Боб продовжить користуватися додатковими 3 годинами, які надаються для кожного поділу.

Це може призвести до затримки вирішення сумнівів. Максимальний час затримки для Боба становить 3,5 днів + 3 години × максимальна кількість подвоєння. MAX_GAME_DEPTH для OPFP дорівнює 73, що означає, що Боб може затримати процес на 3,5 днів + 3 години × 36 = 8 днів. Якщо Еліс також приймає схожі заходи для затримки сумніву, процес подвоєння може зайняти 16 днів.

Це означає, що користувачі не зможуть зняти кошти протягом 16 днів? Насправді це не так, оскільки механізм зняття коштів Optimism не дозволяє такій ситуації створитися. На відміну від Arbitrum, який вимагає, щоб зняття коштів було підтверджено включенням у певний L2 Блок, OP Stack використовує механізм збереження підтвердження, а запити на зняття коштів реєструються в контракті L2ToL1MessagePasser на L2. Це означає, що навіть якщо спірному виходу займає багато часу, користувач все одно може зачекати на наступний вихід і зняти кошти на основі кореня контракту, який міститься в цьому виході. Тому, навіть якщо їх запит на зняття коштів знаходиться під сумнівом, користувачам не потрібно чекати довгою затримкою, оскільки вони можуть використовувати наступний вихід.

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

Запустіть виведення коштів на L2 (initiateWithdrawal).
Доведення зняття коштів на L1 (proveWithdrawalTransaction) включає в себе вихідні дані зняття коштів.
Очікуйте на завершення підтвердження затримки протягом тижня, а потім остаточно завершіть транзакцію зняття коштів (finalizeWithdrawalTransaction).

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

Отже, користувачі, які не усвідомлюють сумнів або реагують пізніше, можуть зазнати додаткового затримки зняття коштів до 9 днів.

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

Сума маржі OPFP | Джерело: [Optimism File] (https://specs.optimism.io/fault-proof/stage-one/bond-incentives.html)

Іншими словами, чим довше атакувач затримує час вирішення сумніву в OPFP, тим вищою буде вартість Маржа, оскільки вимога до Маржа зростає експоненційно, що зменшує стимули до атаки затримки з плином часу. Крім того, оскільки виведення в OPFP може бути подано в будь-який час, важко зрозуміти атакуючому, які ресурси потрібні для атаки затримки. Початкове значення Маржа становить 0.08 ETH, а загальна Маржа, яку потрібно подати під час повного сумніву, становить приблизно 700 ETH.

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

У OPFP можливі наступні Вектор атаки Sybil, які можуть призвести до крадіжки коштів користувача:

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

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

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

Проте, для переходу OPFP до фази 2, Optimism повинна змінити механізм, щоб забезпечити захисникам більшу перевагу над нападниками. Optimism готує спірне гри V2 для вирішення цієї проблеми, більше деталей буде представлено в розділі 4 "Можливі покращення".

4) Доказательство неисправности Kroma ZK (Kroma ZKFP)

Kroma - це L2 на основі стеку OP, яка була запущена на своїй основній мережі у вересні 2023 року, перед впровадженням OPFP, безліцензійна система ZK з доказами відмови. Kroma ZKFP має схожі характеристики з OPFP, але його особливість полягає в використанні ZK для створення доказів на рівні блоків і використанні розкладу замість двійкового розкладу, що значно зменшує кількість взаємодій, необхідних для процесу виклику. Основні характеристики Kroma ZKFP узагальнено таким чином:

Зменшення кількості взаємодій за допомогою ZK та розкладу

Kroma ZKFP дозволяє учасникам знайти розбіжності протягом чотирьох взаємодій. Під час виникнення сумніву Kroma ZKFP обробляє сумнів на 1,800 блоках, від попереднього виводу до поточного виводу. На відміну від бінарного пошуку, де діапазон розділяється навпіл, у розкладанні пропонент та сумнівник розділяють діапазон на N частин. Процес виглядає наступним чином:

Після того як кожен учасник подасть дві угоди, вони визначать Блок, в якому вони мають розбіжності, і сумнівник може створити доказ несправності ZK, щоб показати, що твердження пропонента є невірним. У Kroma ZKFP двохвилинний таймаут встановлено на 1 годину, а таймаут для створення доказу ZK становить 8 годин.

Реалізація Децентралі zats_ії за допомогою механізму стимулювання

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

Для цього Kroma змінила OP Stack, розподіливши половину комісій згенерованих у блокчейні Gas між валідаторами, які подають вихідні дані. Крім того, Kroma планує після TGE перенести цей механізм винагород на свій власний Токен KRO і має на меті впровадити систему валідаторів, подібну до DPoS, щоб звичайні користувачі могли вносити вклад у безпеку та активність ланцюжка, не запускаючи власний клієнт.

Сума Маржа в Kroma наразі становить 0,2 ETH, щоб забезпечити його більшим за витрати на створення ZK-профілю та поділу. Ця Маржа стане заставою за KRO у майбутній системі валідаторів.

Система виклику на 1 на 1 з викликом

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

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

Строгий тайм-аут означає, що навіть зловмисники, які намагаються здійснити затримку атак, повинні завершити всі поділ і генерацію доказів протягом 10 годин. Крім того, оскільки заявнику доведеться завершити всі операції протягом 6 днів (не включаючи період контролю протягом 1 дня), то в Kroma неможливо здійснити загальну затримку атаку.

Однак, якщо сума коштів нападника перевищує суму коштів захисника, Kroma ZKFP все ще зазнає ризику Sybil-атаки, схожої на OPFP. У сценарії Sybil-атаки в Kroma ZKFP можуть мати місце такі ситуації:

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

Крома ZKFP, схоже з OPFP, після успішного виклику буде видалено відповідний вивід. Отже, якщо станеться такий атака, відповідний вивід може бути видалено, що призведе до затримки вилучення коштів на 1 годину. Якщо атака триватиме, всі чесні валідатори можуть вичерпати кошти, що призведе до підтвердження помилкового виводу, що в свою чергу дозволить зловмиснику вкрасти кошти користувача.

Крім того, Kroma ZKFP все ще знаходиться на етапі 0, його система підтвердження ще не є повноцінною, причини наступні:

Початок поділу ґрунтується на останньому виводі, а не на остаточному підтвердженні виводу.

У OPFP початок розділення зазвичай є останнім підтвердженим виходом приблизно тиждень тому. Але в Kroma ZKFP початок є останнім поданим виходом, який було подано близько години тому, а процес розділення відбувається на 1 800 блоках.

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

Не було перевірки того, чи кожен валідатор основується на правильних пакетних даних.

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

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

Однак у практиці комісія із безпеки може втрутитися, щоб відкликати результати неправдивих сумнівів або видаляти недійсні виходи, тому ці Вектор атаки не впливатимуть на кошти користувачів мережі Kroma Основна мережа. Однак, для досягнення етапу 2, Kroma ZKFP повинна впровадити механізми захисту від цих вразливостей. Kroma вже запропонувала поліпшення з приводу цих питань, які будуть детально описані в розділі 4 «Можливі покращення».

3.4 Вектор атаки #2：L1 审查

Раніше ми згадували, що Rollup успадковує безпеку Ethereum. Це означає, що якщо безпека Ethereum буде скомпрометована, це також вплине на Rollups.

Існує два сценарії, в яких стан Ethereum може впливати на безпеку Rollup:

Перевірка транзакцій Rollup на доказ шахрайства ETH буфером перевірки. Якщо верифікатори або будівельники ETH фальшиві, подають зловмисний корінь виведення в Optimistic Rollup, одночасно переглядають всі угоди, пов'язані з доказом шахрайства, що стосуються, що станеться? Сумнів не буде розв'язаний протягом визначеного строку, виведення буде підтверджено, кошти користувачів можуть бути під загрозою. Це називається слабкою перевіркою. У випадку Optimistic Rollup, якщо ця перевірка триватиме більше встановленого часу (зазвичай 7 днів), кошти користувача можуть бути під загрозою.
**Ефіріум став жертвою атаки 51%, що спричинило перевірку всіх доказ шахрайства угод **Ця ситуація включає в себе два можливих шляхи атаки:

По-перше, суб'єкт може отримати більше 2/3 від загальної кількості застейкованих ETH, що дозволить йому вільно підтверджувати блоки. У цьому випадку зловмисник може перевіряти шахрайство доказів угод, навіть випадково генеруючи такі угоди.
Другий метод передбачає "прихований" напад, в якому учасник, який має більше 1/3 від загальної кількості заставки ETH, може перешкоджати підтвердженню будь-якого Блоку, який йому не подобається. Якщо нападник продовжує голосувати за звичайні Блоки, у той час як він мовчить про Блоки з доказами шахрайства, він може підтвердити зловмисний вихідний корінь, що дозволить йому вкрасти кошти з Optimistic Rollup. Це відомо як неатрибутний цензурний напад на доказово засновані L2 протоколи. Цей вид нападу складніший для виявлення, ніж просте отримання більше 2/3 заставки та контроль всіх Блоків ETH.

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

3.5 Рішення №2: Затримка у 7 днів для виводу коштів та напівавтоматичне відновлення після 51% атаки

Для того щоб протистояти цим Вектор атаки, Optimistic Rollup наразі реалізує 7 днів виведення затримки. Ці 7 днів спочатку були запропоновані Віталіком, ґрунтуючись на ідеї того, що 7 днів є "достатньо" для протидії атакам на перевірку.

Давайте проаналізуємо, чи достатньо 7-денного періоду сумнівів у Optimistic Rollup, щоб захиститися від цензурних атак, розглянемо два типи цензури: слабка і сильна цензура.

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

Тут потрібно врахувати два фактори:

Щоб успішно сформувати суперечку протягом 7 днів, необхідно мати декілька успішних транзакцій.

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

Необхідно розумно припустити процент валідаторів, які підлягають перевірці. Наразі більшість будівельників блоків у форках ETH (відомих як централізовані) не перевірені, з урахуванням того, що на ETH в основному відсутня пропорція самостійних стейкерів, ймовірність спільного проведення перевірок відсутня (наприклад, 99,9%)валідаторів майже нульова).

(Огляд головних Блок будівельників Ethereum | Джерело: Твіт Джастіна Дрейка)

Беручи до уваги ці два моменти, якщо ми припустимо, що 99.5% валідаторів (що все ще є занадто екстремальним припущенням) беруть участь у перевірці, і обчислити ймовірність успішного надсилання 30-40 опротоколу (такого як BoLD або OPFP) біржі від чесних учасників, то в усіх випадках ймовірність успіху становить майже 100%. Крім того, з появою майбутніх рішень (таких як включення списку або кількох конкуруючих пропозицій, наприклад BRAID, APS + FOCIL), можливість протистояти перевірці може подальше зміцнитися, що зменшить ризик Падіння Optimistic Rollup через слабку перевірку від користувачів.

Таким чином, 7 днів достатньо при сильній перевірці? Атака 51%, згадана вище, може бути вирішена лише за допомогою соціального форку. Атаки, які не можна пов'язати з перевіркою, особливо складно виявити і неможливо запобігти заходами, спрямованими на слабку перевірку (наприклад, включення до списку).

Є пропозиція розробити напівавтоматичний інструмент відновлення випадку атаки 51% в клієнтському програмному забезпеченні, який ґрунтується на структурі, запропонованій Віталіком. Дослідники з Ethereum подальшим розробили це рішення для виявлення та аналізу, розділене на два етапи:

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

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

У такому випадку кошти, які постраждали від атаки 51%, мають залишатися заблокованими до завершення соціального форку. Під час Хардфорка The DAO відбувалася подібна ситуація, коли кошти Хакера були заблоковані в підрозділі DAO на протязі 27 днів, поки він не зміг їх вивести. Протягом цього часу спільнота Ethereum здійснила успішний хардфорк, що запобігло Хакеру зняти свої кошти (див. докладнішу інформацію у пості Віталіка на Reddit).

Іншими словами, навіть у випадку атаки на 51%, кошти все одно потрібно утримувати в захопленні до проведення форку спільноти. У цьому випадку період виведення коштів тривалістю 7 днів в Optimistic Rollup виступає як буферна зона. Якщо протягом цього тижня не буде проведено форк спільноти, кошти користувачів в Optimistic Rollup можуть бути вкрадені, або виведені на централізовану біржу, або через Tornado Cash змішані, в результаті чого кошти практично неможливо повернути користувачам після форку спільноти.

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

З цього кута зору деякі критикують OPFP за скорочення цього терміну до 3,5 днів, що робить його більш вразливим до атаки інтенсивної перевірки. Однак ця критика не має підстав. Оскільки Optimism все ще перебуває на етапі 1, опікунам достатньо часу для перевірки правильності кореня стану, а виведення коштів може відбуватися лише після закінчення додаткового 3,5-денного періоду опіки. Тому навіть при інтенсивній атакі перевірки, зловмиснику все одно доведеться чекати 7 днів, щоб вивести кошти. Крім того, зловмисник повинен успішно переглянути всі транзакції, пов'язані з сумнівами, протягом повного тижня, оскільки опікунам також потрібно бути перевіреними, щоб запобігти припиненню підтвердження зловмисного виведення.

Проте ключовим є те, що ETH має забезпечити можливість обробки соціального форку протягом 7 днів. Це означає, що інструменти для виявлення атаки на 51% повинні бути готові, а також потрібно провести достатньо досліджень та моделювань, щоб визначити, чи можливо здійснити соціальний форк протягом 7 днів. Тільки в такому випадку витяг з 7-денною затримкою в Optimistic Rollup можна вважати ефективним заходом захисту.

3.6 Вектор атаки №3: Використання уразливостей у системі доказу шахрайства

Більшість сумнівів протоколу полягає в тому, що учасники знаходять певну точку (інструкцію або Блок), на якій вони не згодні, а потім генерують доказ того, що твердження іншого учасника є невірним. Віртуальна машина, яка використовується для генерації цього доказу, називається доказ шахрайства Віртуальна машина (Fraud Proof VM), а програмне забезпечення, яке використовується на цій Віртуальна машина для генерації доказів, називається програмою (program). Кожен протокол використовує різні доказ шахрайства Віртуальна машина і програми, як показано нижче:

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

Це питання можна обговорити через виявлення вектора атаки Yoav Weiss в OVM. Через наявність уразливості функції Відкат в OVM атака стає можливою, проте для здійснення атаки вирішальним є створення «шахрайської угоди». Шахрайська угода - це угода, яка виконується при нормальній обробці на Rollup, але викликає інший результат, коли її сумнівно ставлять під сумнів докази шахрайства та віртуальна машина. Оскільки система доказу шахрайства має генерувати ті ж результати, що й EVM, можливість створення шахрайської угоди свідчить про наявність уразливості в системі доказу шахрайства.

Yoav виявив кілька уразливостей у системі доказу шахрайства OVM та може емулювати такий атаки шляхом створення шахрайських транзакцій. Простим прикладом атаки, яку він виявив, є помилкове записування вартості газу для операцій SSTORE та SLOAD (що використовуються для збереження та читання стану) в StateManager OVM. Це означає, що будь-яка транзакція, яка зберігає або читає значення в контракті (майже всі транзакції, крім простих переказів ETH), буде позначена як шахрайська транзакція під час перевірки, навіть якщо вона правильно виконується на Rollup.

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

Це також є однією з причин, чому OP Mainnet недавно перейшов з системи доказу непрацездатності без дозволу на режим, в який можуть приєднатися лише авторизовані учасники. Після впровадження Основна мережа OPFP, безпечний аудит виявив систему доказу шахрайства (Cannon та op-program) і декілька вразливостей в протоколі суперечливих грив. Щоб запобігти зловживанню системою, Optimism оголосив 17 серпня про перехід до системи дозволу.

Звичайно, використання вразливостей Віртуальної машини може не мати серйозного впливу на Rollup, що знаходиться на етапі 0 або 1, оскільки Комітет з безпеки може втрутитися в будь-який момент, щоб виправити сумнівні результати. Це було висловлено раніше OP Labs. Насправді, OP Labs поділилися своєю аудиторською рамкою у форумі Optimism, де описані стандарти, за якими потрібно проводити зовнішній аудит.

(Структура аудиту OP Labs | Джерело: [Форум оптимізму] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864))

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

Однак, як тільки були виявлені вразливості, потрібно вирішити ці проблеми. Optimism вирішив ці проблеми у своєму оновленні мережі Granite, що дозволило відновити OP Mainnet до етапу 1.

З іншого боку, вразливості в системі можуть бути фатальними в Rollup етапу 2. На етапі 2 комісія з безпеки може втручатися лише в разі вразливостей, які можуть бути підтверджені в у блокчейні. Оскільки майже неможливо довести у блокчейні, що “результат суперечки є невірним через вразливість системи”, тому якщо в етапі 2 Rollup виникнуть вразливості, кошти користувачів можуть бути під загрозою.

3.7 Рішення №3: Множинні докази

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

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

Наприклад, уявіть собі систему з багаторазовими доказами з використанням одночасно Optimism Cannon та asterisc ZK доказами невдач Віртуальна машина (за Risc-V). У випадку сумнівів відбудуться наступні ситуації:

Якщо виявлено помилковий вивід, скаргувач створює скаргу та запускає двійковий пошук.
Як тільки знайдеться Блок, що відрізняється за допомогою бінарного пошуку, відбудуться дві підгри:

Субітка Cannon з використанням традиційного методу OPFP. Створення підгри генерації доказів некоректності (ZK) за допомогою Asterisc.

Після завершення двох ігор буде перевірено ці два різних докази шахрайства.

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

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

Це одна з постійних зусиль для досягнення фази 2 Optimism. Для підтримки цього, спірна гра OPFP передбачає модульну систему, яка дозволяє вільно реалізовувати декілька систем доказу шахрайства та визначати мінімальний інтерфейс для підтримки цього.

4. Виконані покращення

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

4.1 Простір для покращення кожного протоколу

1) Арбітраж BoLD

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

Співвідношення ресурсів у 6,5 раза занадто мале для переваги захисника.
Внесення застави за кореневий заяв у розмірі 3 600 ETH є надто великим.

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

Ця концепція схожа на пропозицію BoLD++ від Gabriel від Cartesi. Коли сумнів розділений на кілька рівнів, збільшення відношення ресурсів призводить до експоненційного зростання розміру депозиту на найвищому рівні. Однак, використовуючи один рівень, можна більш легко збільшити відношення ресурсів, що дозволяє протоколу більш ефективно протистояти атакам Сібіл.

Друга проблема — це вимога застави в розмірі 3 600 ETH, яка є ще складнішою для вирішення. Розмір застави BoLD не лише призначений для боротьби із Sybil-атаками, але і для запобігання атакам затримки. Розмір застави є функцією TVL (загальної вартості заблокованих коштів), і навіть за допомогою ZK не може значно падати. Для вирішення цієї проблеми BoLD запроваджує механізм застави в майнінговому пулі, що дозволяє декільком учасникам спільно нести витрати на заставу.

2) Картезі Дейв

Dave ефективно впорався з атакою Сібіл через свою турнірну структуру, але, як було зазначено раніше, вона легко піддаватиметься затримці. Максимальний час затримки - це функція кількості заяв з злочинними намірами NA та рівня застейкання L, її обчислювальна формула така: Td = 7 x [log2(1 + NA)]L (днів)

Якщо NA = 7 та L = 3, протокол може стикнутися з затримкою до чотирьох місяців, що призведе до помітних незручностей та збитків для користувачів, оскільки виведення коштів буде затримано.

ZK може допомогти зменшити цю проблему. Шляхом закріплення рівня L як 1 (як у рядку BoLD++), максимальний час затримки може бути зменшений до: Td = 7 x log2(1 + NA) (днів)

За даними звіту, Cartesi використовує технологію ZK RISC Zero для цього вдосконалення. Однак існують опаски, чи достатньо це вдосконалення, щоб повністю запобігти атакам затримки. Якщо NA = 7, протокол все ще може стикатися з додатковою затримкою до двох тижнів, при цьому вартість для атакуючого складає лише 7 ETH депозиту, плюс витрати на газ та позаланцюгові витрати на історичні зобов'язання. Для ланцюжків з високою вартістю Закрита позиція, ця покарання може бути недостатньою для стримування атак затримки.

（Dave: механізм суб'єктивного сумніву з виразним стилем BoLD | Джерело: L2Beat Medium）

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

Td = 7 x log8 (1 + NA) (днів)

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

Проте, недоліком цього методу є підірвання переваги захисника в обличчі атак Сібіла. Хоча BoLD надає структуру, в якій захисник має N-кратну перевагу над атакуючим, Dave створив метод, в якому захисник має експоненційно більшу перевагу над атакуючим.

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

3) Оптимізм Fault Proof (OPFP)

Недоліком OPFP є його легка схильність до атак Сибіл, оскільки вартість для нападника та захисника однакова. OP Labs запропонували рішення цієї проблеми у спірній грі V2.

У відміну від початкового OPFP, останній подає Маржа кожного разу під час поділу, тоді як спірна гра V2 вимагає від учасників подавати Маржа в початковий момент поділу. Крім того, спірна гра V2 впроваджує поділ, що дозволяє учасникам подавати кілька запитів одночасно в точці розгалуження, що в більшості випадків зменшує кількість взаємодій.

(Заява про гілку |. у грі «Суперечки» V2.) Джерело: Optimism Specs GitHub)

У попередній версії OPFP вектори атаки Сибілл були такі:

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

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

По-друге, у грі Controversy Game V2 вищі рівні мають більшу кількість Маржа, тому вартість постійного подання фальшивих виходів вища для нападника, ніж для захисника.

Отже, OPFP може ефективно протистояти атакам Сібіл за допомогою введення гілкових заяв у грі V2, яка стала предметом суперечок.

4)Kroma ZK Fault Proof (Kroma ZKFP)

Kroma ZKFP стикається з вразливістю перед атаками Сібіл та недосконалою системою підтвердження. Для того щоб Kroma ZKFP міг перейти до етапу 1, потрібно вирішити наступні дві проблеми:

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

Крома планує перейти від Halo2 zkEVM Scroll до Succinct SP1 zkVM, щоб вирішити ці дві проблеми та перейти до етапу 1.

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

Щодо другого питання, Kroma буде використовувати недовірну дедукцію на основі ZK. Конкретний спосіб роботи наступний:

(Виведення без довіри за допомогою ЗК |.) Джерело: [Lightscale Notion] (https://www.notion.so/Complete-Trust-less-Derivation-for-Zero-Knowledge-Dispute-Game-bfaebd36375d48169424064237986dea?pvs=4))

Уявіть собі, що ми хочемо довести, що певний L2 Блок T правильно виконується. Перш ніж створювати ZK довідки, ми повинні перевірити, чи правильно побудовані дані про транзакції Блоку T на основі пакетних даних L1.

Тут Kroma планує перевірити, чи правильно витягнуті пакетні дані з L1 за допомогою ZK-перевірки. Якщо дані знаходяться поза ZK-програмою і отримані лише через довірчий RPC, то неможливо впевнитися, що пакетні дані не були підроблені. Можна перевірити, чи програма отримала правильний Блок і витягнула пакетні дані, шляхом засвідченої ZK-доводної пропозиції, що створює зв'язок між Блоком O (джерело L1 для Блоку T L2) і Блоком C (Блок L1, що створений під час суперечки). Якщо суперечник побудував Блок T L2 на основі неправильних пакетних даних, то посилання на Блокхеш L1, на яке посилаються пакетні дані, буде відрізнятися від фактичного Блокхеша L1, який містить пакетні дані (включаючи T1), і вона також не буде зв'язана з Блоком C. Тому, якщо немає конфлікту хешів, перевірка зв'язку Блоку L1 за допомогою ZK може довести, що суперечник побудував Блок T L2 з правильних пакетних даних.

Проект Kroma планує використовувати ZK для перевірки точності пакетних даних, це дозволяє перевірити зв'язність між Блоком L1 і Блоком C за допомогою хешу. Якщо супротивник, використовуючи неправильні пакетні дані, створює Блок L2 T, його посилання на Блок L1 буде відрізнятися від правильного пакету в Блоку L1 і не буде з'єднуватися з Блоком C. Через відсутність конфлікту хешу, процес спірності може використовувати цей метод для перевірки правильності пакетних даних.

Завдяки цим вдосконаленням Kroma ZKFP зможе увійти до етапу 1. Однак для досягнення етапу 2 Kroma потребує додаткових рішень для запобігання атакам Sybil, включаючи зміну протоколу на всіх проти всіх (All-vs-All) та переробку механізму Маржа.

4.2. Заключення

5. майбутнє доказу шахрайства

5.1. Rollup етапу 2 - ваші кошти залишаються в безпеці

Як вже зазначалося, Optimistic Rollups рухаються в напрямку фази 2. Arbitrum працює над досягненням фази 2 на основі BoLD. План впровадження BoLD вже опубліковано на форумі управління і отримав значну підтримку, в даний час він вже розгорнутий на тестовій мережі. Якщо не виявиться серйозних проблем з безпекою, то ймовірно, що до кінця цього року Arbitrum реалізує фазу 2 за допомогою BoLD.

Optimism також працює над досягненням етапу 2. Для досягнення етапу 2 для OP Основна мережа необхідно завершити гру спорів V2 та мати підтримку різноманітних механізмів підтвердження. Незважаючи на те, що стандарти все ще удосконалюються, гра спорів V2 успішно вирішує слабкі сторони існуючого OPFP, надаючи потужний захист від атаки Сібіла, що наближає його до етапу 2. Крім того, різні команди, включаючи OP Labs, Succinct, Kroma та Kakarot, активно працюють над розробкою різноманітних механізмів підтвердження, вкладаючи значні ресурси в створення різноманітних способів підтвердження стеку OP. Таким чином, за відсутності серйозних проблем очікується, що Optimism також перейде до етапу 2 в першій половині наступного року.

Ці дві розширюваність (Rollup) можуть суттєво вплинути на екосистему Rollup при переході до етапу 2. Arbitrum та Optimism мають власні фреймворки розширюваності (Rollup), відповідно, Arbitrum Orbit та OP Stack. Перехід до етапу 2 означає, що всі розширюваності (Rollup), які використовують ці фреймворки, також можуть перейти до етапу 2.

В результаті, очікується, що з кінця цього року до наступного року великі ролапи з великими базами користувачів, такі як Arbitrum, OP Основна мережа та Base, перейдуть до фази 2, успадкувавши повну безпеку Ethereum. Це, швидше за все, придушить критику на кшталт «Rollup — це просто Мультипідпис» або «Rollup може забрати ваші кошти в будь-який час».

5.2. ZK доказ шахрайства - майбутнє

Більшість обговорень протоколу можуть отримати перевагу від використання ZK доказу шахрайства. Наприклад, застосування ZK до Arbitrum BoLD може підвищити співвідношення ресурсів, що зробить його більш стійким до атак типу Sybil, тоді як Cartesi Dave може зробити його менш вразливим до затримкових атак. OPFP також вивчає використання ZK для підтримки багатопроофових систем, що може знизити суму маржі та підвищити безпеку протоколу.

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

Через цей підхід, ZK доказ шахрайства відіграє ключову роль в безпеці та децентралізації в Optimistic Rollup.

Як веде себе ZK Rollup? Чи стане доказ шахрайства слабкішим?

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

Перехід від Optimistic Rollups до ZK Rollups може бути швидшим, ніж очікувалося. Це тому, що основний недолік ZK Rollups - високі витрати та час на генерацію доказів - швидко поліпшується. Недавно Succinct Labs запустила OP Succinct - версію ZK на основі OP Stack, яка надає фреймворк для легкого запуску ZK Rollups.

Вступ до ОП Стислий | Джерело: [Стислий блог] (https://blog.succinct.xyz/op-succinct/)

Однак є кілька факторів, які потрібно врахувати. По-перше, це вартість. У OP Succinct вартість створення Блок-свідоцтва становить приблизно від $0.005 до $0.01, а вартість експлуатації перевірника оцінюється від $6,480 до $12,960 щомісяця. Якщо обсяг операцій ланцюжка на секунду (TPS) є високим, ці витрати можуть додатково зрости.

(Вартість підтвердження кожної мережі Бенчмарк | Джерело: Блог Succinct )

Наприклад, на базі мережі OP Succinct вартість генерації сертифікатів для кожного Блоку приблизно становить $0.62. За цими цифрами витрати за місяць складуть $803,520. Це є додаткові витрати, яких немає в Optimistic Rollups, навіть за врахування витрат на ZK Падіння, витрати на операційну діяльність ZK Rollups завжди будуть вищими, ніж в Optimistic Rollups.

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

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

Arbitrum прагне досягти свого кінцевого ціле шляхом розробки комбінованого протоколу, який об'єднує методи ZK і Optimistic. Цей протокол головним чином працює як Optimistic Rollup, і лише у випадках потреби у швидкому знятті коштів створює ZK-підтвердження. Це дуже корисно для сценаріїв, де потрібно швидко збалансувати кошти між ланцюжками (наприклад, біржа або кросчейн міст), й сприяє взаємодії між ланцюжками.

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

5.4. доказ шахрайства лише застосовується до Rollup?

Ми вже вивчили оптимістичні роллапи Ethereum та їхній механізм доказу шахрайства. Таким чином, у яких інших випадках є цей доказ шахрайства?

Заставити протокол доказ шахрайства можно активно использовать в протоколе застейкати. Давайте воспользуемся примером Eigenlayer, это типичная служба застейкати на базе ETH.

Eigenlayer - це сервіс, який дозволяє здійснювати заставку Ethereum для забезпечення безпеки. У Eigenlayer оператори можуть зберігати ETH або LST користувачів за допомогою делегованого контракту в Eigenlayer та брати участь у перевірці, вибираючи кілька AVS (активніх перевіряючих сервісів). За допомогою Eigenlayer протокол може легко будувати AVS та зменшувати витрати на первинну ініціалізаціювалідаторів.

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

**Приклад слешінгу AVS | Джерело: Eigenlayer GitHub

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

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

Шар доступності даних** **доказ шахрайства також може використовуватися на рівні доступності даних (DA). Один з репрезентативних прикладів - це доказ шахрайства, запропонований та реалізований Celestia. У Celestia є технологія, яка дозволяє легка нода здійснювати перевірку правильності зберігання даних шляхом вибіркової перевірки доступності даних. Давайте докладніше розберемося в цей концепції.

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

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

У Celestia є два типи доказу шахрайства:

Стан переходу доказ шахрайства

Спочатку працює доказ шахрайства даних наступним чином: Celestia дозволяє легка нода перевіряти, чи валідатори мають правильні дані, не завантажуючи безпосередньо всі дані в блоку. Для досягнення цієї мети Celestia використовує технологію, яка називається вибіркове визначення доступності даних (Data Availability Sampling, DAS).

Вибіркове взірцювання доступності даних Celestia | Джерело: Документація Celestia

Celestia валідатори перетворюють структуру даних угод до матриці розміром k x k, а потім розширюють її до матриці розміром 2k x 2k за допомогою технології, відомої як 2D кодування Ріда-Соломона. Потім вони обчислюють 4k Корінь Меркла для кожного рядка та кожного стовпця, після чого включають результати хешування цих Коренів Меркла до Заголовка блоку та поширюють його.

Лише за інформацією Корінь Меркла в Блоку, легка нода може перевірити, чи володіє валідатори правильними даними Celestia. Легка нода запитує дані випадкової точки з матриці 2k x 2k, одночасно отримуючи Корінь Меркла від валідаторів для відповідного рядка та стовпця. Якщо ці дані можуть бути перевірені зі значеннями в Блоку, то можна довіряти валідаторам, що вони володіють правильними даними.

Проте з'явилася важлива обставина: якщо валідатори у зловмисним чином виконають кодування Ріда-Соломона? Celestia вирішує цю проблему шляхом впровадження механізму, відомого як "доказ шахрайства", який дозволяє виявити неправильне кодування. Якщо повний вузол Celestia виявить неправильне кодування під час відновлення Блоку, він згенерує доказ шахрайства, що містить висоту Блоку, частину неправильного кодування та доказ про відмову, та розповсюдить його серед легких вузлів. Легкі вузли перевірять цей доказ, щоб підтвердити факт неправильного кодування даних та припинити використання неправильних даних.

Крім того, Celestia запропонувала механізм доказу шахрайства переходу стану.

Архітектура блоку Селестія | Джерело: [Блог DAO] (https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

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

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

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

Основні причини застосування машинного навчання до блокчейну такі:

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

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

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

доказ шахрайства Віртуальна машина（Fraud Proof VM）：Ця Віртуальна машина виконує машинне навчання та інференцію, її функціонал схожий на WAVM в Arbitrum або Cannon в Optimism.
opML Смарт-контракт：цей контракт перевіряє шахрайство, діє подібно до контракту MIPS.sol оптимізму.
Підтвердження гри: валідатори, які поставляють питання, взаємодіють з сервером за допомогою бінарного пошуку, щоб визначити окремі неправильні кроки у Віртуальній машині, після чого генерують докази шахрайства для цього кроку та подають їх на операційний контракт opML.

Гра на валідацію на ORA opML | Джерело: [Документ ORA] (https://docs.ora.io/doc/technology/proving-frameworks-zkml-opml-opp-ai/opml)

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

6. Висновок

Optimistic Rollup нині активно вдосконалює доказ шахрайства та спірний протокол, щоб успадкувати більше безпеки Ethereum та створити менш довірливий ланцюжок. Arbitrum очікується досягти етапу 2 до кінця цього року за допомогою BoLD, тоді як Optimism також працює над етапом 2, залежачи від гри з суперечками V2 та багатофакторного підтвердження. Наступного року користувачі Optimistic Rollup зможуть взаємодіяти з мережею з більшою безпекою, не боячись, що “Rollup може забрати їхні кошти”. Крім того, Віталік зазначив у своєму блозі, що очікується збільшення кількості Rollup на етапах 1 та вище у наступному році.

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

У сфері доказу шахрайства, крім Rollup, інші протоколи також вкладають значні ресурси в дослідження. При постулаті «потрібен лише один чесний учасник», поєднання доказу шахрайства з ZK може сприяти побудові мінімалістично довіреної архітектури блокчейну, що врешті-решт стане реальністю, яку ми відчуємо впродовж. 01928374656574839201

7. Джерела

(https://l2beat.com/scaling/summary)[L2Beat]

[Шахрайство доводить війну |.] Лука Донно на L2Beat](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

[Файл арбітражу] (https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction)

[Стаття про оптимізм] (https://docs.optimism.io/).

Специфікація оптимізму

Неправомірний матч арбітра | Cartesi

[Технічні характеристики Kroma] (https://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html)

BoLD: швидке та недороге вирішення спорів

[Економіка БоЛД] (https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/Economics.pdf)

Чому період виклику оптимістичного Rollup триває 7 днів? | Кельвін Фіхтер у OP Labs

[Доказ шахрайства вийшов з ладу |.] Габріель Коутіньо де Паула в Картезі](https://ethresear.ch/t/fraud-proofs-are-broken/19234)

[Оптимістична подорож у часі |.] Йоав Вайс](https://medium.com/infinitism/optimistic-time-travel-6680567f1864)

[Вступ до першого успішного випробування основної мережі Kroma] (https://blog.kroma.network/about-the-first-successful-challenge-on-kroma-mainnet-aeca715b05d7)

Розпакування прогресу в базовій децентралізації | OP Labs

Проти неатрибутної цензурної атаки на протоколи другого рівня, засновані на доказі шахрайства

[Структура аудиту OP Labs] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864)

[Виведення, що не потребує довіри |.] Крома](https://www.notion.so/Complete-Trust-less-Derivation-for-Zero-Knowledge-Dispute-Game-bfaebd36375d48169424064237986dea?pvs=4)

OP Succinct: доказ дійсності повністю на стеку OP | Succinct

[Eigenlayer GitHub] (https://github.com/Layr-Labs/eigenlayer-contracts/blob/d3730b5dd1b94d5e676e0c7a00a031574263c2c3/docs/experimental/AVS-Guide.md)

[Файли Celestia] (https://docs.celestia.org/)

[Внесок блогу DAO] (https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

[Документ ORA] (https://docs.ora.io/doc/technology/proving-frameworks-zkml-opml-opp-ai/opml)

Заявлення:

Цей текст був взятий з [research.2077], всі права належать оригінальним авторам [sm-stack і BTC Penguin]. Якщо у вас є які-небудь запитання щодо цього перекладу, будь ласка, зв'яжіться з командою Gate Learn, вони оперативно відреагують.
Відмова від відповідальності: погляди та думки, висловлені в цій статті, є особистими поглядами автора і не є інвестиційними рекомендаціями.
Команда Gate Learn перекладає статтю іншими мовами. Якщо не вказано інше, забороняється копіювати, розповсюджувати або займатися плагіатом перекладених статей.