Provably Fair: криптографическая математика верификации и эмпирический анализ RTP

1. Проблема доверия в традиционных системах

В стандартной архитектуре (подробнее — Архитектура RTP) честность ГСЧ подтверждается косвенно: сертификатами независимых лабораторий и лицензией регулятора. Участник доверяет третьей стороне, но не может самостоятельно проверить каждый конкретный результат.

Provably Fair решает эту проблему: протокол предоставляет участнику криптографическое доказательство того, что результат не был модифицирован после инициации события.

2. Полная формализация протокола

Протокол состоит из четырёх фаз:

Фаза 1: Commitment (обязательство сервера)

Перед началом сессии сервер генерирует случайную строку — Server Seed \( S \), и вычисляет её криптографический хеш:

\[ H_S = \text{SHA-256}(S). \]

Хеш \( H_S \) отправляется участнику. Это обязательство (commitment): сервер «запечатывает» своё значение до начала событий. Свойство preimage resistance гарантирует:

\[ P(\text{восстановить } S \text{ из } H_S) \leq 2^{-256} \approx 0. \]

Участник сохраняет \( H_S \), но не может узнать \( S \) до раскрытия.

Фаза 2: Client Seed (вклад участника)

Участник генерирует (или принимает автоматически сгенерированный) Client Seed \( C \) — произвольную строку. Участник может менять \( C \) в любой момент.

Значение \( C \) критически важно: оно гарантирует, что сервер не мог заранее подобрать \( S \) для получения нужного результата, поскольку \( C \) был неизвестен серверу на момент генерации \( S \).

Фаза 3: Вычисление результата

Для каждого события \( n \) (nonce — порядковый номер в сессии) результат вычисляется детерминированной функцией от трёх параметров:

\[ \text{Hash}_n = \text{HMAC-SHA256}(S, \; C \| n), \]

где \( \| \) — конкатенация, HMAC — Hash-based Message Authentication Code. Результат — 256-битная строка (64 шестнадцатеричных символа).

Фаза 4: Преобразование хеша в числовой результат

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

Пример: модель «продолжить/остановиться» (мультипликатор)

Алгоритм извлекает результат из первых байтов хеша:

\[ h = \text{int}(\text{Hash}_n[0{:}8], \; 16), \quad h \in [0, \; 2^{32} - 1]. \]

Затем вычисляется мультипликатор:

\[ M = \left\lfloor \frac{2^{32}}{h + 1} \right\rfloor \cdot \frac{1}{100}, \quad \text{если } h > \frac{2^{32}}{100} \cdot (100 - \text{Edge}). \]

Если \( h \) попадает в «зону оператора» (нижние \( \text{Edge}\% \) диапазона), результат = 0 (немедленный отрицательный исход). В остальных случаях \( M \) монотонно убывает с ростом \( h \), обеспечивая обратную зависимость: малые \( h \) → большие мультипликаторы.

Числовой пример:
Пусть \( \text{Hash}_n = \texttt{a1b2c3d4...} \), тогда:
\( h = \text{int}(\texttt{a1b2c3d4}, 16) = 2\,712\,879\,060 \).
\( M = \lfloor 2^{32} / (2\,712\,879\,060 + 1) \rfloor / 100 = \lfloor 1{,}583... \rfloor / 100 \).
Результат: мультипликатор 1,58×.
Каждый участник, зная \( S \), \( C \) и \( n \), может воспроизвести этот расчёт и подтвердить результат.

Пример: дискретная модель с N исходами

Для систем с конечным числом исходов хеш преобразуется через модульную арифметику:

\[ \text{outcome} = h \bmod N, \quad h = \text{int}(\text{Hash}_n[0{:}8], \; 16). \]

При \( N = 37 \) (дискретная модель) это даёт равномерное распределение по 37 исходам (с пренебрежимо малой неравномерностью: \( 2^{32} \bmod 37 \neq 0 \), но отклонение \( < 10^{-7} \)).

3. Верификация: пошаговый процесс

После завершения сессии (или по запросу) сервер раскрывает \( S \). Участник выполняет проверку:

Шаг 1: Проверка commitment

\[ \text{SHA-256}(S_{\text{раскрытый}}) \stackrel{?}{=} H_S. \]

Если хеши совпадают — Server Seed не был изменён после обязательства.

Шаг 2: Воспроизведение результата

Для каждого события \( n \) участник вычисляет:

\[ \text{Hash}_n^{\text{verify}} = \text{HMAC-SHA256}(S_{\text{раскрытый}}, \; C \| n). \]

Если \( \text{Hash}_n^{\text{verify}} \) совпадает с хешем, предъявленным платформой, и результат из этого хеша совпадает с зафиксированным — результат не был модифицирован.

Шаг 3: Статистический анализ (опционально)

Собрав данные за \( N \) событий, участник может вычислить эмпирический RTP — это переход от «верификации отдельного результата» к «верификации модели».

4. Эмпирический расчёт RTP

Provably Fair даёт уникальную возможность: участник может собрать верифицированные данные и рассчитать фактический RTP с доверительным интервалом.

Точечная оценка

\[ \widehat{\text{RTP}} = \frac{\sum_{i=1}^{N} \text{Payout}_i}{\sum_{i=1}^{N} s_i}. \]

Доверительный интервал

Для оценки точности используем центральную предельную теорему. Пусть \( Y_i = \text{Payout}_i / s_i \) — нормированный результат \( i \)-го события. Тогда:

\[ \bar{Y} = \frac{1}{N} \sum_{i=1}^{N} Y_i, \quad \hat{\sigma}^2 = \frac{1}{N-1} \sum_{i=1}^{N} (Y_i - \bar{Y})^2. \]

95%-й доверительный интервал для истинного RTP:

\[ \text{CI}_{95\%} = \bar{Y} \pm 1{,}96 \cdot \frac{\hat{\sigma}}{\sqrt{N}}. \]

Числовой пример:
После \( N = 1000 \) верифицированных событий участник получил:
\( \bar{Y} = 0{,}971 \), \( \hat{\sigma} = 3{,}2 \).
\( \text{CI}_{95\%} = 0{,}971 \pm 1{,}96 \cdot \frac{3{,}2}{\sqrt{1000}} = 0{,}971 \pm 0{,}198 = [0{,}773; \; 1{,}169] \).
Интервал слишком широк для вывода о соответствии RTP. При \( N = 100\,000 \):
\( \text{CI}_{95\%} = 0{,}971 \pm 0{,}020 = [0{,}951; \; 0{,}991] \).
Если декларированный RTP = 97%, интервал [95,1%; 99,1%] содержит 97% — данные не противоречат заявлению.

Необходимый объём выборки

Для обнаружения отклонения RTP на \( \delta \) процентных пунктов с мощностью 80%:

\[ N \geq \left( \frac{(z_{\alpha/2} + z_{\beta}) \cdot \sigma}{\delta} \right)^2 = \left( \frac{(1{,}96 + 0{,}84) \cdot \sigma}{\delta} \right)^2. \]

При \( \sigma = 3{,}2 \) и \( \delta = 0{,}02 \) (2 п.п.):

\[ N \geq \left( \frac{2{,}8 \times 3{,}2}{0{,}02} \right)^2 = (448)^2 = 200\,704. \]

Для статистически значимого обнаружения 2%-го отклонения RTP необходимо ~200 тысяч верифицированных событий. Это иллюстрирует фундаментальное ограничение: индивидуальный участник за типичную сессию (100–500 событий) не может статистически отличить RTP 95% от RTP 97%.

5. Свойства безопасности протокола

Атака	Описание	Защита
Подмена Server Seed	Сервер меняет \( S \) после получения \( C \)	Commitment \( H_S \) зафиксирован до начала сессии; \( \text{SHA-256}(S') \neq H_S \)
Подбор \( S \) под нужный результат	Сервер генерирует \( S \), дающий желаемый исход при известном \( C \)	\( C \) неизвестен серверу до момента commitment. Участник может менять \( C \) после получения \( H_S \)
Предсказание результата участником	Участник знает \( H_S \) и пытается найти \( S \)	Preimage resistance SHA-256: \( P \leq 2^{-256} \)
Повторное использование seed	Сервер использует один \( S \) для нескольких сессий	Nonce \( n \) гарантирует уникальность хеша: \( \text{HMAC}(S, C\\|n_1) \neq \text{HMAC}(S, C\\|n_2) \)
Коллизия хешей	Нахождение \( S' \neq S \) с \( H(S') = H(S) \)	Collision resistance SHA-256: \( O(2^{128}) \) операций (практически недостижимо)

6. Ограничения Provably Fair

Несмотря на криптографическую строгость, протокол имеет границы:

Что протокол гарантирует

✓ Результат не был изменён после инициации события.
✓ Результат детерминирован и воспроизводим из \( S, C, n \).
✓ Ни сервер, ни участник не контролируют исход в одностороннем порядке.

Что протокол НЕ гарантирует

✗ Соответствие RTP декларированному. Алгоритм преобразования хеша в результат определяет RTP. Provably Fair подтверждает, что алгоритм применяется без изменений, но не проверяет, что RTP алгоритма равен заявленному.
✗ Справедливость алгоритма. Провайдер мог заложить Edge 10% вместо декларированных 3%. Протокол это не выявит.
✗ Автоматическую защиту. Участник должен активно проверять хеши. Если проверка не проводится, протокол не функционирует.

Комплексная верификация: Provably Fair + эмпирический анализ RTP = максимальный уровень проверки.
1. Provably Fair подтверждает, что каждый результат не был модифицирован.
2. Эмпирический RTP с доверительным интервалом подтверждает (при \( N \geq 10^5 \)), что фактический RTP соответствует декларированному.
Только комбинация обоих методов закрывает все уязвимости.

7. Инструменты верификации

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

Встроенные верификаторы платформы: большинство платформ с Provably Fair предоставляют интерфейс проверки (ввод \( S, C, n \) → пересчёт результата).
Независимые верификаторы: сторонние сервисы и open-source скрипты, реализующие алгоритм HMAC-SHA256 → результат. Преимущество: исключают возможность манипуляции со стороны платформы.
Собственные скрипты: участник с техническими знаниями может написать скрипт на Python, JavaScript или любом языке с поддержкой HMAC-SHA256.

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

      Вход: S, C, n, заявленный_результат

hash ← HMAC-SHA256(key=S, message=C||n)

h ← int(hash[0:8], base=16)

результат ← convert(h, модель_параметры)

assert результат == заявленный_результат

assert SHA-256(S) == H_S_сохранённый

Выводы

Provably Fair формализует честность через криптографию: commitment \( H_S = \text{SHA-256}(S) \), двусторонний вклад \( (S, C) \), детерминированное вычисление результата через HMAC-SHA256.
Преобразование хеша в результат — ключевой технический шаг. Для моделей с мультипликатором: \( M = \lfloor 2^{32}/(h+1) \rfloor / 100 \). Для дискретных: \( \text{outcome} = h \bmod N \).
Эмпирический RTP с 95%-м доверительным интервалом требует \( N \geq 200\,000 \) событий для обнаружения 2%-го отклонения. Индивидуальная сессия статистически недостаточна.
Протокол защищает от подмены результата, но не гарантирует справедливость заложенного RTP. Комплексная верификация = Provably Fair + эмпирический анализ RTP.
Активная проверка обязательна: неиспользуемый протокол не обеспечивает защиту.

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