Ethereum Pectra обновление: Глубина анализа EIP-7702 и руководство по лучшим практикам

Введение

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

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

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

Обзор

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

Конкретная реализация EIP-7702 заключается во введении типа транзакции SET_CODE_TX_TYPE (0x04), структура данных которой определена следующим образом:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Поле authorization_list определено как:

authorization_list = [[chain_id, адрес, nonce, y_parity, r, s], ...]

В новой структуре транзакций, кроме поля authorization_list, остальные следуют той же семантике, что и EIP-4844. Это поле является списковым типом, в списке может содержаться несколько авторизационных записей, в каждой авторизационной записи:

• поле chain_id указывает на цепь, на которой действует эта авторизация
• поле address указывает целевой адрес делегирования
• поле nonce должно соответствовать nonce текущего авторизованного аккаунта
• поля y_parity, r, s являются данными подписи, подписанными авторизованным аккаунтом.

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

реализовать

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

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

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

В то же время такие сделки будут настоятельно требовать, чтобы поле authorization_list в транзакции содержало как минимум одну запись авторизации. Если несколько записей авторизации подписаны одним и тем же авторизатором, то в конечном итоге будет действовать только последняя запись авторизации.

Затем, в процессе выполнения сделки, узел сначала увеличит значение nonce инициатора сделки, а затем выполнит операцию applyAuthorization для каждого элемента авторизации в authorization_list. В операции applyAuthorization узел сначала проверит nonce авторизатора, а затем увеличит nonce авторизатора. Это означает, что если инициатор сделки и авторизатор являются одним и тем же пользователем (EOA), то при подписании авторизационной сделки значение nonce должно быть увеличено на 1.

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

После завершения авторизации приложения поле code адреса авторизатора будет установлено в 0xef0100 || address, где 0xef0100 является фиксированным идентификатором, а address - целевой адрес делегирования. Из-за ограничений EIP-3541 пользователи не могут развертывать код контрактов, начинающийся с байтов 0xef, обычным способом, что гарантирует, что такие идентификаторы могут быть развернуты только транзакциями типа SET_CODE_TX_TYPE (0x04).

После завершения авторизации, если авторизующий желает отменить авторизацию, ему достаточно установить целевой адрес делегирования на 0-адрес.

Новый тип транзакций, введенный через EIP-7702, позволяет авторизатору ( EOA ) выполнять код, как смарт-контракт, и одновременно сохранять возможность инициировать транзакции. По сравнению с EIP-4337, это предоставляет пользователям опыт, более близкий к нативному абстрагированному счету ( Native AA ), что значительно снижает порог входа для пользователей.

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

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

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

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

Для пользователей, при использовании аккаунта после делегирования, пользователи все равно должны ставить защиту приватного ключа на первое место и всегда помнить: Not your keys, not your coins.

Мультицепочечная атака повторения

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

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

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

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

Текущие основные смарт-контрактные кошельки в основном используют прокси-модель. При развертывании прокси-кошелек будет вызывать функцию инициализации контракта через DELEGateCALL, чтобы достичь атомарной операции инициализации кошелька и развертывания прокси-кошелька, избегая проблемы преждевременной инициализации. Однако, когда пользователь использует EIP-7702 для делегирования, обновляется только поле code адреса, и нельзя инициализировать через вызов адреса делегата. Это делает невозможным для EIP-7702 вызывать функцию инициализации в транзакции развёртывания контракта, как это делается в распространённых ERC-1967 прокси-контрактах.

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

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

При использовании функции делегирования EIP-7702 пользователи могут столкнуться с необходимостью повторного делегирования на другой адрес контракта из-за изменения требований к функциональности, обновления кошелька и других причин. Однако структура хранения различных контрактов может отличаться###, например, слот slot0 разных контрактов может представлять разные типы данных(. В случае повторного делегирования это может привести к неожиданному повторному использованию данных старого контракта новым контрактом, что, в свою очередь, может вызвать блокировку аккаунта, потерю средств и другие неприятные последствия.

Для пользователей следует осторожно относиться к ситуации с повторной делегацией.

Для разработчиков важно следовать формуле пространств имен, предложенной ERC-7201, при разработке, распределяя переменные по назначенным независимым местам хранения, чтобы уменьшить риск конфликтов хранения. Кроме того, ERC-7779 )draft( также предоставляет стандартный процесс повторной делегации специально для EIP-7702: включая использование ERC-7201 для предотвращения конфликтов хранения и проверку совместимости хранения перед повторной делегацией, а также вызов интерфейса старой делегации для очистки старых данных из хранилища.

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

После того как пользователь сделает委托, EOA также сможет использоваться как смарт-контракт, поэтому централизованные биржи ###CEX( могут столкнуться с ситуацией, когда пополнение смарт-контрактов станет повсеместным.

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

) Конвертация счета

После внедрения делегирования EIP-7702 тип учетной записи пользователя может свободно переключаться между EOA и SC, что позволяет учетной записи как инициировать транзакции, так и вызываться. Это означает, что когда учетная запись вызывает саму себя и выполняет внешние вызовы, её msg.sender также будет tx.origin, что нарушает некоторые предположения о безопасности, ограничивающие участие только EOA в проекте.

Для разработчиков контрактов предположение, что tx.origin всегда является EOA, больше не будет действительным. Аналогично, проверка через msg.sender == tx.origin для защиты от атак повторного входа также будет неэффективной.

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

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

Существующие токены ERC-721 и ERC-777 имеют функцию Hook при переводе на контракт, что означает, что получатель должен реализовать соответствующую функцию обратного вызова для успешного получения токенов.

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

Проверка на рыбалку

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

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

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

Резюме

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