Как работают аккаунты Ethereum под капотом

Эфириум использует два типа счетов: внешние владимые счета (EOA) и контрактные счета. EOA контролируются приватными ключами и используются физическими лицами или приложениями для подписания транзакций. Эти счета имеют простую структуру. Они включаютNonce, баланс и связанный публичный ключ, но не имеют внутреннего кода. Когда пользователь подписывает транзакцию из EOA, Виртуальная Машина Эфириума (EVM) проверяет подпись и вычитает плату за газ перед выполнением транзакции. Контрактные счета, напротив, контролируются кодом и не инициируют действия самостоятельно. Они только отвечают на транзакции, инициируемые EOA. EVM обрабатывает логику контракта и хранит состояние, но контракт не может подписывать транзакции самостоятельно или инициировать их без внешнего ввода.

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

Как абстракция аккаунта меняет валидацию транзакций, газ и доступ

Абстракция аккаунта изменяет путь валидации транзакций, позволяя самому аккаунту определять, как действия одобряются и выполняются. Вместо того чтобы требовать подпись от конкретного закрытого ключа, смарт-контрактный кошелек может определить свою собственную логику аутентификации. Эта логика может включать пороговые подписи, проверки аппаратных устройств или правила для лимитов расходов и временных блокировок.

Одним из самых значительных изменений, введенных абстракцией аккаунтов, является декомплектация оплаты газа от отправителя. Традиционно инициатор транзакции должен оплачивать газ в ETH. В рамках абстракции аккаунтов логика валидации может позволить третьим лицам — называемым плательщиками — покрывать расходы на газ от имени пользователя. Это открывает новые возможности, такие как спонсирование транзакций для новых пользователей, возможность взаимодействия с dApp без газа или оплата сборов в стейблкоинах или токенах родных проектов.

Кроме того, абстракция учетной записи вводит возможность объединять несколько операций в одну транзакцию. Например, пользователь может одобрить токен, выполнить своп и перевести средства в одном действии, уменьшая количество необходимых подтверждений и улучшая пользовательский опыт. Эти улучшения значительно снижают трение в взаимодействиях с dApp, сохраняя при этом безопасность и совместимость.

Введение в ERC-4337 и «альтернативный мемпул»

ERC-4337, окончательно принят в 2023 году, представляет собой важный этап в пути Ethereum к абстракции аккаунтов. В отличие от более ранних предложений, таких как EIP-2938, ERC-4337 не требует изменений в слое консенсуса Ethereum. Вместо этого он полностью работает в существующей среде смарт-контрактов, вводя параллельный поток транзакций с использованием альтернативного мемпула и специфической архитектуры контракта.

По стандарту ERC-4337 транзакции заменяются на UserOperations — объекты данных, которые описывают желаемые действия, но не отправляются в традиционный мемпул. Эти UserOperations подбираются специализированными оффчейн-акторами, известными как бандлеры. Бандлер агрегирует несколько UserOperations в стандартную транзакцию Ethereum и отправляет ее в блокчейн.

В цепочке, синглтон-контракт под названием EntryPoint проверяет и обрабатывает эти объединённые операции. EntryPoint взаимодействует с пользовательскими смарт-аккаунтами, которые определяют свою собственную логику валидации и делегируют выполнение транзакций после их валидации. Для оплаты газовых сборов аккаунты могут по желанию взаимодействовать с платёжными мастерами, которые спонсируют затраты на выполнение при условиях, указанных в коде.

Эта структура позволяет децентрализованный, безразрешительный способ поддержки абстракции аккаунтов без изменения базового протокола Ethereum. В результате разработчики могут развертывать смарт-контрактные кошельки, которые ведут себя как EOA с точки зрения пользователя, но предлагают гораздо более богатую функциональность.

Подход Solana: Нативная абстракция аккаунта

Solana принимает принципиально иной подход к абстракции учетных записей, поддерживая ее на уровне протокола. Учетные записи Solana не делятся на EOA и контрактные учетные записи. Вместо этого все учетные записи на Solana являются универсальными контейнерами для хранения, которые могут хранить данные, иметь назначенное право собственности и взаимодействовать с программами.

В модели Solana валидация действий встроена непосредственно в программы (умные контракты). Адреса, полученные от программ (PDA), являются ключевым элементом этой системы. Это детерминированные адреса, генерируемые из семян и программ, которые не имеют связанного закрытого ключа. Вместо этого они контролируются логикой программы и могут выполнять действия, когда выполнены соответствующие условия.

Благодаря этой родной гибкости, Solana предложила такие функции, как многофакторная авторизация, делегирование аккаунта и оплата сборов третьими сторонами, не требуя внешних стандартов или смоделированных потоков транзакций. Кошельки, такие как Phantom и Solflare, рано интегрировали эти возможности, демонстрируя бесшовный пользовательский опыт и программируемый контроль над средствами. Это контрастирует с Ethereum, где аналогичная функциональность зависит от накладок, таких как ERC-4337 и сети бандлеров.