Разработчики Ethereum выдвинули предложение, которое даст ончейн-коду возможность проверять, что транзакция фактически изменила, — и отменять всю транзакцию, если результат нарушает правила, заранее заданные пользователем. Концепция, известная как нативные ассерты транзакций, была представлена Ethereum Foundation в блоге, опубликованном 5 октября 2026 года.

Предложение нацелено на одну из старейших и самых стойких уязвимостей в безопасности криптовалют: слепое подписание.

Проблема слепого подписания

Слепое подписание — это криптоаналог согласия с условиями использования, которые вы не читали. Кошелёк показывает запрос, детали нечитаемы или непонятны, и пользователь всё равно подтверждает. Чаще всего ничего плохого не происходит, но когда происходит — это, как правило, дорого обходится. Уязвимость коренится в том, как устроены транзакции Ethereum: подписываемые данные представлены в машиночитаемом формате, а не на естественном языке, поэтому на экране кошелька отображается лишь интерпретация этих данных конкретным интерфейсом.

Ethereum Foundation представила новую работу как прямой ответ на эти риски, отмеченные в рамках инициативы Trillion Dollar Security. Эта программа уже включает меры вроде Clear Signing, которые направлены на то, чтобы сделать запросы транзакций читаемыми до их подтверждения пользователем.

Нативные ассерты транзакций работают на другом этапе процесса. Clear Signing помогает пользователю понять транзакцию до её выполнения. Ассерты проверяют, соответствовал ли результат ожиданиям после выполнения.

Внутри EIP-7906

Техническое ядро предложения — EIP-7906, который вводит три новых опкода в Ethereum Virtual Machine: TXTRACE, TXDIFF и EVENTDATACOPY. Опкоды — это низкоуровневые инструкции, которые понимает EVM, поэтому добавление новых расширяет возможности смарт-контрактного кода.

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

Как это встраивается в EIP-8141

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

Frame-транзакции разбивают одну транзакцию на отдельные сегменты — фреймы. EIP-7906 добавляет в эту структуру новый элемент: фрейм POST_TX.

Фрейм POST_TX работает как static call во время выполнения. Static call — это операция только для чтения: он может изучать состояние, но не может его изменять. Если условия, определённые во фрейме, не выполнены, эффекты транзакции могут быть полностью отменены (revert).

##атус и сроки

Ничего из описанного пока не запущено. EIP-7906 остаётся в статусе черновика. Согласно процессу разработки Ethereum, черновик должен пройти ревью и получить одобрение разработчиков, координирующих обновление, прежде чем его изменения попадут в сеть. Цель — включить его в обновление Hegotá, развертывание которого ожидается в 2027 году.

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

Почему это важно за пределами кода

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

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

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

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

Ключевые ориентиры: выйдет ли EIP-7906 из статуса черновика, получит ли EIP-8141 место в Hegotá и последуют ли за ранними демонстрациями новые тесты на devnet.