Автор: imToken
На прошлой неделе на встрече основных разработчиков Ethereum официально обсуждалось, включать ли EIP-8141 в обновление Hegota. Результат оказался неожиданным: этот предложение, лично поддержанное Виталиком, не было включено в список «главных функций» Hegota, а получило статус «рассматривается для включения» (CFI).
А на этой неделе квантовая команда Google AI опубликовала новую белую книгу, в которой сообщается, что при их аппаратных предположениях оценка необходимых физических кубитов для взлома ECDLP-256 снизилась в 20 раз по сравнению с предыдущими оценками. Хотя это не означает, что квантовая атака уже на пороге, это напоминает нам, что если система аккаунтов в будущем не сможет гибко менять логику верификации, то многие сегодняшние дискуссии об удобстве кошельков в конечном итоге могут превратиться в проблемы безопасности.
Хотя с практической точки зрения продвижения протокола EIP-8141 все еще слишком тяжел, особенно в реализации клиента, безопасности пула транзакций и сложности верификации, пока нет достаточного прочного консенсуса.
Но на текущий момент кажется, что тем для обсуждения и внимательного изучения EIP-8141 становится все больше.
一、Что именно решает EIP-8141?
EIP-8141 продвигается Виталиком Бутериным, timbeiko и другими ключевыми участниками, официальное название — Frame Transactions (фреймовые транзакции).
Если概括овать более понятными словами, он пытается не просто добавить какую-то функцию кошелька, а на уровне протокола позволить любому аккаунту не быть привязанным к единственному пути подписи ECDSA, а иметь более гибкую логику верификации и выполнения.
Это также означает, что мультиподпись, спонсирование газа, ротация ключей, социальное восстановление и даже будущее подключение квантоустойчивых схем подписи перестанут быть просто дополнительными возможностями, навешанными на кошелек снаружи, а получат шанс стать «родными членами» системы аккаунтов Ethereum.
Если смотреть поверхностно, EIP-8141 обсуждает набор очень конкретных возможностей: оплата газа стейблкоинами, объединение многошаговых операций в одну транзакцию, поддержка более гибких способов подписи и даже预留 места для будущих квантоустойчивых подписей. Можно сказать, что многие улучшения, от ERC-4337 до EIP-7702, годами по сути делали аккаунт не просто одним приватным ключом, а входом с настраиваемыми правилами.
Проблема в том, что эти улучшения действительно делают кошельки все более похожими на смарт-аккаунты, но так и не затрагивают самую основу модели аккаунтов по умолчанию в Ethereum.
Как известно, в существующей системе аккаунты Ethereum делятся на два типа. Первый — externally owned accounts (EOA), то есть знакомые всем аккаунты, контролируемые приватным ключом, которые могут инициировать транзакции, но не имеют возможности программирования. Второй — контрактные аккаунты, то есть сами смарт-контракты, которые могут выполнять сложную логику, но не могут самостоятельно инициировать транзакции.
Это приводит к тому, что способность инициировать транзакции долгое время была привязана к единственной подписи приватного ключа. Пока это условие не изменится, многие возможности, которые пользователи сегодня считают само собой разумеющимися, такие как гибкая смена правил подписи, оплата газа кем-то другим, восстановление контроля над аккаунтом после потери ключа или плавный переход на новую криптосистему в будущем, вряд ли станут стандартными возможностями аккаунта.
Если вы пользовались imToken или другими Web3-кошельками, вы наверняка сталкивались с этими проблемами: например, в кошельке много USDC, но без ETH нельзя отправить транзакцию (потому что газ можно оплачивать только ETH); потеря сид-фразы означает безвозвратную потерю денег, восстановление невозможно; операция «approve + swap» требует двух подписей и двух подтверждений и так далее.
Эти проблемы связаны не с тем, что продукты-кошельки «недостаточно хороши», а с самим дизайном модели аккаунтов Ethereum.
С этой точки зрения, эволюция последних двух лет уже довольно ясна: ERC-4337, не меняя протокол, запустил абстракцию аккаунтов сначала на уровне приложения; EIP-7702 further доказал, что EOA не полностью нерасширяемы, по крайней мере, они могут временно получать возможности, близкие к смарт-аккаунтам.
Другими словами, Ethereum не против абстракции аккаунтов, а всегда шел к этому более мягким, более консервативным way, постепенно приближаясь к цели. Появление EIP-8141 означает, что этот путь достиг новой точки. Он больше не удовлетворяется добавлением возможностей смарт-аккаунтов на периферии существующей системы, а пытается встроить абстракцию аккаунтов непосредственно в саму модель транзакций, чтобы аккаунты с уровня протокола обладали программируемой логикой верификации и выполнения.
Вот почему EIP-8141 снова набирает обороты сегодня. С одной стороны, пользовательский опыт кошельков верхнего уровня уже все ближе к нативной абстракции аккаунтов, и уровень протокола рано или поздно должен догнать. С другой стороны, долгосрочное давление квантовых вычислений превращает вопрос «может ли аккаунт гибко менять способ подписи» из далекой технической темы в реальную проблему, которую уже необходимо серьезно рассматривать.
二、Как работает EIP-8141?
В конечном счете, EIP-8141 вводит全新的 тип транзакций — фреймовую транзакцию (Frame Transaction) с номером типа 0x06.
Если базовая логика традиционной транзакции Ethereum — это один вызов на одну транзакцию, то EIP-8141 пытается разбить транзакцию на набор «фреймов», которые могут выполняться последовательно по правилам, таким образом разделяя原本 связанные together верификацию, оплату и выполнение.
Каждый «фрейм» имеет три режима выполнения:
- VERIFY (фрейм верификации): отвечает за проверку легитимности транзакции, запускает пользовательскую логику верификации аккаунта. Если проверка пройдена, вызывается новый opcode APPROVE для авторизации выполнения и указания лимита газа.
- SENDER (фрейм отправителя): выполняет фактические операции, такие как переводы, вызовы контрактов и т.д. Адрес вызывающего — это отправитель транзакции.
- DEFAULT (входной фрейм): использует адрес системного входа в качестве вызывающего, для развертывания контрактов, верификации Paymaster и других сценариев;
Значение этого механизма не в том, что транзакции могут стать сложнее, а в том, что впервые три действия — «верификация, оплата, выполнение» —分离 из действия аккаунта и交由 протоколу для нативного调度.
Ведь раньше то, кто проверяет транзакцию, кто платит за газ, кто выполняет реальную операцию, в основном было связано с одним действием аккаунта. В дизайне EIP-8141 эти действия могут быть разбиты на разные фреймы и выполняться протоколом в четкой последовательности. Именно поэтому аккаунт больше не должен полагаться на единственный приватный ключ для «полной подписи», а начинает приобретать форму, более близкую к программируемому исполняющему субъекту.
Приведем конкретный пример: предположим, вы хотите использовать USDC для оплаты газа при выполнении свопа. В рамках EIP-8141 это теоретически организовать как полный фреймовый процесс: сначала аккаунт проверяет подпись и права на выполнение, затем плательщик или Paymaster проверяет условия, при которых он готов покрыть расходы, затем происходит оплата комиссии соответствующим активом, и только затем выполняется сама операция свопа.
Таким образом, оплата газа и основная транзакция могут быть объединены в один атомарный процесс: либо все успешно, либо все откатывается.
Для пользователя самым直观ным изменением будет то, что многие операции, которые раньше приходилось разбивать на два-три шага с риском неудачи между ними, в будущем могут выглядеть как одно целое действие. Эта атомарность также является ключом к решению EIP-8141 проблемы фрагментации пользовательского опыта.
Что это значит для пользователей кошельков? С точки зрения результата, наиболее очевидных изменений как минимум четыре:
- Абстракция оплаты газа: наличие стейблкоинов в кошельке больше не означает, что вам дополнительно нужно иметь немного ETH для операций. В будущем оплата газа DApp, Paymaster или другими спонсорами станет более нативной;
- Объединение многошаговых операций: такие процессы, как «approve + swap», «approve + стейкинг», которые сейчас часто требуют multiple подписей, могут быть упакованы в одну более complete операцию;
- Открытие правил безопасности аккаунта: мультиподпись, социальное восстановление, дневные лимиты, временные замки, ротация ключей — все это перестает быть просто дополнительными функциями, предоставляемыми某个 продуктом-кошельком, а получает возможность строиться на более нативной логике аккаунта;
- Схемы подписи больше не обязаны быть намертво привязаны к единственному пути ECDSA: это впервые дает аккаунту возможность миграции на разные криптосистемы, включая постквантовые схемы подписи, на уровне протокола;
三、Почему не стал главной фичей Hegotá?
Легко упустить из виду, но для пользователей кошельков ключевой момент заключается в следующем: даже если EIP-8141最终 будет реализован, существующая система аккаунтов не будет полностью推翻нута.
Даже если вы сейчас используете imToken или другие существующие Web3-кошельки, вам не нужно migрировать, потому что он обратно совместим. Существующие EOA-адреса могут продолжать использоваться, нужно лишь в подходящее время выбрать «апгрейд» логики верификации аккаунта.
Но, с другой стороны, именно потому, что изменения достаточно глубоки, он и не стал главной функцией в последнем раунде обсуждений Hegotá. Однако, согласно процессу champion EIP 2026 года, CFI (Considered for Inclusion) означает не отказ, а переход на стадию серьезного рассмотрения, но еще не до final решения о включении.
Другими словами, основные разработчики не отвергают направление EIP-8141, а, признавая его ценность, также считают, что он пока еще слишком «тяжелый».
Ведь нативная абстракция аккаунтов, в отличие от ERC-4337, которую可以先 продвигать постепенно少数 кошельками, инфраструктурой и приложениями,一旦 попадает на уровень протокола, означает, что все клиенты уровня выполнения должны серьезно реализовывать, тестировать и координировать. Это天然 повышает порог внедрения и заставляет основных разработчиков при планировании форков склоняться к более稳妥ным решениям.
Что будет дальше? Можно разделить на two линии:
- Поскольку EIP-8141 находится в статусе CFI, он продолжает оцениваться. Авторы предложения будут продолжать дополнять ключевые детали, касающиеся безопасности пула транзакций, правил верификации и реализации клиентов. Последующие meetings ACD также будут пересматривать,具备 ли он условиями для дальнейшего продвижения;
- Если эти неопределенности будут持续 сжиматься, у него появится шанс перейти на более существенную стадию включения в последующих обновлениях; если нет, он вполне может быть отложен на более поздние циклы обновлений;
客观地说, EIP-8141 также не является единственным предложением по нативной абстракции аккаунтов и сам по себе не является готовой квантоустойчивой схемой подписи, не может напрямую решить проблему квантовых вычислений. Но его важность заключается в том, что он впервые предоставляет выход на уровне протокола для освобождения аккаунтов от единственного пути ECDSA.
С этой точки зрения, истинная ценность EIP-8141 заключается не в том, является ли он единственным правильным ответом, а в том, что он впервые非常完整地 выносит на стол обсуждений протокола Ethereum вопрос: «Как в конечном итоге должна выглядеть нативная абстракция аккаунтов?».
Это не единственное решение, но оно действительно является одним из самых амбициозных и близких к上限 воображения «полной нативной AA» на данный момент.
Вне зависимости от того, успеет ли EIP-8141 в Hegotá или нет, само это обсуждение по крайней мере уже说明了一件事:
Ethereum не ждет на месте发酵 проблем, а日拱一卒地 прокладывает путь для системы аккаунтов следующего поколения.
