Может ли стол в блэкджек Kaspa обойтись без крупье от дома?

Короткий ответ: технически да, но пока не реализовано. Исследование стола блэкджека Arena без крупье — где обычный пользователь, а не KaspaForge, выступает крупье — подтвердило, что локальная генерация ZK-доказательства позволяет хранить секретный сид крупье исключительно на его собственном устройстве. Ковенант по-прежнему обеспечивает легальность игры и правильные выплаты независимо от того, кто раздаёт карты. Однако реализация намеренно отложена: текущий спрос на одноранговый блэкджек Kaspa не оправдывает инженерных и UX-затрат на выпуск этой функции прямо сейчас.

В этой статье рассказывается, как Arena Blackjack доказывает честность перетасовки, почему сделать роль крупье открытой сложнее, чем кажется, что показало исследование и где проходят честные продуктовые границы.

Как Arena Blackjack доказывает честность перетасовки

Каждая раздача в Arena Blackjack начинается с криптографической перетасовки. Два участника вносят энтропию:

shuffled_deck(game_id, dealer_seed, player_seed)
  → canonical 52-card permutation
  → deck_root (Merkle commitment)

dealer_seed и player_seed генерируются локально каждой из сторон. Вместе они детерминированно порождают единственную перестановку из 52 карт — колода для данной раздачи. Корень Меркла этой перестановки (deck_root) фиксируется ончейн внутри ковенанта Game.

Чтобы доказать корректность перетасовки без раскрытия любого из сидов, Arena использует ZK-доказательство RISC Zero. Гостевая программа принимает оба сида как приватный свидетель — входные данные, которые никогда не появляются ончейн — и генерирует доказательство того, что заявленный deck_root был честно вычислен. Ковенант-скрипт Kaspa проверяет это доказательство ончейн с помощью опкода OpZkPrecompile 0x20 ещё до раздачи карт.

Это та же модель верификации, что описана в базе знаний разработчика Kaspa wiki: ковенант определяет, какие транзакции легальны, а ZK-доказательство — один из проверяемых им фактов.

После подтверждения начальной раздачи последующие ходы — Взять, Стойка, Удвоение, Сплит — следуют детерминированным правилам крупье. Каждый переход — это новая трата ковенанта: игрок подписывает своё решение локально, детерминированное действие крупье вычисляется на основе текущего состояния руки, и публикуется следующий UTXO игры. Ковенант проверяет, что каждая взятая карта соответствует зафиксированной колоде, и что выплаты в конце корректны (3:2 за натуральный блэкджек, выплата 1:1 в остальных случаях, согласно текущим правилам Arena).

Ключевая гарантия: даже если одна из сторон знает колоду, она не может изменить выплату или легальную последовательность карт. Ковенант-скрипт выступает арбитром, и он выполняется на каждом узле Kaspa.

Секретная проблема крупье

В нынешнем Arena Blackjack — публичной бете основной сети — KaspaForge является крупье за каждым столом. Инфраструктура хостингового прувера генерирует ZK-доказательство, а значит, оба сида — dealer_seed и player_seed — проходят через прувер как приватный свидетель.

Для стола заведения это заявленная модель доверия. Дом уже сгенерировал dealer_seed; передача его собственному пруверу не создаёт нового вектора утечки. Ковенант не позволяет заведению изменить выплаты, даже если бы оно того захотело.

Но что, если обычный пользователь хочет стать крупье? В этом суть протокола P2P-крупье: стол, где ни одна из сторон не является KaspaForge, а правила обеспечиваются исключительно ковенантом.

Проблема очевидна. Если пользователь-крупье отправит свой dealer_seed хостинговому пруверу — даже тому, которым он не управляет — этот прувер сможет восстановить полную перестановку из 52 карт:

prover sees:  dealer_seed + player_seed
prover knows: full deck order before any card is revealed

Ковенант по-прежнему не позволяет пруверу изменить выплаты или навязать нелегальные ходы. Но приватность колоды утрачена. Прувер, знающий колоду, теоретически может её слить или использовать для решений по побочным каналам. Для P2P-игры, не требующей доверия, это неприемлемо — секрет крупье должен оставаться секретом.

Это не дефект дизайна ковенанта Arena. Это фундаментальное свойство текущего конвейера доказательств: тот, кто строит доказательство, видит свидетеля.

Пять путей, которые исследовала команда

В рамках исследования были оценены пять различных подходов к решению проблемы секрета крупье. Каждый оценивался по четырём осям: корректность (можно ли подделать доказательство?), приватность (кто видит сиды?), живучесть (может ли одна из сторон заблокировать игру?) и избирательный отказ (может ли сторона выйти из игры, узнав что-то выгодное, например следующую карту?).

A. Локальный прувер на устройстве крупье. Собственное устройство крупье — настольный хелпер или нативный клиент — генерирует доказательство RISC Zero. Сид dealer_seed никогда не покидает его устройства. Это самый прямой путь к настоящему блэкджеку без крупье: владелец секрета подтверждает утверждение локально. Компромисс — аппаратные требования: генерация доказательства занимает время CPU или GPU, а крупье должен держать приложение запущенным до завершения процесса.

B. Аутсорсинговая генерация доказательств с сохранением приватности. Техники вроде вычисления со множеством сторон (MPC), разделённого доказательства между устройством крупье и хостинговым GPU, или неведомых вычислений, где удалённый прувер ассистирует, не видя сырых свидетелей. Каждый кандидат оценивался по конкретному протоколу, допущениям безопасности и совместимости с существующим путём верификации через OpZkPrecompile 0x20. Технические документы без рабочего кода были отмечены как исследовательские ссылки, а не варианты для реализации.

C. Генерация доказательств в TEE с удалённым удостоверением. Доверенная среда исполнения (Intel SGX, AMD SEV или аналог) запускает прувер в анклаве. Пользователь проверяет удалённое удостоверение перед отправкой своего сида. Это может обеспечить практическую приватность, но вводит новый доверенный аппаратный корень — не криптографическую гарантию. Применимы риски цепочки поставок, отката, DMA и атак со стороны администратора хоста.

D. Изменения протокола или утверждения. Переработать перетасовку так, чтобы ни один прувер не видел оба сида: зафиксированные или зашифрованные колоды, поэтапные доказательства для каждой карты, верифицируемые протоколы перетасовки с двумя участниками или двухстороннее доказательство, где крупье подтверждает небольшую локальную часть, а хостинговый прувер берёт на себя тяжёлые публичные вычисления. Любое изменение гостевой программы или схемы журнала означает новый image_id, новую версию программы и новый инвентарь Room/Game — существующие активные UTXO невозможно мигрировать.

E. Честная хостинговая модель (запасной вариант). Принять тот факт, что хостинговый прувер видит колоду, явно задокументировать границу доверия и полагаться на ковенант в предотвращении манипуляции результатами. Это не настоящий P2P — это отдельный класс столов «с участием прувера» с чётко заявленным допущением о доверии.

Вердикт по локальному пруверу

Исследование завершилось вердиктом ОДОБРЕНО — ЛОКАЛЬНОЕ ДОКАЗАТЕЛЬСТВО КРУПЬЕ.

Вывод: устройство крупье способно генерировать доказательство RISC Zero локально, полностью удерживая dealer_seed на своей машине. Доказательство было проверено независимым локальным верификатором и движком TxScriptEngine Kaspa на параметрах simnet. Холодная и тёплая латентность, пиковое потребление памяти и объём передаваемых данных были измерены на репрезентативном оборудовании — не оценены по маркетинговым заявлениям.

Ключевое свойство: в локальной модели хостинговый прувер полностью исключается из уравнения доверия. Крупье генерирует свой сид, строит доказательство и транслирует результат. Ни одна третья сторона никогда не видит порядок карт в колоде. Многопользовательская случайность Kaspa — совокупная энтропия обоих сидов — остаётся распределённой исключительно между двумя игроками.

Это отражает принцип, делающий Kaspa Safe некастодиальным: секрет (здесь — сид крупье, там — ключ хранилища) остаётся на устройстве пользователя. Ковенант обеспечивает правила ончейн независимо от обстоятельств.

Почему реализация намеренно отложена

Несмотря на положительный вердикт исследования, продуктовое решение — отложить реализацию. Обоснование экономическое, а не техническое:

• Текущие столы Arena Blackjack демонстрируют умеренное стабильное использование в статусе публичной беты основной сети.
• Модель с хостинговым крупье работает: ковенант обеспечивает честность, а граница доверия — заведение видит колоду, но не может изменить результаты — чётко задокументирована.
• Разработка локального клиента прувера — с установкой, обновлениями, восстановлением после сбоев, зашифрованным сохранением сессий и аппаратной совместимостью между платформами — это значительная инженерная работа для функции, спрос на которую пока не проявился в масштабе.
• Артефакты исследования (модель угроз, матрица вариантов, анализ потоков секретов, логи бенчмарков) сохранены и воспроизводимы. Когда спрос оправдает вложение, путь реализации ясен.

Это не архивированный эксперимент. Исследование завершено, вердикт задокументирован, техническая основа надёжна. Это осознанное продуктовое решение — строить то, что нужно пользователям сейчас, и откладывать то, что может понадобиться потом.

Компромиссы и честные границы

Несколько вещей, которые исследование не выявило:

• Ни один вариант аутсорсинговой генерации доказательств с сохранением приватности не был признан жизнеспособным для текущего стека RISC Zero/Groth16 с совместимым рабочим кодом. MPC и неведомые вычисления остаются активными областями исследований в более широкой ZK-экосистеме, но ни одно из них не предложило готового решения для гостевой программы Arena.
• Генерация доказательств на основе TEE вводит новый корень доверия, а не гарантию, не требующую доверия. Для некоторых пользователей этого может быть практически достаточно, но не следует позиционировать это как эквивалент криптографической приватности.
• Изменения протокола обходятся дорого. Любая модификация утверждения перетасовки означает новую версию программы, новый инвентарь Room и невозможность миграции существующих активных UTXO. Это жёсткое ограничение дизайна на основе ковенантов — ончейн-скрипт неизменяем после пополнения.

Текущая бета Arena Blackjack — с KaspaForge в роли крупье — остаётся актуальным продуктом. Его модель доверия: заведение видит колоду, ковенант обеспечивает легальность игры и правильные выплаты, а ZK-доказательство публично верифицируемо. Эта модель честна и функциональна сегодня.

Что это значит для стека игр с самостоятельным хранением в Kaspa

Исследование P2P-крупье иллюстрирует более широкий принцип дизайна Kaspa Forge: ковенант — арбитр, а не платформа. Оперирует ли KaspaForge прувером или это делает пользователь-крупье, ончейн-скрипт определяет, какие транзакции легальны. Задача прувера — предоставить доказательство честности перетасовки; он не может изменить правила.

Это разделение — генерация доказательств офчейн, применение правил ончейн — делает модель расширяемой. Будущий стол с P2P-крупье будет использовать тот же ковенант, ту же верификацию через OpZkPrecompile 0x20 и те же детерминированные правила раздач. Меняется только место генерации доказательства.

Для держателей и майнеров Kaspa вывод архитектурный: ковенанты в основной сети Toccata позволяют игровую логику, которая прозрачна, неизменяема и не зависит от того, кто управляет инфраструктурой. BlockDAG подтверждает транзакции. Скрипт определяет исход. Всё остальное — детали реализации.

---

*Статус продукта: Arena Blackjack — публичная бета основной сети. Исследование P2P-крупье завершено; реализация намеренно отложена. Dice находится в инженерной разработке, его постоянный продакшен отключён до завершения проверки. Duel и баккара — идеи из дорожной карты, а не продукты.*