Вступ

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

EOA оновлюються шляхом встановлення "делегованого призначення", вказівника на смарт-контракт делегата, логіка якого потім керує EOA. Оновлені EOA можуть мати функції, встановлювати зберігання, генерувати події та робити все інше, що може робити смарт-контракт. EOA можуть змінювати або видаляти це делегування в будь-який час з новою, підписаною авторизацією EIP-7702. Хоча це відкриває багато нових можливостей, ця потужна функція також вводить нові виклики безпеки, які потребують ретельного розгляду та інноваційних рішень.

Щоб дозволити EOA діяти як гаманці смарт-контрактів, ми розробили EIP7702Proxy, легкийПроксі ERC-1967 контракт, розроблений для виконання ролі EIP-7702 делегата для EOA. На додаток до основного логічного пересилання, яке виконується проксі, EIP7702Proxy містить додаткові функції та дизайнерські рішення, які вирішують кілька викликів, унікальних для EIP-7702-делегованих рахунків. Метою розробки EIP7702Proxy було забезпечити максимально можливу паритетність між "стандартними" Coinbase Smart Wallets і EIP-7702-делегованими Coinbase Smart Wallets, що вимагало абстрагування додаткової складності, пов'язаної з механікою EIP-7702, у спеціалізований проксі та продовження покладання на оригінальну реалізацію CoinbaseSmartWallet. Рішення цієї проблеми може бути корисно застосовано до будь-якої логіки реалізації, а не тільки до реалізації CoinbaseSmartWallet, водночас допомагаючи EOA залишатися в безпеці в середовищі, що підтримує 7702.

Ми описуємо нижче конкретні виклики та відповідні дизайнерські рішення, які дозволяють нам безпечно адаптувати будь-яку існуючу реалізацію гаманця смарт-контрактів для використання в оновленнях EIP-7702.

Челендж #1: Забезпечення безпечної ініціалізації

Першою великою перешкодою в реалізації EIP-7702 є обмеження його ініціалізації. Традиційні гаманці смарт-контрактів, включаючи CoinbaseSmartWallet, зазвичай обробляють безпечну ініціалізацію (встановлення власності на рахунок) атомарно під час їх розгортання через окремий фабричний контракт. Ця атомарність означає, що багато таких реалізацій мають незахищені функції ініціалізації, які можуть бути викликані точно один раз. Однак дизайн EIP-7702 не дозволяє виконання calldata ініціалізації під час процесу делегування коду (порівняльний етап до "розгортання") і, отже, це не може бути зроблено атомарно.

Ця роздільність кроків створює критичне вікно вразливості. Коли контракт реалізації "розгортається" на EOA через EIP-7702, немає жодної гарантії, що це оновлення 7702 і стандартна транзакція EVM, яка ініціалізує гаманець, будуть виконані атомарно. Код, що встановлює авторизацію, технічно може бути застосований незалежно від транзакції ініціалізації, навіть якщо вони подані одночасно, і це може дозволити зловмиснику випередити транзакцію ініціалізації зі своїм власним навантаженням і заявити про право власності на смарт-обліковий запис.

Рішення: Вимагати підпис EOA для атомарного встановлення реалізації та ініціалізації

Зверніть увагу, що існуючі смарт-гаманці Coinbase розгорнуті заERC-1967 проксі зUUPSUpgradeable реалізація (фактична логіка CoinbaseSmartWallet). Код за фактичною адресою облікового запису є проксі, а проксі використовує звичайне місце зберігання, визначене ERC-1967, щоб утримувати вказівник на свою логіку реалізації. Наша рішення щодо вразливості ініціалізації в контексті 7702 полягає в розпізнаванні того, що будь-яка логіка реалізації стає активною (а отже, небезпечною) лише тоді, коли проксі фактично встановлює з'єднання з нею. Тому, якщо ми не можемо забезпечити атомарне розгортання з ініціалізацією, ми можемо натомість забезпечити атомарне налаштування реалізації з ініціалізацією.

Архітектура контракту CoinbaseSmartWallet EIP-7702 та логічний потік делегування

У контексті EIP-7702 EOA сам є початковим органом влади над будь-якими змінами до свого рахунку і має надати підпис для авторизації ініціалізації та встановлення будь-яких власників нового смарт-рахунку. Наш контракт EIP7702Proxy реалізує функцію setImplementation, яка може атомарно встановити нову логічну реалізацію та ініціалізувати рахунок. Функція setImplementation:

1. Перевіряє підпис від EOA на основі ключових даних, таких як адреса нового контракту реалізації, початкові дані для виклику, адреса контракту валідатора, який оцінюватиме безпеку отриманого стану рахунку, а також основні заходи захисту від повторного використання підписів, такі як nonce та термін дії.
2. Встановлює значення вказівника ERC-1967 на нову реалізацію та виконує надані calldata проти нової логічної реалізації
3. Викликає функцію validateAccountState, яка повинна бути реалізована валідатором, включеним у підпис.

Валідатор є контрактом, специфічним для реалізації, який містить логіку для оцінки того, чи вважає він отриманий стан рахунку безпечним. Наприклад, у випадку CoinbaseSmartWallet валідатор CoinbaseSmartWallet перевірить, чи є стан власності рахунку непорожнім, і, отже, більше не підлягає випадковій ініціалізації.

Виклик #2: Спільне сховище між делегатами EIP-7702

Можливо, найскладнішим викликом EIP-7702 є управління сховищем. EOA може вільно повторно делегувати свою логіку різним контрактам або повністю скасувати делегування в будь-який час. Усі делегати ділять один і той самий простір для зберігання за адресою EOA. Багато контрактів, які протягом часу мають доступ до одного і того ж сховища, можуть призвести до проблеми "колізії сховища". Колізії сховища виникають, коли два контракти вносять різні зміни до або роблять різні припущення щодо одного і того ж місця зберігання, що може призвести до непередбачуваних помилок.

Управління конфліктами зберігання вже є знайомою проблемою в просторі проєктування проксі, де змінна логіка реалізації використовується для управління спільним зберіганням. Хоча оновлювальні проксі можуть змінювати реалізації, сам код проксі (для адрес, що не є 7702) не може змінюватись. Це забезпечує певність та гарантії в процесі оновлення. Повторна делегація 7702 вводить ще один рівень повної змінності до потенційної логіки, яка може керувати цим спільним зберіганням. Це фактично усуває будь-які гарантії щодо ефекту, який може мати довільний делегат на зберігання. Наприклад, якщо EOA делегує від делегата A до B і назад до A, то повертаючий делегат не може робити припущення щодо стану свого зберігання, яке могло бути стерто або маніпульовано делегатом B до стану, якого не можна було б досягти лише за допомогою логіки делегата A. Це вірно для будь-якого делегата 7702, незалежно від шаблону делегування, оскільки попередній делегат міг зберігати або видаляти будь-що в будь-якому місці зберігання.

Приклад недійсного стану для DeleGate A, викликаного делегаційною схемою A → B → A

Рішення: Екстерналізація критичних для безпеки значень зберігання

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

Ми розробили EIP7702Proxy, щоб він був самозахисним проти передбачуваних проблем у багатогаманцевій, що підтримує 7702, екосистемі добрих, але потенційно хаотичних учасників. Він не може захистити EOA, які уповноважують дійсно зловмисних або несправних делегатів.

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

Загальний захист від повторного використання підписів використовує нонси в підписаних повідомленнях, які позначаються як спожиті після перевірки. Ризик для рахунків 7702: інші делегати можуть скомпрометувати це сховище відстеження нонса. Якщо знищується сховище відстеження використання нонса, підпис setImplementation EOA (публічно доступний у мемпулі) може бути повторно застосований під час делегування назад до EIP7702Proxy.

Щоб гарантувати нереплеюваність підписів, ми реалізували окремий NonceTracker singleton, який підтримує статус nonce в незмінному місці контракту поза сховищем облікового запису. Тільки EOA може впливати на свої nonce (тільки інкрементально), запобігаючи іншим делегатам маніпулювати цими критично важливими значеннями безпеки. NonceTracker забезпечує, що кожен підпис setImplementation працює лише один раз, незалежно від змін у сховищі облікового запису.

Виклик #3: Збільшений ризик спільних традиційних місць зберігання

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

Щоб більш чітко проілюструвати проблему, що вирішується, зверніть увагу, що коли рахунок переходить між різними делегатами (A→B→A), де обидва делегати реалізують шаблони проксі ERC-1967, делегат B природно використовуватиме ту ж саму зону пам'яті, яку використовував делегат A для зберігання адреси його реалізації. Протягом свого терміну делегат B може модифікувати або перезаписувати цю зону, як навмисно, так і в рамках своїх власних операцій проксі. У шаблоні UUPSUpgradeable логіка для оновлення реалізації визначається на самому контракті реалізації. Якщо реалізація, встановлена в цьому вказівнику делегатом B, не містить інтерфейс upgradeToAndCall, очікуваний на реалізації, тоді при поверненні до делегата A сам механізм зміни його реалізації може не існувати в поточній доступній логіці.

Приклад перезапису спільного традиційного місця зберігання новим deleGate

Рішення: Механізм оновлення доступний на EIP7702Proxy

Наш EIP7702Proxy вирішує це через свою функцію setImplementation, яка забезпечує механізм оновлення, незалежний від реалізації, безпосередньо на самому проксі. Це гарантує, що навіть якщо проміжний делегат вказав реалізацію ERC-1967 на недійсну реалізацію (або зовсім її видалив), оригінальний EOA, після делегування назад до EIP7702Proxy, зберігає можливість переналаштувати вказівник ERC-1967 проксі на їх обрану логічну реалізацію.

Виклик #4: Зворотна сумісність зі стандартною поведінкою EOA

Дизайнерською метою EIP7702Proxy було підтримання зворотної сумісності з функціональністю EOA облікового запису, а також новою функціональністю смарт-контракту. Наявність або відсутність коду за адресою може вплинути на потік виконання протоколів, які взаємодіють з адресою, оскільки вони базуються на цій якості для розрізнення між EOA та смарт-контрактами. Це вимагало врахування двох основних поведінок: перевірки підпису та поведінки отримання токенів.

Перевірка підпису

Смарт-контракти мають інший стандарт для валідації підписів, ніж стандартні EOA. Смарт-контракти реалізують інтерфейс isValidSignature, визначений ERC-1271 і можуть вільно визначати довільну логіку, яка визначає, чи вважає контракт підпис дійсним. Для стандартних EOA підпис перевіряється за стандартною перевіркою ecrecover, яка забезпечує, що підписувач відновлюється до очікуваної адреси EOA.

Щоб забезпечити визнання існуючих або майбутніх підписів EOA після оновлення 7702, EIP7702Proxy реалізує версію isValidSignature, яка спочатку делегує перевірку підпису функції isValidSignature, яка повинна бути визначена в логічній реалізації, але слідує за невдалою перевіркою з остаточною перевіркою ecrecover. Якщо це проходить, підпис вважається дійсним. Таким чином, EOA, що використовують EIP7702Proxy, можуть гарантувати, що прості підписи EOA завжди будуть визнані за їх адресою незалежно від реалізації isValidSignature їхнього смарт-контрактного гаманця.

Отримання токена

Деякі стандарти токенів (конкретно ERC-1155 і ERC-721) спроба захистити від зависання токенів у смарт-контрактах, які можуть не мати можливості їх керувати. Ці токени вимагають, щоб будь-який смарт-контракт, який отримуватиме такі токени, оголосив про цю можливість, реалізувавши стандартні інтерфейси отримувачів токенів, які викликаються контрактом токена під час передачі токена. Також важливо, щоб логіка в оновленому EOA містила стандартну функцію отримання або платіжний зворотний виклик, щоб мати можливість отримувати нативні токени. Обліковий запис ніколи не повинен бути в стані, що залишає його нездатним отримувати ETH або інші токени, хоч би й на короткий час.

Оскільки наш проксі не має початкової реалізації, ми включаємо незмінну реалізацію DefaultReceiver як стандартну логіку для EIP7702Proxy за відсутності вказівника ERC-1967. Цей приймач реалізує функцію отримання та гачки приймача для цих загальних стандартів токенів, що забезпечує можливість рахунку приймати токенові перекази до чіткого встановлення нової реалізації.

Висновок

Дизайн EIP7702Proxy дозволяє нам підтримувати близьку паритетність зі стандартними деплойменти CoinbaseSmartWallets та продовжувати використовувати існуючу реалізацію CoinbaseSmartWallet, вирішуючи унікальні проблеми безпеки, які виникають у контексті EIP-7702. Ретельно розглянувши безпеку ініціалізації, наслідки імперманентності зберігання та завади, необхідність безперервної обробки токенів та зворотну сумісність зі стандартною перевіркою підписів EOA, ми створили проксі для безпечного делегування та управління гаманцями смарт-контрактів EIP-7702. Хоча EIP7702Proxy був спроектований з урахуванням реалізації CoinbaseSmartWallet V1, цей проксі в кінцевому підсумку є незалежним від реалізації. Ми закликаємо розробників оцінити це рішення для 7702-proofing інших реалізацій гаманців смарт-контрактів.

Застереження:

1. Ця стаття перепублікована з [Блог базової інженерії]. Всі авторські права належать оригінальному автору [Amie Corso]. Якщо є заперечення щодо цього повторного видання, будь ласка, зв'яжіться з Gate Learn команда, і вони вирішать це швидко.
2. Відмова від відповідальності: Думки та погляди, висловлені в цій статті, є виключно думками автора і не є інвестиційною порадою.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не вказано інше, копіювання, розповсюдження або плагіат перекладених статей заборонено.