EIP-7702: Значительная реформа внешних счетов Ethereum

Ethereum вскоре встретит обновление Pectra, в котором EIP-7702 произвел революционные изменения для внешнего счета (EOA). Это предложение размывает границы между EOA и контрактным счетом CA, что является ключевым шагом к нативной абстракции счетов и приносит новую модель взаимодействия в экосистему Ethereum.

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

Анализ протокола

Обзор

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

EIP-7702 ввёл тип транзакции SET_CODE_TX_TYPE (0x04), его структура данных содержит поле authorization_list, которое может содержать несколько авторизационных записей. Каждая авторизационная запись включает chain_id, address, nonce и данные подписи.

реализация

При подписании данных авторизации доверителем необходимо выполнить RLP-кодирование chain_id, address и nonce, затем произвести хеширование с использованием keccak256 вместе с MAGIC-числом, после чего подписать с помощью приватного ключа. MAGIC (0x05) служит разделителем домена, чтобы гарантировать, что результаты подписей разных типов не будут конфликтовать.

Когда chain_id равен 0, это означает, что авторизация может быть воспроизведена на всех поддерживающих EIP-7702 EVM-совместимых цепочках. Перед выполнением транзакции Пропозер проведет предварительную проверку, чтобы убедиться, что транзакция не является транзакцией создания контракта. Поле authorization_list в транзакции должно содержать как минимум одну запись авторизации.

При выполнении транзакции узлом сначала увеличивается nonce инициатора, затем для каждого элемента авторизации выполняется операция applyAuthorization. В случае ошибки этот элемент авторизации будет пропущен, остальные элементы продолжат применяться. После завершения авторизации поле code адреса авторизатора будет установлено в 0xef0100||address. Авторизатор может установить целевой адрес делегата в 0 адрес для удаления авторизации.

Лучшие практики

Несмотря на то, что EIP-7702 вносит новую жизнь в экосистему Ethereum, он также приносит новые риски. Вот аспекты, на которые участникам экосистемы следует обратить внимание:

хранение приватного ключа

Даже если после делегирования EOA можно решить проблему потери средств с помощью социальных восстановлений, риск утечки приватного ключа все равно остается. Пользователи должны ставить защиту приватного ключа на первое место.

Многоцепочечное воспроизведение

Пользователи могут выбрать chainId равный 0 для делегирования, чтобы оно действовало на нескольких цепочках. Однако на разных цепочках один и тот же адрес контракта может иметь разные реализации. Поставщики кошельков должны проверить, совпадают ли цепочка делегирования и текущая сеть, и предупредить пользователей о связанных рисках.

Не удалось инициализировать

EIP-7702 не может вызывать функцию инициализации при развертывании, как контракт прокси ERC-1967. Разработчики должны проводить проверку прав доступа во время инициализации кошелька, чтобы избежать риска перехвата.

Управление хранилищем

Перенаправление на другой адрес контракта может привести к различиям в структуре хранения, что может вызвать блокировку счета или потерю средств. Разработчики должны следовать формуле пространства имен ERC-7201 и выделять переменные в независимые места хранения.

Ложный депозит

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

преобразование счета

Счет может свободно переключаться между EOA и SC, разрушая некоторые предположения о безопасности, которые ограничивают участие только EOA в проектах. Разработчики должны предполагать, что будущие участники могут быть смарт-контрактами.

Совместимость контрактов

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

Проверка рыбалки

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

Итог

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