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. Це поле є списковим типом, у списку може міститися кілька записів авторизації, у кожному записі авторизації:

• поле chain_id вказує на ланцюг, на якому діє це уповноваження.
• поле address вказує на цільову адресу делегування
• поле nonce повинно відповідати nonce поточного авторизованого облікового запису
• поля y_parity, r, s є підписаними даними авторизованого облікового запису

У полі authorization_list однієї транзакції може міститися кілька різних авторизованих облікових записів, підписаних EOA(, тобто ініціатор транзакції може відрізнятися від авторизатора, щоб здійснити операцію авторизації з оплатою gas за рахунок авторизатора.

) реалізація

Уповноважений під час підписання даних повноважень спочатку повинен закодувати chain_id, address, nonce за допомогою RLP. Потім закодовані дані разом з MAGIC числом підлягають обчисленню хешу keccak256, щоб отримати дані для підписання. На завершення, використовуючи приватний ключ уповноваженого, підписують хешовані дані, в результаті чого отримують дані y_parity, r, s. При цьому, MAGIC ###0x05( використовується як роздільник доменів, метою якого є забезпечення відсутності конфліктів результатів підписів різних типів.

Потрібно звернути увагу на те, що коли chain_id, який надається авторизатором, дорівнює 0, це означає, що авторизатор дозволяє повторне використання авторизації ) на всіх EVM-сумісних ланцюгах, що підтримують EIP-7702, за умови, що nonce також точно відповідає (.

Коли уповноважений підпише дані про авторизацію, ініціатор угоди збирає їх у полі authorization_list для підпису та транслює угоду через RPC. Перш ніж угода буде включена до блоку для виконання, Пропозер спочатку проводить попередню перевірку угоди, зокрема, проводить обов'язкову перевірку адреси to, щоб переконатися, що ця угода не є угодою на створення контракту, тобто при надсиланні угоди типу EIP-7702 адреса to не може бути пустою.

Одночасно такі транзакції будуть зобов'язані вимагати, щоб поле authorization_list у транзакції містило принаймні один елемент авторизації. Якщо кілька елементів авторизації підписані одним і тим же авторизатором, то в підсумку буде діяти лише останній елемент авторизації.

Потім, під час виконання транзакції, вузол спочатку збільшує значення nonce ініціатора транзакції, а потім виконує операцію applyAuthorization для кожного з авторизаційних записів у authorization_list. У операції applyAuthorization вузол спочатку перевіряє nonce авторизатора, а потім збільшує nonce авторизатора. Це означає, що якщо ініціатор транзакції та авторизатор є одним і тим же користувачем )EOA(, то при підписанні авторизаційної транзакції значення nonce має бути збільшено на 1.

При застосуванні певного авторизаційного запису вузлом, якщо виникає будь-яка помилка, цей авторизаційний запис буде пропущено, транзакція не зазнає невдачі, інші авторизаційні записи продовжать застосовуватися, щоб забезпечити уникнення ризику DoS у сценаріях масової авторизації.

Після завершення авторизації програми поле code адреси авторизатора буде встановлено на 0xef0100 || address, де 0xef0100 є фіксованим ідентифікатором, а address - адресою делегування. Через обмеження EIP-3541 користувачі не можуть звичайним способом розгортати контрактний код, що починається з байтів 0xef, що забезпечує, що такі ідентифікатори можуть бути розгорнуті лише за допомогою транзакцій типу SET_CODE_TX_TYPE ) 0x04(.

Після завершення авторизації, якщо авторизатор хоче скасувати авторизацію, він просто повинен встановити адресу цільового делегування на адресу 0.

Новий тип транзакцій, введений через EIP-7702, дозволяє авторизатору )EOA( виконувати код так, як це робить смарт-контракт, при цьому зберігаючи можливість ініціювати транзакції. На відміну від EIP-4337, це забезпечує користувачам досвід, який ближчий до рідної абстракції рахунків )Native AA(, що значно знижує поріг входження для користувачів.

Найкращі практики

Хоча EIP-7702 надає нову енергію екосистемі Ethereum, нові сценарії використання також можуть призвести до нових ризиків. Ось аспекти, на які учасники екосистеми повинні звернути увагу в процесі практики:

) зберігання приватного ключа

Навіть якщо EOA може вирішити проблему втрати коштів через втрату приватного ключа за допомогою вбудованого в смарт-контракт соціального відновлення тощо після делегування, все ж не можна уникнути ризику витоку приватного ключа EOA. Потрібно чітко усвідомлювати, що після виконання делегування приватний ключ EOA все ще має найвищу контрольну владу над рахунком; володіння приватним ключем дозволяє вільно розпоряджатися активами на рахунку. Навіть якщо користувач або постачальник гаманців повністю видалить збережений на локальному пристрої приватний ключ після завершення делегування для EOA, це не може повністю виключити ризик витоку приватного ключа, особливо в умовах ризику атаки на постачальницький ланцюг.

Для користувачів, при використанні рахунку після делегування, користувачі все ще повинні ставити захист приватних ключів на перше місце, завжди пам'ятати: Not your keys, not your coins.

Багатоланцюгове відтворення

Користувач при підписанні довіреності може вибрати ланцюг, на якому довіреність може набути чинності, за допомогою chainId, звичайно, користувач також може вибрати використання chainId рівного 0 для довіреності, що дозволяє довіреності відтворюватися на кількох ланцюгах, щоб користувач міг підписати один раз і здійснити довіреність на кількох ланцюгах. Але слід звернути увагу на те, що в одному й тому ж адресі смарт-контракту на кількох ланцюгах можуть бути різні реалізації коду.

Для постачальників послуг гаманців, під час делегування користувачами, слід перевірити, чи відповідає ланцюг дії делегування підключеній мережі, а також попередити користувачів про ризики, пов'язані з підписанням делегування з chainId, що дорівнює 0.

Користувачі також повинні звернути увагу на те, що однакові адреси контрактів на різних ланцюгах не завжди мають однаковий код контракту, тому спочатку слід зрозуміти мету делегування.

Не вдалося ініціалізувати

Поточні основні гаманці смарт-контрактів в основному використовують модель代理, при розгортанні гаманця代理, він буде використовувати DELEGateCALL для виклику функції ініціалізації контракту, досягаючи таким чином атомарної операції ініціалізації гаманця та розгортання代理-гаманця, уникаючи проблеми з передчасною ініціалізацією. Але коли користувач використовує EIP-7702 для делегування, він лише оновлює поле code своєї адреси, не може виконати ініціалізацію через виклик адреси делегата. Це робить EIP-7702 нездатним викликати функцію ініціалізації для ініціалізації гаманця під час транзакції розгортання контракту так, як це робить звичайний контракт代理 ERC-1967.

Для розробників, при поєднанні EIP-7702 з існуючим EIP-4337 гаманцем, слід звернути увагу на проведення перевірки прав під час ініціалізації гаманця ###, наприклад, через ecrecover для відновлення підписаної адреси для перевірки прав (, щоб уникнути ризику того, що ініціалізація гаманця буде перехоплена.

) Управління зберігання

Користувачі, використовуючи функцію делегування EIP-7702, можуть зіткнутися з необхідністю повторного делегування на іншу адресу контракту через зміни в вимогах функцій, оновлення гаманця тощо. Але структура зберігання різних контрактів може відрізнятися ###, наприклад, слот0 різних контрактів може представляти різні типи даних (. У випадку повторного делегування це може призвести до випадкового повторного використання даних старого контракту новим контрактом, що, в свою чергу, може викликати блокування рахунку, втрату коштів та інші негативні наслідки.

Для користувачів слід обережно поводитися з ситуацією повторного делегування.

Для розробників під час розробки слід дотримуватись формули простору назв, запропонованої 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 тощо, стикаються з численними викликами та можливостями в практичному застосуванні. Найкращі практики, викладені в цій статті, не можуть охопити всі потенційні ризики, але все ж заслуговують на увагу всіх сторін для застосування на практиці.