Ethereum Pectra оновлення:EIP-7702 Глибина аналізу
Вступ
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 вказує на ланцюг, на якому діє ця уповноважена делегація
адреса означає цільову адресу делегування
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, можуть з різних причин, таких як зміна вимог до функціональності чи оновлення гаманця, потребувати повторного делегування на іншу адресу контракту. Але структура зберігання різних контрактів може відрізнятися, ### наприклад, різні слоти slot0 можуть представляти різні типи даних (, у випадку повторного делегування це може призвести до випадкового повторного використання даних старого контракту новим контрактом, що може викликати блокування облікового запису, втрату коштів та інші негативні наслідки.
Користувачам слід обережно ставитися до ситуації з повторним делегуванням.
Для розробників під час процесу розробки слід дотримуватись Формули Простору Імен, запропонованої 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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
6 лайків
Нагородити
6
5
Поділіться
Прокоментувати
0/400
PermabullPete
· 19год тому
приєднуйтесь就卷 Книга ордерів又得炸咯
Переглянути оригіналвідповісти на0
StablecoinEnjoyer
· 19год тому
Трохи випереджає події, відчуваю, що Віталік Бутерін знову замішаний у великій справі.
Переглянути оригіналвідповісти на0
Token_Sherpa
· 19год тому
мех... ще одна пропозиція, яка насправді не вирішить реальні проблеми eth, якщо чесно
EIP-7702 Глибина аналізу: оновлення Ethereum Pectra розмиває межі між EOA та CA
Ethereum Pectra оновлення:EIP-7702 Глибина аналізу
Вступ
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 для кожного елемента авторизації в 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, можуть з різних причин, таких як зміна вимог до функціональності чи оновлення гаманця, потребувати повторного делегування на іншу адресу контракту. Але структура зберігання різних контрактів може відрізнятися, ### наприклад, різні слоти slot0 можуть представляти різні типи даних (, у випадку повторного делегування це може призвести до випадкового повторного використання даних старого контракту новим контрактом, що може викликати блокування облікового запису, втрату коштів та інші негативні наслідки.
Користувачам слід обережно ставитися до ситуації з повторним делегуванням.
Для розробників під час процесу розробки слід дотримуватись Формули Простору Імен, запропонованої 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, різні учасники екосистеми, такі як користувачі, постачальники гаманців, розробники, біржі тощо, стикаються з численними викликами та можливостями. Найкращі практики, викладені в цій статті, не можуть охопити всі потенційні ризики, але все ж варто звернути на них увагу під час практичного застосування.