В обновлении Pectra возникла самая сложная проблема управления. После того, как EIP3074 был включен в обновление Pectra, возникли большие споры, особенно со стороны команды ERC4337.
EIP3074 столкнулся с трудностями, процесс управления не может продолжаться. Пока Виталик не предложил EIP7702, который положил конец критике команды ERC4337 по поводу EIP3074.
Исследование GCC обнаружило, что в китайском мире мало обсуждается вопрос управления 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 относится к адресу контракта invoker, который пользователь желает делегировать. EVM будет проверять, совпадает ли содержимое подписи пользователя с контрактом, который действительно проверяет подпись, чтобы избежать использования содержимого AUTH-подписи пользователя другими контрактами.
Nonce является идентификатором, предотвращающим повторную атаку на транзакции. Однако следует обратить внимание на то, что операция AUTH будет проверять, совпадает ли nonce в подписи с текущим nonce EOA. Теоретически, если пользователь не использует EOA-аккаунт для инициирования транзакции с увеличением значения nonce, то AUTH-подпись, выданная пользователем, может постоянно использоваться контрактом invoker. Это представляет собой огромную уязвимость безопасности, что означает, что пользователи, использующие EIP3074, должны доверять релейным сервисам, получающим подписи. Если релейный сервис, получивший подпись пользователя, является злонамеренным, он может в какой-то момент повторно воспроизвести AUTH-подпись пользователя для кражи активов пользователя.
Еще одной проблемой безопасности является поле commit. Поле commit используется для обеспечения определенных операций, пользователь может точно контролировать свои права подписи внутри commit, например, записывая некоторые данные в commit, чтобы избежать использования своих подписей для перевода ETH. В документе EIP3074 инициатор предлагает ряд примеров использования поля commit. Однако проблема в том, что роль commit полностью зависит от определения смарт-контракта, по сути, это необязательный элемент. Разные смарт-контракты могут совершенно по-разному интерпретировать содержимое commit, некоторые контракты могут вообще не считывать содержимое commit. Если пользователь хочет безопасно использовать 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 некоторые разработчики предложили стандартизировать подпись 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.
Очевидно, что из-за проблем с безопасностью EIP3074 это предложение не было включено в обновление London.
На Meeting #115, состоявшемся 11 июня 2021 года, разработчики EIP3074 представили отчет по безопасности. Основное внимание на встрече было уделено вопросам безопасности EIP3074. Простое заключение состоит в том, что контракт invoker EIP3074 имеет большое значение для системы, поэтому вопрос о необходимости управления контрактом invoker является актуальным. Разработчики EIP3074 надеются провести формальное доказательство для контракта invoker, чтобы повысить безопасность.
Конечно, есть также часть дискуссии о некоторых контрактах, использующих msg.sender == tx.origin для определения того, является ли адрес вызова EOA, и когда EIP3074 будет введен, эти решения будут признаны недействительными, но вывод таков, что отказ от этой части решения не вызовет серьезных проблем с безопасностью. В двух словах, встреча была посвящена EIP3074 докладчикам, представляющим результаты аудита безопасности 3074 основным разработчикам. Окончательный вывод встречи заключался в том, что 3074 все еще нуждается в рассмотрении вопроса о контракте инициатора, и рекомендуется не присоединяться в рамках хардфорка London.
25 июня 2021 года на встрече #116 основной автор 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.
В ходе заседания #167 3 августа 2023 года ключевые разработчики упомянули EIP3074, обсуждая другой EIP5806. EIP5806 — это предложение, позволяющее EOA вызывать внешние контракты с помощью deleGate.io call в процессе транзакции. Эта схема в определенной степени похожа на EIP7702. Однако ключевые разработчики также выразили сомнения по поводу безопасности этой схемы; Ансгар отметил, что из-за возможных проблем с безопасностью EIP3074 не удалось включить в жесткий форк, а EIP5806 является более радикальным предложением.
На встрече #182, которая состоялась 29 февраля 2024 года, разработчики подробно обсудили, должна ли EIP3074 быть включена в обновление Pectra. Виталик предложил, что любой стандарт абстракции аккаунтов должен иметь следующие три функции:
Ротация ключей
Устаревание ключа
Совместимые с квантово-устойчивыми подписями
Виталик отметил, что EIP5806 может быть лучшим выбором по сравнению с EIP3074. Эндрю считает, что EIP3074 более универсален, и предлагает использовать EIP3074. Виталик опроверг Эндрю, заявив, что в будущем все кошельки могут стать кошельками смарт-контрактов, и как только это произойдет, предоперационные коды, вводимые EIP3074, потеряют свою эффективность. Ёав, как автор ERC4337, выступил с довольно длинным выступлением на этой конференции, в котором основное внимание было уделено:
EIP3074 может привести к DoS-атакам на память Ethereum, в то время как ERC4337 провел обширные исследования по этой части и предложил некоторые правила для предотвращения атак.
EIP3074 требует дважды подписывать транзакции при инициировании массовых переводов пользователем, что неразумно.
EIP3074 требует использования централизованных ретрансляторов
Yova более склонна использовать EIP5806 в качестве решения для абстракции учетных записей.
На внутреннем заседании Meeting #183 14 марта 2024 года ведущие разработчики пригласили Дэна Финлея из MetaMask обсудить мнение кошельков об EIP3074. Дэн поддерживает EIP3074 и также отмечает, что MetaMask будет поддерживать тестирование EIP3074. MetaMask считает, что EIP3074 функционально позволяет EOA пользоваться всеми функциями абстракции счета. В плане безопасности EIP3074 предоставляет кошельковым сервисам решение в виде разделения горячих и холодных ключей. Кошельковые сервисы могут использовать EIP3074 подпись EOA для инициирования транзакций, пользователи могут использовать горячий ключ для обычных транзакций, но холодный ключ может храниться в аппаратном кошельке пользователя; в случае обнаружения чрезвычайной ситуации пользователь может использовать холодный ключ из холодного кошелька для инициирования отмены подписи EIP3074. Такое решение по разделению горячих и холодных ключей предоставляет гибкость для поставщиков кошельков.
Виталик отметил, что в EIP3074 разработчики кошельков должны создать строгую логику авторизации, чтобы избежать злоупотребления подписями пользователей EIP3074. Интересно, что в обсуждении добавления поддержки функции EIP3074 в MetaMask Виталик указал, что можно использовать L2 в качестве переходного решения, то есть любые новые изменения в исполнительном слое должны быть сначала протестированы в L2, так как объем средств в L2 ограничен, и даже в случае серьезной проблемы это приведет к серьезным потерям.
Дрор Тирос в обсуждении указал, что лучшим способом обеспечить безопасность EIP3074 является прямое предоставление контракта invoker официальным Ethereum. Однако Дэн Финлей выступил против мнения о том, что контракт должен быть предоставлен официально, он считает, что контракт invoker должен полностью определяться пользователями, и в конечном итоге рынок выберет самый безопасный контракт invoker.
Ансгар по-прежнему настаивает на том, что EIP3074 одно подписание должно соответствовать только одной транзакции, и провайдеры кошельков не должны повторно использовать подписи пользователей для инициации транзакций, но Дэн Финлей также выразил несогласие. Дэн Финлей считает, что EIP3074 должен подписываться холодным кошельком, а затем провайдеры кошельков могут повторно использовать эту подпись для инициации транзакций от имени пользователей; если каждый раз требовать от пользователя повторной подписи, это может привести к многократному использованию холодного приватного ключа. Это противоречит идее разделения холодных и горячих ключей.
На этой конференции основные разработчики обсудили еще одну важную тему — список включения. Список включения является способом увеличения антикоррупционных свойств Ethereum. Проще говоря, список включения позволяет некоторым транзакциям быть обещанными для непосредственного включения в следующий блок. Однако основные разработчики отметили, что EIP3074 противоречит списку включения.
На внутреннем заседании #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, что может вызвать проблемы с безопасностью средств.
На встрече #188, состоявшейся 23 мая 2024 года, основная группа разработчиков обсудила возможность замены EIP7702 на EIP3074. Окончательное решение этой встречи заключалось в использовании EIP7702 вместо EIP3074 в качестве стандарта абстракции учетных записей в рамках жесткого форка Pectra. Виталик отметил, что EIP7702 также обладает некоторыми свойствами необратимости, аналогичными EIP3074, которые уже были предметом обширного обсуждения при обсуждении EIP3074. Интересно, что на встрече присутствовало много представителей ERC4337, которые выступали с речами.
На самом деле, обсуждение замены EIP3074 на EIP7702 широко обсуждалось до 188-го собрания разработчиков ядра, когда обсуждение привело к замене 3074, поэтому на собрании разработчиков ядра не было много разногласий.
Дорожная карта и решение
Основная инфраструктура аккаунт-абстракции Zerodev, узнав о том, что EIP3074 будет заменен, опубликовала интересную статью с заголовком "Reflections on Ethereum Governance Following the 3074 Saga". В статье делается вывод, что EIP7702 является хорошим предложением, которое может принести выгоду всем пользователям. Однако процесс управления заменой EIP3074 на EIP7702 не является оптимальным, причины включают:
EIP3074 прошел длительный процесс обсуждения, в предыдущем тексте мы уже представили множество обсуждений EIP3074 на встречах основных разработчиков.
После того как EIP3074 был определён как часть обновления Pectra, он столкнулся с большим количеством противодействия со стороны сообщества ERC4337. Конечно, в вышеупомянутом мы уже указали, что основной разработчик ERC4337 yova многократно выражал своё недовольство EIP3074 на встречах основных разработчиков.
Zerodev считает, что лучший путь управления должен заключаться в том, что сообщество ERC4337 должно широко участвовать и выражать свое мнение в ходе долгих обсуждений среди основных разработчиков EIP3074.
Разработчики 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. Если в процессе управления Ethereum возникнут серьезные споры, то как определитель дорожной карты Виталик имеет окончательное право решать. Именно решение Виталика привело к замене EIP3074.
Модель управления Ethereum представляет собой модель values ⇒ vision ⇒ roadmaps ⇒ clients, или сокращенно модель VVRC. Процесс управления следующий:
ценности, особенно ценности сообщества, ценности сообщества Ethereum включают децентрализацию, антиконтроль и т.д.
vision Видение, на самом деле, это личные размышления Виталика о будущем Эфириума.
дорожные карты, исследователь на основе видения предоставляет некоторые технические детали и предлагает более полную реализацию дорожной карты.
Клиенты Клиентская реализация, основные разработчики клиента обсуждают дорожную карту с помощью таких инструментов, как собрания основных разработчиков, и реализуют требования, содержащиеся в дорожной карте.
Указанный процесс является настоящим процессом управления Эфириумом. Мы можем видеть, что личное видение Виталика находится в нижней части модели управления Эфириумом, поэтому, как только в клиенте возникают серьезные споры, личное мнение Виталика будет окончательным решением.
Список литературы
Введение в ZeroDev
null
Введение в ZeroDev
null
Примечания по дорожной карте абстракции аккаунта - HackMD
Заметки по дорожной карте абстракции аккаунтов *Особая благодарность Виталику и команде AA за отзывы
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Эфирное управление война: 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).
В предыдущей статье 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.
Каково конкретное содержание подписи пользователя? Пользователь должен подписать следующее содержание:
! Войны управления Ethereum: EIP3074, ERC4337 и EIP7702
В приведенном выше содержании адрес invoker относится к адресу контракта invoker, который пользователь желает делегировать. EVM будет проверять, совпадает ли содержимое подписи пользователя с контрактом, который действительно проверяет подпись, чтобы избежать использования содержимого AUTH-подписи пользователя другими контрактами.
Nonce является идентификатором, предотвращающим повторную атаку на транзакции. Однако следует обратить внимание на то, что операция AUTH будет проверять, совпадает ли nonce в подписи с текущим nonce EOA. Теоретически, если пользователь не использует EOA-аккаунт для инициирования транзакции с увеличением значения nonce, то AUTH-подпись, выданная пользователем, может постоянно использоваться контрактом invoker. Это представляет собой огромную уязвимость безопасности, что означает, что пользователи, использующие EIP3074, должны доверять релейным сервисам, получающим подписи. Если релейный сервис, получивший подпись пользователя, является злонамеренным, он может в какой-то момент повторно воспроизвести AUTH-подпись пользователя для кражи активов пользователя.
Еще одной проблемой безопасности является поле commit. Поле commit используется для обеспечения определенных операций, пользователь может точно контролировать свои права подписи внутри commit, например, записывая некоторые данные в commit, чтобы избежать использования своих подписей для перевода ETH. В документе EIP3074 инициатор предлагает ряд примеров использования поля commit. Однако проблема в том, что роль commit полностью зависит от определения смарт-контракта, по сути, это необязательный элемент. Разные смарт-контракты могут совершенно по-разному интерпретировать содержимое commit, некоторые контракты могут вообще не считывать содержимое commit. Если пользователь хочет безопасно использовать 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 некоторые разработчики предложили стандартизировать подпись 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.
Очевидно, что из-за проблем с безопасностью EIP3074 это предложение не было включено в обновление London.
На Meeting #115, состоявшемся 11 июня 2021 года, разработчики EIP3074 представили отчет по безопасности. Основное внимание на встрече было уделено вопросам безопасности EIP3074. Простое заключение состоит в том, что контракт invoker EIP3074 имеет большое значение для системы, поэтому вопрос о необходимости управления контрактом invoker является актуальным. Разработчики EIP3074 надеются провести формальное доказательство для контракта invoker, чтобы повысить безопасность.
Конечно, есть также часть дискуссии о некоторых контрактах, использующих msg.sender == tx.origin для определения того, является ли адрес вызова EOA, и когда EIP3074 будет введен, эти решения будут признаны недействительными, но вывод таков, что отказ от этой части решения не вызовет серьезных проблем с безопасностью. В двух словах, встреча была посвящена EIP3074 докладчикам, представляющим результаты аудита безопасности 3074 основным разработчикам. Окончательный вывод встречи заключался в том, что 3074 все еще нуждается в рассмотрении вопроса о контракте инициатора, и рекомендуется не присоединяться в рамках хардфорка London.
25 июня 2021 года на встрече #116 основной автор 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.
В ходе заседания #167 3 августа 2023 года ключевые разработчики упомянули EIP3074, обсуждая другой EIP5806. EIP5806 — это предложение, позволяющее EOA вызывать внешние контракты с помощью deleGate.io call в процессе транзакции. Эта схема в определенной степени похожа на EIP7702. Однако ключевые разработчики также выразили сомнения по поводу безопасности этой схемы; Ансгар отметил, что из-за возможных проблем с безопасностью EIP3074 не удалось включить в жесткий форк, а EIP5806 является более радикальным предложением.
На встрече #182, которая состоялась 29 февраля 2024 года, разработчики подробно обсудили, должна ли EIP3074 быть включена в обновление Pectra. Виталик предложил, что любой стандарт абстракции аккаунтов должен иметь следующие три функции:
Виталик отметил, что EIP5806 может быть лучшим выбором по сравнению с EIP3074. Эндрю считает, что EIP3074 более универсален, и предлагает использовать EIP3074. Виталик опроверг Эндрю, заявив, что в будущем все кошельки могут стать кошельками смарт-контрактов, и как только это произойдет, предоперационные коды, вводимые EIP3074, потеряют свою эффективность. Ёав, как автор ERC4337, выступил с довольно длинным выступлением на этой конференции, в котором основное внимание было уделено:
Yova более склонна использовать EIP5806 в качестве решения для абстракции учетных записей.
На внутреннем заседании Meeting #183 14 марта 2024 года ведущие разработчики пригласили Дэна Финлея из MetaMask обсудить мнение кошельков об EIP3074. Дэн поддерживает EIP3074 и также отмечает, что MetaMask будет поддерживать тестирование EIP3074. MetaMask считает, что EIP3074 функционально позволяет EOA пользоваться всеми функциями абстракции счета. В плане безопасности EIP3074 предоставляет кошельковым сервисам решение в виде разделения горячих и холодных ключей. Кошельковые сервисы могут использовать EIP3074 подпись EOA для инициирования транзакций, пользователи могут использовать горячий ключ для обычных транзакций, но холодный ключ может храниться в аппаратном кошельке пользователя; в случае обнаружения чрезвычайной ситуации пользователь может использовать холодный ключ из холодного кошелька для инициирования отмены подписи EIP3074. Такое решение по разделению горячих и холодных ключей предоставляет гибкость для поставщиков кошельков.
Виталик отметил, что в EIP3074 разработчики кошельков должны создать строгую логику авторизации, чтобы избежать злоупотребления подписями пользователей EIP3074. Интересно, что в обсуждении добавления поддержки функции EIP3074 в MetaMask Виталик указал, что можно использовать L2 в качестве переходного решения, то есть любые новые изменения в исполнительном слое должны быть сначала протестированы в L2, так как объем средств в L2 ограничен, и даже в случае серьезной проблемы это приведет к серьезным потерям.
Дрор Тирос в обсуждении указал, что лучшим способом обеспечить безопасность EIP3074 является прямое предоставление контракта invoker официальным Ethereum. Однако Дэн Финлей выступил против мнения о том, что контракт должен быть предоставлен официально, он считает, что контракт invoker должен полностью определяться пользователями, и в конечном итоге рынок выберет самый безопасный контракт invoker.
Ансгар по-прежнему настаивает на том, что EIP3074 одно подписание должно соответствовать только одной транзакции, и провайдеры кошельков не должны повторно использовать подписи пользователей для инициации транзакций, но Дэн Финлей также выразил несогласие. Дэн Финлей считает, что EIP3074 должен подписываться холодным кошельком, а затем провайдеры кошельков могут повторно использовать эту подпись для инициации транзакций от имени пользователей; если каждый раз требовать от пользователя повторной подписи, это может привести к многократному использованию холодного приватного ключа. Это противоречит идее разделения холодных и горячих ключей.
На этой конференции основные разработчики обсудили еще одну важную тему — список включения. Список включения является способом увеличения антикоррупционных свойств Ethereum. Проще говоря, список включения позволяет некоторым транзакциям быть обещанными для непосредственного включения в следующий блок. Однако основные разработчики отметили, что EIP3074 противоречит списку включения.
На внутреннем заседании #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, что может вызвать проблемы с безопасностью средств.
На встрече #188, состоявшейся 23 мая 2024 года, основная группа разработчиков обсудила возможность замены EIP7702 на EIP3074. Окончательное решение этой встречи заключалось в использовании EIP7702 вместо EIP3074 в качестве стандарта абстракции учетных записей в рамках жесткого форка Pectra. Виталик отметил, что EIP7702 также обладает некоторыми свойствами необратимости, аналогичными EIP3074, которые уже были предметом обширного обсуждения при обсуждении EIP3074. Интересно, что на встрече присутствовало много представителей ERC4337, которые выступали с речами.
На самом деле, обсуждение замены EIP3074 на EIP7702 широко обсуждалось до 188-го собрания разработчиков ядра, когда обсуждение привело к замене 3074, поэтому на собрании разработчиков ядра не было много разногласий.
Дорожная карта и решение
Основная инфраструктура аккаунт-абстракции Zerodev, узнав о том, что EIP3074 будет заменен, опубликовала интересную статью с заголовком "Reflections on Ethereum Governance Following the 3074 Saga". В статье делается вывод, что EIP7702 является хорошим предложением, которое может принести выгоду всем пользователям. Однако процесс управления заменой EIP3074 на EIP7702 не является оптимальным, причины включают:
Zerodev считает, что лучший путь управления должен заключаться в том, что сообщество ERC4337 должно широко участвовать и выражать свое мнение в ходе долгих обсуждений среди основных разработчиков EIP3074.
Разработчики 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. Если в процессе управления Ethereum возникнут серьезные споры, то как определитель дорожной карты Виталик имеет окончательное право решать. Именно решение Виталика привело к замене EIP3074.
Модель управления Ethereum представляет собой модель values ⇒ vision ⇒ roadmaps ⇒ clients, или сокращенно модель VVRC. Процесс управления следующий:
Указанный процесс является настоящим процессом управления Эфириумом. Мы можем видеть, что личное видение Виталика находится в нижней части модели управления Эфириумом, поэтому, как только в клиенте возникают серьезные споры, личное мнение Виталика будет окончательным решением.