Можете сделать простой пример чтобы было понятно?
При чём тут signer? Нужен код dapp
Пример кода: https://waves-ide.com/s/6477185ae40ef7002a7c207b
Спасибо, сейчас попробую
Я правильно понимаю, что VRF это типа уникальная подпись блока(типа случайное число)? И суть этого похода будет сводиться к алгоритму: 1) С клиента взывать метод commit который запишет в данные блокчейна через сколько ждать блок с ответом (например, + 1) 2) Ожидать на клиенте пока высота дойдет до нужного блока 3) С клиента запросить второй метод reveal и получить собственно VRF от высоты загонного блока Верно?
- уникальная и детерминированная (что для нас в случае рандома самое важное), это проверяется консенсусом сети - 1) запишет все необходимые данные, которые дальше не могут больше меняться - 2) да - 3) запросить результат, который является однозначно посчитанным и проверенным = result( commit + reveal )
Но если VRF уже уникален, почему он не безопасен? Типа я могу за один блок успеть узнать его VRF и после этого использовать это чтобы обмануть игру? Следуя этой логике, если очень быстро запрашивать данные то ID транзакции из Invocation можно тоже предугадать. В алгоритме commit-reveal подразумеваться ожидание, а блокчей и так медленно работает. В тестовой сети после выполнения метода и потом запроса данных через api занимает у меня 3-8 секунд, на генерацию N блоков могу уйти минуты. ( Выходит нормального варианта нет? Я вижу только: 1) Или мы долго ждем - что убивает любую динамическую игру 2) Или мы используем оракул - накладывает дополнительные траты и делает не прозрачным механизм получения рандома 3) Или мы как в моем случае работаем с данными которые можно предугадать Есть какой-то стандартный оракул к которому можно обратиться для рандома? Сколько будет стоить каждый такой вызов?
Других честных вариантов проверяемых консенсусом сети не придумано. Быстрее можно только через ключ на бэкенде: https://habr.com/ru/companies/waves/articles/464357/
Обсуждают сегодня