В этой статье в основном рассказывается о разработке и соответствующем содержимом абстрактных учетных записей (AA, абстрактных учетных записей) в решении уровня 2 zkSync. Основное внимание будет уделено трем частям:
Контракт учетной записи: тип учетной записи, важная точка входа и соответствующие ключевые моменты контракта учетной записи.
Транзакция: метод проверки, метод выполнения и процесс транзакции AA.
Плата за обработку: комиссия за транзакцию, Paymaster
Оглавление
предисловие
Краткий обзор контракта zkSync AA.
Модель комиссий и Paymaster в эпоху zkSync
Резюме и сравнение
Заключение
фон
Знакомство с кошельком смарт-контрактов и его общими функциями.
Получите обзор того, как работают транзакции Ethereum.
Общее представление о режиме работы EIP-4337.
Общее представление о режиме работы ЗК (срок действия) Rollup
Быстрый просмотр zkSync
Здесь для удобства чтения не обязательно глубоко разбираться в zkSync, а кратко рассмотреть основную информацию о zkSync. Существует две основные версии zkSync: версия 1.0 (zkSync Lite) и версия 2.0 (zkSync Era).
zkSync версии 1.0 поддерживает только EOA (внешнюю учетную запись) и не поддерживает смарт-контракты (поддерживает только передачу и обмен токенов), тогда как zkSync 2.0, а именно zkSync Era, принадлежит собственной AA (абстрактной учетной записи) (все типы учетных записей являются контрактами, без EOA). , в чем разница между EOA и контрактной учетной записью в Ethereum), совместим с EVM (виртуальной машиной Ethereum) и поддерживает разработку смарт-контрактов с использованием Rust, Yul, Vyper, Solidity и т. д.
Упомянутый ниже zkSync относится к zkSync 2.0, а именно к zkSync Era, если не указано иное.
В эпоху zkSync существует множество контрактов, которые можно понимать как реализацию некоторых важных функций операционной системы zkSync в смарт-контрактах. Эти контракты представляют собой предварительно скомпилированные контракты, которые никогда не были развернуты (запускаются непосредственно на узле), но все они имеют формальный адрес.
При реализации протокола AA zkSync будет выполнять логические операции и оценки посредством некоторых контрактов. Например, при проверке nonce он оценивается NonceHolder, а реализация механизма абстрактной учетной записи и сбор комиссий оценивается загрузчиком. Ниже будет представлено их один за другим.
Обзор абстракции аккаунта
Основную концепцию абстракции счета можно свести к двум ключевым моментам: абстракция подписи и абстракция платежа.
Цель абстракции подписи — дать возможность различным контрактам учетных записей использовать разные схемы проверки. Это означает, что пользователи не ограничены алгоритмом цифровой подписи, который может использовать только определенную кривую, но могут выбрать любой механизм проверки, который им нравится.
Абстракция платежа направлена на предоставление пользователям различных вариантов оплаты транзакций. Например, платежи могут осуществляться с использованием токенов ERC-20 вместо собственных токенов, или транзакции могут спонсироваться третьей стороной, или даже использовать другие, более специальные модели оплаты.
Учетные записи в zkSync 2.0 могут инициировать транзакции, такие как EOA, но также могут использовать свои программируемые возможности для реализации произвольной логики, например, для контрактных учетных записей. Это то, что мы называем абстракцией учетных записей, которая сочетает в себе преимущества двух типов учетных записей в Ethereum, чтобы сделать опыт использования учетных записей AA более гибким, тем самым достигая двух вышеуказанных целей: абстракции подписей и абстракции платежей.
Механизм АА в эпоху zkSync
В эпоху zkSync наиболее важной ролью zkSync AA является загрузчик, который представляет собой контракт, в основном используемый для обработки транзакций и выполнения механизма AA, соответствующего контракту EntryPoint в EIP-4337. Загрузчик не может быть вызван пользователем (он может быть запущен только Оператором), и он никогда не был развернут (запускается непосредственно на ноде), но имеет официальный адрес (может использоваться для приема платежей).
Оператор играет важную роль в ZK Rollup. Это централизованный сервер вне цепочки. Подобно секвенсору, который вы, возможно, видели, он отвечает за запуск контрактов, таких как загрузчик, извне.
Собственные протоколы абстракции учетной записи (такие как StarkNet, zkSync) в основном разработаны со ссылкой на EIP-4337. При реализации zkSync пользователь отправляет транзакцию оператору, а оператор отправляет транзакцию загрузчику и запускает серия обработки.
С точки зрения блока:
Когда загрузчик получает входные данные от оператора, он сначала определяет некоторые переменные среды для блока (например, цену на газ, номер блока, временную метку блока и т. д.). Затем загрузчик последовательно прочитает список транзакций, сначала запросит, согласуется ли контракт учетной записи с транзакцией (то есть вызовет функцию проверки в механизме AA), а затем поместит их в блок.
После проверки каждой транзакции Оператор проверяет, достаточно ли велик блок для отправки верификатору (или истекло ли время ожидания). Если он достаточно велик или истекло время ожидания, Оператор закрывает блок, прекращает добавление новых транзакций в загрузчик и завершает выполнение транзакции.
С точки зрения транзакций, когда Оператор запускает загрузчик, загрузчик будет обрабатывать каждую транзакцию последовательно:
Подтвердите, является ли одноразовый номер, соответствующий контрактному адресу учетной записи пользователя, законным.
Вызовите функцию проверки контракта учетной записи пользователя для проверки.
После прохождения проверки контракт аккаунта переведет комиссию за газ на адрес загрузчика (или через Paymaster, что будет введено позже), а загрузчик проверит, получил ли он достаточно денег.
Вызовите функцию ute в контракте учетной записи пользователя, чтобы выполнить транзакцию.
Первые три шага, описанные выше, соответствуют циклу проверки (цикл проверки) EIP-4337, а четвертый шаг соответствует циклу выполнения (цикл выполнения) EIP-4337.
В основном это обзорное введение, а детали и роли каждого шага будут подробно описаны один за другим в следующем подробном описании.
Nonce учетной записи zkSync записывается в системный контракт с именем NonceHolder, который запоминает, используется ли каждая пара (account_address, nonce) путем сопоставления (отображения) для определения того, является ли nonce допустимым.
Согласно вышеизложенному, первым шагом после того, как Оператор запускает загрузчик, является проверка nonce. Таким образом, перед началом каждой транзакции NonceHolder будет использоваться для подтверждения того, является ли текущий используемый набор одноразовых номеров допустимым (в настоящее время проверяется только то, использовались ли они). Если nonce является законным, он перейдет в фазу проверки (Verification Phase), после чего nonce будет помечен как использованный; если он не является законным, транзакция (проверка) завершится неудачей.
Важные моменты о текущем одноразовом номере zkSync:
Хотя в настоящее время пользователи могут отправлять несколько транзакций с разными одноразовыми номерами в учетную запись для выполнения одновременно, поскольку zkSync не поддерживает параллельную обработку, транзакции с разными одноразовыми номерами все равно будут обрабатываться последовательно.
Теоретически пользователи могут использовать любое 256-битное ненулевое целое число в качестве nonce, но zkSync по-прежнему рекомендует использовать инкрементNonceIfEquals как способ управления одноразовым номером, чтобы гарантировать, что он увеличивается по порядку (в настоящее время механизм AA zkSync только подтверждает неиспользованный одноразовый номер, но официальный документ указывает, что последовательное приращение может потребоваться в будущем).
Контракт на аккаунт
Контракт учетной записи в zkSync имеет следующие четыре необходимые точки входа (Entry Point), а именно:
validateTransaction: вызывается на этапе проверки, чтобы подтвердить, разрешена ли операция владельцем учетной записи, где пользователи могут настроить свою собственную логику проверки (например, различные алгоритмы подписи, мультиподпись и т. д.).
payForTransaction: Когда комиссия за транзакцию оплачивается с этого счета (вместо использования paymaster), оператор вызовет эту функцию для выплаты как минимум tx.gasprice * tx.gaslimit ETH на адрес загрузчика.
ПодготовкаForPaymaster: Когда комиссия за транзакцию будет оплачена Paymaster, оператор вызовет эту функцию для завершения подготовительных работ перед взаимодействием с Paymaster. Пример, предоставленный zkSync, представляет собой токен ERC-20, одобренный Paymaster.
uteTransaction: после успешного прохождения этапа проверки и успешного взимания комиссии за транзакцию эта функция будет использоваться для выполнения операции, которую хочет выполнить пользователь (например, взаимодействие с контрактом, денежный перевод и т. д.).
Что касается Paymaster, размер комиссии за обработку (tx.gasprice * tx.gaslimit) и т. д. будет объяснен в последующих главах.
Также в аккаунте zkSync есть необязательная страховая функция uteTransactionFromOutside. Средства можно вывести на L1 с использованием «механизма выхода», когда операции не могут быть выполнены (например, когда генератор последовательностей не отвечает или zkSync признан регуляторным риском). Эта часть имеет мало общего с протоколом АА, поэтому подробно описываться здесь не будет, желающие могут ознакомиться с официальными документами и спецификацией zkSync.
Ключевые моменты и ограничения функций проверки
В функции validateTransaction можно реализовать различные пользовательские логики. Например, если в учетной записи реализован стандарт EIP-1271, логику проверки в EIP-1271 можно напрямую применить к validateTransaction или обратиться к контракту учетной записи с несколькими подписями. реализация в официальном документе zkSync.
В то же время, чтобы избежать DoS-угроз на этапе верификации EIP-4337, существуют некоторые ограничения (невозможно использовать внешние коды операций, ограничена глубина и т. д.), и аналогичные ограничения есть в zkSync, например:
1. Логика контракта может касаться только своего слота (если адрес контракта аккаунта равен A):
слот, принадлежащий адресу A
слот А по любому другому адресу
Слот keccak256(A||X) любого другого адреса, который может напрямую использовать адрес в качестве ключа сопоставления (например, сопоставление (адрес=>значение)), также эквивалентен разрешению доступа к слоту keccak256( A||X), чтобы добиться расширения. Например, балансы токенов на ERC-20.
2. Логика контракта не должна использовать глобальные переменные, такие как блок.номер.
Ключевые моменты и ограничения выполнения функций
Что необходимо отметить в функции uteTransaction, так это то, что если вы хотите выполнить системный вызов (Call), вам необходимо убедиться, что у нее есть флаг is. Поскольку эти системные контракты оказывают большое влияние на систему учетных записей. Например, единственный способ увеличить значение nonce — это взаимодействовать с NonceHolder. Чтобы развернуть контракт, необходимо взаимодействовать с ContractDeployer. Использование флага is может гарантировать, что разработчики учетных записей будут сознательно взаимодействовать с системными контрактами.
Однако рекомендуется использовать библиотеку ContractsCaller, предоставляемую zkSync, чтобы избежать самостоятельной обработки флага is, и использовать CallWithPropagatedRevert для завершения системного вызова.
Приведенный выше пример кода включает взаимодействие с DEPLOYER__CONTRACT. Наиболее распространенная ситуация с системным контрактом, с которой сталкиваются разработчики учетных записей, заключается в том, что мы хотим использовать учетную запись для развертывания контракта. На данный момент мы должны взаимодействовать с системным контрактом ContractDeployer. В этом случае разработчику учетной записи необходимо связаться с контрактом ContractDeployer, чтобы убедиться, что контракт успешно развернут и выполняет необходимые операции.
Модель комиссий и Paymaster в эпоху zkSync
Сборы и лимит газа
Модель комиссий zkSync очень похожа на Ethereum, токеном комиссии по-прежнему является ETH. Однако, как и другие решения уровня 2 (такие как Arbitrum, Optimism), zkSync также необходимо учитывать дополнительные затраты на публикацию на уровне L1 (плату за безопасность) в дополнение к базовым расчетам и затратам на слоты записи. Поскольку цена газа, публикующего данные в L1, очень нестабильна, Оператор zkSync определяет следующие динамические параметры при открытии каждого блока (начинает записывать транзакции):
gasPrice: цена на газ в gwei, то есть tx.gasprice в объекте транзакции, упомянутом выше.
gasPerPubdata: количество газа, необходимое для публикации байта данных в Ethereum.
Кроме того, в отличие от EIP-4337, zkSync не требует определения трех пределов газа:verificationGas, utionGas и preVerificationGas, а требует только gasLimit для покрытия всех вышеперечисленных затрат, поэтому пользователям необходимо убедиться, что gasLimit достаточен для покрытия Этап проверки, этап настройки и загрузка данных. Все расходы, такие как плата за безопасность, для L1. Стоимость этой комиссии включена в tx.gaslimit в объекте транзакции, упомянутом выше.
Умножьте эти два значения (tx.gasprice * tx.gaslimit), чтобы получить комиссию за транзакцию, выплачиваемую загрузчику.
Казначей
Paymaster в основном выплачивает ETH загрузчику вместо контракта учетной записи пользователя на этапе оплаты комиссии за транзакцию пользователя. Пользователи могут выбирать различные Paymaster и способы оплаты для оплаты комиссии за обработку, например (но не ограничиваясь):
Выплата токенов ERC-20 Paymaster до начала транзакции или после ее выполнения.
Пополните контракт Paymaster с помощью кредитной карты.
Paymaster продолжит оплачивать часть или все комиссии пользователей бесплатно.
Способ взаимодействия пользователей с Paymaster зависит от разных протоколов: он может быть централизованным или децентрализованным, может происходить до или после транзакции, может использовать токены ERC-20 или законное платежное средство или даже быть бесплатным.
Контракт Paymaster zkSync в основном состоит из двух функций, а именно validateAndPayForPaymasterTransaction (обязательно) и postTransaction (необязательно), обе из которых могут быть вызваны только загрузчиком:
— validateAndPayForPaymasterTransaction — единственная функция, которая должна быть реализована во всем контракте Paymaster. Когда оператор получает транзакцию с параметром Paymaster, это означает, что комиссия за обработку оплачивается не договором счета пользователя, а Paymaster. На этом этапе оператор вызовет validateAndPayForPaymasterTransaction, чтобы определить, готов ли Paymaster оплатить комиссию за транзакцию. Если Paymaster согласится, эта функция отправит загрузчику как минимум tx.gasprice* tx.gaslimit ETH.
— postTransaction — дополнительная функция, обычно используемая для возврата денег (возврата неиспользованного газа отправителю). Однако текущий zkSync пока не поддерживает эту операцию.
Paymaster в zkSync выполнит postTransaction после реализации postTransaction, что отличается от EIP-4337. EIP-4337 не будет вызывать postOp, если validatePaymasterUserOp не возвращает контекст, и наоборот.
Например, на основании вышеизложенного пользователь теперь хочет отправить транзакцию, комиссия за обработку которой оплачивается Paymaster, процесс выглядит следующим образом:
Используйте NonceHolder, чтобы подтвердить, является ли одноразовый номер законным.
Вызовите validateTransaction в контракте учетной записи пользователя, чтобы убедиться, что транзакция авторизована владельцем учетной записи.
Вызов подготовитьForPaymaster в Контракте учетной записи пользователя, который может выполнить, например, утвердить определенное количество токенов ERC-20 для Paymaster или ничего не делать.
Вызовите validateAndPayForPaymasterTransaction в контракте Paymaster, чтобы подтвердить, что Paymaster готов оплатить и взимать комиссию за обработку, и в то же время Paymaster взимает с пользователя определенную сумму ERC-20 (утвержденную ранее).
Подтвердите, что загрузчик получает правильную сумму (не менее tx.gasprice * tx.gaslimit) комиссий ETH.
Вызовите uteTransaction в контракте учетной записи пользователя, чтобы выполнить транзакцию, которую хочет пользователь.
Если Контракт Paymaster реализует postTransaction и газа все еще достаточно (нет ошибки отсутствия газа), выполните postTransaction.
На последнем этапе, даже если postTransaction не может быть выполнен из-за ошибки отсутствия газа, эта транзакция AA считается успешной, но действие вызова postTransaction опускается.
Если вы углубитесь в Paymaster zkSync, вы обнаружите, что его правила проверки немного отличаются от 4337 (zkSync Paymaster может вступить в любой другой слот контракта), а также существуют различные типы (например, на основе одобрения). к сравнению деталей.Кому интересно могут обратиться к официальным документам или моей предыдущей реализации.
Сводка и сравнение
Из предыдущих объяснений мы узнали, какие важные точки входа имеет контракт учетной записи, а также их функции и связанные с ними ограничения. Заодно мы также узнали о функциях системного контракта. Далее подведем итог процесса транзакции автоматизированной операции (АА) в zkSync от построения до завершения, а также предоставим более подробные ссылки для тех, кто хочет узнать больше:
Пользователь использует SDK или кошелек локально для создания объектов транзакции (например: от, к, данные, стоимость и т. д.).
Пользователь подписывает транзакцию. Подпись здесь не обязательно представляет собой традиционный формат EIP-712 и кривую подпись ECDSA. zkSync также поддерживает EIP-2718 и EIP-1559. Ключом к выбору метода подписи и метода проверки является проверка с помощью функции проверки в контракте учетной записи.
Отправьте подписанную транзакцию оператору через RPC API. В этот момент транзакция переходит в состояние ожидания. Оператор передает транзакцию загрузчику (вызывает функциюprocessL2Tx в контракте загрузчика) и запускает серию процессов протокола AA.
Загрузчик проверит, является ли Nonce допустимым, и использует NonceHolder для проверки.
Загрузчик вызовет функцию validateTransaction в контракте учетной записи пользователя, чтобы подтвердить, что транзакция была авторизована владельцем учетной записи.
Bootloader может взимать комиссию двумя способами, и конкретный метод взимания комиссии зависит от параметров транзакции (прикрепляется ли параметр paymaster при построении объекта транзакции):
а. Вызовите функцию payForTransaction и контракт счета, чтобы взимать комиссию за транзакцию;
б) Вызовите функции подготовитьForPaymaster и validateAndPayForPaymasterTransaction, чтобы получить комиссию за транзакцию по контракту Paymaster.
«Вызовите payForTransaction, чтобы заключить договор о комиссии с учетной записью» или «вызовите методprepreForPaymaster и validateAndPayForPaymasterTransaction, чтобы заключить договор о комиссии с Paymaster».
Проверьте, получил ли загрузчик хотя бы комиссию за транзакцию tx.gasprice*tx.gaslimit.
Загрузчик вызовет функцию uteTransaction контракта учетной записи пользователя для выполнения транзакции.
(Необязательно) Если для оплаты комиссии за транзакцию используется Paymaster, загрузчик вызовет функцию postTransaction. Если Paymaster не реализует postTransaction или газ исчерпан, этот шаг будет пропущен.
Вышеуказанные шаги 4.~7. являются этапом проверки (определенным в l2TxValidation загрузчика) и этапом выполнения 8.~9.(определенным в l2Txution загрузчика).
Сравнение EIP-4337, StarkNet и эпохи zkSync
По сути, процессы механизма AA в этих трех случаях аналогичны: все они представляют собой этап проверки → механизм комиссии за обработку (оплачивается контрактом на счет или Paymaster) → этап исполнения. Основные различия заключаются в следующем:
Роль реализации механизма AA такова: разница между открытием в эпоху zkSync и двумя другими AA заключается в том, что Оператору необходимо сотрудничать с загрузчиком (системный контракт), например, загрузчик откроет новый блок и определит соответствующие параметры блока и получить операцию, отправленную участником и проверенную трейдером. В 4337 эту часть координируют Bundler и EntryPoint, а в StarkNet за эту часть отвечает Sequencer.
Должна ли стоимость газа учитывать плату за безопасность L1: L2 AA должна учитывать стоимость загрузки данных в L1, а не только ZK (действительность) Rollups Native AA, упомянутую в push-уведомлении, но также должна быть включена в L1 при оптимистическом сценарии. В накопительных пакетах взимается плата за безопасность в размере 4337 (рассчитывается в preVerificationGas, подробности см. в документах, связанных с алхимией).
Можно ли отправлять транзакции до развертывания контракта учетной записи: в эпоху StarkNet и zkSync не существует точки входа, такой как 4337, которая имеет поле initCode, позволяющее пользователю развертывать контракт учетной записи, поэтому она не отправляет транзакции. прежде чем учетную запись можно будет настроить.
В сравнении
Поскольку StarkNet еще не реализовал механизм Paymaster, а zkSync еще не завершил разработку механизма возврата газа, некоторые более подробные сравнения здесь не приводятся.
Кроме того, мы завершили создание мемпула P2P для текущего бандлера 4337, а Sequencer и Оператор zkRollups также являются единственными официальными серверами, поэтому существуют определенные централизованные компоненты.
В процессе разработки, поскольку у zkSync нет проблем с подключением к различным бандлерам (нужно только взаимодействовать с API оператора), легко использовать 4337, да и опыт разработки контрактов учетных записей (SDK) тоже лучше; в то же время zkSync может использовать Solidity в качестве контрактного языка разработки, поэтому нет необходимости переступать порог Cairo в разработке StarkNet.
Заключение
Поскольку и StarkNet, и zkSync относятся к категории локальных AA (Native AA), вы также можете обратиться к моему предыдущему введению в StarkNet AA под названием «Введение в абстракцию учетной записи StarkNet» (Введение в абстракцию учетной записи StarkNet). Кроме того, вы можете прочитать другие статьи, связанные с EIP-4337, для получения дополнительной информации.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Введение в собственную абстракцию учетной записи в zkSync
Автор: Автор ChiHaoLu, imToken Labs
В этой статье в основном рассказывается о разработке и соответствующем содержимом абстрактных учетных записей (AA, абстрактных учетных записей) в решении уровня 2 zkSync. Основное внимание будет уделено трем частям:
Оглавление
фон
Здесь для удобства чтения не обязательно глубоко разбираться в zkSync, а кратко рассмотреть основную информацию о zkSync. Существует две основные версии zkSync: версия 1.0 (zkSync Lite) и версия 2.0 (zkSync Era).
zkSync версии 1.0 поддерживает только EOA (внешнюю учетную запись) и не поддерживает смарт-контракты (поддерживает только передачу и обмен токенов), тогда как zkSync 2.0, а именно zkSync Era, принадлежит собственной AA (абстрактной учетной записи) (все типы учетных записей являются контрактами, без EOA). , в чем разница между EOA и контрактной учетной записью в Ethereum), совместим с EVM (виртуальной машиной Ethereum) и поддерживает разработку смарт-контрактов с использованием Rust, Yul, Vyper, Solidity и т. д.
Упомянутый ниже zkSync относится к zkSync 2.0, а именно к zkSync Era, если не указано иное.
В эпоху zkSync существует множество контрактов, которые можно понимать как реализацию некоторых важных функций операционной системы zkSync в смарт-контрактах. Эти контракты представляют собой предварительно скомпилированные контракты, которые никогда не были развернуты (запускаются непосредственно на узле), но все они имеют формальный адрес.
При реализации протокола AA zkSync будет выполнять логические операции и оценки посредством некоторых контрактов. Например, при проверке nonce он оценивается NonceHolder, а реализация механизма абстрактной учетной записи и сбор комиссий оценивается загрузчиком. Ниже будет представлено их один за другим.
Обзор абстракции аккаунта
Основную концепцию абстракции счета можно свести к двум ключевым моментам: абстракция подписи и абстракция платежа.
Цель абстракции подписи — дать возможность различным контрактам учетных записей использовать разные схемы проверки. Это означает, что пользователи не ограничены алгоритмом цифровой подписи, который может использовать только определенную кривую, но могут выбрать любой механизм проверки, который им нравится.
Абстракция платежа направлена на предоставление пользователям различных вариантов оплаты транзакций. Например, платежи могут осуществляться с использованием токенов ERC-20 вместо собственных токенов, или транзакции могут спонсироваться третьей стороной, или даже использовать другие, более специальные модели оплаты.
Учетные записи в zkSync 2.0 могут инициировать транзакции, такие как EOA, но также могут использовать свои программируемые возможности для реализации произвольной логики, например, для контрактных учетных записей. Это то, что мы называем абстракцией учетных записей, которая сочетает в себе преимущества двух типов учетных записей в Ethereum, чтобы сделать опыт использования учетных записей AA более гибким, тем самым достигая двух вышеуказанных целей: абстракции подписей и абстракции платежей.
Механизм АА в эпоху zkSync
В эпоху zkSync наиболее важной ролью zkSync AA является загрузчик, который представляет собой контракт, в основном используемый для обработки транзакций и выполнения механизма AA, соответствующего контракту EntryPoint в EIP-4337. Загрузчик не может быть вызван пользователем (он может быть запущен только Оператором), и он никогда не был развернут (запускается непосредственно на ноде), но имеет официальный адрес (может использоваться для приема платежей).
Оператор играет важную роль в ZK Rollup. Это централизованный сервер вне цепочки. Подобно секвенсору, который вы, возможно, видели, он отвечает за запуск контрактов, таких как загрузчик, извне.
Собственные протоколы абстракции учетной записи (такие как StarkNet, zkSync) в основном разработаны со ссылкой на EIP-4337. При реализации zkSync пользователь отправляет транзакцию оператору, а оператор отправляет транзакцию загрузчику и запускает серия обработки.
С точки зрения блока:
Когда загрузчик получает входные данные от оператора, он сначала определяет некоторые переменные среды для блока (например, цену на газ, номер блока, временную метку блока и т. д.). Затем загрузчик последовательно прочитает список транзакций, сначала запросит, согласуется ли контракт учетной записи с транзакцией (то есть вызовет функцию проверки в механизме AA), а затем поместит их в блок.
После проверки каждой транзакции Оператор проверяет, достаточно ли велик блок для отправки верификатору (или истекло ли время ожидания). Если он достаточно велик или истекло время ожидания, Оператор закрывает блок, прекращает добавление новых транзакций в загрузчик и завершает выполнение транзакции.
С точки зрения транзакций, когда Оператор запускает загрузчик, загрузчик будет обрабатывать каждую транзакцию последовательно:
Первые три шага, описанные выше, соответствуют циклу проверки (цикл проверки) EIP-4337, а четвертый шаг соответствует циклу выполнения (цикл выполнения) EIP-4337.
В основном это обзорное введение, а детали и роли каждого шага будут подробно описаны один за другим в следующем подробном описании.
Краткий обзор контракта абстрактного аккаунта zkSync
Нонс
Nonce учетной записи zkSync записывается в системный контракт с именем NonceHolder, который запоминает, используется ли каждая пара (account_address, nonce) путем сопоставления (отображения) для определения того, является ли nonce допустимым.
Согласно вышеизложенному, первым шагом после того, как Оператор запускает загрузчик, является проверка nonce. Таким образом, перед началом каждой транзакции NonceHolder будет использоваться для подтверждения того, является ли текущий используемый набор одноразовых номеров допустимым (в настоящее время проверяется только то, использовались ли они). Если nonce является законным, он перейдет в фазу проверки (Verification Phase), после чего nonce будет помечен как использованный; если он не является законным, транзакция (проверка) завершится неудачей.
Важные моменты о текущем одноразовом номере zkSync:
Хотя в настоящее время пользователи могут отправлять несколько транзакций с разными одноразовыми номерами в учетную запись для выполнения одновременно, поскольку zkSync не поддерживает параллельную обработку, транзакции с разными одноразовыми номерами все равно будут обрабатываться последовательно.
Теоретически пользователи могут использовать любое 256-битное ненулевое целое число в качестве nonce, но zkSync по-прежнему рекомендует использовать инкрементNonceIfEquals как способ управления одноразовым номером, чтобы гарантировать, что он увеличивается по порядку (в настоящее время механизм AA zkSync только подтверждает неиспользованный одноразовый номер, но официальный документ указывает, что последовательное приращение может потребоваться в будущем).
Контракт на аккаунт
Контракт учетной записи в zkSync имеет следующие четыре необходимые точки входа (Entry Point), а именно:
Что касается Paymaster, размер комиссии за обработку (tx.gasprice * tx.gaslimit) и т. д. будет объяснен в последующих главах.
Также в аккаунте zkSync есть необязательная страховая функция uteTransactionFromOutside. Средства можно вывести на L1 с использованием «механизма выхода», когда операции не могут быть выполнены (например, когда генератор последовательностей не отвечает или zkSync признан регуляторным риском). Эта часть имеет мало общего с протоколом АА, поэтому подробно описываться здесь не будет, желающие могут ознакомиться с официальными документами и спецификацией zkSync.
Ключевые моменты и ограничения функций проверки
В функции validateTransaction можно реализовать различные пользовательские логики. Например, если в учетной записи реализован стандарт EIP-1271, логику проверки в EIP-1271 можно напрямую применить к validateTransaction или обратиться к контракту учетной записи с несколькими подписями. реализация в официальном документе zkSync.
В то же время, чтобы избежать DoS-угроз на этапе верификации EIP-4337, существуют некоторые ограничения (невозможно использовать внешние коды операций, ограничена глубина и т. д.), и аналогичные ограничения есть в zkSync, например:
1. Логика контракта может касаться только своего слота (если адрес контракта аккаунта равен A):
слот, принадлежащий адресу A
слот А по любому другому адресу
Слот keccak256(A||X) любого другого адреса, который может напрямую использовать адрес в качестве ключа сопоставления (например, сопоставление (адрес=>значение)), также эквивалентен разрешению доступа к слоту keccak256( A||X), чтобы добиться расширения. Например, балансы токенов на ERC-20.
2. Логика контракта не должна использовать глобальные переменные, такие как блок.номер.
Ключевые моменты и ограничения выполнения функций
Что необходимо отметить в функции uteTransaction, так это то, что если вы хотите выполнить системный вызов (Call), вам необходимо убедиться, что у нее есть флаг is. Поскольку эти системные контракты оказывают большое влияние на систему учетных записей. Например, единственный способ увеличить значение nonce — это взаимодействовать с NonceHolder. Чтобы развернуть контракт, необходимо взаимодействовать с ContractDeployer. Использование флага is может гарантировать, что разработчики учетных записей будут сознательно взаимодействовать с системными контрактами.
Однако рекомендуется использовать библиотеку ContractsCaller, предоставляемую zkSync, чтобы избежать самостоятельной обработки флага is, и использовать CallWithPropagatedRevert для завершения системного вызова.
Приведенный выше пример кода включает взаимодействие с DEPLOYER__CONTRACT. Наиболее распространенная ситуация с системным контрактом, с которой сталкиваются разработчики учетных записей, заключается в том, что мы хотим использовать учетную запись для развертывания контракта. На данный момент мы должны взаимодействовать с системным контрактом ContractDeployer. В этом случае разработчику учетной записи необходимо связаться с контрактом ContractDeployer, чтобы убедиться, что контракт успешно развернут и выполняет необходимые операции.
Модель комиссий и Paymaster в эпоху zkSync
Сборы и лимит газа
Модель комиссий zkSync очень похожа на Ethereum, токеном комиссии по-прежнему является ETH. Однако, как и другие решения уровня 2 (такие как Arbitrum, Optimism), zkSync также необходимо учитывать дополнительные затраты на публикацию на уровне L1 (плату за безопасность) в дополнение к базовым расчетам и затратам на слоты записи. Поскольку цена газа, публикующего данные в L1, очень нестабильна, Оператор zkSync определяет следующие динамические параметры при открытии каждого блока (начинает записывать транзакции):
gasPrice: цена на газ в gwei, то есть tx.gasprice в объекте транзакции, упомянутом выше.
gasPerPubdata: количество газа, необходимое для публикации байта данных в Ethereum.
Кроме того, в отличие от EIP-4337, zkSync не требует определения трех пределов газа:verificationGas, utionGas и preVerificationGas, а требует только gasLimit для покрытия всех вышеперечисленных затрат, поэтому пользователям необходимо убедиться, что gasLimit достаточен для покрытия Этап проверки, этап настройки и загрузка данных. Все расходы, такие как плата за безопасность, для L1. Стоимость этой комиссии включена в tx.gaslimit в объекте транзакции, упомянутом выше.
Умножьте эти два значения (tx.gasprice * tx.gaslimit), чтобы получить комиссию за транзакцию, выплачиваемую загрузчику.
Казначей
Paymaster в основном выплачивает ETH загрузчику вместо контракта учетной записи пользователя на этапе оплаты комиссии за транзакцию пользователя. Пользователи могут выбирать различные Paymaster и способы оплаты для оплаты комиссии за обработку, например (но не ограничиваясь):
Выплата токенов ERC-20 Paymaster до начала транзакции или после ее выполнения.
Пополните контракт Paymaster с помощью кредитной карты.
Paymaster продолжит оплачивать часть или все комиссии пользователей бесплатно.
Способ взаимодействия пользователей с Paymaster зависит от разных протоколов: он может быть централизованным или децентрализованным, может происходить до или после транзакции, может использовать токены ERC-20 или законное платежное средство или даже быть бесплатным.
Контракт Paymaster zkSync в основном состоит из двух функций, а именно validateAndPayForPaymasterTransaction (обязательно) и postTransaction (необязательно), обе из которых могут быть вызваны только загрузчиком:
— validateAndPayForPaymasterTransaction — единственная функция, которая должна быть реализована во всем контракте Paymaster. Когда оператор получает транзакцию с параметром Paymaster, это означает, что комиссия за обработку оплачивается не договором счета пользователя, а Paymaster. На этом этапе оператор вызовет validateAndPayForPaymasterTransaction, чтобы определить, готов ли Paymaster оплатить комиссию за транзакцию. Если Paymaster согласится, эта функция отправит загрузчику как минимум tx.gasprice* tx.gaslimit ETH.
— postTransaction — дополнительная функция, обычно используемая для возврата денег (возврата неиспользованного газа отправителю). Однако текущий zkSync пока не поддерживает эту операцию.
Paymaster в zkSync выполнит postTransaction после реализации postTransaction, что отличается от EIP-4337. EIP-4337 не будет вызывать postOp, если validatePaymasterUserOp не возвращает контекст, и наоборот.
Например, на основании вышеизложенного пользователь теперь хочет отправить транзакцию, комиссия за обработку которой оплачивается Paymaster, процесс выглядит следующим образом:
На последнем этапе, даже если postTransaction не может быть выполнен из-за ошибки отсутствия газа, эта транзакция AA считается успешной, но действие вызова postTransaction опускается.
Если вы углубитесь в Paymaster zkSync, вы обнаружите, что его правила проверки немного отличаются от 4337 (zkSync Paymaster может вступить в любой другой слот контракта), а также существуют различные типы (например, на основе одобрения). к сравнению деталей.Кому интересно могут обратиться к официальным документам или моей предыдущей реализации.
Сводка и сравнение
Из предыдущих объяснений мы узнали, какие важные точки входа имеет контракт учетной записи, а также их функции и связанные с ними ограничения. Заодно мы также узнали о функциях системного контракта. Далее подведем итог процесса транзакции автоматизированной операции (АА) в zkSync от построения до завершения, а также предоставим более подробные ссылки для тех, кто хочет узнать больше:
Пользователь использует SDK или кошелек локально для создания объектов транзакции (например: от, к, данные, стоимость и т. д.).
Пользователь подписывает транзакцию. Подпись здесь не обязательно представляет собой традиционный формат EIP-712 и кривую подпись ECDSA. zkSync также поддерживает EIP-2718 и EIP-1559. Ключом к выбору метода подписи и метода проверки является проверка с помощью функции проверки в контракте учетной записи.
Отправьте подписанную транзакцию оператору через RPC API. В этот момент транзакция переходит в состояние ожидания. Оператор передает транзакцию загрузчику (вызывает функциюprocessL2Tx в контракте загрузчика) и запускает серию процессов протокола AA.
Загрузчик проверит, является ли Nonce допустимым, и использует NonceHolder для проверки.
Загрузчик вызовет функцию validateTransaction в контракте учетной записи пользователя, чтобы подтвердить, что транзакция была авторизована владельцем учетной записи.
Bootloader может взимать комиссию двумя способами, и конкретный метод взимания комиссии зависит от параметров транзакции (прикрепляется ли параметр paymaster при построении объекта транзакции):
а. Вызовите функцию payForTransaction и контракт счета, чтобы взимать комиссию за транзакцию;
б) Вызовите функции подготовитьForPaymaster и validateAndPayForPaymasterTransaction, чтобы получить комиссию за транзакцию по контракту Paymaster.
«Вызовите payForTransaction, чтобы заключить договор о комиссии с учетной записью» или «вызовите методprepreForPaymaster и validateAndPayForPaymasterTransaction, чтобы заключить договор о комиссии с Paymaster».
Проверьте, получил ли загрузчик хотя бы комиссию за транзакцию tx.gasprice*tx.gaslimit.
Загрузчик вызовет функцию uteTransaction контракта учетной записи пользователя для выполнения транзакции.
(Необязательно) Если для оплаты комиссии за транзакцию используется Paymaster, загрузчик вызовет функцию postTransaction. Если Paymaster не реализует postTransaction или газ исчерпан, этот шаг будет пропущен.
Вышеуказанные шаги 4.~7. являются этапом проверки (определенным в l2TxValidation загрузчика) и этапом выполнения 8.~9.(определенным в l2Txution загрузчика).
Сравнение EIP-4337, StarkNet и эпохи zkSync
По сути, процессы механизма AA в этих трех случаях аналогичны: все они представляют собой этап проверки → механизм комиссии за обработку (оплачивается контрактом на счет или Paymaster) → этап исполнения. Основные различия заключаются в следующем:
В сравнении
Кроме того, мы завершили создание мемпула P2P для текущего бандлера 4337, а Sequencer и Оператор zkRollups также являются единственными официальными серверами, поэтому существуют определенные централизованные компоненты.
В процессе разработки, поскольку у zkSync нет проблем с подключением к различным бандлерам (нужно только взаимодействовать с API оператора), легко использовать 4337, да и опыт разработки контрактов учетных записей (SDK) тоже лучше; в то же время zkSync может использовать Solidity в качестве контрактного языка разработки, поэтому нет необходимости переступать порог Cairo в разработке StarkNet.
Заключение
Поскольку и StarkNet, и zkSync относятся к категории локальных AA (Native AA), вы также можете обратиться к моему предыдущему введению в StarkNet AA под названием «Введение в абстракцию учетной записи StarkNet» (Введение в абстракцию учетной записи StarkNet). Кроме того, вы можете прочитать другие статьи, связанные с EIP-4337, для получения дополнительной информации.