Пектра 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, до якого застосовується авторизація (також відомого як authority)

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

Приватний ключ EOA зберігає повний контроль над акаунтом після делегування. Наприклад, делегування до Safe не робить акаунт мультипідписом, оскільки все ще існує єдиний ключ, який може обійти будь-яку політику підписання. Надалі розробники повинні проєктувати з припущенням, що будь-який учасник системи може бути смарт-контрактом. Для розробників смарт-контрактів більше не безпечно припускати, що tx.origin вказує на EOA. Абстракція облікового запису: Контракт делегування повинен відповідати ширшим стандартам абстракції облікового запису (AA) Етеріуму для максимальної сумісності. Зокрема, в ідеалі він має бути сумісним або відповідати стандарту ERC-4337.

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

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

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

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

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

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

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

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

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

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

• Специфікація ERC-5792 (відкривається в новій вкладці)
• Специфікація ERC-6900 (відкривається в новій вкладці)

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

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

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

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

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

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

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

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

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

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

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

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

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

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