Comments 12
Ничего не понял, можно кратко по шагам принцип работы?
- пользователь получает от оракула первую половину подписи (из ничего) и держит в запасе;
- когда пользователю необходимо получить доверенной случайности, он формирует сообщение и получает от оракула вторую половину подписи, используя первую половину подписи как однозначный фиксатор;
- две половины являются полноценной подписью пользовательского сообщения — это проверяется смарт-контрактом в рамках блокчейна;
- утверждается, что вторая половина подписи обладает необходимыми свойствами для использования её в качестве доверенного источника энтропии для псевдослучайного числа.
Ну не сказать что это совсем уж понятно, «две половины являются полноценной подписью пользовательского сообщения» — зачем подписью, какого сообщения?
И какой смысл в этой хитрой схеме? Проблему доверия к оракулу она не решает, зачем тогда?
И какой смысл в этой хитрой схеме? Проблему доверия к оракулу она не решает, зачем тогда?
В статье как раз и говорится, что оракулу совершенно не обязательно доверять. Доверяем криптографии и принципам работы блокчейна.
Если вам интересна данная тема, в тексте проставлены ссылки для погружения.
Останутся вопросы — задавайте по существу.
Совсем недавно на Хабре было про случайные числа на блокчейне. Без оракула и СМС…
Задача получить случайное значение заранее, чтоб избежать подтасовки со стороны казино.
Пример: игра «угадай число».
Мы отсылаем бабло и предполагаемое число в контракт. Если угадали — получаем обратно вдвое больше.
Простор для подтасовки огромный:
— со стороны владельца контракта: генерируем всегда другое число, стрижём бабло
— со стороны клиента: если мы знаем как генерируется число, мы можем ждать «удобной» транзакции
— со стороны мощного узла: мы можем собрать удобную транзакцию сами
Делаем многоэтапно:
— клиент запрашивает сперва случайное число
— затем делает своё предположение.
Понятно же, что это не работает — клиенты начнут выигрывать.
Значит, запрашиваем не случайное число, а нечто, что используется как база для случайного числа.
Но без возможности проверки результата, ситуация ничем не лучше предыдущего.
Как обеспечить проверяемость? Простой способ: прикладывать пароль для проверки к ответу результата игры.
Без прозрачности алгоритма и возможности аудита алгоритма опять же ничем не лучше предыдущего.
Приходим к старой боброй асимметричной криптографии.
Публичный ключ известен заранее или запрашивается еще до запроса случайного числа.
Затем запрашиваем шифрованное число (или фиксированную соль для детерминированного алгоритма).
Делаем предположение, в ответ получаем недостающую половинку для проведения доказательства самостоятельно.
— Без приватного ключа мы не сможем получить само число, так что наше действие не зависит от ответа.
— Правильная криптография гарантирует существование только одного приватного ключа к выданному раньше публичному — то есть сервер не может выбрать более хороший ключ
Пример: игра «угадай число».
Мы отсылаем бабло и предполагаемое число в контракт. Если угадали — получаем обратно вдвое больше.
Простор для подтасовки огромный:
— со стороны владельца контракта: генерируем всегда другое число, стрижём бабло
— со стороны клиента: если мы знаем как генерируется число, мы можем ждать «удобной» транзакции
— со стороны мощного узла: мы можем собрать удобную транзакцию сами
Делаем многоэтапно:
— клиент запрашивает сперва случайное число
— затем делает своё предположение.
Понятно же, что это не работает — клиенты начнут выигрывать.
Значит, запрашиваем не случайное число, а нечто, что используется как база для случайного числа.
Но без возможности проверки результата, ситуация ничем не лучше предыдущего.
Как обеспечить проверяемость? Простой способ: прикладывать пароль для проверки к ответу результата игры.
Без прозрачности алгоритма и возможности аудита алгоритма опять же ничем не лучше предыдущего.
Приходим к старой боброй асимметричной криптографии.
Публичный ключ известен заранее или запрашивается еще до запроса случайного числа.
Затем запрашиваем шифрованное число (или фиксированную соль для детерминированного алгоритма).
Делаем предположение, в ответ получаем недостающую половинку для проведения доказательства самостоятельно.
— Без приватного ключа мы не сможем получить само число, так что наше действие не зависит от ответа.
— Правильная криптография гарантирует существование только одного приватного ключа к выданному раньше публичному — то есть сервер не может выбрать более хороший ключ
Так всё ясно, но такие случайные числа годятся только для очень узкого класса задач, вроде только для угадай число и годится.
К сожалению, я не представляю как обеспечить доверие рандомности данных полученным хз откуда. Всегда может оказаться что шумящий диод просто подогрели.
Ну я скорее про проблему договориться в кластере об общем случайном числе, если нам, например, нужно выбрать случаный узел, который будет подписывать следующий блок, то такой вариант с оракулом не подойдёт, ибо он означает, что оракул будет назначать подписантов и сможет продвинуть своих людей в таковые.
Sign up to leave a comment.
Cлучайный оракул на основе цифровой подписи в блокчейне