Крипто-казино
Torrent Gear
Що таке Provably Fair і як перевірити чесність гри
Що таке Provably Fair (PF)
Provably Fair - це протокол, що дозволяє криптографічно перевірити, що результат раунду був випадковим і не міг бути підмінений оператором після ставки.
Ідея: спочатку публікується коміт (хеш прихованого server seed), потім після ставки розкривається ревіл (сам server seed), і будь-хто може звірити хеш і відтворити RNG, враховуючи client seed гравця і ідентифікатори раунду.
Базовий протокол: commit → bet → reveal
1. Commit: до початку раундів сервер генерує випадковий'server _ seed'і публікує його хеш:
commit = SHA-256(server_seed salt )//або Keccak-256Коміт можна вивести в історію/блокчейн/журнал.
2. Ставка: гравець вибирає або підтверджує свій'client _ seed'( з UI або власний), відправляє ставку з:
client_seed, roundId, nonce
SHA-256(server_seed salt) = = commit//перевірка цілісності
rng = HMAC-SHA256(key=server_seed, msg=client_seed roundId nonce)
//або rng = SHA-256 (server_seed client_seed roundId nonce)5. Маппінг в результат: перетворюємо «rng» в діапазон гри без зміщення (див. нижче).
Як отримати число без зміщення (bias-free)
Неправильно брати'rng% N'- це дає модульне зміщення, якщо 2 ^ k не кратно N. Правильно - rejection sampling:pseudo
// rng_bytes = 32 байта хешу → uint256 x = uint256 (rng_bytes)
limit = floor(2^256 / N) N while x >= limit:
rng_bytes = SHA-256 (rng_bytes )//« перемішати »ще раз детерміновано x = uint256 (rng_bytes)
result = x % NТак отримуємо рівномірний розподіл за N наслідками (комірки рулетки, символи барабана тощо).
Міні-приклад (покрокова верифікація гравцем)
Припустимо:
server_seed = «b2c6... e9 »//розкритий після раунду (hex/utf8)
client_seed = «my-client-seed »//обраний мною roundId =« R-2025-10-17-001 »
nonce = 42 commit = «c9a1... f3 »//опубл. заздалегідь1) Перевірити коміт
Порахувати'SHA-256 (server_seed)'і переконатися, що збігається з'commit'.
2) Детермінований RNG
Порахувати:
rng = HMAC-SHA256(key=server_seed, msg= client_seed ":" roundId ":" nonce)3) Перетворення в результат
Для рулетки (37 чисел) → N = 37, застосувати rejection sampling і взяти'x% 37'.
Для слота: використовувати кілька порцій RNG для визначення барабанів/символів згідно таблиці розподілів.
4) Звірити з результатом в історії
Майданчик повинен показувати ті ж вхідні, які використовувалися в розрахунку: `server_seed`, `client_seed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVersion`.
Альтернатива/посилення: VRF (Verifiable Random Function)
Замість коміту оператор може (або додатково) використовувати VRF:1. Смарт-контракт або публічний реєстр запитує у провайдера'VRF (seed)'.
2. Публікується «(random, proof)».
3. Будь-хто може перевірити «proof» тією ж публічною ключовою парою VRF.
4. Далі - ті ж кроки маппінгу RNG в результат.
Плюси: менше довіри до оператора. Мінуси: залежність від VRF-провайдера/ланцюга і можлива вартість.
Як казино має впроваджувати PF коректно
Договір (контракт даних PF)
Поля в історії раунду:- `serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
- Значення - у WORM-сховищі (immutable), зі штампами часу (UTC).
Генерація сидів
'server _ seed'генерується криптостійким PRNG (OS CSPRNG/HSM).
Сиди ніколи не повинні повторюватися між серіями (ротація).
«client _ seed» - вибирається гравцем або генерується на клієнті і підтверджується.
Публікація комітів
Коміти доступні до ставок (історія, RSS, on-chain-якір).
Для лотів можна використовувати мерклі-дерево комітів з щоденною публікацією кореня.
Розкриття (reveal)
Перед публікацією результату'server _ seed'розкривається і логується.
Для серії раундів на одному сиді - розкриття після кінця серії (вказати політику заздалегідь).
Прозорий маппінг
Версія алгоритму маппінгу ('mappingVer') фіксується.
Будь-яка зміна ('mappingVer '/' rngAlgo') - тільки з анонсом і новою серією комітів.
Аудит і суперечки
Сирі входи + запис обчислень зберігаються; при суперечці генерується звіт: входи → RNG → mapping → результат.
Стріми/Live: зберігати хеш-якоря подій CV/RFID, відео - в WORM.
Як гравцеві перевірити чесність (чек-лист)
1. Відкрийте історію раунду і скопіюйте: `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`.
2. Порахуйте хеш'serverSeedReveal'і порівняйте з'serverSeedHash'.
3. Порахуйте RNG за вказаним алгоритмом (HMAC/Hash + входи).
4. Застосуйте «беззміщений» мапінг (rejection sampling) до числа результатів.
5. Переконайтеся, що результат збігається з показаним.
6. Якщо заявлена VRF - перевірте'proof'( кнопка «Verify» або незалежний скрипт/блок-експлорер).
Типові помилки (анти-патерни)
'rng% N'без rejection sampling → зміщені ймовірності.
Прихований або мінливий'client _ seed'( генерується сервером без участі гравця).
Перегенерація'server _ seed'після ставки (коміт змінюється заднім числом).
Непрозорі зміни алгоритмів без версії/публікації.
Повтор сидів між серіями.
Відсутність WORM/штампів часу - не можна довести порядок подій.
Змішування PF і бізнес-логіки (наприклад, бонус застосований так, що змінює простір результатів, але це не описано в'mappingVer').
FAQ (коротко)
Чи можна перевірити слоти, а не тільки рулетку?
Так. PF застосовують до послідовності виборів (наприклад, індекс символу на барабані). Важливо, щоб таблиці ймовірностей і порядок читання RNG були задокументовані.
А якщо я ввів свій'client _ seed', оператор все одно може «підібрати»'server _ seed'?
Ні, якщо коміт був опублікований до ставки. Він фіксує'server _ seed'і не дає замінити його заднім числом.
Чому іноді розкривають сиди пакетно?
Щоб не було можливості «перебирати» сід в серії. Це допустимо, якщо коміт опублікований заздалегідь, а політика розкриття - прозора.
Міні-референс форматів
Хеші: SHA-256 або Keccak-256.
RNG: HMAC-SHA256 (серверний сід як ключ) або SHA-256 конкатенації.
Ідентифікатори: 'roundId'( UTC-штамп + гра + інкремент),'nonce'( лічильник ставок в серії).
Версії: `rngAlgo=HMAC-SHA256@1`, `mappingVer=roulette. v2`, `calcVer=wallet-7. 2`.
Чек-лист впровадження PF для оператора
Криптографія та сиди
- CSPRNG/HSM; унікальні'server _ seed', документована ротація.
- 'client _ seed'- керований гравцем, зберігається в історії.
Публікації та зберігання
- Коміти до ставок, доступ до історії/каналу публікацій/якоря.
- WORM-сховище, UTC-штампи, мерклі-батчі для масштабів.
Алгоритми
- RNG і mapping без зміщення; версіонування'rngAlgo/mappingVer'.
- Скрипт/сторінка «Перевірити чесність» (open-source бажаний).
Live і гібрид
- Хеш-якоря CV/RFID/фаз раунду, журнал «коли закрили вікно ставок».
- Процедури спору (звіт vkhodov→iskhod, посилання на коміти/VRF).
Безпека та аудит
- Незалежний аудит протоколу PF, баг-баунті.
- Логи рішень незмінні; регулярні тести відтворення.
Provably Fair перетворює «повірте нам» в «перевірте самі». З коміт/ревіл або VRF, детермінованим RNG і коректним маппінгом без зміщення будь-який раунд стає відтворюваним і перевіряється. Для гравця - це прозорість і довіра. Для оператора - менше суперечок, сильніше бренд і відповідність вимогам регуляторів. Головне - дисципліна: публікувати коміти заздалегідь, фіксувати версії алгоритмів, зберігати докази незмінно і давати користувачеві простий інструмент перевірки.