Чем отличаются клиентский и серверный сиды и как их проверить

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

Эти элементы работают вместе, а не заменяют друг друга. При этом не все системы Provably Fair используют именно пару сидов и счётчик: проверять нужно конкретный опубликованный протокол, а не знакомые названия полей. Общий принцип разобран в объяснении Provably Fair.

Хэш SHA-256 — не зашифрованный серверный сид. Это результат хэш-функции фиксированной длины; раскрытие сида означает публикацию исходных данных, а не «расшифровку» хэша. Криптографическая стойкость опирается на практические предположения, а не на математическую невозможность совпадений. Основа — стандарт SHA-256.

В каком порядке сохранять хэш и выбирать клиентский сид?

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

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

В описании Stake старый серверный сид раскрывается при смене пары сидов. Это правило конкретного протокола, а не обещание немедленного раскрытия после каждой ставки во всех казино. Сама смена пары сидов также не доказывает, что оператор выбирал исходные данные беспристрастно.

Чем nonce (счётчик) отличается от позиции в потоке байтов?

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

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

В реализации Stake каждый блок HMAC-SHA256 содержит 32 байта. Счётчик блоков HMAC определяется как целая часть от деления позиции в потоке байтов на 32, а смещение внутри блока — как остаток от этого деления. Одному раунду может потребоваться несколько блоков. Это описано в официальной реализации.

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

Как из сидов получаются байты: пример Stake

В опубликованной реализации Stake серверный сид используется как буквальная строка UTF-8 в качестве ключа HMAC-SHA256, а сообщение имеет вид clientSeed:nonce:blockIndex. Первые четыре байта можно преобразовать в дробь, но эта дробь ещё не является результатом дайса или выплатой.

Обычный SHA-256 от серверного сида и результат HMAC — разные вычисления. Первый нужен для сравнения обязательства; второе использует ключ и сообщение для получения байтов. Различие ключа и сообщения описано в RFC 2104, а конкретный формат Stake — в реализации.

Ниже синтетический учебный пример, не реальная ставка. Серверный сид — toolsgambling-demo-seed-2026, клиентский сид — user-demo-client, nonce (счётчик) — 42, счётчик блоков HMAC — 0. Короткий пример можно запустить в Node.js:

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

const serverSeed = 'toolsgambling-demo-seed-2026';
const clientSeed = 'user-demo-client';
const nonce = 42;
const blockIndex = 0;

const hash = createHash('sha256').update(serverSeed, 'utf8').digest('hex');
const bytes = createHmac('sha256', Buffer.from(serverSeed, 'utf8'))
  .update(`${clientSeed}:${nonce}:${blockIndex}`, 'utf8')
  .digest();
const fraction = [...bytes.subarray(0, 4)]
  .reduce((sum, byte, i) => sum + byte / 256 ** (i + 1), 0);

console.log({ hash, hmac: bytes.toString('hex'), fraction });

Хэш SHA-256 здесь равен:

9d948b54fb3d5557e30a3e100a052de2f83d4d3ad6c0166729528dd059c53b8f

Результат HMAC-SHA256 для сообщения user-demo-client:42:0:

89ae4d041d340aa2798f70bdad3ce5a2d37caf81c723c866c8d87d6a85d55436

Первые четыре байта — 137, 174, 77, 4. По правилу преобразования Stake дробь вычисляется так:

137/256 + 174/256² + 77/256³ + 4/256⁴
= 0.5378158697858453

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

Серверный сид во всех строках одинаков. Таблица показывает детерминированность: те же входы дают тот же расчёт, изменение входа меняет расчёт. Она не показывает «более удачный» сид и не содержит игровых выплат.

Почему эта формула не подходит всем провайдерам?

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

Фрагмент официального англоязычного примера BGaming: строка Result+Secret с данными в формате JSON — результатом сервера 2, идентификатором игры AmericanRoulette и секретом

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

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

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

Открой инструмент проверки Provably Fair, нажми элемент интерфейса «Попробовать на примере» и затем «ПРОВЕРИТЬ ХЕШ». Этот пример проверяет SHA-256 и отдельно показывает учебный расчёт HMAC-SHA512; он не воспроизводит ставку Stake или другой именованной игры.

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

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

Входные данные учебного примера, заполненные после нажатия кнопки «Попробовать на примере».

1. Открой страницу инструмента и нажми «Попробовать на примере».
2. Сверь четыре заполненных значения с таблицей ниже. Полный хэш приведён для копирования: в узком поле на снимке видна лишь его часть.
3. Нажми «ПРОВЕРИТЬ ХЕШ».
4. Сравни полный вычисленный SHA-256 с хэшем-обязательством, а не только первые символы.
5. Рассматривай дополнительное число 78.35 только как результат формулы этой демонстрации.

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

Совпадение хэша относится к введённой строке. Число 78.35 рассчитано по отдельной демонстрационной формуле ToolsGambling.

Дополнительный расчёт использует HMAC-SHA512: ключ — буквальный серверный сид в UTF-8, сообщение — user-demo-client:42. Далее выполняются следующие преобразования:

Здесь 78.35 получается именно делением остатка, а не округлением дроби из примера Stake. Отличаются и алгоритм HMAC, и сообщение, и преобразование байтов.

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

Что доказывает совпадение хэша, а что требует полной проверки?

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

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

Поэтому даже сообщение интерфейса «ИГРА ЧЕСТНАЯ» в нашем инструменте означает совпадение хэшей в этой проверке, а не аудит оператора. Один хэш не подтверждает RTP, лицензию, надёжность вывода средств или беспристрастный выбор сидов. Подробнее — в пошаговом руководстве по проверке и сравнении Provably Fair с сертифицированным ГСЧ.

Важно перед использованием встроенного учебного блока: обязательство в нём всегда проверяется через SHA-256. Выбор HMAC-SHA256 или HMAC-SHA512 относится только к расчёту с сообщением client:nonce. Поля «Dice» и «Crash» служат для иллюстрации: они не реализуют точные формулы Stake или любого другого провайдера. Не используй эти игровые числа как доказательство результата казино и не путай блок с отдельной демонстрацией ToolsGambling выше.

Что меняется при смене пары сидов?

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

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

Для следующей пары придерживайся короткой проверки:

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

Разумная причина смены — раскрытие данных и проверка истории, а не «удачная серия» или обязательный интервал в 50–100 ставок. Активный скрытый серверный сид не раскрывается из-за того, что у тебя есть его хэш.

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

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

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

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

Может ли новый клиентский сид повысить ожидаемую прибыль?

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

Например, в условной модели вероятность выигрыша равна 50%, а общая выплата при выигрыше составляет 1.98 на единицу ставки, включая саму ставку. Тогда ожидаемая выплата на единицу равна 0.5 × 1.98 = 0.99: RTP составляет 99%, а преимущество казино — 1%.

При суммарном обороте ставок 1000 ожидаемая чистая прибыль равна −10. Здесь оборот — сумма всех ставок, а не обязательно первоначальный депозит. Эти значения относятся только к указанной условной модели, не описывают реальную игру и не обещают конкретный итог сессии. Новый сид меняет вход расчёта, но не устраняет отрицательное математическое ожидание.