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

На самом деле всё сложнее. Это не было чистым везением, но и не было моментом в стиле “AI решил безопасность”. Баг нашли потому, что в одной точке совпали новая модель, структурированный audit framework, правильно выбранная цель и человеческая проверка.

Это не был случайный prompt в чатбот

Согласно disclosure-документу, Taylor Hornby использовал собственный audit setup под названием zcash-full-stack-auditor вместе с новой моделью Anthropic Opus 4.8. Цель была не случайной. Аудит был сфокусирован на halo2 implementation и включал Orchard circuit, одну из самых чувствительных частей shielded-транзакций Zcash.

Процесс начинался с initialization phase. Framework собирал релевантные участки кода, statements из протокольной спецификации, security properties и failure modes. После этого audit phase распределял задачи между специализированными агентами.

Эта деталь важна. AI не просто блуждал по codebase и угадывал. Его использовали внутри структурированного security workflow, где у модели был контекст и список конкретных вещей для проверки.

Сама уязвимость была missing-constraint issue в variable-base scalar multiplication gadget, который используется в Orchard. Если упростить, circuit должен был доказывать, что spender использует правильный internal viewing key для note, которую он тратит. Эта связь важна, потому что она соединяет note с правильным nullifier. Если проверку можно обойти, одну и ту же note можно потратить несколько раз с разными nullifiers.

В прозрачной системе double-spend обычно оставляет видимый след. В shielded-системе privacy делает такую ошибку гораздо сложнее для обнаружения. В disclosure говорится, что exploit мог позволить незаметную инфляцию внутри Orchard pool, ограниченную turnstile accounting Zcash, но всё равно достаточно серьёзную для emergency response.

Где действительно было везение

Элемент везения всё же был. Opus 4.8 вышла буквально перед аудитом. Предыдущие automated audits с тем же agent framework, но на Opus 4.7, этот баг не нашли. Позже Hornby проверил, что Opus 4.7 могла найти проблему только если очень конкретно направить её на vulnerable area.

Даже Opus 4.8 не находила issue стабильно при любом широком prompt. Это значит, что upgrade модели сыграл роль, но результат не был гарантирован. Тот же код, похожий инструмент и немного другая постановка задачи могли снова пропустить баг.

Но “везение” не равно “случайность”. Аудит уже был направлен на правильный класс проблем: inflation и double-spend risk внутри zero-knowledge circuit. Framework уже разбил протокол на проверяемые утверждения. Модель подняла suspicious constraint gap потому, что workflow дал ей конкретный объект для проверки.

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

AI нашёл зацепку, человек превратил её в уязвимость

Самая важная часть истории началась после того, как модель указала на проблему. В disclosure говорится, что AI agent сам был скептичен к своей находке и сначала склонялся к мысли, что audited upstream code, скорее всего, корректен.

После этого Hornby использовал Claude, чтобы построить proof of concept сначала против похожего circuit, а затем против реального Orchard circuit. Позже, с помощью AI, он помог разработать полноценный RPC test в regtest. Этот тест показал, что value of an Orchard note можно удваивать до тех пор, пока локальный баланс кошелька не превысит 10 млн ZEC.

Именно здесь история становится не про “AI заменил аудиторов”, а про то, что AI резко сжал research loop. Модель помогла найти suspicious missing constraint, разобрать алгебру и написать proof-of-concept code. Но человеческая часть осталась критически важной: заметить finding, решить, что он заслуживает проверки, протестировать его, приватно сообщить команде, координироваться с Zcash engineers и смотреть fixes.

Реакция была быстрой. Проблему сообщили поздно 29 мая, Zcash Open Development Lab подтвердил получение 30 мая, emergency soft fork mitigation активировали 1 июня, а Orchard снова включили через NU6.2 на block 3,364,600 3 июня. Zcash Foundation описала Zebra 4.5.3 и 5.0.0 как двухэтапный response: сначала отключить Orchard actions, затем включить Orchard с исправленным circuit.

Неприятная часть в том, что баг существовал с активации Orchard в мае 2022 года. Orchard уже проходил серьёзные аудиты, и это говорит не о том, что аудиторы “не справились”, а о сложности класса ошибок. Missing constraints в zero-knowledge circuits особенно коварны: код может выглядеть рабочим, но не доказывать ровно то утверждение, которое нужно протоколу.

Так нашли ли Orchard bug благодаря везению? Частично. Было ли это случайностью? Нет.

Более точный ответ: это была подготовленная удача. Новая модель сделала баг более discoverable, но audit framework создал путь поиска, а human verification превратила model finding в подтверждённую уязвимость.

Для crypto security это важное различие. Вывод не в том, что AI теперь найдёт все баги. Вывод в том, что серьёзным протоколам, возможно, придётся запускать targeted AI-assisted soundness и balance-integrity audits после выхода новых frontier models. Не потому, что модель всегда права, а потому что один удачный run внутри правильного workflow может найти flaw, который годами прятался за общей уверенностью.