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 вказує на ланцюг, на якому діє це уповноваження.
адреса вказує на цільову адресу делегування
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, щоб переконатися, що ця угода не є угодою на створення контракту.
Одночасно такі транзакції вимагають, щоб поле 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 як смарт-контракт, тому деякі біржі можуть зіткнутися з ситуацією, коли поповнення через смарт-контракти стане загальним.
Біржа повинна перевіряти статус кожної операції поповнення через 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, різні учасники екосистеми, такі як користувачі, постачальники гаманців, розробники, біржі тощо, стикаються з численними викликами та можливостями в реальному застосуванні. Вміст найкращих практик, викладений у цій статті, не може охопити всі потенційні ризики, але все ж вартий уваги для застосування на практиці.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
5
Поділіться
Прокоментувати
0/400
digital_archaeologist
· 07-07 03:43
Списування домашнього завдання, так? Якось дуже схоже на минулорічний EIP-4337.
Переглянути оригіналвідповісти на0
PanicSeller69
· 07-04 09:18
А-а-а, топ-топ-топ, знову EIP, тепер все треба модернізувати!
Переглянути оригіналвідповісти на0
DevChive
· 07-04 06:03
Оновлення вже тут, EOA буде послаблено, це явно неправильний шлях.
Переглянути оригіналвідповісти на0
Token_Sherpa
· 07-04 05:54
ще один день, ще одне оновлення ETH... коли ж номери піднімуться?
Ethereum Pectra оновлення: EIP-7702 приносить Програмованість та виклики для 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, щоб переконатися, що ця угода не є угодою на створення контракту.
Одночасно такі транзакції вимагають, щоб поле 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 як смарт-контракт, тому деякі біржі можуть зіткнутися з ситуацією, коли поповнення через смарт-контракти стане загальним.
Біржа повинна перевіряти статус кожної операції поповнення через 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, різні учасники екосистеми, такі як користувачі, постачальники гаманців, розробники, біржі тощо, стикаються з численними викликами та можливостями в реальному застосуванні. Вміст найкращих практик, викладений у цій статті, не може охопити всі потенційні ризики, але все ж вартий уваги для застосування на практиці.