У рамках оновлення Pectra виникли найскладніші питання з управління. Після включення EIP3074 в оновлення Pectra виникла величезна дискусія, особливо з боку команди ERC4337.
EIP3074 опинився в глухому куті, процес управління не може продовжуватися. Доки Віталік не запропонував EIP7702, що поклало край сумнівам команди ERC4337 щодо EIP3074.
Дослідження GCC показало, що управління EIP3074 і ERC7702 в оновленні Pectra рідко обговорюється в китайському світі. Але це питання управління також відображає більш глибоку проблему управління Ethereum, тобто хто може контролювати конкретний вміст коду, виходячи з того, що код є законом. Питання управління EIP3074 та ERC7702 можуть дати нам гарне уявлення про реальний процес управління в Ethereum.
Остаточним висновком цієї статті є парафраз зі статті, опублікованої ZeroDev, в якій стверджується, що система управління Ethereum є моделлю VVRC, і що включення будь-якої пропозиції має спочатку узгоджуватися з цінностями Ethereum (Value), а потім пропозиція повинна відображати бачення, розроблене Віталіком (Vision), остаточна пропозиція повинна бути відображена в дорожній карті (Roadmap) і, нарешті, обговорена основними розробниками і включена в клієнт (Client) Реалізація.
T EIP2537, представлений GCC Research у попередній статті, мав проблеми з реалізацією лише на рівні клієнта, що призвело до можливої затримки приєднання до хардфорку, тоді як 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 підпису користувача іншим контрактом.
А nonce - це ідентифікатор, який запобігає повторному виконанню транзакцій. Але варто звернути увагу на те, що код операції AUTH перевіряє, чи збігається nonce у підпису з nonce поточного підпису EOA, теоретично, якщо користувач не використовує EOA-рахунок для ініціювання транзакції з підвищенням значення nonce, тоді підпис AUTH, надісланий користувачем, може безперервно використовуватися контрактом invoker. Це величезна вразливість безпеки, що означає, що користувачі, які використовують EIP3074, повинні довіряти релейним постачальникам послуг, які отримують підпис. Якщо релейний постачальник, який отримав підпис користувача, є зловмисним, цей постачальник може в якийсь момент повторити підпис AUTH користувача, щоб вкрасти активи користувача.
Ще однією проблемою безпеки є поле коміту. Поле коміту використовується для гарантування певних операцій, і користувачі можуть точно налаштувати контроль над своїми дозволами на підпис у коміті, наприклад, написання певного вмісту в коміті, щоб запобігти використанню вмісту підпису для переказів ETH. У документі EIP3074 ініціатор наводить серію прикладів використання поля коміту. Але проблема полягає в тому, що роль коміту повністю залежить від визначення смарт-контракту і, по суті, є необов'язковим вмістом. Різні смарт-контракти можуть аналізувати вміст коміту абсолютно непослідовно, а деякі контракти можуть взагалі не читати вміст коміту. Якщо ви хочете використовувати EIP3074 безпечно, вам потрібно просто переглянути смарт-контракт самостійно.
Нарешті, ми представляємо вплив EIP3074 на поточний пул пам'яті транзакцій Ethereum. Після впровадження EIP3074 може з'явитися метод атаки на пул пам'яті, при якому хакери можуть використовувати велику кількість облікових записів для ініціювання транзакцій, а потім, коли транзакції майже готові до упаковки, використовувати EIP3074 для одноразового виснаження ETH з цих облікових записів, що призведе до того, що всі попередні транзакції зазнають невдачі. Такий метод атаки може значно вплинути на вузли виконавчого рівня, по суті, представляючи собою атаку типу DoS. Але варто зазначити, що EIP7702, який пропонує альтернативу EIP3074, також має цю проблему, але EIP7702 ввів деякі обмеження, щоб запобігти виникненню цієї проблеми, про що ми обговоримо далі.
Окрім проблем, що існують у самій EIP3074, автор ERC4337 Yova у статті "Implicації включення EIP-3074" представив більше заперечень. Якщо сказати простіше, ці заперечення в основному включають:
Ризики централізації. Через особливі властивості AUTH підпису користувачі повинні повністю довіряти релейним сервісам EIP3074 та базовій інфраструктурі. Водночас поточна інфраструктура, побудована на таких протоколах, як ERC4337, повністю несумісна з EIP3074.
Безпека користувачів. Як зазначалося вище, EIP3074 не має єдиного методу контролю доступу, а також існують ризики безпеки в дизайні nonce підпису, що може призвести до серйозних проблем з безпекою.
Неповна функція абстракції рахунків. У порівнянні з іншими пропозиціями абстракції рахунків, EIP3074 є неповною і не може реалізувати такі функції, як зміна алгоритму підпису користувача.
Існують проблеми з користувацьким досвідом. Коли користувачеві потрібно делегувати свій рахунок смарт-контракту, він повинен виконати один AUTH підпис, а потім опублікувати виклик з AUTH підписом в ланцюг. Користувачеві потрібно виконати два підписи.
EIP7702 – пропозиція Віталіка замінити EIP3074. Замість того, щоб вводити новий код операції EVM, пропозиція вводить новий тип транзакції, який називається SET_CODE_TX_TYPE. Після того, як користувач ініціює EIP7702 тип транзакції, користувач може додати функціональність смарт-контракту до свого EOA, зберігши при цьому базову функціональність EOA. Простіше кажучи, користувачі можуть або продовжувати ініціювати транзакції за допомогою таких гаманців, як MetaMask, або інші користувачі можуть викликати адреси EOA у формі смарт-контрактів.
Ми представляємо функціонал 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 по суті дозволяє EOA мати функціональність смарт-контракту. Це узгоджується з основними правилами абстракції облікового запису, такими як ERC4337, що означає, що EIP7702 можемо використовувати всю існуючу інфраструктуру в домені абстракції поточного рахунку для дослідження та повторного використання існуючої інфраструктури, наприклад, EIP7702 можете безпосередньо використовувати ERC4337 інфраструктуру. EntryPoint v0.8 з підтримкою EIP7702 викликів тепер доступний в ERC4337. З точки зору повторного використання існуючої інфраструктури, EIP7702 має такий самий ступінь деігровості, як і ERC4337.
Звичайно, EIP7702 насправді також не повністю виправляє проблеми, що виникають у EIP3074. Більшість проблем, які існують у EIP3074, залишаються. EIP7702 вимагає, щоб контракт облікового запису мав безпечну реалізацію, у той час як сам протокол не гарантує ніякої безпеки. На ранніх етапах обговорення EIP7702 деякі розробники пропонували стандартизувати підпис nonce, щоб уникнути можливих атак повторного використання, але EIP7702 зрештою не прийняв ці пропозиції. Тож якщо користувач хоче безпечно використовувати EIP7702, тоді йому потрібно самостійно перевірити безпеку контракту.
Одночасно EIP7702 також принесе низку проблем для виконавчого рівня. У наведеному вище тексті ми описали один із можливих способів використання EIP3074 для проведення DoS-атаки на пул пам'яті виконавчого рівня. Цей метод також є ефективним у EIP7702. Тому EIP7702 рекомендує, щоб усі EOA адреси, які використовують EIP7702, мали лише одну незавершену транзакцію в пулі пам'яті, щоб уникнути виникнення масштабних DoS-атак.
Отже, головною проблемою EIP3074 є те, що EIP3074 не реалізував повну функцію абстракції облікових записів, тоді як EIP7702 реалізував повну функцію абстракції облікових записів. А саме визначення "повної абстракції облікових записів" належить авторам ERC4337. Прочитавши це, читач має зрозуміти, чому команда ERC4337 виступала проти EIP3074, врешті-решт його замінив EIP7702. У подальшій частині ми розглянемо весь процес управління та обговорення.
Процес управління EIP3074 та EIP7702
EIP3074 було згадано на ранніх етапах зустрічі основних розробників Ethereum. 2 квітня 2021 року на Meeting #109 основні розробники Ethereum провели просте обговорення EIP3074. Результат обговорення був дуже простим:
Алексей висловив занепокоєння щодо безпекових ризиків, пов'язаних із змістом підпису EIP3074, що може призвести до серйозних втрат безпеки для користувачів, запропонувавши детальніше регулювати конкретний зміст підпису AUTH в EIP3074, що отримало підтримку від Мартіна.
Джеймс зазначив, що EIP3074 може містити потенційні вразливості на рівні виконання, такі як атаки DoS, та запропонував, щоб EIP3074 надало письмовий аналіз загроз.
Алексей та Мартін скаржаться на середню якість документації EIP3074, витративши багато часу на читання та розуміння
Мартін вважає, що основою EIP3074 є співпраця та реалізація з додатками, особливо з розробниками гаманців. Автори EIP3074 заявили, що вже провели ряд обговорень з розробниками додатків.
Цікаво, що Віталік на цій конференції вважає, що в будь-якому випадку Ethereum потребує технічного рішення, яке дозволяє генерувати кілька викликів з однієї транзакції, спроектованої для EOA. Хоча EIP3074 має потенційні проблеми з безпекою, EIP3074 пропонує можливе технічне рішення, на основі якого розробники повинні продовжувати працювати.
Очевидно, що через проблеми безпеки з EIP3074 ця пропозиція не була включена в оновлення London.
11 червня 2021 року на засіданні #115 розробники EIP3074 подали звіт щодо безпеки. Основна увага на засіданні була приділена проблемам безпеки EIP3074. Простий висновок полягає в тому, що контракт invoker EIP3074 є надзвичайно важливим для системи, тому питання про те, чи потрібно управляти контрактом invoker, є актуальним. Розробники EIP3074 сподіваються на формальне підтвердження контракту invoker, щоб підвищити безпеку.
Звичайно, також було обговорення щодо деяких контрактів, які використовують msg.sender == tx.origin для визначення, чи є адреса виклику EOA. Коли буде введено EIP3074, ці перевірки перестануть працювати, але висновок полягає в тому, що втрата цих перевірок не призведе до серйозних проблем безпеки. Коротко кажучи, основна мета цієї зустрічі полягала в тому, щоб представити розробникам ядра результати аудиту безпеки 3074, запропонованого автором EIP3074. Остаточний висновок зустрічі полягає в тому, що 3074 ще потрібно врахувати питання контракту invoker і рекомендується не включати його в жорстке розгалуження London.
На засіданні #116, яке відбулося 25 червня 2021 року, основний автор ERC4337 Yova представив матеріали "A case for a simpler alternative to EIP 3074", в яких зазначено, що EIP3074 має багато проблем з безпекою. Було запропоновано змінити деякі його частини, наприклад, обмежити вміст поля commit у підписі, вимагаючи, щоб поле commit було у форматі {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 wallets today and tomorrow — EIP-3074 vs. ERC-4337", у якій не міститься заперечень проти EIP3074.
На засіданні Meeting #167, яке відбулося 3 серпня 2023 року, ключові розробники обговорювали EIP3074 в контексті іншого EIP5806. 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 користувачів. Цікаво, що під час обговорення підтримки функцій EIP3074 у MetaMask Віталік зазначив, що можна використовувати 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 хвилин до початку засідання основних розробників, яке проводив Віталік. На засіданні основні розробники визнали EIP7702 стандартом, який є значно кращим за EIP3074. На цьому засіданні не було висловлено жодних заперечень щодо EIP7702, лише деякі дослідники вважали, що EIP7702 також має подібні до EIP3074 незворотні властивості, що можуть призвести до проблем безпеки коштів.
На засіданні Meeting #188, яке відбулося 23 травня 2024 року, основні розробники обговорили можливість заміни EIP7702 на EIP3074. Остаточне рішення цього засідання полягало в тому, щоб використати EIP7702 замість EIP3074 як стандарт абстракції рахунків у жорсткому форку Pectra. Віталік зазначив, що EIP7702 також має деякі характеристики незворотності, які були детально обговорені під час обговорення EIP3074. Досить цікаво, що на засіданні була велика кількість представників ERC4337, які виступали.
Фактично, обговорення заміни EIP3074 на EIP7702 широко обговорювалося ще до 188-ї зустрічі основних розробників, і результатом тих обговорень стало те, що 3074 буде замінено, тому на зустрічі основних розробників не було великої суперечки.
Дорожня карта та рішення
Zerodev, основна інфраструктура абстракції облікових записів, опублікував цікаву статтю під назвою «Роздуми про управління Ethereum після саги 3074», дізнавшись, що EIP3074 буде замінено, зробивши висновок, що EIP7702 хороша пропозиція, яка приносить користь усім користувачам. Однак процес управління для EIP7702 замінити EIP3074 не є оптимальним з низки причин, зокрема:
EIP3074 пройшов тривалий процес обговорення, у вищезгаданій статті ми вже представили кілька обговорень EIP3074 на зустрічах основних розробників.
Після того, як EIP3074 було вирішено включити в оновлення Pectra, воно отримало велику кількість заперечень з боку спільноти ERC4337. Звісно, у вищезгаданому ми вже вказали, що основний розробник ERC4337 yova неодноразово висловлював своє заперечення щодо EIP3074 на засіданнях основних розробників.
Zerodev вважає, що найкращий шлях управління полягає в тому, щоб під час тривалої дискусії основних розробників EIP3074 спільнота ERC4337 повинна широко брати участь і висловлювати свою думку.
Розробники EIP3074 вважають, що ERC4337 має нести відповідальність за невдачу в управлінні. Оскільки EIP3074 активно брав участь в управлінні протягом останніх кількох років і неодноразово спілкувався з основним розробником ERC4337 yova.
Спільнота ERC4337 вважає, що EIP3074 повинна нести основну відповідальність за невдачу управління. Члени спільноти ERC4337 вважають, що Yova, як основний розробник ERC4337, неодноразово висловлював заперечення щодо EIP3074 на засіданнях основних розробників, але основні розробники, здається, не звертали на це уваги. Більшість членів спільноти ERC4337 не слідкували за динамікою управління EIP3074, більшість з них вважає, що EIP3074 є мертвою стандартом. Спільнота ERC4337 також вважає, що основні розробники не активно спілкуються зі спільнотою ERC4337.
EIP3074 та ERC4337 обидва вважають, що виконали правильну роботу з управління, а інша сторона повинна нести основну відповідальність за провал управління. Очевидно, що в цьому процесі управління існує більш глибока причина, яка відіграє роль.
Простими словами, цю більш глибоку причину насправді викликано дорожньою картою Ethereum. Дорожня карта Ethereum має владу, що перевищує повноваження основних розробників. Дорожня карта абстракції рахунків базується на ERC4337. EIP7702 повністю сумісний зі стандартом ERC4337, але EIP3074 не є достатньо сумісним зі стандартом ERC4337. Отже, з точки зору дорожньої карти Ethereum, заміна EIP3074 є неминучою.
Звичайно, дорожня карта Ethereum є відображенням особистого бачення Віталіка щодо майбутнього Ethereum. Якщо під час процесу управління виникають серйозні суперечки, то як визначник дорожньої карти Віталік має остаточне право вирішення. І саме рішення Віталіка призвело до заміни EIP3074.
Модель управління Ethereum - це модель values ⇒ vision ⇒ roadmaps ⇒ clients, або коротко модель VVRC. Процес управління виглядає наступним чином:
цінності, особливо цінності спільноти, цінності спільноти Ethereum включають децентралізацію, стійкість до цензури та інше
vision Візія, насправді, це особисті роздуми Віталіка про майбутнє Ethereum.
дорожні карти, дослідник на основі бачення надає деякі технічні деталі для більш повної реалізації дорожньої карти.
реалізація клієнтів, основні розробники клієнтів обговорюють дорожню карту за допомогою таких інструментів, як зустрічі основних розробників, і реалізують вимоги з дорожньої карти.
Вищезгаданий процес є справжнім процесом управління Ethereum. Ми можемо бачити, що особисте бачення Віталіка знаходиться в нижній частині моделі управління Ethereum, тому, коли в реалізації клієнта виникають серйозні суперечки, особиста думка Віталіка буде остаточним вирішенням.
>
> Список літератури
>
>
>
Вступ до ZeroDev
>
>
> null
>
>
>
>
>
> Вступ до ZeroDev
>
>
> null
>
>
>
>
>
>Примітки щодо дорожньої карти абстракції облікового запису - HackMD
>
>
> # Примітки щодо дорожньої карти абстракції облікового запису *Особлива подяка Віталіку та команді AA за зворотний зв'язок
>
>
>
>
>
>
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Ефіріум управлінська війна: EIP3074, ERC4337 та EIP7702
Автор: shew
Огляд
У рамках оновлення Pectra виникли найскладніші питання з управління. Після включення EIP3074 в оновлення Pectra виникла величезна дискусія, особливо з боку команди ERC4337.
EIP3074 опинився в глухому куті, процес управління не може продовжуватися. Доки Віталік не запропонував EIP7702, що поклало край сумнівам команди ERC4337 щодо EIP3074.
Дослідження GCC показало, що управління EIP3074 і ERC7702 в оновленні Pectra рідко обговорюється в китайському світі. Але це питання управління також відображає більш глибоку проблему управління Ethereum, тобто хто може контролювати конкретний вміст коду, виходячи з того, що код є законом. Питання управління EIP3074 та ERC7702 можуть дати нам гарне уявлення про реальний процес управління в Ethereum.
Остаточним висновком цієї статті є парафраз зі статті, опублікованої ZeroDev, в якій стверджується, що система управління Ethereum є моделлю VVRC, і що включення будь-якої пропозиції має спочатку узгоджуватися з цінностями Ethereum (Value), а потім пропозиція повинна відображати бачення, розроблене Віталіком (Vision), остаточна пропозиція повинна бути відображена в дорожній карті (Roadmap) і, нарешті, обговорена основними розробниками і включена в клієнт (Client) Реалізація.
T EIP2537, представлений GCC Research у попередній статті, мав проблеми з реалізацією лише на рівні клієнта, що призвело до можливої затримки приєднання до хардфорку, тоді як EIP3074 не був включений до хардфорку через проблеми з баченням та дорожньою картою, а розробники ядра Ethereum безпосередньо вибрали EIP7702, написаний Віталіком, як остаточну пропозицію щодо абстракції облікового запису.
Огляд змісту пропозиції
Перед тим, як представити конкретні процеси управління, спочатку потрібно коротко ознайомити з конкретним змістом, що стосується EIP3074, EIP7702 та ERC4337.
EIP3074 – це пропозиція рівня виконання, виконання якої вимагає оновлення програмного забезпечення вузла. Основною метою EIP3074 є забезпечення спонсорства газу та оптової торгівлі. Так зване спонсорство газу означає, що користувачі можуть сплачувати комісію за газ будь-яким токеном, або користувачі можуть сплачувати комісію за газ офлайн. Однак слід зазначити, що EIP3074 не дозволяє користувачам використовувати будь-який алгоритм підпису, відмінний від secp256k1, порівняно з іншими пропозиціями абстракції облікового запису, які дозволяють змінювати алгоритм перевірки підпису. Іншими словами, EIP3074 не є пропозицією, яка задовольняє всім абстракціям рахунку. Це також момент, за який EIP3074 критикують.
Щоб досягти запланованої мети, EIP3074 вводить два операційних коди: AUTH та AUTHCALL. Операційний код AUTH може перевіряти підпис, і якщо перевірка підпису пройде, цей операційний код налаштує адресу authorized в контексті EVM на адресу підписанта. Коли в контексті налаштовано authorized, AUTHCALL може використовувати адресу authorized як msg.sender для ініціювання транзакції. В певному сенсі, користувач може делегувати свій рахунок для використання смарт-контрактом в одній транзакції через підпис. Зазвичай ми називаємо цей смарт-контракт, якому делеговано користувачем, invoker контрактом.
Який конкретний зміст підпису користувача? Користувачеві потрібно підписати таке:
! Війни управління Ethereum: EIP3074, ERC4337 і EIP7702
Вищезгаданий invoker address означає адресу invoker контракту, яку користувач бажає делегувати. EVM перевіряє, чи збігається підпис користувача з контрактом, який насправді перевіряє підпис, щоб уникнути використання AUTH підпису користувача іншим контрактом.
А nonce - це ідентифікатор, який запобігає повторному виконанню транзакцій. Але варто звернути увагу на те, що код операції AUTH перевіряє, чи збігається nonce у підпису з nonce поточного підпису EOA, теоретично, якщо користувач не використовує EOA-рахунок для ініціювання транзакції з підвищенням значення nonce, тоді підпис AUTH, надісланий користувачем, може безперервно використовуватися контрактом invoker. Це величезна вразливість безпеки, що означає, що користувачі, які використовують EIP3074, повинні довіряти релейним постачальникам послуг, які отримують підпис. Якщо релейний постачальник, який отримав підпис користувача, є зловмисним, цей постачальник може в якийсь момент повторити підпис AUTH користувача, щоб вкрасти активи користувача.
Ще однією проблемою безпеки є поле коміту. Поле коміту використовується для гарантування певних операцій, і користувачі можуть точно налаштувати контроль над своїми дозволами на підпис у коміті, наприклад, написання певного вмісту в коміті, щоб запобігти використанню вмісту підпису для переказів ETH. У документі EIP3074 ініціатор наводить серію прикладів використання поля коміту. Але проблема полягає в тому, що роль коміту повністю залежить від визначення смарт-контракту і, по суті, є необов'язковим вмістом. Різні смарт-контракти можуть аналізувати вміст коміту абсолютно непослідовно, а деякі контракти можуть взагалі не читати вміст коміту. Якщо ви хочете використовувати EIP3074 безпечно, вам потрібно просто переглянути смарт-контракт самостійно.
Нарешті, ми представляємо вплив EIP3074 на поточний пул пам'яті транзакцій Ethereum. Після впровадження EIP3074 може з'явитися метод атаки на пул пам'яті, при якому хакери можуть використовувати велику кількість облікових записів для ініціювання транзакцій, а потім, коли транзакції майже готові до упаковки, використовувати EIP3074 для одноразового виснаження ETH з цих облікових записів, що призведе до того, що всі попередні транзакції зазнають невдачі. Такий метод атаки може значно вплинути на вузли виконавчого рівня, по суті, представляючи собою атаку типу DoS. Але варто зазначити, що EIP7702, який пропонує альтернативу EIP3074, також має цю проблему, але EIP7702 ввів деякі обмеження, щоб запобігти виникненню цієї проблеми, про що ми обговоримо далі.
Окрім проблем, що існують у самій EIP3074, автор ERC4337 Yova у статті "Implicації включення EIP-3074" представив більше заперечень. Якщо сказати простіше, ці заперечення в основному включають:
EIP7702 – пропозиція Віталіка замінити EIP3074. Замість того, щоб вводити новий код операції EVM, пропозиція вводить новий тип транзакції, який називається SET_CODE_TX_TYPE. Після того, як користувач ініціює EIP7702 тип транзакції, користувач може додати функціональність смарт-контракту до свого EOA, зберігши при цьому базову функціональність EOA. Простіше кажучи, користувачі можуть або продовжувати ініціювати транзакції за допомогою таких гаманців, як MetaMask, або інші користувачі можуть викликати адреси EOA у формі смарт-контрактів.
Ми представляємо функціонал 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 по суті дозволяє EOA мати функціональність смарт-контракту. Це узгоджується з основними правилами абстракції облікового запису, такими як ERC4337, що означає, що EIP7702 можемо використовувати всю існуючу інфраструктуру в домені абстракції поточного рахунку для дослідження та повторного використання існуючої інфраструктури, наприклад, EIP7702 можете безпосередньо використовувати ERC4337 інфраструктуру. EntryPoint v0.8 з підтримкою EIP7702 викликів тепер доступний в ERC4337. З точки зору повторного використання існуючої інфраструктури, EIP7702 має такий самий ступінь деігровості, як і ERC4337.
Звичайно, EIP7702 насправді також не повністю виправляє проблеми, що виникають у EIP3074. Більшість проблем, які існують у EIP3074, залишаються. EIP7702 вимагає, щоб контракт облікового запису мав безпечну реалізацію, у той час як сам протокол не гарантує ніякої безпеки. На ранніх етапах обговорення EIP7702 деякі розробники пропонували стандартизувати підпис nonce, щоб уникнути можливих атак повторного використання, але EIP7702 зрештою не прийняв ці пропозиції. Тож якщо користувач хоче безпечно використовувати EIP7702, тоді йому потрібно самостійно перевірити безпеку контракту.
Одночасно EIP7702 також принесе низку проблем для виконавчого рівня. У наведеному вище тексті ми описали один із можливих способів використання EIP3074 для проведення DoS-атаки на пул пам'яті виконавчого рівня. Цей метод також є ефективним у EIP7702. Тому EIP7702 рекомендує, щоб усі EOA адреси, які використовують EIP7702, мали лише одну незавершену транзакцію в пулі пам'яті, щоб уникнути виникнення масштабних DoS-атак.
Отже, головною проблемою EIP3074 є те, що EIP3074 не реалізував повну функцію абстракції облікових записів, тоді як EIP7702 реалізував повну функцію абстракції облікових записів. А саме визначення "повної абстракції облікових записів" належить авторам ERC4337. Прочитавши це, читач має зрозуміти, чому команда ERC4337 виступала проти EIP3074, врешті-решт його замінив EIP7702. У подальшій частині ми розглянемо весь процес управління та обговорення.
Процес управління EIP3074 та EIP7702
EIP3074 було згадано на ранніх етапах зустрічі основних розробників Ethereum. 2 квітня 2021 року на Meeting #109 основні розробники Ethereum провели просте обговорення EIP3074. Результат обговорення був дуже простим:
Цікаво, що Віталік на цій конференції вважає, що в будь-якому випадку Ethereum потребує технічного рішення, яке дозволяє генерувати кілька викликів з однієї транзакції, спроектованої для EOA. Хоча EIP3074 має потенційні проблеми з безпекою, EIP3074 пропонує можливе технічне рішення, на основі якого розробники повинні продовжувати працювати.
Очевидно, що через проблеми безпеки з EIP3074 ця пропозиція не була включена в оновлення London.
11 червня 2021 року на засіданні #115 розробники EIP3074 подали звіт щодо безпеки. Основна увага на засіданні була приділена проблемам безпеки EIP3074. Простий висновок полягає в тому, що контракт invoker EIP3074 є надзвичайно важливим для системи, тому питання про те, чи потрібно управляти контрактом invoker, є актуальним. Розробники EIP3074 сподіваються на формальне підтвердження контракту invoker, щоб підвищити безпеку.
Звичайно, також було обговорення щодо деяких контрактів, які використовують msg.sender == tx.origin для визначення, чи є адреса виклику EOA. Коли буде введено EIP3074, ці перевірки перестануть працювати, але висновок полягає в тому, що втрата цих перевірок не призведе до серйозних проблем безпеки. Коротко кажучи, основна мета цієї зустрічі полягала в тому, щоб представити розробникам ядра результати аудиту безпеки 3074, запропонованого автором EIP3074. Остаточний висновок зустрічі полягає в тому, що 3074 ще потрібно врахувати питання контракту invoker і рекомендується не включати його в жорстке розгалуження London.
На засіданні #116, яке відбулося 25 червня 2021 року, основний автор ERC4337 Yova представив матеріали "A case for a simpler alternative to EIP 3074", в яких зазначено, що EIP3074 має багато проблем з безпекою. Було запропоновано змінити деякі його частини, наприклад, обмежити вміст поля commit у підписі, вимагаючи, щоб поле commit було у форматі {nonce,to,gas,calldata,value,chainid}. Після використання цього підписного формату EIP3074 можна буде застосовувати лише для виконання певних специфічних транзакцій, щоб забезпечити безпеку транзакцій.
У цій нараді автор EIP3074 відповів на матеріали, подані Yova:
Віталік на цій конференції висловив такі три пункти:
На зустрічі #131 4 лютого 2022 року розробники обговорювали типи EIP, які повинні бути включені в оновлення ShangHai. EIP3074 було включено в обговорення, але розробники лише коротко синхронізували динаміку розробки EIP3074. Варто зазначити, що перед початком зустрічі nethermind написала статтю "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", у якій не міститься заперечень проти EIP3074.
На засіданні Meeting #167, яке відбулося 3 серпня 2023 року, ключові розробники обговорювали EIP3074 в контексті іншого EIP5806. 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 користувачів. Цікаво, що під час обговорення підтримки функцій EIP3074 у MetaMask Віталік зазначив, що можна використовувати 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 хвилин до початку засідання основних розробників, яке проводив Віталік. На засіданні основні розробники визнали EIP7702 стандартом, який є значно кращим за EIP3074. На цьому засіданні не було висловлено жодних заперечень щодо EIP7702, лише деякі дослідники вважали, що EIP7702 також має подібні до EIP3074 незворотні властивості, що можуть призвести до проблем безпеки коштів.
На засіданні Meeting #188, яке відбулося 23 травня 2024 року, основні розробники обговорили можливість заміни EIP7702 на EIP3074. Остаточне рішення цього засідання полягало в тому, щоб використати EIP7702 замість EIP3074 як стандарт абстракції рахунків у жорсткому форку Pectra. Віталік зазначив, що EIP7702 також має деякі характеристики незворотності, які були детально обговорені під час обговорення EIP3074. Досить цікаво, що на засіданні була велика кількість представників ERC4337, які виступали.
Фактично, обговорення заміни EIP3074 на EIP7702 широко обговорювалося ще до 188-ї зустрічі основних розробників, і результатом тих обговорень стало те, що 3074 буде замінено, тому на зустрічі основних розробників не було великої суперечки.
Дорожня карта та рішення
Zerodev, основна інфраструктура абстракції облікових записів, опублікував цікаву статтю під назвою «Роздуми про управління Ethereum після саги 3074», дізнавшись, що EIP3074 буде замінено, зробивши висновок, що EIP7702 хороша пропозиція, яка приносить користь усім користувачам. Однак процес управління для EIP7702 замінити EIP3074 не є оптимальним з низки причин, зокрема:
Zerodev вважає, що найкращий шлях управління полягає в тому, щоб під час тривалої дискусії основних розробників EIP3074 спільнота ERC4337 повинна широко брати участь і висловлювати свою думку.
Розробники EIP3074 вважають, що ERC4337 має нести відповідальність за невдачу в управлінні. Оскільки EIP3074 активно брав участь в управлінні протягом останніх кількох років і неодноразово спілкувався з основним розробником ERC4337 yova.
Спільнота ERC4337 вважає, що EIP3074 повинна нести основну відповідальність за невдачу управління. Члени спільноти ERC4337 вважають, що Yova, як основний розробник ERC4337, неодноразово висловлював заперечення щодо EIP3074 на засіданнях основних розробників, але основні розробники, здається, не звертали на це уваги. Більшість членів спільноти ERC4337 не слідкували за динамікою управління EIP3074, більшість з них вважає, що EIP3074 є мертвою стандартом. Спільнота ERC4337 також вважає, що основні розробники не активно спілкуються зі спільнотою ERC4337.
EIP3074 та ERC4337 обидва вважають, що виконали правильну роботу з управління, а інша сторона повинна нести основну відповідальність за провал управління. Очевидно, що в цьому процесі управління існує більш глибока причина, яка відіграє роль.
Простими словами, цю більш глибоку причину насправді викликано дорожньою картою Ethereum. Дорожня карта Ethereum має владу, що перевищує повноваження основних розробників. Дорожня карта абстракції рахунків базується на ERC4337. EIP7702 повністю сумісний зі стандартом ERC4337, але EIP3074 не є достатньо сумісним зі стандартом ERC4337. Отже, з точки зору дорожньої карти Ethereum, заміна EIP3074 є неминучою.
Звичайно, дорожня карта Ethereum є відображенням особистого бачення Віталіка щодо майбутнього Ethereum. Якщо під час процесу управління виникають серйозні суперечки, то як визначник дорожньої карти Віталік має остаточне право вирішення. І саме рішення Віталіка призвело до заміни EIP3074.
Модель управління Ethereum - це модель values ⇒ vision ⇒ roadmaps ⇒ clients, або коротко модель VVRC. Процес управління виглядає наступним чином:
Вищезгаданий процес є справжнім процесом управління Ethereum. Ми можемо бачити, що особисте бачення Віталіка знаходиться в нижній частині моделі управління Ethereum, тому, коли в реалізації клієнта виникають серйозні суперечки, особиста думка Віталіка буде остаточним вирішенням.
> > Список літератури > > > Вступ до ZeroDev > > > null > > >
> > > Вступ до ZeroDev > > > null > > > > > >Примітки щодо дорожньої карти абстракції облікового запису - HackMD > > > # Примітки щодо дорожньої карти абстракції облікового запису *Особлива подяка Віталіку та команді AA за зворотний зв'язок > > > > > >