Обзор решений мультичейн-абстракции аккаунта: нативная поддержка и совместимость с ERC-4337

Автор: Киви Яо, исследователь OKX Ventures

Решения мультичейн-абстракции аккаунта (AA) — это новый и инновационный способ взаимодействия с несколькими блокчейнами. Они позволяют создавать аккаунты и управлять ими в нескольких блокчейнах, не беспокоясь о технических деталях, таких как наличие достаточного количества нативных токенов для платы за газ. Это значительно упрощает начало работы с технологией блокчейн и одновременное использование нескольких блокчейнов. Существует два основных типа решений мультичейн-AA: нативная поддержка и совместимость с ERC-4337.

Нативная поддержка — это когда блокчейн непосредственно поддерживает мультичейн-AA. Совместимость с ERC-4337 — это когда блокчейн или L2-решение масштабирования использует смарт-контракт для реализации мультичейн-AA. В этой статье мы рассмотрим решения мультичейн-АА как с нативной поддержкой, так и с совместимостью с ERC-4337. Мы также обсудим преимущества и недостатки каждого подхода.

Сети, совместимые с абстракцией аккаунта ERC-4337.

Arbitrum

Сеть Arbitrum официально активировала конечные точки AA на Arbitrum One и Arbitrum Nova после принятия предложения AIP-2. В предложении представлена новая конечная точка RPC — eth_sendRawTransactionConditional — специально разработанная для упаковщиков ERC-4337.

Polygon

Polygon соответствует стандарту ERC-4337. Это стало возможным за счет использования таких решений, как Biconomy, Gas Station Network (GSN), Infura и Gelato для метатранзакций. Кроме того, zkEVM от Polygon поддерживает AA через ERC-4337, что позволяет оплачивать комиссии любым токеном.

Optimism

В настоящее время в mainnet OP доступны различные инфраструктуры AA через такие проекты, как Alchemy, Biconomy, CyberConnect, Pimlico и Stackup, хотя подробная информация об их архитектуре еще не опубликована.

BNB

В технической дорожной карте BNB Chain на 2023 год команда упоминает создание инфраструктуры AA. Совместимость с ERC-4337 также подтверждена. Более подробная информация будет опубликована в ближайшее время.

Нативная абстракция аккаунта

Starknet

Starknet изначально поддерживает AA, отображая все аккаунты как контрактные (CA) или смарт-аккаунты. Цели нативной поддержки AA включают абстракцию подписей и платежей. Они направлены на то, чтобы позволить различным контрактам в аккаунте использовать различные схемы проверки подписи и разные модели оплаты транзакций. Таким образом управление аккаунтом становится удобнее, поскольку у пользователей появляется больше возможностей проверки подписи и оплаты от третьей стороны или смарт-контракта.

Поток транзакций в Starknet

После выбора транзакции для добавления в блок секвенсор забирает ее и выполняет. Выполнение сделки происходит в два этапа. Сначала секвенсор отправляет запрос контрактному аккаунту подтвердить транзакцию, а затем выполнить ее. Эти два этапа закодированы в двух отдельных функциях контрактного аккаунта — проверка и выполнение.

Различие между этими этапами позволяет ОС Starknet гарантировать оплату секвенсору. Для предотвращения DOS-атак (отказ в обслуживании) на пул транзакций Starknet и наполнения его недействительными транзакциями Starknet требует от ноды, принимающей транзакцию, провести локальную симуляцию с известным состоянием. После этого сеть добавляет транзакцию в пул и передает ее другим нодам и секвенсорам. После завершения симуляции транзакция может быть добавлена в пул и распространена по сети.

Starknet transaction flow
An illustration outlining the flow of a Starknet transaction

Источник: StarkNet

Сравнение AA в Starknet и АА в ERC-4337

  • Starknet устраняет дополнительные сложности, связанные с упаковщиком, и назначает эту роль секвенсору. Это отличается от решения AA в ERC-4337, которое требует от упаковщиков выполнения пользовательских операций (user ops).

  • В отличие от решения AA в ERC-4337, Starknet не имеет протокола абстракции комиссий за транзакции, подобный казначею.

  • Starknet также не делает различий между обычными транзакциями и пользовательскими операциями, что упрощает процесс.

  • Одно заметное отличие заключается в развертывании. Starknet сначала развертывает контрактный аккаунт, прежде чем к нему можно начать обращаться. По сути, для создания нового контрактного аккаунта в Starknet требуется аккаунт с активами. Новый аккаунт создается путем запуска функции deploy_account. Этот развернутый контрактный аккаунт может оплачивать газ. Решение AA в ERC-4337, в свою очередь, не требует предварительного развертывания. Упаковщик развертывает контрактный аккаунт, выполняя транзакцию пользовательской операции с ненулевым параметром initCode. Для процесса развертывания не требуется аккаунт с активами, а плата за газ может оплачиваться казначеем.

zkSync

zkSync поддерживает нативную AA и обеспечивает совместимость с виртуальной машиной Ethereum (EVM). Подобно Starknet, zkSync применяет абстракцию подписей и платежей с поддержкой различных схем проверки подписей для различных контрактных аккаунтов, а также разнообразные модели платежей и формы токенов для проведения транзакций.

Поток транзакций в zkSync

Поток транзакций zkSync предполагает отправку пользователем подписанной транзакции оператору, а затем загрузчику для проверки. После проверки и получения комиссии загрузчик отправляет запрос контрактному аккаунту для выполнения транзакции.

Сравнение АА в zkSync и АА в ERC-4337

  • В отличие от решения AA в ERC-4337, zkSync не различает аккаунты с внешним владельцем (EOA) и контрактные аккаунты.

  • zkSync позволяет функции validateTransaction вызывать развернутые внешние контракты. Эта функция ограничена в Ethereum, так как она может привести к изменению состояния, которое приведет к прохождению проверки транзакции и сбою ее выполнения.

  • Еще одно отличие состоит в том, что zkSync позволяет функции validateTransaction и казначею отправлять запрос внешнему хранилищу контрактного аккаунта, инициировавшему эту транзакцию. Например, благодаря казначею и функции validateTransaction можно посмотреть баланс контрактного аккаунта на внешнем контракте. Ethereum же запрещает такую функцию.

Сравнение решений AA от zkSync, Starknet и сетей, совместимых с ERC-4337

Сходства

  • У zkSync, Starknet и сетей, совместимых с ERC-4337, схожие процессы абстракции аккаунта. Они включают этап проверки, механизм комиссий (оплачиваются контрактным аккаунтом или казначеем) и этап исполнения. Кроме того, интерфейсы кошелька смарт-контрактов подразделяются на функции validateTransaction и ExecuteTransaction.

  • zkSync, Starknet и ERC-4337 обрабатывают DoS-атаки одинаково. Логике контракта zkSync разрешено затрагивать только свои собственные слоты, но не разрешается использовать глобальные переменные. Секвенсор Starknet действует схожим образом: он требует локальной симуляции перед добавлением транзакций в мемпул и их передачей. Наконец, пользовательская операция в ERC-4337 накладывает ограничение на газ на этапе validateUserOp и требует от казначея зарезервировать токены.

Различия

  • Самое большое различие заключается в том, что zkSync и StarkNet имеют нативную поддержку AA, а их архитектура отличается от сетей, совместимых с ERC-4337.

  • Что касается потребления газа внутри сети, zkSync и StarkNet являются L2-решениями масштабирования, которые должны учитывать затраты на роллапы.

  • Отличаются и роли, ответственные за исполнение АА. В архитектуре zkSync оператор и загрузчик (системный контракт) вместе выполняют пользовательские операции. В StarkNet секвенсор обрабатывает пользовательские операции упаковщика и казначея. Наконец, сети, совместимые с ERC-4337, имеют разную архитектуру, включающую упаковщиков и контракты точек входа.

  • Еще одно ключевое отличие заключается в том, можно ли отправлять транзакции до развертывания контрактного аккаунта. У StarkNet и zkSync контракт точки входа не имеет поля initCode, которое позволяет развернуть контрактный аккаунт. В итоге ни один из них не сможет отправлять транзакции до развертывания аккаунта.

  • Наконец, существует разница в вызове внешних контрактов. zkSync позволяет функции validateTransaction вызывать развернутые внешние контракты. Однако ни сети, совместимые с ERC-4337, ни Starknet этого не позволяют.

Различия в казначее

  • У Starknet нет интерфейса казначея

  • Для сетей, совместимых с ERC-4337, интерфейс казначея определяет функцию validatePaymasterOp. От этого зависит логика оплаты транзакции казначеем. Интерфейс также использует функцию postOp, которая гарантирует, что казначей сможет получить компенсацию платы за газ после выполнения транзакции. Казначей должен внести Ethereum в контракт точки входа для платы за газ, а затем зарезервировать Ethereum в контракте точки входа для предотвращения создания вредоносных пакетов ботами.

  • zkSync аналогичен сетям, совместимым с ERC-4337, где интерфейс определяет функции validatePaymasterOp и postOp. Эти возможности аналогичны ERC-4337, но эта часть функции пока не реализована. В отличие от казначея в ERC-4337, казначей zkSync не начнет выполнение до тех пор, пока не вызовет функцию postTransaction, когда у него будет достаточно газа. При этом казначей ERC-4337 не будет вызывать функцию postOp, если validatePaymasterUserOp не вернет контекст.

Сравнительная таблица

Хотите быстро разобраться в отличиях между нативной поддержкой и сетями, совместимыми с ERC-4337? Посмотрите нашу таблицу ниже.

Аспекты

ERC-4337

Starknet

zkSync

Аккаунт АА

Смарт-контракт

Нативная поддержка в протоколе

Нативная поддержка в протоколе

Логика процесса

Этап проверки → механизм комиссии (оплачивается контрактным аккаунтом или казначеем) → этап исполнения

Процесс выполнения/вызова

Упаковщик → точка входа

Секвенсор

Оператор → загрузчик

Роль в определении порядка транзакции

Упаковщик

Секвенсор

Оператор

Роль в определении газа

Упаковщик

Секвенсор

Оператор

Потребление газа

Layer 1

Layer 1 ончейн + layer 2

Layer 1 ончейн + layer 2

Можно ли отправлять транзакции до развертывания контрактного аккаунта

Да

Нет

Нет

Правила проверки казначея

Определенная логика через validatePaymasterOp и postOp, казначею необходимо внести и зарезервировать эфир

Нет казначея

Определенная логика через validatePaymasterOp и postOp, где логика вызова postOp немного отличается от Ethereum.

Можно ли вызывать внешние контракты

Нет

Нет

Да

Как минимизировать DoS-угрозы

Пользовательские операции налагают ограничение на газ на этапе validateUserOp, и казначею необходимо зарезервировать токены

Транзакции необходимо добавлять в мемпул и моделировать локально перед передачей

Разрешено задействовать только собственные слоты, нельзя использовать глобальные переменные

Заключение

Мы становимся свидетелями, как многие сети следуют примеру Ethereum и реализуют возможности AA, решая при этом множество проблем, которые могут затруднить массовое распространение. Благодаря мультичейн-AA конкурирующие экосистемы могут показать, что они не сильно отстают в решении таких проблем, как отсутствие гибкости в плате за газ и зависимость от закрытых ключей.

Прочитали про мультичейн-абстракцию аккаунта и заинтересовались изучением пространства Web3? Узнайте, как OKX интегрирует AA в свой мультичейн-кошелек.

Дисклеймер
Данный контент размещен исключительно в ознакомительных целях и может относиться к продуктам, недоступным в вашем регионе. Контент не является (i) советами или рекомендациями по инвестициям; (ii) предложением или приглашением купить, продать или удерживать цифровые активы; (iii) финансовыми, бухгалтерскими, юридическими или налоговыми советами. Цифровые активы, в частности стейблкоины и NFT, несут высокие риски и могут сильно колебаться в цене. Нужно тщательно взвесить оправданность торговли цифровыми активами или владения ими с учетом финансового положения. При возникновении вопросов, связанных с конкретной ситуацией, рекомендуем проконсультироваться у юридического, налогового или инвестиционного специалиста. Информация в статье, в том числе статистика и рыночные данные (при их наличии), предназначена только для общего ознакомления. Несмотря на все старания при подготовке данных и графиков, мы не несем ответственности ни за какие содержащиеся в них ошибки или упущения. На кошелек OKX Web3 и маркетплейс OKX NFT распространяются отдельные условия обслуживания, которые приведены на сайте www.okx.com.
© OKX, 2024. Эту статью можно воспроизводить или распространять как полностью, так и в цитатах объемом не более 100 слов при условии некоммерческого использования. При любом воспроизведении или распространении полного ее содержания нужно четко указать: «Разрешение на использование получено от владельца авторских прав (© 2024) на эту статью — OKX». Цитаты необходимо приводить со ссылкой на название статьи и авторство, например: «Название статьи, [имя автора], © OKX, 2024». Использование статьи в производных и других работах не допускается.
Развернуть
Похожие статьи
Показать еще
Показать еще