Как функционируют доказательства действительности транзакций согласно EIP-8361?

EIP-8361 дает возможность транзакциям с рамкой EIP-8141 отправлять лаконичный STARK вместе с p2p-платежной нагрузкой, позволяя узлам подтвердить, что префикс валидации одобрил транзакцию при заявленных предположениях о состоянии. Узлы вместо повторного выполнения одного механизма проверяют одно доказательство, его зависимости и соответствующие условия состояния, что может снизить стоимость проверки для сложной логики аккаунтов. В следующих разделах показано, как корректные транзакции получают доказательства, как узлы выявляют устаревшие или мошеннические транзакции, почему доказательство ссылается на предыдущее корректное состояние, не превращаясь в Merkle-корень, и почему оно исчезает после включения в блок.

В объяснении также проводится различие между EIP-8361 и двумя основными типами безопасности роллапов: ZK-доказательства, которые подтверждают корректность до принятия, и fraud proofs, которые требуют процедуры оспаривания для демонстрации некорректного перехода состояния. Кроме того, разъясняются ограничения, связанные с подписями ECDSA, квантовой безопасностью, потенциальными рисками квантовых компьютеров и более узкой ролью предложения по сравнению с решениями масштабирования. Этот технический разбор предназначен для команд кошельков, разработчиков клиентов, операторов пруверов и пользователей, оценивающих, как транзакции с доказательствами могут расширить возможности валидации Ethereum, пока EIP-8361 остается черновым сетевым предложением, а не действующим правилом консенсуса.

Основные выводы

• EIP-8361 позволяет транзакциям с рамкой EIP-8141 содержать доказательство допуска как офчейн метаданные транспортировки.

• Офчейн прувер выполняет префикс валидации при заявленных предположениях и создает STARK, связанный с транзакцией, плательщиком, зависимостями и условиями корректности.

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

• Корректное доказательство разрешает допуск в мемпул без повторного полного моделирования префикса валидации.

• Доказательство не определяет корректность блока, не изменяет исполнение и не становится частью постоянного состояния Ethereum. Оно удаляется после включения или удаления из мемпула.

Что такое доказательства корректности транзакций EIP-8361?

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

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

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

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

Более широкий фреймворк EIP-8361 касается допуска в мемпул с доказательством, а процесс валидации мемпула EIP-8361 определяет, как принимающие узлы решают, принять, удержать, поставить на паузу или удалить такие транзакции.

На 6 августа 2026 года EIP-8361 представлен в черновом pull request #12075 как предложение по сетевому стандарту. Оно не вводит новый тип транзакций и не изменяет консенсус Ethereum само по себе.

Как работает криптографическое доказательство EIP-8361?

Доказательство охватывает конкретное утверждение, а не заявляет, что известен каждый будущий результат исполнения.

В упрощенной форме прувер должен доказать:

Префикс валидации транзакции T, при оценке с заявленными предположениями и зависимостями, следует правилам трассировки EIP-8141 и завершается APPROVE и плательщиком P при указанных условиях.

Предлагаемые публичные входные данные связывают доказательство с пятью элементами:

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

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

EIP-8361 предлагает использовать формат доказательства и механизм проверки входа, связанные с EIP-8288. В стандарте упоминаются STARK, поскольку они позволяют представить большую вычислительную задачу в сравнительно компактном доказательстве и не требуют от каждого верификатора воспроизведения исходной нагрузки.

Как используется вектор предположений при валидации транзакций?

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

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

Определены два типа сравнения:

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

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

Точное EQ-предположение подходит для хэша кода, nonce или ветки хранилища, значение которых меняется при изменении базового значения. GEQ-предположение полезно для монотонных требований, например проверки, что у плательщика достаточно средств для предварительного депозита.

Например, если префикс валидации смарт-аккаунта разрешает транзакцию только при балансе paymaster не менее 0,2 ETH, прувер может записать GEQ-предположение с порогом 0,2 ETH. Узел может считать доказательство действительным, пока баланс равен или превышает 0,2 ETH. Новое доказательство не требуется при увеличении баланса выше порога.

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

Как работают доказательства корректности транзакций по EIP-8361?

Процесс валидации транзакций проходит серию последовательных проверок.

1. Выполнить проверки без состояния. Узел проверяет внутреннюю корректность транзакции и подтверждает, что список зависимостей или подписей сформирован правильно. Некорректная транзакция отклоняется до дорогостоящей проверки доказательства.

2. Проверить доказательство допуска. Узел проверяет STARK по указанному ключу верификации. Если проверка неудачна, заявленное вычисление валидации не подтверждено.

3. Проверить внешние зависимости. Доказательство может предполагать, что подписи или другие заявленные зависимости валидны. Узел отдельно проверяет эти зависимости и сверяет их список с коммитментом хэша зависимостей.

4. Проверить условия корректности. Узел оценивает заявленные условия, которые могут включать дедлайны, окна слота или эпохи, диапазоны истечения или требования к nonce.

5. Сравнить предположения с текущим состоянием. Каждый EQ-элемент проверяется на равенство, каждый GEQ-элемент — на соответствие порогу.

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

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

Что происходит при изменении состояния Ethereum?

Допуск в мемпул не гарантирует постоянство, так как состояние Ethereum меняется после попадания транзакции в пул.

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

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

Неудача по GEQ-условию может обрабатываться иначе. Узел может поставить транзакцию на паузу вместо полного удаления. Если позже плательщик или paymaster получает достаточно средств, узел может реактивировать транзакцию, проверив порог заново.

Такое различие делает вектор предположений не просто Merkle-коммитментом к историческому состоянию, а определяет, какие изменения состояния действительно аннулируют разрешение, а какие остаются совместимыми.

Почему доказательство удаляется после включения в блок?

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

Когда валидатор включает транзакцию в блок, Ethereum обрабатывает ее через обычное исполнение протокола. EVM выполняет префикс валидации и оставшиеся фреймы по каноническому состоянию блока. Клиенты консенсуса определяют корректность блока по стандартным правилам Ethereum.

В результате доказательство допуска:

• не помещается в блок;

• не добавляется в calldata транзакции;

• не появляется в квитанции;

• не становится частью Merkle-дерева или корня состояния;

• не создает постоянное ончейн изменение состояния;

• не требуется хранить после включения или удаления транзакции.

Его удаление предотвращает постоянные расходы на calldata и рост состояния для информации, уже выполнившей свою сетевую функцию. Сама транзакция остается ончейн, но ее временный конверт доказательства — нет.

Система доказательств EIP-8361 против доказательств корректности ZK-роллапов

EIP-8361 использует криптографические доказательства, но доказательство допуска не следует путать с доказательствами корректности, применяемыми в ZK-роллапах.

ZK-роллапы обычно применяют ZK-SNARK или ZK-STARK для подтверждения корректности батчей транзакций. После принятия доказательства контрактом Layer 1 роллап может финализировать переход состояния без ожидания периода оспаривания fraud proof, используемого в оптимистических роллапах.

EIP-8361 не доказывает L2-батч, не разрешает немедленные выводы роллапов и не гарантирует, что L2-цепочка никогда не станет некорректной. Его доказательство — временный сетевой артефакт предварительной проверки допуска.

Аналогично, хотя zero-knowledge proofs могут подтвердить утверждение без раскрытия всех данных свидетеля, EIP-8361 не является в первую очередь предложением по приватности. «Лаконичное доказательство» и «zero knowledge» — смежные, но не идентичные свойства.

Вывод средств с Layer 2 на Layer 1 может быть быстрее с доказательствами корректности, так как ZK-роллапы не требуют периода оспаривания fraud proof, используемого в оптимистических роллапах. Время финального вывода зависит от генерации доказательства, проверки Layer 1, правил мостов и финальности Ethereum. EIP-8361 не предоставляет этот механизм вывода; его доказательство поддерживает допуск в мемпул отдельной транзакции с рамкой EIP-8141, а не расчет батча Layer 2.

Как работают fraud proofs в оптимистических роллапах?

Fraud proofs используют другой механизм безопасности. Оптимистический роллап изначально принимает предложенный переход состояния и позволяет оспаривать его во время периода спора. В зависимости от реализации разрешение спора может требовать нескольких раундов или суженного доказательства исполнения.

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

Ключевое различие — во времени и области:

• Доказательство корректности подтверждает заявленное утверждение до принятия.

• Fraud proof допускает оптимистичное утверждение, пока оно не оспорено.

• Доказательство допуска EIP-8361 касается политики мемпула.

• Fraud proof роллапов касается корректности перехода состояния L2.

Технические компромиссы между повторным исполнением EVM и лаконичной проверкой рассмотрены в EIP-8361 против моделирования транзакций, включая случаи, когда стоимость генерации доказательства заменяет затраты на моделирование на узле.

EIP-8361, сложная валидация аккаунтов и постквантовая безопасность

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

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

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

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

Например, трейдер, оценивающий влияние развития абстракции аккаунтов Ethereum на рыночное настроение, может сравнить этапы предложений с графиком рынка ETH/USDT, хотя динамика цены не подтверждает внедрение или принятие чернового EIP.

Риски и ограничения

EIP-8361 остается ранним черновиком, поэтому формат доказательства, ограничения, зависимости, терминология и детали реализации могут измениться до стандартизации.

Механизм также вводит несколько технических рисков:

Концентрация генерации доказательств: Создание STARK может требовать специализированного ПО и значительных вычислений. Если только немногие сервисы могут эффективно генерировать доказательства, кошельки могут зависеть от централизованной инфраструктуры пруверов.

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

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

Устаревание состояния: Доказательство может оставаться криптографически корректным, если заявленные условия больше не соответствуют текущему состоянию. Узлы должны продолжать проверять A и C, пока транзакция находится в пуле.

Нет гарантии исполнения: Допуск в мемпул не гарантирует включение в блок или успешное финальное исполнение. Другая транзакция может изменить nonce отправителя, баланс, код, хранилище или другое релевантное состояние до включения.

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

Является ли EIP-8361 также предложением Tapered Issuance Burn?

В ранних обсуждениях номер EIP-8361 связывали с отдельным предложением по монетарной политике Ethereum — Tapered Issuance Burn. Позже это предложение было обозначено как EIP-8363, а EIP-8361 относится к доказательствам корректности транзакций в сетевой категории. Предложения не связаны: EIP-8361 касается допуска в мемпул на основе доказательств, а Tapered Issuance Burn меняет экономику наград консенсусного слоя в зависимости от активного баланса стейкинга.

Заключение

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

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

Часто задаваемые вопросы

Как ZK-роллапы используют доказательства корректности?

ZK-роллапы обрабатывают транзакции офчейн, группируют их в батчи и вычисляют доказательство корректности для каждого батча. Доказательство, обычно построенное с помощью ZK-SNARK, ZK-STARK или полиномиальных коммитментов, позволяет контракту Ethereum подтвердить, что переход состояния корректен, не воспроизводя каждую транзакцию.

Гарантируют ли доказательства корректности невозможность некорректного состояния L2?

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

Почему выводы из ZK-роллапов обычно быстрее?

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

Чем доказательства корректности отличаются от fraud proofs?

Доказательства корректности подтверждают корректность транзакции до принятия перехода состояния. Fraud proofs работают по оптимистичной модели, в которой переход может быть временно принят и оспорен позже; многие оптимистические роллапы используют период оспаривания около семи дней, хотя точная длительность различается.

Всегда ли zero-knowledge proofs скрывают данные транзакции?

Нет. Zero-knowledge proofs могут подтвердить утверждение без раскрытия приватного свидетеля, но приватность зависит от того, какие входные данные скрываются. Многие ZK-роллапы используют ZK-доказательства в основном для масштабируемой проверки транзакций, а не для полностью приватных транзакций.

В чем разница между ZK-SNARK и ZK-STARK?

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

Что подтверждает Merkle-доказательство?

Merkle-доказательство подтверждает принадлежность конкретных данных к набору, представленному Merkle-корнем, без раскрытия или загрузки полного набора данных. Оно доказывает включение или исключение, а не корректность всего батча транзакций или перехода состояния.

Снижают ли доказательства корректности расход ресурсов ончейн?

Да, они могут сжать большую офчейн вычислительную задачу в одно доказательство, которое дешевле проверить ончейн, чем воспроизводить каждую транзакцию. Фактическая экономия зависит от стоимости проверки доказательства, размера батча, использования calldata или blob и реализации роллапа.

Снижают ли доказательства корректности риск атаки 51%?

Не напрямую. Доказательства корректности защищают корректность проверенных переходов состояния Layer 2, а атака 51% касается контроля над консенсусом Ethereum и выбором форка. Механизмы решают разные задачи безопасности.

Являются ли доказательства EIP-8361 тем же, что и доказательства ZK-роллапов?

Нет. Доказательства ZK-роллапов проверяют батчи транзакций Layer 2 и поддерживают финальность состояния и выводы. Доказательства EIP-8361 поддерживают допуск в мемпул отдельных транзакций с рамкой EIP-8141, остаются вне блока и удаляются после включения или удаления.

Дисклеймер

Этот материал носит образовательный характер и описывает черновое предложение Ethereum, спецификация и статус реализации которого могут измениться. Он не содержит финансовых, технических или рекомендаций по развертыванию ПО. Разработчикам следует сверять актуальный текст EIP и требования клиентов перед созданием продуктивных систем.