EIP-8141: Почему нативная абстракция аккаунтов не является ключевой функцией обновления Hegota в ethereum

Автор: imToken

На прошлой неделе на встрече разработчиков Ethereum официально обсудили включение EIP-8141 в обновление Hegota. Результат оказался неожиданным: предложение, поддержанное лично Vitalik, не было включено в число «ключевых функций» Hegota, а получило статус «рассматривается на включение» (CFI).

На этой неделе команда Google Quantum AI опубликовала новую белую книгу, в которой сообщается, что оценка количества физических кубитов, необходимых для взлома ECDLP-256 при заданных предположениях о аппаратном обеспечении, снизилась в 20 раз по сравнению с предыдущими расчетами. Хотя это не означает, что квантовые атаки уже близки, это реальное напоминание о том, что если система учетных записей в будущем не сможет гибко менять логику проверки, многие сегодняшние обсуждения опыта кошельков могут в конечном итоге превратиться в проблемы безопасности.

Хотя с практической точки зрения продвижения протокола EIP-8141 пока остается слишком тяжелым, особенно в плане реализации клиентов, безопасности пула транзакций и сложности проверки, достаточного консенсуса пока не сформировано.

Но на текущем этапе вопросов, заслуживающих обсуждения и внимательного рассмотрения в отношении EIP-8141, кажется, действительно становится все больше.

EIP-8141, продвигаемый Vitalik Buterin, timbeiko и другими ключевыми участниками, официально называется Frame Transactions.

Если выразить это проще, цель состоит не в том, чтобы добавить отдельную функцию кошелька, а в том, чтобы на уровне протокола освободить любые аккаунты от привязки к единому пути подписи ECDSA, позволив им использовать более гибкие логики проверки и выполнения.

Это также означает, что мультиподпись, спонсорство газа, смена ключей, социальное восстановление и даже будущая интеграция квантово-устойчивых подписей больше не будут лишь внешними функциями, добавленными к кошельку, а получат возможность стать «родными участниками» экосистемы аккаунтов Ethereum.

Если смотреть только на поверхность, EIP-8141 обсуждает набор очень конкретных возможностей: оплата газа стабильной монетой, объединение нескольких операций в одну транзакцию, поддержка более гибких способов подписи и даже резервирование места для будущих квантово-устойчивых подписей. Можно сказать, что многие улучшения в опыте кошелька, начиная с ERC-4337 и до EIP-7702, по сути направлены на то, чтобы аккаунт перестал быть просто приватным ключом и превратился в настраиваемую точку входа.

Проблема в том, что эти улучшения действительно сделали кошельки все более похожими на смарт-аккаунты, но так и не затронули самую базовую модель аккаунтов по умолчанию в Ethereum.

Как известно, в существующей системе аккаунты Ethereum в основном делятся на два типа. Один — это внешние аккаунты, известные как EOA, которые управляются приватными ключами и могут инициировать транзакции самостоятельно, но не обладают возможностью программирования. Другой — это аккаунты контрактов, то есть сами смарт-контракты, которые могут выполнять сложную логику, но не могут инициировать транзакции самостоятельно.

Это приводит к тому, что возможность инициировать транзакции долгое время была жестко связана с подписью единственным приватным ключом. Пока это условие не изменится, многие функции, которые сегодня пользователи считают само собой разумеющимися — такие как гибкая смена правил подписи, возможность оплаты газа другим лицом, восстановление контроля над аккаунтом после потери приватного ключа или будущее плавное переключение на новую криптографическую систему — будет сложно сделать стандартными возможностями аккаунта.

Если вы использовали imToken или другие Web3-кошельки, вы, скорее всего, сталкивались с этими проблемами: например, в кошельке есть много USDC, но вы не можете отправить транзакцию, потому что не хватает ETH (так как Gas можно оплатить только ETH); потеря мнемонической фразы означает полную потерю средств и невозможность восстановления; операция «авторизация + обмен» требует двух подписей и двух подтверждений и т.д.

Эти проблемы не связаны с тем, что кошелек недостаточно хорош, а являются результатом самой архитектуры аккаунтной модели Ethereum.

С этой точки зрения эволюция за последние два года уже очень ясна: ERC-4337 позволил запустить абстракцию аккаунтов на уровне приложений без изменения протокола; EIP-7702 дал дальнейшее подтверждение, что EOA не являются полностью нерасширяемыми — по крайней мере, они могут временно получать часть возможностей смарт-аккаунтов.

То есть Эфириум не отказывается от абстракции аккаунтов, а последовательно и осторожно приближается к этому вопросу. Появление EIP-8141 означает, что этот путь достиг новой стадии: вместо того чтобы добавлять возможности смарт-аккаунтов поверх существующей системы, он стремится встроить абстракцию аккаунтов непосредственно в модель транзакций, обеспечивая программируемую логику проверки и выполнения на уровне протокола.

Вот почему EIP-8141 сегодня снова набирает обороты. С одной стороны, опыт использования кошельков верхнего уровня все больше приближается к нативной абстракции аккаунтов, и протокольный уровень рано или поздно должен успеть за этим; с другой стороны, долгосрочное давление со стороны квантовых вычислений превращает вопрос «может ли аккаунт гибко менять способ подписи» из отдаленной технической проблемы в насущную реальность, которую необходимо серьезно рассмотреть.

В конечном счете, EIP-8141 вводит новый тип транзакции — фрейм-транзакцию (Frame Transaction), с номером типа 0x06.

Если базовая логика традиционных транзакций Ethereum заключается в том, что одна транзакция соответствует одному вызову, то EIP-8141 стремится разбить одну транзакцию на набор «кадров», которые могут выполняться в определённом порядке, тем самым разделяя три ранее связанных действия — проверку, оплату и выполнение.

Каждый «кадр» имеет три режима выполнения:

• VERIFY (проверка фрейма): отвечает за проверку легитимности транзакции; он выполняет пользовательскую логику проверки аккаунта, и если проверка пройдена, вызывает новый оператор APPROVE для авторизации выполнения и указания лимита газа.
• ОТПРАВИТЕЛЬ (отправка фрейма): выполняет фактические действия, такие как переводы средств или вызовы смарт-контрактов. Адрес вызывающего лица является адресом самого отправителя транзакции.
• DEFAULT (входной кадр): используется в качестве вызывающего адреса системы для сценариев развертывания смарт-контрактов, проверки Paymaster и т.д.;

Значение этого механизма заключается не в том, чтобы сделать торговлю более сложной, а в том, что впервые «проверка, оплата, выполнение» были отделены от действий с аккаунтом и переданы на управление нативному протоколу.

В прошлом проверка транзакций, оплата Gas и выполнение реальных операций были жестко связаны с одним и тем же действием аккаунта. В рамках дизайна EIP-8141 эти действия могут быть разделены на отдельные фреймы, которые протокол выполняет в строго определенном порядке. Именно поэтому аккаунт больше не ограничен необходимостью «подписывать целиком» с помощью единственного приватного ключа, а начинает приобретать форму, более близкую к программируемому исполнительному субъекту.

Возьмем конкретный пример: предположим, вы хотите оплатить газ в USDC для выполнения операции Swap. В рамках EIP-8141 это теоретически может быть организовано как полный процесс фрейма: сначала аккаунт проверяет подпись и права на выполнение, затем плательщик или Paymaster проверяет условия своего согласия покрыть расходы, после чего производится оплата соответствующих активов, и наконец выполняется сама операция Swap.

Таким образом, оплата Gas и основная транзакция могут быть включены в одну атомарную процедуру — либо обе успешны, либо обе отменены.

Для пользователей самым очевидным изменением станет то, что многие операции, которые раньше требовали разбиения на два-три шага с риском сбоя на промежуточных этапах, в будущем будут выполняться как единое целое. Именно эта атомарность является одним из ключевых аспектов, которые EIP-8141 стремится решить для устранения фрагментации пользовательского опыта.

Что это означает для пользователей кошельков? По итогам, как минимум, есть четыре очевидных изменения:

• Оплата газа абстрагирована: наличие стабильной монеты в кошельке больше не означает, что вам нужно дополнительно иметь ETH для выполнения операций; в будущем оплата газа со стороны dapp, Paymaster или других спонсоров станет более естественной;
• Несколько шагов объединены: такие процессы, как «авторизация + Swap» или «авторизация + стейкинг», которые сейчас часто требуют нескольких подписей, могут быть объединены в одну более целостную операцию;
• Правила безопасности аккаунта включены: мультиподпись, социальное восстановление, ежедневные лимиты, таймлок и смена ключей — это больше не просто дополнительные функции, предлагаемые отдельными кошельками, а начинают внедряться на более нативном уровне логики аккаунта;
• Схема подписи больше не обязана быть заблокирована исключительно на пути ECDSA: это впервые предоставляет протокольную возможность для будущего перевода аккаунтов на другие криптографические системы, включая постквантовые схемы подписи;

Одна из важных, но часто упускаемых из виду деталей для пользователей кошельков: даже если EIP-8141 будет окончательно реализован, существующая система аккаунтов не будет полностью отменена.

Даже если вы сейчас используете существующий Web3-кошелек, такой как imToken, вам не нужно выполнять миграцию, так как он обратно совместим: существующие EOA-адреса можно продолжать использовать, достаточно просто выбрать логику «обновления» проверки учетной записи в подходящий момент.

Но, с другой стороны, именно потому, что изменения были достаточно глубокими, он не стал ведущей функцией Hegotá в последнем цикле обсуждений. Тем не менее, в соответствии с процессом EIP champion 2026 года, CFI (Considered for Inclusion) означает не отклонение, а переход на этап серьезного рассмотрения, но еще не до финального решения о запуске.

Другими словами, основные разработчики не отвергают направление EIP-8141, а, признавая его ценность, считают, что оно пока слишком «тяжелое».

Ведь абстракция собственных аккаунтов не может, как ERC-4337, постепенно продвигаться через небольшое количество кошельков, инфраструктуры и приложений; как только она попадает на уровень протокола, это означает, что все клиенты исполнительного уровня должны реально реализовать, протестировать и скоординировать её, что естественным образом повышает барьер для продвижения и заставляет основных разработчиков при планировании форка отдавать предпочтение более осторожному подходу.

А что произойдет дальше? Можно рассмотреть это по двум линиям:

• EIP-8141, находясь в статусе CFI, означает, что он продолжает оцениваться; авторы предложения будут продолжать дополнять ключевые детали, связанные с безопасностью пула транзакций, правилами проверки и реализацией клиентов, а на последующих встречах ACD будет повторно рассмотрено, соответствует ли он условиям для дальнейшего продвижения;
• Если эти неопределенности смогут быть постоянно сжаты, у них появится шанс перейти на более значимый этап включения на последующих обновлениях; если нет, они вполне могут быть отложены на более поздний цикл обновлений;

Честно говоря, EIP-8141 — не единственный предложенный протокол нативной абстракции аккаунтов, и он сам по себе не является готовым постквантовым подписывающим решением, не способным напрямую решить проблемы, связанные с квантовыми вычислениями; однако его важность заключается в том, что он впервые предоставляет протокольный выход для выхода аккаунтов из единого пути ECDSA.

С этой точки зрения истинная ценность EIP-8141 заключается не в том, является ли она единственным правильным ответом, а в том, что она впервые полностью поставила на стол обсуждения протокола Ethereum вопрос: «Каким должен быть финальный вид нативной абстракции аккаунтов?»

Это не единственный вариант, но он один из самых амбициозных и ближе всего к пределу представлений о «полностью нативном AA».

Независимо от того, успеет ли EIP-8141 догнать Hegotá или нет, само это обсуждение по крайней мере доказывает один факт:

Эфириум не оставался на месте, пока проблемы накапливались, а последовательно прокладывал путь для следующего поколения систем учетных записей.