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 обозначает цепь, на которой действует данная делегация полномочий
• адрес обозначает целевой адрес для делегирования
• nonce должен соответствовать nonce текущей авторизованной учетной записи
• y_parity, r, s являются данными подписи, подписанными уполномоченным аккаунтом.

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

) реализация

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

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

После того как авторизующий подписал данные авторизации, инициатор сделки соберет их в поле authorization_list для подписи и будет транслировать сделку через RPC. Прежде чем сделка будет выполнена и включена в блок, Предложитель сначала проведет предварительную проверку сделки, в которой будет осуществлена строгая проверка адреса 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 по-прежнему имеет высшую контрольную власть над счетом, и обладая приватным ключом, можно свободно распоряжаться активами на счете. Пользователи или провайдеры кошельков, даже после полного удаления локально хранящегося приватного ключа в результате делегирования 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 также сможет использоваться как смарт-контракт, поэтому некоторые биржи могут столкнуться с повсеместным использованием пополнений через смарт-контракты.

Биржа должна проверять статус каждой операции пополнения через 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, различные участники экосистемы, такие как пользователи, провайдеры кошельков, разработчики и биржи, сталкиваются с множеством вызовов и возможностей в реальном применении. Описанные в статье лучшие практики не могут охватить все потенциальные риски, но все же заслуживают внимания и применения всеми сторонами в реальной практике.