Ethereum Pectra оновлення: Глибина аналізу та найкращі практики EIP-7702
Вступ
Ethereum незабаром зустріне оновлення Pectra, яке є значним оновленням. Серед них, EIP-7702 здійснив революційну трансформацію зовнішнього облікового запису Ethereum (EOA). Ця пропозиція розмиває межі між EOA та контрактним обліковим записом CA, що є ключовим кроком до рідної абстракції облікових записів, приносячи нові моделі взаємодії в екосистему 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. authorization_list є списковим типом і може містити кілька авторизаційних записів. Кожен авторизаційний запис містить:
chain_id вказує на ланцюг, на якому діє делегування повноважень.
адреса вказує на адресу цільового делегування
nonce має відповідати nonce поточного авторизованого облікового запису
y_parity, r, s є підписаними даними авторизації, підписаними обліковим записом
Список авторизацій однієї транзакції може містити кілька різних авторизованих рахунків, підписаних (EOA), що забезпечує оплату газу для операцій авторизації.
реалізація
Під час підписання даних про авторизацію уповноваженою особою спочатку потрібно закодувати chain_id, address, nonce за допомогою RLP. Потім закодовані дані разом з MAGIC даними підлягають обчисленню хешу keccak256, що дає підписувані дані. Нарешті, за допомогою приватного ключа уповноваженої особи підписується хешоване дані, отримуючи y_parity, r, s дані. MAGIC (0x05) використовується як роздільник доменів, щоб забезпечити, що результати підписів різних типів не конфліктують.
Коли chain_id, що наданий уповноваженим, дорівнює 0, це означає, що уповноважений дозволяє повторне використання авторизації на всіх EVM-сумісних ланцюгах, що підтримують EIP-7702 (при умові, що nonce також точно збігається).
Після підписання даних авторизації уповноваженою особою, ініціатор транзакції збирає їх у полі authorization_list для підпису та транслює транзакцію через RPC. Перед виконанням транзакції Пропонент спочатку проводить попередню перевірку, щоб переконатися, що ця транзакція не є транзакцією створення контракту, тобто при надсиланні транзакції типу EIP-7702 адреса to не може бути порожньою.
Цей тип транзакцій вимагає, щоб поле authorization_list містило принаймні один пункт авторизації. Якщо кілька пунктів авторизації підписані одним і тим же уповноваженим, то в остаточному підсумку лише останній пункт авторизації діє.
Під час виконання транзакції вузол спочатку збільшує значення nonce ініціатора транзакції, а потім виконує операцію applyAuthorization для кожного з авторизаційних записів у списку authorization_list. У операції applyAuthorization вузол спочатку перевіряє nonce авторизатора, а потім збільшує nonce авторизатора. Це означає, що якщо ініціатор транзакції та авторизатор є одним і тим же користувачем (EOA), значення nonce під час підписання авторизаційної транзакції повинно бути збільшене на 1.
При застосуванні авторизаційних записів вузла, якщо виникає будь-яка помилка, цей запис буде пропущений, транзакція не зазнає невдачі, інші авторизаційні записи продовжать застосування, щоб уникнути ризику DoS у сценаріях масової авторизації.
Після завершення авторизації програми, поле code адреси авторизатора буде встановлено на 0xef0100 || address, де 0xef0100 є фіксованим ідентификатором, а address - адреса делегування. Обмеження EIP-3541 гарантує, що такі ідентификатори можуть бути розгорнуті лише транзакціями типу 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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
5
Поділіться
Прокоментувати
0/400
Ser_Liquidated
· 07-17 21:03
Ай-йой, оновлення за оновленням, бик, коні та невдахи не відрізняються.
Переглянути оригіналвідповісти на0
SeasonedInvestor
· 07-16 10:06
Нарешті можу позбутися гаманця. На передовій їв невдах багато років. Все розумію трохи.
Переглянути оригіналвідповісти на0
LiquidationWatcher
· 07-16 00:41
Знову зробили великий рух, просто слідуйте за цим.
Переглянути оригіналвідповісти на0
LightningAllInHero
· 07-16 00:40
Віталік Бутерін ця хвиля справді піднімає мене на місяць, сподіваюся на зростання до небес 0.5eth
Переглянути оригіналвідповісти на0
AltcoinHunter
· 07-16 00:20
Неправильна відповідь testnet зроблено, просто До місяця, закрий очі і все.
Глибина аналізу та найкращі практики оновлення EIP-7702 Pectra Ethereum
Ethereum Pectra оновлення: Глибина аналізу та найкращі практики EIP-7702
Вступ
Ethereum незабаром зустріне оновлення Pectra, яке є значним оновленням. Серед них, EIP-7702 здійснив революційну трансформацію зовнішнього облікового запису Ethereum (EOA). Ця пропозиція розмиває межі між EOA та контрактним обліковим записом CA, що є ключовим кроком до рідної абстракції облікових записів, приносячи нові моделі взаємодії в екосистему 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. Перед виконанням транзакції Пропонент спочатку проводить попередню перевірку, щоб переконатися, що ця транзакція не є транзакцією створення контракту, тобто при надсиланні транзакції типу EIP-7702 адреса to не може бути порожньою.
Цей тип транзакцій вимагає, щоб поле authorization_list містило принаймні один пункт авторизації. Якщо кілька пунктів авторизації підписані одним і тим же уповноваженим, то в остаточному підсумку лише останній пункт авторизації діє.
Під час виконання транзакції вузол спочатку збільшує значення nonce ініціатора транзакції, а потім виконує операцію applyAuthorization для кожного з авторизаційних записів у списку authorization_list. У операції applyAuthorization вузол спочатку перевіряє nonce авторизатора, а потім збільшує nonce авторизатора. Це означає, що якщо ініціатор транзакції та авторизатор є одним і тим же користувачем (EOA), значення nonce під час підписання авторизаційної транзакції повинно бути збільшене на 1.
При застосуванні авторизаційних записів вузла, якщо виникає будь-яка помилка, цей запис буде пропущений, транзакція не зазнає невдачі, інші авторизаційні записи продовжать застосування, щоб уникнути ризику DoS у сценаріях масової авторизації.
Після завершення авторизації програми, поле code адреси авторизатора буде встановлено на 0xef0100 || address, де 0xef0100 є фіксованим ідентификатором, а address - адреса делегування. Обмеження EIP-3541 гарантує, що такі ідентификатори можуть бути розгорнуті лише транзакціями типу 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 тощо, стикаються з багатьма викликами та можливостями. Найкращі практики, викладені в цій статті, не можуть охопити всі потенційні ризики, але все ж варто, щоб усі сторони враховували їх у своїй практичній діяльності.