Часть III · Глава 12 из 43 · Byzantium

EIP-196/197: доказательства с нулевым разглашением on-chain

Верификация zk-SNARK означает вычисления спаривания на эллиптических кривых — тысячи операций над полем, которые, будучи записаны как EVM-байткод, стоили бы больше газа, чем вмещает целый блок. EIP-196 и 197 добавляют эту математику как нативные прекомпайлы, так что контракт может проверить доказательство за несколько дешёвых вызовов. Это тихий фундамент приватности on-chain и каждого validity-роллапа.

Обновлено 24 июн. 2026 г. · 10 мин
Предполагается
  • контракты и EVM
  • прекомпайлы (идея)

Byzantium, октябрь 2017. Глава про REVERT — это изменение того форка, которое вы ощущаете каждый день; а это изменение переформатировало будущее Ethereum. Звучит узко — арифметика на эллиптической кривой на пару опкодов, — но именно оно впервые сделало верификацию доказательства с нулевым разглашением on-chain доступной по цене, и из этой единственной возможности выросли приватные транзакции и каждый validity- (zk-) роллап. Проблема, которую оно решает, — жестокая стена стоимости, а инструмент, которым оно пользуется, — прекомпайл — один из важнейших люков аварийного выхода Ethereum. Давайте выведем его.

1 шаг Математика слишком дорога

Проблема: спаривания не помещаются в блок

zk-SNARK Доказательство с нулевым разглашением того, что утверждение истинно (например, «эта пачка транзакций валидна»), которое крошечное и быстро проверяется, не раскрывая ничего сверх этого. Для его верификации нужны операции на эллиптической кривой — в частности, проверка спаривания. прекрасен тем, что его проверка мала и быстра, — но «быстро» тут относительно операции, которая для этого нужна: спаривания на эллиптической кривой, плюс сложений на кривой и скалярных умножений. Это тяжёлые вычисления теории чисел над большими полями. Записанная как обычный EVM-байткод — цикл по арифметике над полем опкод за опкодом, — одна-единственная верификация обошлась бы в сотни миллионов газа, намного больше лимита газа целого блока. Верификация доказательства on-chain просто не помещается.

проверка zk-доказательства требует спариваний на эллиптических кривых zk-доказательство валидно? — проверьте pairing в байткоде тысячи операций лимит газа блока сотни миллионов газа — верификация on-chain нереальна
Верификация zk-доказательства требует спариваний на эллиптической кривой — тысяч операций над полем. Реализованная как EVM-байткод, одна верификация стоит сотни миллионов газа, далеко превышая лимит газа всего блока. Так что проверка доказательства on-chain — нежизнеспособная затея.

→ Шаг 2: пусть протокол выполнит сложную часть.

2 шаг Реализуем нативно

Прекомпайлы: нативная криптография по зарезервированным адресам

Люк аварийного выхода — это precompile Встроенная операция, доступная по зарезервированному низкому адресу (0x01, 0x02, …). Она вызывается точно как контракт, но вместо выполнения EVM-байткода клиент запускает оптимизированную нативную реализацию, оцениваемую фиксированной стоимостью газа, отражающей её реальную работу. (прекомпайл). Вместо того чтобы проталкивать спаривание через EVM, протокол предоставляет оптимизированную нативную (C/Go) реализацию по зарезервированному адресу, вызываемую как любой контракт. EIP-196 добавляет сложение и скалярное умножение на alt_bn128 curve Эллиптическая кривая (также называемая BN254), операции которой Byzantium сделал доступными: ecAdd по адресу 0x06, ecMul по адресу 0x07 и проверка ecPairing по адресу 0x08. Выбрана потому, что эффективные системы SNARK ориентированы на неё. (ecAdd по 0x06, ecMul по 0x07), а EIP-197 добавляет решающую проверку спаривания (ecPairing по 0x08). Каждая операция тарифицируется фиксированной, скромной стоимостью газа, соответствующей тому, что операция реально стоит узлу, — а не тому, во что она обошлась бы как байткод.

дать EVM нативную математику по зарезервированным адресам контракт-верификатор CALL 0x08 вызов CALL прекомпайл · 0x08 alt_bn128 pairing нативный C/Go · фикс. дешёвый газ 0x06 · ecAdd0x07 · ecMul0x08 · ecPairing сложная крипто — нативно в протоколе, по реальной цене теперь контракт проверяет SNARK за пару дешёвых вызовов
Контракт-верификатор делает CALL к прекомпайлу (например, 0x08 для спаривания alt_bn128) точно так же, как вызов контракта, но клиент выполняет быструю нативную реализацию и списывает фиксированную низкую стоимость газа. EIP-196 добавляет ecAdd/ecMul (0x06/0x07); EIP-197 добавляет проверку ecPairing (0x08).

→ Шаг 3: проверять что угодно, не раскрывая ничего.

3 шаг Доказательства on-chain

Выигрыш: приватность и validity-роллапы

Раз проверка спаривания стала доступной по цене, контракт может проверить SNARK за горстку вызовов — а SNARK способен удостоверить почти что угодно, не раскрывая ничего сверх «это правда». Отсюда напрямую выросли два огромных применения. Приватность: контракт-миксер может принять доказательство «я владею депозитом в этом множестве и не выводил его», не раскрывая, каким именно депозитом, — это позволяет делать приватные переводы (схема, лежащая в основе Tornado Cash и решений в духе Zcash). И масштабирование: validity rollup Layer-2, который выполняет транзакции офчейн и публикует в L1 одно сжатое доказательство того, что вся пачка была валидна. Контракт в L1 проверяет это доказательство — дёшево, благодаря прекомпайлу спаривания, — вместо повторного выполнения каждой транзакции. (zk-роллап) может доказать, что вся пачка из тысяч L2-транзакций была выполнена корректно, а контракт в L1 проверяет это одно доказательство вместо повторного прогона пачки.

проверка доказательств on-chain — уже достаточно дёшева проверка SNARK приватные транзакции доказать валидность, скрыть детали validity-роллапы (zk) одно доказательство = целый батч прекомпайл спаривания дал ончейн-приватность и zk-роллапы
Как только контракт может дёшево проверить SNARK, он может принять доказательство того, что нечто истинно, не узнав ничего сверх этого, — это движет приватными транзакциями (доказать валидность, скрыть детали) и validity-роллапами (одно доказательство заменяет целую пачку L2-транзакций).
04 Глубже Куда двигаться дальше