Хотя есть литература, в которой упоминаются возможности оракулов для предоставления внешних данных для смарт-контрактов в блокчейне, я новичок, и мне было интересно, есть ли успешная реализация этого.
Мне известны такие сервисы, как Oraclize и Reality Keys , которые предоставляют данные из «внешнего мира».
Какой самый развитый и задокументированный сервис для оракулов?
В каких проектах используются эти оракулы?
Существует список Dapps, которые были разработаны с использованием Oraclize и Ethereum. Но как именно здесь используется Oracle?
Рассмотрим сценарий, в котором смарт-контракту из частного блокчейна Ethereum необходимо читать/записывать данные в облачный сервис. Могу ли я создать свой собственный оракул для этого? Если да, то где я могу получить больше информации об этом?
Службы блокчейна используются для обеспечения одноранговых транзакций без доверия и безопасного распределенного хранения этих транзакций. Не будет ли концепция оракулов противоречить этому, потому что мы «доверяем» единственному источнику нашей информации? Или есть способ реализовать оракулы в системе, основанной на консенсусе?
Пожалуйста, предоставьте любые полезные источники, чтобы лучше понять Oracles. Заранее спасибо.
Марко из Oraclize здесь :)
Я думаю, что этот пост в блогеТомас Бертани, это хороший учебник для начинающих о том, что такое Оракулы и что они могут делать. Вкратце, Oracle — это третья сторона, которая предлагает получить данные, которые вам нужны, но которые вы не можете получить сами. Именно для этого Oraclize используется в экосистеме Ethereum. Смарт-контракты слепы к внешнему миру, и часто в них нужно вбрасывать данные, чтобы заставить их делать что-то полезное. Мы предоставляем эту услугу и в то же время мы также можем предоставить криптографическое доказательство нашей честности, т.е. предоставления вам неизмененных данных из источника данных. Хотя это и не идеальное решение, TlsNotary — это первый шаг в правильном направлении, направленный на устранение доверия к службе Oracle и перенос его на гораздо более крупных участников, таких как в данном случае Amazon, который управляет нотариально заверенными серверами, и на сами источники данных.
Как упомянул Эдгар, возможность проверять непосредственно из смарт-контрактов Ethereum криптографическое доказательство честности Oracle, прежде чем принимать эти данные, станет огромным шагом вперед для служб Oracle. Эта функция должна появиться до конца года, со следующим хард-форком Ethereum. Сейчас в Oraclize мы работаем над расширением наших криптографических доказательств за пределы TLSNotary и других программных подходов, и в ближайшие месяцы мы будем использовать аппаратные решения. По мере того, как стоимость контрактов растет, полезность становится все более и более важной для предоставления чрезвычайно надежных и устойчивых к атакам сервисов Oracle.
Чтобы ответить на другие ваши вопросы, вы можете посмотреть, как наши сервисы используются в упомянутом вами списке dApp, проверив код их смарт-контракта в нашем репозитории GitHub . Основная механика заключается в том, что мы подключаемся к API этих сервисов и используем метод обратного вызова _callback для отправки данных обратно в контракт, запрашивающий их.
Oraclize также работает с частными блокчейнами. Если вы заинтересованы, вы должны связаться с нами напрямую, и мы можем обсудить интеграцию. Если вместо этого вы хотите создать собственное простое специальное решение Oracle, для начала есть несколько ресурсов с открытым исходным кодом .
Эдмунд Эдгар из Reality Keys здесь. Хорошим примером использования Reality Keys является EtherOpt , децентрализованная биржа опционов. Вы можете увидеть их исходный код здесь .
Вы правы в том, что использование оракула принципиально требует некоторого доверия к оракулу, и избегание такого доверия является одной из основных причин использования блокчейнов.
Это подразумевает стандартную уязвимость «Доверенные третьи стороны — дыры в безопасности»: если Reality Keys взломают или успешно подкупят, EtherOpt заплатит не тем людям. История доверенных сторон в криптовалюте такова, что наши доверенные третьи стороны часто взламываются (или «взламываются», трудно сказать), так что это не чисто академическая проблема.
Очевидным решением является объединение нескольких оракулов, так как маловероятно, что все они будут скомпрометированы одновременно. Это очень ценно и значительно снижает риск, хотя и не так сильно, как может показаться, потому что риск оракула несколько коррелирует; Например, если в какой-то основной части бесплатной инфраструктуры, такой как SSH, существует серьезная угроза нулевого дня, это увеличивает вероятность того, что и Томас, и мы будем взломаны одновременно. Кроме того, если один из ваших оракулов скомпрометирован, это увеличивает ценность успешной атаки на остальные.
Интересный подход, над которым работал Томас, заключается в использовании нотариального заверения TLS для криптографического подтверждения того, что данные, которые он сообщает, являются теми данными, которые были опубликованы сайтом HTTPS, с которого он их получил. ИМХО, в настоящее время это в основном pr0n разработчика, а не реальная безопасность, потому что контракты не могут на самом деле проверить доказательство, поэтому все, что вам нужно сделать, это убедиться, что он был скомпрометирован, но поскольку данные оракула обычно общедоступны, и кто-то обычно имеет долю в каждый результат и стимул кричать о голубом убийстве, если их ограбят, что решает проблему, которой у нас никогда не было, не решая ту, которая у нас есть: если его взломают, вы потеряете свои деньги.
Становится интереснее, если и когда Эфириум проведет хард-форк, который позволит контрактам напрямую проверять доказательства; Однако даже в этом случае вы действительно перемещаете оракула: вам не нужно доверять мне или Томасу, чтобы предоставить правильные данные, но вам нужно доверять исходному поставщику данных, чтобы предоставить правильные данные. Преимущество этого перед тем, чтобы доверять мне или Томасу, заключается в том, что поставщик корма может быть более крупной компанией с брендом, который нужно защищать. Тем не менее, все еще существуют серьезные риски, особенно если поставщик данных на самом деле не намеревается использовать его так, как мы его используем, и в этом случае он может не защитить его должным образом или просто выдернуть ключи API из вашего контракта. нужен доступ к их ленте...
Галахад