Ethereum Pectra обновление: Глубокий анализ EIP-7702 и руководство по лучшим практикам
Введение
Ethereum скоро встретит обновление Pectra, это значительное обновление. В частности, EIP-7702 произвёл революционные изменения в внешнем аккаунте Ethereum (EOA). Это предложение размывает границы между EOA и контрактными аккаунтами CA, что является ключевым шагом к абстракции аккаунтов, принося новую модель взаимодействия в экосистему Ethereum.
Pectra уже завершила развертывание в тестовой сети и ожидается, что вскоре она будет запущена в основной сети. В данной статье будет подробно рассмотрен механизм реализации EIP-7702, исследованы возможные возможности и вызовы, а также предоставлены практические руководства для различных участников.
Анализ протокола
Обзор
EIP-7702 вводит новый тип транзакции, позволяющий EOA указывать адрес смарт-контракта и устанавливать для него код. Это позволяет EOA выполнять код так же, как и смарт-контракт, при этом сохраняя возможность инициировать транзакции. Эта функция наделяет EOA программируемостью и совместимостью, пользователи могут реализовать в EOA функции социальной восстановления, контроля доступа, управления мультиподписями, zk-проверки, подписной оплаты, спонсирования транзакций и пакетной обработки транзакций. Стоит отметить, что EIP-7702 идеально совместим с кошельками смарт-контрактов, реализованными EIP-4337, что упрощает процесс разработки и применения новых функций.
EIP-7702 ввел тип транзакции SET_CODE_TX_TYPE (0x04), структура данных которого определяется следующим образом:
В новой структуре транзакций, кроме поля authorization_list, остальные следуют той же семантике, что и EIP-4844. authorization_list является списковым типом и может содержать несколько записей авторизации. В каждой записи авторизации:
chain_id обозначает цепь, на которой активируется полномочие делегата
адрес обозначает целевой адрес делегирования
nonce должен соответствовать nonce текущего авторизованного аккаунта
y_parity, r, s являются данными подписи, подписанными авторизованным аккаунтом
Список авторизации транзакции может содержать несколько различных авторизованных аккаунтов, подписанных (EOA), что позволяет осуществлять оплату газа для операций авторизации.
Реализация
Когда уполномоченный подписывает данные о полномочиях, необходимо сначала закодировать chain_id, address, nonce с помощью RLP. Затем закодированные данные вместе с MAGIC проходят хэширование keccak256, чтобы получить данные для подписи. Наконец, с помощью частного ключа уполномоченного подписываются хэшированные данные, чтобы получить данные y_parity, r, s. MAGIC (0x05) используется в качестве разделителя домена, чтобы гарантировать, что результаты подписей разных типов не конфликтуют.
Когда chain_id, разрешенный авторизатором, равен 0, это означает, что авторизатор разрешает повторное использование разрешения на всех EVM-совместимых цепях, поддерживающих EIP-7702 (при условии, что nonce также совпадает).
После того как уполномоченный подпишет данные о разрешении, инициатор транзакции соберет их в поле authorization_list для подписи и распространит транзакцию через RPC. Перед выполнением транзакции Предложитель сначала проведет предварительную проверку, чтобы убедиться, что эта транзакция не является транзакцией создания контракта, то есть при отправке транзакции типа EIP-7702 адрес to не может быть пустым.
Такие транзакции требуют, чтобы поле authorization_list содержало как минимум одну запись авторизации. Если несколько записей авторизации подписаны одним и тем же авторизатором, то в конечном итоге будет действительна только последняя запись авторизации.
При выполнении транзакции узел сначала увеличивает значение nonce инициатора транзакции, а затем выполняет операцию applyAuthorization для каждой записи в authorization_list. В операции applyAuthorization узел сначала проверяет nonce авторизующего лица, а затем увеличивает nonce авторизующего лица. Это означает, что если инициатор транзакции и авторизующее лицо являются одним и тем же пользователем (EOA), то при подписании авторизационной транзакции значение nonce должно быть увеличено на 1.
При авторизации элементов приложений узлов, если возникает ошибка, этот элемент будет пропущен, сделка не потерпит неудачу, другие элементы авторизации продолжат применяться, чтобы избежать риска DoS в сценариях массовой авторизации.
После завершения авторизации приложения поле code адреса авторизующего лица будет установлено в 0xef0100 || address, где 0xef0100 является фиксированным идентификатором, а address — целевым адресом делегирования. Ограничения EIP-3541 обеспечивают, что такие идентификаторы могут быть развернуты только транзакциями типа 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.
Разработчики должны выполнять проверку прав доступа (например, с помощью ecrecover для восстановления адреса подписи) во время инициализации кошелька, когда они комбинируют EIP-7702 с существующим кошельком EIP-4337, чтобы избежать риска того, что операция инициализации кошелька будет перехвачена.
Управление хранилищем
При использовании функции делегирования 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 Ethereum. EIP-7702 вводит новый тип транзакций, позволяя EOA обладать программируемостью и композируемостью, размывая границы между EOA и контрактными счетами. Поскольку на данный момент нет стандарта смарт-контрактов, совместимого с EIP-7702, который прошел бы испытания в реальных условиях, различные участники экосистемы, такие как пользователи, провайдеры кошельков, разработчики, CEX и т.д., сталкиваются с множеством вызовов и возможностей в практическом применении. Описанные в статье лучшие практики не могут охватить все потенциальные риски, но все же стоят внимания для применения на практике.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
5
Поделиться
комментарий
0/400
Ser_Liquidated
· 07-17 21:03
Ай-ай, снова обновление, быков и неудачников не отличить.
Посмотреть ОригиналОтветить0
SeasonedInvestor
· 07-16 10:06
Наконец-то могу выбросить Кошелек. На передовой ел неудачников много лет, всё немного понимаю.
Посмотреть ОригиналОтветить0
LiquidationWatcher
· 07-16 00:41
Снова устроили большое событие, просто следуйте за этим и все.
Посмотреть ОригиналОтветить0
LightningAllInHero
· 07-16 00:40
Виталик Бутерин эта волна действительно поднимает меня на Луну, жду 0.5eth рост до небес
Посмотреть ОригиналОтветить0
AltcoinHunter
· 07-16 00:20
Нажмите на кнопку testnet, и на луну. Закройте глаза и все.
Ethereum Pectra обновление EIP-7702 Глубина анализа и лучшие практики
Ethereum Pectra обновление: Глубокий анализ EIP-7702 и руководство по лучшим практикам
Введение
Ethereum скоро встретит обновление Pectra, это значительное обновление. В частности, EIP-7702 произвёл революционные изменения в внешнем аккаунте Ethereum (EOA). Это предложение размывает границы между EOA и контрактными аккаунтами CA, что является ключевым шагом к абстракции аккаунтов, принося новую модель взаимодействия в экосистему Ethereum.
Pectra уже завершила развертывание в тестовой сети и ожидается, что вскоре она будет запущена в основной сети. В данной статье будет подробно рассмотрен механизм реализации EIP-7702, исследованы возможные возможности и вызовы, а также предоставлены практические руководства для различных участников.
Анализ протокола
Обзор
EIP-7702 вводит новый тип транзакции, позволяющий EOA указывать адрес смарт-контракта и устанавливать для него код. Это позволяет 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. authorization_list является списковым типом и может содержать несколько записей авторизации. В каждой записи авторизации:
Список авторизации транзакции может содержать несколько различных авторизованных аккаунтов, подписанных (EOA), что позволяет осуществлять оплату газа для операций авторизации.
Реализация
Когда уполномоченный подписывает данные о полномочиях, необходимо сначала закодировать chain_id, address, nonce с помощью RLP. Затем закодированные данные вместе с MAGIC проходят хэширование keccak256, чтобы получить данные для подписи. Наконец, с помощью частного ключа уполномоченного подписываются хэшированные данные, чтобы получить данные y_parity, r, s. MAGIC (0x05) используется в качестве разделителя домена, чтобы гарантировать, что результаты подписей разных типов не конфликтуют.
Когда chain_id, разрешенный авторизатором, равен 0, это означает, что авторизатор разрешает повторное использование разрешения на всех EVM-совместимых цепях, поддерживающих EIP-7702 (при условии, что nonce также совпадает).
После того как уполномоченный подпишет данные о разрешении, инициатор транзакции соберет их в поле authorization_list для подписи и распространит транзакцию через RPC. Перед выполнением транзакции Предложитель сначала проведет предварительную проверку, чтобы убедиться, что эта транзакция не является транзакцией создания контракта, то есть при отправке транзакции типа EIP-7702 адрес to не может быть пустым.
Такие транзакции требуют, чтобы поле authorization_list содержало как минимум одну запись авторизации. Если несколько записей авторизации подписаны одним и тем же авторизатором, то в конечном итоге будет действительна только последняя запись авторизации.
При выполнении транзакции узел сначала увеличивает значение nonce инициатора транзакции, а затем выполняет операцию applyAuthorization для каждой записи в authorization_list. В операции applyAuthorization узел сначала проверяет nonce авторизующего лица, а затем увеличивает nonce авторизующего лица. Это означает, что если инициатор транзакции и авторизующее лицо являются одним и тем же пользователем (EOA), то при подписании авторизационной транзакции значение nonce должно быть увеличено на 1.
При авторизации элементов приложений узлов, если возникает ошибка, этот элемент будет пропущен, сделка не потерпит неудачу, другие элементы авторизации продолжат применяться, чтобы избежать риска DoS в сценариях массовой авторизации.
После завершения авторизации приложения поле code адреса авторизующего лица будет установлено в 0xef0100 || address, где 0xef0100 является фиксированным идентификатором, а address — целевым адресом делегирования. Ограничения EIP-3541 обеспечивают, что такие идентификаторы могут быть развернуты только транзакциями типа 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.
Разработчики должны выполнять проверку прав доступа (например, с помощью ecrecover для восстановления адреса подписи) во время инициализации кошелька, когда они комбинируют EIP-7702 с существующим кошельком EIP-4337, чтобы избежать риска того, что операция инициализации кошелька будет перехвачена.
Управление хранилищем
При использовании функции делегирования 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 Ethereum. EIP-7702 вводит новый тип транзакций, позволяя EOA обладать программируемостью и композируемостью, размывая границы между EOA и контрактными счетами. Поскольку на данный момент нет стандарта смарт-контрактов, совместимого с EIP-7702, который прошел бы испытания в реальных условиях, различные участники экосистемы, такие как пользователи, провайдеры кошельков, разработчики, CEX и т.д., сталкиваются с множеством вызовов и возможностей в практическом применении. Описанные в статье лучшие практики не могут охватить все потенциальные риски, но все же стоят внимания для применения на практике.