Ethereum Pectra обновление EIP-7702: значительная трансформация для EOA

Введение

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

! Несброшенный код учетной записи EOA