Как участники проверяют валидность выбора валидатора в Proof‑of‑Fortune (PoF) GoodLuckCoin

В механизме PoF выбор валидатора для формирования блока полностью прозрачен и поддаётся независимой проверке. Это обеспечивается за счёт криптографического инструмента — Verifiable Random Function (VRF). Разберём, как именно участники могут удостовериться в корректности процесса.

Что подлежит проверке

Перед созданием блока нужно подтвердить:

1. Корректность генерации случайного значения (vrf_output).
2. Правомерность выбора валидатора (его candidate действительно попадает в допустимый диапазон).
3. Отсутствие манипуляций с параметрами отбора.

Пошаговый алгоритм проверки

1. Получение исходных данных

Участник запрашивает из блокчейна TON:

1. vrf_seed — начальное значение, использованное для расчёта (обычно берётся из хэша последнего блока TON);
2. публичный ключ выбранного валидатора;
3. vrf_output — результат работы VRF;
4. параметры диапазона отбора (например, «топ‑1 по значению candidate»).

Эти данные доступны в:

1. последнем блоке PoF, записанном в TON;
2. интерфейсе терминала GoodLuckCoin;
3. блокчейн‑эксплорере TON (через смарт‑контракт PoF).

2. Локальный расчёт candidate

Участник самостоятельно выполняет VRF‑вычисление:candidate = VRF(public_key_валидатора, vrf_seed)

Для этого используется:

1. открытый алгоритм VRF (стандартизован, например, RFC 6979);
2. библиотека криптографических функций (доступна в SDK GoodLuckCoin).

3. Сравнение с диапазоном отбора

Участник проверяет, попадает ли полученный candidate в заданный диапазон:

1. Если система выбирает «топ‑1», то candidate валидатора должен быть максимальным среди всех возможных.
2. Если диапазон задан как «первые 5 значений», то candidate должен входить в эту пятёрку.

4. Верификация VRF

Участник запускает проверку:VRF_verify(public_key, vrf_seed, vrf_output) == true

Это подтверждает:

1. vrf_output действительно сгенерирован на основе vrf_seed и приватного ключа валидатора;
2. результат не подделан.

5. Контроль параметров события

Участник убеждается, что:

1. vrf_seed соответствует хэшу последнего блока TON (исключает подмену источника случайности);
2. правила отбора (selection_type) не изменены постфактум;
3. LuckLevel валидатора учтён корректно (нет необоснованного преимущества).

Где взять данные для проверки

1. Блокчейн TONВсе транзакции PoF хранятся в смарт‑контракте.Доступ через эксплореры: Tonviewer, Tonscan.
2. Все транзакции PoF хранятся в смарт‑контракте.
3. Доступ через эксплореры: Tonviewer, Tonscan.
4. Интерфейс GoodLuckCoinВ терминале есть раздел «Проверка валидатора» с автоматизированным калькулятором VRF.
5. В терминале есть раздел «Проверка валидатора» с автоматизированным калькулятором VRF.
6. API PoFПрограммируемый доступ к данным блоков и параметрам VRF.
7. Программируемый доступ к данным блоков и параметрам VRF.

Примеры проверок

Сценарий 1: подозрение на подмену валидатора

1. Участник видит, что валидатор № 42 выбран, но его candidate не максимальный.
2. Проверка: локальный расчёт candidate для всех валидаторов показывает, что № 15 имел большее значение.
3. Вывод: выбор некорректен — система нарушила правила.

Сценарий 2: проверка случайности

1. Участник сравнивает vrf_output с ожидаемым распределением значений.
2. Если результаты систематически отклоняются от равномерного распределения — возможна уязвимость VRF.
3. Верификация через VRF_verify подтверждает или опровергает подозрения.

Почему это надёжно

1. Криптографическая гарантияVRF основан на эллиптических кривых (Ed25519) — взлом вычислительно невозможен.Подделка vrf_output без приватного ключа исключена.
2. VRF основан на эллиптических кривых (Ed25519) — взлом вычислительно невозможен.
3. Подделка vrf_output без приватного ключа исключена.
4. Открытость данныхВсе входные параметры (vrf_seed, публичный ключ) публичны.Алгоритм VRF стандартизован и проверен сообществом.
5. Все входные параметры (vrf_seed, публичный ключ) публичны.
6. Алгоритм VRF стандартизован и проверен сообществом.
7. Независимость проверкиУчастник не зависит от системы — он может верифицировать всё локально.Нет «чёрных ящиков»: каждый шаг прозрачен.
8. Участник не зависит от системы — он может верифицировать всё локально.
9. Нет «чёрных ящиков»: каждый шаг прозрачен.

Что делать, если обнаружена ошибка

1. Зафиксировать доказательстваСохранить хэши блоков, значения vrf_seed, vrf_output, публичные ключи.
2. Сохранить хэши блоков, значения vrf_seed, vrf_output, публичные ключи.
3. Опубликовать результаты проверкиЧерез форум GoodLuckCoin, соцсети, GitHub.
4. Через форум GoodLuckCoin, соцсети, GitHub.
5. Обратиться в поддержку PoFПредоставить лог верификации — команда проверит и при необходимости инициирует расследование.
6. Предоставить лог верификации — команда проверит и при необходимости инициирует расследование.
7. Использовать арбитражЕсли спор не урегулирован, можно привлечь независимых экспертов или децентрализованный суд (если предусмотрен в правилах PoF).
8. Если спор не урегулирован, можно привлечь независимых экспертов или децентрализованный суд (если предусмотрен в правилах PoF).

Вывод

Механизм проверки валидатора в PoF построен на трёх принципах:

1. Доказуемая случайность (VRF);
2. Полная прозрачность (все данные в TON);
3. Самостоятельность проверки (любой участник может верифицировать процесс).

Это исключает:

1. манипуляции с выбором валидатора;
2. скрытые правила отбора;
3. зависимость от централизованных органов.

Таким образом, PoF сочетает скорость единичного валидатора с надёжностью коллективного консенсуса — благодаря криптографии, а не доверию.