От теории к практике: анализ механизма реализации антицензурных транзакций с помощью Ethereum Rollup

Исходное название: «Введение в механизм Force Inclusion Rollup»

Автор: NIC Lin, руководитель Taipei Ethereum Meetup

Вчера произошло событие, которое потрясло многих: второй уровень Ethereum Linea, запущенный материнской компанией Metamask Consensys, был остановлен, и официально заявлено, что цель этого шага — снизить влияние хакерской атаки Velocore. Это невольно напоминает о том, как ранее цепочка BSC (BNB Chain) была остановлена по инициативе властей, чтобы уменьшить ущерб от хакерских атак. Каждый раз, когда люди обсуждают такие события, они начинают сомневаться в децентрализованных ценностях, которые пропагандирует Web3.

Конечно, основная причина вышеупомянутого события заключается в недостаточной зрелости инфраструктуры, а именно в недостаточной децентрализации: если цепочка достаточно децентрализована, то она не должна просто так останавливаться. Из-за уникальной конструкции второго уровня Ethereum, большинство Layer2 зависят от централизованного Sequencer, хотя в последние годы все больше говорят о децентрализованных сортировщиках, но учитывая цель и структуру второго уровня, можно с уверенностью сказать, что сортировщики Layer2, скорее всего, не будут сильно децентрализованы и в конечном итоге могут оказаться менее децентрализованными, чем BSC. Если это действительно так, что нам делать?

На самом деле для второго уровня наиболее непосредственная угроза, связанная с недецентрализованностью сортировщика, заключается в антиконтрольности и активности. Если сущностей (Sequencer), обрабатывающих транзакции, очень мало, то они обладают абсолютной властью над тем, будут ли они вам служить: захотят — откажут, а вы, возможно, ничего не сможете с этим сделать. Как решить проблему антиконтрольности Layer2, очевидно, является важной темой.

За последние несколько лет различные вторые уровни Ethereum предложили множество решений для проблемы антиконтрольности, такие как принудительное снятие и функции спасательных капсул Loopring, Degate и StarkEx, а также функции Force Inclusion Arbitrum и других OP Rollup, которые могут в определенных условиях создать баланс сил против Sequencer, чтобы предотвратить его произвольный отказ в обработке транзакционных запросов пользователей.

В сегодняшней статье NIC Lin из ассоциации Ethereum в Тайбэе делится своим опытом, экспериментируя с антиконтрольными функциями четырех основных Rollup, глубоко анализируя механизм Force Inclusion с точки зрения рабочего процесса и методов операций, что особенно ценно для сообщества Ethereum и крупных держателей активов.

Контроль транзакций и Force Inclusion

Антиконтрольность транзакций (Censorship Resistance) очень важна для блокчейна; если блокчейн может произвольно контролировать и отказывать в транзакциях, инициированных пользователями, то он не отличается от сервера Web2. В настоящее время антиконтрольная способность Ethereum зависит от множества валидаторов; если кто-то хочет контролировать транзакцию Боба и не позволяет ей попасть в цепочку, ему нужно либо попытаться подкупить большинство валидаторов в сети, либо спамить всю сеть, постоянно отправляя транзакции с более высокими комиссиями, чем у Боба, чтобы занять место в блоке. В любом случае, стоимость будет очень высокой.

Примечание: в текущей архитектуре PBS Ethereum стоимость контроля транзакций значительно снижена, можно обратиться к пропорции блоков, контролирующих транзакции Tornado Cash в соответствии с OFAC. Текущая антиконтрольная способность зависит от независимых валидаторов и Relay за пределами юрисдикции OFAC и правительства.

Но что насчет Rollup? Rollup не требует большого количества валидаторов для обеспечения безопасности; даже если у Rollup есть только одна централизованная роль (Sequencer) для создания блоков, он все равно так же безопасен, как L1. Но безопасность и антиконтрольная способность — это разные вещи; даже если Rollup так же безопасен, как Ethereum, в случае наличия только одного централизованного Sequencer он может контролировать любую транзакцию пользователя.

Sequencer может отказать в обработке транзакций пользователей, что приведет к блокировке средств пользователей и невозможности покинуть этот Rollup

Механизм Force Inclusion

Вместо того чтобы требовать от Rollup большого количества децентрализованных Sequencer, лучше напрямую использовать антиконтрольную способность L1:

Sequencer должен упаковать данные транзакций и отправить их в контракт Rollup на L1, так что можно добавить в контракт дизайн, позволяющий пользователям самостоятельно вставлять транзакции в контракт Rollup, этот механизм называется «Force Inclusion». Пока Sequencer не может контролировать пользователей на уровне L1, он не может помешать пользователям принудительно вставлять транзакции на L1. Таким образом, Rollup может унаследовать антиконтрольную способность L1.

Sequencer не может контролировать L1 транзакции пользователей, если только не понесет очень высокие затраты

Как должны действовать принудительные транзакции?

Если разрешить вставлять транзакции напрямую в контракт Rollup через Force Inclusion (то есть немедленно), состояние Rollup изменится немедленно, например, если Боб вставляет транзакцию «перевести 1000 DAI Кэрол» через механизм Force Inclusion, если транзакция немедленно вступает в силу, то в последнем состоянии баланс Боба уменьшится на 1000 DAI, а Кэрол увеличится на 1000 DAI.

Если Force Inclusion может напрямую записать транзакцию в контракт Rollup и немедленно вступить в силу, состояние изменится немедленно

Если в это время Sequencer также собирает транзакции вне цепи и отправляет следующую партию транзакций в контракт Rollup, то это может быть затронуто транзакцией, которую Боб принудительно вставил и которая немедленно вступила в силу. Эту проблему необходимо избегать, поэтому Rollup обычно не позволяет транзакциям Force Inclusion немедленно вступать в силу, а сначала позволяет пользователям вставлять транзакции в очередь ожидания на L1, переходя в состояние «в ожидании».

Когда Sequencer упаковывает транзакции вне цепи и отправляет их в контракт Rollup, он выбирает, вставлять ли упомянутую транзакцию в последовательность транзакций; если Sequencer продолжает игнорировать эти транзакции в состоянии «в ожидании», после окончания окна пользователи могут принудительно вставить эти транзакции в контракт Rollup.

Sequencer может решить, когда «включить» транзакции из очереди ожидания

Sequencer все еще может отказать в обработке транзакций из очереди ожидания

Если Sequencer отказывается долгое время, через некоторое время любой может принудительно вставить транзакцию в контракт Rollup через функцию Force Inclusion

Далее мы последовательно представим механизмы Force Inclusion для четырех известных Rollup: Optimism, Arbitrum, StarkNet и zkSync.

Механизм Force Inclusion Optimism

Сначала рассмотрим процесс Deposit в Optimism, этот Deposit не только означает внесение денег в Optimism, но и включает в себя «отправку информации от пользователя на L2» на L2. Узлы L2, получив новые сообщения о внесении, преобразуют их в транзакции L2 для выполнения и отправляют получателю, указанному в сообщении.

Пользователь отправляет сообщение от L1 на L2

Контракт L1CrossDomainMessenger

Когда пользователь хочет внести ETH или токены ERC-20 в Optimism, он взаимодействует с контрактом L1StandardBridge на фронтенде, указывая, сколько средств внести и на какой адрес L2 отправить эти активы.

Контракт L1StandardBridge передает сообщение в следующий уровень — контракт L1CrossDomainMessenger, который служит компонентом для взаимной связи между L1 и L2; L1StandardBridge использует этот универсальный компонент связи для общения с L2StandardBridge на L2, чтобы определить, кто может выпускать токены на L2 или кто может разблокировать токены с L1.

Если разработчику необходимо создать контракт, который будет взаимодействовать и синхронизировать состояние между L1 и L2, он может построить его на основе контракта L1CrossDomainMessenger.

Сообщение пользователя передается через контракт CrossDomainMessenger с L1 на L2

Примечание: в некоторых изображениях этой статьи CrossDomainMessager написан как CrossChainMessager.

Контракт OptimismPortal

Контракт L1CrossDomainMessenger затем отправляет сообщение в самый нижний уровень — контракт OptimismPortal, который после обработки выбрасывает событие под названием TransactionDeposited, параметры которого включают «отправителя сообщения», «получателя сообщения» и соответствующие параметры выполнения.

Затем узлы Optimism на L2 слушают событие Transaction Deposited, выбрасываемое контрактом OptimismPortal, и преобразуют параметры события в транзакцию L2, инициатором которой будет «отправитель сообщения», указанный в параметрах события, а получателем будет «получатель сообщения» из параметров события, другие параметры транзакции также берутся из параметров вышеупомянутого события.

Узлы L2 преобразуют параметры события Transaction Deposited, выбрасываемого OptimismPortal, в транзакцию L2

Например, это транзакция, в которой пользователь вносит 0.01 ETH через контракт L1StandardBridge; это сообщение и ETH передаются в контракт OptimismPortal (адрес 0xbEb5…06Ed), а затем через несколько минут преобразуются в транзакцию L2:

Отправителем сообщения является контракт L1CrossDomainMessenger; получателем является контракт L2CrossDomainMessenger на L2; содержание сообщения — это информация о том, что L1StandardBridge получил депозит 0.01 ETH от Боба. После этого произойдут дополнительные процессы, такие как выпуск 0.01 ETH для L2StandardBridge, который затем передаст его Бобу.

Как это инициировать

Когда вы хотите принудительно включить транзакцию в контракт Rollup Optimism, вы должны добиться того, чтобы транзакция «инициировалась с вашего адреса L2 на L2 и должна быть выполнена», и в этом случае вы должны использовать свой адрес L2, чтобы напрямую отправить сообщение в контракт OptimismPortal (обратите внимание, что контракт OptimismPortal на самом деле находится на L1, но формат адреса OP совпадает с форматом адреса L1, вы можете просто вызвать указанный контракт с тем же адресом, что и ваш L2-аккаунт).

Затем инициатором транзакции, преобразованной из события Transaction Deposited, станет ваш L2-аккаунт, и в этот момент формат транзакции будет таким же, как у обычной транзакции L2.

В транзакции L2, преобразованной из события Transaction Deposited, инициатором будет сам Боб; получателем будет контракт Uniswap; и будет прикреплено указанное ETH, как будто Боб сам инициировал транзакцию L2

Если вы хотите вызвать функцию Force Inclusion в Optimism, вам нужно напрямую вызвать функцию depositTransaction контракта OptimismPortal, заполнив параметры транзакции, которую вы хотите выполнить на L2

Я провел простой эксперимент Force Inclusion, эта транзакция хотела достичь следующего: перевести деньги на свой адрес на L2 (0xeDc1…6909) и прикрепить текстовое сообщение «force inclusion».

Это транзакция L1, в которой я вызываю функцию depositTransaction контракта OptimismPortal; можно увидеть, что в выброшенном событии Transaction Deposited от «from» и «to» — это я сам.

Остальные значения в разделе opaque Data закодированы как «сколько ETH добавил вызывающий функцию depositTransaction», «сколько ETH инициатор транзакции должен передать получателю», «GasLimit транзакции L2» и «Data для L2 получателя» и т. д.

После декодирования вышеуказанной информации мы получим:

«Сколько ETH добавил вызывающий функцию depositTransaction»: 0, так как я не вносил ETH с L1 на L2;

«Сколько ETH инициатор транзакции должен передать получателю»: 5566 (wei)

«GasLimit транзакции L2»: 50000

«Data для L2 получателя»: 0x666f72636520696e636c7573696f6e, что является шестнадцатеричным кодом строки «force inclusion».

Вскоре появилась преобразованная транзакция L2: я перевел деньги себе на L2, сумма составила 5566 wei, а Data — строка «force inclusion». Также можно заметить, что в предпоследней строке Other Attributes тип транзакции (TxnType) отображается как системная транзакция 126 (System), что означает, что эта транзакция не была инициирована мной на L2, а была преобразована из события Deposited L1.

Преобразованная транзакция L2

Если вы хотите вызвать контракт L2 через Force Inclusion и отправить разные Data, вам просто нужно заполнить параметры в функции depositTransaction, просто помните, что нужно использовать тот же адрес L1, что и у вашего L2-аккаунта, чтобы при преобразовании события Deposited в транзакцию L2 инициатором была ваша учетная запись L2.

SequencerWindow

Ранее упомянутый узел Optimism L2 преобразует событие Transaction Deposited в транзакцию L2; на самом деле этот узел Optimism относится к Sequencer, поскольку это связано с сортировкой транзакций, поэтому только Sequencer может решить, когда преобразовать вышеупомянутое событие в транзакцию L2.

Когда Sequencer обнаруживает событие TransactionDeposited, он не обязательно сразу преобразует событие в транзакцию L2; может быть задержка, максимальная продолжительность которой называется SequencerWindow.

В настоящее время Sequencer Window в основной сети Optimism составляет 24 часа, то есть когда пользователь вносит деньги с L1 или принудительно включает транзакцию, в худшем случае она будет включена в историю транзакций L2 только через 24 часа.

Механизм Force Inclusion Arbitrum

В Optimism операция Deposit на L1 выбрасывает событие Transaction Deposited, после чего остается ждать, пока Sequencer включит вышеупомянутую операцию; но в Arbitrum операции, происходящие на L1 (внесение денег или отправка сообщений на L2 и т. д.), будут храниться в очереди на L1, а не просто выбрасывать событие.

Sequencer получает определенное время, чтобы включить транзакции из вышеупомянутой очереди в историю транзакций L2; если время истечет, и Sequencer ничего не сделает, любой может завершить эту задачу за Sequencer.

Arbitrum будет поддерживать очередь на L1; если Sequencer не обработает транзакции в очереди, по истечении времени любой может принудительно включить транзакции из очереди в историю транзакций L2

В дизайне Arbitrum операции, такие как внесение средств, должны проходить через контракт Delayed Inbox, как следует из названия, операции здесь будут задержаны; другой контракт — Sequencer Inbox, это место, где Sequencer загружает транзакции L2 на L1. Каждый раз, когда Sequencer загружает транзакции L2, он может одновременно извлекать некоторые ожидающие транзакции из Delayed Inbox и записывать их в историю транзакций.

Sequencer может одновременно извлекать транзакции из DelayedInbox, когда записывает новые транзакции

Сложный дизайн и недостаток документации

Если читатели напрямую обратятся к официальному разделу Arbitrum о Sequencer и Force Inclusion, они увидят, что там упоминается, как примерно работает Force Inclusion, а также некоторые названия параметров и функций:

Пользователь сначала вызывает функцию sendUnsignedTransaction контракта DelayedInbox; если Sequencer не включит ее в течение примерно 24 часов, пользователь может вызвать функцию forceInclusion контракта SequencerInbox. Однако официальные ссылки на функции не добавлены в документацию на сайте, и их нужно искать в коде контракта.

Когда вы находите функцию sendUnsignedTransaction, вы обнаруживаете, что вам нужно самостоятельно заполнить значения nonce и maxFeePerGas. Чей адрес nonce? Какой сети maxFeePerGas? Как лучше заполнить? Без документации, даже Natpsec нет. Затем вы также обнаружите в контракте Arbitrum кучу похожих функций:

sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, и ни одна из них не имеет документации, объясняющей различия между этими функциями, как их использовать и как заполнять параметры, даже Natpsec нет.

Вы пробуете заполнить параметры и отправить транзакцию, надеясь найти правильный способ, но обнаруживаете, что все эти функции выполняют AddressAliasing для вашего адреса L1, в результате чего инициатором транзакции на L2 становится совершенно другой адрес, и ваш адрес L2 остается неподвижным.

sendL2Message

Позже, случайно открыв Google, я обнаружил, что у Arbitrum есть собственная библиотека учебных программ, в которой есть скрипты, демонстрирующие, как отправлять транзакции L2 с L1 (что и означает Force Inclusion), и функции, которые они перечисляют, совершенно не совпадают с упомянутыми выше, а называются sendL2Message, и параметр message, который нужно передать, оказывается подписанной транзакцией L2?

Кто бы мог подумать, что «сообщение, отправляемое на L2 через Force Inclusion», на самом деле будет «подписанной транзакцией L2»? И нет никаких документов или Natspec, объясняющих, когда и как использовать эту функцию.

Заключение: вручную создать принудительную транзакцию Arbitrum довольно сложно, рекомендуется просто следовать официальному учебнику и использовать Arbitrum SDK. Arbitrum не имеет четкой документации для разработчиков и аннотаций к коду, как у других Rollup, многие функции и параметры недостаточно объяснены, что заставляет разработчиков тратить больше времени на интеграцию и использование, чем ожидалось. Я также спрашивал людей из Arbitrum в Discord, но не получил удовлетворительного ответа.

Когда я спрашивал в Discord, они просто говорили мне посмотреть на sendL2Message, не желая объяснять функции других функций (даже функции sendUnsignedTransaction, упомянутой в документации Force Inclusion), что они делают, как их использовать и когда их использовать.

Механизм Force Inclusion StarkNet

К сожалению, в StarkNet в настоящее время нет механизма Force Inclusion. Есть только две статьи на официальном форуме, обсуждающие контроль и Force Inclusion.

Неудачные транзакции, которые невозможно доказать

Вышеупомянутое связано с тем, что система нулевых знаний StarkNet не может доказать неудачную транзакцию, поэтому Force Inclusion не может быть разрешен. Если кто-то злонамеренно (или случайно) принудительно включит неудачную транзакцию, которую невозможно доказать, StarkNet просто зависнет: поскольку транзакция была принудительно включена, Prover должен доказать, что эта транзакция не удалась, но он не может этого сделать.

StarkNet ожидает внедрить функцию доказательства неудачных транзакций в версии v0.15.0, после чего механизм Force Inclusion должен быть реализован.

Механизм Force Inclusion zkSync

Передача сообщений L1->L2 и механизм Force Inclusion в zkSync осуществляется через функцию requestL2Transaction контракта MailBox, пользователь указывает адрес L2, calldata, количество прикрепленного ETH, значение L2GasLimit и т. д., requestL2Transaction объединяет эти параметры в транзакцию L2 и помещает ее в приоритетную очередь (PriorityQueue), Sequencer будет указывать, сколько транзакций нужно извлечь из приоритетной очереди, когда он упаковывает транзакции для загрузки на L1 (через функцию commitBatches).

Форма Force Inclusion в zkSync похожа на Optimism, обе используют адрес инициатора L2 (который совпадает с адресом L1) для вызова соответствующих функций и заполнения данных (вызываемое лицо, calldata и т. д.), в отличие от Arbitrum, где нужно заполнить подписанную транзакцию L2; но по дизайну она аналогична Arbitrum, обе поддерживают очередь Queue на L1, и Sequencer извлекает транзакции, которые пользователи отправляют напрямую из очереди и записывает их в историю транзакций.

Если вы используете официальный мост zkSync для внесения ETH, например, эта транзакция вызывает функцию requestL2Transaction контракта MailBox, она помещает транзакцию L2 на внесение ETH в приоритетную очередь и выбрасывает событие NewPriorityRequest. Поскольку контракт кодирует данные транзакции L2 в строку байтов, их трудно прочитать, если посмотреть на параметры этой транзакции L1, можно увидеть, что адрес L2 получателя также является инициатором транзакции (поскольку это депозит для себя), поэтому через некоторое время, когда Sequencer извлекает эту транзакцию из приоритетной очереди и включает ее в историю транзакций, она будет преобразована в транзакцию, в которой он переводит деньги самому себе, а сумма перевода будет равна количеству ETH, указанному инициатором в транзакции L1.

В транзакции L1Deposit инициатором и получателем являются 0xeDc1…6909, сумма составляет 0.03 ETH, calldata пуст.

На L2 появится транзакция, в которой 0xeDc1…6909 переводит деньги самому себе, тип транзакции (TxnType) — 255, что означает системную транзакцию

Затем я, как и в предыдущем эксперименте с функцией принудительного перевода OP, вызвал функцию requestL2Transaction в zkSync и отправил транзакцию перевода самому себе: без прикрепленного ETH, calldata содержит шестнадцатеричный код строки «force inclusion».

Затем она была преобразована в транзакцию, в которой он переводит деньги самому себе на L2, а calldata содержит шестнадцатеричный код строки «force inclusion»: 0x666f72636520696e636c7573696f6e.

Когда Sequencer извлекает транзакцию из PriorityQueue и записывает ее в историю транзакций, на L2 она будет преобразована в соответствующую транзакцию L2

С помощью функции requestL2Transaction пользователь может использовать тот же аккаунт L1, что и у L2, чтобы отправить данные на L1, указать адрес L2 получателя, прикрепленное количество ETH и calldata. Если пользователь хочет вызвать другие контракты с разными Data, то ему просто нужно заполнить параметры в функции requestL2Transaction.

Функция принудительного включения для пользователей еще не реализована

Хотя транзакции L2 помещаются в приоритетную очередь, и срок ожидания включения этой транзакции в историю транзакций L2 рассчитывается, в текущем дизайне zkSync нет функции Force Inclusion, позволяющей пользователям принудительно выполнять транзакции, что означает, что это только частичное решение. То есть, хотя существует «срок ожидания включения», на самом деле это все еще «зависит от того, захочет ли Sequencer включить»; Sequencer может дождаться истечения срока и включить, а может никогда не включить никакие транзакции из приоритетной очереди.

В будущем zkSync, вероятно, добавит соответствующие функции, позволяющие пользователям принудительно включать транзакции в историю транзакций L2, если срок действия истек, но они еще не были включены Sequencer, так что это будет действительно эффективный механизм Force Inclusion.

Резюме

L1 полагается на множество валидаторов для обеспечения «безопасности» и «антиконтрольной способности» сети, в то время как Rollup записываются транзакции только небольшим количеством или даже одним Sequencer, что делает антиконтрольную способность еще более слабой. Поэтому Rollup необходимо иметь механизм Force Inclusion, чтобы пользователи могли обойти Sequencer и записать транзакции в историю, избегая контроля Sequencer, что может привести к невозможности использования и вывода средств из этого Rollup.

Force Inclusion позволяет пользователям принудительно записывать транзакции в историю, но в дизайне необходимо выбирать между «можно ли немедленно вставить транзакцию в историю и сделать ее немедленно действующей». Если разрешить транзакции немедленно вступать в силу, это негативно скажется на Sequencer, поскольку все транзакции, ожидающие включения на L2, могут быть затронуты принудительно включенными транзакциями на L1.

Поэтому в настоящее время механизмы Force Inclusion в Rollup сначала помещают транзакции, вставленные на L1, в состояние ожидания и предоставляют Sequencer определенное время для реакции и выбора, хочет ли он включить эти ожидающие транзакции.

zkSync и Arbitrum поддерживают очередь Queue на L1 для управления транзакциями L2, которые пользователи отправляют с L1, или сообщениями для L2. Arbitrum называет это DelayedInbox; zkSync называет это PriorityQueue.

Но способ отправки транзакций L2 в zkSync более похож на Optimism, обе используют адрес L2 для отправки сообщений на L1, так что после преобразования в транзакцию L2 инициатором станет этот адрес L2. Функция отправки транзакций L2 в Optimism называется depositTransaction; в zkSync — requestL2Transaction. Arbitrum же генерирует полную транзакцию L2 и подписывает ее, а затем отправляет через функцию sendL2Message, при этом Arbitrum восстанавливает подписавшего через подпись, чтобы определить инициатора транзакции L2.

В StarkNet в настоящее время нет механизма Force Inclusion; zkSync же реализует лишь частичный механизм Force Inclusion, — у него есть PriorityQueue, и каждая транзакция L2 в очереди имеет срок действия для включения, но этот срок действия в настоящее время является лишь декоративным, на самом деле Sequencer может выбрать не включать никакие транзакции из PriorityQueue.