Система управління Ethereum - це модель VVRC, будь-яка пропозиція повинна спочатку відповідати цінностям Ethereum (Value).
Автор: shew
Огляд
Під час оновлення Pectra виникла найскладніша проблема управлінських суперечок. Коли EIP3074 було включено в оновлення Pectra, це спричинило величезні суперечки, особливо з боку команди ERC4337.
EIP3074 потрапив у безвихідь, процес управління не може продовжуватися. Поки Віталік не запропонував EIP7702, що поклало кінець запереченням команди ERC4337 щодо EIP3074.
GCC Research виявив, що питання управління EIP3074 та ERC7702 в оновленні Pectra мало обговорюється в китайському світі. Але це питання управління також відображає глибокі проблеми управління Ethereum, а саме, хто може контролювати конкретний зміст коду за умови, що код є законом. Питання управління EIP3074 та ERC7702 можуть дати нам чудову перспективу для спостереження за реальними процесами управління всередині Ethereum.
Остаточним висновком цієї статті є парафраз зі статті, опублікованої ZeroDev, в якій стверджується, що система управління Ethereum є моделлю VVRC, і що включення будь-якої пропозиції має спочатку узгоджуватися з цінностями Ethereum (Value), а потім пропозиція повинна відображати бачення, розроблене Віталіком (Vision), остаточна пропозиція повинна бути відображена в дорожній карті (Roadmap) і, нарешті, обговорена основними розробниками і включена в клієнт (Client) Реалізація.
У статті, представленій GCC Research, було зазначено, що EIP2537 зіткнувся з проблемами реалізації на рівні клієнта, що призвело до затримки його включення в хардфорк, тоді як EIP3074 не був включений у хардфорк через проблеми з баченням та дорожньою картою, і основні розробники Ethereum безпосередньо вибрали EIP7702, написаний Віталіком, як остаточну пропозицію щодо абстракції рахунків.
Огляд змісту пропозиції
Перед тим як представити конкретний процес управління, спочатку потрібно коротко ознайомити з конкретним змістом, що стосується EIP3074, EIP7702 та ERC4337.
EIP3074 – це пропозиція рівня виконання, виконання якої вимагає оновлення програмного забезпечення вузла. Основною метою EIP3074 є забезпечення спонсорства газу та оптової торгівлі. Так зване спонсорство газу означає, що користувачі можуть сплачувати комісію за газ будь-яким токеном, або користувачі можуть сплачувати комісію за газ офлайн. Однак слід зазначити, що EIP3074 не дозволяє користувачам використовувати будь-який алгоритм підпису, відмінний від secp256k1, порівняно з іншими пропозиціями абстракції облікового запису, які дозволяють змінювати алгоритм перевірки підпису. Іншими словами, EIP3074 не є пропозицією, яка задовольняє всім абстракціям рахунку. Це також момент, за який EIP3074 критикують.
Щоб досягти очікуваних цілей, EIP3074 вводить два опкодів: AUTH і AUTHCALL. Зокрема, опкод AUTH може перевіряти підпис, і коли перевірка підпису пройшла успішно, цей опкод налаштує адресу authorized у контексті EVM на адресу підписанта. Коли адреса authorized налаштована в контексті, AUTHCALL може використовувати адресу authorized як msg.sender для ініціювання транзакції. В певному сенсі, користувач може через підпис делегувати свій рахунок для використання в транзакції смарт-контракту. Зазвичай ми називаємо цей смарт-контракт, якому користувач делегує, invoker контрактом.
Що конкретно містить підпис користувача? Користувачеві потрібно підписати таке:
!
Вищезазначений invoker address означає адресу invoker контракту, яку користувач бажає делегувати. EVM перевірить, чи відповідає підпис користувача дійсному контракту для перевірки підпису, щоб уникнути використання підпису AUTH користувача іншим контрактом.
Нонсе, з іншого боку, є ідентифікатором, який запобігає повторному відтворенню транзакцій. Однак слід зазначити, що код операції AUTH перевірятиме, чи відповідає nonce у підписі nonce поточного підписаного EOA, і теоретично, якщо користувач не використовує обліковий запис EOA для ініціювання транзакції для збільшення значення nonce, то підпис AUTH, виданий користувачем, завжди може бути використаний контрактом виклику. Це величезна вразливість системи безпеки, яка означає, що користувачі, які використовують EIP3074, повинні довіряти постачальнику послуг ретрансляції, який отримує підпис. Якщо постачальник послуг ретрансляції, який отримує підпис користувача, є зловмисним, постачальник послуг може в якийсь момент повторно відтворити підпис AUTH користувача, щоб викрасти активи користувача.
Ще однією проблемою безпеки є поле коміту. Поле коміту використовується для гарантування певних операцій, і користувачі можуть точно налаштувати контроль над своїми дозволами на підпис у коміті, наприклад, написання певного вмісту в коміті, щоб запобігти використанню вмісту підпису для переказів ETH. У документі EIP3074 ініціатор наводить серію прикладів використання поля коміту. Але проблема полягає в тому, що роль коміту повністю залежить від визначення смарт-контракту і, по суті, є необов'язковим вмістом. Різні смарт-контракти можуть аналізувати вміст коміту абсолютно непослідовно, а деякі контракти можуть взагалі не читати вміст коміту. Якщо ви хочете використовувати EIP3074 безпечно, вам потрібно просто переглянути смарт-контракт самостійно.
Нарешті, давайте подивимося на вплив EIP3074 на поточний мемпул транзакцій Ethereum. З введенням EIP3074 хакер може використовувати велику кількість облікових записів для ініціювання транзакцій, а потім використовувати EIP3074 транзакції для зливу ETH на цих рахунках відразу, коли транзакція збирається бути упакована, що призведе до збою всіх раніше ініційованих транзакцій. Цей тип атаки може мати значний вплив на вузли виконавчого рівня і, по суті, є DoS-атакою. Слід, однак, зазначити, що EIP7702, який використовується для заміни EIP3074, також має цю проблему, але EIP7702 вводить деякі обмеження, щоб уникнути цієї проблеми, про які ми поговоримо пізніше.
Окрім проблем, пов'язаних з EIP3074, про які згадувалося раніше, автор ERC4337 Yova у статті "Implications of EIP-3074 inclusion" навів більше заперечень. Простими словами, ці заперечення в основному включають:
Ризик централізації. Через особливі властивості AUTH підпису, користувачі повинні повністю довіряти релієвим постачальникам та підґрунтям EIP3074. Водночас, на даний момент інфраструктура, побудована на таких протоколах абстракції рахунків, як ERC4337, зовсім не є сумісною з EIP3074.
Безпека користувачів. Як було зазначено вище, EIP3074 не має єдиного методу контролю доступу, а також дизайн nonce підпису має безпекові вади, що може призвести до серйозних проблем з безпекою.
Неповна функціональність абстракції рахунків. У порівнянні з іншими пропозиціями абстракції рахунків, EIP3074 є неповним і не може реалізувати такі функції, як зміна алгоритму підпису користувача.
Існують проблеми з користувацьким досвідом. Коли користувачеві потрібно передати свій рахунок смарт-контракту, користувачу потрібно виконати один AUTH підпис, а потім опублікувати виклик, що містить AUTH підпис, на ланцюгу. Користувачеві потрібно виконати два підписи.
EIP7702 – пропозиція Віталіка замінити EIP3074. Замість того, щоб вводити новий код операції EVM, пропозиція вводить новий тип транзакції, який називається SET_CODE_TX_TYPE. Після того, як користувач ініціює EIP7702 тип транзакції, користувач може додати функціональність смарт-контракту до свого EOA, зберігши при цьому базову функціональність EOA. Простіше кажучи, користувачі можуть або продовжувати ініціювати транзакції за допомогою таких гаманців, як MetaMask, або інші користувачі можуть викликати адреси EOA у формі смарт-контрактів.
Давайте розглянемо особливості EIP7702 на простому прикладі оптової торгівлі. Користувачі можуть використовувати EIP7702 для делегування своєї EOA-адреси смарт-контракту, який може виконувати масові виклики, а потім користувачі можуть безпосередньо дзвонити на свою адресу EOA у формі смарт-контракту для ініціювання масових транзакцій.
З технічної точки зору, новий тип транзакцій, введений EIP7702, порівняно з традиційними транзакціями, містить список authorization_list, який складається з [[chain_id, address, nonce, y_parity, r, s], ...]. Де address - це адреса смарт-контракту, яку користувач хоче делегувати, а nonce - це поточне значення nonce користувача. Інші параметри y_parity, r і s - це результати підпису користувача. У процесі виконання ми спочатку обробляємо кожен елемент у списку authorization_list, відновлюючи EOA-адресу за допомогою параметрів підпису, таких як y_parity, а потім вказуємо EOA-адресу на смарт-контракт за адресою address. Після цього EOA-адреса може приймати виклики для реалізації функцій контракту.
Переваги EIP7702 дуже очевидні, причому найбільшою перевагою є те, що EIP7702 по суті дозволяє EOA мати функціональність смарт-контракту. Це відповідає основним правилам абстракції рахунків, таким як ERC4337, що означає, що EIP7702 може використовувати всі дослідження в області абстракції рахунків і повторно використовувати наявну інфраструктуру, наприклад, EIP7702 може безпосередньо використовувати інфраструктуру ERC4337. Наразі ERC4337 вже випустив EntryPoint v0.8, що підтримує виклики EIP7702. З точки зору повторного використання наявної інфраструктури, EIP7702 має таку ж ступінь децентралізації, як і ERC4337.
Звичайно, EIP7702 також не зовсім вирішує проблеми, які виникають у EIP3074. Проблеми, які існують в більшості EIP3074 все ще існують. EIP7702 вимагає, щоб контракт облікового запису мав безпечну реалізацію, а сам протокол не гарантує жодної безпеки. У перші дні EIP7702 року деякі розробники пропонували стандартизувати підписні нонцеси, щоб уникнути можливих повторних атак, але EIP7702 також не прийняли ці пропозиції. Тому, якщо користувач хоче безпечно використовувати EIP7702, то користувачеві потрібно самостійно переглянути безпеку контракту.
Одночасно EIP7702 також принесе ряд проблем для виконавчого шару. У згаданому вище ми описали один з можливих способів використання EIP3074 для DoS-атаки на пул пам'яті виконавчого шару. Цей метод також є дієвим в EIP7702. Тому EIP7702 рекомендує всім EOA-адресам, які використовують EIP7702, мати лише одну непідтверджену транзакцію в пулі пам'яті, щоб уникнути масових DoS-атак.
Отже, найбільшою проблемою EIP3074 є те, що EIP3074 не реалізує повноцінну функцію абстракції облікових записів, тоді як EIP7702 реалізує повну функцію абстракції облікових записів. А визначення "повної абстракції облікових записів" містить саме те, що автори ERC4337. Прочитавши це, читач має зрозуміти, чому команда ERC4337 виступила проти EIP3074, в результаті чого EIP7702 замінив його. У подальшому ми розглянемо весь процес загального управління та обговорення.
Процес управління EIP3074 та EIP7702
EIP3074 було згадано на ранніх зустрічах розробників ядра Ethereum. 2 квітня 2021 року на засіданні #109 розробники ядра Ethereum провели просту дискусію щодо EIP3074. Результати обговорення були дуже простими:
Алексей висловив занепокоєння щодо безпекових ризиків, пов'язаних з вмістом підпису EIP3074, що може призвести до серйозних фінансових втрат для користувачів. Він рекомендує подальшу нормалізацію конкретного вмісту підпису AUTH у EIP3074. Цю пропозицію підтримав Мартін.
Джеймс提出 EIP3074可能 принести потенційні уразливості на рівні виконання, такі як атаки DoS тощо, рекомендує EIP3074 надати письмовий аналіз загроз.
Alexey та Martin скаржаться на середню якість документації EIP3074, витративши багато часу на читання та розуміння
Мартін вважає, що основою EIP3074 є співпраця та реалізація з додатками, особливо з розробниками гаманців. Автори EIP3074 заявили, що вже провели серію обговорень з розробниками додатків.
Цікаво, що Віталік на цій конференції вважає, що в будь-якому випадку Ethereum потребує технічного рішення для генерації кількох викликів з однієї транзакції, спроектованої для EOA. Хоча EIP3074 має потенційні проблеми з безпекою, EIP3074 пропонує можливе технічне рішення, і розробники повинні рухатися вперед на основі EIP3074.
Очевидно, що через проблеми безпеки EIP3074 ця зустріч не включила EIP3074 до оновлення London.
На засіданні #115, яке відбулося 11 червня 2021 року, розробники EIP3074 подали звіт з питань безпеки. На засіданні основна увага приділялася питанням безпеки EIP3074. Простий висновок полягає в тому, що контракт invoker EIP3074 є надзвичайно важливим для системи, тому питання управління контрактом invoker є актуальним. Розробники EIP3074 сподіваються на формальне доведення контракту invoker, щоб підвищити безпеку.
Звичайно, є також частина дискусії про те, що деякі контракти використовують msg.sender == tx.origin для визначення, чи є адреса виклику EOA, і коли EIP3074 буде введено, ці рішення будуть визнані недійсними, але висновок полягає в тому, що невиконання цієї частини судового рішення не викличе серйозних проблем з безпекою. Коротко кажучи, зустріч була зосереджена на тому, щоб EIP3074 доповідачів представили основні розробникам результати аудиту безпеки 3074. Остаточний висновок зустрічі полягав у тому, що 3074 все ще потрібно розглянути питання контракту invoker, і рекомендується не приєднуватися до лондонського хардфорку.
На зустрічі #116 25 червня 2021 року Йова, основний автор ERC4337, представила аргументи на користь простішої альтернативи EIP 3074, в якій вказала, що в EIP3074 є багато проблем безпеки, і запропонувала змінити деякі з них, наприклад, обмежити вміст поля коміту в підписі, вимагаючи, щоб поле коміту було {nonce,to,gas, calldata,value,chainid}. За допомогою цього шаблону підпису EIP3074 можна використовувати лише для виконання певних конкретних транзакцій, щоб забезпечити їх безпеку.
У цьому засіданні автор EIP3074 відповів на матеріали, подані Yova:
Сподіваюсь, що адресу контракту invoker внесуть до стандарту EIP, а потім основні розробники Ethereum напишуть безпечний контракт invoker, щоб уникнути проблем з безпекою.
Щодо змісту commit у підписі, розробники EIP3074 вважають, що це повністю проблема користувача та програмного забезпечення гаманця, і не потрібно вводити стандарти в EIP.
Віталік на цій конференції提出了 наступні три пункти:
EIP3074 все ще використовує традиційну схему підпису secp256k1, що не може реалізувати антиквантові властивості.
EIP3074 не має майбутньої сумісності, використання EIP3074 також не дозволяє EOA еволюціонувати в обліковий запис смарт-контракту.
EIP3074 має обмежений життєвий цикл. 3074 ПРЕДСТАВЛЯЄ ДВА ПОПЕРЕДНЬО ЗІБРАНИХ КОДУ, AUTH І AUTHCALL, АЛЕ ЗГІДНО З ДОРОЖНЬОЮ КАРТОЮ АБСТРАКЦІЇ ОБЛІКОВОГО ЗАПИСУ, ВСІ ГАМАНЦІ В ETHEREUM МОЖУТЬ БУТИ ГАМАНЦЯМИ СМАРТ-КОНТРАКТІВ У МАЙБУТНЬОМУ, А КОД EIP3074 ПОПЕРЕДНЬОЇ ЗБІРКИ БУДЕ ЗАСТАРІЛИМ У МАЙБУТНЬОМУ
На зустрічі #131 4 лютого 2022 року розробники обговорили типи EIP, які повинні бути включені в оновлення ShangHai. EIP3074 було включено в обговорення, але розробники просто синхронізували розробку EIP3074. Примітно, що до зустрічі nethermind писав гаманці Ethereum сьогодні і завтра - EIP-3074 vs. ERC-4337, які не містили заперечень проти EIP3074.
На зустрічі #167 3 серпня 2023 року основні розробники обговорювали інший EIP5806, згадуючи про EIP3074. EIP5806 – це пропозиція, яка дозволяє EOA використовувати deleGate.io call для виклику зовнішніх контрактів під час транзакцій. Цей підхід в якомусь сенсі схожий на EIP7702. Але основні розробники також висловили сумніви щодо безпеки цього рішення, Ansgar зазначив, що EIP3074 ніколи не міг бути включений до жорсткого форку через можливі проблеми з безпекою, в той час як EIP5806 є більш радикальним варіантом.
На засіданні #182, яке відбулося 29 лютого 2024 року, розробники детально обговорили, чи має EIP3074 бути включений до оновлення Pectra. Віталік висловив думку, що будь-який стандарт абстракції рахунків має мати такі три функції:
Заміна ключів
Відмова від ключа
Може підтримувати квантовий підпис
Коментарі Віталіка щодо EIP5806 можуть бути кращим варіантом, ніж EIP3074. Андрій вважає, що EIP3074 більш універсальний, ніж EIP5806, і рекомендує використовувати EIP3074. Віталік заперечує Ендрю, стверджуючи, що всі гаманці в майбутньому можуть бути гаманцями смарт-контрактів, і що якщо це станеться, попередньо зібраний код операції, введений EIP3074, буде визнаний недійсним. Йоав, автор ERC4337, виступив на конференції з розлогою доповіддю, яка охопила такі теми:
EIP3074 може призвести до DoS-атаки на пам'яті Ethereum, тоді як ERC4337 провів багато досліджень у цій частині та надав деякі правила для уникнення атак.
EIP3074 вимагає підпису двічі, коли користувач ініціює пакетну транзакцію, що є необґрунтованим.
EIP3074 вимагає використання централізованих ретрансляторів
Yova більше схильна використовувати EIP5806 як схему абстракції облікового запису.
Inside Meeting #183 14 березня 2024 року основні розробники запросили Дена Фінлі з MetaMask обговорити, що гаманець думає про EIP3074. Ден виступає за EIP3074, зазначаючи, що MetaMask також підтримуватиме тестування EIP3074. MetaMask вважає, що EIP3074 може функціонально дозволити EOA насолоджуватися повною функціональністю абстракції облікового запису. З точки зору безпеки, EIP3074 надає рішення для постачальників послуг гаманця, тобто поділ гарячих і холодних ключів. Постачальник послуг гаманця може зберігати EIP3074 підпис EOA, щоб ініціювати транзакцію, і користувачі можуть використовувати гарячий закритий ключ у звичайних транзакціях, але холодний приватний ключ може зберігатися в апаратному гаманці користувача, і коли буде виявлено надзвичайну ситуацію, користувач може використовувати холодний приватний ключ у холодному гаманці, щоб ініціювати транзакцію, щоб відкликати підпис EIP3074. Це рішення гарячого та холодного поділу приватних ключів дає гнучкість постачальникам гаманців.
Віталік зазначає, що в рамках EIP3074 розробники гаманців повинні розробити сувору логіку авторизації, щоб уникнути неправомірного використання підписів EIP3074 користувачів. Цікаво, що, обговорюючи здатність MetaMask додавати EIP3074 функціональність, Віталік зазначив, що L2 можна використовувати як перехідне рішення, тобто будь-які нові зміни рівня виконання повинні бути реалізовані спочатку в межах L2, оскільки L2 має обмежене фінансування і може завдати серйозних збитків, навіть якщо щось піде не так.
Дрор Тірос у дискусії зазначив, що найкращий спосіб забезпечити безпеку EIP3074 – це коли офіційний Ethereum безпосередньо надає invoker контракт. Але Дан Фінлей виступає проти надання контракту від офіційних осіб, вважаючи, що invoker контракт повинен повністю визначатися користувачами, а ринок врешті-решт вибере найбезпечніший invoker контракт.
Ансгар, як і раніше, наполягає на тому, що EIP3074 один підпис повинен відповідати лише одній транзакції, а постачальники послуг гаманців не повинні повторно використовувати підписи користувачів для ініціювання транзакцій, але Ден Фінлі також заперечив. Ден Фінлей вважає, що EIP3074 повинні бути підписані холодним гаманцем, і тоді постачальник послуг гаманця може повторно використовувати підпис для ініціювання транзакцій безпосередньо для користувача, і якщо користувачеві потрібно повторно підписувати кожен раз, холодний приватний ключ може використовуватися кілька разів. Це не узгоджується з ідеєю розділення гарячих і холодних закритих ключів.
На цій зустрічі основні розробники обговорили ще одну важливу тему — списки включення. Списки включення є засобом для підвищення антикорупційних властивостей Ethereum. Простими словами, списки включення дозволяють деяким транзакціям бути обіцяними для прямого включення в наступний блок. Але основні розробники зазначили, що EIP3074 суперечить спискам включення.
На внутрішньому засіданні Meeting #185, що відбулося 11 квітня 2024 року, більшість реалізацій клієнтів погодилася на включення EIP3074 до жорсткого хардфорку Pectra, але Geth висловив заперечення, оскільки EIP3074 може призвести до проблем з деревом Verkle. Danno також висловив заперечення, оскільки EIP3074 може викликати випадки повторного використання підписів. Yoav також висловив заперечення, надавши план атаки на пам'яті за допомогою EIP3074 та Blob-транзакцій. Простими словами, зловмисник може ініціювати велику кількість Blob-транзакцій, які містять велику кількість даних, а потім використовувати EIP3074, щоб анулювати всі ці Blob-транзакції.
Коротко кажучи, на цій зустрічі всі розробники клієнтів погодилися, що EIP3074 буде включено в остаточне оновлення.
На зустрічі #187 9 травня 2024 року основні розробники вперше обговорили питання заміни EIP7702 EIP3074. EIP7702 було зроблено в перші 90 хвилин зустрічі розробників Vitalik. Під час конференції розробники ядра визнали EIP7702 кращим стандартом, ніж EIP3074. На цій зустрічі не було спротиву EIP7702, але деякі дослідники вважали, що EIP7702 також мають безповоротні атрибути, подібні до EIP3074, що може призвести до проблем з фінансовою безпекою.
На зустрічі #188 23 травня 2024 року основні розробки обговорили можливість заміни EIP3074 на EIP7702. Остаточним завершенням зустрічі була заміна EIP3074 на EIP7702 як стандарт абстракції облікового запису в хардфорку Pectra. Віталік зазначає, що EIP7702 також має певну безповоротність, що відповідає EIP3074, атрибутам, які багато обговорювалися в обговоренні EIP3074. Цікаво, що на засіданні була велика кількість ERC4337 делегатів.
Насправді, обговорення заміни EIP3074 на EIP7702 було широко обговорено ще до 188-ї зустрічі основних розробників, і тоді було вирішено, що 3074 буде замінено, тому на зустрічі основних розробників не було великої суперечки.
Дорожня карта та рішення
Zerodev, основна інфраструктура абстракції облікових записів, опублікував цікаву статтю під назвою «Роздуми про управління Ethereum після саги 3074», дізнавшись, що EIP3074 буде замінено, зробивши висновок, що EIP7702 хороша пропозиція, яка приносить користь усім користувачам. Однак процес управління для EIP7702 замінити EIP3074 не є оптимальним з низки причин, зокрема:
EIP3074 пройшов тривалий процес обговорення, у попередньому тексті ми вже представили EIP3074 у багатьох обговореннях на зустрічах основних розробників.
Після того як EIP3074 був затверджений для включення в оновлення Pectra, він отримав значну опозицію з боку спільноти ERC4337. Звичайно, у вищезгаданому ми вже вказали, що основний розробник ERC4337 yova неодноразово висловлював свою опозицію EIP3074 на засіданнях основних розробників.
Zerodev вважає, що найкращий шлях управління повинен полягати в тому, щоб спільнота ERC4337 широко брала участь і висловлювала свої думки в процесі тривалого обговорення основних розробників EIP3074.
Розробники EIP3074 вважають, що ERC4337 має нести відповідальність за невдачу в управлінні. Оскільки EIP3074 активно брала участь в управлінні протягом останніх кількох років і неодноразово спілкувалася з основним розробником ERC4337 yova.
З іншого боку, ERC4337-спільнота вважає, що EIP3074 несе основну відповідальність за невдачі в управлінні. ERC4337 члени спільноти вважають, що Йова, як основний розробник ERC4337, висловлювалася проти EIP3074 на кількох основних зборах розробників, але основний розробник, схоже, не слухає. Більшість членів спільноти в ERC4337 не звертають уваги на динаміку управління EIP3074, і більшість членів погоджуються, що EIP3074 є мертвим стандартом. Спільнота ERC4337 також відчула, що основні розробники не ведуть активної комунікації з ERC4337-спільнотою.
EIP3074 та ERC4337 вважають, що вони виконали правильну управлінську роботу, а інша сторона повинна нести основну відповідальність за провал управління. Очевидно, що в цьому процесі управління існує більш глибока причина, яка впливає на ситуацію.
Простіше кажучи, ця глибша причина насправді є дорожньою картою Ethereum. Дорожня карта Ethereum має більше повноважень, ніж основна зустріч розробників. Дорожня карта абстракції облікового запису орієнтована на ERC4337. EIP7702 повністю сумісний зі стандартом ERC4337, але EIP3074 не повністю сумісний зі стандартом ERC4337. Отже, з точки зору дорожньої карти Ethereum, EIP3074 заміна обов'язково відбудеться.
Звичайно, дорожня карта Ethereum є відображенням особистого бачення Віталіка щодо майбутнього Ethereum. Якщо в процесі управління Ethereum виникають серйозні суперечки, то як визначник дорожньої карти Віталік має остаточне право на ухвалення рішення. Саме рішення Віталіка призвело до заміни EIP3074.
Управлінська модель Ethereum - це модель values ⇒ vision ⇒ roadmaps ⇒ clients, або, коротко, модель VVRC. Процес управління виглядає наступним чином:
цінності цінності, особливо цінності спільноти, цінності спільноти Ethereum включають децентралізацію, опір цензурі тощо.
vision Візія, насправді це особисті роздуми Віталіка про майбутнє Ethereum
дорожні карти, дослідник на основі бачення надає деякі технічні деталі та пропонує більш повну реалізацію дорожньої карти
реалізація клієнтів, основні розробники клієнтів обговорюють дорожню карту за допомогою таких інструментів, як зустрічі основних розробників, та реалізують вимоги, що містяться в дорожній карті.
Вищезгаданий процес є справжнім процесом управління Ethereum. Ми можемо бачити, що особисте бачення Віталіка розташоване в основній частині моделі управління Ethereum, тому, як тільки в реалізації клієнта виникнуть серйозні суперечки, особиста думка Віталіка буде остаточною.
Джерела
ZeroDev Вступ
null
Введення до ZeroDev
null
Примітки щодо дорожньої карти абстракції облікового запису - HackMD
Примітки щодо дорожньої карти абстракції облікового запису *Особлива подяка Віталіку та команді AA за відгуки
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Управління війною: EIP3074, ERC4337 та EIP7702｜GCC Research
Автор: shew
Огляд
Під час оновлення Pectra виникла найскладніша проблема управлінських суперечок. Коли EIP3074 було включено в оновлення Pectra, це спричинило величезні суперечки, особливо з боку команди ERC4337.
EIP3074 потрапив у безвихідь, процес управління не може продовжуватися. Поки Віталік не запропонував EIP7702, що поклало кінець запереченням команди ERC4337 щодо EIP3074.
GCC Research виявив, що питання управління EIP3074 та ERC7702 в оновленні Pectra мало обговорюється в китайському світі. Але це питання управління також відображає глибокі проблеми управління Ethereum, а саме, хто може контролювати конкретний зміст коду за умови, що код є законом. Питання управління EIP3074 та ERC7702 можуть дати нам чудову перспективу для спостереження за реальними процесами управління всередині Ethereum.
Остаточним висновком цієї статті є парафраз зі статті, опублікованої ZeroDev, в якій стверджується, що система управління Ethereum є моделлю VVRC, і що включення будь-якої пропозиції має спочатку узгоджуватися з цінностями Ethereum (Value), а потім пропозиція повинна відображати бачення, розроблене Віталіком (Vision), остаточна пропозиція повинна бути відображена в дорожній карті (Roadmap) і, нарешті, обговорена основними розробниками і включена в клієнт (Client) Реалізація.
У статті, представленій GCC Research, було зазначено, що EIP2537 зіткнувся з проблемами реалізації на рівні клієнта, що призвело до затримки його включення в хардфорк, тоді як EIP3074 не був включений у хардфорк через проблеми з баченням та дорожньою картою, і основні розробники Ethereum безпосередньо вибрали EIP7702, написаний Віталіком, як остаточну пропозицію щодо абстракції рахунків.
Огляд змісту пропозиції
Перед тим як представити конкретний процес управління, спочатку потрібно коротко ознайомити з конкретним змістом, що стосується EIP3074, EIP7702 та ERC4337.
EIP3074 – це пропозиція рівня виконання, виконання якої вимагає оновлення програмного забезпечення вузла. Основною метою EIP3074 є забезпечення спонсорства газу та оптової торгівлі. Так зване спонсорство газу означає, що користувачі можуть сплачувати комісію за газ будь-яким токеном, або користувачі можуть сплачувати комісію за газ офлайн. Однак слід зазначити, що EIP3074 не дозволяє користувачам використовувати будь-який алгоритм підпису, відмінний від secp256k1, порівняно з іншими пропозиціями абстракції облікового запису, які дозволяють змінювати алгоритм перевірки підпису. Іншими словами, EIP3074 не є пропозицією, яка задовольняє всім абстракціям рахунку. Це також момент, за який EIP3074 критикують.
Щоб досягти очікуваних цілей, EIP3074 вводить два опкодів: AUTH і AUTHCALL. Зокрема, опкод AUTH може перевіряти підпис, і коли перевірка підпису пройшла успішно, цей опкод налаштує адресу authorized у контексті EVM на адресу підписанта. Коли адреса authorized налаштована в контексті, AUTHCALL може використовувати адресу authorized як msg.sender для ініціювання транзакції. В певному сенсі, користувач може через підпис делегувати свій рахунок для використання в транзакції смарт-контракту. Зазвичай ми називаємо цей смарт-контракт, якому користувач делегує, invoker контрактом.
Що конкретно містить підпис користувача? Користувачеві потрібно підписати таке:
!
Вищезазначений invoker address означає адресу invoker контракту, яку користувач бажає делегувати. EVM перевірить, чи відповідає підпис користувача дійсному контракту для перевірки підпису, щоб уникнути використання підпису AUTH користувача іншим контрактом.
Нонсе, з іншого боку, є ідентифікатором, який запобігає повторному відтворенню транзакцій. Однак слід зазначити, що код операції AUTH перевірятиме, чи відповідає nonce у підписі nonce поточного підписаного EOA, і теоретично, якщо користувач не використовує обліковий запис EOA для ініціювання транзакції для збільшення значення nonce, то підпис AUTH, виданий користувачем, завжди може бути використаний контрактом виклику. Це величезна вразливість системи безпеки, яка означає, що користувачі, які використовують EIP3074, повинні довіряти постачальнику послуг ретрансляції, який отримує підпис. Якщо постачальник послуг ретрансляції, який отримує підпис користувача, є зловмисним, постачальник послуг може в якийсь момент повторно відтворити підпис AUTH користувача, щоб викрасти активи користувача.
Ще однією проблемою безпеки є поле коміту. Поле коміту використовується для гарантування певних операцій, і користувачі можуть точно налаштувати контроль над своїми дозволами на підпис у коміті, наприклад, написання певного вмісту в коміті, щоб запобігти використанню вмісту підпису для переказів ETH. У документі EIP3074 ініціатор наводить серію прикладів використання поля коміту. Але проблема полягає в тому, що роль коміту повністю залежить від визначення смарт-контракту і, по суті, є необов'язковим вмістом. Різні смарт-контракти можуть аналізувати вміст коміту абсолютно непослідовно, а деякі контракти можуть взагалі не читати вміст коміту. Якщо ви хочете використовувати EIP3074 безпечно, вам потрібно просто переглянути смарт-контракт самостійно.
Нарешті, давайте подивимося на вплив EIP3074 на поточний мемпул транзакцій Ethereum. З введенням EIP3074 хакер може використовувати велику кількість облікових записів для ініціювання транзакцій, а потім використовувати EIP3074 транзакції для зливу ETH на цих рахунках відразу, коли транзакція збирається бути упакована, що призведе до збою всіх раніше ініційованих транзакцій. Цей тип атаки може мати значний вплив на вузли виконавчого рівня і, по суті, є DoS-атакою. Слід, однак, зазначити, що EIP7702, який використовується для заміни EIP3074, також має цю проблему, але EIP7702 вводить деякі обмеження, щоб уникнути цієї проблеми, про які ми поговоримо пізніше.
Окрім проблем, пов'язаних з EIP3074, про які згадувалося раніше, автор ERC4337 Yova у статті "Implications of EIP-3074 inclusion" навів більше заперечень. Простими словами, ці заперечення в основному включають:
EIP7702 – пропозиція Віталіка замінити EIP3074. Замість того, щоб вводити новий код операції EVM, пропозиція вводить новий тип транзакції, який називається SET_CODE_TX_TYPE. Після того, як користувач ініціює EIP7702 тип транзакції, користувач може додати функціональність смарт-контракту до свого EOA, зберігши при цьому базову функціональність EOA. Простіше кажучи, користувачі можуть або продовжувати ініціювати транзакції за допомогою таких гаманців, як MetaMask, або інші користувачі можуть викликати адреси EOA у формі смарт-контрактів.
Давайте розглянемо особливості EIP7702 на простому прикладі оптової торгівлі. Користувачі можуть використовувати EIP7702 для делегування своєї EOA-адреси смарт-контракту, який може виконувати масові виклики, а потім користувачі можуть безпосередньо дзвонити на свою адресу EOA у формі смарт-контракту для ініціювання масових транзакцій.
З технічної точки зору, новий тип транзакцій, введений EIP7702, порівняно з традиційними транзакціями, містить список authorization_list, який складається з [[chain_id, address, nonce, y_parity, r, s], ...]. Де address - це адреса смарт-контракту, яку користувач хоче делегувати, а nonce - це поточне значення nonce користувача. Інші параметри y_parity, r і s - це результати підпису користувача. У процесі виконання ми спочатку обробляємо кожен елемент у списку authorization_list, відновлюючи EOA-адресу за допомогою параметрів підпису, таких як y_parity, а потім вказуємо EOA-адресу на смарт-контракт за адресою address. Після цього EOA-адреса може приймати виклики для реалізації функцій контракту.
Переваги EIP7702 дуже очевидні, причому найбільшою перевагою є те, що EIP7702 по суті дозволяє EOA мати функціональність смарт-контракту. Це відповідає основним правилам абстракції рахунків, таким як ERC4337, що означає, що EIP7702 може використовувати всі дослідження в області абстракції рахунків і повторно використовувати наявну інфраструктуру, наприклад, EIP7702 може безпосередньо використовувати інфраструктуру ERC4337. Наразі ERC4337 вже випустив EntryPoint v0.8, що підтримує виклики EIP7702. З точки зору повторного використання наявної інфраструктури, EIP7702 має таку ж ступінь децентралізації, як і ERC4337.
Звичайно, EIP7702 також не зовсім вирішує проблеми, які виникають у EIP3074. Проблеми, які існують в більшості EIP3074 все ще існують. EIP7702 вимагає, щоб контракт облікового запису мав безпечну реалізацію, а сам протокол не гарантує жодної безпеки. У перші дні EIP7702 року деякі розробники пропонували стандартизувати підписні нонцеси, щоб уникнути можливих повторних атак, але EIP7702 також не прийняли ці пропозиції. Тому, якщо користувач хоче безпечно використовувати EIP7702, то користувачеві потрібно самостійно переглянути безпеку контракту.
Одночасно EIP7702 також принесе ряд проблем для виконавчого шару. У згаданому вище ми описали один з можливих способів використання EIP3074 для DoS-атаки на пул пам'яті виконавчого шару. Цей метод також є дієвим в EIP7702. Тому EIP7702 рекомендує всім EOA-адресам, які використовують EIP7702, мати лише одну непідтверджену транзакцію в пулі пам'яті, щоб уникнути масових DoS-атак.
Отже, найбільшою проблемою EIP3074 є те, що EIP3074 не реалізує повноцінну функцію абстракції облікових записів, тоді як EIP7702 реалізує повну функцію абстракції облікових записів. А визначення "повної абстракції облікових записів" містить саме те, що автори ERC4337. Прочитавши це, читач має зрозуміти, чому команда ERC4337 виступила проти EIP3074, в результаті чого EIP7702 замінив його. У подальшому ми розглянемо весь процес загального управління та обговорення.
Процес управління EIP3074 та EIP7702
EIP3074 було згадано на ранніх зустрічах розробників ядра Ethereum. 2 квітня 2021 року на засіданні #109 розробники ядра Ethereum провели просту дискусію щодо EIP3074. Результати обговорення були дуже простими:
Цікаво, що Віталік на цій конференції вважає, що в будь-якому випадку Ethereum потребує технічного рішення для генерації кількох викликів з однієї транзакції, спроектованої для EOA. Хоча EIP3074 має потенційні проблеми з безпекою, EIP3074 пропонує можливе технічне рішення, і розробники повинні рухатися вперед на основі EIP3074.
Очевидно, що через проблеми безпеки EIP3074 ця зустріч не включила EIP3074 до оновлення London.
На засіданні #115, яке відбулося 11 червня 2021 року, розробники EIP3074 подали звіт з питань безпеки. На засіданні основна увага приділялася питанням безпеки EIP3074. Простий висновок полягає в тому, що контракт invoker EIP3074 є надзвичайно важливим для системи, тому питання управління контрактом invoker є актуальним. Розробники EIP3074 сподіваються на формальне доведення контракту invoker, щоб підвищити безпеку.
Звичайно, є також частина дискусії про те, що деякі контракти використовують msg.sender == tx.origin для визначення, чи є адреса виклику EOA, і коли EIP3074 буде введено, ці рішення будуть визнані недійсними, але висновок полягає в тому, що невиконання цієї частини судового рішення не викличе серйозних проблем з безпекою. Коротко кажучи, зустріч була зосереджена на тому, щоб EIP3074 доповідачів представили основні розробникам результати аудиту безпеки 3074. Остаточний висновок зустрічі полягав у тому, що 3074 все ще потрібно розглянути питання контракту invoker, і рекомендується не приєднуватися до лондонського хардфорку.
На зустрічі #116 25 червня 2021 року Йова, основний автор ERC4337, представила аргументи на користь простішої альтернативи EIP 3074, в якій вказала, що в EIP3074 є багато проблем безпеки, і запропонувала змінити деякі з них, наприклад, обмежити вміст поля коміту в підписі, вимагаючи, щоб поле коміту було {nonce,to,gas, calldata,value,chainid}. За допомогою цього шаблону підпису EIP3074 можна використовувати лише для виконання певних конкретних транзакцій, щоб забезпечити їх безпеку.
У цьому засіданні автор EIP3074 відповів на матеріали, подані Yova:
Віталік на цій конференції提出了 наступні три пункти:
На зустрічі #131 4 лютого 2022 року розробники обговорили типи EIP, які повинні бути включені в оновлення ShangHai. EIP3074 було включено в обговорення, але розробники просто синхронізували розробку EIP3074. Примітно, що до зустрічі nethermind писав гаманці Ethereum сьогодні і завтра - EIP-3074 vs. ERC-4337, які не містили заперечень проти EIP3074.
На зустрічі #167 3 серпня 2023 року основні розробники обговорювали інший EIP5806, згадуючи про EIP3074. EIP5806 – це пропозиція, яка дозволяє EOA використовувати deleGate.io call для виклику зовнішніх контрактів під час транзакцій. Цей підхід в якомусь сенсі схожий на EIP7702. Але основні розробники також висловили сумніви щодо безпеки цього рішення, Ansgar зазначив, що EIP3074 ніколи не міг бути включений до жорсткого форку через можливі проблеми з безпекою, в той час як EIP5806 є більш радикальним варіантом.
На засіданні #182, яке відбулося 29 лютого 2024 року, розробники детально обговорили, чи має EIP3074 бути включений до оновлення Pectra. Віталік висловив думку, що будь-який стандарт абстракції рахунків має мати такі три функції:
Коментарі Віталіка щодо EIP5806 можуть бути кращим варіантом, ніж EIP3074. Андрій вважає, що EIP3074 більш універсальний, ніж EIP5806, і рекомендує використовувати EIP3074. Віталік заперечує Ендрю, стверджуючи, що всі гаманці в майбутньому можуть бути гаманцями смарт-контрактів, і що якщо це станеться, попередньо зібраний код операції, введений EIP3074, буде визнаний недійсним. Йоав, автор ERC4337, виступив на конференції з розлогою доповіддю, яка охопила такі теми:
Yova більше схильна використовувати EIP5806 як схему абстракції облікового запису.
Inside Meeting #183 14 березня 2024 року основні розробники запросили Дена Фінлі з MetaMask обговорити, що гаманець думає про EIP3074. Ден виступає за EIP3074, зазначаючи, що MetaMask також підтримуватиме тестування EIP3074. MetaMask вважає, що EIP3074 може функціонально дозволити EOA насолоджуватися повною функціональністю абстракції облікового запису. З точки зору безпеки, EIP3074 надає рішення для постачальників послуг гаманця, тобто поділ гарячих і холодних ключів. Постачальник послуг гаманця може зберігати EIP3074 підпис EOA, щоб ініціювати транзакцію, і користувачі можуть використовувати гарячий закритий ключ у звичайних транзакціях, але холодний приватний ключ може зберігатися в апаратному гаманці користувача, і коли буде виявлено надзвичайну ситуацію, користувач може використовувати холодний приватний ключ у холодному гаманці, щоб ініціювати транзакцію, щоб відкликати підпис EIP3074. Це рішення гарячого та холодного поділу приватних ключів дає гнучкість постачальникам гаманців.
Віталік зазначає, що в рамках EIP3074 розробники гаманців повинні розробити сувору логіку авторизації, щоб уникнути неправомірного використання підписів EIP3074 користувачів. Цікаво, що, обговорюючи здатність MetaMask додавати EIP3074 функціональність, Віталік зазначив, що L2 можна використовувати як перехідне рішення, тобто будь-які нові зміни рівня виконання повинні бути реалізовані спочатку в межах L2, оскільки L2 має обмежене фінансування і може завдати серйозних збитків, навіть якщо щось піде не так.
Дрор Тірос у дискусії зазначив, що найкращий спосіб забезпечити безпеку EIP3074 – це коли офіційний Ethereum безпосередньо надає invoker контракт. Але Дан Фінлей виступає проти надання контракту від офіційних осіб, вважаючи, що invoker контракт повинен повністю визначатися користувачами, а ринок врешті-решт вибере найбезпечніший invoker контракт.
Ансгар, як і раніше, наполягає на тому, що EIP3074 один підпис повинен відповідати лише одній транзакції, а постачальники послуг гаманців не повинні повторно використовувати підписи користувачів для ініціювання транзакцій, але Ден Фінлі також заперечив. Ден Фінлей вважає, що EIP3074 повинні бути підписані холодним гаманцем, і тоді постачальник послуг гаманця може повторно використовувати підпис для ініціювання транзакцій безпосередньо для користувача, і якщо користувачеві потрібно повторно підписувати кожен раз, холодний приватний ключ може використовуватися кілька разів. Це не узгоджується з ідеєю розділення гарячих і холодних закритих ключів.
На цій зустрічі основні розробники обговорили ще одну важливу тему — списки включення. Списки включення є засобом для підвищення антикорупційних властивостей Ethereum. Простими словами, списки включення дозволяють деяким транзакціям бути обіцяними для прямого включення в наступний блок. Але основні розробники зазначили, що EIP3074 суперечить спискам включення.
На внутрішньому засіданні Meeting #185, що відбулося 11 квітня 2024 року, більшість реалізацій клієнтів погодилася на включення EIP3074 до жорсткого хардфорку Pectra, але Geth висловив заперечення, оскільки EIP3074 може призвести до проблем з деревом Verkle. Danno також висловив заперечення, оскільки EIP3074 може викликати випадки повторного використання підписів. Yoav також висловив заперечення, надавши план атаки на пам'яті за допомогою EIP3074 та Blob-транзакцій. Простими словами, зловмисник може ініціювати велику кількість Blob-транзакцій, які містять велику кількість даних, а потім використовувати EIP3074, щоб анулювати всі ці Blob-транзакції.
Коротко кажучи, на цій зустрічі всі розробники клієнтів погодилися, що EIP3074 буде включено в остаточне оновлення.
На зустрічі #187 9 травня 2024 року основні розробники вперше обговорили питання заміни EIP7702 EIP3074. EIP7702 було зроблено в перші 90 хвилин зустрічі розробників Vitalik. Під час конференції розробники ядра визнали EIP7702 кращим стандартом, ніж EIP3074. На цій зустрічі не було спротиву EIP7702, але деякі дослідники вважали, що EIP7702 також мають безповоротні атрибути, подібні до EIP3074, що може призвести до проблем з фінансовою безпекою.
На зустрічі #188 23 травня 2024 року основні розробки обговорили можливість заміни EIP3074 на EIP7702. Остаточним завершенням зустрічі була заміна EIP3074 на EIP7702 як стандарт абстракції облікового запису в хардфорку Pectra. Віталік зазначає, що EIP7702 також має певну безповоротність, що відповідає EIP3074, атрибутам, які багато обговорювалися в обговоренні EIP3074. Цікаво, що на засіданні була велика кількість ERC4337 делегатів.
Насправді, обговорення заміни EIP3074 на EIP7702 було широко обговорено ще до 188-ї зустрічі основних розробників, і тоді було вирішено, що 3074 буде замінено, тому на зустрічі основних розробників не було великої суперечки.
Дорожня карта та рішення
Zerodev, основна інфраструктура абстракції облікових записів, опублікував цікаву статтю під назвою «Роздуми про управління Ethereum після саги 3074», дізнавшись, що EIP3074 буде замінено, зробивши висновок, що EIP7702 хороша пропозиція, яка приносить користь усім користувачам. Однак процес управління для EIP7702 замінити EIP3074 не є оптимальним з низки причин, зокрема:
Zerodev вважає, що найкращий шлях управління повинен полягати в тому, щоб спільнота ERC4337 широко брала участь і висловлювала свої думки в процесі тривалого обговорення основних розробників EIP3074.
Розробники EIP3074 вважають, що ERC4337 має нести відповідальність за невдачу в управлінні. Оскільки EIP3074 активно брала участь в управлінні протягом останніх кількох років і неодноразово спілкувалася з основним розробником ERC4337 yova.
З іншого боку, ERC4337-спільнота вважає, що EIP3074 несе основну відповідальність за невдачі в управлінні. ERC4337 члени спільноти вважають, що Йова, як основний розробник ERC4337, висловлювалася проти EIP3074 на кількох основних зборах розробників, але основний розробник, схоже, не слухає. Більшість членів спільноти в ERC4337 не звертають уваги на динаміку управління EIP3074, і більшість членів погоджуються, що EIP3074 є мертвим стандартом. Спільнота ERC4337 також відчула, що основні розробники не ведуть активної комунікації з ERC4337-спільнотою.
EIP3074 та ERC4337 вважають, що вони виконали правильну управлінську роботу, а інша сторона повинна нести основну відповідальність за провал управління. Очевидно, що в цьому процесі управління існує більш глибока причина, яка впливає на ситуацію.
Простіше кажучи, ця глибша причина насправді є дорожньою картою Ethereum. Дорожня карта Ethereum має більше повноважень, ніж основна зустріч розробників. Дорожня карта абстракції облікового запису орієнтована на ERC4337. EIP7702 повністю сумісний зі стандартом ERC4337, але EIP3074 не повністю сумісний зі стандартом ERC4337. Отже, з точки зору дорожньої карти Ethereum, EIP3074 заміна обов'язково відбудеться.
Звичайно, дорожня карта Ethereum є відображенням особистого бачення Віталіка щодо майбутнього Ethereum. Якщо в процесі управління Ethereum виникають серйозні суперечки, то як визначник дорожньої карти Віталік має остаточне право на ухвалення рішення. Саме рішення Віталіка призвело до заміни EIP3074.
Управлінська модель Ethereum - це модель values ⇒ vision ⇒ roadmaps ⇒ clients, або, коротко, модель VVRC. Процес управління виглядає наступним чином:
Вищезгаданий процес є справжнім процесом управління Ethereum. Ми можемо бачити, що особисте бачення Віталіка розташоване в основній частині моделі управління Ethereum, тому, як тільки в реалізації клієнта виникнуть серйозні суперечки, особиста думка Віталіка буде остаточною.