Модель, которая заключает контракты, может только принимать и обрабатывать данные, вместо того, чтобы иметь возможность извлекать данные из Интернета, кажется ограничивающей (даже если нет, она менее прямолинейна). Если вас беспокоит, что данные или Интернет ненадежны, нельзя ли запрограммировать контракт на обработку таких случаев?
Существуют ли фундаментальные технические ограничения, которые привели к тому, что контракты Ethereum не могли «выйти в Интернет» напрямую?
Блокчейн Ethereum был разработан, чтобы быть полностью детерминированным. Это означает, что если я взял всю историю сети, а затем воспроизвел ее на своем компьютере, я всегда должен получить правильное состояние.
Поскольку Интернет недетерминирован и меняется со временем, каждый раз, когда я проигрывал все транзакции в сети, я получал другой ответ.
Детерминизм важен для того, чтобы узлы могли прийти к консенсусу. Если бы существовал контракт, который требовал количества голосов по этому вопросу, значение могло бы меняться время от времени или даже от места к месту, в результате чего узлы в будущем или без доступа к этому сайту приходили бы к разным выводам о состоянии сети. , тем самым нарушив консенсус.
Требуя, чтобы каждый ввод данных инициировался через внешнюю транзакцию, мы можем быть уверены, что сама цепочка блоков содержит всю информацию, необходимую для проверки себя. Этот процесс сбора данных вне сети, а затем вставки их в блокчейн известен как работа с оракулом .
Существует несколько сервисов оракула, которые позволяют смарт-контракту выглядеть так, как будто он выполняет вызов API, однако на самом деле оракул выполняет вызовы API вне цепочки и публикует результат в цепочке для использования смарт-контрактами. Некоторые из них включают Chainlink , Provable , BandChain и Tellor .
На самом деле вы можете получать данные из Интернета . Вам просто нужно, чтобы кто-то вручил это вашему контракту. Как можно доверять этому человеку? Используйте что-то вроде Provable. https://provable.xyz Это идея, которая использует TLS Notary, чтобы гарантировать подлинность ответа от веб-сервера.
Я нашел его, потому что изначально думал сделать то же самое с нотариусом TLS. Я написал об этом Виталику на Reddit 22 августа 2015 года. Он сказал следующее:
Использование контрактов ethereum для проверки HTTPS-сессий теоретически является отличной идеей; меня больше всего беспокоит то, что EVM прямо сейчас может быть слишком медленным для его реализации. Если вы хотите попробовать, не стесняйтесь провести исследование и точно посмотреть, сколько работы потребуется для этого; возможно, это возможно в пределах 3 м газа, и я хотел бы сам увидеть результаты.
Я рад, что у кого-то возникла та же идея, что и у меня, и он уже воплотил ее в жизнь. Если бы все разработки были такими простыми!
Я считаю, что это было разработано для минимизации нагрузки на сеть и сокращения ресурсов. Есть несколько решений, если вы хотите «вызов API по контракту»:
http://www.ethereum-alarm-clock.com/
Источник: https://forum.ethereum.org/discussion/3571/ethereum-alarm-clock-call-scheduling-for-contracts
pipermerriam Сообщения: 10Member ✭ Сентябрь 2015 в Общее обсуждение проекта (нетехнические) Я с гордостью объявляю о запуске сервиса Ethereum Alarm Clock.
http://www.ethereum-alarm-clock.com/
Служба Alarm облегчает планирование вызовов функций контракта для указанного номера блока в будущем. Текущий выпуск следует рассматривать как альфа-версию программного обеспечения.
Запланируйте вызовы функции контракта, которые будут выполняться в указанном блоке в будущем. Ненадежный. Никому, включая меня, не предоставляется ни административный API, ни специальный доступ. Опубликован проверяемый исходный код. Много документации с примерами. Мне очень интересно услышать отзывы людей. Не стесняйтесь, присылайте мне сообщение в pipemerriam на gitter.
Томас Бертани
Тьяден Хесс