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

Смарт-контракты переводят логику казино из «чёрного ящика» на просматриваемый код в блокчейне. Ставки, коэффициенты, house edge, случайность и выплаты фиксируются в ончейн-событиях — их можно проверить. При этом казино может быть полностью on-chain или гибридным (часть логики — вне цепи). Ниже — как это устроено на практике.

1) Базовая архитектура

Контракт банка/кассы (Vault/Bankroll). Хранит ликвидность, принимает депозиты/выдаёт выплаты, применяет лимиты и комиссии.

Игровые контракты (Games). Правила конкретных игр: рулетка, дайс, crash, слоты, кости, coinflip, Plinko.

Модуль случайности. Источник случайных чисел: commit-reveal, VRF (верифицируемая случайность), реже — собственные схемы с многосторонним раскрытием.

Оракулы/сервисы. Для VRF или коэффициентов; вызываются транзакцией и возвращают доказуемый результат.

Модуль аффилиатов/бонусов. Хранит реферальные проценты, кешбэк, вейджер-условия.

2) Жизненный цикл ставки (по шагам)

1. Депозит. Игрок отправляет токен/монету в кассу или делает «разрешение» (approve) на списание контракта.

2. Создание ставки. Вызов функции `placeBet(...)` с параметрами игры (сумма, выбор, лимит риска, slippage для коэффициентов, канал VRF).

3. Фиксация условий. Контракт записывает ставку в состояние и генерирует событие `BetPlaced` (адрес, сумма, игра, timestamp).

4. Получение случайности.

Commit-reveal: казино заранее публикует хэш секрета, позже раскрывает его. Игрок/контракт проверяет соответствие.

VRF: контракт запрашивает у провайдера случайное число + криптодоказательство, которое проверяется ончейн.

5. Розыгрыш. Функция `settleBet(...)` вычисляет исход, проверяет коэффициент/house edge и считает выигрыш.

6. Выплата. Контракт переводит приз на адрес игрока (событие `Payout`). Опционально удерживает комиссию/налог, обновляет лимиты.

7. Логи и метрики. Все шаги идут в события (`BetSettled`, `RandomnessRequested/Fullfilled`, `JackpotHit`) — их можно анализировать дашбордом.

3) Случайные числа и «provably fair»

Commit-reveal. Оператор публикует хэш секрета (commit); после ставки раскрывает секрет (reveal). Контракт проверяет хэш → исключает подмену задним числом. Часто добавляют соль игрока (client seed) + соль сервера (server seed), чтобы обе стороны влияли на результат.

VRF (Verifiable Random Function). Ончейн-верификация доказательства: контракт убеждается, что число действительно случайно и получено из заявленного источника.

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

4) Управление банком и house edge

Лимиты. Максимум на ставку/игрока/раунд, дневные капы, анти-вэйл защита.

House edge. Закодирован в правилах игры (например, 1–3% у дайс/коинфлип, выше — у слотов).

Джекпоты. Накопительный пул с долей от каждой ставки; условия триггера фиксированы в коде.

Кросс-токены. Контракт может принимать несколько активов; цены нормализуют через оракулы (риски: задержки и манипуляции).

5) Бонусы, вейджер и реферальные выплаты

Бонус-баланс. Хранится отдельно от «реальных» средств; вывод разрешён после выполнения вейджера (например, x20).

Стейт-машина бонусов. Состояния: `Granted → Active → Locked → Cleared/Forfeited`. Условия и переходы прозрачны в коде.

Аффилиаты. Проценты от чистой прибыли/оборотки записываются событием; выплаты — периодически из кассы.

6) Полностью on-chain vs гибридная модель

Полностью on-chain. Вся логика в смарт-контрактах (прозрачность на максимум; минусы — газ, задержки, нагрузка).

Гибрид. Ставка/выплата on-chain, а тяжёлая логика и интерфейс — off-chain; результат подтверждается VRF/подписью. Это снижает газ и улучшает UX.

7) Риски и как их закрывают

MEV/фронт-раннинг. Злоумышленник пытается вставить свою транзакцию между ставкой и розыгрышем. Меры: отложенное раскрытие, коммит-схемы, приватные мемпулы, батч-сеттеры.

Оракульные риски. Задержки/отказ/манипуляция источника. Меры: проверка доказательств, резервные каналы, лимиты на зависимые игры.

Апгрейды и доверие. Часто используют прокси-паттерн (Upgradeable). Нужно Timelock + мультисиг для смены логики и белый список ролей (`owner`, `pauser`, `treasurer`).

Ошибки в коде. Аудиты, баунти-программы, формальная верификация критичных частей.

Ликвидность. Банку нужны буферы под максимальные выигрыши, иначе выплаты задержатся.

Газ и UX. На L1 ставки могут быть дорогими. Решения: L2, метатранзакции, батчинг, агрегаторы газа.

Комплаенс. Блокировки по странам, лимиты, self-exclusion, проверка возраста — часто реализованы off-chain, но «флаги» хранятся в контракте.

8) Что может проверить игрок (самостоятельно)

Адреса контрактов. Сверьте в интерфейсе и обозревателе сети; проверьте верифицированный исходник.

События. Посмотрите `BetPlaced/Settled`, соответствуют ли суммы и коэффициенты интерфейсу.

Случайность. Есть ли commit-reveal/VRF, публикуются ли хэши и раскрытия, валидируются ли доказательства.

Роли и апгрейды. Кто владелец? Есть ли `Timelock`, мультисиг, `pause`?

Лимиты и банк. Размер кассы, дневные лимиты выплат, частота срабатывания джекпота.

Approve/разрешения. Отзывайте лишние `approve/permit` после игры.

9) Что должен сделать оператор (минимум)

Аудит и тестнет. Публичный отчёт, развертывание на тестовой сети, баунти.

Timelock + мультисиг. Любые апгрейды — только через задержку и коллективную подпись.

Мониторинг. Ончейн-алерты по ликвидности, VRF-ответам, аномалиям ставок/выплат.

Резерв по ликвидности. Буферы под худшие сценарии, стратегии ребалансировки.

Прозрачность. Публичные адреса, документация, формулы коэффициентов, политика бонусов/вейджера.

Защита игроков. Лимиты, таймауты, self-exclusion, KYC там, где требует закон.

10) Частые вопросы

Можно ли «подкрутить RNG»? При корректном commit-reveal/VRF — нет: любое отклонение видно по доказательствам. Риск — только в неверной интеграции.

Зачем нужен прокси/апгрейд? Для исправления багов и добавления игр. Но апгрейд должен быть с Timelock и мультисигом.

Почему иногда игра «дорогая»? Газ L1. Играйте на L2/в периоды низкой нагрузки или используйте проекты с батчингом.

Чем гибрид хуже полного on-chain? Больше доверия к бэкенду, зато дешевле/быстрее. Компенсация — VRF, прозрачные логи и жёсткие лимиты.

11) Чеклист игрока

Контракт и исходник верифицированы, адреса совпадают с сайтом.
Есть commit-reveal/VRF и публичные события розыгрыша.
Видны лимиты ставок, касса достаточна для выплат.
Разрешения `approve` ограничены суммой/временем; лишние — отозваны.
Тестовая ставка прошла корректно.

12) Чеклист оператора

Аудит/баунти/тестнет пройдены; критичные пути покрыты тестами.
Timelock, мультисиг, роли `pauser/treasurer` разделены.
VRF/commit-reveal реализованы правильно, сиды ротируются.
Лимиты/капитализация банка адекватны рискам.
Документация и адреса контрактов опубликованы, поддержка отвечает.

Смарт-контракты делают казино проверяемым: правила зашиты в код, случайность — доказуема, выплаты — прозрачны. Главное — правильная архитектура (RNG, банк, апгрейды, лимиты) и дисциплина безопасности. Игроки получают проверяемость и быстрые выплаты, операторы — автоматизацию и доверие аудитории. Баланс между «чистым» on-chain и гибридом выбирают исходя из газа и UX, но в обоих случаях фундамент — открытые контракты и воспроизводимые доказательства честности.