В реальному світі майже кожен хмарочос має невід'ємний елемент: аварійний вихід. Коли трапляються непередбачені події, такі як пожежі або землетруси, ці виходи є порятунком для безпеки людей. Так само в екосистемі Ethereum Layer 2, де зберігаються мільярди доларів активів, функція "примусового зняття" , яка дозволяє користувачам безпечно повертати активи на Рівень 1, стала невід'ємним об'єктом.

Віталік також наголосив у своєму останньому статті “Різні типи рівнів 2”, що можливість користувачів плавно виводити активи з Рівня 2 назад на Рівень 1 є дуже важливим показником безпеки.

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

З метою підвищення усвідомленості серед читачів про ризики безпеки Рівня 2, «Geek Web3» у наступному тексті використає протокол Loopring V3 та Arbitrum як приклади, щоб пояснити, чому "функції виведення без дозволу", такі як примусове виведення та вихідна люк, є невід'ємними складовими Рівня 2.

(Згідно з браузером L2BEAT dYdX, наразі функція примусової торгівлі/виведення в dYdX використовувалася загалом 152 рази, при цьому великі виведення на суму понад один мільйон доларів склали 7 випадків) Стійкість до цензури - це важлива проблема: Що, якщо Секвенсер умисно відмовиться від вашого запиту?

Минулі популярно-наукові статті на Рівень 2 часто мали одну проблему: вони в основному підкреслювали «безпеку» та поверхневу «зручність використання», але не звертали увагу на «стійкість до цензури». Навіть коли обговорювалися децентралізовані рішення для послідовності, багато людей звертало увагу на те, чи є MEV децентралізованим, а не на поліпшення стійкості до цензури.

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

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

Навіть якщо лише кілька осіб можуть зіткнутися з такими ситуаціями, якщо це трапиться з деякими 'китами', які утримують великі суми коштів, весь ринок може постраждати. Наприклад, припустимо, що хтось з сотнями мільйонів доларів активів в протоколі кредитування DeFi на Ethereum опиняється під загрозою ліквідації протягом тижня, але йому було накладено санкції OFAC через використання Tornado. Більшість їхніх коштів знаходиться на Optimism (OP), і OP Sequencer, дотримуючись вимог OFAC, відмовляє їхнім запитам.

Давайте проекціюємо це питання на незалежні блокчейни, такі як Avalanche або Polygon, відокремлені від Ethereum. Якщо понад дві третини вузлів консенсусу Валідаторів на Avalanche вирішать провести перевірку транзакцій проти вас, вони можуть відмовитися включати ваші транзакції у блок або відмовитися визнавати блок, що містить ваші транзакції. У цьому випадку ваші кошти фактично застрягнуть в цьому ланцюжку і не зможуть бути виведені:

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

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

Отже, як можна вирішити це питання? Просто кажучи, як ми можемо реалізувати функцію «бездозвільного» зняття, яка дозволить користувачам безпечно повернути свої активи назад на Рівень 1 навіть під час перевірки Секвенсором або командою проекту Рівня 2? Деякі команди проекту запропонували ідею децентралізованих Секвенсорів, але це поверхневе рішення. Якщо ці обмежені кількості Секвенсорів узгоджуються, щоб вас перевірити, вони все ще можуть «заморозити» ваші активи. Крім того, проблема анти-Сібіл-атак в вузлах Proof of Stake (PoS) також проблематична (як бачимо в інциденті Multichain).

Найефективніше рішення - це створити спеціальний 'вихід' на блокчейні рівня 1, що дозволить користувачам зняти свої кошти з рівня 2 через цей вихід L1 у випадках, коли вони не отримують відповіді від послідовника протягом тривалого періоду.

У контексті версії 3 протокола Loopring визначається два різних сценарії для примусових виведень, ініційованих користувачем. Перший сценарій виглядає так:

Користувачі можуть безпосередньо ініціювати примусовий виведення на Рівні 1, використовуючи функцію forcedWithdraw в контракті ExchangeV3. Вони повинні заявити, який є їх обліковий запис на Рівні 2 у Протоколі Loopring та який Токен вони бажають вивести. Надалі контракт ExchangeV3 видає подію блокчейну, сигналізуючи, що хтось ініціював запит на примусове виведення. Оскільки всі вузли у Протоколі Loopring, включаючи Послідовника, використовують клієнт Geth, вони будуть інформовані про примусове виведення та відповідну подію блокчейну з даних блоку Ethereum.

Важливо зауважити, що примусовий виведення не обробляється негайно, а замість цього поміщається в чергу pendingForcedWithdrawals, очікуючи обробки. При поміченні примусового виведення, ініційованого на Рівні 1, Послідовник зазвичай запускає функцію Process в контракті ExchangeV3 протягом 15 днів. Ця функція виконує переказ токенів на ланцюгу Ethereum ініціатору виведення (з адреси депозиту проекту на Рівні 2 на ланцюгу Ethereum до особи, що виводить).

Якщо Секвенсор не відповідає на запит користувача щодо примусового вилучення протягом 15 днів, користувач може викликати функцію notifyForcedRequestTooOld. Ця дія підтримує контракт ExchangeV3 відправити подію під назвою WithdrawalModeActivated, сповіщаючи всі вузли в протоколі Loopring, що режим ліквідації банкрутства було активовано.

Якщо активований режим ліквідації банкрутства, Loopring Protocol V3 припинить отримувати нові блоки L2, надіслані послідовником, що означає, що весь Loopring Protocol припинить працювати у цей час. Цей процес триватиме щонайменше 30 днів.

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

Стаття описує модель ліквідації банкрутства протоколу Loopring, яка також відома як механізм \"Виходу втечі\" на L2BEAT. Цю модель активується за певних умов, наприклад, коли послідовник не відповідає на запит на примусовий вивід користувача протягом визначеного часу, або якщо послідовник переживає довгостроковий збій або вимкнення. У таких випадках користувачі можуть вручну активувати процес, який ставить контракт Rollup у застояному або зупиненому стані. Після цього користувачі можуть скласти доказ Меркла, щоб продемонструвати свою ситуацію з активами на Рівні 2 та вивести свою частку активів з адреси депозиту проекту Рівня 2 на Рівні 1.

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

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

Функція 'Примусове включення транзакції' Arbitrum

Однак примусові вилучення / капсули для втечі, схоже, не є єдиною антицензурною рішенням. Наприклад, Arbitrum використовує метод «примусового включення транзакції», де користувачі можуть спочатку подати транзакції / вилучення, які потрібно обробити Послідовнику, до відкладеного контракту Вхідної скриньки на Рівні 1 (L1). Якщо Послідовник не може обробити їх протягом 24 годин, користувачі можуть викликати функцію примусового включення на контракті Вхідної скриньки Послідовника L1, дозволяючи транзакцію безпосередньо включити в послідовність транзакцій Arbitrum (за допомогою спрацювання події on-chain, що повідомляє вузли Arbitrum, що кілька транзакцій, записаних відкладеної скриньки, потрібно включити в журнал L2).

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

“Порівняно з іншими, метод Arbitrum дещо простіший, але він все ще має недоліки. Він лише видає подію на ланцюжку, щоб повідомити вузли Arbitrum, що кілька транзакцій, які були проігноровані послідовником, повинні бути включені в найдовший ланцюжок L2, на відміну від протоколу Loopring та режиму / ескейп-подарунку StarkEx, які дозволяють користувачам безпосередньо зняти свої кошти на L1. Якщо вузли-викликачі в Arbitrum узгоджуються, щоб запустити цензурний атаку, здається можливим заморозити кошти користувачів на L2.

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

Зокрема, "операції, які потребують примусового включення", повинні бути визнані принаймні одним вузлом-викликачем ARB. Наразі існує дев'ять таких вузлів, і вони мають право вирішувати, які міжланцюжкові повідомлення між L2 та L1 схвалювати, і вони єдині, хто може видачу доказів шахрайства. Якщо ці дев'ять вузлів узгодяться разом, вони теоретично можуть скасувати "примусову транзакцію" користувача.

Отже, поточні транзакції щодо включення або вилучення сил в Arbitrum не є такими ж дозвільними, як режим ліквідації банкрутства від Loopring та StarkEx. Однак L2BEAT все ще високо оцінює цей підхід від Arbitrum. У майбутньому Arbitrum запустить механізм публікації бездозвільних доказів шахрайства під назвою BOLD, що ускладнить, якщо навіть не неможливо, спільне змовляння викликаючих вузлів (що вже зараз важко).

Згідно з даними з L2BEAT, наразі платформи рівня 2 (L2) з Загальною заблокованою вартістю (TVL), що перевищує 50 мільйонів доларів США, і не пропонують заходів щодо вирішення або Відмови Послідовника, або Відмови Пропозера, включають OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM та Metis. У виняткових випадках ці платформи L2 можуть призвести до заморожування активів користувачів і неможливості їх виведення з L2.

Отже, очевидно, що існує необхідність в механізмах, таких як примусові виведення або режими ліквідації банкрутства. Хоча наразі вони в основному ґрунтуються на теорії ігор між користувачами та сортувальниками (виробниками замовлень) і не можуть вважатися по-справжньому «виводимими в будь-який час» (Arbitrum має затримку 24 години, Loopring має затримку до 15 днів, StarkEx має максимальну затримку 7 днів), наявність цих механізмів безсумнівно краще, ніж їх відсутність зовсім. Проблему затримки у примусових виведеннях можна потенційно вирішити у майбутньому за допомогою більш вдосконалених конструкцій механізмів. Поточні конструкції враховують можливе використання MEV (Максимально екстрагована вартість) через forceInclusion, що вимагає введення затримок. Для отримання додаткових відомостей рекомендується консультуватися з офіційною документацією різних проєктів L2.

Зі зростанням включення децентралізованих послідовників в багатьох дорожнях L2 та постійних зусиллях таких суб'єктів, як Ethereum Foundation, під керівництвом Віталіка Бутеріна, навчати людей про безпеку 2-го рівня, функції, такі як антицензурна транзакційна функція в примусових виведеннях, ймовірно, здобудуть більше уваги. Це наблизить екосистему Ethereum Layer 2 до цензуростійкого, мінімізованого довіри фінансової інфраструктури. Якщо 2-й рівень досягне мінімізованого способу переміщення коштів вперед та назад, очікується, що більше робочих ринків та постачальників ліквідності увійдуть в інфраструктуру L2, просуваючи крок до масового прийняття web3.

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

1. Ця стаття перепублікована з [Faust, веб3 гік]. Усі авторські права належать оригінальному авторові [Faust, веб3 гік]. Якщо є зауваження до цього повторення, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони вирішать це негайно.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови здійснюються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.