Provably Fair: как работает проверка и где её границы

Provably Fair — это способ проверить завершённую игру через предварительную фиксацию данных хэшем, их последующее раскрытие и воспроизведение результата по документированному протоколу. Ты можешь проверить, соответствуют ли раскрытые данные сохранённому до ставки хэш-обязательству, а при наличии точного алгоритма — совпадает ли рассчитанный исход с записанным результатом. Это не гарантия прибыли, выплат или общей добросовестности оператора.

Главная польза — возможность проверить конкретное утверждение о конкретном раунде, а не просто поверить значку «честная игра». Но доказательство зависит от того, какие данные ты сохранил, когда получил хэш и доступен ли алгоритм нужной версии.

Что именно можно доказать

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

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

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

Хэш — не зашифрованные данные. SHA-256 вычисляет из сообщения хэш фиксированной длины; раскрытие исходной строки не является расшифровкой. Основа этого различия описана в стандарте SHA-256 — FIPS 180-4.

Какие данные участвуют в проверке

Состав данных зависит от протокола: серверный сид, клиентский сид и nonce (счётчик) встречаются часто, но не обязательны для каждой реализации.

Общее устройство HMAC описано в RFC 2104, но документ не задаёт правила конкретной казино-игры.

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

Как сохранить данные и проверить завершённый раунд

Начни с официальных правил конкретной игры и сохрани хэш-обязательство до ставки. Для уже завершённого раунда можно использовать существующую историю — новая ставка для проверки не нужна.

1. Открой официальное описание проверки. Найди алгоритм, версию протокола, состав входных данных и порядок раскрытия. Одного значка Provably Fair недостаточно.
2. До ставки сохрани хэш-обязательство. Вместе с ним сохрани версию правил и схему входных данных. Важно иметь подтверждение, что хэш был доступен до игры.
3. Выбери клиентский сид, если это предусмотрено. Используй соответствующее поле игры после получения серверного хэш-обязательства, когда протокол допускает такой порядок.
4. Сохрани запись раунда. Нужны идентификатор раунда, доступные сиды, nonce (счётчик), а при необходимости — позиция в потоке байтов, действия игрока и записанный исход.
5. Дождись предусмотренного раскрытия. Это может происходить после раунда или после смены серверного сида. Не предполагай, что раскрытие обязательно следует за каждой ставкой.
6. Проверь хэш-обязательство. Вычисли хэш именно тех данных и в том представлении, которые указаны в правилах.
7. Выполни воспроизведение результата. Используй точный алгоритм и преобразование данных в исход выбранной игры.
8. Сравни исход и выплату отдельно. Совпадение исхода не заменяет проверку таблицы выплат и фактически начисленной суммы.

Если нужных данных или версии алгоритма нет, полная проверка остаётся недоступной. Более подробный порядок действий разобран в руководстве по проверке Provably Fair.

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

Разные протоколы фиксируют разные данные и по-разному превращают их в игровой исход. Универсальная подстановка сидов в один алгоритм не заменяет проверку по документации конкретной игры.

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

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

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

Учебный пример BGaming: проверка полного хэша

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

Официальная страница BGaming показывает данные примера рулетки и дальнейшее преобразование результата.

Исходные JSON-данные Result + Secret из учебного примера BGaming для американской рулетки

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

Исходная строка для этого примера:

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

Опубликованный полный хэш:

f88e5c0943740b0269b21347fa26c59b1717ee200584ac40e1c56edd49ad82b8

В строке поле server содержит исходный серверный результат 2, game — обозначение игры, а secret — секретную строку. Хэш фиксирует всю строку, а не только одно из этих значений.

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

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

Для этой проверки вставь полный хэш в первое поле, а всю строку данных — в поле раскрытого серверного сида. Клиентский сид оставь пустым, nonce (счётчик) — равным 0.

Открой инструмент проверки Provably Fair и заполни реальные элементы интерфейса:

Поля русской версии инструмента: полное хэш-обязательство, исходная строка BGaming, пустой клиентский сид и nonce (счётчик) со значением 0

В поле SERVER SEED введена вся исходная строка JSON, а не только значение secret.

Нажми кнопку ПРОВЕРИТЬ ХЕШ. Сравни вычисленный и введённый хэши целиком — от первого символа до последнего.

Результат проверки SHA-256 в русской версии инструмента: вычисленный и введённый полные хэши совпадают

Зелёное сообщение ИГРА ЧЕСТНАЯ в этой реализации означает только совпадение хэшей. Оно не является сертификатом игры или оператора.

Инструмент вычисляет SHA-256 введённой строки в кодировке UTF-8. В этой проверке он не рассчитывает окончательный результат BGaming и не выполняет универсальное воспроизведение результата Stake или других провайдеров. Встроенный демонстрационный расчёт игрового числа не используй как алгоритм проверки этого примера.

Точность строки принципиальна: добавление одного пробела после первой запятой даёт другой хэш. Поэтому не добавляй пробелы, типографские кавычки или перенос строки в конец сообщения. Для собственных данных следуй правилам экспорта провайдера, а не самостоятельно «исправляй» строку.

Откуда в примере берётся результат 7

Результат 7 указан в документации BGaming: к исходному серверному результату 2 применяется клиентское значение 5, и в показанном примере получается 2 + 5 = 7.

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

Из одного примера нельзя вывести общую формулу для всех значений и разновидностей рулетки. Здесь не проверены правила перехода через границу диапазона, поэтому подставлять придуманное правило остатка от деления нельзя.

Чем Provably Fair отличается от проверки ГСЧ и видеотрансляции

Provably Fair даёт возможность проверить зафиксированные данные и, при полном протоколе, воспроизвести конкретный исход. Проверка ГСЧ и видеотрансляция дают другие виды свидетельств и не заменяют эту процедуру.

Provably Fair и ГСЧ не исключают друг друга: генератор случайных чисел может участвовать в системе с последующей проверкой данных.

В качестве примера требований к случайности британский стандарт UKGC RTS 7 описывает качество случайных исходов и их преобразование. Это не сертификат конкретного оператора и не подтверждение того, что любая игра соответствует стандарту. Для такого вывода нужен соответствующий отчёт и его область действия. Подробнее различия разобраны в сравнении Provably Fair и проверки ГСЧ.

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

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

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

Рассмотрим условную модель: ставка равна 1, вероятность выигрыша — 50%, общая выплата при выигрыше — 1,98, при проигрыше — 0. Выплата 1,98 включает возвращаемую ставку.

Ожидаемая выплата на единицу ставки: 0,5 × 1,98 = 0,99. Поэтому в этой модели RTP составляет 99%, а преимущество казино — 1%. При сумме всех ставок 1000 ожидаемая общая выплата равна 990, а ожидаемая чистая прибыль игрока — −10.

Это математическое ожидание условной модели, а не RTP названной игры и не прогноз твоей сессии. Фактический результат может отличаться; комиссии здесь не учитываются. Вероятность выигрыша 50% тоже не означает RTP 50%: для RTP важен размер выплаты.

При ставке 1 и вероятности выигрыша 50% выплата 2 дала бы нулевое преимущество казино в этой модели. Возможность проверить исход и выгодность условий — разные вопросы.

Что делать, если проверка не совпала

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

Проверь последовательно:

• Используешь ли ты раскрытый серверный сид именно нужной пары, а не текущий активный сид?
• Было ли сравниваемое хэш-обязательство сохранено до ставки?
• Совпадают ли кодировка, пробелы, переносы строк, кавычки и порядок полей?
• Нужно ли хэшировать шестнадцатеричную строку как текст или сначала преобразовать её в байты?
• Не перепутан ли nonce (счётчик) с идентификатором раунда?
• Верны ли позиция в потоке байтов, счётчик блоков HMAC и версия протокола?
• Совпадают ли клиентский сид и другие входные значения?
• Учтены ли преобразование для конкретной игры, округление и история действий?

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

Без истории, раскрытых данных или нужной версии правил полную проверку выполнить нельзя. Сохрани исходные строки, хэш-обязательство, сведения о раунде и результат сравнения; обратись в официальную поддержку. До объяснения расхождения разумно приостановить ставки на реальные деньги. Успешное разрешение спора не гарантировано.

Можно ли предсказать следующий результат по хэшу

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

Утечки, ошибки реализации и нарушения порядка фиксации данных нельзя исключить одним названием Provably Fair. Оператор, получивший все необходимые входные данные, может выполнить расчёт; утверждение о непредсказуемости для любого участника было бы неверным.

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