Пектра 7702

Анотація

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

Цей новий тип транзакції вводить список авторизації. Кожен кортеж авторизації у списку визначається як

[ chain_id, address, nonce, y_parity, r, s ]

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

Делегування можна скинути, делегувавши на нульову адресу.

Приватний ключ EOA зберігає повний контроль над акаунтом після делегування. Наприклад, делегування до Safe не робить акаунт мультипідписом, оскільки все ще існує єдиний ключ, який може обійти будь-яку політику підписання. Надалі розробники повинні проєктувати з припущенням, що будь-який учасник системи може бути смарт-контрактом. Для розробників смарт-контрактів більше не безпечно припускати, що tx.origin вказує на EOA.

Найкращі практики

Абстракція облікового запису: Контракт делегування повинен відповідати ширшим стандартам абстракції облікового запису (AA) Етеріуму для максимальної сумісності. Зокрема, в ідеалі він має бути сумісним або відповідати стандарту ERC-4337.

Бездозвільний та стійкий до цензури дизайн: Етеріум цінує бездозвільну участь. Контракт делегування НЕ ПОВИНЕН жорстко кодувати або покладатися на будь-якого єдиного «довіреного» ретранслятора чи сервіс. Це перетворить акаунт на «цеглину», якщо ретранслятор вийде в офлайн. Такі функції, як пакетування (наприклад, approve+transferFrom), можуть використовуватися самим EOA без ретранслятора. Розробникам застосунків, які хочуть використовувати розширені функції, що стали можливими завдяки EIP-7702 (абстракція газу, зняття коштів зі збереженням приватності), знадобиться ретранслятор. Хоча існують різні архітектури ретрансляторів, ми рекомендуємо використовувати бандлери 4337 (opens in a new tab), що вказують принаймні на точку входу 0.8 (opens in a new tab), оскільки:

• Вони надають стандартизовані інтерфейси для ретрансляції
• Включають вбудовані системи пеймайстерів
• Забезпечують пряму сумісність
• Можуть підтримувати стійкість до цензури через публічний мемпул (opens in a new tab)
• Можуть вимагати, щоб функція ініціалізації викликалася лише з EntryPoint (opens in a new tab)

Іншими словами, будь-хто повинен мати можливість виступати в ролі спонсора/ретранслятора транзакції, за умови надання необхідного дійсного підпису або користувацької операції (UserOperation) від акаунта. Це забезпечує стійкість до цензури: якщо не потрібна спеціальна інфраструктура, транзакції користувача не можуть бути довільно заблоковані ретранслятором-посередником. Наприклад, Delegation Toolkit від МетаМаск (opens in a new tab) явно працює з будь-яким бандлером або пеймайстером ERC-4337 у будь-якому ланцюзі, а не вимагає специфічного сервера МетаМаск.

Інтеграція децентралізованих застосунків (dapp) через інтерфейси гаманців:

Враховуючи, що гаманці додаватимуть до білого списку певні контракти делегування для EIP-7702, децентралізовані застосунки (dapp) не повинні очікувати прямого запиту на авторизацію 7702. Натомість інтеграція має відбуватися через стандартизовані інтерфейси гаманців:

• ERC-5792 (wallet_sendCalls): Дозволяє децентралізованим застосункам (dapp) запитувати у гаманців виконання пакетних викликів, сприяючи таким функціям, як пакетування транзакцій та абстракція газу.

• ERC-6900: Дозволяє децентралізованим застосункам (dapp) використовувати можливості модульних смарт-акаунтів, такі як сесійні ключі та відновлення акаунта, через модулі, керовані гаманцем.

Використовуючи ці інтерфейси, децентралізовані застосунки (dapp) можуть отримати доступ до функцій смарт-акаунтів, що надаються EIP-7702, без прямого управління делегуваннями, забезпечуючи сумісність та безпеку в різних реалізаціях гаманців.

Примітка: Немає стандартизованого методу для децентралізованих застосунків (dapp) безпосередньо запитувати підписи авторизації 7702. Децентралізовані застосунки (dapp) повинні покладатися на специфічні інтерфейси гаманців, такі як ERC-6900, щоб скористатися перевагами функцій EIP-7702.

Для отримання додаткової інформації:

• Специфікація ERC-5792 (opens in a new tab)
• Специфікація ERC-6900 (opens in a new tab)

Уникнення прив'язки до постачальника: Відповідно до вищезазначеного, хороша реалізація є нейтральною до постачальника та інтероперабельною. Це часто означає дотримання нових стандартів для смарт-акаунтів. Наприклад, Modular Account від Alchemy (opens in a new tab) використовує стандарт ERC-6900 для модульних смарт-акаунтів і розроблений з урахуванням «бездозвільного інтероперабельного використання».

Збереження приватності: Хоча ончейн-приватність обмежена, контракт делегування повинен прагнути мінімізувати розкриття даних та можливість їх пов'язування. Цього можна досягти шляхом підтримки таких функцій, як оплата газу в токенах ERC-20 (щоб користувачам не потрібно було підтримувати публічний баланс ETH, що покращує приватність та UX) та одноразові сесійні ключі (які зменшують залежність від єдиного довгострокового ключа). Наприклад, EIP-7702 дозволяє оплачувати газ у токенах через спонсоровані транзакції, і хороша реалізація дозволить легко інтегрувати таких пеймайстерів без витоку більшої кількості інформації, ніж необхідно. Крім того, позамережеве делегування певних схвалень (з використанням підписів, які перевіряються ончейн) означає меншу кількість ончейн-транзакцій з основним ключем користувача, що сприяє приватності. Акаунти, які вимагають використання ретранслятора, змушують користувачів розкривати свої IP-адреси. Публічні мемпули (PublicMempools) покращують цю ситуацію: коли транзакція/користувацька операція (UserOp) поширюється через мемпул, неможливо визначити, чи вона походить від IP-адреси, яка її надіслала, чи просто була ретрансльована через неї за допомогою p2p-протоколу.

Розширюваність та модульна безпека: Реалізації акаунтів мають бути розширюваними, щоб вони могли розвиватися з новими функціями та покращеннями безпеки. Можливість оновлення закладена в EIP-7702 (оскільки EOA завжди може делегувати новому контракту в майбутньому для оновлення своєї логіки). Окрім можливості оновлення, хороший дизайн дозволяє модульність — наприклад, підключення модулів для різних схем підпису або політик витрат — без необхідності повного повторного розгортання. Account Kit від Alchemy є чудовим прикладом, що дозволяє розробникам встановлювати модулі валідації (для різних типів підписів, таких як ECDSA, BLS тощо) та модулі виконання для користувацької логіки. Щоб досягти більшої гнучкості та безпеки в акаунтах з підтримкою EIP-7702, розробникам рекомендується делегувати проксі-контракту, а не безпосередньо конкретній реалізації. Цей підхід дозволяє безперешкодно оновлювати та забезпечувати модульність без необхідності додаткових авторизацій EIP-7702 для кожної зміни.

Переваги патерну проксі:

• Можливість оновлення: Оновлюйте логіку контракту, вказуючи проксі на новий контракт реалізації.

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

Наприклад, SafeEIP7702Proxy (opens in a new tab) демонструє, як проксі можна використовувати для безпечної ініціалізації та управління делегуваннями в акаунтах, сумісних з EIP-7702.

Недоліки патерну проксі:

• Залежність від зовнішніх учасників: Вам доводиться покладатися на зовнішню команду, щоб вона не оновила контракт до небезпечного.

Міркування щодо безпеки

Захист від повторного входу: Із запровадженням делегування EIP-7702 акаунт користувача може динамічно перемикатися між зовнішньо керованим акаунтом (EOA) та смарт-контрактом (SC). Ця гнучкість дозволяє акаунту як ініціювати транзакції, так і бути ціллю викликів. У результаті сценарії, коли акаунт викликає сам себе та робить зовнішні виклики, матимуть msg.sender рівним tx.origin, що підриває певні припущення щодо безпеки, які раніше покладалися на те, що tx.origin завжди є EOA.

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

Надалі розробники повинні проєктувати з припущенням, що будь-який учасник системи може бути смарт-контрактом. Як альтернативу, вони можуть реалізувати явний захист від повторного входу, використовуючи патерни модифікатора nonReentrant. Ми рекомендуємо використовувати перевірений аудитом модифікатор, наприклад, Reentrancy Guard від OpenZeppelin (opens in a new tab). Вони також можуть використовувати змінну транзитного сховища (opens in a new tab).

Міркування щодо безпеки ініціалізації

Реалізація контрактів делегування EIP-7702 створює специфічні виклики для безпеки, особливо щодо процесу ініціалізації. Критична вразливість виникає, коли функція ініціалізації (init) атомарно пов'язана з процесом делегування. У таких випадках фронтраннер може перехопити підпис делегування та виконати функцію init зі зміненими параметрами, потенційно захопивши контроль над акаунтом.

Цей ризик особливо актуальний при спробі використовувати існуючі реалізації смарт-акаунтів (SCA) з EIP-7702 без зміни їхніх механізмів ініціалізації.

Рішення для пом'якшення вразливостей ініціалізації

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

• Використовуйте EntryPoint стандарту ERC-4337
  Вимагайте, щоб функція ініціалізації викликалася виключно з контракту EntryPoint стандарту ERC-4337. Цей метод використовує стандартизований фреймворк валідації та виконання, що надається ERC-4337, додаючи додатковий рівень безпеки до процесу ініціалізації.
  (Див.: Документація Safe (opens in a new tab))

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

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

Ризики фішингу З впровадженням делегування EIP-7702 активи на акаунті користувача можуть повністю контролюватися смарт-контрактами. Якщо користувач через незнання делегує свій акаунт шкідливому контракту, зловмисник може легко отримати контроль і вкрасти кошти. При використанні chain_id=0 делегування застосовується до всіх ідентифікаторів ланцюгів (chain ids). Делегуйте лише незмінному контракту (ніколи не делегуйте проксі-контракту) і лише контрактам, які були розгорнуті за допомогою CREATE2 (зі стандартним initcode — без метаморфічних контрактів), щоб розгортач не міг розгорнути щось інше за тією ж адресою в іншому місці. Інакше ваше делегування ставить ваш акаунт під загрозу в усіх інших EVM-ланцюгах.

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

Мінімальна довірена поверхня та безпека: Пропонуючи гнучкість, контракт делегування повинен зберігати свою основну логіку мінімальною та придатною для аудиту. Контракт фактично є розширенням EOA користувача, тому будь-яка помилка може бути катастрофічною. Реалізації повинні дотримуватися найкращих практик спільноти з безпеки смарт-контрактів. Наприклад, функції конструктора або ініціалізатора мають бути ретельно захищені — як підкреслює Alchemy, у разі використання патерну проксі в рамках 7702 незахищений ініціалізатор може дозволити зловмиснику захопити акаунт. Команди повинні прагнути зберігати ончейн-код простим: контракт 7702 від Ambire містить лише ~200 рядків на Solidity, навмисно мінімізуючи складність для зменшення кількості помилок. Необхідно знайти баланс між багатою на функції логікою та простотою, яка полегшує аудит.

Відомі реалізації

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

Настанови щодо апаратних гаманців

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

Сценарії інтеграції для супутніх застосунків

Лінива

Оскільки EOA все ще працює як зазвичай, нічого робити не потрібно.

Примітка: деякі активи можуть бути автоматично відхилені кодом делегування, наприклад, NFT стандарту ERC-1155, і служба підтримки повинна знати про це.

Обізнана

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

Спільне делегування

Постачальник апаратного забезпечення додає до білого списку відомі контракти делегування та реалізує їх підтримку в програмному супутнику. Рекомендується вибрати контракт із повною підтримкою ERC-4337.

EOA, делеговані іншому контракту, оброблятимуться як стандартні EOA.

Користувацьке делегування

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

EOA, делеговані іншому контракту, оброблятимуться як стандартні EOA.

Останнє оновлення сторінки: 3 квітня 2026 р.

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

Переглянути учасників