В мире блокчейна, где слово «газ» чаще всего ассоциируется не с автомобильными заправками, а с комиссиями за транзакции в Ethereum, поиск способов минимизации этих расходов становится всё более актуальным. Меньше боли в сердце за опустошённый кошелёк и больше времени для решения действительно важных вопросов... например, что приготовить на обед =)
Подобно эпическому сражению Бэтмена против Супермена сравним GSN и Account Abstraction. Как и в любой супергеройской истории, каждый из них имеет свои уникальные способности и недостатки, которые мы подробно рассмотрим.
Знакомство с GSN
GSN (Gas Station Network) — это решение, разработанное для облегчения взаимодействия пользователей с блокчейном Ethereum, позволяя им отправлять транзакции без необходимости оплачивать газ. GSN строится на основе стандарта ERC-2771, который позволяет смарт‑контрактам интерпретировать вызовы функций так, будто они были выполнены конечным пользователем, хотя на самом деле вызов осуществляется посредником.
Архитектура GSN была подробно раскрыта в предыдущей статье. Там был детально рассмотрен алгоритм взаимодействия компонентов, а также приведены различные сценарии использования технологии. Подробнее:
Знакомство с Account Abstraction
Account Abstraction (ERC-4337) — это подход в Ethereum, который предлагает стандартизированное решение для более гибкого управления аккаунтами, что значительно расширяет их функциональность. Основная идея заключается в том, чтобы сделать аккаунты более "умными", т.е. позволить контрактам выполнять роли аккаунтов пользователей.
Возможности Account Abstraction
1. Умные аккаунты (Smart Accounts): ERC-4337 позволяет пользователям использовать смарт-контракты как аккаунты, которые могут иметь собственные правила и логику для обработки транзакций. Например, включать автоматические утверждения транзакций, усовершенствованные меры безопасности, и другие пользовательские логики.
2. Gasless-решения: хотя основная цель Account Abstraction не заключается в создании безгазовых приложений, этот стандарт позволяет реализовать такую функциональность как дополнительную опцию. С помощью умных аккаунтов можно настраивать, кто именно (пользователь или децентрализованное приложение) будет платить за газ, что делает возможным создание dApps без необходимости оплаты газа конечными пользователями.
3. Пакетная обработка транзакций: умные аккаунты могут отправлять несколько транзакций как одну пакетную операцию. Это удобно, например, для выполнения сложных финансовых операций, где нужно последовательно выполнить несколько шагов.
4. Повышенная безопасность и гибкость: с умными аккаунтами пользователи могут внедрять различные уровни безопасности, такие как многофакторная аутентификация или автоматические ограничения на максимальные суммы транзакций.
Ключевые компоненты ERC-4337
UserOperation: структура данных, представляющая операцию пользователя. Она включает в себя все необходимые данные, такие как вызываемая функция, параметры операции, и сигнатура пользователя.
EntryPoint: центральный контракт в системе Account Abstraction, который получает и обрабатывает User Operations. EntryPoint отвечает за проверку валидности операций и их исполнение.
Bundler (или Block Proposer): эти агенты собирают операции от пользователей и отправляют их в сеть Ethereum, включая их в блоки.
Smart Account Contract: это смарт‑контракт пользователя, который функционирует как его аккаунт в блокчейне. Этот контракт содержит логику, которая определяет, как именно должны быть обработаны входящие транзакции и кто и как может инициировать транзакции от имени пользователя.
Эта архитектура может быть расширена дополнительными компонентами:
Paymasters: необязательные смарт‑контракты, предназначенные для финансирования операций от имени контрактных аккаунтов. Paymasters могут брать на себя затраты на газ, уменьшая нагрузку на пользователей и увеличивая доступность децентрализованных приложений.
Aggregators: также необязательные смарт‑контракты, которые могут выполнять роль проверяющих подписи для операций, исходящих от множества контрактных аккаунтов. Aggregators упрощают и оптимизируют процесс обработки транзакций, позволяя обрабатывать большое количество подписей и запросов эффективно.
Сравнение технологий
Вот мы и подошли к самой эпической части — битве двух супергероев блокчейна! GSN и Account Abstraction готовы показать, на что они способны. Давайте подробно рассмотрим, в чём их преимущества и недостатки по ключевым критериям. Приступим!
1. Используемый стандарт
GSN: GSN использует стандарт ERC-2771, который предоставляет способ обработки метатранзакций через релеевые серверы.
Account Abstraction: в основе Account Abstraction лежит стандарт ERC-4337, который расширяет возможности аккаунтов, позволяя смарт‑контрактам выполнять функции обычных пользовательских аккаунтов.
2. Безопасность
GSN: хотя GSN и упрощает пользовательский опыт, механизм релеев может быть уязвим для атак, таких как фронтраннинг (когда злоумышленник перехватывает и изменяет транзакции до их исполнения). Для минимизации таких рисков необходимо тщательно управлять релеевыми серверами и Paymaster'ами, что требует дополнительных ресурсов и мониторинга.
Account Abstraction: благодаря использованию контрактов‑кошельков, безопасность в Account Abstraction может быть кастомизирована под конкретные нужды пользователей. Например, можно внедрять многофакторную аутентификацию, устанавливать лимиты на транзакции или использовать мультиподписи. Всё это делает Account Abstraction более безопасным и гибким для сложных сценариев, но увеличивает сложность в настройке и использовании.
3. Масштабируемость
GSN: с ростом количества пользователей и транзакций в сети, масштабируемость GSN может стать проблемой, так как для обработки транзакций необходима поддержка релеев. Если сеть релеев не растёт с той же скоростью, что и количество транзакций, это может привести к задержкам в выполнении и даже к отказам.
Account Abstraction: масштабируемость Account Abstraction лучше управляется, поскольку этот стандарт позволяет объединять транзакции в пакеты и уменьшать затраты на газ благодаря контрактам Paymaster и агрегаторам подписей. Это позволяет обрабатывать большое количество операций эффективнее, но добавляет сложность в реализации.
4. Поддержка мульти-операций
GSN: в основном нацелен на оплату газа за одну операцию от имени пользователя, и его возможности в плане мульти‑операций ограничены.
Account Abstraction: одно из главных преимуществ Account Abstraction — это возможность обрабатывать несколько операций в одной транзакции. Например, пользователи могут объединять несколько шагов в рамках одной финансовой операции, что значительно снижает затраты на газ и делает систему более эффективной.
5. Поддержка Externally Owned Accounts (EOA)
GSN: поддерживает работу с классическими аккаунтами (EOA). Это делает его легко совместимым с существующими пользователями и инфраструктурой Ethereum.
Account Abstraction: наоборот, требует использования аккаунтов‑смарт‑контрактов, что ограничивает возможность работы с классическими EOA.
6. Интеграция с кошельками
GSN: поскольку GSN использует существующие аккаунты Ethereum и релеевые серверы для оплаты газа, он полностью совместим с классическими кошельками, такими как MetaMask и другие. Пользователям не нужно менять кошельки или настраивать дополнительные контракты для взаимодействия с DApp'ами через GSN.
Account Abstraction: одно из ключевых ограничений Account Abstraction заключается в том, что он не совместим с традиционными кошельками, такими как MetaMask. Для работы с этим стандартом пользователям нужно будет использовать контракты‑кошельки, которые выполняют функции аккаунтов. Это усложняет интеграцию с существующими кошельками, но даёт более высокую гибкость для разработчиков, так как можно встроить свою логику безопасности и обработки транзакций.
7. Архитектура и сложность интеграции
GSN: имеет относительно простую архитектуру, включающую релеевые серверы, Paymaster‑контракты и смарт‑контракты‑получатели (Recipient Contracts). Однако релеевые серверы требуют тщательного управления и мониторинга, чтобы избежать атак и недобросовестного поведения. В то же время, для пользователей с классическими кошельками GSN предоставляет более низкий порог входа, так как архитектура легко интегрируется с существующими приложениями. Таким образом GSN более релевантен для интеграции в уже разработанные решение без модернизации существующей архитектуры.
Account Abstraction: обладает более сложной архитектурой. Ключевые компоненты — это UserOperation, EntryPoint и Bundlers — требуют более детальной интеграции и настройки. При этом Account Abstraction предлагает большую гибкость для разработчиков, так как они могут самостоятельно создавать логику работы своих аккаунтов. Однако внедрение этой системы требует значительных усилий, особенно если нужно поддерживать совместимость с существующими dApps и инфраструктурой.
Заключение
Итак, если GSN и Account Abstraction — это супергерои блокчейна, то GSN можно представить как дружелюбного Человека‑Паука: простого, надёжного, легко совместимого с классическими кошельками и подходящего для большинства повседневных задач. Но когда дело доходит до спасения мира (сложных операций, мульти‑операции и расширенной безопасности), на сцену выходит Account Abstraction — это Железный Человек с арсеналом высокотехнологичных гаджетов, готовый к любым испытаниям, даже если для этого нужно сменить классический костюм на новый смарт‑контракт.
Каждый из них имеет свои сильные и слабые стороны: GSN — это лёгкость и совместимость, но с ограниченной гибкостью, в то время как Account Abstraction — это мощь и возможности, хотя и с более высокой планкой интеграции. Выбирайте своего героя в зависимости от того, нужен ли вам быстрый релей или умный аккаунт, способный справиться с множеством задач сразу. В конце концов, в блокчейне, как и в жизни, супергероев много не бывает!
Комментарии (3)
pnaydanovgoo
25.10.2024 01:50одно из ключевых ограничений Account Abstraction заключается в том, что он не совместим с традиционными кошельками, такими как MetaMask.
Вот здесь не соглашусь. Для АА вполне можно использовать обычный metamask для идентификации пользователя. В этом плане пользователю с метамаском не нужно ничего придумывать, он точно также пользуется свои кошельком, чтобы подписывать транзакции (точнее userOperations) для своего абстрактного акаунта, эта подпись потом будет разбираться на контрактах и олицетвораять пользователя с его контрактом кошелька. Другое дело, если мы хотим заменить идентификацию пользователя в АА на что-то другое, например на обычную почту. Но тут все равно без EOA никак (точнее потенциал на замену ECDSA есть, но я пока не встречал что-то другое, поделитесь, если есть примеры), он любым способом генерится для пользователя, как ни крути, только для этого используют еще сторонние сервисы: MagicLink, Fireblocks и так далее.
Хотел еще поделиться, что сложность АА легко нивелируется использованием готовых решений: Alchemy, ZeroDev, Biconomy, что-то там от gnosis и другие. Тут на любой вкус с разными прайсами и стандартами поверх ERC-4337 (Это еще стандарты ERC-6900, ERC-7579). Там уже сложность, если тебе не хватает контрактов кошельков под АА готовых, то тогда надо разобраться, как добавить своей логики.
В конце добавлю, что ERC-4337 разрабатывался при поддержки и консультациях ребят из GSN) Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, если посмотреть их профили, они все в организации OpenGSN. Так что железный человек и человек-паук и тут дружат.
csl
Какие аналоги рассмотренных решений есть в других блокчейнах, например, Cardano, Kadena?
pnaydanovgoo
Знаю, что в Solana АА работает из коробки.