Как самостоятельно проверить раунд 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 байта, которые она описывает, — разные входные данные.
Сравни полученный хеш с commit, сохранённым до игры. При несовпадении сначала проверь формат, отсутствие лишних символов и принадлежность всех полей одному раунду. Если данные точны, сохрани их вместе с идентификатором раунда для обращения в поддержку. Не отправляй пароль, одноразовые коды или приватные ключи кошелька.
Повтори расчёт
В 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 и порог, но не подтверждает события денежного матча. Запиши, какие поля совпали, какой алгоритм использован и был ли хеш сохранён до игры. Так ты сможешь повторить проверку или передать точные данные в поддержку.
Читать дальше
Частые вопросы
Что именно доказывает совпадение при проверке раунда?
Совпадение означает, что раскрытые данные воспроизводят указанные значения. Хеш, сохранённый до игры, позволяет также проверить отсутствие подмены серверного seed. Это не независимая проверка всех передач, победителя или выплаты.