Что делает Web3-лотерею проверяемо честной

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

Можно даже правильно определить победителя, хотя обещанный приз так и останется обещанием.

Поэтому «записано в блокчейне» не означает «честно». Блокчейн способен сохранить данные, полученные в результате слабого или управляемого процесса.

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

Правила и срок

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

Список участников

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

Условия приза и его хранение

Участник должен понимать, что является призом и кто его контролирует. Актив под контролем смарт-контракта, актив у организатора и обещание будущего приза требуют разных доказательств.

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

Запрос случайности

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

Способ выбора победителя

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

Результат и передача приза

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

1. Опубликовать правила, срок, условия приза и способ выбора победителя.
2. Принимать заявки по этим правилам.
3. Закрыть участие и зафиксировать окончательный список.
4. Запросить случайность, связанную с нужным событием.
5. Проверить ответ, а не доверять числу от оператора.
6. Применить заранее заданное правило выбора.
7. Опубликовать результат, а состояние передачи приза показать отдельно.

Разные системы могут реализовать этот процесс по-разному. Важно сохранить непрерывную цепочку доказательств от первой заявки до итогового результата.

VRF выдаёт результат вместе с доказательством, которое проверяется по публичному ключу и заданным входным данным. RFC 9381 описывает алгоритмы проверки и свойства уникальности VRF.

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

Действительное доказательство VRF не показывает, правильно ли составлен список участников, существует ли приз и честно ли выбрано правило сопоставления. Для этих утверждений нужны отдельные данные.

Поводы для настороженности:

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

Запись итогового значения в смарт-контракт сама по себе не исправляет ни одну из этих проблем.

Прежде чем считать лотерею проверяемо честной, спросите:

• Были ли правила и срок известны до участия?
• Можно ли установить, какие заявки вошли в розыгрыш?
• Был ли список закрыт до запроса случайности?
• Определён ли приз и понятно ли, кто его контролирует?
• Связан ли случайный ответ с нужным событием?
• Можно ли независимо проверить ответ?
• Был ли способ выбора победителя задан заранее?
• Может ли кто-либо отбросить невыгодный результат и повторить запрос?
• Показаны ли выбор победителя и передача приза как разные состояния?

Неясный ответ не всегда доказывает мошенничество. Он показывает, где утверждение о честности всё ещё требует доверия.

ElyxS использует Supra dVRF для случайности в розыгрышах. Перед расчётом результата смарт-контракт проверяет ответ и связывает его с ожидаемыми запросом, розыгрышем и раундом.

Этот пример показывает только одну часть модели: система отвергает случайный ответ, который не соответствует записанному запросу. Доказательство VRF не заменяет данные о составе участников или призе.

Пользовательский путь описан в руководстве Как проверить результат розыгрыша, а общая модель контрактов — в разделе Смарт-контракты.

• Британская комиссия по азартным играм: RTS 7 — правила до участия, непредсказуемость, сопоставление и показ результата.
• RFC 9381 о VRF — алгоритмы и свойства безопасности проверяемых случайных функций.
• Рекомендации Solidity по безопасности — сложность случайности, когда производитель блока может влиять на процесс.
• Обзор Supra dVRF — общая модель проверяемой случайности, использованная в примере ElyxS.