Зачем в Blinko две схемы проверки Provably Fair
Как определить схему по полям доказательства и выбрать правильное кодирование секрета и способ расчёта.
Один вклад игрока или два
Проверка должна соответствовать входным данным и алгоритму конкретного раунда. В Blinko сохранены проверка хеш-цепочки с одним значением клиента и проверка PvP с двумя такими значениями. Внешне похожие секреты не делают эти способы взаимозаменяемыми.
Практика работает локально против ИИ без денег. Проверка её расчёта может включать звено публичной хеш-цепочки, если оно доступно, но не доказывает события серверного матча. Старые записи хеш-цепочки тоже используют схему с одним клиентским значением. Текущий LIVE, напротив, показывает реальные серверные PvP-дуэли.
В PvP сервер фиксирует свой секрет, а оба игрока добавляют собственные входные значения. Расчёт связывает эти данные с одним матчем и раундом. По ним определяются скрытый порог и первый держатель, но не итоговый победитель: принятые передачи влияют на то, у кого окажется заряд.
Хеш-цепочка: практика и старые записи
Оператор заранее создаёт длинную последовательность секретов, где каждый элемент является хешем следующего. Публикация первого элемента фиксирует последовательность: другая подходящая последовательность потребовала бы нахождения коллизии хеша.
Раунды последовательно используют звенья цепочки. Фиксация для текущего раунда — ранее раскрытый элемент. После раунда раскрывается секрет, стоящий за ним; его хеширование должно воспроизвести исходное значение. Затем цепочка продвигается ещё на одно звено.
Цепочка связывает будущие серверные секреты, а не все будущие исходы матчей. В расчёт порога также входят значение клиента и nonce — счётчик, используемый схемой. Сохранённая исходная точка цепочки позволяет проверять следующие звенья. Секрет и совпавший хеш, впервые полученные после игры, не устанавливают, когда именно хеш был опубликован.
Фиксация и раскрытие с двумя вкладами: дуэли
До дуэли сервер фиксирует секрет, а оба игрока отправляют независимые случайные значения. Эти данные определяют точку взрыва и первого держателя, но не окончательного победителя. Если вклада одного из игроков нет, раунд отменяется, а не использует неполный набор значений.
Расчёт, описанный на странице Provably Fair, включает идентификаторы матча и раунда, счётчик поколения и nonce раунда вместе с обоими значениями игроков. Фиксированный формат байтов привязывает вычисление именно к этому раунду и исключает неоднозначное расположение входных данных.
Точка взрыва и первый держатель вычисляются по общим данным, но с разными метками HMAC. Разные метки разделяют назначения этих двух расчётов. Для воспроизведения результата нужно сохранить каждую метку, кодирование секрета и порядок байтов точно так, как они опубликованы.
Текст и байты дают разные хеши
Обе схемы используют SHA-256 для фиксации секрета, но хешируют разные данные. Поэтому одного совпадения названия алгоритма недостаточно для выбора способа проверки.
Хеш-цепочка обрабатывает секрет как текст: шестнадцатеричную строку длиной 64 символа в кодировке UTF-8. Схема дуэли обрабатывает исходные 32 байта, представленные этой строкой. Значение на экране выглядит одинаково, но результаты хеширования будут совершенно разными.
Если проверить запись хеш-цепочки способом PvP, исходный хеш не совпадёт даже при согласованных значениях. Это распространённая ловушка при ручной проверке. Выбирай схему по полям доказательства, а не по странице, на которой смотрел раунд.
Как отличить одну схему от другой
У раунда хеш-цепочки есть идентификатор цепочки, индекс звена, одно значение клиента и nonce. У дуэли есть идентификаторы матча и раунда, два значения игроков, счётчик поколения и nonce раунда. Сначала сопоставь эти поля с выбранной формой проверки.
Обе схемы рассчитаны на одно распределение точек взрыва и один диапазон нагрева арены. При этом кодирование входных данных и этапы округления нужно воспроизводить точно для нужной схемы. Совпадение секрета и порога проверяет расчёт, но не является независимым аудитом каждой передачи, задержки сети или денежного результата.
Читать дальше
Частые вопросы
Почему Blinko использует две схемы проверки?
Практика и старые записи хеш-цепочки используют одно случайное значение клиента и nonce. Доказательство серверного PvP использует значения обоих игроков и идентификаторы матча. Текущий LIVE показывает настоящие PvP-дуэли, а не отдельную игру на хеш-цепочке. Выбирай схему по полям доказательства: кодирование секрета и расчёты различаются.