Ethereum Pectra оновлення: Глибокий аналіз EIP-7702 та найкращі практики
Передмова
Ethereum незабаром отримає оновлення Pectra, яке є важливим оновленням, оскільки будуть впроваджені кілька важливих пропозицій щодо вдосконалення Ethereum. Зокрема, 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), структура даних якої визначена наступним чином:
У новій торговій структурі, крім поля authorization_list, інші дотримуються тієї ж семантики, що й EIP-4844. Це поле є списковим типом і може містити кілька авторизаційних записів, кожен з яких:
chain_id позначає ланцюг, на якому діє це уповноваження.
address означає адресу цільового делегування
nonce повинен відповідати nonce поточного авторизованого облікового запису
y_parity, r, s є підписаними даними авторизації, підписаними обліковим записом.
Поле authorization_list в одній транзакції може містити кілька різних авторизованих облікових записів, підписаних (EOA), тобто ініціатор транзакції може відрізнятися від авторизатора, щоб здійснити операцію з авторизації з оплатою газу за рахунок авторизатора.
реалізація
Коли уповноважений підписує дані авторизації, спочатку потрібно закодувати chain_id, address, nonce за допомогою RLP. Потім закодовані дані разом з MAGIC числом проходять через хешування keccak256, щоб отримати дані для підпису. Нарешті, використовуючи приватний ключ уповноваженого, підписують хешовані дані, отримуючи y_parity, r, s дані. MAGIC (0x05) використовується як роздільник доменів, щоб забезпечити, що результати підписів різних типів не конфліктують.
Коли chain_id, авторизований уповноваженим, дорівнює 0, це означає, що уповноважений дозволяє повторне використання авторизації ( на всіх EVM-сумісних ланцюгах, які підтримують EIP-7702, за умови, що nonce також точно відповідає ).
Після підписання даних про авторизацію уповноваженим, ініціатор транзакції зіб'є їх у полі authorization_list для підпису та транслює транзакцію через RPC. Перед виконанням транзакції в блоці, пропонент спочатку проводить попередню перевірку транзакції, під час якої обов'язково перевіряється адреса 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 у майбутньому оновленні Pectra Ethereum. EIP-7702, впроваджуючи новий тип транзакцій, надає EOA програмованість і комбінованість, стираючи межі між EOA та контрактними рахунками. Оскільки наразі не існує перевіреного стандарту смарт-контракту, сумісного з типом EIP-7702, на практиці різні учасники екосистеми, такі як користувачі, постачальники гаманців, розробники, CEX тощо, стикаються з багатьма викликами та можливостями. Найкращі практики, викладені в цій статті, не можуть охопити всі потенційні ризики, проте все ж варто звернути на них увагу під час практичного застосування.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
5
Поділіться
Прокоментувати
0/400
ser_ngmi
· 07-21 20:33
Списувати домашнє завдання стало нудно, просто хочеться отримати eoa і ca.
Переглянути оригіналвідповісти на0
ParanoiaKing
· 07-20 23:50
Ще одна купа незрозумілих оновлень, не знаю, що й сказати.
Переглянути оригіналвідповісти на0
YieldHunter
· 07-20 23:49
технічно кажучи, цей eip виглядає трохи підозріло... чи є якісь дані про витрати на tx у тестнеті?
Переглянути оригіналвідповісти на0
EyeOfTheTokenStorm
· 07-20 23:26
Ще одна хвиля можливостей для попереднього розміщення? З історичних даних видно, що після подібних оновлень ETH завжди великі пампи. Проте ринок виглядає дещо надутих.
Переглянути оригіналвідповісти на0
SchrodingerPrivateKey
· 07-20 23:23
Знову новий EIP, з'явився акаунт для контрактів на базовому рівні.
EIP-7702 аналіз: як оновлення Ethereum Pectra надає EOA програмованість
Ethereum Pectra оновлення: Глибокий аналіз EIP-7702 та найкращі практики
Передмова
Ethereum незабаром отримає оновлення Pectra, яке є важливим оновленням, оскільки будуть впроваджені кілька важливих пропозицій щодо вдосконалення Ethereum. Зокрема, 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. Це поле є списковим типом і може містити кілька авторизаційних записів, кожен з яких:
Поле authorization_list в одній транзакції може містити кілька різних авторизованих облікових записів, підписаних (EOA), тобто ініціатор транзакції може відрізнятися від авторизатора, щоб здійснити операцію з авторизації з оплатою газу за рахунок авторизатора.
реалізація
Коли уповноважений підписує дані авторизації, спочатку потрібно закодувати chain_id, address, nonce за допомогою RLP. Потім закодовані дані разом з MAGIC числом проходять через хешування keccak256, щоб отримати дані для підпису. Нарешті, використовуючи приватний ключ уповноваженого, підписують хешовані дані, отримуючи y_parity, r, s дані. MAGIC (0x05) використовується як роздільник доменів, щоб забезпечити, що результати підписів різних типів не конфліктують.
Коли chain_id, авторизований уповноваженим, дорівнює 0, це означає, що уповноважений дозволяє повторне використання авторизації ( на всіх EVM-сумісних ланцюгах, які підтримують EIP-7702, за умови, що nonce також точно відповідає ).
Після підписання даних про авторизацію уповноваженим, ініціатор транзакції зіб'є їх у полі authorization_list для підпису та транслює транзакцію через RPC. Перед виконанням транзакції в блоці, пропонент спочатку проводить попередню перевірку транзакції, під час якої обов'язково перевіряється адреса 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 у майбутньому оновленні Pectra Ethereum. EIP-7702, впроваджуючи новий тип транзакцій, надає EOA програмованість і комбінованість, стираючи межі між EOA та контрактними рахунками. Оскільки наразі не існує перевіреного стандарту смарт-контракту, сумісного з типом EIP-7702, на практиці різні учасники екосистеми, такі як користувачі, постачальники гаманців, розробники, CEX тощо, стикаються з багатьма викликами та можливостями. Найкращі практики, викладені в цій статті, не можуть охопити всі потенційні ризики, проте все ж варто звернути на них увагу під час практичного застосування.