Як перевірити раунд Provably Fair

Provably fair — це можливість перевірити результат постфактум, а не вірити на слово. Платні міні-ігри Gift Club побудовані на стандартній схемі commit-reveal з HMAC-SHA256, і всі дані, потрібні для самостійного перерахунку раунду, доступні просто в застосунку. Нижче — як це зробити і, що не менш важливо, яку частину Gift Club ця схема не покриває.

1. Що насправді гарантує provably fair

Гарантія рівно одна, вузька й цінна: оператор зафіксував результат до твоєї гри й не міг змінити його заднім числом.

Механізм — це зобов’язання. Перед ставкою сервер генерує таємний серверний сид і публікує його SHA-256-хеш. Хеш нічого не каже про сам сид, але фіксує його: після публікації підмінити сид уже не вийде — хеш не зійдеться. Коли сид згодом розкривається, ти хешуєш його сам(а) й переконуєшся, що це той самий сид, зафіксований ще до появи твоєї ставки.

Чого схема не гарантує: що гра щедра, що шанси хороші або що тобі заплатять. Гра може бути ідеально перевірюваною й водночас повертати 40%. Перевірюваність і RTP — це різні питання, і ставити треба обидва.

2. Три вхідні значення

Будь-який результат у платній грі Gift Club — чиста функція від трьох значень. Жодного прихованого четвертого входу, серверного годинника чи випадковості, доданої після фіксації.

Ці три значення йдуть у HMAC-SHA256 з ключем на серверному сиді та повідомленням clientSeed:nonce:round. Лічильник round починається з 0 і збільшується на кожні потрібні 32 байти — так гра, якій треба більше (наприклад, розкладка поля з 25 клітинок), продовжує черпати з того самого зобов’язання.

Байти перетворюються на числа по чотири, як дріб за основою 256:

Це та сама конструкція, яку задокументував Stake і яку використовує більшість перевірених реалізацій. Власну схему ми навмисно не вигадували: оригінальну тобі не було б із чим звірити.

3. Як перевірити раунд самому

Зробити це можна двома способами. Швидкий — просто в застосунку; консольний сніпет нижче для тих, хто не хоче вірити на слово навіть нашій власній перевірці.

У застосунку

Відкрий будь-яку платну гру, натисни щит поряд із назвою та розгорни «Перевірити раунд». Розкритий сид, твій клієнтський сид і nonce підставляться самі, але всі поля залишаються редагованими — можна перевірити будь-який раунд, а не лише той, що на екрані.

Перевірка виконується у твоєму браузері. SHA-256 і HMAC-SHA256 обчислюються локально через Web Crypto API — нам нічого не надсилається, тож результат не залежить від нашої чесності в момент натискання кнопки. Якщо зобовʼязання не збіглося, розіграш не показується взагалі: сид, який не збігся з опублікованим хешем, не описує жодного раунду.

У консолі

Спершу виконай ротацію сидів — вона розкриє серверний сид, що діяв для вже зіграних раундів. Потім візьми розкритий серверний сид, свій клієнтський сид і nonce потрібного раунду та виконай це в будь-якій JavaScript-консолі:

const crypto = require("crypto");

// Із застосунку: Профіль → Provably Fair → Історія сидів
const serverSeed = "<розкритий серверний сид, hex>";
const clientSeed = "<твій клієнтський сид>";
const nonce      = 0;      // раунд, який перевіряєш

// 1. Переконайся, що сид збігається з хешем, показаним ДО гри.
const commitment = crypto
  .createHash("sha256")
  .update(Buffer.from(serverSeed, "hex"))
  .digest("hex");
console.log("commitment:", commitment);   // має збігтися з опублікованим хешем

// 2. Перезбери байти раунду.
const hmac = crypto
  .createHmac("sha256", Buffer.from(serverSeed, "hex"))
  .update(`${clientSeed}:${nonce}:0`)
  .digest();

// 3. Перетвори перші чотири байти на число в діапазоні [0, 1).
const float =
  hmac[0] / 256 +
  hmac[1] / 65536 +
  hmac[2] / 16777216 +
  hmac[3] / 4294967296;
console.log("first float:", float);

Ключовий — перший крок. Якщо обчислений commitment не збігається з хешем, який застосунок показав до раунду, сид підмінили, і решту цієї сторінки читати немає сенсу. Якщо збігається — байти з кроку 2 єдині, які цей раунд міг використати.

Повна історія сидів — кожен виведений з обігу серверний сид, його хеш і діапазон nonce — доступна за адресою GET /api/games/{gameType}/seed-history та в застосунку в розділі Provably Fair.

4. Ротація сидів

Ротація робить дві речі одночасно: розкриває серверний сид, проти якого ти грав(ла), і фіксує новий. Nonce скидається до 0.

• Змінюй клієнтський сид коли завгодно. Новий клієнтський сид змінює всі подальші результати, а оскільки хеш серверного сида опубліковано заздалегідь, підлаштуватися під твій вибір ми не можемо.
• Спершу ротація, потім перевірка. Активний серверний сид ніколи не розкривається — інакше будь-хто зміг би обчислити майбутні результати, а саме це схема й має унеможливлювати.
• Ротація не змінює шанси. Вона змінює, які результати ти отримаєш, а не наскільки вони добрі. Порада «крутити сид, доки не випаде» — це помилка гравця, а не стратегія.

5. Чого схема не покриває

Саме цей розділ більшість операторів оминає, тож скажемо прямо.

Відкриття подарункових кейсів, скретч-картки й Колесо призів не є provably fair. Коли ти відкриваєш кейс, стираєш картку або крутиш Колесо призів у вкладці «Кейси», який приз тобі дістанеться, визначає інший рушій — із динамічними індивідуальними вагами, тими самими модифікаторами XP і удачі, про які ми пишемо в розборі механік подарункових ігор. Ці ваги не входять до зобов’язання, і відновити результат кейса, картки чи колеса зі своїх сидів не вийде. Сид у карток і колеса є, але він лише розкладає сітку або задає, де зупиниться колесо, навколо вже обраного призу.

У міні-іграх сиди визначають розкладку, а не удачу. Сид задає, де стоять міни, куди відскочить кулька в Plinko, які числа випадуть у Keno — геометрію раунду. У Minefield це буквально і є вся гра: розкладка клітинок і є результатом. В іграх, де призовий рівень обирає окремий розіграш, гарантія вужча.

Тому точне формулювання таке: раунди платних міні-ігор Gift Club перевірювані, відкриття кейсів, скретч-картки й обертання Колеса призів — ні. Якщо конкурент заявляє «provably fair» про весь гача-застосунок без такого застереження, ця заява або означає менше, ніж звучить, або неправдива.

Ще два обмеження, спільні для будь-якої provably fair системи, не лише нашої:

• Вона не робить гру прибутковою. Перевірений раунд усе одно може бути програшним, а перевага закладу застосовується до кожної ставки.
• Вона не гарантує виплату. Перевірка доводить, що результат не підробили. Про те, чи виконає оператор виведення, вона не каже нічого — це окреме питання, і оцінювати його треба окремо.

6. Часті питання

Чи може Gift Club побачити мій клієнтський сид до вибору серверного?

Ні, і саме порядок дій це забезпечує. Серверний сид генерується, а його хеш публікується до раунду; твій клієнтський сид підмішується пізніше. Зміна клієнтського сида будь-якої миті знецінює будь-які попередні розрахунки.

Чому серверний сид прихований, поки я граю?

Бо, знаючи його та твій клієнтський сид, будь-хто обчислить усі майбутні результати. Розкриття під час ротації — стандартне рішення: доказ ти отримуєш, але лише для вже завершених раундів.

Які ігри покриті?

Кожна платна міні-гра з каталогу ігор: якщо гра приймає ставку в зірках, її раунд можна перевірити. В іграх лише на XP перевіряти нічого — ставки немає.

Що робити, якщо перевірка не сходиться?

Надішли нам серверний сид, клієнтський сид і nonce. Розбіжність — це або баг з нашого боку, або помилка у вхідних даних: найчастіше це nonce (він рахується з нуля) або серверний сид, захешований як текст, а не як hex-байти.

Provably fair — це те саме, що ліцензія чи аудит ГВЧ?

Ні. Provably fair — самостійна перевірка окремих раундів. Сертифікація генератора випадкових чисел у лабораторії на кшталт iTech Labs чи BMM Testlabs — незалежна перевірка всієї системи, а ліцензія — дозвіл регулятора. Це відповіді на різні питання, і одне не замінює інше.

Читати далі

• «Ігри в Telegram з RTP 95% і без KYC» — друга половина питання: перевірювана не означає щедра.
• «Індекс RTP ігор Telegram» — опублікована віддача за кожною грою.
• Minefield — гра, де розкладка за сидом безпосередньо і є результатом.
• Gift Club у Telegram — панель Provably Fair є у профілі.