Ethereum Pectra в оновленні EIP-7702: значна трансформація для EOA

Вступ

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

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

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

Огляд

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

Конкретна реалізація EIP-7702 полягає у впровадженні типу транзакції SET_CODE_TX_TYPE (0x04), структура даних якої визначена наступним чином:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, призначення, значення, дані, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

параметр authorization_list визначається як:

authorization_list = [[chain_id, адреса, ні, y_parity, р, с], ...]

У новій торговій структурі, крім поля authorization_list, інші дотримуються тих самих семантичних значень, що й EIP-4844. Це поле є списковим типом, у якому може міститися кілька авторизаційних записів, у кожному з яких:

• поле chain_id вказує на ланцюг, на якому ця авторизація делегування є дійсною
• поле адреси вказує на адресу призначення делегування
• поле nonce повинно відповідати nonce поточного авторизованого облікового запису
• y_parity, r, s поля є підписаними даними, авторизованими обліковим записом

У полі authorization_list в одній транзакції може міститися кілька різних авторизованих облікових записів, підписаних (EOA), тобто ініціатор транзакції може бути іншим, ніж авторизатор, для того щоб реалізувати операцію з авторизації з оплатою gas за рахунок авторизатора.

реалізація

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

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

Коли уповноважена особа підписує дані уповноваження, ініціатор交易 об'єднує їх у полі authorization_list для підпису та транслює交易 через RPC. Перед виконанням交易 в блоці Proposer спочатку проводить попередню перевірку交易, під час якої обов'язково перевіряється адреса to, щоб забезпечити, що ця交易 не є交易 на створення контракту, тобто при надсиланні交易 типу EIP-7702 адреса to не може бути порожньою.

Одночасно такі транзакції зобов'язують, щоб поле authorization_list містило щонайменше один елемент авторизації; якщо кілька елементів авторизації підписані одним і тим же авторизатором, то в підсумку лише останній елемент авторизації буде дійсним.

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

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

Після завершення авторизації додатка поле code адреси авторизатора буде встановлено на 0xef0100 || address, де 0xef0100 є фіксованим ідентифікатором, а address є адресою делегування. Через обмеження EIP-3541, користувачі не можуть звичайним способом розгортати код контракту, що починається з байтів 0xef, що гарантує, що такі ідентифікатори можуть бути розгорнуті лише за допомогою транзакцій типу SET_CODE_TX_TYPE (0x04).

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

Новий тип транзакцій, введений через EIP-7702, дозволяє авторизатору (EOA) виконувати код, так само як і смарт-контракт, одночасно зберігаючи можливість ініціювати транзакції. У порівнянні з EIP-4337, це забезпечує користувачам досвід, який наближається до нативного абстрагування рахунків (Native AA), що значно знижує поріг входження для користувачів.

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

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

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

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

Для користувачів, під час використання рахунку після делегування, користувачі все ще повинні ставити захист приватного ключа на перше місце, завжди пам'ятати: Not your keys, not your coins.

Багатоланцюгове повторення

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

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

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

не вдалося ініціалізувати

Поточні основні гаманці смарт-контрактів в основному використовують модель代理, гаманець代理 під час розгортання буде викликати ініціалізаційну функцію контракту через DELEGateCALL, щоб досягти атомарної операції ініціалізації гаманця та розгортання代理-гаманця, уникаючи проблеми з передчасною ініціалізацією. Але коли користувач використовує EIP-7702 для делегування, він лише оновлює поле code його адреси, не зможе ініціалізувати через виклик адреси делегування. Це робить EIP-7702 неспроможним викликати ініціалізаційну функцію для ініціалізації гаманця в транзакції розгортання контракту, як це робить звичайний контракт代理 ERC-1967.

Для розробників важливо звернути увагу на перевірку прав під час ініціалізації гаманця, поєднуючи EIP-7702 з існуючим гаманцем EIP-4337 (наприклад, шляхом відновлення адреси підпису через ecrecover), щоб уникнути ризику "викрадення" ініціалізації гаманця.

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

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

Користувачам слід обережно ставитися до ситуацій з повторним делегуванням.

Для розробників під час процесу розробки слід дотримуватись Namespace Formula, запропонованої ERC-7201, розподіляючи змінні на вказані незалежні місця зберігання, щоб зменшити ризик конфліктів зберігання. Крім того, ERC-7779 (draft) також спеціально передбачає стандартний процес повторного делегування для EIP-7702: включаючи використання ERC-7201 для запобігання конфліктам зберігання, а також перевірку сумісності зберігання перед повторним делегуванням і виклик інтерфейсу старого делегування для очищення старих даних.

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

Користувачі після делегування також зможуть використовувати EOA як смарт-контракт, тому централізовані біржі (CEX) можуть зіткнутися з ситуацією загального використання поповнень смарт-контрактів.

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

Переклад рахунку

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

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

Розробники під час розробки повинні припускати, що майбутні учасники можуть бути всіми смарт-контрактами.

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

Існуючі токени ERC-721, ERC-777 мають функцію Hook під час передачі токенів до контракту, що означає, що одержувач повинен реалізувати відповідну функцію зворотного виклику для успішного отримання токенів.

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

Перевірка риболовлі

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

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

Крім того, більш глибокий автоматичний аналіз цільових контрактів, делегованих акаунтом (відкритий аудит, перевірка прав тощо), може краще допомогти користувачам уникнути таких ризиків.

Підсумок

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

! Встановити код облікового запису EOA

! Скасувати код облікового запису EOA