Pectra 7702

Анотація

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

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

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

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

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

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

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

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

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

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

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

Інтеграція dApps через інтерфейси гаманців:

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

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

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

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

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

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

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

Уникнення прив'язки до постачальника: Відповідно до вищезазначеного, хороша реалізація є нейтральною до постачальника та інтероперабельною. Це часто означає дотримання нових стандартів для смарт-облікових записів. Наприклад, модульний обліковий запис від Alchemyopens 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 для кожної зміни.

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

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

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

Наприклад, SafeEIP7702Proxyopens 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 від Open Zeppelinopens in a new tab. Вони також можуть використовувати перехідну змінну сховищаopens in a new tab.

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

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

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

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

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

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

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

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

Ризики фішингу З впровадженням делегування EIP-7702 активи в обліковому записі користувача можуть повністю контролюватися смарт-контрактами. Якщо користувач несвідомо делегує свій обліковий запис зловмисному контракту, зловмисник може легко отримати контроль і вкрасти кошти. При використанні chain_id=0 делегування застосовується до всіх ідентифікаторів ланцюжків. Делегуйте лише незмінному контракту (ніколи не делегуйте проксі) і лише контрактам, які були розгорнуті за допомогою 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.

Останні оновлення сторінки: 22 жовтня 2025 р.

popens in a new tab

wopens in a new tab

copens in a new tab

+6

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