Cлучайный оракул на основе цифровой подписи в блокчейне

[worldmind]

Ничего не понял, можно кратко по шагам принцип работы?

[deemru]

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

[worldmind]

Ну не сказать что это совсем уж понятно, «две половины являются полноценной подписью пользовательского сообщения» — зачем подписью, какого сообщения?
И какой смысл в этой хитрой схеме? Проблему доверия к оракулу она не решает, зачем тогда?

[deemru]

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

Если вам интересна данная тема, в тексте проставлены ссылки для погружения.

Останутся вопросы — задавайте по существу.

[vtools]

Совсем недавно на Хабре было про случайные числа на блокчейне. Без оракула и СМС…

[worldmind]

там как раз всё понятно, а вот тут что-то подозрительное

[deemru]

Хорошая статья размышление. Готовых решений, а тем более внедрений, ни в одном блокчейне пока нет.

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

[datacompboy]

Задача получить случайное значение заранее, чтоб избежать подтасовки со стороны казино.
Пример: игра «угадай число».
Мы отсылаем бабло и предполагаемое число в контракт. Если угадали — получаем обратно вдвое больше.

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

Делаем многоэтапно:
— клиент запрашивает сперва случайное число
— затем делает своё предположение.

Понятно же, что это не работает — клиенты начнут выигрывать.
Значит, запрашиваем не случайное число, а нечто, что используется как база для случайного числа.
Но без возможности проверки результата, ситуация ничем не лучше предыдущего.

Как обеспечить проверяемость? Простой способ: прикладывать пароль для проверки к ответу результата игры.
Без прозрачности алгоритма и возможности аудита алгоритма опять же ничем не лучше предыдущего.

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

Затем запрашиваем шифрованное число (или фиксированную соль для детерминированного алгоритма).
Делаем предположение, в ответ получаем недостающую половинку для проведения доказательства самостоятельно.

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

[worldmind]

Так всё ясно, но такие случайные числа годятся только для очень узкого класса задач, вроде только для угадай число и годится.

[datacompboy]

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

[worldmind]

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

[datacompboy]

А это совершенно другая история, с совершенно нестандартным применением случайности для реально распределённой сети.

Всё же оракулы это для уже рабочей сети, а не обспечение жизни самой сети.