Разработка GambleFi-протокола (децентрализованные ставки)
Централизованные беттинг-платформы — это black box. Пользователь не знает, как на самом деле рассчитывается выигрыш, не может проверить что рандом честный, не имеет доступа к средствам когда платформа решает «заморозить» аккаунт. GambleFi решает ровно эти три проблемы: логика на смарт-контрактах открыта, случайность верифицируема, средства не кастодиальные.
Но построить честный протокол ставок на блокчейне технически сложнее, чем кажется. Главная проблема: все данные в блокчейне публичны и детерминированы. Откуда взять реальную случайность?
Главная техническая проблема: верифицируемая случайность
Почему нельзя использовать on-chain данные как рандом
block.timestamp, block.hash, block.difficulty — любой майнер/валидатор может их контролировать. Валидатор видит результат ставки заранее и может выбрать, включать ли транзакцию в блок. Это называется validator manipulation или block stuffing.
Использовать keccak256(block.timestamp + player_address) — ошибка, которую совершали первые казино-контракты 2017-2018 годов. Достаточно написать атакующий контракт, который вызывает целевое казино в том же транзакции и проверяет результат до финализации — откатывает если проиграл.
Chainlink VRF — стандартное решение
Chainlink VRF (Verifiable Random Function) предоставляет случайные числа с криптографическим доказательством честности. Процесс:
- Контракт запрашивает random через
VRFCoordinatorV2.requestRandomWords() - Chainlink node генерирует случайное число + proof
- Proof публикуется on-chain, верифицируется контрактом
-
fulfillRandomWords()вызывается с верифицированным числом
Задержка: 1-3 блока (20-60 секунд на Ethereum). Это неудобно для казино с мгновенными результатами — пользователь ждёт почти минуту. Для sporadic betting (раз в несколько минут) — приемлемо.
Стоимость: каждый VRF запрос стоит LINK токены. При высоком объёме транзакций — это существенная operational cost. Для протоколов с тысячами ставок в день нужно либо оптимизировать (батчинг нескольких ставок в один VRF запрос) либо рассматривать альтернативы.
Commit-reveal схема для быстрых игр
Для игр, где задержка в 30+ секунд неприемлема, используем commit-reveal:
- Игрок отправляет
commit = keccak256(secret + nonce)и ставку - Дилер (оператор протокола) коммитит своё
dealer_commit - Оба reveal свои secrets
- Результат =
keccak256(player_secret + dealer_secret)
Ни одна сторона не знает финального числа до reveal. Если дилер не ревилит (потому что проигрывает) — протокол возвращает ставку игроку через timeout. Если игрок не ревилит — ставка считается проигрышем.
Минус: дилер должен быть всегда онлайн, что добавляет centralization risk. Для полностью децентрализованного протокола — Chainlink VRF.
DRAND и commit-reveal с публичным рандомом
Drand — распределённая сеть для генерации публично верифицируемых случайных чисел. Раунды публикуются каждые 3 секунды (fastnet). Протокол может использовать будущий раунд Drand как источник рандома: принимаем ставки до блока N, используем drand раунд, соответствующий блоку N+5.
Менее популярен чем Chainlink VRF из-за сложности on-chain верификации, но есть реализации для EVM.
Модели протоколов
House LP (казино-пул)
Liquidity providers предоставляют ликвидность в пул. Пул — это «дом», который принимает ставки. При выигрыше игрока — пул платит. При проигрыше — пул забирает. LP получают долю house edge.
House edge — математическое преимущество. В рулетке ноль (0) даёт house edge ~2.7%. Протокол должен конфигурировать fair odds с учётом edge: если реальная вероятность выигрыша 50%, пayout должен быть меньше 2x (например, 1.98x) — разница и есть edge для LP.
Риски для LP: большой выигрыш одного игрока может опустошить пул. Решение — max bet = X% от pool TVL. При small TVL max bet маленький — это ограничивает attraction крупных игроков.
P2P ставки (peer-to-peer betting)
Игроки делают ставки друг против друга. Протокол — только матчинг и эскроу. House edge минимален (только комиссия протокола 1-2%).
Сложность: liquidity matching. Кто-то должен принять противоположную сторону ставки. Для нишевых событий (ставка на исход конкретного матча) — найти counterparty сложно. Для бинарных событий (да/нет) — проще.
Prediction markets (Polymarket, Augur) — это форма P2P betting на события реального мира. Используют LMSR (Logarithmic Market Scoring Rule) или AMM для автоматического market making без counterparty.
Контракты: ключевые компоненты
Game контракт: логика конкретной игры (dice, coinflip, roulette, lottery). Принимает ставку, запрашивает VRF, обрабатывает результат. Один контракт на тип игры.
House pool: ERC-4626 vault для LP ликвидности. Автоматически рассчитывает max bet на основе current TVL.
BetManager: хранит pending ставки до получения VRF. Связывает requestId Chainlink с конкретной ставкой.
Oracle/resolver: для prediction markets — механизм определения outcome. Самый сложный компонент. Chainlink Any API для публичных данных, мультисиг оракул для спорных результатов.
Anti-manipulation защиты
Front-running: игрок видит VRF запрос в mempool и может угадать результат до исполнения. Защита: блокировать ставки на тот же requestId после публикации запроса.
Flash loan attacks на house pool: если LP pool price зависит от on-chain балансов — атака на oracle. Решение то же, что для стейблкоинов: TWAP для расчёта house pool value, не spot.
Grief через unfulfilled commitments: в commit-reveal, если дилер не ревилит — игрок должен получить возврат. Таймаут должен быть разумным (не слишком коротким — дилер может быть offline, не слишком длинным — деньги заморожены надолго).
Правовые и compliance аспекты
GambleFi находится в серой зоне регулирования. В большинстве юрисдикций онлайн-гемблинг требует лицензии. Полная децентрализация (protocol без admin ключей, открытый frontend) снижает регуляторный риск для разработчиков, но не устраняет. Гео-блокировка через frontend (IP check) — стандартная практика для снижения рисков.
Ориентиры по срокам
Простая игра (coinflip) с Chainlink VRF на testnet — 3-5 дней. Полноценный протокол с house pool, несколькими играми, LP токеном и дашбордом — 2-3 месяца. Prediction market с oracle механикой — отдельная оценка из-за сложности dispute resolution. Аудит обязателен для любого протокола с пользовательскими средствами. Стоимость рассчитывается после выбора игровой механики и архитектуры.