Provably Fair RNG: Техническое руководство (2026)

Provably Fair — Генерирование случайных чисел объяснено (2026)

Ты только что поставил 0.5 BTC на крипто-дайс игру. На экране выпало 37.42 и ты проиграл. Ты открываешь панель честности и видишь хэш серверного сида, твой клиентский сид и nonce — четыре значения, которые якобы доказывают, что ничего не было сфальсифицировано. Но как эти четыре значения стали 37.42? Что именно превратило случайные символы в конкретный результат дайса?

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

Это руководство проведёт тебя через генерирование случайных чисел в Provably Fair так, как разработчик строил бы это в 2026 году — CSPRNG примитивы под капотом, формула HMAC-SHA256, которая превращает сиды в числа, разные схемы маппинга для дайса, крэша и карт, и поверхность атак, которая остаётся даже когда математика идеальна. В конце ты узнаешь, почему PF RNG криптографически невозможно сломать, какие баги реализации всё ещё их портят, и когда вместо них используется блокчейн-случайность (Chainlink VRF).

Кратко — Как PF RNG на самом деле генерируют числа

Каждая Provably Fair игра использует одинаковый основной RNG примитив, отличается только маппинг выходных данных. Вот версия на 60 секунд.

Математика:

$\text{outcome} = f\big(\text{HMAC-SHA256}(\text{server\_seed},\; \text{client\_seed} : \text{nonce})\big)$

Где f — функция маппинга, специфичная для игры — f_dice возвращает 0-99.99, f_crash возвращает множитель, f_cards возвращает позиции перетасованной колоды. Часть HMAC идентична во всех PF казино мира.

Ключевые цифры, которые нужно знать

• 3 входа: серверный сид + клиентский сид + nonce создают каждый результат
• 64 hex-символа: длина SHA-256 / HMAC-SHA256 выхода
• 128 hex-символов: длина HMAC-SHA512 (используется BC.Game и PF блэкджек)
• ~2^256 операций: что потребуется, чтобы сломать HMAC-SHA256 — астрономически невозможно
• 0.00–99.99: стандартный диапазон дайса после маппинга
• 1.00x до ∞: стандартный диапазон множителя крэша (ограничен на практике точностью float)

Честность ≠ Прибыль

То, что RNG Provably Fair, говорит тебе, что казино не могло манипулировать результатом после твоей ставки. Это не говорит:

• Разумна ли маржа казино (проверь RTP отдельно)
• Будет ли казино честить выводы
• Честны ли бонусы и условия отыгрыша
• Был ли пул серверных сидов беспристрастным до коммита

Полную поверхность атак мы разберём ниже. Для более широкого сравнения с традиционной сертификацией см. наш гайд Provably Fair vs RNG-сертифицировано.

Что делает RNG "Provably Fair"

Перед тем как перейти к формуле, помогает разделить Provably Fair от более широкого мира RNG. PF — это конкретное улучшение для CSPRNG, не замена.

Примитив Commit-Reveal

Весь трюк Provably Fair — это криптографический паттерн, называемый commit-reveal.

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

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

Слой commit-reveal — это то, что отделяет PF от любого другого CSPRNG. Традиционное RNG-сертифицированное казино тоже использует CSPRNG — но ничто не помешает им поменять его в продакшене, как iTech Labs аудиты доказывают только статистические свойства, не идентичность во время выполнения.

HMAC как примитив RNG

HMAC-SHA256 — это реальный генератор случайных чисел внутри каждого PF раунда. Вот почему он работает:

• Детерминированный: При одинаковых входах HMAC всегда выдаёт одинаковый выход. Это позволяет тебе проверить.
• Односторонний: По выходу ты не можешь восстановить серверный сид (ключ). Это то, что держит результат непредсказуемым.
• Равномерный: HMAC выходы неотличимы от случайных 256-битных строк. Это то, что держит игру беспристрастной.
• С ключом: Серверный сид действует как секрет, который нужно знать, чтобы воспроизвести выход. Это то, что предотвращает манипуляцию.

Технически HMAC-SHA256 не является CSPRNG сам по себе — это код аутентификации сообщения. Но когда ключ (серверный сид) генерируется из реального источника энтропии, конструкция эквивалентна CSPRNG для всех практических целей. NIST формализовал это как HMAC_DRBG в SP 800-90A Rev 1, и PF казино по сути переработают этот стандарт с добавлением публичного коммита сида.

Почему CSPRNG важны (не Math.random)

Каждое легитимное PF казино генерирует серверный сид криптографически защищённым RNG — не JavaScript Math.random(). Разница важнее, чем кажется большинству игроков:

Если казино тайком сидит в Math.random(), квалифицированный атакующий мог бы восстановить сид из достаточного числа публичных выходов и предсказать каждый будущий раунд — даже если математика HMAC идеальна. Вот почему проверка того, что твоё казино действительно использует crypto.randomBytes или эквивалент, имеет значение; объяснение что такое Provably Fair гемблинг охватывает полную цепь доверия.

Как число фактически генерируется

Теперь сама формула. Это раздел, который стоит добавить в закладки — всё выше было контекстом.

Три входа, одна формула

Каждый раунд Provably Fair вычисляет:

$\text{hex\_output} = \text{HMAC-SHA256}(\text{server\_seed},\; \text{client\_seed} \; : \; \text{nonce})$

В псевдокоде:

function pfHmac(serverSeed, clientSeed, nonce) {
  const message = clientSeed + ':' + nonce
  const hex = hmacSha256(serverSeed, message)  // 64-символная hex-строка
  return hex
}

Двоеточие : — это канонический разделитель на Stake, Primedice, Rainbet и большинстве PF-казино. Несколько (BC.Game, Roobet) используют другие разделители — всегда проверяй документацию честности казино на предмет точного формата.

На выходе получается 64-символная шестнадцатеричная строка типа 8b2d4a1f9c6e7b3d5a8f2c9e4b1d7a6f3e8c5b2d9a4f7e1c8b3d6a2f9e5c4b7d. Этот hex — сырая случайность — 256 бит непредсказуемости, статистически неотличимая от подбрасывания 256 справедливых монет.

Пошагово: от выхода HMAC к результату в игре

Давай разберём один раунд полностью.

Исходные значения:

• server_seed = f4a9c2e1b7d8e3c5a1b9f6d2e8c4a7b3e9d1c6a2b5f8e4c7a3b6e1d9c2a5b8f4
• client_seed = player-xyz-42
• nonce = 7

Шаг 1 — вычислить HMAC:

HMAC-SHA256(server_seed, "player-xyz-42:7")
= 8b2d4a1f9c6e7b3d5a8f2c9e4b1d7a6f3e8c5b2d9a4f7e1c8b3d6a2f9e5c4b7d

Шаг 2 — извлечь первые 5 символов hex:

8b2d4 → преобразовать в десятичное → 569 300

Шаг 3 — отобразить на диапазон 0-99.9999:

dice = (569_300 % 1_000_000) / 10_000
     = 569_300 / 10_000
     = 56.93

Шаг 4 — применить логику ставки:

Если ты поставил "выпадет меньше 50" → ты проиграл (56.93 > 50). Если ты поставил "выпадет меньше 60" → ты выиграл. Точный результат был определён в момент, когда эти три входа объединились, ещё до того, как запустилась анимация в интерфейсе.

Шаг 5 — проверить:

После раунда ты получаешь открытый server_seed. Ты его хэшируешь — SHA-256 совпадает с предварительно заверенным хэшем? Хорошо. Ты повторно запускаешь шаги 1-3 — воспроизвёл 56.93? Хорошо. Раунд криптографически подтверждён как честный.

Для полного пошагового разбора с копипастой значений и скриншотами, см. как проверить Provably Fair раунд.

Разные игры, разные формулы

Вызов HMAC всегда идентичен. Меняется шаг 3 — как hex отображается на конкретный результат игры.

Каждое отображение разработано так, чтобы быть равномерным по всему диапазону выхода — модульная арифметика над равномерно случайным hex-значением сохраняет равномерность. Вот почему PF-игры могут заявлять об честном RTP без манипуляции отдельными раундами со стороны казино. Формула отображения настраивается, чтобы попасть в целевой перевес дома казино, а не сама случайность.

От hex-строки к результату в игре (с математикой)

Отображение для dice стоит разобрать подробнее, потому что это самый наглядный случай — и потому что это показывает, почему распределение Provably Fair в dice действительно равномерно при правильной реализации.

Отображение Dice (0-99.9999)

Dice на Stake использует первые 5 символов hex, что даёт 20 бит = 1 048 576 возможных значений. Отображение выглядит так:

$\text{dice} = \frac{(\text{int}(\text{hex}_{0:5}) \; \text{mod} \; 10^6)}{10^4}$

Зачем модуль 1 000 000, если срез может достигать 1 048 575? Потому что без модуля значения 1 000 000-1 048 575 отобразились бы на 100.0000-104.8575, за пределами диапазона dice. Модуль складывает их обратно — но вводит крошечную ошибку (значения 0-48 575 более вероятны, чем 48 576-99 999 в соотношении 2:1). Чтобы исключить смещение, реальные реализации отклоняют срезы выше 1 000 000 и переходят к следующему куску hex (символы 5-10, затем 10-15 и т. д.).

При правильной реализации это даёт идеально равномерное распределение от 0.0000 до 99.9999. Тест из 10 000 бросков показывает практически плоское покрытие — гистограмма ниже воспроизводит то, что ты увидишь с любой легитимной реализацией PF-dice.

Отображение Crash (множитель)

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

$\text{crash} = \frac{\left\lfloor \dfrac{100 \cdot 2^{52} - h}{2^{52} - h} \right\rfloor}{100}$

Где h = int(hex[0:8]) (32-битное целое число из первых 8 символов hex). С одной оговоркой: если h mod 33 == 0, множитель равен 1.00x (мгновенный краш), что создаёт примерно 1% перевес дома на Stake. Другие казино используют разные делители — 25 (Rainbet, примерно 4% перевеса), 50 (варианты с низким перевесом), 100 (очень низкий перевес).

Запусти эту формулу миллион раз и получишь распределение, где ~50% раундов краша под 2x, ~10% проходят 10x, и может быть 1% достигают 100x. Ожидаемая ценность выходит 0.99 на 1 ставку — недостающий 1% — это перевес дома, встроенный в константы формулы, а не в манипуляцию отдельными раундами.

Отображение карт (перемешивание колод)

PF blackjack, покер и баккара перемешивают виртуальные колоды с использованием HMAC-SHA512 (более длинный выход = больше карт на вызов хэша). Стандартный алгоритм Fisher-Yates:

for i = 51 down to 1:
  j = hmac_int(i) mod (i + 1)
  swap(deck[i], deck[j])

Каждый вызов hmac_int(i) использует 4 символа hex из 128-символного выхода SHA-512. Карты одного раунда полностью определены одним вызовом HMAC, поэтому PF-игры в blackjack часто показывают 13+ целых чисел в десятичном преобразовании на панели проверки — по одному за замену карты. Для конкретной реализации на Stake и BC.Game см. руководство по Provably Fair blackjack.

Традиционный ГСЧ vs Provably Fair ГСЧ

На уровне ГСЧ конкретно (а не всего стека справедливости), PF — это строгий надмножество сертифицированного CSPRNG.

Где традиционные ГСЧ отстают

Сертифицированные ГСЧ от eCOGRA, iTech Labs и GLI все криптографически безопасны — математика такая же сильная, как у PF. Проблема не в примитиве, а в модели доверия во время выполнения:

• Сертифицированный ГСЧ находится на сервере казино, проверяется один раз
• Ты никогда не видишь его выход напрямую, только конечное состояние игры
• Ничего не заставляет казино продолжать запускать сертифицированный код в боевой среде
• Спор по конкретному раунду невозможно разрешить в реальном времени

Если сертифицированный слот-движок Pragmatic Play тихо запускает другой ГСЧ в боевой среде Roobet, чем тот, что тестировала eCOGRA, никакая проверка сертификата это не поймает. Зазор закрывается только с открытой проверкой каждый раунд.

Что PF добавляет к примитиву

Provably Fair берет ту же криптографическую основу и открывает её. Конкретно:

• Хэш серверного сида публикуется до твоей ставки (обязательство)
• Твой клиентский сид участвует в входе HMAC (совместное подписание)
• Исходный серверный сид раскрывается после раунда (раскрытие)
• Вычисление детерминировано и воспроизводимо в любом браузере (проверка)

Вот вся разница. Один и тот же HMAC, один и тот же CSPRNG — с четырьмя дополнительными слоями прозрачности сверху. Для более глубокого разбора того, как оба подхода соотносятся, см. provably fair vs RNG certified.

Блокчейн-случайность — Chainlink VRF и игры в сети

Provably Fair ГСЧ хорошо работает для централизованных крипто-казино. Но что насчет полностью децентрализованных приложений — лотерей в сети, назначения характеристик NFT, кубиков в сети? Здесь вступает в силу другое решение.

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

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

• block.timestamp контролируется майнером в пределах нескольких секунд
• block.blockhash может быть манипулирован майнерами, удерживающими блоки
• block.prevrandao (после слияния Ethereum) лучше, но всё ещё может быть смещен валидаторами
• Любой источник энтропии в сети может быть прочитан контрактом до того, как его использовать, что лишает смысла

Наивные лотереи dApp, использовавшие blockhash, были в прошлом дренированы. Экономический стимул манипулировать джекпотом в $1M может заставить майнера рационально удерживать блок.

Как Chainlink VRF это решает

Chainlink VRF (Verifiable Random Function) генерирует случайность вне сети и доставляет её в сеть с криптографическим доказательством. Процесс:

1. Смарт-контракт запрашивает случайное число
2. Оракул Chainlink генерирует значение вне сети, используя свой приватный ключ + сид запроса
3. Доказательство — это BLS-подпись, которую любой может проверить против публичного ключа оракула
4. И значение, и доказательство публикуются обратно в сеть в одной транзакции
5. Контракт проверяет доказательство перед использованием значения

Критическое свойство: потому что доказательство связывает случайное значение с приватным ключом оракула и сидом запроса, оракул не может выбирать удобные значения. Любое отклонение математически обнаруживаемо.

Когда использовать VRF vs HMAC-базированный PF

Большинство крипто-казино в 2026 году всё ещё используют HMAC-базированный PF, потому что он быстр, дешев и уже хорошо понят. VRF — это то место, где сияют децентрализованные игры DeFi, NFT и полностью децентрализованные игры. Наш рейтинг provably fair Bitcoin games специально фильтрует по тому, какую реализацию PF использует каждое казино. Если хочешь стресс-тестить эти концепции на живом казино, в каталоге provably fair перечислены реализации, которые можно проверить без депозита — большинство публикуют хэши server seed на открытом эндпоинте.

Уязвимости RNG в Provably Fair

Криптографически идеальный PF RNG всё равно может сломаться при плохой реализации. Вот что переживает проверку математики.

Атака на смещённый пул сидов

Самая реалистичная атака — и одна из причин, почему ротация клиентского сида имеет значение.

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

Каждый развёрнутый сид по-прежнему хеширует корректно до своего предварительно обязательного хэша. Математика commit-reveal проходит проверку. Но пул доступных сидов был отобран вишнёвым сбором до того, как любой игрок их увидел, и долгосрочное преимущество казино незаметно превышает заявленный RTP.

Почему ротация это блокирует

Атаки на смещённые сиды требуют, чтобы казино знало твой будущий клиентский сид до фиксации серверного сида. Ротируй свой клиентский сид каждые 50–100 ставок и предварительные вычисления казино становятся бесполезными — оно зафиксировало серверный сид до того, как узнало новый клиентский сид, поэтому не может направлять исходы.

Поэтому легитимные казино дают тебе ротировать мгновенно. PF казино, которое отказывается от ротации клиентского сида (или автоматически переделывает клиентский сид по собственному расписанию, а не твоему) — сигнализирует, что уязвимость открыта. Гайд клиентский сид vs серверный сид охватывает весь workflow ротации.

Слабые источники энтропии

Если генерация серверного сида использует предсказуемую энтропию, протокол commit-reveal по-прежнему запускается, но атакующий может предсказать сиды.

Ловушка Math.random

JavaScript Math.random() — это вариант линейного конгруэнтного генератора. После наблюдения ~700 последовательных выходов атакующий может реконструировать полное внутреннее состояние и предсказать каждый последующий выход. Если PF казино использует Math.random для генерации серверного сида:

1. Атакующий играет 700+ раундов, собирая каждый раскрытый серверный сид
2. Атакующий реконструирует состояние PRNG
3. Атакующий предсказывает следующий хэшированный серверный сид до его фиксации
4. Атакующий ставит с полным знанием исхода

Защита: казино должны использовать crypto.randomBytes(32) (Node.js), crypto.getRandomValues(new Uint8Array(32)) (браузер) или аппаратный RNG. Разница — одна строка кода, но разрыв в безопасности полный.

Красные флаги реализации

Короткий чеклист сигналов, что PF RNG небезопасен:

• Нет кнопки ротации клиентского сида или ротация занимает >5 секунд
• Клиентский сид автоматически переделывается казино по их расписанию
• История серверного сида не показывает алгоритм или ширину слайса
• Инструмент верификации работает только на собственном сайте казино (не локально)
• Опубликованный алгоритм хеширования не указан — "SHA-256 где-то" недостаточно; нужна точная формула
• Раскрытые серверные сиды не совпадают с их предварительно зафиксированными хэшами ни в одном раунде

Любой из этих флагов говорит, что заявление о PF — это маркетинговый лак поверх обычного RNG. Для сравнения сторон по сторонам, какие казино действительно публикуют свой PF код, см. рейтинг provably fair Bitcoin игр.

Попробуй сам — интерактивный верификатор

Математика перестаёт быть абстрактной в момент, когда ты запускаешь её на своих сидах. Вставь любые четыре значения из панели справедливости твоего казино в верификатор ниже — всё выполняется в твоём браузере через Web Crypto API, никакие данные не отправляются на наш сервер.

Практический совет: если под рукой нет реальной ставки в PF казино, попробуй эти одноразовые тестовые значения, чтобы увидеть проверенный раунд:

• Хэш серверного сида: bf3c0a9b0f4b3c8e8f4f0c5f0c4e8b7d8f3e2a1c9f6e3b7c4d5a8e2f9b1c6d3a (пример только — не совпадёт с реальными хэшами)
• Серверный сид: f4a9c2e1b7d8e3c5a1b9f6d2e8c4a7b3e9d1c6a2b5f8e4c7a3b6e1d9c2a5b8f4
• Клиентский сид: demo-player
• Nonce: 1

Результат показывает вердикт PASS / FAIL на совпадение хэша плюс реконструированные исходы дайса и краша. Та же логика работает за Aviator provably fair калькулятором для crash-игры Spribe, и наш полный верификатор на provably fair хабе покрывает каждое мейнстримное PF казино. Для подбора размера ставок при известном RTP после подтверждения, что RNG легитимен, сочетай с нашим RTP калькулятором, калькулятором преимущества казино и калькулятором банкролла.

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

FAQ