Проектирование дуэльной игры один на один на Kaspa

Дуэль один на один на Kaspa — старшая карта, камень-ножницы-бумага, чёт-нечёт — звучит как простейшая возможная on-chain-игра: никакого скрытого состояния, ни крупье, ни тасовки, ни доказательств. Два человека выбирают значение, контракт сравнивает их, победитель забирает банк. На практике сложная часть — не игровая логика, а *протокол*: как два незнакомых человека договариваются о пари, блокируют средства, честно раскрывают свой выбор и рассчитываются — всё без доверенного третьего лица, на блокчейне на основе PoW, подтверждающем транзакции за секунды.

В этой статье мы подробно разберём криптографическое проектирование P2P-игрового протокола Kaspa для дуэлей один на один, как мы его проработали внутри команды. Дуэльный движок — это пункт дорожной карты, а не реализованный продукт. Arena Blackjack — действующая игровая площадка; Dice находится в разработке, а его боевая версия отложена до независимого аудита. Всё, описанное ниже, — система, которую мы спроектировали, но ещё не построили.

Проблема: доверительный пари между двумя сторонами

Дуэль между двумя людьми, которые уже доверяют друг другу, тривиальна — один просто передаёт другому деньги после игры. Интересный случай — двое, которые друг другу не доверяют, и единственная связь между ними — ссылка и адрес на Kaspa. On-chain-контракт должен обеспечить выполнение каждого шага:

1. Оба игрока фиксируют свой выбор до того, как увидят выбор соперника. 2. Оба раскрывают секрет — и раскрытое значение проверяемо совпадает с зафиксированным хешем. 3. Исход детерминирован на основе двух раскрытых значений. 4. Если один из игроков исчезает, добросовестная сторона получает компенсацию из залога, а не остаётся в ожидании.

Каждый из этих пунктов — отдельная криптографическая и ковенантная инженерная задача.

Многопользовательский commit-reveal: базовый механизм

Паттерн commit-reveal — это фундамент каждой игры Kaspa Forge. Для дуэли он работает в три фазы.

Фаза 1 — Фиксация (commit). Каждый игрок генерирует секрет локально — случайную строку байтов, которая никогда не передаётся и не хранится в блокчейне в открытом виде. Он хеширует секрет и публикует только хеш. На Kaspa это означает создание транзакции, ковенантный выход которой фиксирует SHA-256(secret) или BLAKE3(secret) как часть состояния комнаты в блокчейне. Хеш — это *обязательство*: оно закрепляет за игроком выбор, не раскрывая его.

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

Фаза 2 — Раскрытие (reveal). После того как оба обязательства подтверждены в блокчейне, каждый игрок публикует свой секрет. Контракт — или оффчейн-верификатор, следящий за DAG — хеширует раскрытый секрет и сравнивает его с обязательством. Если они совпадают, раскрытие действительно. Если игрок раскрывает значение, хеш которого не совпадает с обязательством, контракт отклоняет его, и срабатывает ветка тайм-аута.

Это как если бы игрок открыл свой конверт. Хеш доказывает, что это тот самый конверт, который он положил раньше.

Фаза 3 — Исход и расчёт. Ковенантный скрипт вычисляет результат на основе двух раскрытых значений по правилам игры (старшая карта побеждает, матрица «камень-ножницы-бумага», проверка чётности) и направляет заблокированные средства соответствующим образом. На Kaspa это одна ковенантная транзакция с детерминированными выходами выплат. Модель комиссий и UTXO-структура Kaspa, описанная в базе знаний разработчика на вики Kaspa, делают этот расчёт быстрым и дешёвым — в дуэльном расчёте нет накладных расходов генерации ZK-доказательств или верификации Merkle-путей.

Игрок A  ─── hash(a)  ──→  ROOM_OPEN
Игрок B  ─── hash(b)  ──→  COMMITTED
Игрок A  ─── reveal a ──→  ┐
Игрок B  ─── reveal b ──→  ┘ evaluate → SETTLED

Ковенантный конечный автомат: как контракт обеспечивает честность

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

ROOM_OPEN    + оба обязательства на месте  → COMMITTED
COMMITTED    + оба раскрытия на месте      → evaluate → SETTLED (победитель/ничья)
COMMITTED    + дедлайн истёк               → TIMEOUT (залог добросовестной стороне)
ROOM_OPEN    + дедлайн истёк               → TIMEOUT (залог создателю)

Каждый переход состояния — это одна транзакция, расходующая текущий ковенантный выход и порождающая следующий. Ковенант проверяет:

• Наличие обязательства — содержит ли последующая транзакция хеш обязательства?
• Действительность раскрытия — совпадает ли hash(раскрытый_секрет) с зафиксированным обязательством?
• Правила игры — правильно ли определён победитель на основе двух значений?
• Соблюдение дедлайна — превысил ли текущий DAA-счёт значение якоря тайм-аута плюс задержка?

Механизм тайм-аута требует точности. Консенсус Kaspa использует virtualDaaScore как монотонные часы. Ковенант фиксирует дедлайн как anchorDaa + delayBlocks, и скрипт проверяет, что DAA-счёт транзакции расходования не превысил этого значения. Если дедлайн прошёл и игрок не предпринял действий, срабатывает ветка тайм-аута и присуждает банк — включая залог нарушителя — ожидающему игроку.

Это тот же паттерн дедлайнов, который Arena Blackjack использует для веток PLAYER_SEED_TIMEOUT и DEALER_TURN_TIMEOUT. Дуэль переиспользует эту структуру без ZK, деревьев Меркла или доказывающего модуля — что делает её простейшим потребителем ковенантного слоя.

Залог > ставка: гарантия активности

Каждая игра Arena разделяет *ставку* (пари) и *залог* (депозит активности). Для дуэли залог должен быть строго больше ставки. Вот почему:

Если залог ≤ ставка, проигрывающий игрок может просто перестать отвечать. Тайм-аут срабатывает, но потеря залога стоит меньше или равно потере от честного проигрыша. Рациональный ход — исчезнуть: худший исход не хуже, чем честно проиграть.

При залог > ставка отказ от игры всегда обходится дороже, чем её завершение. Ушедший игрок теряет залог *плюс* ставку, а добросовестная сторона получает весь банк. Математика принуждает к завершению игры.

Банк в ковенанте = 2 × ставка + 2 × залог

Ветка тайм-аута (B исчезает):
  A получает = ставка(A) + залог(A) + ставка(B) + залог(B) − комиссии
  B получает = ничего

Обычный расчёт:
  Победитель получает = 2 × ставка − комиссии
  Проигравший получает = залог(проигравшего) (возврат)
  Залог победителя      = возвращается

В запланированном дизайне создатель вносит свою ставку и залог при создании комнаты; приглашённый игрок вносит свои при присоединении. Пути выплат ковенанта полностью детерминированы результатом игры — никаких оракулов, разрешения споров или оффчейн-переговоров.

Ковенантные приглашения: комнаты с криптографическим ключом

Текущие комнаты Arena Blackjack создаются оператором. Они появляются в публичном лобби; любой может занять свободное место. Это работает для игр с банком дома, где оператор управляет жизненным циклом комнаты.

Дуэль устроена иначе. Создатель хочет сыграть с *конкретным человеком* — но без готовой системы идентификации, списков доступа или регистрации. Криптографическое решение — приглашение с криптографическим ключом:

1. Создатель генерирует случайный invitation_secret. 2. Ковенант комнаты фиксирует SHA-256(invitation_secret) как часть состояния в блокчейне. 3. Создатель делится ссылкой, содержащей прообраз: https://…/duel?reveal=<invitation_secret>. 4. Когда приглашённый игрок открывает ссылку, его клиент предъявляет секрет ковенанту. Скрипт проверяет hash(прообраз) == зафиксированный_хеш и допускает игрока.

Создателю не нужно заранее знать адрес Kaspa приглашённого игрока. Любой, у кого есть ссылка, может сесть за стол — но место соперника только одно, и первое корректное подтверждение побеждает. Это не список доступа; это одноразовый криптографический замок. Ссылка *и есть* ключ.

У этого дизайна есть определённый компромисс: если ссылка утечёт, вместо предполагаемого соперника может присоединиться посторонний. Для неформальных игр этот риск приемлем — создатель контролирует момент пополнения комнаты и может отменить создание, если появится нежелательный участник. Для дуэлей с крупными суммами ссылку можно передать через зашифрованный канал. Зашифрованный браузерный профиль Desk от Kaspa Forge — один из таких каналов: ключи хранятся на устройстве пользователя, а сессия изолирована от хостовой операционной системы.

Что существует сегодня и чего не хватает дуэли

Дуэльный движок наследует несколько компонентов, уже созданных и работающих в Arena Blackjack:

• Ковенантный конечный автомат — паттерн переходов состояний, обеспечиваемый скриптами L1 Kaspa, проверен на живых руках мейннета.
• Механика commit-reveal для сида — двухфазный подход «сначала хеш, потом раскрытие» для генерации случайности напрямую подходит для фиксации игровых выборов.
• Обеспечение тайм-аутов — дедлайны по DAA-счёту с ветками штрафования залога уже в работе.
• Процесс подписи в Desk — локальное хранение ключей, зашифрованный профиль, подтверждение паролем для каждого действия, отказоустойчивый кошелёк на WASM.

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

1. Создать ковенант комнаты с выбранными параметрами игры. 2. Пополнить её своей ставкой, залогом и резервом на комиссии. 3. Сгенерировать и зафиксировать секрет приглашения. 4. Опубликовать комнату на обнаруживаемой площадке — или просто поделиться ссылкой в частном порядке.

Это единственный и самый сложный пробел в возможностях. Он затрагивает логику допуска, гибкость ковенантных шаблонов, UI Desk для создания комнат и границу безопасности между операторскими и пользовательскими комнатами. Внутренний архитектурный план отмечает, что дуэль — *самый простой* способ построить и проверить эту возможность, поскольку в ней нет сложности ZK-доказательств, перемешанных колод или многораундных ходов крупье. Как только создание комнат без разрешений будет реализовано, P2P-крупье для Blackjack и других двухсторонних игр сможет его унаследовать.

Честные границы и текущие ограничения

Несколько вещей нужно сказать прямо:

• Это не продукт. Дуэльный движок — проектная конструкция без отправленного кода, без живых комнат и без ссылок-приглашений. Arena Blackjack — единственная действующая игровая площадка.
• Dice находится в разработке, а его боевая версия отложена до независимого аудита. Дуэль идёт после Dice в конвейере, и конвейер уже был перестроен один раз на основе измеренных приоритетов.
• Возможность создания комнат без разрешений ещё не реализована. Пока она не будет создана, протестирована и проверена, дуэльный движок не может функционировать — даже как прототип.
• Социальный спрос не измерен. Архитектурный план явно откладывает дуэльный движок до тех пор, пока не будет подтверждён спрос на социальные игры (без банка дома). Обязательное создание комнаты, отправка приглашения и ожидание второго участника создают высокий порог входа для игры, которая разрешается за считанные секунды.
• Аудит не проводился. Описанные здесь конструкции — внутренние плановые документы, а не проверенные артефакты. Трёхраундный независимый процесс проверки, который прошёл Dice — V1 НЕТ-GO, V2 НЕТ-GO, V3 GO — это стандарт. Дизайны дуэли пройдут ту же строгость перед любым развёртыванием в мейннете.

Семантика тайм-аутов заслуживает отдельной оговорки. В Blackjack мягкий тайм-аут возвращает игроку ставку минус комиссии, если тот не предпринял действий — игра аннулируется, а не наказывает. Для дуэли план предусматривает более строгое правило: весь банк (ставка плюс залог неответившей стороны) переходит к добросовестному игроку. Это правильный стимул для симметричной игры без банка дома, но это означает, что ковенант должен обрабатывать граничные случаи частичных раскрытий, замены транзакций и отклонений DAA-часов без какой-либо допустимости неоднозначности.

Куда это ведёт

Рабочий дуэльный движок — не самоцель. Это инфраструктура для любой двухсторонней ковенантной игры — старшая карта, камень-ножницы-бумага, чёт-нечёт и всё, что сообщество придумает на основе единой ковенантной формы. Что ещё важнее — это первая площадка, где *пользователи*, а не операторы, создают и финансируют on-chain игровые комнаты. Эта возможность — создание комнат без разрешений с криптографическим допуском и залоговым обеспечением активности — фундамент, на котором будет стоять будущий P2P-крупье для Blackjack.

Путь пролегает через ковенантный слой Kaspa: опкоды Toccata делают конечный автомат реализуемым на L1, DAA-счёты обеспечивают часы, а PoW DAG обеспечивает финализацию. Никаких оракулов, никакого оффчейн-расчёта, никакого кастодиального эскроу. Два игрока, один контракт, одна транзакция расчёта.

Пока что дизайн живёт в плановых документах и внутренних архитектурных записках. Когда он перейдёт в код, он пройдёт тот же цикл независимой проверки, который породил три раунда аудита Dice до решения GO. В этом и суть: доверительные игры требуют доверительной инженерии.