Нативная абстракция аккаунтов + защита от квантовых угроз: почему EIP-8141 еще не стал флагманом Ethereum Hegotá?

Автор: imToken

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

А на этой неделе команда Google по квантовым вычислениям и искусственному интеллекту опубликовала новый white paper и заявила, что при заданных ею допущениях по аппаратному обеспечению оценка физического количества квантовых битов, необходимых для взлома ECDLP-256, по сравнению с ранее опубликованными оценками существенно снизилась — в 20 раз. Хотя это и не означает, что квантовые атаки уже совсем рядом, это вполне конкретно напоминает: если в будущем система аккаунтов не сможет гибко менять логику верификации, то многие обсуждения «комфорта кошелька», которые сегодня кажутся естественными, в итоге могут превратиться в проблемы безопасности.

Хотя с точки зрения реальной динамики продвижения протокола EIP-8141 на данный момент всё ещё слишком «тяжёлый», особенно с точки зрения реализации на клиенте, безопасности transaction pool и сложности верификации — до сих пор не сформировался достаточно твёрдый консенсус.

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

I. Что именно EIP-8141 должен решать?

EIP-8141 продвигают Виталик Бутерин и такие ключевые участники, как timbeiko; официальное название — Frame Transactions（frame-транзакции）.

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

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

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

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

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

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

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

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

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

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

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

II. Как работает EIP-8141?

По сути, EIP-8141 вводит совершенно новый тип транзакции — Frame Transaction (frame-транзакцию); идентификатор типа транзакции — 0x06.

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

У каждого «фрейма» есть три режима выполнения:

VERIFY（верификационный frame）: отвечает за проверку корректности транзакции; он запускает верификационную логику, заданную самим аккаунтом. Если она проходит, то вызывается новый введённый operation code APPROVE, который авторизует выполнение и задаёт лимит Gas.

SENDER（отправляющий frame）: выполняет реальное действие, например перевод, вызов контракта и т.п. Адрес вызывающего — это сам отправитель транзакции.

DEFAULT（входной frame）: в качестве вызывающего используется системный входной адрес; применяется для сценариев вроде деплоя контрактов, верификации Paymaster и т. п.;

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

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

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

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

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

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

Абстрагирование оплаты Gas: наличие стейблкоинов в кошельке больше не означает, что вам обязательно нужно отдельно держать немного ETH для выполнения действий; в будущем оплата Gas более естественно будет делаться DApp, Paymaster или другими спонсорами;

Слияние многошаговых операций: такие процессы, как «authorize + swap» или «authorize + staking», которые сейчас часто требуют нескольких подписей, получают шанс быть упакованными в одну более цельную операцию;

Открытие правил безопасности аккаунта: мультиподписи, социальное восстановление, ежедневные лимиты, timelock, ротация ключей — всё это перестаёт быть лишь «продвинутой» функцией, которую дополнительно предоставляет конкретный кошелёк, и начинает получать возможность строиться на более нативной логике аккаунта;

Схемы подписи больше не обязаны быть «заперты» одним единственным путём ECDSA: это впервые создаёт на уровне протокола возможность для того, чтобы аккаунт в будущем мигрировал в разные криптографические схемы, включая схемы после-квантовых подписей;

III. Почему это не стало главным козырем Hegotá?

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

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

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

Иначе говоря, основные разработчики не то чтобы не признают направление EIP-8141: они одновременно признают его ценность, но считают, что сейчас он всё ещё слишком «тяжёлый».

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

Что будет дальше? Это можно разделить на две линии:

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

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

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

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

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

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

Ethereum не ждал, пока проблемы начнут созревать на месте: он прокладывает путь для следующего поколения системы аккаунтов шаг за шагом, без остановки.