EIP-7702: Значна трансформація зовнішніх акаунтів Ethereum

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

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

Аналіз протоколу

Огляд

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

EIP-7702 впроваджує тип транзакції SET_CODE_TX_TYPE (0x04), структура даних якої містить поле authorization_list, що може включати кілька авторизаційних записів. Кожен авторизаційний запис містить chain_id, address, nonce та підписані дані.

реалізація

Коли уповноважений підписує дані уповноваження, потрібно RLP-кодувати chain_id, address, nonce, разом з MAGIC-числом виконати хешування keccak256, а потім підписати приватним ключем. MAGIC ( 0x05) як роздільник доменів, забезпечує, щоб результати підписів різних типів не конфліктували.

Коли chain_id дорівнює 0, це означає, що авторизація може бути повторена на всіх підтримуваних EIP-7702 EVM-сумісних блокчейнах. Перед виконанням транзакції Proposer проведе попередню перевірку, щоб гарантувати, що транзакція не є транзакцією створення контракту. Поле authorization_list у транзакції повинно містити принаймні один пункт авторизації.

Під час виконання транзакції вузлом спочатку збільшується nonce ініціатора, а потім для кожного з дозволів виконується операція applyAuthorization. У разі помилки цей запис дозволу буде пропущений, а інші записи продовжать застосовуватися. Після завершення авторизації поле code адреси авторизатора буде встановлено на 0xef0100||address. Авторизатор може встановити адресу делегата на 0 адресу, щоб видалити авторизацію.

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

Хоча EIP-7702 вносить нову енергію в екосистему Ethereum, він також приносить нові ризики. Ось аспекти, на які учасникам екосистеми слід звернути увагу:

зберігання приватного ключа

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

багатопоточне повторення

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

Неможливо ініціалізувати

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

Управління зберігання

Перекладання на іншу адресу контракту може призвести до відмінностей у структурі зберігання, що викликає блокування акаунта або втрату коштів. Розробники повинні дотримуватися формули простору імен ERC-7201, розподіляючи змінні на окремі місця зберігання.

Фальшивий депозит

Централізовані біржі можуть зіткнутися з поширенням поповнень через смарт-контракти, тому слід перевіряти статус поповнень через trace, щоб запобігти ризику фальшивих поповнень.

акаунт перетворення

акаунт може вільно конвертуватись між EOA та SC, руйнуючи деякі безпекові припущення, які обмежують участь у проектах лише EOA. Розробники повинні виходити з припущення, що майбутні учасники можуть бути всіми смарт-контрактами.

Сумісність контракту

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

Перевірка на рибалку

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

Підсумок

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