Первая Постквантовая подпись на тестовой сети Kaspa Testnet-10

24 июня 2026 года исследователь Максим Бирюков опубликовал транзакцию на тестовой сети Kaspa testnet-10 и описал ее как первую постквантовую подпись, запущенную в живой сети Kaspa. Результат носит экспериментальный характер — репозиторий kaspa-xmss помечен как таковой — и это не запуск кошелька. Он демонстрирует нечто более узкое и более значимое: верификатор постквантовой подписи на основе хеш-функций, написанный полностью на языке скриптов Kaspa (txscript), прошел через путь расходования ковенанта на публичном тестовом узле с активированным Toccata. (источник)

Хеш транзакции: 0c401bcf922eba67eadf1830c78578ac172d71f7735c0c669d681582aedc6e0c. Коммит f55230b фиксирует тот же живой тестовый сценарий. Тайминг важен: тест состоялся через два дня после подписания в США указа, формализующего миграцию к постквантовой криптографии как государственную политику.

Что изменилось — а что нет

Сегодня Bitcoin, Ethereum и Kaspa полагаются на подписи на эллиптических кривых (ECDSA на secp256k1 или эквиваленте) для авторизации обычных транзакций. Достаточно мощный квантовый компьютер угрожает этим системам с открытым ключом, поэтому NIST стандартизирует постквантовую криптографию как для шифрования, так и для цифровых подписей.

Результат Бирюкова не решает эту проблему для основной сети Kaspa. Репозиторий kaspa-xmss прямо указывает: код экспериментальный и непроверенный. Что он решает — это технический вопрос, который ранее оставался открытым: может ли верификатор постквантовой подписи быть выражен как txscript, привязан к состоянию ковенанта и принят живым тестовым узлом в рамках скриптового пути эпохи Toccata? С 24 июня ответ — да.

Схема подписи: XMSS^MT

Реализация использует XMSS^MT — многодеревьевую версию расширенной схемы подписи Меркла (eXtended Merkle Signature Scheme). Спецификация схемы в репозитории следует профилю NIST SP 800-208 с двумя деревьями высотой 12, одноразовыми подписями WOTS+, 24-байтным хеш-выводом и подписями размером около 3 КБ.

Ключевое отличие в том, что проверка подписи строится на хеш-операциях, а не на вычислениях с эллиптическими кривыми. Верификатор, построенный из детерминированных хеш-шагов, можно скомпилировать в txscript и проверить правилами консенсуса, не дожидаясь специальной постквантовой опкода. Crate xmss-script в репозитории — это компонент, работающий в цепочке: он генерирует верификатор, привязывает подпись к каноническому сообщению транзакции и тестирует путь расходования ковенанта.

У XMSS есть реальный компромисс

XMSS построена на одноразовых подписях WOTS+. Каждый индекс листа в дереве Меркла может быть использован только один раз. Повторное использование одного и того же индекса листа для двух разных сообщений полностью нарушает модель безопасности. Управление состоянием подписи — какой лист текущий, был ли он использован — столь же важно, как и сама проверка подписи.

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

Двухскриптовый дизайн ковенанта

Тестовая реализация Бирюкова решает проблему состояния архитектурно, используя разделение двухскриптового ковенанта:

• Vault A — публичный адрес для внесения средств, не несущий обязательства по подписи.
• Скрипт состояния B(i) несет верификатор XMSS и текущий индекс листа.

Каждое корректное расходование должно создавать ровно один выход-преемник состояния, B(i+1). Поступления направляются на A; состояние подписи продвигается только через B.

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

Почему скрипт весит 84 КБ

Проверка XMSS избегает вычислений с кривыми, но все равно обходит хеш-цепочки WOTS+ и обрабатывает аутентификационные пути Меркла. Развернутый в скрипте, это составляет около 1650 хеш-операций. Бирюков отметил, что открытый скрипт имеет размер около 84 КБ; заметки к тестовой сети в репозитории указывают размер скрипта погашения (redeem script) примерно 84,5 КБ.

Размещение такого большого скрипта непосредственно в выходе превысило бы лимит размера scriptPublicKey в Kaspa. Реализация обходит это с помощью оплаты по хешу скрипта (P2SH): выходы фиксируют только хеш скрипта погашения, а расходующие раскрывают полное тело размером 84 КБ только при расходовании. Этот подход сохраняет заблокированный выход компактным, одновременно делая полный верификатор доступным для движка скриптов во время расходования.

Что делает возможным Toccata

Этот результат зависит от скриптовой поверхности и ковенантов, которые активирует Toccata. Запускающий тест проверяет виртуальный балл DAA, чтобы подтвердить, что путь Toccata активен, перед отправкой транзакций. Без инфраструктуры ковенантов Toccata двухскриптовый автомат состояний — хранилище A, состояние B(i), обязательный преемник B(i+1) — не имел бы поверхности для обеспечения в консенсусе.

Это более широкий сигнал для держателей и строителей на Kaspa: Toccata — это не просто функция для хранилищ и эскроу. Это скриптовая и ковенантная основа, на которой более сложные конструкции в цепочке, включая схемы постквантовых подписей, становятся выражаемыми в txscript.

Политический фон

За два дня до теста Бирюкова, 22 июня 2026 года, президент Дональд Трамп подписал указ «Обеспечение национальной безопасности перед лицом продвинутых криптографических атак». Указ требует от федеральных активов и систем высокого воздействия в США использовать постквантовую криптографию для установления ключа к 31 декабря 2030 года и для цифровых подписей к 31 декабря 2031 года.

Cloudflare охарактеризовал указ как две последовательные миграции: сначала постквантовое шифрование, затем постквантовая аутентификация. Это различие напрямую применимо к блокчейн-системам. Шифрование защищает приватный трафик (рукопожатия, распространение в мемпуле). Аутентификация защищает способность доказать, что транзакция подписана правильным ключом. Тест Бирюкова относится ко второй категории: это верификатор подписи.

Указ не предписывает ничего для permissionless блокчейнов. Но он задает темп для более широкой криптографической экосистемы. Поставщики, библиотеки, аппаратные модули безопасности и движки браузеров в течение следующих пяти лет будут мигрировать в сторону поддержки подписей PQ. Блокчейны, которые смогут продемонстрировать совместимость с подписями PQ на уровне своих скриптов — даже на экспериментальном этапе — будут лучше подготовлены к принятию этой инфраструктуры по мере ее созревания.

Что это значит для держателей KAS и пользователей с самостоятельным хранением

Честная оценка трехаспектна:

1. Для пользователей сегодня ничего не меняется. Это исследовательская демонстрация на тестовой сети с непроверенной кодовой базой. Пока не существует ни кошелька, ни инструмента подписи, ни продуктивной схемы. 2. Технический вопрос решен. Верификатор PQ на основе хеш-функций может работать внутри движка скриптов Kaspa, внутри ковенанта, на живом тестовом узле с активированным Toccata. Это отмеченный как выполненный необходимый этап, а не запущенный продукт. 3. Временные рамки реальны. Придут ли квантовые компьютеры в срок или нет, институциональное и регуляторное давление на миграцию подписей формализуется. Скриптовая поверхность Kaspa в рамках Toccata теперь продемонстрировала, что она способна нести эту миграцию, когда она наступит.

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

Репозиторий kaspa-xmss — открытый исходный код. Тестовые транзакции публичны. Спецификация двухскриптового ковенанта задокументирована. Если вы строите на Kaspa, это стоит прочитать.