Абрстракція рахунку (Account Abstraction, AA) є важливим напрямком довгострокового дослідження в екосистемі Ethereum, що має на меті зламати межі між зовнішніми рахунками (EOA) та контрактними рахунками, надаючи гаманцям більшу програмованість, безпеку та можливість оновлення. EIP-4337, як найпоширеніша реалізація AA, вже активно використовується в ряді смарт-контрактних гаманців на базі EntryPoint (таких як Safe, Stacks, Argent). Однак EIP-4337 має певні обмеження в плані рідності на ланцюгу, складності операцій та екологічної сумісності через впровадження незалежного пулу транзакцій та механізму вхідного контракту.
Для подальшого зниження бар'єрів використання абстракцій облікових записів та посилення їхньої рідної підтримки, Віталік у 2024 році запропонував EIP-7702 і включив цю пропозицію в оновлення Pectra. Основна ідея EIP-7702 полягає в тому, що дозволяє вихідному EOA під час ініціювання транзакції виконувати код контракту (contract_code) за вказаною адресою, визначаючи логіку виконання цієї транзакції за допомогою цього коду.
EIP-7702 вводить новий механізм «ін'єкції коду на рівні транзакції», який дозволяє обліковим записам користувачів динамічно вказувати логіку виконання в кожній транзакції, а не покладатися на попередньо розгорнутий код контракту. Це порушує традиційну статичну модель дозволів на основі коду, забезпечує більшу гнучкість і створює нові проблеми безпеки: контракти, які покладаються на логіку судження, такі як isContract і extcodehash, можуть стати недійсними, а деякі системи, які припускають, що абонент є чистим EOA, можуть бути обійдені. Для аудиторів важливо не тільки перевірити безпеку самого введеного коду, а й оцінити його потенційний вплив на інші контрактні системи в динамічному контексті.
У цій статті команда безпеки Beosin системно розгляне принципи дизайну та ключові особливості EIP-7702, а також можливі ризики безпеки, з якими може зіштовхнутися AA-гаманець, побудований на його основі, під час аудиту. На основі практичного досвіду будуть запропоновані процеси аудиту та рекомендації, щоб допомогти дослідникам безпеки краще впоратися з технічними викликами в рамках цієї нової парадигми.
Вступ до EIP-7702
Огляд технології EIP-7702
EIP-7702 вводить новий тип транзакцій 0x04 (SetCode), який дозволяє EOA авторизувати код контракту, який потрібно виконати за допомогою цієї транзакції. Структура транзакції така:
У списку authorization_list міститься кілька списків авторизації, також можуть бути дії авторизації, що не ініційовані учасником угоди, внутрішня структура така:
У цьому випадку chain_id означає ланцюг, на якому активується авторизація користувача, і його значення повинно дорівнювати ID ланцюга виконання або бути рівним 0. Коли chain_id дорівнює 0, це означає, що авторизація діє для всіх EVM-ланцюгів, які підтримують EIP-7702, за умови, що інші параметри (наприклад, nonce) також відповідають. Address означає адресу цільового контракту, на яку надається авторизація користувача.
Після завершення авторизації система змінить поле code авторизованого користувача на 0xef0100 || address, де address є адресою контракту, що підлягає авторизації. Якщо ви хочете скасувати авторизацію, просто ініціюйте транзакцію SetCode, встановивши address на адресу 0.
Переваги EIP7702
(1) Гнучкість та налаштування
Абстрактні облікові записи можуть гнучко налаштовувати функціональність відповідно до потреб, записуючи логіку облікового запису в смарт-контракти. Наприклад, користувачі можуть налаштувати мультипідпис, соціальне відновлення та контроль квот для задоволення потреб окремих осіб або підприємств у різних сценаріях. Такий дизайн значно покращує функціональну масштабованість облікового запису та долає обмеження традиційних зовнішніх облікових записів (EOA).
(2) підвищити безпеку
Абстрактні облікові записи забезпечують кілька рівнів безпеки, включаючи багатофакторну автентифікацію, ліміти транзакцій і соціальне відновлення. Навіть якщо користувач втратить свій приватний ключ, він може відновити свій обліковий запис за допомогою довірених контактів або багатофакторної автентифікації, уникаючи незворотної втрати активів, спричиненої втратою приватного ключа в традиційних облікових записах. У той же час такі функції, як контроль лімітів, також можуть запобігти зловмисному крадіжці великих сум коштів.
(3) Газ оптимізація
Абстрактні рахунки підтримують гнучкий механізм абстракції Gas, що дозволяє користувачам сплачувати Gas через третіх осіб, або навіть безпосередньо використовувати інші токени для оплати комісій за транзакції. Цей механізм не лише знижує витрати користувачів, але й ще більше спрощує процес використання блокчейну, особливо підходить для новачків або складних багатоступеневих торгових сценаріїв.
( Сприяння поширенню Web3
Оптимізуючи досвід і безпеку, абстрактні облікові записи приховують складність блокчейну в місцях, які не видно користувачеві, забезпечуючи зручнішу роботу, схожу на Web2. Такий дизайн знижує витрати на навчання для звичайних користувачів, дозволяючи більшій кількості людей безперешкодно брати участь у Web3 додатках, що сприяє поширенню децентралізованих технологій.
Друге, аналіз безпекових ризиків EIP-7702 на практиці
Хоча EIP-7702 вніс нову енергію в екосистему Ethereum і розширив різноманітні можливості застосування, водночас він також неминуче впровадив деякі нові ризики безпеки:
Атака з повторним використанням авторизації
У моделі EIP-7702, якщо користувач встановлює значення поля chain_id в 0, це означає, що цей дозвіл може бути дійсним на кількох ланцюгах. Цей дизайн «крос-ланцюгового загального дозволу» хоч і підвищує гнучкість у певних сценаріях, але водночас вводить очевидні ризики безпеки.
Важливо відзначити, що навіть якщо ідентичність облікового запису однієї і тієї ж адреси в різних ланцюгах однакова, реалізація контракту, що стоїть за нею, може бути абсолютно різною. Це означає, що зловмисник може розгорнути шкідливу версію контракту в іншому ланцюжку та виконати непередбачені дії, використовуючи авторизацію тієї ж адреси в ланцюжку, тим самим створюючи ризик для активів користувача.
Отже, для постачальників послуг гаманців або платформ переднього зв'язку, під час здійснення користувачами таких авторизаційних операцій, необхідно чітко перевіряти, чи збігається заявлений у авторизації chainId з поточною підключеною мережею; якщо виявлено, що користувач встановив chainId на 0, слід надати чітке повідомлення про ризики, попереджаючи користувача, що ця авторизація буде діяти на всіх EVM-сумісних блокчейнах і може бути зловживана зловмисними контрактами.
Крім того, постачальник послуг також повинен оцінити, чи обмежувати або забороняти авторизацію з chainId 0 за замовчуванням на рівні інтерфейсу користувача, щоб зменшити ризик неправильної роботи або фішингових атак.
Проблеми сумісності контрактів
)1( Сумісність зворотного виклику контракту
Існуючі контракти на токени, такі як ERC-721, ERC-777 і ERC1155, будуть викликати стандартні інтерфейси зворотного виклику (такі як onERC721Received, tokensReceived) для завершення операції переказу при переказі грошей на адресу контракту. Якщо в адресі отримання не реалізовано відповідний інтерфейс, переказ не вдасться або навіть призведе до блокування активу.
У EIP-7702 адреси користувачів можуть бути надані кодом контракту через операцію «set_code», що перетворює їх на рахунки контрактів. У цей момент:
Адреса користувача буде розглядатися як контракт;
Якщо цей контракт не реалізує необхідний інтерфейс зворотного виклику, це призведе до невдачі переказу токенів;
Користувачі можуть не усвідомлювати, що не можуть отримати основні токени.
Отже, розробники повинні забезпечити реалізацію відповідних інтерфейсів зворотного виклику для цільового контракту, делегованого користувачами, щоб забезпечити сумісність з основними токенами.
)2( "tx.origin" валідація не працює
У традиційних контрактах «tx.origin» часто використовується для визначення, чи була транзакція ініційована безпосередньо користувачем, щоб запобігти викликам контрактів та іншим заходам безпеки.
Але в контексті EIP-7702:
Користувач підписує авторизацію на транзакцію, фактично її транслює ретранслятор або служба пакування (bundler); під час виконання транзакції «tx.origin» є адресою ретранслятора, а не адресою користувача.
«msg.sender» є контрактом гаманця, що представляє особу користувача.
Таким чином, перевірка дозволів на основі "tx.origin == msg.sender" призведе до того, що законні операції користувача будуть відхилені та втратять надійність, а ті самі обмежені виклики контракту, такі як "tx.origin == user", також будуть визнані недійсними. Рекомендується відмовитися від "tx.origin" як основи для судження про безпеку та використовувати замість цього механізм перевірки підпису або авторизації.
)3( «isContract» помилкове визначення
Багато контрактів запобігають участі контрактних рахунків у певних операціях, таких як аерозольні розподіли, покупки тощо, через «isContract )address(» (перевірка довжини коду адреси):
У механізмі EIP-7702 адреси користувачів можуть перетворюватися на контракти через транзакцію «set_code», «isContract» повертає true, контракт неправильно визначає законного користувача як контрактний рахунок, відмовляючи йому в участі в операціях, що призводить до того, що користувач не може використовувати деякі послуги, що заважає досвіду.
З розвитком контрактних гаманців залежність від «isContract» для визначення «чи є це людиною» більше не є безпечною, рекомендовано використовувати підписну верифікацію та інші більш точні способи ідентифікації користувачів.
Фішинг-атака
Після впровадження механізму делегування EIP-7702 активи в обліковому записі користувача будуть повністю контролюватися делегованим смарт-контрактом. Після того, як користувач авторизує шкідливий контракт, зловмисник може отримати повний контроль над активами облікового запису, що призведе до швидкого переказу або крадіжки коштів, що є надзвичайно ризикованим.
Тому важливо, щоб постачальники послуг гаманців якнайшвидше підтримували механізми вирішення транзакцій EIP-7702 та виявлення ризиків. Коли користувач підписує транзакцію довірення, інтерфейс повинен чітко та помітно відображати цільову адресу контракту та поєднувати допоміжну інформацію, таку як джерело контракту та інформація про розгортання, щоб допомогти користувачам виявити потенційні фішингові або шахрайські дії, тим самим знижуючи ризик неправильного підписання. Крім того, сервіс гаманця повинен інтегрувати можливості автоматизованого аналізу безпеки для цільового контракту, такі як перевірка статусу відкритого вихідного коду контракту, аналіз моделі дозволів та ідентифікація потенційно небезпечних операцій, щоб допомогти користувачам робити більш безпечні судження перед авторизацією.
Зокрема, EIP-7702 вводить формат делегованого підпису, несумісний з існуючими стандартами підпису EIP-191 та EIP-712. Його підпис може легко обійти оригінальне попередження про підпис і запит на взаємодію гаманця, що ще більше збільшує ризик того, що користувачі будуть обмануті для підписання шкідливих операцій. Тому впровадження механізму ідентифікації та обробки структури підпису в реалізацію гаманця стане ключовою ланкою для забезпечення безпеки користувачів.
Ризики контракту гаманця
)1( Управління правами контракту гаманця
Багато гаманців EIP-7702 використовують проксі-архітектуру ) або вбудовані адміністративні права ( для підтримки логічних оновлень. Однак це також призводить до підвищеного ризику управління правами. Якщо права на оновлення не будуть строго обмежені, зловмисники можуть замінити реалізацію контракту та ввести шкідливий код, що призведе до змін у рахунках користувачів або крадіжки коштів.
Рекомендації з безпеки:
Використання мультипідписів, багатофакторної автентифікації або механізму тайм-лок для контролю прав на оновлення.
Зміни в коді та дозволах повинні проходити суворий аудит та перевірку безпеки.
Відкритий і прозорий процес оновлення, що гарантує право користувачів на інформацію та участь.
)2( ризик конфлікту зберігання та ізоляція даних
Версії контрактів гаманців або різні постачальники послуг гаманців можуть повторно використовувати однакові слоти пам'яті (storage slot). Якщо користувач змінює постачальника послуг гаманців або оновлює логіку гаманця, повторне використання слотів пам'яті може призвести до конфлікту змінних стану, виникнення проблем з перезаписом даних, читанням тощо. Це не тільки може порушити нормальну функцію гаманця, але й призвести до втрати коштів або аномалій у правах.
Рекомендації з безпеки:
Використовуйте спеціалізовані рішення для ізоляції сховища (такі як стандарт EIP-1967) або використовуйте унікальне простір імен для управління слотами сховища.
При оновленні контракту переконайтеся, що зберігання сумісне, уникайте перекриття змінних.
Суворе тестування обґрунтованості стану зберігання під час процесу оновлення.
) Управління nonce всередині гаманця
Гаманець контрактів зазвичай має внутрішнє налаштування nonce та здійснює його самостійне управління, щоб забезпечити порядок виконання операцій користувача та запобігти атакам повтору. Якщо nonce використовується неналежним чином, це призведе до того, що операції користувача не можуть бути виконані належним чином.
Рекомендації з безпеки:
nonce повинен бути строго рівним (або зростаючим), не можна пропускати.
Заборонено безпосередньо змінювати nonce функцією, він повинен оновлюватися тільки під час виконання дій користувача.
Розробка механізмів відмовостійкості та відновлення для аномальних ситуацій з nonce, щоб уникнути мертвих блоків nonce.
(4) Перевірка прав виклику функції
Щоб забезпечити безпеку, контракт гаманця повинен гарантувати, що викликачі ключових функцій є обліковими записами власників гаманця. Два поширених способи включають:
Офлайн-підпис авторизації
Користувач підписує набір операцій за допомогою приватного ключа, а смарт-контракт гаманця на ланцюгу перевіряє, чи є підпис дійсним, чи не протермінований, чи відповідає відповідному nonce. Цей спосіб підходить для моделі релейних транзакцій, запропонованої EIP-7702 (офлайн-підпис користувача + транзакції, що відправляються релеєм).
Виклик обмеження (msg.sender == адреса (this))
Функцію дії користувача дозволено запускати лише самим контрактом, який, по суті, є механізмом контролю шляху виклику, гарантуючи, що зовнішнім ініціатором має бути сам обліковий запис. Це фактично еквівалентно вимозі від абонента бути оригінальним EOA, оскільки адреса контракту є адресою EOA.
Третє. Перспективи: EIP-7702 та майбутній стандарт AA гаманців
Запровадження EIP-7702 є не лише революцією традиційної моделі облікових записів, але й значним поштовхом для екосистеми абстракції облікових записів (Account Abstraction). Його можливість завантажувати код контракту користувачами відкриває широкі можливості для майбутнього дизайну гаманців та системи контрактів, а також ставить нові вимоги до стандартів безпеки аудиту.
Спільна еволюція з EIP-4337: перехід до бімодальної сумісності
Хоча EIP-7702 і EIP-4337 мають різні цілі в дизайні, перший реорганізовує механізм завантаження коду рахунків, а другий будує повний вхід для транзакцій і екосистему пакування. Але обидва не конфліктують, а навпаки, мають сильну взаємодоповнювальність:
EIP-4337 надає "універсальний торговий канал" та "інтерфейс виконання абстрактних облікових записів";
EIP-7702 дозволяє користувацьким обліковим записам динамічно на赋увати контрактну логіку без зміни адреси;
Отже, у майбутньому гаманці можуть використовувати «двомодну підтримувальну архітектуру»: на ланцюгах, які не підтримують EIP-4337, використовувати EIP-7702 як легковаговий аналог, а в сценаріях, де потрібне упаковування поза ланцюгом та агрегація кількох користувачів, продовжувати покладатися на повний стек протоколу EIP-4337.
Цей двомодальний механізм також сприятиме тому, щоб гаманці на ядерному рівні підтримували більш гнучку модель прав облікових записів, механізм деградації та плани відкату.
Підтримка та натхнення нових логік гаманців, таких як MPC, ZK тощо
Механізм контрактних рахунків, запропонований EIP-7702, має природний потенціал для інтеграції з новими структурами, такими як популярні сьогодні гаманці MPC, гаманці ZK, модульні гаманці тощо:
У режимі MPC підписувальна поведінка більше не залежить від єдиного приватного ключа, а є результатом спільного рішення багатьох сторін. Підписи, згенеровані шляхом інтеграції EIP-7702 та MPC, можуть контролювати логіку контрактів, що динамічно завантажуються, що дозволяє реалізувати більш гнучкі стратегії виконання.
Гаманець ZK перевіряє особистість або авторизацію користувача за допомогою нульових знань, не розкриваючи інформацію про приватні ключі. Після впровадження EIP-7702 гаманець ZK може тимчасово вводити специфічні логічні контракти після завершення перевірки, що дозволяє реалізувати персоналізовані дії після обчислень конфіденційності, наприклад, автоматичне виконання певної логіки тільки після виконання певних умов конфіденційності.
Модульні гаманці (Modular Wallets) можуть використовувати EIP-7702 для розділення логіки облікового запису на кілька модулів, які можуть динамічно завантажуватися за потреби.
Таким чином, EIP-7702 надає більш рідний «контейнер виконання» для вищезазначених розширених гаманців: різна логіка контракту може бути введена з однією і тією ж адресою користувача, що дозволяє уникнути проблеми залежності адреси в традиційному процесі розгортання контрактів, і немає необхідності в попередньому розгортанні, що значно покращує гнучкість і можливість комбінування поведінки облікового запису.
Прозорість для розробників контрактів та аудиторів
EIP-7702 призведе до глибоких змін у парадигмі розробки. Розробники контрактів більше не просто розглядають абонента як традиційний EOA або фіксований контрактний обліковий запис, а повинні адаптуватися до нового механізму: особистість абонента може динамічно перемикатися між EOA та статусом контракту під час транзакції, а логіка поведінки облікового запису більше не є статично закріпленою, а може бути гнучко змінена відповідно до вимоги. Це вимагає від розробників та аудиторів:
Введення більш жорсткої логіки верифікації виклику та перевірки прав;
Перевірте, чи впливає логіка динамічного контракту на шлях виклику;
Визначити потенційні вразливості поведінки, такі як msg.sender.code.length == 0, isContract () тощо;
Ясно визначити логіку контракту «залежність від контексту», наприклад, контроль меж статичних викликів, deleGatecall;
Підтримка моделювання та відновлювального аналізу сценаріїв setCode на рівні інструментального ланцюга.
Іншими словами, безпека коду більше не є просто «проблемою перед розгортанням», а стала «динамічним процесом, який також потрібно перевіряти під час виклику та транзакції».
Чотири, підсумок
EIP-7702 представляє легшу, ріднішу та гнучкішу реалізацію Account Abstraction (AA), яка дозволяє звичайному EOA передавати логіку контракту та виконувати її в одній транзакції. Цей механізм ламає традиційні статичні припущення про поведінку облікового запису, і розробники більше не можуть просто покладатися на стан коду адреси облікового запису, щоб судити про його модель поведінки, а повинні реконструювати розуміння ідентичності та межі повноважень абонента. З цим відбувається зміна парадигми в аналітиці безпеки. Фокус аудиту більше не обмежується тим, «чи має адреса дозволи», а зміщується на те, «що може зробити логіка контракту, що міститься в транзакції, в поточному контексті». Кожна транзакція може нести незалежне визначення поведінки, що надає обліковому запису більшу функціональність і висуває більш високі вимоги до аудиту безпеки.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Beosin: EIP-7702 та аналіз безпеки следующих поколінь Гаманець
Автор: Beosin
Абрстракція рахунку (Account Abstraction, AA) є важливим напрямком довгострокового дослідження в екосистемі Ethereum, що має на меті зламати межі між зовнішніми рахунками (EOA) та контрактними рахунками, надаючи гаманцям більшу програмованість, безпеку та можливість оновлення. EIP-4337, як найпоширеніша реалізація AA, вже активно використовується в ряді смарт-контрактних гаманців на базі EntryPoint (таких як Safe, Stacks, Argent). Однак EIP-4337 має певні обмеження в плані рідності на ланцюгу, складності операцій та екологічної сумісності через впровадження незалежного пулу транзакцій та механізму вхідного контракту.
Для подальшого зниження бар'єрів використання абстракцій облікових записів та посилення їхньої рідної підтримки, Віталік у 2024 році запропонував EIP-7702 і включив цю пропозицію в оновлення Pectra. Основна ідея EIP-7702 полягає в тому, що дозволяє вихідному EOA під час ініціювання транзакції виконувати код контракту (contract_code) за вказаною адресою, визначаючи логіку виконання цієї транзакції за допомогою цього коду.
EIP-7702 вводить новий механізм «ін'єкції коду на рівні транзакції», який дозволяє обліковим записам користувачів динамічно вказувати логіку виконання в кожній транзакції, а не покладатися на попередньо розгорнутий код контракту. Це порушує традиційну статичну модель дозволів на основі коду, забезпечує більшу гнучкість і створює нові проблеми безпеки: контракти, які покладаються на логіку судження, такі як isContract і extcodehash, можуть стати недійсними, а деякі системи, які припускають, що абонент є чистим EOA, можуть бути обійдені. Для аудиторів важливо не тільки перевірити безпеку самого введеного коду, а й оцінити його потенційний вплив на інші контрактні системи в динамічному контексті.
У цій статті команда безпеки Beosin системно розгляне принципи дизайну та ключові особливості EIP-7702, а також можливі ризики безпеки, з якими може зіштовхнутися AA-гаманець, побудований на його основі, під час аудиту. На основі практичного досвіду будуть запропоновані процеси аудиту та рекомендації, щоб допомогти дослідникам безпеки краще впоратися з технічними викликами в рамках цієї нової парадигми.
Вступ до EIP-7702
Огляд технології EIP-7702
EIP-7702 вводить новий тип транзакцій 0x04 (SetCode), який дозволяє EOA авторизувати код контракту, який потрібно виконати за допомогою цієї транзакції. Структура транзакції така:
У списку authorization_list міститься кілька списків авторизації, також можуть бути дії авторизації, що не ініційовані учасником угоди, внутрішня структура така:
У цьому випадку chain_id означає ланцюг, на якому активується авторизація користувача, і його значення повинно дорівнювати ID ланцюга виконання або бути рівним 0. Коли chain_id дорівнює 0, це означає, що авторизація діє для всіх EVM-ланцюгів, які підтримують EIP-7702, за умови, що інші параметри (наприклад, nonce) також відповідають. Address означає адресу цільового контракту, на яку надається авторизація користувача.
Після завершення авторизації система змінить поле code авторизованого користувача на 0xef0100 || address, де address є адресою контракту, що підлягає авторизації. Якщо ви хочете скасувати авторизацію, просто ініціюйте транзакцію SetCode, встановивши address на адресу 0.
(1) Гнучкість та налаштування
Абстрактні облікові записи можуть гнучко налаштовувати функціональність відповідно до потреб, записуючи логіку облікового запису в смарт-контракти. Наприклад, користувачі можуть налаштувати мультипідпис, соціальне відновлення та контроль квот для задоволення потреб окремих осіб або підприємств у різних сценаріях. Такий дизайн значно покращує функціональну масштабованість облікового запису та долає обмеження традиційних зовнішніх облікових записів (EOA).
(2) підвищити безпеку
Абстрактні облікові записи забезпечують кілька рівнів безпеки, включаючи багатофакторну автентифікацію, ліміти транзакцій і соціальне відновлення. Навіть якщо користувач втратить свій приватний ключ, він може відновити свій обліковий запис за допомогою довірених контактів або багатофакторної автентифікації, уникаючи незворотної втрати активів, спричиненої втратою приватного ключа в традиційних облікових записах. У той же час такі функції, як контроль лімітів, також можуть запобігти зловмисному крадіжці великих сум коштів.
(3) Газ оптимізація
Абстрактні рахунки підтримують гнучкий механізм абстракції Gas, що дозволяє користувачам сплачувати Gas через третіх осіб, або навіть безпосередньо використовувати інші токени для оплати комісій за транзакції. Цей механізм не лише знижує витрати користувачів, але й ще більше спрощує процес використання блокчейну, особливо підходить для новачків або складних багатоступеневих торгових сценаріїв.
( Сприяння поширенню Web3
Оптимізуючи досвід і безпеку, абстрактні облікові записи приховують складність блокчейну в місцях, які не видно користувачеві, забезпечуючи зручнішу роботу, схожу на Web2. Такий дизайн знижує витрати на навчання для звичайних користувачів, дозволяючи більшій кількості людей безперешкодно брати участь у Web3 додатках, що сприяє поширенню децентралізованих технологій.
Друге, аналіз безпекових ризиків EIP-7702 на практиці
Хоча EIP-7702 вніс нову енергію в екосистему Ethereum і розширив різноманітні можливості застосування, водночас він також неминуче впровадив деякі нові ризики безпеки:
У моделі EIP-7702, якщо користувач встановлює значення поля chain_id в 0, це означає, що цей дозвіл може бути дійсним на кількох ланцюгах. Цей дизайн «крос-ланцюгового загального дозволу» хоч і підвищує гнучкість у певних сценаріях, але водночас вводить очевидні ризики безпеки.
Важливо відзначити, що навіть якщо ідентичність облікового запису однієї і тієї ж адреси в різних ланцюгах однакова, реалізація контракту, що стоїть за нею, може бути абсолютно різною. Це означає, що зловмисник може розгорнути шкідливу версію контракту в іншому ланцюжку та виконати непередбачені дії, використовуючи авторизацію тієї ж адреси в ланцюжку, тим самим створюючи ризик для активів користувача.
Отже, для постачальників послуг гаманців або платформ переднього зв'язку, під час здійснення користувачами таких авторизаційних операцій, необхідно чітко перевіряти, чи збігається заявлений у авторизації chainId з поточною підключеною мережею; якщо виявлено, що користувач встановив chainId на 0, слід надати чітке повідомлення про ризики, попереджаючи користувача, що ця авторизація буде діяти на всіх EVM-сумісних блокчейнах і може бути зловживана зловмисними контрактами.
Крім того, постачальник послуг також повинен оцінити, чи обмежувати або забороняти авторизацію з chainId 0 за замовчуванням на рівні інтерфейсу користувача, щоб зменшити ризик неправильної роботи або фішингових атак.
)1( Сумісність зворотного виклику контракту
Існуючі контракти на токени, такі як ERC-721, ERC-777 і ERC1155, будуть викликати стандартні інтерфейси зворотного виклику (такі як onERC721Received, tokensReceived) для завершення операції переказу при переказі грошей на адресу контракту. Якщо в адресі отримання не реалізовано відповідний інтерфейс, переказ не вдасться або навіть призведе до блокування активу.
У EIP-7702 адреси користувачів можуть бути надані кодом контракту через операцію «set_code», що перетворює їх на рахунки контрактів. У цей момент:
Адреса користувача буде розглядатися як контракт;
Якщо цей контракт не реалізує необхідний інтерфейс зворотного виклику, це призведе до невдачі переказу токенів;
Користувачі можуть не усвідомлювати, що не можуть отримати основні токени.
Отже, розробники повинні забезпечити реалізацію відповідних інтерфейсів зворотного виклику для цільового контракту, делегованого користувачами, щоб забезпечити сумісність з основними токенами.
)2( "tx.origin" валідація не працює
У традиційних контрактах «tx.origin» часто використовується для визначення, чи була транзакція ініційована безпосередньо користувачем, щоб запобігти викликам контрактів та іншим заходам безпеки. Але в контексті EIP-7702:
Користувач підписує авторизацію на транзакцію, фактично її транслює ретранслятор або служба пакування (bundler); під час виконання транзакції «tx.origin» є адресою ретранслятора, а не адресою користувача.
«msg.sender» є контрактом гаманця, що представляє особу користувача.
Таким чином, перевірка дозволів на основі "tx.origin == msg.sender" призведе до того, що законні операції користувача будуть відхилені та втратять надійність, а ті самі обмежені виклики контракту, такі як "tx.origin == user", також будуть визнані недійсними. Рекомендується відмовитися від "tx.origin" як основи для судження про безпеку та використовувати замість цього механізм перевірки підпису або авторизації.
)3( «isContract» помилкове визначення
Багато контрактів запобігають участі контрактних рахунків у певних операціях, таких як аерозольні розподіли, покупки тощо, через «isContract )address(» (перевірка довжини коду адреси):
У механізмі EIP-7702 адреси користувачів можуть перетворюватися на контракти через транзакцію «set_code», «isContract» повертає true, контракт неправильно визначає законного користувача як контрактний рахунок, відмовляючи йому в участі в операціях, що призводить до того, що користувач не може використовувати деякі послуги, що заважає досвіду. З розвитком контрактних гаманців залежність від «isContract» для визначення «чи є це людиною» більше не є безпечною, рекомендовано використовувати підписну верифікацію та інші більш точні способи ідентифікації користувачів.
Після впровадження механізму делегування EIP-7702 активи в обліковому записі користувача будуть повністю контролюватися делегованим смарт-контрактом. Після того, як користувач авторизує шкідливий контракт, зловмисник може отримати повний контроль над активами облікового запису, що призведе до швидкого переказу або крадіжки коштів, що є надзвичайно ризикованим.
Тому важливо, щоб постачальники послуг гаманців якнайшвидше підтримували механізми вирішення транзакцій EIP-7702 та виявлення ризиків. Коли користувач підписує транзакцію довірення, інтерфейс повинен чітко та помітно відображати цільову адресу контракту та поєднувати допоміжну інформацію, таку як джерело контракту та інформація про розгортання, щоб допомогти користувачам виявити потенційні фішингові або шахрайські дії, тим самим знижуючи ризик неправильного підписання. Крім того, сервіс гаманця повинен інтегрувати можливості автоматизованого аналізу безпеки для цільового контракту, такі як перевірка статусу відкритого вихідного коду контракту, аналіз моделі дозволів та ідентифікація потенційно небезпечних операцій, щоб допомогти користувачам робити більш безпечні судження перед авторизацією.
Зокрема, EIP-7702 вводить формат делегованого підпису, несумісний з існуючими стандартами підпису EIP-191 та EIP-712. Його підпис може легко обійти оригінальне попередження про підпис і запит на взаємодію гаманця, що ще більше збільшує ризик того, що користувачі будуть обмануті для підписання шкідливих операцій. Тому впровадження механізму ідентифікації та обробки структури підпису в реалізацію гаманця стане ключовою ланкою для забезпечення безпеки користувачів.
)1( Управління правами контракту гаманця
Багато гаманців EIP-7702 використовують проксі-архітектуру ) або вбудовані адміністративні права ( для підтримки логічних оновлень. Однак це також призводить до підвищеного ризику управління правами. Якщо права на оновлення не будуть строго обмежені, зловмисники можуть замінити реалізацію контракту та ввести шкідливий код, що призведе до змін у рахунках користувачів або крадіжки коштів.
Рекомендації з безпеки:
Використання мультипідписів, багатофакторної автентифікації або механізму тайм-лок для контролю прав на оновлення.
Зміни в коді та дозволах повинні проходити суворий аудит та перевірку безпеки.
Відкритий і прозорий процес оновлення, що гарантує право користувачів на інформацію та участь.
)2( ризик конфлікту зберігання та ізоляція даних
Версії контрактів гаманців або різні постачальники послуг гаманців можуть повторно використовувати однакові слоти пам'яті (storage slot). Якщо користувач змінює постачальника послуг гаманців або оновлює логіку гаманця, повторне використання слотів пам'яті може призвести до конфлікту змінних стану, виникнення проблем з перезаписом даних, читанням тощо. Це не тільки може порушити нормальну функцію гаманця, але й призвести до втрати коштів або аномалій у правах.
Рекомендації з безпеки:
Використовуйте спеціалізовані рішення для ізоляції сховища (такі як стандарт EIP-1967) або використовуйте унікальне простір імен для управління слотами сховища.
При оновленні контракту переконайтеся, що зберігання сумісне, уникайте перекриття змінних.
Суворе тестування обґрунтованості стану зберігання під час процесу оновлення.
) Управління nonce всередині гаманця
Гаманець контрактів зазвичай має внутрішнє налаштування nonce та здійснює його самостійне управління, щоб забезпечити порядок виконання операцій користувача та запобігти атакам повтору. Якщо nonce використовується неналежним чином, це призведе до того, що операції користувача не можуть бути виконані належним чином.
Рекомендації з безпеки:
nonce повинен бути строго рівним (або зростаючим), не можна пропускати.
Заборонено безпосередньо змінювати nonce функцією, він повинен оновлюватися тільки під час виконання дій користувача.
Розробка механізмів відмовостійкості та відновлення для аномальних ситуацій з nonce, щоб уникнути мертвих блоків nonce.
(4) Перевірка прав виклику функції
Щоб забезпечити безпеку, контракт гаманця повинен гарантувати, що викликачі ключових функцій є обліковими записами власників гаманця. Два поширених способи включають:
Офлайн-підпис авторизації
Користувач підписує набір операцій за допомогою приватного ключа, а смарт-контракт гаманця на ланцюгу перевіряє, чи є підпис дійсним, чи не протермінований, чи відповідає відповідному nonce. Цей спосіб підходить для моделі релейних транзакцій, запропонованої EIP-7702 (офлайн-підпис користувача + транзакції, що відправляються релеєм).
Виклик обмеження (msg.sender == адреса (this))
Функцію дії користувача дозволено запускати лише самим контрактом, який, по суті, є механізмом контролю шляху виклику, гарантуючи, що зовнішнім ініціатором має бути сам обліковий запис. Це фактично еквівалентно вимозі від абонента бути оригінальним EOA, оскільки адреса контракту є адресою EOA.
Третє. Перспективи: EIP-7702 та майбутній стандарт AA гаманців
Запровадження EIP-7702 є не лише революцією традиційної моделі облікових записів, але й значним поштовхом для екосистеми абстракції облікових записів (Account Abstraction). Його можливість завантажувати код контракту користувачами відкриває широкі можливості для майбутнього дизайну гаманців та системи контрактів, а також ставить нові вимоги до стандартів безпеки аудиту.
Хоча EIP-7702 і EIP-4337 мають різні цілі в дизайні, перший реорганізовує механізм завантаження коду рахунків, а другий будує повний вхід для транзакцій і екосистему пакування. Але обидва не конфліктують, а навпаки, мають сильну взаємодоповнювальність:
EIP-4337 надає "універсальний торговий канал" та "інтерфейс виконання абстрактних облікових записів";
EIP-7702 дозволяє користувацьким обліковим записам динамічно на赋увати контрактну логіку без зміни адреси;
Отже, у майбутньому гаманці можуть використовувати «двомодну підтримувальну архітектуру»: на ланцюгах, які не підтримують EIP-4337, використовувати EIP-7702 як легковаговий аналог, а в сценаріях, де потрібне упаковування поза ланцюгом та агрегація кількох користувачів, продовжувати покладатися на повний стек протоколу EIP-4337.
Цей двомодальний механізм також сприятиме тому, щоб гаманці на ядерному рівні підтримували більш гнучку модель прав облікових записів, механізм деградації та плани відкату.
Механізм контрактних рахунків, запропонований EIP-7702, має природний потенціал для інтеграції з новими структурами, такими як популярні сьогодні гаманці MPC, гаманці ZK, модульні гаманці тощо:
У режимі MPC підписувальна поведінка більше не залежить від єдиного приватного ключа, а є результатом спільного рішення багатьох сторін. Підписи, згенеровані шляхом інтеграції EIP-7702 та MPC, можуть контролювати логіку контрактів, що динамічно завантажуються, що дозволяє реалізувати більш гнучкі стратегії виконання.
Гаманець ZK перевіряє особистість або авторизацію користувача за допомогою нульових знань, не розкриваючи інформацію про приватні ключі. Після впровадження EIP-7702 гаманець ZK може тимчасово вводити специфічні логічні контракти після завершення перевірки, що дозволяє реалізувати персоналізовані дії після обчислень конфіденційності, наприклад, автоматичне виконання певної логіки тільки після виконання певних умов конфіденційності.
Модульні гаманці (Modular Wallets) можуть використовувати EIP-7702 для розділення логіки облікового запису на кілька модулів, які можуть динамічно завантажуватися за потреби.
Таким чином, EIP-7702 надає більш рідний «контейнер виконання» для вищезазначених розширених гаманців: різна логіка контракту може бути введена з однією і тією ж адресою користувача, що дозволяє уникнути проблеми залежності адреси в традиційному процесі розгортання контрактів, і немає необхідності в попередньому розгортанні, що значно покращує гнучкість і можливість комбінування поведінки облікового запису.
EIP-7702 призведе до глибоких змін у парадигмі розробки. Розробники контрактів більше не просто розглядають абонента як традиційний EOA або фіксований контрактний обліковий запис, а повинні адаптуватися до нового механізму: особистість абонента може динамічно перемикатися між EOA та статусом контракту під час транзакції, а логіка поведінки облікового запису більше не є статично закріпленою, а може бути гнучко змінена відповідно до вимоги. Це вимагає від розробників та аудиторів:
Введення більш жорсткої логіки верифікації виклику та перевірки прав;
Перевірте, чи впливає логіка динамічного контракту на шлях виклику;
Визначити потенційні вразливості поведінки, такі як msg.sender.code.length == 0, isContract () тощо;
Ясно визначити логіку контракту «залежність від контексту», наприклад, контроль меж статичних викликів, deleGatecall;
Підтримка моделювання та відновлювального аналізу сценаріїв setCode на рівні інструментального ланцюга.
Іншими словами, безпека коду більше не є просто «проблемою перед розгортанням», а стала «динамічним процесом, який також потрібно перевіряти під час виклику та транзакції».
Чотири, підсумок
EIP-7702 представляє легшу, ріднішу та гнучкішу реалізацію Account Abstraction (AA), яка дозволяє звичайному EOA передавати логіку контракту та виконувати її в одній транзакції. Цей механізм ламає традиційні статичні припущення про поведінку облікового запису, і розробники більше не можуть просто покладатися на стан коду адреси облікового запису, щоб судити про його модель поведінки, а повинні реконструювати розуміння ідентичності та межі повноважень абонента. З цим відбувається зміна парадигми в аналітиці безпеки. Фокус аудиту більше не обмежується тим, «чи має адреса дозволи», а зміщується на те, «що може зробити логіка контракту, що міститься в транзакції, в поточному контексті». Кожна транзакція може нести незалежне визначення поведінки, що надає обліковому запису більшу функціональність і висуває більш високі вимоги до аудиту безпеки.