Що таке делегування EIP-7702? Пояснення смарт-акаунтів EOA

Делегування EIP-7702 дає змогу зовнішньо керованому акаунту (EOA) передати логіку виконання іншому контракту без зміни адреси чи розкриття приватного ключа. У полі коду встановлюється 0xef0100 разом з адресою делегата, а подальші виклики виконують цей код у власному контексті EOA, при цьому баланс, nonce і сховище й надалі належать акаунту.

Матеріал призначений для читачів, які вже знайомі з гаманцями самостійного зберігання та моделлю акаунтів EVM. Ethereum давно має два типи акаунтів: EOA, якими керують ключі, і контрактні акаунти з кодом. Лише другий тип міг містити власну логіку валідації, але ціною створення нової адреси. Механізм було впроваджено в оновленні Pectra: він переносить власну валідацію зі створення нового акаунту на запис коду за адресою, яка вже використовується.

Кортеж авторизації містить шість полів, а дескриптор делегування займає 23 байти: трьохбайтовий префікс і 20-байтову адресу. Спосіб запису, межі нових можливостей, відмінності від ERC-4337 і надійність делегата визначають, який рівень контролю акаунт зберігає після підписання.

Основні висновки

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

• Транзакція типу 0x04 записує делегування через кортеж авторизації; підписане повідомлення не містить полів комісії, а відправник не обов’язково має бути власником.

• Делегування не має строку дії; скасування очищує код, але не сховище, дозволи токенів або підписи Permit.

• Делегат без receive() або fallback() спричиняє скасування звичайних переказів ETH, а tx.origin більше не означає, що акаунт не має коду.

• ERC-4337 створює окрему систему акаунтів, тоді як EIP-7702 додає код до наявних EOA, тому ці механізми можуть використовуватися разом.

Що змінює делегування EIP-7702 у зовнішньо керованому акаунті?

Ethereum має два типи акаунтів: зовнішньо керований акаунт, яким управляє приватний ключ, і контрактний акаунт, який містить код.

З EIP-7702 змінюється поле коду, а не ідентичність акаунту, оскільки EOA може тимчасово посилатися на код контракту без зміни своєї адреси. Адреса, приватний ключ, баланс і nonce залишаються без змін; відмінність полягає в тому, що адреса тепер містить виконуваний код, отриманий з іншого розгорнутого контракту.

Поле містить 23-байтовий дескриптор делегування: префікс 0xef0100 і 20-байтову адресу. Коли виклик спрямовується до такого EOA, EVM зчитує дескриптор і завантажує код делегата. Завдяки цьому акаунт може поводитися як смарт-акаунт, водночас приватний ключ зберігає контроль, а відправник, баланс і сховище зчитуються як дані EOA.

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

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

Тип 0x04 і кортежі авторизації: як делегування отримує доступ до коду контракту

Для запису потрібен новий тип транзакції 0x04, тіло якої містить список авторизацій. Кожен кортеж підписує власник акаунту, тоді як саму транзакцію може надіслати й оплатити будь-яка адреса, а авторизація визначає, який код акаунт дозволяє виконувати.

Кортеж має вигляд [chain_id, address, nonce, y_parity, r, s], а підписане повідомлення — keccak(0x05 || rlp([chain_id, address, nonce])). У специфікації EIP-7702 використовується префікс 0x05, щоб відокремити підписи авторизації від звичайних підписів транзакцій, а повідомлення не містить полів газу чи комісії.

Підписується адреса, на яку має посилатися код, а не конкретна транзакція, тому деякі системи натомість поєднують авторизацію з наміром. Акаунт також може один раз підписати повідомлення офлайн, тоді як спонсор покриє витрати на газ.

Перевірка вузлом виконується у шість етапів, а прив’язка до nonce робить авторизацію придатною для використання лише один раз — за відповідного nonce.

Список авторизацій додається до тіла транзакції так само, як список доступу розширює формат транзакції: ідентифікатор мережі дорівнює 0 або збігається з локальною мережею (0 означає дійсність у будь-якій мережі); nonce менший за 2^64 – 1; ecrecover перевіряє підпис; код акаунту порожній або вже делегований; nonce відповідає поточному значенню; а код записується як 0xef0100 || address із збільшенням nonce.

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

Які властивості акаунту залишаються незмінними?

Чотири властивості залишаються такими самими, а змінюються лише код і сховище: код переходить від 0x до дескриптора, невикористані комірки сховища починають приймати записи, і ці значення зберігаються після скасування. Специфікація окремо наводить три ончейн-інваріанти, які більше не виконуються та стосуються балансу, nonce та ідентичності виклику; їх розглянуто в розділі про ризики.

1. Адреса: не змінюється, тому історія, дозволи токенів і записи імен і надалі посилаються на одну адресу.

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

3. Баланс: не змінюється, оскільки делегування не переміщує активи, а акаунт і далі зберігає їх безпосередньо.

4. Nonce: продовжує зростати, оскільки авторизація використовує одне значення, що блокує повторне використання того самого підпису.

Чи може делегований акаунт і надалі отримувати ETH у звичайний спосіб?

Не за замовчуванням. Щойно акаунт містить код, звичайний переказ ETH переходить до шляху виконання коду. Якщо делегат не реалізує ані receive(), ані fallback(), переказ скасовується, а кошти повертаються відправнику.

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

Рисунок 1. Шлях запису EIP-7702: EOA підписує кортеж авторизації, транзакція типу 0x04 встановлює код 0xef0100 разом з адресою делегата, а подальші виклики виконують цей код у контексті EOA.

Що може робити делегований акаунт? Пакетування, спонсорування газу та відновлення

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

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

Спонсорування газу забезпечується відокремленням підпису від відправника: третя сторона платить, акаунту не потрібен ETH наперед, а з paymaster ERC-4337 витрати може взяти на себе застосунок. Це також означає, що деякі застосунки можуть покривати газ або спрощувати початкове налаштування, обробляючи це у фоновому режимі. Однак розробникам не слід запитувати делегування в момент, коли користувач просто запитує доступ до іншої функції.

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

Межа є чіткою: будь-хто, хто володіє приватним ключем, завжди може підписати нову авторизацію, яка перезапише делегування. Тому відновлення тут слабше, ніж у нативному смарт-акаунті, і лише зменшує наслідки втрати ключа.

Делегування не має строку дії. Воно залишається активним, доки нова авторизація не перезапише його або нульова адреса не скасує його. Отже, дозвіл є довгостроковим і потребує активного керування. З погляду безпеки перевіряйте обсяг доступу та контролю, який може отримати делегований код.

Чим делегування EIP-7702 відрізняється від ERC-4337 та абстракції акаунтів?

EIP-7702 додає код до наявного EOA, тоді як ERC-4337 створює окрему систему акаунтів. Як взаємодоповнювальні підходи до абстракції акаунтів, вони можуть використовуватися разом, а не замінювати один одного.

ERC-4337 починається з нового розгорнутого контракту, тому активи й дозволи потрібно переміщувати. 7702 починається з початкової адреси та додає код, уникаючи міграції й дозволяючи наявним акаунтам використовувати поведінку смарт-контракту без попереднього розгортання окремого гаманця.

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

Існують два способи виправлення: initWithSig, який прив’язує підпис до аргументів ініціалізації, або обмеження ініціалізації лише для EntryPoint.

Чи є делегат надійним? Як перевірити його незмінність

Делегуйте лише незмінним контрактам, розгорнутим зі стандартного initcode CREATE2. Механізм перевірки має надавати перевагу цілям без шляху оновлення, оскільки проксі-контракти, контракти з можливістю оновлення та контракти зі шляхом self-destruct є неналежними цілями.

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

Три критерії — незмінний код, відсутність проксі та відтворюване розгортання — перетворюються на чотири перевірки в блокчейн-оглядачі, які гаманці та розробники мають виконати перед наданням делегування:

1. Перевірте слоти реалізації та адміністратора: ненульовий слот EIP-1967, що починається з 0x360894, сигналізує про проксі або шлях оновлення.

2. Порівняйте ончейн-байткод із верифікованим вихідним кодом, переконавшись, що аргументи конструктора та розгорнутий байткод збігаються.

3. Знайдіть selfdestruct і delegatecall та переконайтеся, що жодна гілка не може стерти код або перенаправити виконання в інше місце.

4. Повторно обчисліть адресу CREATE2 на основі initcode і salt, переконавшись, що розгортач не може підставити інший контракт за іншою адресою.

Які ризики має делегування EIP-7702?

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

Рядок щодо tx.origin має найширший радіус впливу. Делегований акаунт може виконувати код усередині стека викликів, тому msg.sender == tx.origin більше не означає, що викликач не має коду, а захисти, побудовані на цьому порівнянні, перестають захищати. Блокування nonReentrant або на основі тимчасового сховища не залежать від ідентичності викликача.

На практиці, якщо гаманці нечітко показують деталі авторизації, користувачі можуть схвалити доступ, який не мали наміру переглядати. Рекомендації щодо EIP-7702 у документації Pectra розглядають це окремо.

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

Як перевірити та скасувати делегування?

Для перевірки достатньо одного зчитування коду: якщо eth_getCode повертає 0x, делегування немає; 23 байти, що починаються з 0xef0100, означають, що акаунт є делегованим зовнішньо керованим акаунтом; будь-який інший байткод означає контрактний акаунт.

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

Для швидкої ручної перевірки скористайтеся інструкцією перевірка та скасування делегування.

Скасування відбувається в гаманці: підпишіть нову авторизацію з нульовою адресою в полі address, і вузол очистить хеш коду, повернувши акаунт до звичайного EOA. Зовнішні dApp зазвичай не можуть зробити це за власника. Якщо команди гаманців підтримують процеси скасування, будь-які запити на дії від імені власника все одно мають вимагати його власного схвалення.

Скасування видаляє делегований код, але не видаляє попередні дозволи смарт-контрактів або інший доступ, уже наданий застосункам. Примітки OpenZeppelin щодо делегування EOA окреслюють цю межу.

Підсумок

EIP-7702 надає EOA програмованість за допомогою одного підпису: адреса та ключ залишаються на місці, поле коду вказує на делегата, а виконання відбувається у власному контексті акаунту.

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

Поширені запитання

Чи перетворює EIP-7702 мій гаманець на мультипідписний?

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

Як перевірити, чи делегований мій гаманець відповідно до EIP-7702?

Викличте eth_getCode для адреси. Повернення 0x означає відсутність делегування; 23 байти, що починаються з 0xef0100, означають делегування, а останні 20 байтів указують на делегата; інший байткод означає контрактний акаунт.

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

Як скасувати делегування EIP-7702?

Усередині гаманця підпишіть нову авторизацію з нульовою адресою в полі address, і вузол очистить хеш коду після успішної валідації. Підписати її може лише власник акаунту, а зовнішні dApp зазвичай не можуть діяти від його імені.

Чи має делегування строк дії та чи зберігаються попередні дозволи токенів після скасування?

Делегування не має строку дії та залишається активним, доки його не перезапишуть або не скасують. Скасування очищує лише код, не змінюючи сховище, дозволи ERC-20 і підписи Permit.

Мій ключ не було скомпрометовано — чи може зловмисна авторизація EIP-7702 все одно вивести кошти з акаунту?

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

Перевіряйте ідентифікатор мережі та цільову адресу в кортежі й підписуйте лише для незмінних контрактів. Команди гаманців також мають перевіряти повноваження підписанта перед наданням внутрішніх схвалень, пов’язаних із делегуванням, від імені організації.