Как работает алгоритм Proof‑of‑Fortune (PoF)

1. Исходные данные: seed для случайности

Система генерирует vrf_seed — начальное значение для VRF. Обычно это:

1. хэш последнего блока блокчейна (например, TON);
2. комбинация временных меток и предыдущих результатов.

Цель: сделать seed непредсказуемым и неподменяемым.

2. Выбор валидатора через VRF

Каждый активный валидатор:

1. Берёт свой приватный ключ (sk) и vrf_seed.
2. Вычисляет candidate = VRF(sk, vrf_seed) — 256‑битное число.
3. Отправляет candidate в сеть.

Система выбирает валидатора, чей candidate:

1. попадает в заданный диапазон (например, топ‑1 по значению);
2. соответствует правилам отбора (зависит от события).

Почему это честно?

1. VRF гарантирует, что candidate невозможно предсказать без sk.
2. Любой участник может проверить корректность candidate по публичному ключу.

3. Формирование блока

Выбранный валидатор:

1. Собирает данные события:room_id — идентификатор события (например, "lottery‑2025«);список участников;правила отбора (количество победителей, формат пар и т. д.).
2. room_id — идентификатор события (например, «lottery‑2025»);
3. список участников;
4. правила отбора (количество победителей, формат пар и т. д.).
5. Вычисляет результат жеребьёвкичерез VRF:vrf_output = VRF(sk, vrf_seed_for_result) Это может быть:случайное число;перестановка списка участников;бинарный выбор.
6. случайное число;
7. перестановка списка участников;
8. бинарный выбор.
9. Заполняет заголовок блока:vrf_seed (исходный seed);vrf_output (результат жеребьёвки);merkle_root (корень Меркла для списка участников);prev_pof_block_hash (хэш предыдущего блока PoF);signature (подпись валидатора).
10. vrf_seed (исходный seed);
11. vrf_output (результат жеребьёвки);
12. merkle_root (корень Меркла для списка участников);
13. prev_pof_block_hash (хэш предыдущего блока PoF);
14. signature (подпись валидатора).
15. Подписывает блок своим приватным ключом.

4. Верификация блока сетью

Любой узел может проверить:

1. Корректность VRF:VRF_verify(pk, vrf_seed, vrf_output, proof) == true Где proof — доказательство, сгенерированное валидатором.
2. Соответствие правилам:vrf_output соответствует заявленному selection_type (например, "топ‑5«);список участников не изменён (проверка через merkle_root).
3. vrf_output соответствует заявленному selection_type (например, «топ‑5»);
4. список участников не изменён (проверка через merkle_root).
5. Подпись валидатора:подпись соответствует публичному ключу;блок не модифицирован.
6. подпись соответствует публичному ключу;
7. блок не модифицирован.

5. Финализация и запись в блокчейн

После проверки:

1. Блок транслируется в сеть (например, в TON) как транзакция смарт‑контракта PoF.
2. Блок включается в блокчейн — данные становятся неизменяемыми.
3. Результат доступен для публичного аудита через:блокчейн‑эксплореры (Tonviewer, Tonscan);терминал GoodLuckCoin.
4. блокчейн‑эксплореры (Tonviewer, Tonscan);
5. терминал GoodLuckCoin.

6. Обновление параметров

После создания блока:

1. LuckLevel валидатора увеличивается на 1 → снижает его шансы на следующий выбор.
2. LuckLevel остальных валидаторов уменьшается на 1 (но не ниже 0) → восстанавливает их шансы.
3. prev_pof_block_hash обновляется → обеспечивает связь блоков в цепи.

Эффект: предотвращает монополизацию процесса одним узлом.

Ключевые криптографические примитивы

1. VRF (Verifiable Random Function)Генерирует случайный вывод с доказательством.Невозможно подделать без приватного ключа.Проверяется публично по pk, seed и proof.
2. Генерирует случайный вывод с доказательством.
3. Невозможно подделать без приватного ключа.
4. Проверяется публично по pk, seed и proof.
5. Ed25519Алгоритм подписей → защита авторства блока.
6. Алгоритм подписей → защита авторства блока.
7. SHA‑256Хэш‑функция для merkle_root и связей блоков.
8. Хэш‑функция для merkle_root и связей блоков.
9. Дерево МерклаОбеспечивает целостность списка участников.
10. Обеспечивает целостность списка участников.

Почему это безопасно?

1. Доказуемая случайностьVRF исключает манипуляции с выбором валидатора и результатом.Любой участник может перепровернуть расчёты.
2. VRF исключает манипуляции с выбором валидатора и результатом.
3. Любой участник может перепровернуть расчёты.
4. Криптографическая защитаПодпись валидатора подтверждает авторство.Изменение блока ломает хэш‑связь (prev_pof_block_hash).
5. Подпись валидатора подтверждает авторство.
6. Изменение блока ломает хэш‑связь (prev_pof_block_hash).
7. ПрозрачностьВсе данные (seed, vrf_output, merkle_root) публичны.Правила отбора зафиксированы в смарт‑контракте.
8. Все данные (seed, vrf_output, merkle_root) публичны.
9. Правила отбора зафиксированы в смарт‑контракте.
10. ДецентрализацияНет центрального органа — выбор валидатора математически обоснован.
11. Нет центрального органа — выбор валидатора математически обоснован.

Примеры сценариев

1. ЛотереяВалидатор генерирует vrf_output → определяет победителей.Блок с результатами записывается в TON.Участники проверяют VRF и список победителей.
2. Валидатор генерирует vrf_output → определяет победителей.
3. Блок с результатами записывается в TON.
4. Участники проверяют VRF и список победителей.
5. Отбор спикеровVRF выбирает 5 спикеров из 100 кандидатов.Результат фиксируется в блоке с merkle_root.
6. VRF выбирает 5 спикеров из 100 кандидатов.
7. Результат фиксируется в блоке с merkle_root.
8. Формирование парВалидатор создаёт случайные пары для мероприятия.Блок подписывается и отправляется в сеть.
9. Валидатор создаёт случайные пары для мероприятия.
10. Блок подписывается и отправляется в сеть.

Преимущества PoF

1. Скорость: блок создаётся за секунды (без ожидания кворума).
2. Низкие затраты: один валидатор вместо множества узлов.
3. Честность: случайность подтверждена математикой.
4. Простота: узлы только проверяют, а не согласовывают.
5. Масштабируемость: поддержка тысяч событий параллельно.

Ограничения и меры защиты

1. Атака злонамеренного валидатораРешение: VRF‑проверка отвергнет некорректный vrf_output.
2. Решение: VRF‑проверка отвергнет некорректный vrf_output.
3. Задержка VRFРешение: оптимизация алгоритмов и кэширование.
4. Решение: оптимизация алгоритмов и кэширование.
5. Зависимость от TONРешение: локальное хранение блоков до синхронизации.
6. Решение: локальное хранение блоков до синхронизации.

Вывод

Proof‑of‑Fortune заменяет сложный консенсус (PoW/PoS) на математически доказуемую случайность. Ключевые идеи:

1. Один валидатор создаёт блок — но его выбор и результат проверены VRF.
2. Мгновенная финализация — без ожидания подтверждения сети.
3. Полная прозрачность — любой участник может перепроверить данные.

Это делает PoF идеальным для сценариев, где критичны:

1. честность жеребьёвки;
2. скорость финализации;
3. низкие операционные издержки.

Proof-of-Fortune (PoF) спроектирован так, чтобы минимизировать риски компрометации системы одним валидатором, даже если он действует злонамеренно. Это достигается за счёт криптографических механизмов и распределённой верификации, которые не требуют проверки всех узлов сети, но обеспечивают безопасность и прозрачность процесса. Рассмотрим ключевые аспекты.

Механизмы защиты в PoF

1. Verifiable Random Function (VRF)Выбор валидатора происходит на основе VRF — криптографической функции, которая генерирует случайное число и доказательство его корректности. Результат VRF невозможно предсказать или подделать без приватного ключа валидатора. Любой участник сети может проверить корректность VRF по открытым данным: vrf_seed, публичному ключу и vrf_output.
2. Проверка блока сетьюПосле формирования блока валидатором, сеть проверяет:Корректность VRF через функцию VRF_verify(public_key, vrf_seed, vrf_output).Соответствие vrf_output правилам отбора (например, топ-1 по значению).Целостность данных через merkle_root (корень Меркла для списка участников). Подпись валидатора, подтверждающую авторство и целостность блока.
3. Корректность VRF через функцию VRF_verify(public_key, vrf_seed, vrf_output).
4. Соответствие vrf_output правилам отбора (например, топ-1 по значению).
5. Целостность данных через merkle_root (корень Меркла для списка участников).
6. Подпись валидатора, подтверждающую авторство и целостность блока.
7. Ограничения и балансировкаСистема использует параметры, которые снижают вероятность повторного выбора одного и того же валидатора:LuckLevel — корректирующий коэффициент, который увеличивает штраф за «удачу» узла, снижая его шансы на следующий выбор. NFT-талисманы — бонусы, которые могут влиять на вероятность выбора, но их эффект ограничен.
8. LuckLevel — корректирующий коэффициент, который увеличивает штраф за «удачу» узла, снижая его шансы на следующий выбор.
9. NFT-талисманы — бонусы, которые могут влиять на вероятность выбора, но их эффект ограничен.
10. Формальная спецификация и доказательства безопасностиВ формальной спецификации PoF доказаны:Непредвзятость выбора: вероятность выбора узла не зависит от его вычислительных ресурсов. Устойчивость к Sybil-атакам: создание фальшивых узлов не увеличивает вероятность выбора из-за требования минимального стейкинга и привязки выхода VRF к публичному ключу. Безопасность и живучесть: при наличии хотя бы одного честного узла система генерирует валидные блоки и избегает форков.
11. Непредвзятость выбора: вероятность выбора узла не зависит от его вычислительных ресурсов.
12. Устойчивость к Sybil-атакам: создание фальшивых узлов не увеличивает вероятность выбора из-за требования минимального стейкинга и привязки выхода VRF к публичному ключу.
13. Безопасность и живучесть: при наличии хотя бы одного честного узла система генерирует валидные блоки и избегает форков.

Возможные угрозы и их нейтрализация

УгрозаМеханизм защитыПодделка блока злонамеренным валидаторомVRF-проверка отвергнет некорректныйvrf_output. Атака 51% (контроль большинства валидаторов)В PoF нет необходимости контролировать большинство узлов, так как выбор валидатора случаен и верифицируем. Sybil-атаки (создание множества фальшивых узлов)Минимальный стейкинг и привязка выхода VRF к публичному ключу исключают подмену. Квантовые атакиТребуется переход на постквантовые VRF.

Сравнение с другими механизмами консенсуса

МеханизмТребование проверки всех узловУстойчивость к одиночной атакеPoFНет (достаточно проверки одного блока)Высокая (благодаря VRF и верификации)PoWНет (майнеры конкурируют, но проверка блоков распределена)Уязвим при концентрации 51% мощностейPoSНет (валидаторы выбираются по стейку, но требуется кворум)Уязвим при контроле 51% стейка

Вывод

Proof-of-Fortune устойчив к компрометации одним валидатором благодаря криптографической верификации, распределённой проверке блоков и механизмам балансировки шансов. Однако система не лишена уязвимостей, например, потенциальной угрозы квантовых атак, что требует дальнейших разработок в области постквантовой криптографии. Решение квантовых атак описано в статье WaveVRF, где предлагается защита функции от квантовых атак квантовыми компьютерами, в статье приводится доказательства устойчивости функции к квантовым атакам.

WaveVRF: постквантовая проверяемая псевдослучайная функция, основанная на кодах, исправляющих ошибки

Решается квантовая атака, квантовых компьютеров на алгоритм VRF ,

https://ntv.ifmo.ru/ru/article/23339/WaveVRF:_postkvantovaya_proveryaemaya_psevdosluchaynaya_funkciya,_osnovannaya_na_kodah,_ispravlyayuschih_oshibki.htm