Автор: Faust, Geek Web3
В реальном мире почти у каждого высотного здания есть неотъемлемый ингредиент: аварийный выход. Когда случаются чрезвычайные ситуации, такие как пожары и землетрясения, аварийные выходы являются спасением для обеспечения безопасности жизни людей. В системе кастодиальной платформы Ethereum Layer 2, которая несет в себе активы на десятки миллиардов долларов, функция «принудительного вывода», которая позволяет пользователям безопасно выводить активы на уровень 1, стала незаменимым и необходимым средством.
В своей недавней статье «Разные типы layer 2s» Виталик также подчеркнул, что способность пользователей беспрепятственно выводить активы из Layer 2 в Layer 1 является очень важным показателем безопасности.
Тем не менее, вопрос «плавного вывода», похоже, не привлекал большого внимания со стороны большинства людей в прошлом, и даже многие проекты уровня 2 не запустили функцию «принудительного вывода» или «спасательной капсулы». В эпоху, когда экосистема L2 не находится в полном разгаре, игнорирование «вывода средств без разрешения» не кажется проблемой. Но теперь, когда активы Layer 2 превышают 12 миллиардов долларов, он стал «слишком большим, чтобы обанкротиться». Если у такого небоскреба нет безопасного выхода, последствия просто невообразимы.
Для того, чтобы побудить читателей обратить внимание на риски безопасности уровня 2, Geek Web3 возьмет Loopring Protocol V3 и Arbitrum в качестве примеров ниже, чтобы объяснить, почему «функции вывода без разрешения», такие как принудительное извлечение и аварийный люк, являются неотъемлемой частью уровня 2.
(Согласно браузеру L2BEAT dYdX, функция принудительной транзакции/вывода средств dYdX была использована 152 раза, и было зафиксировано 7 крупных выводов на сумму более 1 миллиона долларов.)
Сопротивление цензуре — большая проблема: что делать, если секвенсор намеренно отклоняет ваш запрос****
В прошлом научно-популярные статьи о Layer 2 часто сталкивались с проблемой, то есть большую часть времени они фокусировались на «безопасности» и «удобстве использования» на поверхности, но игнорировали «сопротивление цензуре». Даже когда речь заходит о децентрализованных секвенсорных решениях, многие обращают внимание на то, является ли MEV децентрализованным, а не на устойчивость к цензуре.
Другими словами, большинство людей, как правило, сосредотачиваются на том, являются ли переходы состояний уровня 2 действительными, может ли секвенсор украсть монеты и используется ли система доказательства мошенничества/валидности, но они игнорируют риск, который не следует упускать из виду: что, если Sequencer продолжает отклонять ваши запросы на транзакции, или просто не работает в течение длительного времени, или даже выходит из строя? **
Вы знаете, что во время сбоя в работе Solana были люди, которые не смогли вовремя покрыть свои позиции, потому что их активы находились на грани ликвидации, что поставило под угрозу активы на миллионы долларов. **Как только происходит такое отклонение запроса пользователя, причиненный экономический ущерб не является незначительным.
Даже если бы в такой ситуации могли оказаться всего несколько человек, если бы она упала на какого-то кита с большими деньгами, весь рынок мог бы пострадать (допустим, у кого-то есть активы на сотни миллионов долларов в протоколе кредитования Defi на Ethereum, который можно было бы ликвидировать за неделю, но он находится в санкционном списке OFAC за использование Tornado). Большая часть средств этого человека находится на ОП, и секвенсор ОП работает с OFAC, чтобы отклонить его запрос)
С таким же успехом мы могли бы спроецировать эту проблему на публичные цепочки, такие как avalanche или polygon, которые не зависят от Ethereum. Если более 2/3 узлов консенсуса валидаторов на Avalanche решат подвергнуть цензуре ваши транзакции, они могут отказаться включать ваш Txn в блок или не распознать блок, содержащий ваш Txn. В это время ваши деньги в основном похоронены в этой цепочке и не могут выбраться:**
Если только вы не сможете кооптировать некоторых валидаторов так, чтобы менее 2/3 валидаторов были вовлечены в атаку цензуры, или вы можете призвать некоторых людей разветвить Avalanche через социальный консенсус. Очевидно, что на данный момент у вас все еще есть способ быстро вывести средства из Avalanche, и мы должны учитывать, что более 2/3 валидаторов объединяют усилия, чтобы инициировать проверку транзакции определенного адреса, что само по себе занимает некоторое время, что оставит достаточно времени для «побега» подвергшихся цензуре пользователей.
Но на Layer 2 ситуация может быть совсем другой. Layer 2 Sequencer, как правило, управляется самим чиновником, и если Sequencer захочет начать на вас цензурную атаку, он может «заморозить ваши деньги в Layer 2», то есть полностью отклонить ваш запрос на транзакцию по кросс-активам из L2 в L1. Очевидно, что в соответствии с механизмом работы L2, если вы не можете обойти секвенсор для выполнения операции вывода, вполне возможно, что Sequencer заморозит активы в L2 и не сможет быть передан.
Так как же решить такую проблему? На самом деле, грубо говоря, как реализовать функцию «без разрешения», чтобы пользователи могли выводить свои активы на уровень 1 без какого-либо вреда при проверке участниками проекта Sequencer или Layer 2? Есть некоторые проекты, которые предложили децентрализованный Sequencer, но это не паллиативное решение, и если очень ограниченное количество секвенсоров объединит усилия для проверки вас, вы все равно можете «заморозить» свои активы, и анти-ведьма POS-узлов также является сложной проблемой (см. События Multichain).
Наиболее эффективным способом сделать это является настройка «выхода» непосредственно в цепочке L1, что позволит пользователям выводить средства из L2 через выделенный выход на L1, если они не получают ответа от Sequencer в течение длительного времени. **
**** Loopring Protocol V3 Модель принудительного выхода и ликвидации банкротства****
Здесь мы возьмем в качестве примера версию V3 протокола Loopring, в которой перечислены два различных сценария принудительного вывода средств, инициированных пользователем, первый случай:
Пользователи могут инициировать принудительный вывод средств непосредственно на уровне 1 через функцию forcedWithdraw в контракте 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 блоки, отправленные Sequencer, что означает, что весь протокол Loopring перестанет работать. Этот процесс длится не менее 30 дней.
Тем не менее, в режиме ликвидации банкротства пользователи по-прежнему могут вывести свои активы на уровне 1, но им необходимо предоставить доказательство Меркла, чтобы подтвердить свой статус/статус активов, что можно проверить в дереве состояний L2. (Докажите, что баланс ваших активов на уровне 2 соответствует сумме, которую вы задекларировали при инициировании вывода средств)
Эта модель ликвидации банкротства протокола Loopring также известна как механизм аварийного выхода на L2BEAT. Этот режим запускается при условии, что секвенсор не отвечает на запрос пользователя о принудительном выводе средств в течение указанного времени, или если секвенсор имеет длительный сбой или простой. В это время пользователь может вручную перевести контракт Rollup в режим замораживания/остановить его выполнение. Затем пользователи могут создавать доказательства Меркла, чтобы доказать свои активы на уровне 2, и выводить свои собственные активы с депозитного адреса участника проекта L2 в L1. **
В документации StarkEx также нарисована специальная принципиальная схема этого процесса. Если пользователь L2 не получает ответ секвенсора в конце 7-дневного окна, когда пользователь L2 отправляет запрос на принудительный вывод средств на L1, пользователь L2 может вызвать функцию запроса на замораживание, чтобы заставить L2 войти в период замораживания. В этом случае секвенсор L2 не сможет обновить состояние L2 на L1, и потребуется 1 год после замораживания состояния L2, чтобы разморозиться. После этого пользователи могут отправить Merkle Proof и вывести деньги.
Однако для того, чтобы построить доказательство Меркла, нужно сначала знать полное дерево состояний L2, то есть нужно найти полный узел L2 для запроса данных, и в то же время нужен кусок кода для генерации доказательства Меркла, что, очевидно, требует определенного технического порога. Для удобства большинства пользователей L2BEAT ранее заявлял, что уровень 2 должен настроить несколько полных узлов с открытыми разрешениями и открытым исходным кодом, чтобы помочь пользователям узнать состояние всех учетных записей на L2 (включая баланс, количество транзакций и т. д.). Этот шаг также иллюстрирует важность обязательного вывода войск и механизмов эвакуации.
Функция Arbitrum “Принудительное включение транзакций”
Но принудительный вывод войск и эвакуационные капсулы, похоже, не единственное решение, устойчивое к цензуре. Например, Arbitrum использует метод «принудительного включения транзакций», пользователь может сначала отправить Txn/with, который должен быть обработан Sequencer в отложенном контракте Inbox на L1, и если Sequencer не обрабатывал его более 24 часов, пользователь может вызвать функцию принудительного включения контракта Sequencer Inbox на L1. Пусть Txn будет включен непосредственно в последовательность транзакций Arbitrum** (выдайте ончейн-событие, чтобы проинформировать полные узлы Arbitrum о том, что Txn с несколькими отложенными записями в почтовом ящике должны быть включены в реестр L2).
В отличие от этого, подход Arbitrum проще, но ему все же немного не хватает: он только генерирует ончейн-событие, сообщающее узлу Arbitrum о том, что есть несколько транзакций, которые секвенсор игнорирует, и которые должны быть включены в самую длинную цепочку L2, вместо того, чтобы позволить пользователям выводить деньги непосредственно на L1, как это делают Loopring Protocol и режим банкротства/спасательная капсула StarkEx. Если узлы-претенденты Arbitrum объединятся, чтобы начать цензурную атаку, похоже, что все еще можно будет заморозить деньги пользователей на L2. **
Таким образом, принудительное включение в Arbitrum не является достаточно свободным от разрешений, и хотя было бы неплохо сказать, что секвенсор игнорировал запрос пользователя forceInclusion до тех пор, пока существовал честный узел, готовый опубликовать доказательство мошенничества, это все же вводит определенную степень предположения о доверии, хотя и в меньшей степени.
Точнее, «транзакции, которые должны быть в обязательном порядке включены», должны быть признаны хотя бы одним узлом претендента ARB, у которого в настоящее время есть 9 узлов, которые имеют право решать, какие кроссчейн-сообщения L2-L1 разрешить, и теперь только они могут выдавать доказательства мошенничества. ** До тех пор, пока эти 9 узлов находятся в сговоре друг с другом, теоретически «принудительная транзакция» пользователя все еще может быть признана недействительной. **
Таким образом, нынешнее обязательное включение транзакций/выводов в Arbitrum не похоже на модель ликвидации банкротства Loopring и StarkEx, которая не требует разрешения узла L2. Тем не менее, L2BEAT все же дал Arbitrum высокую оценку этому решению. Потому что в будущем Arbitrum запустит механизм Permissionless fraud proof под названием BOLD, и в то время узлам-претендентам будет сложно или невозможно вступить в сговор (на самом деле это сложно сделать сейчас).
По данным L2BEAT, текущий TVL составляет более 50 миллионов долларов, и нет никакой реакции ни на один из сбоев секвенсора или пропозера: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. В крайних случаях эти L2 могут привести к замораживанию пользовательских активов в L2. **
Таким образом, очевидно, что модель принудительного ухода или ликвидации банкротства имеет свою необходимость, хотя на данный момент она полагается только на пользователя-секвенсора в качестве контрагентской игры для функционирования, ** на самом деле не «готов к выводу» ** (Arbitrum имеет 24-часовую задержку и может потерпеть неудачу, Loopring имеет максимальную задержку в 15 дней, StarkEx имеет максимальную задержку в 7 дней), но ясно, что «что-то лучше, чем ничего». Более того, считается, что проблема задержек в принудительном изъятии средств будет решена в будущем с помощью более сложной конструкции механизма** (в настоящее время это в основном связано с тем, что некоторые ученые MEV могут использовать forceInclusion для инициирования опережающих транзакций, поэтому необходимо ввести задержки). Для получения более подробной информации, пожалуйста, обратитесь к официальным документам основных участников проекта L2.
С включением децентрализованного Sequencer во все больше и больше дорожных карт L2, а Ethereum Foundation во главе с Виталиком продолжает просвещать людей о безопасности уровня 2, устойчивым к цензуре функциям транзакций, таким как принудительный вывод средств, обязательно будет уделяться все больше и больше внимания, что сделает систему Ethereum Layer2 ближе к устойчивой к цензуре и не требующей доверия системе финансовой инфраструктуры. Считается, что если Layer 2 реализует трастовый доступ к средствам, в инфраструктуру L2 войдет больше маркет-мейкеров и поставщиков ликвидности, а массовое внедрение всего web3 будет продвигаться еще на один шаг вперед.
