Как работают смарт-контракты в крипто-казино

Смарт-контракты превращают казино в набор прозрачных программ: правила, банк, ставки, случайность и выплаты описаны кодом, исполняются автоматически и видны в блокчейне. Ниже — практическая «карта местности»: из чего состоит такая система, как она обеспечивает «provably fair», где возникают риски и как их закрывают.

1) Архитектура по блокам

1. Игровая логика (Game Core):

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

2. Банк/казначейство (Treasury/Bankroll):

Хранит ликвидность казино, выплачивает выигрыши, применяет лимиты экспозиции (max-win, max-payout-per-block, daily cap).

3. Случайность (RNG Layer):

Источники — on-chain VRF, commit-reveal, мульти-оракулы. Запрещено полагаться на blockhash текущего блока.

4. Роутер платежей (Payments):

Депозиты/выводы, кросс-чейн мосты, поддержка токенов и стейблкоинов, учёт комиссий сети.

5. Админ-модуль (Governance):

Изменение лимитов, пауза аварийного режима (circuit breaker), обновления через proxy-паттерн, ролевые модели (owner, risk-manager, treasurer).

6. Индексация/UX (Off-chain):

Фронтенд, индексаторы, аналитика. Логика честности и расчёта — на цепи; визуализация — вне цепи.

2) Жизненный цикл ставки

1. Депозит: игрок переводит токены на контракт или использует approve+transferFrom.

2. Создание раунда: контракт валидирует ставку (лимиты, whitelists, доступная ликвидность казначейства).

3. Фиксация параметров: размер ставки, коэффициент/правила, seed игрока (если есть), дедлайн получения случайности.

4. Получение случайности: контракт запрашивает RNG (VRF/commit-reveal) и ждёт ответ.

5. Расчёт результата: функция `settle()` берёт случайность, вычисляет исход, умножает ставку на коэффициент, удерживает комиссию (house edge).

6. Выплата: выигрыш отправляется игроку; при проигрыше сумма остаётся в казначействе.

7. Вывод: игрок инициирует `withdraw()`. Контракт проверяет балансы/клеймы, применяет анти-фрод-лимиты.

3) «Provably fair»: откуда берётся честная случайность

A) VRF (Verifiable Random Function):

Контракт делает запрос, оракул возвращает число + криптодоказательство. Контракт верифицирует доказательство сам — без доверия к оператору.

B) Commit-reveal (двухфазная схема):

Игрок отправляет `commit = hash(playerSeed, salt)`.
После ставки казино или децентрализованный участник раскрывает свой `revealSeed`.
Итоговая случайность = H(commit, revealSeed, block data).
Важно: защита от отказа одной стороны (временные окна, штрафы, fallback).

C) Мульти-источник:

Миксуются VRF из 2+ провайдеров или VRF + commit-reveal, чтобы убрать единичную «точку доверия».

Чего нельзя:

Использовать `blockhash(block.number)` текущего блока. Майнер/валидатор может подбирать блок.
Полагаться на предсказуемые источники (timestamp, баланс, nonce).

4) Расчёт выигрыша и house edge

House edge прошит в формулу игры (например, 1–3%).

Коэффициенты (odds) и таблицы выплат должны детерминированно зависеть от случайности и параметров ставки: одинаковый вход → одинаковый выход.

Лимиты выигрыша: max payout per bet/tx/day, чтобы одна ставка не обнулила банк.

Пример упрощённой идеи (псевдо):


random = VRF() % 10_000;       // 0..9999 win = (random < threshold)? stake multiplier: 0;
payout = min(win, bank.maxPayout());

5) Банк казино: ликвидность и управление риском

Буфер ликвидности: контракт хранит резервы под worst-case выплаты.

Экспозиция по играм: лимит на игру/тип ставки/игрока.

Анти-MEV и анти-снайпинг: запрет settle в том же блоке, random-delay для settle, commit-фаза.

Джекпоты: отдельный пул (escrow), наполняемый процентом от каждой ставки; триггер — редкое событие в RNG.

6) Безопасность: главные уязвимости и защиты

Reentrancy:

Использовать модификаторы/паттерн checks-effects-interactions.
Выплаты через pull-модель (игрок сам забирает), а не `transfer` внутри расчёта.

Оракула и RNG:

Только проверяемые источники (VRF), commit-reveal с таймаутами и штрафами.
Fallback-логика, если источник недоступен.

Overflow/precision:

Библиотеки безопасной математики и фиксированная точность для коэффициентов.

Сетевые издержки и отказоустойчивость:

Пауза (circuit breaker) на случай багов.
Ограничение газа на сложные settle-батчи.
L2/роллап для дешёвых ставок; периодические бриджи ликвидности на L1.

MEV/фронт-ран:

Увеличить «непредсказуемость» settle; использовать приватные мемпулы/relay для чувствительных транзакций.

Обновления (upgradeability):

Proxy-паттерн + timelock + мультисиг; публичные анонсы и «lock period» перед апгрейдом.

7) Комиссии и UX

Газ и сети: для микроставок выгоднее L2 (Arbitrum/Optimism/Base) или альтернативные сети с низкой комиссией; выплаты можно агрегировать в клеймы.

Стейблкоины: снижают валютный риск игрока и стабилизируют банк.

Кросс-чейн: мосты — отдельный риск; лучше локальные рельсы per сеть + off-ramp провайдеры.

8) Аудит и прозрачность

Открытый код: репозиторий, выделенные разделы с неизменяемыми параметрами игр.

Снапшоты расчётов: скрипты, пересчитывающие исходы по входной случайности.

Мониторинг ончейн: дашборды ставок/выплат/edge/дисперсии.

Баг-баунти и сторонние аудиты: минимум два независимых аудита перед продом.

9) Соответствие требованиям (в т. ч. «гибридная» модель)

Гео-ограничения и возраст: обычно на фронтенде, но доступ к функциям контракта можно ограничивать списками (registry/allowlist).

KYC/AML для крупных сумм и партнёрских выплат: реализуют на уровне off-ramp и выплат из казначейства.

Налоги и отчётность: экспорт журналов ставок/выплат для игроков по их адресу.

10) Чек-листы

Технический:

RNG = VRF/commit-reveal с верификацией на цепи
Нет использования `blockhash` текущего блока
Reentrancy-guard, checks-effects-interactions
Лимиты экспозиции + circuit breaker
Proxy + timelock + мультисиг на апгрейды
Тесты на крайние случаи (max-win, массовые клеймы)

Операционный:

Публичная формула odds/edge
Логи/дашборды ончейн-метрик
Двойной аудит + баг-баунти
Процедура инцидент-респонд (пауза, план обновления)

UX/платежи:

Дешёвая сеть для мелких ставок (L2)
Стейблкоины и понятные комиссии
Клейм-модель для массовых выплат
Инструкции по сетям/тегам, тестовый перевод

11) Частые ошибки

RNG на blockhash/timestamp. Лёгкая мишень для манипуляций.

Выплаты внутри расчёта без защиты. Риск reentrancy.

Отсутствие лимитов экспозиции. Один крупный выигрыш может «сломать» банк.

Необдуманные апгрейды. Обновление логики без timelock и анонса — репутационный риск.

Игнорирование MEV. Ставки/settle в «голом» публичном мемпуле.

12) Мини-FAQ

VRF решает всё?

Нет. VRF даёт проверяемую случайность, но остаются риски MEV, лимитов ликвидности, ошибок логики и апгрейдов.

Можно ли полностью обойтись без оракулов?

Commit-reveal и мульти-партийные схемы уменьшают доверие к третьим сторонам, но сложнее в UX и требуют анти-отказной логики.

Как доказать игроку «provably fair»?

Покажите входные параметры и ссылку на ончейн-вызов, чтобы любой мог пересчитать исход: `random → outcome → payout`.

Крипто-казино на смарт-контрактах — это код как правило: прозрачные выплаты, воспроизводимая случайность, формализованные лимиты риска. Надёжная реализация держится на трёх китах: проверяемая случайность (VRF/commit-reveal), строгая безопасность (reentrancy/MEV/лимиты) и управляемые апгрейды (proxy+timelock+аудит). Если всё это соблюдено, игрок получает честную игру и предсказуемые выплаты, а оператор — устойчивый банк и доверие.