Практическая верификация Provably Fair: пошаговый протокол, инструменты и типичные ошибки

4 фазы протокола: краткое напоминание

Полная формализация — в теоретической статье. Здесь — практический обзор:

Фаза	Кто выполняет	Что происходит	Что видит участник
1. Commitment	Оператор	Генерирует server_seed, публикует hash(server_seed)	Хеш (64 символа hex)
2. Client Seed	Участник	Генерирует или принимает client_seed	Своё «зерно» (может изменить)
3. Генерация	Система	result = f(HMAC-SHA256(server_seed, client_seed + nonce))	Результат события
4. Раскрытие	Оператор	Раскрывает server_seed	Исходное «зерно» для проверки

Пошаговый протокол верификации

Шаг 1: Зафиксировать хеш до события

Перед началом серии событий оператор публикует:

      server_seed_hash: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    

Это SHA-256 хеш от server_seed. Скопируйте и сохраните этот хеш до начала событий. Именно он доказывает, что server_seed был зафиксирован заранее.

Шаг 2: Установить свой client_seed

Платформа предлагает client_seed по умолчанию (генерируется браузером). Рекомендация: всегда менять client_seed на собственный. Это исключает теоретическую возможность предварительного вычисления результатов оператором.

      client_seed: myCustomSeed2026
    

Шаг 3: Провести серию событий

Каждое событие использует тройку (server_seed, client_seed, nonce), где nonce — последовательный счётчик (1, 2, 3, …). Записывайте результат каждого события.

Шаг 4: Запросить раскрытие server_seed

После завершения серии (или при смене server_seed) оператор раскрывает:

      server_seed: a1b2c3d4e5f6...
    

Шаг 5: Проверить хеш

Вычислите SHA-256 от раскрытого server_seed и сравните с сохранённым хешем из шага 1:

      SHA256("a1b2c3d4e5f6...") == "e3b0c44298fc1c..." ?
    

Если совпадают → server_seed не был изменён после публикации хеша.

Шаг 6: Пересчитать результаты

Для каждого события вычислите:

      hmac = HMAC-SHA256(server_seed, client_seed + ":" + nonce)

      result = f(hmac)  // алгоритм преобразования специфичен для модели

Сравните с фактическим результатом события. Совпадение → результат не был подменён.

Псевдокод верификации

JavaScript (browser-side)

      // 1. Проверка хеша

      const crypto = require('crypto');

      const serverSeed = "a1b2c3d4e5f6...";

      const savedHash = "e3b0c44298fc1c...";

      const computedHash = crypto.createHash('sha256')

        .update(serverSeed).digest('hex');

      console.log(computedHash === savedHash); // true → seed не менялся

      // 2. Пересчёт результата

      const clientSeed = "myCustomSeed2026";

      const nonce = 1;

      const hmac = crypto.createHmac('sha256', serverSeed)

        .update(clientSeed + ":" + nonce).digest('hex');

      // 3. Преобразование в результат (пример: множитель)

      const hashInt = parseInt(hmac.substring(0, 8), 16);

      const maxVal = 0xFFFFFFFF;

      const multiplier = (maxVal / (hashInt + 1)) * (1 - 0.004);

      // 0.004 = Edge; формула зависит от модели

Python

      import hashlib, hmac as hmac_lib

      server_seed = "a1b2c3d4e5f6..."

      client_seed = "myCustomSeed2026"

      nonce = 1

      # Проверка хеша

      computed = hashlib.sha256(server_seed.encode()).hexdigest()

      assert computed == saved_hash

      # Пересчёт

      msg = f"{client_seed}:{nonce}"

      h = hmac_lib.new(server_seed.encode(), msg.encode(),

        hashlib.sha256).hexdigest()

      hash_int = int(h[:8], 16)

      multiplier = (0xFFFFFFFF / (hash_int + 1)) * 0.996

Что Provably Fair гарантирует

Гарантия	Механизм
Результат определён до события	Хеш server_seed опубликован до client_seed
Результат не изменён после события	SHA-256 хеш совпадает с сохранённым
Участник влияет на результат	client_seed включён в HMAC-вычисление
Оператор не может подобрать server_seed под client_seed	server_seed зафиксирован (commitment) до получения client_seed

Что Provably Fair НЕ гарантирует

Частое заблуждение	Реальность
«RTP честный»	❌ Provably Fair гарантирует неподменяемость результата, но НЕ распределение. Алгоритм \(f(\text{hmac})\) может содержать любой Edge. Требуется эмпирическая проверка
«Я могу определить RTP по 100 событиям»	❌ CI_95% при n=100 и σ=5: ±98% RTP. Для точности ±1% нужно \(N \geq 960\,400\) событий (RTP и Edge)
«Оператор не может обмануть»	⚠️ Оператор может: (а) не раскрывать seed для «неудобных» серий; (б) использовать предвычисленные пары; (в) изменить алгоритм \(f\) между сессиями
«Все Provably Fair платформы одинаково надёжны»	❌ Качество реализации различается: открытый ли код \(f\)? Можно ли менять client_seed? Раскрываются ли все seeds?
«Provably Fair заменяет лицензию»	❌ Регуляторная защита (возврат средств, разрешение споров) требует лицензии. Provably Fair — только криптографическая, не правовая гарантия

5 типичных ошибок при верификации

Ошибка 1: Не сохранять хеш до события

Если хеш не сохранён заранее, верификация бессмысленна — оператор мог сгенерировать server_seed post-factum.

Решение: всегда копировать server_seed_hash в файл/заметку до начала серии.

Ошибка 2: Использовать client_seed по умолчанию

Если оператор знает client_seed заранее (сгенерирован его же кодом), он теоретически может предвычислить результат и выбрать «выгодный» server_seed из набора.

Решение: всегда устанавливать собственный client_seed (произвольная строка).

Ошибка 3: Не проверять алгоритм f(hmac)

Даже при корректных seeds алгоритм преобразования хеша в результат может содержать скрытый Edge. Если \(f\) не документирован — верификация неполна.

Решение: использовать только платформы с открытой документацией \(f\).

Ошибка 4: Путать «честный результат» с «положительным ожиданием»

Provably Fair подтверждает, что результат не подменён. Но \(E[\text{P\&L}] = -s \cdot \text{Edge} < 0\) — это нормальная работа модели, а не обман.

Решение: понимать, что «честность» = «результат соответствует заявленному алгоритму», а не «ожидание положительное».

Ошибка 5: Малая выборка для оценки RTP

Участник проверяет 50 событий, получает эмпирический RTP = 85% и заключает «платформа нечестна». При \(\sigma = 5\):

\[ \text{CI}_{95\%} = 85\% \pm \frac{1{,}96 \times 5}{\sqrt{50}} \times 100\% = 85\% \pm 139\%. \]

Реальный RTP с 95% вероятностью находится в диапазоне от −54% до 224%. Заключение о нечестности статистически необоснованно.

Решение: для обоснованного вывода об RTP требуется \(N > 200\,000\) событий с расчётом CI (теоретическая статья).

Эмпирический журнал: как вести учёт

Рекомендуемая структура записи для каждого события:

Поле	Пример	Назначение
nonce	42	Порядковый номер события
client_seed	myCustomSeed2026	Ваше «зерно»
server_seed_hash	e3b0c4...b855	Сохранён до события
Размер позиции \(s\)	1,00	Для расчёта RTP
Выплата \(X_i\)	2,50	Для расчёта RTP
server_seed (после раскрытия)	a1b2c3...f6	Для верификации
Верификация пройдена?	✅ / ❌	Совпадение хеша и результата

Расчёт эмпирического RTP с доверительным интервалом

\[ \widehat{\text{RTP}}_n = \frac{\sum_{i=1}^n X_i}{\sum_{i=1}^n s_i}, \quad \text{CI}_{95\%} = \widehat{\text{RTP}}_n \pm \frac{1{,}96 \cdot \hat{\sigma}}{\sqrt{n}}, \]

где \(\hat{\sigma}\) — выборочное стандартное отклонение \(X_i/s_i\). Если нижняя граница CI > 0 и верхняя < 200%, выборка начинает быть информативной.

Сравнение: Provably Fair vs традиционный аудит

Параметр	Provably Fair	Традиционный аудит (NIST + лаборатория)
Кто проверяет	Каждый участник самостоятельно	Независимая лаборатория (eCOGRA, GLI, BMM)
Что проверяется	Неподменяемость конкретного результата	Статистические свойства ГСЧ + RTP на N > 10⁶
Гарантия RTP	❌ Не проверяет распределение	✅ NIST SP 800-22 + эмпирический RTP
Правовая защита	❌ Нет (криптография ≠ право)	✅ Лицензия = правовая ответственность
Прозрачность	✅ Каждый результат проверяем	⚠️ Отчёт аудитора (доступ ограничен)
Защита от манипуляции f()	⚠️ Только если код f() открыт	✅ Лаборатория проверяет код
Стоимость	Бесплатно для участника	50 000–200 000 у.е. для оператора

Подробнее о традиционном аудите — верификация ГСЧ.

Чек-лист надёжной Provably Fair платформы

✅ Хеш server_seed публикуется до начала серии событий.
✅ Участник может установить собственный client_seed.
✅ Алгоритм \(f(\text{hmac})\) полностью документирован и открыт.
✅ Все server_seeds раскрываются (не выборочно).
✅ Nonce увеличивается строго последовательно (без пропусков).
✅ Независимые верификаторы подтверждают корректность реализации.
⚠️ Наличие дополнительной лицензии (MGA, Curaçao) — плюс, но не замена Provably Fair.

Выводы

Provably Fair гарантирует неподменяемость — результат определён до события и не может быть изменён оператором после получения client_seed.
Provably Fair НЕ гарантирует RTP — алгоритм \(f\) может содержать любой Edge. Для оценки RTP необходимо \(N > 200\,000\) событий.
5 типичных ошибок снижают ценность верификации: несохранённый хеш, дефолтный client_seed, закрытый \(f\), путаница «честность ≠ прибыль», малая выборка.
Ведение эмпирического журнала — единственный способ объективно оценить платформу на основе данных.
Provably Fair дополняет, но не заменяет традиционный аудит и лицензирование.

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