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), структура даних якої визначена наступним чином:
У новій торговій структурі, окрім поля 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 для кожного елемента авторизаційного списку. У процесі 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, через зміни в вимогах до функцій, оновлення гаманця тощо, може виникнути необхідність повторно делегувати на іншу адресу контракту. Однак структура зберігання різних контрактів може відрізнятися ), наприклад, різні контракти можуть мати різні типи даних у слоті slot0 ###. У випадку повторного делегування це може призвести до випадкового повторного використання даних старого контракту новим контрактом, що, в свою чергу, може спричинити блокування облікового запису, втрату коштів та інші негативні наслідки.
Користувачам слід обережно ставитися до ситуацій з повторною делегацією.
Для розробників важливо дотримуватись 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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
9
Репост
Поділіться
Прокоментувати
0/400
notSatoshi1971
· 07-26 08:08
Перед початком торгів на ринку потрібно заздалегідь лежати в засідці, 7702 обов'язково До місяця.
Переглянути оригіналвідповісти на0
0xSunnyDay
· 07-24 10:37
Це оновлення занадто жорстке 8 Погнали
Переглянути оригіналвідповісти на0
BasementAlchemist
· 07-23 13:37
Ще одна хвиля інновацій акаунтів контрактів? Це просто абсурд.
Переглянути оригіналвідповісти на0
MEVHunterX
· 07-23 13:21
Знову наступна історія 4337, вау~ Смачно, просто в атаку!
Переглянути оригіналвідповісти на0
PanicSeller69
· 07-23 13:20
Одразу видно, що буде памп. Коли почнемо купувати просадку В-світ?
Переглянути оригіналвідповісти на0
FastLeaver
· 07-23 13:14
Знову оновлення?? Шахрайство
Переглянути оригіналвідповісти на0
PerennialLeek
· 07-23 13:12
Піднялося кілька хвиль, хто розуміє, той розуміє
Переглянути оригіналвідповісти на0
WinterWarmthCat
· 07-23 13:12
Термінал заговорив! Нове оновлення? Про виведення коштів поговоримо пізніше.
Переглянути оригіналвідповісти на0
Web3ExplorerLin
· 07-23 13:07
фантастично... eip-7702 може стати тим квантовим стрибком, який потрібен eth прямо зараз
Ethereum Pectra оновлення: EIP-7702 розмиває межі між EOA та CA, відкриваючи нову еру абстрагування рахунку
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. Це поле має тип списку і може містити кілька авторизованих записів, кожен з яких:
Поле 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 для кожного елемента авторизаційного списку. У процесі 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, через зміни в вимогах до функцій, оновлення гаманця тощо, може виникнути необхідність повторно делегувати на іншу адресу контракту. Однак структура зберігання різних контрактів може відрізнятися ), наприклад, різні контракти можуть мати різні типи даних у слоті slot0 ###. У випадку повторного делегування це може призвести до випадкового повторного використання даних старого контракту новим контрактом, що, в свою чергу, може спричинити блокування облікового запису, втрату коштів та інші негативні наслідки.
Користувачам слід обережно ставитися до ситуацій з повторною делегацією.
Для розробників важливо дотримуватись 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 тощо, стикаються з численними викликами та можливостями. Найкращі практики, викладені в цій статті, не можуть охопити всі потенційні ризики, але все ж заслуговують на увагу для застосування на практиці.