Слой нулевых знаний Kaspa сделал конкретный шаг вперёд в начале августа. PR #1067, открытый и слитый Ори Ньюманом, добавил фрагмент верификатора Groth16 с динамическим идентификатором образа в rusty-kaspa. Мерж состоялся 2 августа в 10:25 UTC. Спустя несколько дней Silverscript получил соответствующий встроенный метод g16.verify. В совокупности эти изменения делают путь ZK-скриптов более гибким, не меняя того, что они доказывают, — это обновление композируемости, а не новая система доказательств.
Для всех, кто строит на ковенантном слое Kaspa или следит за становлением ZK-инструментария, детали важны. Вот что изменилось, что показало обсуждение при ревью и что это значит — и чего не значит.
Что на самом деле добавляет PR #1067
Пул-реквест под названием append_r0_groth16_verifier_dynamic_image_id вводит хелпер, позволяющий разработчику собирать скрипт верификатора Groth16, в котором идентификатор образа подаётся во время выполнения, а не встраивается в структуру скрипта при сборке. Сопутствующий путь, append_r0_groth16_verifier, обрабатывает статический случай, когда идентификатор образа не меняется.
До этого мержа предыдущая работа над ZK-SDK — включая поверхность, описанную в PR #953 — уже упростила построение скриптов верификаторов RISC Zero и Groth16 без ручного написания путей опкодов. Однако та работа предполагала, что идентичность гостевого образа фиксирована. Хелпер с динамическим идентификатором образа расширяет эту поверхность: семейство доказательств остаётся Groth16, но идентичность гостевой программы может различаться между релизами или вариантами приложения.
Говоря прямо: один фрагмент верификатора теперь обслуживает несколько гостевых образов. В этом суть изменения.
Почему динамические идентификаторы образов важны
В системах доказательств с нулевым разглашением *идентификатор образа* — это хеш, уникально идентифицирующий гостевую программу, то есть код, выполнение которого подтверждает доказательство. Когда этот хеш фиксируется в скрипте верификатора на этапе сборки, любое изменение гостевой программы (исправление бага, добавление функции, обновление версии) требует развёртывания нового скрипта верификатора с другим вшитым идентификатором образа.
Для одного приложения, которое редко обновляется, это терпимо. Для растущей экосистемы, где несколько команд выпускают ZK-гостей на одной цепочке, это становится точкой трения. Каждая новая версия гостя — новый статический верификатор. Поверхность скриптов фрагментируется.
Динамические идентификаторы образов снимают это узкое место. Верификатор принимает идентификатор образа на вход в момент верификации, проверяет доказательство по нему и продолжает работу. Математика Groth16 не меняется; меняется только способ построения скрипта верификатора. Результат — один переиспользуемый фрагмент верификатора, способный обслуживать семейство гостей вместо одного фиксированного.
Источник осторожно формулирует объём утверждения. Это *слитая возможность построения скриптов* — хелпер на уровне SDK для конструирования скриптов верификаторов. Это не гарантия на уровне рантайма, что приложения должны запускать произвольную динамическую смену идентификаторов образов уже сегодня. Инструментарий существует; продакшн-применение придёт позже — когда команды его опробуют и поверхность стабилизируется.
След ревью: что показал канал R&D
Мерж произошёл не в вакууме. Telegram-канал Kaspa Core R&D зафиксировал процесс ревью, раскрывающий стандарты команды.
5 июля Саттон поднял вопрос о дизайне расположения контракта в стеке (pre-stack contract layout) для динамического пути. Он спросил, не должен ли порядок быть [journal_hash, image_id, compressed_proof], а не обратный порядок с image_id, который обсуждался. Он назвал это «мелочью», но отметил, что это перенесло бы первый своп из динамического хелпера в базовый. Позже он подтвердил, что изменение с его стороны одобрено. По отдельности это мелкое замечание — порядок аргументов, — но оно показывает, что команда рассматривает layout стека как часть публичного API, а не как деталь реализации, которую можно игнорировать.
К 8 июля оставалась одна проблема — полнота API. Пользователь saefstroem запросил соответствующий WASM-метод, отметив, что другие фрагменты уже выставляют API через ZkScriptBuilder. Ньюман согласился и попросил его оставить это как отзыв на ревью. saefstroem так и сделал, сказав, что одобрит, как только это будет реализовано. Паритет WASM важен, потому что ZK-SDK не только для Rust; потребители в браузерах и других окружениях нуждаются в той же поверхности.
Вот как должна зреть инфраструктура протокола: конкретный PR, обсуждение дизайна, явные условия одобрения. Никаких пустых обещаний о будущем.
Silverscript добавляет парную инструкцию
Через шесть дней после мержа в rusty-kaspa, 7 августа, Ньюман слил отдельный пул-реквест — PR #138, автор elldeeone — в Silverscript. Изменение добавило встроенный метод g16.verify: прямой низкоуровневый вызов в путь прекомпиляции Groth16 на стороне узла.
Это не заменяет работу над фрагментом в rusty-kaspa. Это её дополнение. Фрагмент даёт разработчикам способ конструировать скрипты верификаторов на уровне SDK. Встроенный метод даёт языку Silverscript более высокого уровня парную инструкцию, способную обращаться к тому же семейству верификаторов, как только поверхность на стороне узла будет доступна.
Представьте себе два слоя одного стека, которые сходятся. Узел выставляет прекомпиляцию. SDK предлагает хелперы для построения скриптов, которые её вызывают. Язык добавляет ключевое слово, делающее этот вызов естественным. Каждый слой по отдельности невелик; вместе они формируют рабочий путь от высокоуровневого намерения до ZK-верификации на чейне.
Обновление ковенантов Toccata открыло поверхность скриптинга Kaspa для настоящей контрактной логики — и каждое улучшение этой поверхности, от хелперов ZK-верификаторов до встроенных методов на уровне языка, расширяет возможности продуктов на основе ковенантов. Kaspa Forge выпускает некастодиальные ковенантные хранилища (Kaspa Safe), эскроу для P2P-сделок (Kaspa Escrow) и залоговые депозиты (Deposit) в основной сети уже сегодня, построенные непосредственно на инфраструктуре Toccata. Улучшенный инструментарий на уровне протокола делает фундамент прочнее для всего, что выше.
Что это значит для держателей KAS, майнеров и пользователей, практикующих самостоятельное хранение
Не каждое улучшение протокола напрямую затрагивает каждого пользователя. Это изменение не влияет на производство блоков, сложность майнинга и то, как вы храните свои ключи. Оно важно для экосистемы, от которой зависят эти пользователи.
Для билдеров и приложений, которые они выпускают: Динамические идентификаторы образов снижают стоимость итераций на ZK-гостях. Команда может обновить свою гостевую программу, не вынуждая каждый нисходящий скрипт верификатора к переразвёртыванию. Это понижает порог для выпуска функций на ZK в Kaspa — не гипотетически, а через слитый код, который уже есть в репозитории.
Для держателей KAS, следящих за созреванием экосистемы: Качество инструментария для разработчиков — опережающий индикатор. Цепочки, где ZK-верификация является первоклассным, хорошо прорецензированным элементом, привлекают разработчиков, создающих приложения, которые дают цепочке право на существование помимо спекуляций. Этот PR — небольшой, но конкретный сигнал: код слит, ревью зафиксировано, паритет WASM запрошен.
Для майнеров и сторонников PoW: Ничего из этого не меняет консенсусную модель Kaspa. blockDAG по-прежнему работает на PoW. Ковенанты и ZK-верификация действуют внутри транзакций, а не на консенсусном слое. Что меняется — это *выразительность* того, что транзакции могут делать, что со временем способно увеличить объём транзакций и, следовательно, доход от комиссий. Это длинная дуга, а не событие за одну ночь, но за ней стоит следить.
Для тех, кто практикует самостоятельное хранение: Принцип важен. ZK-доказательства позволяют проверять утверждения, не доверяя утверждающему. Динамические идентификаторы образов делают эту проверку более практичной для множества сторон, генерирующих доказательства. Направление ведёт к миру, где вам не нужно доверять серверу платформы, чтобы знать, что вычисление было честным. Этот мир ещё не наступил, но инструментарий для его построения мержится.
Честный объём
Исходный текст заканчивается ясной оговоркой, которую стоит повторить: это не доказательство того, что продакшн-приложения должны рассчитывать на произвольную динамическую смену идентификаторов образов уже завтра. Это слитая возможность построения скриптов, давление ревью в сторону паритета WASM и встроенный метод Silverscript, нацеленный на то же семейство верификаторов.
Вот как выглядит прогресс протокола большую часть времени — не единое объявление, меняющее всё, а серия прорецензированных, слитых, дополняющих друг друга изменений, расширяющих выразительность системы. Фрагмент динамического идентификатора образа Groth16, встроенный метод g16.verify и обсуждения ревью вокруг них формируют одну такую серию. Следующий шаг — паритет WASM для поверхности SDK и реальные приложения, опробующие динамический путь в продакшн-условиях.
До тех пор инструментарий существует открыто, в публичных репозиториях, сформированный публичным ревью. Это стандарт.
---
*Источник: Dynamic Groth16 Image IDs Land In Rusty Kaspa — Kaspa News, 10 августа 2026 г.*
FAQ
Что такое динамический идентификатор образа при верификации Groth16?
Динамический идентификатор образа позволяет верификатору принимать хеш, идентифицирующий ZK-гостевую программу в момент вызова, вместо того чтобы вшивать его в фиксированный скрипт. Это означает, что один фрагмент верификатора может обслуживать несколько версий гостя или вариантов приложения без необходимости каждый раз разворачивать новый скрипт-путь.
Значит ли это, что продакшн ZK-приложения могут свободно менять идентификаторы образов в Kaspa уже сегодня?
Нет. Слитый PR добавляет инструмент для построения скриптов на уровне SDK. В исходном тексте прямо сказано: «это не доказательство того, что продакшн-приложения должны рассчитывать на произвольную динамическую смену идентификаторов образов уже завтра». Это инструментальный слой, а не гарантия рантайма.
Что такое встроенный метод g16.verify в Silverscript?
Это низкоуровневая инструкция языка Silverscript, которая напрямую вызывает путь прекомпиляции Groth16 на стороне узла. Она даёт коду более высокого уровня возможность обращаться к тому же семейству верификаторов, которое теперь поддерживается фрагментом в rusty-kaspa.
Как это связано с ковенантами Toccata?
Toccata принесла поддержку ковенантов в основную сеть Kaspa. Инструментарий ZK-скриптов — включая хелперы верификации Groth16 — строится на той же пост-Toccata поверхности скриптинга. Улучшенная инфраструктура верификаторов означает, что на том же основании становится возможна более выразительная логика ковенантов.
Держите KAS там, где кражу можно отменить
Ковенант-сейф в мейннете Kaspa: ваши ключи, ваши правила, наш инструмент. Ончейн — бесплатно, навсегда.
Создать сейф