В реальном мире почти у каждого небоскрёба есть незаменимый элемент: аварийный выход. Когда случаются непредвиденные события, такие как пожары или землетрясения, эти выходы становятся спасением для безопасности людей. Точно так же в экосистеме Уровня 2 Ethereum, которая удерживает миллиарды долларов в активах, функция "принудительного вывода", позволяющая пользователям безопасно вернуть активы обратно на Уровень 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 решат провести проверку транзакции против вас, они могут отказаться включать ваши транзакции в блок или отказать в признании блока, содержащего ваши транзакции. В этом случае ваши средства фактически застряли в этой цепочке и не могут быть изъяты:

Если вы не сможете убедить некоторых Валидаторов, чтобы в атаке проверки участвовало менее двух третей, или сможете объединить людей, чтобы разветвить Avalanche через социальное согласие. Очевидно, что в настоящее время у вас все еще есть способы быстро вывести свои средства из Avalanche. Однако мы должны учитывать, что требуется время для объединения более двух третей Валидаторов и инициирования проверки транзакции против конкретного адреса, что предоставляет проверяемому пользователю достаточно времени для 'сбежать'.

Но ситуация на Уровне 2 может быть совершенно иной. Сиквенсоры на Уровне 2 в основном управляются официальной командой. Если сиквенсор хочет запустить атаку проверки против вас, он может 'заморозить ваши деньги на Уровне 2,' эффективно отклоняя ваши запросы на передачу активов с L2 на L1. Согласно операционной механике L2, если вы не можете обойти сиквенсора для выполнения вывода, сиквенсор вполне может заморозить ваши активы на L2, предотвращая их передачу.

Итак, как можно решить эту проблему? Простыми словами, как мы можем реализовать функцию 'без разрешения' вывода, которая позволяет пользователям безопасно вернуть свои активы обратно на Уровень 1, даже если их тщательно проверяет Последователь или команда проекта Уровня 2? Некоторые команды проекта предложили идею децентрализованных Последователей, но это поверхностное решение. Если эти ограниченные числа Последователей сговариваются, чтобы вас проверить, они все равно могут 'заморозить' ваши активы. Более того, проблема анти-Сибил атак в узлах Proof of Stake (PoS) также проблематична (как видно в инциденте Multichain).

Самым эффективным решением будет настройка выделенного 'выхода' на блокчейне уровня 1, позволяющего пользователям выводить свои средства из Уровня 2 через этот L1 выход в случаях, когда они не получают ответа от Последователя в течение продолжительного времени.

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

Пользователи могут непосредственно инициировать принудительный вывод на Уровне 1, используя функцию forcedWithdraw в контракте ExchangeV3. Они должны объявить, какой из их аккаунтов на Уровне 2 в протоколе Loopring и какой токен они хотят вывести. Впоследствии контракт ExchangeV3 генерирует событие блокчейна, сигнализируя о том, что кто-то инициировал запрос на принудительный вывод. Поскольку все узлы в протоколе Loopring, включая Sequencer, работают с клиентом Geth, они будут проинформированы о принудительном выводе и соответствующем событии блокчейна из данных блока Ethereum.

Важно отметить, что принудительный вывод не обрабатывается немедленно, а вместо этого помещается в очередь pendingForcedWithdrawals в ожидании обработки. Обратив внимание на принудительный вывод, инициированный на Уровне 1, Секвенсор обычно запускает функцию Process в контракте ExchangeV3 в течение 15 дней. Эта функция осуществляет передачу токенов на цепи Ethereum инициатору вывода (из адреса депозита проекта Уровня 2 на цепи Ethereum к выводящему).

Если последователь не отвечает на запрос пользователя о принудительном выводе средств в течение 15 дней, пользователь может вызвать функцию notifyForcedRequestTooOld. Это действие приводит к тому, что контракт ExchangeV3 генерирует событие с именем WithdrawalModeActivated, уведомляя все узлы протокола Loopring о том, что режим ликвидации банкротства активирован.

Если режим ликвидации банкротства активирован, протокол Loopring V3 перестанет получать новые блоки L2, представленные Sequencer, что означает, что весь протокол Loopring перестанет работать на этот момент. Этот процесс продлится как минимум 30 дней.

Однако в режиме ликвидации банкротства пользователи по-прежнему могут вывести свои активы на Уровень 1, но им нужно представить доказательство Меркля, чтобы подтвердить статус/состояние своих активов, которое можно проверить в дереве статусов L2. (Докажите, что баланс ваших активов на Уровне 2 соответствует сумме, которую вы заявили при инициировании вывода.)

В статье описана модель ликвидации банкротства протокола Loopring, которая также известна как механизм "Аварийный выход" на L2BEAT. Эта модель срабатывает при определенных условиях, например, когда секвенсор не отвечает на запрос на принудительное изъятие активов пользователя в течение определенного времени, или если секвенсор испытывает длительное неисправное функционирование или выключение. В таких случаях пользователи могут вручную запустить процесс, который помещает контракт Rollup в замороженное или остановленное состояние. Пользователи могут затем составить доказательство Меркла, чтобы продемонстрировать свою ситуацию с активами на Уровне 2 и вывести свою часть активов из адреса депозита проекта на Уровне 1 в Layer 2.

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

Однако для построения доказательства Меркля сначала необходимо получить полное дерево состояния L2, что означает получение данных с полной ноды L2. Кроме того, для генерации доказательства Меркля требуется определенный фрагмент кода, явно демонстрирующий определенный уровень технического барьера. Для облегчения этого для большинства пользователей L2BEAT ранее заявили, что Уровень 2 должен настроить пакет открытых и открытых полных узлов, чтобы помочь пользователям получить статус всех учетных записей на L2 (включая баланс, количество транзакций и т. д.). Этот шаг также подчеркивает важность принудительного вывода и механизмов аварийного выхода.

Функция 'Принудительного Включения Транзакции' Arbitrum

Однако вынужденные выводы/спасательные капсулы, кажется, не единственное антицензурное решение. Например, Arbitrum использует метод «вынужденного включения транзакции», при котором пользователи могут сначала отправить транзакции/выводы, которые должны быть обработаны Sequencer'ом к задержанному контракту Inbox на уровне 1 (L1). Если Sequencer не обрабатывает их в течение 24 часов, пользователи могут вызвать функцию принудительного включения на контракте Sequencer Inbox на уровне 1, позволяя транзакции быть непосредственно включенными в последовательность транзакций Arbitrum (посредством генерации события на цепи, информирующего узлы Arbitrum, что несколько транзакций, записанных в задержанном Inbox, должны быть включены в журнал уровня 2).

В пассаже обсуждаются подходы различных блокчейн-протоколов к обработке транзакций, особенно сосредоточиваясь на Arbitrum в сравнении с Loopring и StarkEx. Вот перевод:

По сравнению с другими, метод Arbitrum несколько проще, но у него все равно есть недостатки. Он просто генерирует on-chain событие, чтобы сообщить узлам Arbitrum, что несколько транзакций, игнорируемых секвенсором, должны быть включены в L2 самую длинную цепочку, в отличие от протокола Loopring и режима банкротства/подъемного аппарата StarkEx, которые позволяют пользователям напрямую выводить свои средства на L1. Если узлы-вызыватели в Arbitrum сговариваются, чтобы запустить цензурную атаку, кажется возможным заморозить средства пользователей на L2.

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

Более конкретно, 'транзакции, требующие принудительного включения', должны быть признаны по крайней мере одним узлом-вызывателем ARB. В настоящее время их девять, и они имеют право решать, какие межцепочные сообщения между L2 и L1 одобрять, а также только они могут выдавать доказательства мошенничества. Если эти девять узлов замышляют вместе, теоретически они могут аннулировать 'принудительную транзакцию' пользователя.

Таким образом, текущие транзакции включения или вывода силы в Arbitrum не такие бесразрешительные, как режим ликвидации банкротства Loopring и StarkEx. Однако L2BEAT по-прежнему высоко оценивает этот подход от Arbitrum. В будущем Arbitrum запустит механизм публикации бесразрешительного доказательства мошенничества под названием BOLD, что сделает сложным, если не невозможным, для узлов-вызывателей сговариваться (что уже сейчас сложно).

Согласно данным от L2BEAT, на данный момент платформы Layer 2 (L2) с общим заблокированным значением (TVL) более 50 миллионов долларов США, которые не предлагают мер по решению проблем с отказом последователя или отказом предложителя, включают OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM и Metis. В экстремальных случаях эти платформы Layer 2 могут привести к заморозке активов пользователей и невозможности их вывода из 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 гик]. Если есть возражения к данному перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат статей, переведенных на другие языки, запрещены.