Beosin: EIP-7702 и аудит безопасности кошельков AA нового поколения

Абстракция учетной записи (AA) — это важное направление долгосрочных исследований в экосистеме Ethereum, направленное на преодоление границы между внешними учетными записями (EOA) и контрактными счетами, чтобы кошелек обладал большей программируемостью, безопасностью и обновляемостью. EIP-4337 в настоящее время является наиболее распространенным решением для реализации AA и широко используется в ряде кошельков смарт-контрактов на основе EntryPoint (таких как Safe, Stacks и Argent). Тем не менее, EIP-4337 по-прежнему имеет определенные ограничения с точки зрения нативности в цепочке, операционной сложности и экологической совместимости из-за внедрения независимого пула транзакций и механизма контрактов на рампе.

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

В EIP-7702 представлен новый механизм «внедрения кода на уровне транзакции», который позволяет учетным записям пользователей динамически указывать логику выполнения в каждой транзакции, а не полагаться на предварительно развернутый код контракта. Это нарушает традиционную модель разрешений на основе статического кода, обеспечивает большую гибкость и создает новые проблемы безопасности: контракты, которые полагаются на логику суждений, такую как isContract и extcodehash, могут стать недействительными, а некоторые системы, которые предполагают, что вызывающий является чистым EOA, также могут быть обойдены. Для аудиторов важно не только проверить безопасность самого внедренного кода, но и оценить его потенциальное влияние на другие контрактные системы в динамическом контексте.

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

1. Введение в EIP-77021

. EIP-7702 Технический

обзорEIP-7702 вводит новый тип транзакции, 0x 04 (SetCode), который позволяет EOA авторизовать код контракта, который должен быть выполнен через эту транзакцию, со следующей структурой транзакции:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. назначение, значение, данные, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Если authorization_list содержит несколько списков авторизации, а также может содержать действия авторизации инициаторов, не являющихся инициаторами транзакций, внутренняя структура выглядит следующим образом:

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

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

После завершения авторизации система изменит поле кода авторизованного пользователя на 0x ef 0100 || address, где address — адрес авторизованного контракта. Если вы хотите отменить авторизацию, просто инициируйте транзакцию SetCode с адресом, равным 0.

2. Преимущества EIP 7702

(1) Гибкость и кастомизация

Абстрактные счетаПрописав логику учетной записи в смарт-контрактах, вы можете гибко настраивать функции в соответствии с вашими потребностями. Например, пользователи могут настроить мультиподпись, социальное восстановление и управление квотами в соответствии с потребностями отдельных лиц или предприятий в различных сценариях. Такая конструкция значительно улучшает функциональную масштабируемость учетной записи и преодолевает ограничения традиционных внешних учетных записей (EOA).

(2) Расширенная

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

(3) Учетная запись Gas Optimized

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

(4) Содействие популяризации Web3Оптимизируя

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

2. Анализ рисков безопасности в EIP-7702 на практике

Хотя EIP-7702 придал новый импульс экосистеме Ethereum и расширил множество сценариев применения, в то же время он неизбежно привнес некоторые новые риски безопасности:

1. Атака с воспроизведением авторизации

В соответствии с моделью EIP-7702, если пользователь авторизует chain_ Если в поле id задано значение 0, авторизация может вступить в силу для нескольких цепочек. Хотя такая «универсальная авторизация между цепочками» повышает гибкость в некоторых сценариях, она также создает очевидные риски для безопасности.

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

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

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

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

1) Совместимость обратного вызова контракта

переводе денег на адрес контракта для существующих контрактов токенов, таких как ERC-721, ERC-777 и ERC 1155, они будут вызывать стандартные интерфейсы обратного вызова (такие как onERC 721 Received, tokensReceived) для завершения операции перевода. Если адрес получателя не реализует соответствующий интерфейс, передача завершится ошибкой или даже приведет к блокировке актива.

В EIP-7702 адрес пользователя может быть преобразован в учетную запись контракта путем присвоения кода контракта с помощью операции «set_code». В этом случае:

• адрес пользователя считается договором;

• Если в контракте не будет реализован необходимый интерфейс обратного вызова, передача токена завершится ошибкой;

• Пользователи могут не иметь возможности получать основные токены без их ведома.

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

(2) Проверка "tx.origin" не пройденаВ

традиционных контрактах "tx.origin" часто используется для определения того, была ли транзакция непосредственно инициирована пользователем, и используется для предотвращения средств управления безопасностью, таких как вызовы контрактов.

Однако в сценарии EIP-7702

• пользователь подписывает транзакцию авторизации, а ретранслятор или сборщик транслирует ее от имени пользователя. Когда транзакция выполняется, "tx.origin" является адресом ретранслятора, а не адресом пользователя.

• "msg.sender" — это контракт кошелька, который представляет собой личность пользователя.

Следовательно, проверка разрешений на основе "tx.origin == msg.sender" приведет к тому, что законные пользовательские операции будут отклонены и потеряют надежность, а те же ограниченные вызовы контракта, такие как "tx.origin == user", также будут признаны недействительными. Рекомендуется отказаться от "tx.origin" в качестве основы для оценки безопасности и вместо этого использовать механизм проверки подписи или авторизации.

(3) "isContract" неправильно оцениваетМногие

контракты запрещают контрактным аккаунтам участвовать в определенных операциях, таких как аирдропы, флэш-продажи и т.д., через "isContract(address)":

require(!isContract(msg.sender), "Контракты не разрешены").

В соответствии с механизмом EIP-7702 адрес пользователя может быть изменен на контрактную учетную запись с помощью транзакции «set_code», а «isContract» возвращает true, и контракт ошибочно идентифицирует законного пользователя как контрактную учетную запись и отказывается участвовать в операции, в результате чего пользователь не сможет использовать определенные услуги, а опыт будет заблокирован.

С постепенной популяризацией контрактных кошельков, дизайн полагается на «isContract» для определения того, является ли «человек-пользователь» больше не безопасным, и рекомендуется использовать более точные методы идентификации пользователя, такие как проверка подписи.

3. Фишинговая атакаПосле

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

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

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

4. Риски, связанные с контрактом кошелька

( 1) Управление полномочиями по контракту кошелька

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

Рекомендации по безопасности

• : используйте мультиподпись, многофакторную аутентификацию или механизмы блокировки времени для управления повышением привилегий.

• Изменения кода и разрешений подлежат тщательному аудиту и проверке безопасности.

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

(2) Риск конфликтов хранения и изоляции данных,

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

Рекомендации по безопасности:

• Используйте специализированную схему изоляции хранилища, такую как стандарт EIP-1967, или используйте уникальное пространство имен для управления слотами хранилища.

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

• Тщательно проверяйте достоверность сохраненного состояния в процессе обновления.

(3) Управление одноразовым номером внутри кошелька

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

Рекомендация по безопасности:

• одноразовый номер должен быть принудительно проверен на эквивалентное значение (или приращение) и не может быть пропущен.

• Функциям запрещено напрямую изменять одноразовый номер, и одноразовый номер будет обновляться только при выполнении пользовательской операции.

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

(4) Проверка разрешений вызывающего функциюЧтобы

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

• подписание вне сети разрешает

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

• call constraint (msg.sender == address(this))

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

3. Перспективы: Предложение EIP-7702 и будущего стандарта кошельков AA

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

1. Совместная эволюция с EIP-4337: на пути к двухрежимной совместимостиХотя

EIP-7702 и EIP-4337 имеют разные цели проектирования, первый реконструирует механизм загрузки кода учетной записи, а второй создает полную экосистему ввода транзакций и упаковки. Тем не менее, они не противоречат друг другу, а имеют сильную взаимодополняемость:

● EIP-4337 предоставляет «общий канал транзакций» и «абстрактный интерфейс выполнения учетных записей»;

● EIP-7702 позволяет учетным записям пользователей динамически предоставлять возможности логики контракта без изменения адреса;

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

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

2. Поддержка и вдохновение для новой логики кошельков, таких как MPC и ZK, а

также механизм контракта учетной записи, пропагандируемый EIP-7702, имеет естественный потенциал интеграции с нынешним популярным кошельком MPC, кошельком ZK, модульным кошельком и другими новыми архитектурами:

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

● Кошелек ZK проверяет личность пользователя или авторизацию с помощью доказательств с нулевым разглашением, не раскрывая информацию о закрытом ключе. В сочетании с EIP-7702 кошельки ZK могут временно внедрять определенные логические контракты после завершения проверки, чтобы реализовать развертывание персонализированного поведения после конфиденциальных вычислений, например, автоматически выполнять определенную логику только после выполнения определенных условий конфиденциальности.

● Модульные кошельки могут использовать EIP-7702 для разборки логики учетной записи на несколько модулей и динамической загрузки их при необходимости.

Таким образом, EIP-7702 предоставляет более нативный «контейнер выполнения» для вышеупомянутых продвинутых кошельков: различная логика контракта может быть внедрена с одним и тем же адресом пользователя, что позволяет избежать проблемы зависимости адресов в традиционном процессе развертывания контракта и устраняет необходимость в предварительном развертывании, что значительно повышает гибкость и комбинацию поведения учетной записи.

3. Последствия для контрактных разработчиков и

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

• введения более строгой проверки вызывающих абонентов и логики суждения о разрешениях;

• Проверьте, влияет ли на путь вызова логика динамического контракта;

• определить потенциальные уязвимости, которые зависят от поведения, такого как msg.sender.code.length == 0, isContract() и т. д.;

• Уточнение «контекстных зависимостей» логики контракта, таких как контроль границ статических вызовов и делегированных вызовов;

• На уровне набора инструментов поддерживается моделирование и анализ откатов сценариев setCode.

Другими словами, безопасность кода — это уже не просто «проблема перед развертыванием», а «динамический процесс, который должен быть проверен во время вызова и транзакции».

4.

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

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