Что такое EIP-8361? Разъяснение Ethereum Validity Proofs

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

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

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

• EIP-8361 стандартизирует данные доказательств валидности транзакций для p2p-распространения. Frame-транзакция может содержать STARK, подтверждающий, что её валидационный префикс достигает утверждённого состояния.

• Узлы проверяют доказательство вместо повторного исполнения ресурсоёмкой логики авторизации. Такое разделение процессов доказательства и верификации может снизить повторные вычисления на всех узлах Ethereum.

• Доказательство не участвует в консенсусе. Оно транспортируется с транзакцией, используется для допуска в mempool и удаляется, когда становится неактуальным.

• Дизайн поддерживает сложную валидацию смарт-аккаунтов. Примеры: мультиподписи, альтернативные системы подписей, paymaster’ы, авторизация на основе доказательств.

• EIP-8361 — это черновик. Это не активированное обновление. Не путайте его с EIP-7701, EIP-7702, доказательствами валидности роллапов или предложениями по вознаграждению за стейкинг.

Что такое EIP-8361?

EIP-8361, озаглавленный Transaction Validity Proofs, предлагает сетевой механизм, с помощью которого транзакция Ethereum может поступать с криптографическим доказательством, что её логика валидации разрешает выполнение. Черновик дополняет изменения на уровне протокола, предложенные в EIP-8141, где определяются frame-транзакции и программируемые стадии валидации.

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

В предложении рассматривается вопрос:

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

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

Сама транзакция при включении в блок должна быть валидна по правилам исполнения Ethereum. Доказательство поддерживает политику допуска, но не заменяет протокольное исполнение или валидацию консенсуса.

Почему сложная валидация транзакций Ethereum затруднена

Обычный внешний аккаунт (EOA) управляется приватным ключом и соответствующим открытым ключом. Такой аккаунт авторизует транзакцию подписью ECDSA, а сама транзакция содержит поля: nonce отправителя, адрес назначения, величину, chain ID, лимит газа и цену газа или параметры комиссии EIP-1559.

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

Смарт-аккаунты расширяют поверхность для проверки. Вместо единственного приватного ключа смарт-аккаунт может использовать:

• несколько открытых ключей;

• лимиты на траты;

• сессионные ключи;

• делегированные контракты;

• правила paymaster’а;

• постквантовые подписи;

• условия восстановления;

• доказательства с нулевым разглашением;

• прикладной код авторизации.

Такая логика может находиться в уже развёрнутом смарт-контракте или в новом контракте, созданном при развертывании аккаунта. Создание и развёртывание контракта могут потребовать проверки фабрики, кода инициализации или адреса будущего контракта.

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

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

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

EIP-8361 предлагает два способа допуска транзакций формата EIP-8141:

1. Симулированный допуск: узел исполняет валидационный префикс напрямую.

2. Допуск на основе доказательства: узел проверяет STARK, подтверждающий разрешение валидационного префикса.

Второй способ предназначен для случаев, когда обычный вызов кода валидации превышает допустимый лимит проверки на узле.

1. Транзакция определяет свою логику валидации

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

Валидационный префикс может вызывать смарт-контракт отправителя или другой делегированный контракт. Такой контракт проверяет подписи, права, балансы, сроки действия или другие условия до вызова операции APPROVE.

EIP-8141 отличается от обычной транзакции, где одна подпись ECDSA, признанная протоколом, определяет отправителя. Его программируемая модель валидации — часть движения Ethereum к нативной абстракции аккаунтов. EIP-8141 не опирается на список авторизации EIP-7702, так как frame-транзакции нацелены на большую криптографическую гибкость.

2. Прувер исполняет валидационный префикс

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

• подпись соответствует нужному открытому ключу;

• у аккаунта-отправителя достаточно средств;

• баланс paymaster’а выше требуемого значения;

• в слоте хранилища контракта содержится нужное разрешение;

• chain ID совпадает с целевой сетью Ethereum;

• nonce предотвращает повторные атаки;

• код валидации завершился разрешением.

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

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

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

Условие равенства может означать, что хэш кода контракта, nonce или значение в хранилище должны точно совпадать с объявленным. Условие «больше или равно» — что баланс аккаунта не ниже минимума.

Эти предположения связывают доказательство с предыдущим валидным состоянием без необходимости встраивать в него полный state Ethereum. При изменении данных новым блоком узел может повторно проверить вектор предположений.

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

4. Узлы проверяют STARK

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

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

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

5. Транзакция попадает в mempool

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

Доказательство остаётся p2p-метаданными. Оно не добавляется в calldata транзакции, не сохраняется в смарт-контракте, не записывается в состояние аккаунта и не включается в Merkle root блока.

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

Что доказывает proof по EIP-8361?

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

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

Это различие важно:

• EIP-8361 доказывает валидацию для допуска.

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

• Доказательство Merkle подтверждает включение в аутентифицированную структуру данных.

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

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

EIP-8361 использует STARK как эффективное доказательство корректности, но цель черновика — не конфиденциальное исполнение. Транзакция и её зависимости могут оставаться видимыми для участвующих узлов.

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

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

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

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

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

Доказательства валидности EIP-8361 и fraud proofs

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

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

Однако утверждать, что доказательства валидности всегда «безопаснее», чем fraud proofs — слишком обобщённо. Ключевые различия — в сложности прувера, безопасности верификатора, доступности данных, необходимости доверенного запуска, предположениях challenge и зрелости реализации.

EIP-8361 не является моделью безопасности роллапа. Его доказательство проверяется до допуска в mempool, тогда как fraud proofs и validity proofs защищают системы масштабирования вне сети.

EIP-8361 и делегирование аккаунта по EIP-7702

EIP-7702 позволяет существующим EOA установить индикатор делегирования в поле кода, чтобы вызовы аккаунта исполнялись через указанный смарт-контракт. Введён тип-4 транзакция с authorization_list.

Каждая запись авторизации содержит:

• chain_id;

• адрес делегированного контракта;

• nonce аккаунта;

• поля подписи.

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

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

EIP-7702 создаёт и дополнительные вопросы безопасности. Chain ID, равный нулю, может сделать авторизацию валидной во всех сетях, а nonce и подписанные поля помогают ограничить повторные атаки. Делегированный код влияет на предположения, связанные с tx.origin, неподтверждёнными транзакциями, хранилищем и балансами.

EIP-8361 не заменяет и не расширяет authorization_list. Он решает вопрос допуска транзакций со сложной логикой валидации. Ключевые отличия между доказательствами валидности EIP-8361 и симуляцией транзакций связаны с вычислениями в mempool, а не с делегированием кода EOA.

EIP-8361 и нативная абстракция аккаунтов по EIP-7701

EIP-7701 был создан 1 мая 2024 года как предложение по нативной абстракции аккаунтов. Он делил обработку транзакций на стадии валидации, исполнения и постопераций и вводил новый тип транзакции EIP-2718.

Дизайн использовал нативный адрес точки входа 0x7701, ролевые опкоды, раздельную валидацию отправителя и paymaster’а, а также оплату газа, контролируемую контрактом. Для нативного типа транзакций не требовался отдельный flow ERC-4337 bundler.

EIP-7701 был отозван, так как его заменил EIP-8141 — не просто помечен как «Stagnant». Причина отзыва указана в опубликованной спецификации. Утверждение, что EIP-7701 требует контракты в формате EOF, также не входит в финальную версию.

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

EIP-2718 определяет типизированный конверт транзакции, используемый в EIP-7701, EIP-7702 и EIP-8141. Транзакция определяется как TransactionType || TransactionPayload, где тип указывает, как интерпретировать payload. Включение типа в подписываемые данные также снижает риск повторного использования подписи между типами.

Практическое влияние на кошельки, узлы и разработчиков

Разработчики кошельков могут использовать допуск на основе доказательств, если авторизация смарт-аккаунта слишком затратна для обычной симуляции в mempool. Кошелёк может запросить доказательство у локального прувера, сервиса или распределённой сети до отправки транзакции.

Разработчикам узлов потребуется реализовать:

• транспорт доказательств по p2p;

• версионированные ключи проверки;

• лимиты размера доказательств;

• проверки предположений и зависимостей;

• лимиты по количеству на пира;

• удаление устаревших доказательств;

• fallback-симуляцию.

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

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

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

Вопросы безопасности и ограничения

EIP-8361 вводит ряд вопросов безопасности.

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

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

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

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

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

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

Что не предлагает EIP-8361

Некоторые утверждения относятся к другим предложениям и не должны приписываться EIP-8361.

EIP-8361 не:

• определяет 18-месячный переходный период;

• отменяет минимальную доходность по стейкингу;

• ограничивает вознаграждение валидаторов;

• уменьшает вознаграждение при достижении 50% стейкинга;

• создаёт рыночное равновесие стейкинга;

• вводит authorization list из EIP-7702;

• вводит нативную точку входа из EIP-7701;

• создаёт новый тип транзакции EIP-2718;

• гарантирует приватность;

• осуществляет расчёт ZK-роллапов;

• заменяет fraud proofs;

• отменяет договорные или иные права пользователей.

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

Заключение

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

Главный сценарий применения — программируемая авторизация, превышающая лимиты обычной валидации mempool, включая продвинутые смарт-аккаунты, альтернативные системы подписей, paymaster’ы и контракты с доказательствами. Дизайн может сократить избыточные вычисления узлов, сохраняя прозрачность и возможность проверки предположений о состоянии.

EIP-8361 не следует путать с расчётом ZK-роллапов, fraud-proof-оспариваниями, делегированием аккаунтов по EIP-7702 или отозванным дизайном EIP-7701. Это черновик сетевого предложения, безопасность, экономика доказательств, совместимость и зависимости которого требуют дальнейшей доработки до возможного внедрения в Ethereum.

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

Создаёт ли EIP-8361 новый тип транзакций?

Нет. Он применяет допуск на основе доказательства к транзакциям формата EIP-8141. Общий фреймворк типизированных транзакций задаёт EIP-2718, но EIP-8361 не вводит новый конверт транзакции.

Являются ли доказательства EIP-8361 доказательствами с нулевым разглашением?

В черновике предлагаются доказательства валидности на основе STARK, но валидность не всегда означает приватность. Доказательство подтверждает корректную валидацию при объявленных предположениях, а не скрывает все данные транзакции.

Может ли одно доказательство покрывать несколько транзакций?

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

Снижает ли EIP-8361 комиссии за газ?

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

Чем EIP-8361 отличается от EIP-7702?

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

Дисклеймер

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