Ми розробили EIP7702Proxy, легкий проксі-контракт ERC-1967, призначений для базової логічної переадресації EIP-7702 для EOA... який вирішує деякі проблеми, унікальні для делегованих облікових записів EIP-7702. Ця стаття взята зі статті, написаної спільнотою Boardlink і складена, упорядкована та надана ForesightNews. (Синопсис: Ethereum Pectra оновлює «хакерський фліп», Wintermute попереджає: EIP-7702 автоматизує розгортання великої кількості контрактів) (Довідкове доповнення: «Проект безпеки на один трильйон доларів» Ethereum Foundation випустив перший звіт: Сортування смарт-контрактів, інфраструктури та хмарної безпеки... Шість екологічних викликів EIP-7702 дозволяє простим гаманцям Ethereum (EOA) перейти на гаманці зі смарт-контрактами, забезпечуючи більшу безпеку, розширені функції, можливості спонсорства газу та інші переваги. Історично склалося так, що розумні гаманці доводилося створювати з нуля, але з впровадженням EIP-7702 традиційні гаманці можуть бути модернізовані та зберігати всі свої активи та історію в ланцюжку з тією ж адресою гаманця. Це все одно, що переключитися зі стаціонарного телефону на смартфон без необхідності отримувати новий номер. EOA оновлюється шляхом встановлення «позначення делегування», тобто вказівника на смарт-контракт делегата, а потім делегування логіки смарт-контракту для керування EOA. В результаті, оновлений EOA може мати функції, встановлювати сховище, випромінювати події та виконувати всі інші операції, які може виконувати смарт-контракт. EOA може будь-коли змінити або видалити цього представника за допомогою нового, підписаного дозволу EIP-7702. Хоча це відкриває багато нових можливостей, ця потужна функція також створює нові виклики безпеці, які вимагають ретельного розгляду та інноваційних рішень. Щоб EOA могла виступати в якості гаманця для смарт-контрактів, ми розробили EIP7702Proxy, легкий проксі-контракт ERC-1967, призначений для виконання функцій делегата EIP-7702 для EOA. Окрім базової логічної пересилання, яку виконує агент, EIP7702Proxy містить додаткові функції та варіанти дизайну, які вирішують деякі проблеми, унікальні для делегованих облікових записів EIP-7702. Однією з цілей розробки EIP7702Proxy є підтримка якомога більшої пірованості між «стандартно розгорнутим» смарт-гаманцем Coinbase і делегованим розумним гаманцем Coinbase EIP-7702, що означає абстрагування додаткової складності, необхідної для механізму EIP-7702, у виділеному проксі та продовження покладатися на оригінальну реалізацію CoinbaseSmartWallet. Рішення цієї проблеми може бути ефективно застосовано до будь-якої логіки впровадження, а не тільки до реалізації CoinbaseSmartWallet, а також допомагаючи EOA залишатися в безпеці в середовищі з підтримкою 7702. Нижче ми представляємо конкретні проблеми та відповідні дизайнерські рішення, які дозволяють нам безпечно адаптувати будь-яку існуючу реалізацію гаманця смарт-контракту для оновлень EIP-7702. Проблема #1: Забезпечення безпечної ініціалізації Перша серйозна перешкода на шляху впровадження EIP-7702 пов'язана з його обмеженнями ініціалізації. Традиційні гаманці смарт-контрактів, включаючи CoinbaseSmartWallet, зазвичай обробляють безпечну ініціалізацію (встановлення права власності на обліковий запис) атомарно під час свого розгортання, як правило, за допомогою окремого заводського контракту. Ця атомарність означає, що багато таких реалізацій мають незахищені функції ініціалізатора, які можуть бути викликані лише один раз. Однак конструкція EIP-7702 не дозволяє виконувати дані виклику ініціалізації під час процесу делегування коду (еквівалентний крок «розгортання»), тому це не може бути зроблено атомарно. Такий поділ кроків створює критичне вікно вразливості. Коли контракт на впровадження «розгортається» на EOA через EIP-7702, немає гарантії, що стандартна транзакція EVM для цього гаманця оновлення та ініціалізації 7702 буде виконана атомарно. Технічно, навіть якщо він скоєний одночасно, код, який встановлює авторизацію, може бути незалежним від програми транзакції ініціалізації, що може дозволити зловмиснику превентивно виконати транзакцію ініціалізації та заявити про право власності на смарт-обліковий запис. Рішення: підпис EOA необхідний для атомарної конфігурації реалізації та ініціалізації Зверніть увагу, що існуючий смарт-гаманець Coinbase розгортається після проксі ERC-1967 з реалізацією UUPSUpgradeable (фактична логіка CoinbaseSmartWallet). Код у фактичній адресі облікового запису є проксі-сервером, який використовує звичайне місце зберігання, визначене ERC-1967, для зберігання вказівок на логіку його реалізації. Наше рішення уразливості ініціалізації в контексті 7702 включає в себе визнання того, що будь-яка логіка реалізації стає активною (і, отже, небезпечною) тільки тоді, коли агент дійсно встановлює з'єднання з нею. Отже, якщо ми не можемо примусово розгорнути та ініціалізувати atomicity, ми можемо примусово налаштувати та ініціалізувати реалізацію atomicity. Структура контракту EIP-7702CoinbaseSmartWallet і логічний процес делегування У контексті EIP-7702 сам EOA є початковим органом для внесення будь-яких змін до свого облікового запису, і необхідно надати підпис для авторизації будь-якого власника, який ініціалізує та встановлює новий обліковий запис Smart. Наш контракт EIP7702Proxy реалізує функцію setImplementation, яка атомарно налаштовує нові логічні реалізації та ініціалізує облікові записи. setImplementation function: перевіряє підпис з EOA, який включає ключові дані, такі як адреса нового контракту на впровадження, ініціалізовані calldata, адреса контракту валідатора, який оцінюватиме безпеку кінцевого стану облікового запису, а також базовий захист від повторного відтворення підпису, такий як nonce та час закінчення терміну дії. Встановіть значення покажчика ERC-1967 на нову реалізацію та виконайте надані дані виклику проти нової логічної реалізації. Викличте функцію validateAccountState, яка має бути реалізована сертифікатором, включеним до підпису. Валідатор – це специфічний для впровадження контракт, який містить логіку для оцінки, чи вважає він остаточний стан облікового запису безпечним. Наприклад, для CoinbaseSmartWallet CoinbaseSmartWalletValidator перевіряє, чи статус власності облікового запису не порожній і тому більше не вразливий до довільної ініціалізації. Проблема #2: Делеговане спільне сховище в EIP-7702 Найскладніші проблеми EIP-7702 можуть бути пов'язані з керуванням сховищем. EOA може в будь-який момент переделегувати свою логіку іншому контракту або повністю видалити делегата. Усі делегати діляться адресами EOA на...
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Забезпечення оновлення Ethereum EIP-7702: агентська модель безпечного переходу від EOA до розумного Гаманець.
Ми розробили EIP7702Proxy, легкий проксі-контракт ERC-1967, призначений для базової логічної переадресації EIP-7702 для EOA... який вирішує деякі проблеми, унікальні для делегованих облікових записів EIP-7702. Ця стаття взята зі статті, написаної спільнотою Boardlink і складена, упорядкована та надана ForesightNews. (Синопсис: Ethereum Pectra оновлює «хакерський фліп», Wintermute попереджає: EIP-7702 автоматизує розгортання великої кількості контрактів) (Довідкове доповнення: «Проект безпеки на один трильйон доларів» Ethereum Foundation випустив перший звіт: Сортування смарт-контрактів, інфраструктури та хмарної безпеки... Шість екологічних викликів EIP-7702 дозволяє простим гаманцям Ethereum (EOA) перейти на гаманці зі смарт-контрактами, забезпечуючи більшу безпеку, розширені функції, можливості спонсорства газу та інші переваги. Історично склалося так, що розумні гаманці доводилося створювати з нуля, але з впровадженням EIP-7702 традиційні гаманці можуть бути модернізовані та зберігати всі свої активи та історію в ланцюжку з тією ж адресою гаманця. Це все одно, що переключитися зі стаціонарного телефону на смартфон без необхідності отримувати новий номер. EOA оновлюється шляхом встановлення «позначення делегування», тобто вказівника на смарт-контракт делегата, а потім делегування логіки смарт-контракту для керування EOA. В результаті, оновлений EOA може мати функції, встановлювати сховище, випромінювати події та виконувати всі інші операції, які може виконувати смарт-контракт. EOA може будь-коли змінити або видалити цього представника за допомогою нового, підписаного дозволу EIP-7702. Хоча це відкриває багато нових можливостей, ця потужна функція також створює нові виклики безпеці, які вимагають ретельного розгляду та інноваційних рішень. Щоб EOA могла виступати в якості гаманця для смарт-контрактів, ми розробили EIP7702Proxy, легкий проксі-контракт ERC-1967, призначений для виконання функцій делегата EIP-7702 для EOA. Окрім базової логічної пересилання, яку виконує агент, EIP7702Proxy містить додаткові функції та варіанти дизайну, які вирішують деякі проблеми, унікальні для делегованих облікових записів EIP-7702. Однією з цілей розробки EIP7702Proxy є підтримка якомога більшої пірованості між «стандартно розгорнутим» смарт-гаманцем Coinbase і делегованим розумним гаманцем Coinbase EIP-7702, що означає абстрагування додаткової складності, необхідної для механізму EIP-7702, у виділеному проксі та продовження покладатися на оригінальну реалізацію CoinbaseSmartWallet. Рішення цієї проблеми може бути ефективно застосовано до будь-якої логіки впровадження, а не тільки до реалізації CoinbaseSmartWallet, а також допомагаючи EOA залишатися в безпеці в середовищі з підтримкою 7702. Нижче ми представляємо конкретні проблеми та відповідні дизайнерські рішення, які дозволяють нам безпечно адаптувати будь-яку існуючу реалізацію гаманця смарт-контракту для оновлень EIP-7702. Проблема #1: Забезпечення безпечної ініціалізації Перша серйозна перешкода на шляху впровадження EIP-7702 пов'язана з його обмеженнями ініціалізації. Традиційні гаманці смарт-контрактів, включаючи CoinbaseSmartWallet, зазвичай обробляють безпечну ініціалізацію (встановлення права власності на обліковий запис) атомарно під час свого розгортання, як правило, за допомогою окремого заводського контракту. Ця атомарність означає, що багато таких реалізацій мають незахищені функції ініціалізатора, які можуть бути викликані лише один раз. Однак конструкція EIP-7702 не дозволяє виконувати дані виклику ініціалізації під час процесу делегування коду (еквівалентний крок «розгортання»), тому це не може бути зроблено атомарно. Такий поділ кроків створює критичне вікно вразливості. Коли контракт на впровадження «розгортається» на EOA через EIP-7702, немає гарантії, що стандартна транзакція EVM для цього гаманця оновлення та ініціалізації 7702 буде виконана атомарно. Технічно, навіть якщо він скоєний одночасно, код, який встановлює авторизацію, може бути незалежним від програми транзакції ініціалізації, що може дозволити зловмиснику превентивно виконати транзакцію ініціалізації та заявити про право власності на смарт-обліковий запис. Рішення: підпис EOA необхідний для атомарної конфігурації реалізації та ініціалізації Зверніть увагу, що існуючий смарт-гаманець Coinbase розгортається після проксі ERC-1967 з реалізацією UUPSUpgradeable (фактична логіка CoinbaseSmartWallet). Код у фактичній адресі облікового запису є проксі-сервером, який використовує звичайне місце зберігання, визначене ERC-1967, для зберігання вказівок на логіку його реалізації. Наше рішення уразливості ініціалізації в контексті 7702 включає в себе визнання того, що будь-яка логіка реалізації стає активною (і, отже, небезпечною) тільки тоді, коли агент дійсно встановлює з'єднання з нею. Отже, якщо ми не можемо примусово розгорнути та ініціалізувати atomicity, ми можемо примусово налаштувати та ініціалізувати реалізацію atomicity. Структура контракту EIP-7702CoinbaseSmartWallet і логічний процес делегування У контексті EIP-7702 сам EOA є початковим органом для внесення будь-яких змін до свого облікового запису, і необхідно надати підпис для авторизації будь-якого власника, який ініціалізує та встановлює новий обліковий запис Smart. Наш контракт EIP7702Proxy реалізує функцію setImplementation, яка атомарно налаштовує нові логічні реалізації та ініціалізує облікові записи. setImplementation function: перевіряє підпис з EOA, який включає ключові дані, такі як адреса нового контракту на впровадження, ініціалізовані calldata, адреса контракту валідатора, який оцінюватиме безпеку кінцевого стану облікового запису, а також базовий захист від повторного відтворення підпису, такий як nonce та час закінчення терміну дії. Встановіть значення покажчика ERC-1967 на нову реалізацію та виконайте надані дані виклику проти нової логічної реалізації. Викличте функцію validateAccountState, яка має бути реалізована сертифікатором, включеним до підпису. Валідатор – це специфічний для впровадження контракт, який містить логіку для оцінки, чи вважає він остаточний стан облікового запису безпечним. Наприклад, для CoinbaseSmartWallet CoinbaseSmartWalletValidator перевіряє, чи статус власності облікового запису не порожній і тому більше не вразливий до довільної ініціалізації. Проблема #2: Делеговане спільне сховище в EIP-7702 Найскладніші проблеми EIP-7702 можуть бути пов'язані з керуванням сховищем. EOA може в будь-який момент переделегувати свою логіку іншому контракту або повністю видалити делегата. Усі делегати діляться адресами EOA на...