Обновление Ethereum Pectra и EIP-7702: важный шаг в размывании границ между EOA и контрактными счетами

Введение

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

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

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

Обзор

EIP-7702 ввел новый тип транзакции, который позволяет EOA указывать адрес смарт-контракта для установки кода. Это позволяет EOA выполнять код так же, как смарт-контракты, сохраняя при этом возможность инициировать транзакции. Эта функция наделяет EOA программируемостью и композируемостью, пользователи могут реализовать функции социального восстановления, управления правами, многоподписного управления, zk-подтверждения, подписной оплаты, спонсирования транзакций и пакетной обработки транзакций в EOA. 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. Затем закодированные данные вместе с MAGIC числом проходят через хеширование keccak256, чтобы получить данные для подписи. Наконец, с помощью личного ключа авторизатора подписываются закодированные данные, что дает y_parity, r и s данные. MAGIC ###0x05( используется в качестве разделителя домена, чтобы гарантировать, что результаты подписей разных типов не будут конфликтовать.

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

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

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

Для разработчиков в процессе разработки следует соблюдать Namespace Formula, предложенную 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 на Эфире. EIP-7702 вводит новый тип транзакций, который обеспечивает EOA программируемостью и совместимостью, размывая границы между EOA и контрактными счетами. Поскольку в настоящее время нет стандартов смарт-контрактов, совместимых с типом EIP-7702, экосистемные участники, такие как пользователи, поставщики кошельков, разработчики, CEX и т. д., сталкиваются с многими вызовами и возможностями. Описанные в статье лучшие практики не могут охватить все потенциальные риски, но все же достойны внимания для применения в реальной практике.