Как самостоятельно проверить раунд Blinko
Какие значения сохранить, как выбрать нужный алгоритм и что означает совпадение результата проверки.
Сначала сохраните исходное обещание
Проверку нужно разделять на две части. Первая: раскрытое серверное значение, или server seed, должно соответствовать хешу, сохранённому до начала игры. Вторая: полный набор опубликованных входных данных должен воспроизводить скрытый порог взрыва и, для PvP, начального держателя заряда. Это проверка входных значений и вычисления, а не независимый аудит всего матча.
Если взять и хеш, и seed только из ответа после раунда, можно проверить их согласованность. Но такое совпадение не доказывает, когда хеш появился впервые: подходящую пару можно посчитать уже после события. Поэтому сохранённое до игры обязательство, называемое commit, имеет самостоятельное значение. Не заменяйте его новым значением из истории, если цель — проверить отсутствие последующей подмены.
Выберите тип доказательства
У разных режимов различается формат вычисления. В доказательстве серверной PvP-дуэли есть matchId, roundId, generation, roundNonce и два клиентских seed: hostClientSeed и guestClientSeed. Для проверки также нужен раскрытый serverSeed. Используйте точные значения из доказательства конкретного раунда: перестановка игроков или замена счётчика меняет входные данные.
У расчёта по хеш-цепочке используются server seed, один client seed и nonce. Такой пример нельзя выдавать за доказательство денежного PvP-матча. В браузерной проверке нужно выбрать соответствующую схему. Если данных нет или формат непонятен, это ещё не означает провал честности: сначала нужно получить полный набор полей нужного раунда.
Проверьте хеш server seed
Для PvP хеш SHA-256 вычисляется от исходных 32 байт серверного seed. Его шестнадцатеричная запись сначала преобразуется в байты. Для схемы хеш-цепочки используется другой способ: SHA-256 берётся от самого текста шестнадцатеричной строки в UTF-8. Строка из 64 символов и 32 байта, которые она описывает, — разные входные данные.
Сравните полученный хеш с обязательством, сохранённым до игры. При несовпадении не переходите к выводу о корректности порога: сначала проверьте формат, отсутствие лишних символов и принадлежность полей одному раунду. Если данные точны, сохраните их вместе с идентификатором раунда для обращения в поддержку. Не отправляйте пароль, одноразовые коды или приватные ключи кошелька.
Воспроизведите вычисление
В PvP идентификаторы матча и раунда, два счётчика и seed обоих игроков собираются в канонический набор байт. На его основе и server seed вычисляются отдельные HMAC-SHA-256 для порога взрыва и первого держателя. Разделение назначений важно: это не один и тот же хеш с двумя произвольно выбранными кусками. Страница честности объясняет общую схему; точные шаги приведены ниже.
Порог PvP называется thresholdCent и выражен в целых градусах арены. Внутреннее значение B — тот же порог, делённый на 100. Не сравнивайте, например, 477 с 4,77 как разные результаты. Для ручного повторения расчёта используйте арифметику и округление именно своей схемы: похожая десятичная формула не заменяет точную обработку целых чисел.
Точный порядок вычисления PvP
Соберите context последовательным соединением байт: UTF-8 строки blinko.fairness.v3; один нулевой байт 0x00; 32 байта SHA-256 от UTF-8 строки matchId; 32 байта SHA-256 от UTF-8 строки roundId; generation как беззнаковое 64-битное целое в порядке big-endian; roundNonce в таком же формате; байты из hex-строки hostClientSeed; затем байты из hex-строки guestClientSeed. Разделители между остальными частями не добавляются. Вычислите entropy = SHA-256(context).
Ключ обоих HMAC — байты из hex-строки serverSeed. Сообщение для порога: UTF-8 строки blinko.explosion.v3, один байт 0x00 и 32 байта entropy. Сообщение для держателя: UTF-8 строки blinko.holder.v3, один байт 0x00 и те же 32 байта entropy. Получите HMAC-SHA-256 каждого сообщения. Эти служебные строки входят в вычисление буквально, включая точки и цифру; их нельзя переводить или сокращать.
Из HMAC порога возьмите первые 13 hex-символов и преобразуйте их в целое x. Используйте точную целочисленную арифметику: E = 2^52, d = E − x, variable = floor((95 × E + floor(d/2))/d). Тогда thresholdCent = min(10000, max(280, 185 + variable)), а B = thresholdCent/100. Для первого держателя возьмите младший бит первого байта второго HMAC: 0 означает host, 1 означает guest. Сравните результат с полями доказательства, не с приблизительным моментом окончания экранной анимации.
Учебный пример хеш-цепочки
Для проверки работы инструментов можно использовать раскрытый пример: server seed 53c095ce747f1b473b564bbf66df4be4e069d93f10405f6ed11f03e4e973af41, client seed player-m35kue и nonce 41. SHA-256 текста server seed даёт 87a1ced498db265b07a34da90df08d088a74ee429dc2a041aef50c8cef827c94. HMAC-SHA-256 вычисляется с этим текстовым seed как ключом и сообщением player-m35kue:41.
Первые 13 шестнадцатеричных символов HMAC задают число x из 52 бит. После деления на 2 в степени 52 получаем u. Для этой схемы B = 2,80 + 0,95/(1 − u) − 0,95, с округлением до сотых и ограничением от 2,80 до 100,00. В примере B = 4,77, то есть 477 градусов. Это пример воспроизведения расчёта, не доказательство времени публикации хеша и не доказательство USDT-дуэли.
Границы результата проверки
Совпадение означает, что опубликованные входные данные воспроизводят указанные значения. В сочетании с заранее сохранённым commit оно позволяет проверить отсутствие подмены серверного seed. Это не гарантирует победу, равенство задержек сети, отсутствие ошибок интерфейса или завершение перевода денег. Механика дуэли и расчёт комиссии — отдельные вопросы.
Практика выполняется локально без денежной ставки. Её проверка может подтвердить согласованность seed и порога, но не подтверждает серверные события денежного матча. Формулируйте вывод проверки узко: какие именно поля совпали, какой алгоритм использован и было ли обязательство сохранено заранее. Так результат остаётся проверяемым фактом, а не общим обещанием безопасности.