👑 EIP-7702: Set EOA account code for one transaction

Стандарт гласит: Добавить новый тип транзакции, который навсегда устанавливает код для EOA. Садитесь и пристегнитесь!🪑

Все кто знаком с Ethereum знают, что существует два типа аккаунтов: EOA (Externally-owned account) и Contract account. Оба имеют свой уникальный адрес, но первый контролируется владельцем приватного ключа и не имеет кода, второй — это смарт-контракт.

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

Одним из авторов этого предложения выступает Виталик Бутерин.

▫️Как это будет работать?

EOA подписывает и отправляет новый тип транзакции, согласно EIP-2718. Клиент проверяет подпись, EOA nonce, chainId. После этого для EOA устанавливается код.

Важно то, что подпись не будет совместима c привычными EIP-712 и EIP-191.

▫️А что с EIP-3074?

EIP-3074 вводит новый коды операций AUTH и AUTHCALL, которые позволяют EOA делегировать действия смарт-контракту, позволяя контракту выполнять транзакции от имени EOA. Изначально, именно этот стандарт планировалось добавить в Pectra.

Однако в ходе обсуждения было решено, что EIP-7702 дает больше преимуществ:
🟠 более простая реализация
🟠 совместимость с ERC-4337

▫️Совместимость с ERC-4337: Account Abstraction Using Alt Mempool

ERC-4337 плотно вошел в нашу жизнь! Предполагается, что будет полная совместимость. Код, который будет ассоциирован с EOA может напрямую вызывать абстрактный аккаунт, созданный под этим стандартом и для него вызов будет выглядеть также, как от обычного EOA.

▫️Что меня смущает?

1️⃣ Неужели код можно будет установить один раз на аккаунт? А что делать если в нем окажется уязвимость? Она останется там навечно? А если это было по ошибке?
2️⃣ Если я захочу в коде организовать проверку подписи, то как это будет работать для разных блокчейнов (я имею ввиду L2)? То есть такой код не будет универсальным?
3️⃣ Как теперь будет работать трансфер NFT, где в случае, если получатель — это контракт, то в нем должна быть реализована специальная функция, которая позволяет принимать NFT. EOA с кодом будет работать как контракт или все останется, как и прежде?

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

▫️Вывод

Мне довелось поработать со стандартом ERC-4337, также познакомиться по касательной с двумя стандартами модульной разработки аккаунта (ERC-6900 и ERC-7579). После подобного опыта я с нетерпением жду, чем для нас обернется EIP-7702.

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

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

#в_гостях_у_Pectra #павел_найданов