Как проверить Provably Fair: от сохранённого хэша до результата

Чтобы проверить Provably Fair, сделай две отдельные проверки: сначала сравни хэш раскрытых данных с хэш-обязательством, сохранённым до ставки, затем воспроизведи результат по точному протоколу провайдера. Совпадение хэшей само по себе не подтверждает исход игры, выплату или правильность всех действий в раунде.

Provably Fair — это механизм, который позволяет проверить связь заранее зафиксированных данных с раскрытыми данными и повторить предусмотренный протоколом расчёт. Это не сертификат и не лицензия. Если нужен обзор принципа, начни с объяснения Provably Fair; ниже — процедура проверки с повторяемым примером.

В каком порядке проводить проверку

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

1. Установи провайдера, игру и версию протокола. Названия игры недостаточно: нужны правила формирования входных данных и преобразования результата.
2. До ставки сохрани полное хэш-обязательство и доступные входные данные. Зафиксируй время, идентификатор раунда и источник записи. Для проверки не нужно специально делать новую ставку.
3. Сохрани данные именно проверяемого раунда. Это могут быть старый клиентский сид, nonce (счётчик), настройки игры и история действий. Текущая пара сидов не заменяет старую.
4. Заверши активные игры, если этого требует провайдер. Раскрывай выведенный из использования серверный сид или другие данные по его протоколу.
5. Проверь хэш-обязательство. Хэшируй ровно те данные и тем способом, которые указаны в документации.
6. Воспроизведи результат и отдельно проверь расчёт выплаты. Используй все входные данные, точное преобразование и историю действий.
7. Запиши границы вывода. Например: «Хэш совпал; результат не воспроизведён, поскольку отсутствует история раздачи».

Не смешивай хэширование с шифрованием: раскрытый серверный сид не получают «расшифровкой хэша». SHA-256 — хэш-функция, описанная в стандарте NIST.

Какие данные нужно сохранить

Сохраняй полные строки и данные старого раунда, а не только снимок зелёного уведомления. Для повторной проверки важны и содержимое, и момент фиксации.

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

Nonce (счётчик) определяется провайдером. Это не обязательно идентификатор раунда, не позиция в потоке байтов и не счётчик блоков HMAC. Разницу между игровыми сидами разбирает руководство о клиентском и серверном сидах.

Как пользоваться проверкой самого провайдера

Используй документированный путь для конкретного сервиса: у Shuffle это смена пары сидов после завершения активных игр, затем возврат к старой ставке и её проверка.

Согласно инструкции Shuffle, последовательность такая:

1. Заверши активные игры.
2. Открой управление сидами и выполни смену пары.
3. Вернись к старой ставке в истории.
4. Открой её проверку и используй раскрытый старый серверный сид вместе со старым клиентским сидом и nonce (счётчиком).

Не подставляй новую пару вместо старой и не делай депозит или новую ставку ради проверки. Это пересказ документированного пути, а не проверка на реальном аккаунте. Если интерфейс отличается, уточни актуальный порядок у провайдера: само отличие не является признаком мошенничества.

Протоколы могут различаться принципиально. Например, BGaming описывает фиксацию данных результата и секрета для отдельного раунда. Его элементы интерфейса «Next Game» и «Last Game» относятся соответственно к следующей и предыдущей игре. Этот порядок нельзя автоматически заменить процедурой ротации серверного сида другого провайдера.

Как повторить опубликованный пример BGaming

Для этого примера нужно вычислить SHA-256 полной строки данных, а не отдельного числа или секрета. Затем сравнить полученный хэш с опубликованным значением.

На странице BGaming приведён опубликованный учебный пример рулетки. Это не наша ставка и не запись проверенного нами завершённого раунда.

Фрагмент официальной страницы BGaming с данными опубликованного учебного примера рулетки

На снимке виден абзац из официального источника на английском языке со строкой JSON для AmericanRoulette, содержащей Result и Secret.

Точная компактная строка JSON для повторения примера:

{"server":2,"game":"AmericanRoulette","secret":"290fb3c9fbfc2afa5339bf27e5c25cbb"}

Её полный хэш SHA-256:

f88e5c0943740b0269b21347fa26c59b1717ee200584ac40e1c56edd49ad82b8

На странице источника используются типографские кавычки. Приведённая выше компактная строка с обычными кавычками ASCII воспроизводит опубликованный хэш. Это не разрешение исправлять или нормализовать собственную выгрузку раунда: для неё нужно точное представление данных для хэширования, включая пробелы, порядок полей и кодировку UTF-8.

Поле server в этом примере содержит исходный результат 2, а не серверный сид. Отдельно источник показывает клиентское значение 5 и итоговый результат 7: в опубликованном примере 2 + 5 = 7. Здесь нет примера перехода через границу диапазона, поэтому из него нельзя выводить универсальное правило или правило остатка от деления.

Как ввести пример в инструмент ToolsGambling

В инструменте проверки Provably Fair вставь ожидаемый хэш и полную строку JSON; в этом сценарии проверяется только SHA-256 строки.

Английские подписи полей сохраняются и в русской версии интерфейса:

1. В поле «SERVER SEED HASH» вставь полный ожидаемый хэш из примера.
2. В поле «SERVER SEED» вставь всю строку JSON. Здесь поле служит для хэширования произвольного текста с помощью SHA-256: данные BGaming — это полная строка исходных данных, а не отдельный серверный сид.
3. Поле «CLIENT SEED» оставь пустым.
4. В поле «NONCE» (счётчик) укажи 0.
5. Нажми кнопку «ПРОВЕРИТЬ ХЕШ».

Поля инструмента с ожидаемым хэшем BGaming, полной строкой данных, пустым клиентским сидом и nonce со значением 0

Снимки инструмента в этой статье сделаны на фактической локальной сборке, а не на рабочем сайте и не при проверке аккаунта или реальной ставки.

Результат проверки с совпадающими полными хэшами опубликованного примера BGaming

Зелёное уведомление означает совпадение хэшей. Даже если интерфейс называет игру честной, здесь подтверждается только соответствие введённой строки ожидаемому хэшу.

Инструмент в этой проверке не вычисляет итоговый результат BGaming 7. Если рядом отображаются производные игровые значения, это учебные расчёты инструмента, а не автоматическое подтверждение результата провайдера. Описанное источником преобразование 2 и 5 в 7 остаётся отдельной частью примера.

Как проверить ту же строку независимо

Вычисли SHA-256 через встроенный модуль crypto в Node.js: дополнительные пакеты, установка зависимостей и секретные данные не нужны. Нужна только уже доступная среда Node.js.

const { createHash } = require('node:crypto');

const payload = '{"server":2,"game":"AmericanRoulette","secret":"290fb3c9fbfc2afa5339bf27e5c25cbb"}';
const expected = 'f88e5c0943740b0269b21347fa26c59b1717ee200584ac40e1c56edd49ad82b8';
const computed = createHash('sha256').update(payload, 'utf8').digest('hex');

console.log(computed);
console.log(computed === expected);

Сохрани код в файл verify-bgaming.cjs и выполни команду:

node verify-bgaming.cjs

Расширение .cjs позволяет использовать require в режиме CommonJS, даже если в проекте включён режим ES-модулей. Код выведет полный хэш, приведённый выше, и true. Он проверяет только хэш-обязательство опубликованного примера; он не воспроизводит игру и не рассчитывает выплату.

Не вставляй в подобные инструменты фразу восстановления кошелька. Игровой сид и фраза восстановления кошелька — разные данные.

Почему для воспроизведения результата нужен точный протокол

Одинаковые названия сидов не означают одинаковый расчёт. Для воспроизведения результата нужны точные ключ, сообщение, алгоритм и преобразование полученных байтов.

Например, в реализации Stake поток байтов строится через HMAC-SHA256:

• ключ — серверный сид;
• сообщение в UTF-8 имеет вид:

  ${clientSeed}:${nonce}:${currentRound}
  

• currentRound — счётчик блоков HMAC, вычисляемый как Math.floor(cursor / 32);
• cursor — позиция в потоке байтов, а не nonce (счётчик).

Третий компонент сообщения нельзя пропускать. Это описание документированного формата, а не проверка какой-либо исторической ставки.

В описании преобразований Stake дробное число формируется из четырёх байтов: складываются значения byte[i] / 256^(i+1) для i от 0 до 3. Дальнейшее преобразование зависит от игры. Этот шаг не задаёт универсальный алгоритм рулетки, игры в кости или игры с растущим множителем.

Проверка также не доказывает, что сервер не мог рассчитать результат после получения всех необходимых входных данных. Её задача уже: установить соответствие заранее сохранённому обязательству и повторить документированный расчёт.

Что подтверждают встроенные проверяющие блоки

Встроенный блок ниже позволяет сравнить SHA-256 и посмотреть учебный расчёт HMAC, но не заменяет проверку полного протокола провайдера. Его зелёный вердикт определяется совпадением хэша.

Здесь сообщение для учебного HMAC имеет вид client:nonce, с выбором HMAC-SHA256 или HMAC-SHA512. Это не тот полный формат, который описан выше для Stake. Расчёты игры в кости и краш-игры — демонстрация преобразований, а не подтверждение результатов Aviator, Stake или другого провайдера. Универсальное название блока не расширяет его возможности.

Блок для блэкджека ниже тоже имеет учебную область применения: он проверяет SHA-256 и показывает частичную демонстрацию с HMAC-SHA512 для одной колоды.

Зелёный вердикт здесь означает совпадение хэшей. Он не подтверждает полную последовательность карт реального провайдера, все действия игрока или расчёт выплаты. Для воспроизведения реальной раздачи нужны модель колоды, правила выдачи карт и полная история действий.

Какие дополнительные данные нужны для разных игр

Набор данных определяется конкретной игрой и её версией. Одной пары сидов и nonce (счётчика) может быть недостаточно.

Не переноси формулу одной игры на все игры бренда. Если документация не раскрывает необходимое преобразование, фиксируй результат как невоспроизведённый, а не подбирай формулу под известный ответ.

Что делать, если хэш или результат не совпадает

Сначала проверь исходные данные и точность строки. Несовпадение требует диагностики, но само по себе не доказывает мошенничество.

Входные строки чувствительны к регистру: замена буквы может изменить хэш. При этом регистр букв в отображении ожидаемого шестнадцатеричного хэша может игнорироваться. В основном инструменте ToolsGambling также игнорируются внешние пробелы у ожидаемого хэша, но не изменения в самой строке для хэширования.

Как увидеть несовпадение из-за одного пробела

Добавь ровно один пробел ASCII после первой запятой в опубликованном примере. Получится другая строка и другой хэш, хотя смысл JSON останется тем же.

{"server":2, "game":"AmericanRoulette","secret":"290fb3c9fbfc2afa5339bf27e5c25cbb"}

Её полный SHA-256:

64711caedf7f2156f8504bcd7f0087ec1233d98f6246892b7d854802dc050a6e

Для повторения в коде выше замени только значение payload этой строкой, оставив expected прежним. Код выведет новый хэш и false.

Для проверки в инструменте оставь исходный ожидаемый хэш и замени только строку в поле «SERVER SEED» — это название элемента интерфейса. Снова нажми «ПРОВЕРИТЬ ХЕШ».

Несовпадение хэшей после добавления одного пробела ASCII после первой запятой в строке данных BGaming

Один дополнительный пробел меняет байты исходной строки и её хэш. Исходный компактный пример совпадает с опубликованным значением; вариант с пробелом — нет.

Как сохранить расхождение и обратиться за уточнением

Собери воспроизводимые доказательства и запроси недостающий протокол или выгрузку. Не создавай новые ставки ради диагностики.

Сохрани:

• старое хэш-обязательство, время фиксации и идентификатор раунда;
• точную выгрузку раскрытых данных, старый клиентский сид и nonce (счётчик);
• дополнительные параметры, настройки и историю действий;
• документацию или исходный код расчёта с указанием версии;
• ожидаемый и вычисленный хэши, записанный и воспроизведённый результаты;
• снимки полей и сообщения о расхождении.

В публичных копиях скрывай чувствительные идентификаторы и сведения аккаунта, сохраняя неизменённый оригинал для собственной проверки. Если раскрытых данных нет или несовпадение остаётся, корректный статус — «не проверено». Попроси поддержку предоставить точный протокол, входные данные и способ привязать их к сохранённому обязательству. Из этой процедуры не следуют универсальные сроки ответа или гарантии вывода средств.

Один совпавший хэш или выборочная проверка истории не доказывают честность всего казино. Воспроизводимый результат также не подтверждает лицензию, выплату, RTP (теоретический возврат игроку) или отсутствие предвзятого выбора сидов. Различие подходов разобрано в сравнении Provably Fair и сертифицированного ГСЧ — генератора случайных чисел.

Проверка не меняет RTP, а смена клиентского сида не повышает его. Учебный результат HMAC не является прогнозом будущей игры. Полезный итог проверки — конкретное утверждение о сохранённых данных и расчёте, а не обещание выигрыша или «невзламываемости».