Многие крипто-лотереи заявляют, что они честные. Намного меньше систем могут это действительно доказать.

Разница важна. Если выбор победителя определяет, кто получит деньги, награду, NFT или доступ, система должна быть устойчивой к скрытым манипуляциям.

Розыгрыш не становится честным только потому, что оператор так сказал. Он становится честным только тогда, когда правила, логика призов, набор участников и механизм выбора победителя можно независимо проверить.

На этом держится стандарт provably fair lottery в Web3.

Честная лотерея — это больше, чем генератор случайных чисел с призом сверху.

Системе нужны фиксированные правила, защищённая логика призов, прозрачное включение участников и источник случайности, которым нельзя тихо управлять изнутри. Если хотя бы одна из этих частей слаба, снаружи лотерея может выглядеть честной, а внутри оставаться манипулируемой.

Многие команды упускают именно это. Они концентрируются только на слое случайности и игнорируют остальную архитектуру.

Большинство нечестных лотерей ломаются не из-за экзотических криптографических проблем, а из-за архитектурных ошибок.

Самые типичные провалы:

• выбор победителя вне цепочки, когда результат определяется на сервере и публикуется постфактум;
• розыгрыши под ручным контролем администратора, когда привилегированная роль решает, какие заявки учесть или когда запускать раунд;
• изменяемые правила призов, которые могут тихо меняться после старта участия;
• скрытые или редактируемые списки участников, из-за чего пользователь не может убедиться, что его заявка реально в списке;
• слабая случайность: block timestamp, block hash, backend RNG, предсказуемые seed-логики.

Provably fair crypto lottery — это не “мы использовали случайность”. Это минимальный стандарт, который включает:

• правила фиксируются до розыгрыша;
• условия приза нельзя скрытно изменить;
• круг допустимых участников определяется прозрачно;
• источник случайности не находится под односторонним контролем оператора;
• выбор победителя можно независимо проверить.

Fairness должна покрывать весь процесс. Она начинается ещё до запроса случайности и продолжается после получения случайного значения. Если окружающая логика остаётся изменяемой или непрозрачной, система не становится по-настоящему provably fair.

Надёжная архитектура лотереи требует совместной работы пяти элементов.

### 1. Фиксированные правила участия

Система должна чётко определять, кто имеет право участвовать, что считается валидной заявкой, когда участие открывается и когда оно закрывается. Эти правила не должны меняться по ходу события.

### 2. Зафиксированная логика призов

Приз не должен изменяться скрытым образом после старта события. Участники должны понимать, что именно заблокировано, что остаётся условным и что ещё может измениться.

### 3. Прозрачный набор участников

Пользователь должен иметь возможность понять, какие заявки вошли в розыгрыш. Если финальный набор участников можно тихо редактировать, шаг случайности теряет смысл.

### 4. Проверяемая случайность

Verifiable randomness lottery требует случайности, которая непредсказуема до розыгрыша и проверяема после него. Поэтому VRF хорошо подходит для этой задачи.

Если хотите увидеть, как выглядит пользовательская проверка результата, откройте Как проверить результат розыгрыша.

### 5. Детерминированное сопоставление победителя

Даже после проверки случайности системе нужен фиксированный способ выбора победителя. Правило должно быть понятно заранее и не меняться постфактум.

“Random” и “fair” — это не одно и то же. Хорошей лотерее нужна случайность, которую невозможно предсказать до розыгрыша, и которую можно проверить после него.

Backend RNG может выдать случайное значение, но пользователю всё равно придётся доверять backend’у. Block timestamp или block hash выглядят нейтрально, но обычно недостаточно устойчивы к манипуляциям. VRF сильнее, потому что связывает результат с проверяемым доказательством.

1. Пользователи входят в розыгрыш до заранее определённого дедлайна.
2. Набор участников закрывается в этот момент.
3. Условия приза фиксируются и не могут быть скрытно изменены.
4. Система запрашивает случайность.
5. Ответ со случайностью проходит проверку.
6. По фиксированному правилу определяется победитель.
7. Любой желающий может проследить процесс и понять, как был получен результат.

VRF сам по себе fairness не решает.

Оператор всё ещё может разрушить честность до розыгрыша, если исключает участников, меняет eligibility или вмешивается в запись заявок. Система остаётся уязвимой, если привилегированные роли слишком широки и позволяют вмешиваться в критические точки процесса.

Если контракт допускает изменение сопоставления приза после получения случайности, честность снова теряет смысл. Если интерфейс скрывает критические состояния, пользователь не может оценить fairness даже при корректной архитектуре.

Полезнее всего короткий чек-лист. Если вы оцениваете лотерею или раздачу, задайте вопросы:

• Можно ли увидеть правила до начала розыгрыша?
• Понятен ли дедлайн участия?
• Можно ли менять или фильтровать заявки после дедлайна?
• Зафиксирован ли prize pool?
• Проверяема ли случайность?
• Понятно ли, как победитель вычисляется из случайного результата?
• Есть ли у оператора скрытые точки контроля?

Если ответы размыты или требуют доверия к серверу, система почти точно слабее, чем заявляет.

Системы, ориентированные на provable fairness, строят архитектуру вокруг детерминированной логики смарт-контрактов, защищённых пулов призов, ограниченных контуров контроля и проверяемой случайности.

Стек вроде Supra Move + Supra dVRF может поддерживать такую модель, соединяя детерминированное исполнение и проверяемую случайность.

Но ценность здесь не в бренде. Ценность — в дисциплине: правила, логика призов и выбор победителя ограничены системами, которые пользователь может проверить.

• Откройте Как проверить результат розыгрыша, если хотите увидеть пользовательский путь проверки результата через SupraScan.
• Откройте Смарт-контракты, если нужен технический контекст и карта пакетов протокола.
• Откройте Частые вопросы, если нужен короткий прикладной уровень без длинной теории.

Provably fair lottery в Web3 не появляется просто потому, что в конце процесса добавили случайность.

Для неё нужна надёжная архитектура от начала до конца: ясные правила участия, прозрачное включение участников, защищённая логика призов, проверяемая случайность и детерминированное сопоставление победителя.

Если хотя бы один из этих элементов остаётся непрозрачным или управляется оператором вручную, fairness оказывается слабее, чем кажется.

Стандарт такой: не “выглядит честно”, а “может быть независимо проверено”.

• Большинство Web3-лотерей нельзя считать по-настоящему честными, если пользователь не может проверить, как именно выбран победитель.
• Fairness зависит от фиксированных правил, защищённых призов, прозрачных заявок, проверяемой случайности и детерминированного выбора победителя.
• VRF полезен потому, что делает случайность проверяемой, а не оставляет её просто похожей на случайную.
• Одного VRF недостаточно, если оператор всё ещё может менять заявки, логику призов или сохранять широкие скрытые полномочия.
• Надёжная лотерея должна быть объяснима пошагово и поддаваться аудиту со стороны пользователя.