Автор: Фауст, Geek Web3
У реальному світі майже кожна висока будівля має незамінний інгредієнт: безпечний вихід. Коли трапляються надзвичайні ситуації, такі як пожежі та землетруси, безпечні виходи є порятунком для забезпечення безпеки життя людей. У системі кастодіальної платформи рівня 2 Ethereum, яка несе в собі активи на десятки мільярдів доларів, функція «примусового зняття», яка дозволяє користувачам безпечно виводити активи на рівень 1, стала незамінним і необхідним засобом.
У своїй нещодавній статті «Різні типи рівня 2» Віталік також підкреслив, що здатність користувачів безперешкодно виводити активи з рівня 2 на рівень 1 є дуже важливим показником безпеки.
Однак питання «плавного виведення», схоже, не привертало особливої уваги більшості людей у минулому, і навіть багато проєктів рівня 2 не запустили функцію «примусового виведення» або «втечі». В епоху, коли екосистема L2 не в самому розпалі, ігнорування «інклюзивного виведення» не здається проблемою. Але тепер, коли активи рівня 2 перевищують 12 мільярдів доларів, він став будівлею «занадто великою, щоб зазнати невдачі». Якщо такий хмарочос не має безпечного виходу, наслідки просто немислимі.
Щоб змусити читачів звернути увагу на ризики безпеки рівня 2, «Geek Web3» візьме Loopring Protocol V3 та Arbitrum як приклади нижче, щоб пояснити, чому «функції виведення без дозволу», такі як примусове витягування та евакуація, є невід’ємною частиною рівня 2.
(За даними браузера L2BEAT dYdX, функція примусової транзакції/зняття коштів dYdX була використана 152 рази, і було здійснено 7 великих зняттів коштів на суму понад 1 мільйон доларів.)
Опір цензурі – велика проблема: що робити, якщо секвенсер навмисно відхиляє ваш запит****
У минулому науково-популярні статті про Layer 2 часто мали проблему, тобто більшу частину часу вони зосереджувалися на «безпеці» та «зручності використання» на поверхні, але ігнорували «опір цензурі». Навіть говорячи про децентралізовані рішення секвенсорів, багато хто звертає увагу на те, чи є MEV децентралізованим, а не на стійкість до цензури.
Іншими словами, більшість людей, як правило, зосереджуються на тому, чи дійсні переходи станів рівня 2, чи може секвенсер красти монети та чи використовується система підтвердження валідності шахрайства/валідності, але вони ігнорують ризик, який не слід ігнорувати: що робити, якщо Секвенсер продовжує відхиляти ваші запити на транзакції, або просто зазнає невдачі протягом тривалого часу, або навіть виходить з ладу? **
Ви знаєте, під час відключення Solana були люди, які не могли вчасно покрити свої позиції, тому що їхнім активам загрожувала ліквідація, що ставило під загрозу активи на мільйони доларів. ** Якщо таке відхилення запиту користувача відбувається, завдані економічні збитки не є незначними.
Навіть якби в такій ситуації могли опинитися лише кілька людей, якби він впав на якогось кита з великими грошима, постраждав би весь ринок (припустимо, у когось є сотні мільйонів доларів активів на протоколі кредитування Defi на Ethereum, які можуть бути ліквідовані за тиждень, але він знаходиться в санкційному списку OFAC за використання Tornado). Більша частина коштів цієї людини знаходиться на ОП, і секвенсор ОП працює з OFAC, щоб відхилити його запит)
З таким же успіхом ми можемо спроектувати цю проблему на публічні ланцюжки, такі як avalanche або polygon, які не залежать від Ethereum. Якщо більше 2/3 вузлів консенсусу валідаторів на Avalanche вирішать цензурувати ваші транзакції, вони можуть відмовитися включати ваш Txn у блок або не розпізнати блок, який містить ваш Txn. У цей час ваші гроші фактично поховані в цьому ланцюжку і не можуть вибратися:**
Якщо ви не можете кооптувати деяких валідаторів, щоб менше 2/3 валідаторів були залучені до цензурної атаки, або ви можете закликати деяких людей до форку Avalanche через соціальний консенсус. Очевидно, що на цьому етапі у вас все ще є спосіб швидко вивести кошти з Avalanche, і ми повинні враховувати, що більше 2/3 валідаторів об’єднують зусилля, щоб ініціювати перевірку транзакції певної адреси, що саме по собі займає деякий час, що залишить достатньо часу для «втечі» цензурованих користувачів.
Але на 2-му рівні ситуація може бути зовсім іншою. Секвенсором рівня 2, як правило, керує сам чиновник, і якщо Секвенсер хоче запустити на вас цензурну атаку, він може «заморозити ваші гроші в рівні 2», тобто повністю відхилити ваш запит на транзакцію для перетину активів з L2 до L1. Очевидно, що відповідно до механізму роботи L2, якщо ви не можете обійти секвенсер для виконання операції виведення, цілком можливо, що секвенсер заморозить активи в L2 і не може бути переведений.
Як же вирішити подібного роду проблеми? Насправді, простіше кажучи, як реалізувати функцію «інклюзивного» виведення, щоб користувачі могли виводити свої активи на рівень 1 без будь-якої шкоди, коли вони перевіряються сторонами проекту Sequencer або Layer 2? Є деякі проекти, які запропонували децентралізований секвенсор, але це не паліативне рішення, і якщо дуже обмежена кількість секвенсерів об’єднає зусилля, щоб перевірити вас, ви все одно можете «заморозити» свої активи, а боротьба з відьмами POS-вузлів також є складною проблемою (див. Мультичейн події).
Найефективніший спосіб зробити це – налаштувати «вихід» безпосередньо в ланцюжку L1, що дозволить користувачам виводити кошти з L2 через виділений вихід на L1, якщо вони не отримують відповіді від Sequencer протягом тривалого часу. **
Модель примусового виведення коштів та ліквідації банкрутства Loopring Protocol V3
Тут ми візьмемо для прикладу V3-версію протоколу Loopring, в якій перераховані два різні сценарії примусового зняття, ініційованого користувачем, перший випадок:
Користувачі можуть ініціювати примусове виведення коштів безпосередньо на рівні 1 через функцію forcedWithdrawal в контракті ExchangeV3 і заявити, який L2-акаунт у них є в протоколі Loopring і який токен вони хочуть вивести. Після цього контракт ExchangeV3 викидає ончейн-подію, яка вказує на те, що хтось ініціював примусовий запит на виведення коштів. Оскільки всі вузли протоколу Loopring (включаючи Sequencer) запускають клієнти Geth, з блоку Ethereum відомо, що хтось ініціював примусове зняття коштів і запустив відповідну подію в мережі.
Важливо зазначити, що примусове зняття коштів обробляється не відразу, а поміщається в чергу pendingForcedWithdrawals і очікує на розгляд. **Секвенсер помітив, що після того, як хтось ініціює примусове зняття коштів на рівні 1, протягом 15 днів спрацьовує функція Process у контракті ExchangeV3 для переказу токена ініціатору виведення в ланцюжку Ethereum (з адреси депозиту сторони проекту L2 у ланцюжку Ethereum для переказу грошей користувачеві).
Якщо Sequencer не відповідає на запит користувача про примусове виведення коштів протягом 15 днів, користувач може викликати функцію notifyForcedRequestTooOld, щоб контракт ExchangeV3 викинув подію під назвою WithdrawalModeActivated, щоб сповістити весь вузол протоколу Loopring про активацію режиму ліквідації банкрутства. **
**Якщо активовано режим ліквідації, Loopring V3 перестане отримувати нові блоки L2, надіслані секвенсером, а це означає, що весь протокол Loopring перестане працювати. Цей процес триває не менше 30 днів.
Однак у режимі ліквідації банкрутства користувачі все ще можуть виводити свої активи на рівні 1, але їм потрібно надати доказ Меркла, щоб підтвердити статус/статус своїх активів, який можна перевірити на дереві стану L2. (Доведіть, що баланс ваших активів на рівні 2 відповідає сумі, яку ви задекларували, коли ініціювали виведення коштів)
Ця модель ліквідації банкрутства протоколу Loopring також відома як механізм Escape Hatch на L2BEAT. Цей режим спрацьовує за попередньою умовою того, що секвенсер не відповідає на запит користувача про примусове виведення коштів протягом зазначеного часу, або якщо секвенсер має тривалий збій або простої. У цей час користувач може вручну перевести зведений контракт у режим заморожування/зупинити виконання. Потім користувачі можуть побудувати докази Меркла, щоб довести свої активи на рівні 2, і вивести власні активи з адреси депозиту сторони проекту L2 у L1. **
У документації StarkEx також намальована спеціальна принципова схема цього процесу. Якщо користувач L2 не отримує відповіді секвенсера в кінці 7-денного вікна, коли користувач L2 подає примусовий запит на виведення коштів на L1, користувач L2 може викликати функцію запиту на заморожування, щоб змусити L2 увійти в період заморожування. У цьому випадку секвенсор L2 не зможе оновити стан L2 на L1, і для розморожування знадобиться 1 рік після заморожування стану L2. Після цього користувачі можуть подати доказ Меркла та вивести гроші.
Однак, для того, щоб побудувати доказ Меркла, вам потрібно спочатку знати повне дерево станів L2, тобто вам потрібно знайти повний вузол L2 для запиту даних, і в той же час вам потрібен шматок коду для генерації доказу Меркла, що, очевидно, вимагає певного технічного порогу. Для зручності більшості користувачів L2BEAT раніше заявляв, що рівень 2 повинен налаштувати ряд повних вузлів з відкритими дозволами та відкритим вихідним кодом, щоб допомогти користувачам знати статус усіх облікових записів на L2 (включаючи баланс, кількість транзакцій тощо). Цей крок також ілюструє важливість обов’язкового виведення коштів та механізмів евакуації.
Функція Arbitrum “Примусове включення транзакцій”
Але примусове вилучення/втеча, схоже, не єдине рішення, стійке до цензури. Наприклад, Arbitrum використовує метод «примусового включення транзакцій», користувач може спочатку відправити Txn/зняття, яке має бути оброблене Секвенсером у відкладеному контракті Inbox на L1, а якщо Секвенсер не обробляв його більше 24 годин, користувач може викликати функцію примусового включення контракту Inbox секвенсера на L1. Нехай Txn буде включено безпосередньо в послідовність транзакцій Arbitrum** (запустіть подію в ланцюжку, щоб повідомити повним вузлам Arbitrum про те, що Txn з кількома відкладеними записами вхідних повідомлень потрібно включити в книгу L2).
На противагу цьому, підхід Arbitrum простіший, але його все одно трохи не вистачає: він лише запускає ончейн-подію, яка повідомляє вузлу Arbitrum про те, що є кілька транзакцій, які секвенсер ігнорує, і які потрібно включити в найдовший ланцюг L2, замість того, щоб дозволити користувачам виводити гроші безпосередньо на L1, як це роблять протокол Loopring і режим банкрутства/escape pod StarkEx. Якщо вузли-претенденти Arbitrum об’єднаються, щоб розпочати цензурну атаку, схоже, що все одно можна буде заморозити гроші користувачів на L2. **
Таким чином, примусове включення Arbitrum недостатньо інклюзивне, і хоча було б непогано сказати, що секвенсер ігнорував запит користувача forceInclusion, поки існував чесний вузол, готовий опублікувати доказ шахрайства, це все одно вводить певний ступінь припущення про довіру, хоча і в меншій мірі.
Точніше, «транзакції, які повинні бути в обов’язковому порядку включені», повинні бути визнані як мінімум одним вузлом-претендентом ARB, який в даний час має 9 вузлів, які мають право вирішувати, які крос-чейн повідомлення L2-L1 дозволяти, і тепер тільки вони можуть видавати докази шахрайства. **Поки ці 9 вузлів вступають у змову, теоретично «примусова транзакція» користувача все ще може бути визнана недійсною. **
Таким чином, поточне обов’язкове включення транзакцій/виведення коштів в Arbitrum не схоже на модель ліквідації банкрутства Loopring і StarkEx, яка не вимагає дозволу вузла L2. Однак L2BEAT все одно дав Arbitrum високу оцінку цьому рішенню. Тому що в майбутньому Arbitrum запустить механізм звільнення від шахрайства Permissionless під назвою BOLD, і вузлам-претендентам буде складно або неможливо вступити в змову в той час (зараз це насправді складно зробити).
За даними L2BEAT, поточний TVL становить понад 50 мільйонів доларів, і немає жодної реакції на будь-які збої секвенсера або помилки пропонента: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. У крайніх випадках ці L2 можуть призвести до заморожування активів користувачів у L2. **
Отже, очевидно, що модель примусового виведення коштів або ліквідації банкрутства має свою необхідність, хоча на даний момент вона покладається лише на user-sequencer як гру для контрагентів, ** насправді не «готовий до виведення» ** (Arbitrum має 24-годинну затримку і може вийти з ладу, Loopring має максимальну затримку 15 днів, StarkEx має максимальну затримку 7 днів), але зрозуміло, що «щось краще, ніж нічого». Крім того, вважається, що проблема затримок у примусовому знятті коштів буде належним чином вирішена в майбутньому за допомогою більш складної конструкції механізму** (в даний час це в основному пов’язано з тим, що деякі вчені MEV можуть використовувати forceInclusion для ініціювання транзакцій, що запускаються, тому необхідно запровадити затримки). Для отримання більш детальної інформації, будь ласка, зверніться до офіційних документів основних сторін проекту L2).
З включенням децентралізованого секвенсера в все більше і більше дорожніх карт L2, а Ethereum Foundation на чолі з Віталіком продовжує навчати людей безпеці рівня 2, стійким до цензури функціям транзакцій, таким як примусове зняття коштів, обов’язково приділятиметься все більше і більше уваги, що зробить систему Ethereum Layer2 ближчою до стійкої до цензури системи фінансової інфраструктури, що не потребує довіри. Якщо рівень 2 реалізує доступ до коштів без довіри, вважається, що більше маркет-мейкерів і постачальників ліквідності увійдуть в інфраструктуру L2, а масове впровадження всього web3 підштовхне ще один крок вперед.
