Розроблення GambleFi-протоколу (децентралізовані ставки)
Централізовані беттинг-платформи — це чорний ящик. Користувач не знає, як насправді розраховується виграш, не може перевірити що рандом чесний, не має доступу до коштів коли платформа вирішує «заморозити» акаунт. 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 - Обидва ревелять свої 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%, payout повинен бути менше 2x (наприклад, 1.98x) — різниця це edge для LP.
Ризики для LP: великий виграш одного гравця може опустошити пул. Рішення — max bet = X% від pool TVL. При малому TVL max bet малий — це обмежує привабливість для крупних гравців.
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. Пов'язує Chainlink requestId з конкретною ставкою.
Oracle/resolver: для prediction markets — механізм визначення результату. Найскладніший компонент. Chainlink Any API для публічних даних, мультисиг оракул для спірних результатів.
Anti-manipulation захисти
Front-running: гравець бачить VRF запрос у мемпулі та може угадати результат до виконання. Захист: блокування ставок на той же requestId після публікації запроса.
Flash loan атаки на 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. Аудит обов'язковий для будь-якого протоколу з користувацькими коштами. Вартість розраховується після вибору ігрової механіки та архітектури.