Beosin: аналіз аудиту безпеки EIP-7702 та гаманця AA нового покоління

Абстракція облікових записів (AA) є важливим напрямком довгострокових досліджень в екосистемі Ethereum, спрямованих на подолання межі між зовнішніми обліковими записами (EOA) і контрактними обліковими записами, щоб гаманець мав сильнішу програмованість, безпеку та можливість оновлення. EIP-4337 в даний час є найбільш поширеним рішенням для впровадження АА і широко використовується в ряді гаманців смарт-контрактів на основі 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-7702EIP-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 являє собою ланцюжок, в якому відбувається авторизація користувача, а його значення має дорівнювати ID ланцюга ланцюга, що виконується, або 0. Коли chain_id дорівнює 0, авторизація набуває чинності для всіх ланцюгів EVM, які підтримують EIP-7702, але тільки в тому випадку, якщо інші параметри (наприклад, nonce) збігаються. Address вказує цільову адресу контракту, авторизовану користувачем.

Після завершення авторизації система змінить поле коду авторизованого користувача на адресу 0x ef 0100 ||, де address – адреса авторизованого договору. Якщо ви хочете деавторизуватися, просто ініціюйте транзакцію SetCode з адресою, встановленою на 0.

2. Переваги EIP 7702

(1) Гнучкість і кастомізація

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

(2) Облікові

записи Enhanced SecurityAbstract забезпечують багаторівневий механізм безпеки, включаючи багатофакторну автентифікацію, ліміти транзакцій і соціальне відновлення. Навіть якщо користувач втратить свій приватний ключ, він може відновити свій обліковий запис за допомогою довірених контактів або багатофакторної автентифікації, уникаючи незворотної втрати активів, спричиненої втратою приватного ключа в традиційних облікових записах. У той же час такі функції, як контроль лімітів, також можуть запобігти зловмисному крадіжці великих сум коштів.

(3) Обліковий запис оптимізованої

абстракції газу підтримує гнучкий механізм забору газу, що дозволяє користувачам платити за газ через третю сторону і навіть безпосередньо використовувати інші токени для оплати комісій за транзакції. Цей механізм не тільки знижує вартість роботи користувачів, але й ще більше спрощує використання блокчейну, особливо підходить для початківців користувачів або складних багатоетапних сценаріїв транзакцій.

(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), "Contracts not allowed"

). Згідно з механізмом 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 всередині та керує собою, щоб забезпечити порядок виконання операцій користувача та запобігти атакам повторного відтворення. Якщо nonce використовується неправильно, операція користувача не буде виконана належним чином.

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

• nonce має бути примусово перевірено на еквівалентне значення (або приріст), і його не можна пропустити.

• Для функцій заборонено безпосередньо змінювати nonce, і nonce буде оновлено лише тоді, коли виконується операція користувача.

• Розробіть механізми відмовостійкості та відновлення для винятків nonce, щоб уникнути глухих кутів nonce.

(4) Перевірка дозволів виклику функціїЗ

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

• підписування поза ланцюгом дозволяє

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

• обмеженням виклику (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.

представляє більш легку, рідну та гнучку реалізацію Account Abstraction (AA), завдяки чому звичайний EOA може нести логіку контракту та виконувати його в одній транзакції. Цей механізм ламає традиційні статичні припущення про поведінку облікового запису, і розробники більше не можуть просто покладатися на стан коду адреси облікового запису, щоб судити про його модель поведінки, а повинні реконструювати розуміння ідентичності та межі повноважень абонента.

З цим відбувається зміна парадигми в аналітиці безпеки. Основна увага аудиту більше не обмежується тим, «чи має адреса дозволи», а тим, «що може зробити логіка контракту, закладена в транзакції, в поточному контексті». Кожна транзакція може нести незалежне визначення поведінки, що надає обліковому запису більшу функціональність і висуває більш високі вимоги до аудиту безпеки.