Все смарт-контракты функционируют в рамках свода правил виртуальной машины эфириума, которая, если сказать грубо, наделила их доступом только к своей области памяти. Контракты не могут самостоятельно читать параметры или делать запись в них в тех случаях, когда последние относятся к другим контрактам. Доступ к данным за пределами блокчейна для контрактов также отсутствует. Из доступных "механизмов общения" есть только функциональный интерфейс на уровне разрешённого и запрограммированного для этих целей набора функций доступа к внутреннему состоянию.
Функциональный интерфейс, наравне с доступом к контрактам посредством API через web3.js, достаточен для внесения информации внутрь блокчейна, но помимо технических проблем в данном вопросе есть ещё проблемы фундаментальные. Так, любые децентрализованные приложения функционируют на принципах математически доказуемой достоверности исполнения возложенных на них условий. Однако в связке с данными, поступающими из-за пределов блокчейна, данная доказуемая достоверность ставится под угрозу при возможном искажении внешней информации. Далее разберём написанное более простым языком.
Обмен данными между контрактами эфириума
Как уже было сказано, виртуальная машина эфириума навязала правила взаимодействия смарт-контрактов в сети на уровне вызова функций. Никто не может считать или записать в переменную смарт-контракта, кроме него самого. Сам контракт, обладая заранее запрограммированными функциями чтения и записи, легко может через эти функции манипулировать внутренними переменными. Всем остальным нужно также вызывать данные методы для изменения этих переменных.
Общение с функциями смарт-контрактов происходит после подключения к нему через указание его адреса и ABI-интерфейса. Это делается как при программировании контрактов для их взаимодействия, так и при обращении к контракту, например, из mist.
Но ведь мы же знаем, что есть механизм общения со смарт-контрактами и через web-интерфейс! Это и есть тот самый способ наполнения блокчейна информацией из внешнего мира. Нужно только разобраться в технике манипулирования данным интерфейсом.
Итак, для доступа к блокчейну извне виртуальной машины эфириума есть специальная библиотека web3.js, которая содержит API для работы с самой машиной и с содержимым её блокчейна. Так, через js можно подключиться к любому смарт-контракту сети и вызвать любой публичный метод. Получается, что при желании мы можем подготовить специальный контракт, который будет хранить внутри в специально отведенной для этого переменной нашу информацию. Мы снабдим этот контракт методами чтения и записи данной переменной при условии, что запись в него будет вестись только от имени указанного аккаунта. Также будем через web3.js передавать в контракт нашу внешнюю информацию.
С другой стороны виртуальной машины другие смарт-контракты смогут считывать состояние нашей переменной, зная адрес и ABI данного контракта. Таким образом, у нас получается некий интерфейс во внешнюю среду для децентрализованных приложений блокчейна эфириум.
Оракул - набор программ внутри и за пределами блокчейна для передачи внутрь блокчейна информации из-за его пределов в автоматическом режиме. Это не определение, мы его только что придумали сами. Но оно в точности отражает смысл оракулов блокчейна.
Внешние поставщики данных
Если сам механизм получения информации из внешнего мира более-менее понятен, то давайте углубимся в вопрос функционирования передающей стороны, поскольку работа по взаимодействии смарт-контрактов внутри блокчейна является привычной для любых разработчиков на solidity.
Внешняя структура оракула
На внешней стороне выделяют источник данных и программное обеспечение для получения информации с источника и передачи его в блокчейн (далее - интеграционное ПО).
В качестве источника могут выступать любые ресурсы, с которых нам понадобилась информация. Это могут быть биржи и банки, букмекерские конторы и сайты погоды, аналитические ресурсы и форекс-брокеры. Любая информация, выкладываемая в интернет, может быть источником данных для смарт-контрактов эфириума.
Здесь очень важно использовать именно первоисточник, чтобы не усложнять путь информации, поскольку на каждом посреднике информация может быть искажена. Например, первоисточником для куса рубля по отношению к доллару будет сайт нацбанка, на котором курс обновляется тем самым органом, который отвечает за его правильность. Именно с сайта нацбанка и нужно данный курс забирать, поскольку если забирать его с обычного коммерческого банка, с которого, может быть, это и было бы удобнее в техническом плане, то можно получить не актуальный курс или курс может быть искажен.
Вместе с тем если информация для оракула забирается из первоисточника, то это не значит, что она в точно таком виде, в котором и была на первоисточнике, гарантированно попадёт внутрь блокчейна. Помните, что на каждом этапе данные могут быть искажены?
Рассмотрим вопрос с позиции доверия к достоверности информации на обязательных итерациях обязательных элементов любого оракула.
Проблема доверия
- Источник - по техническим причинам информация может быть задержана или недоступна. Например, если поломался сайт официального источника информации. Такие моменты нужно обрабатывать на уровне интеграционного ПО и оговаривать при описании всего оракула.
- Скрипт - даже если сам разработчик скрипта всё сделал по-честному, интеграционный скрипт может подменить информацию, например, по причине доступа к нему хакеров, которые знают, что и с какой целью в скрипте меняют. Что уже говорить о непрозрачности самого скрипта, который представляет собой нечто с базой на серверной технологии выполнения (т.е. не просматривается полностью пользователями сети). Подменить исполняющие файлы такого скрипта не составляет большой проблемы.
- Разработчик - если разработчику не сильно важна его репутация или же если на кону стоят деньги, превышающие стоимость его репутации, то читайте пункт "Скрипт" выше.
Получается, что никакое гарантированно достоверное децентрализованное приложение не может быть гарантированно достоверным в случае использования оракулов. Как только используется внешний поставщик данных, так сразу появляется шанс, пусть и минимальный, но всё же шанс, на негарантированную достоверность работы сервиса. Но тут следует оговориться, что, во-первых, для большинства децентрализованных приложений это не критично, во-вторых, сейчас появляются сервисы-посредники, предназначенные для улучшения правдивости подобных решений, выступающие в роли гарантов (например, Oraclize, или ChainLink).
И, конечно же, нужно понимать, что подобные риски возможной недостоверности неприемлемы для сервисов, работающих с деньгами. Иначе и биткойн бы так не вырос. То же самое касается и остальных токенов.
Пример сервиса
Пример рассмотрим схематично и очень поверхностно для наглядного понимания сути работы оракулов даже для людей, далёких от программирования.
Предположим, нам нужен смарт-контракт, который принимает ставки двух участников, поспоривших о победе в футбольной игре. Принимаются деньги в ETH от обоих участников в оговоренной пропорции (например, поровну, но не суть), а выигрыш должен быть автоматически переведён на адрес того игрока, чья команда победит.
В данном условии у смарт-контракта есть потребность во внешних, по отношению к блокчейну, данных – в результате футбольной игры, т.е. в итоговом счёте. Эти данные будут анализироваться при принятии решения, кому же отдавать деньги. Назовём это контракт SK1.
Для снабжения SK1 данными об игре мы разработаем оракул на базе второго смарт-контракта (SK2) и серверного скрипта js, забирающего данные с сайта доверенной букмекерской конторы.
Изучение парсинга web-страниц не является предметом данной статьи, потому по внешней стороне оракула пройдёмся поверхностно. Подробнее остановимся на SK2 с его вызовом из js в предположении, что только от имени владельца (под его аккаунтом) можно записать результат матча в SK2.
Код SK2 будет примерно таким:
Contract sk2 {
Address owner; // переменная с блокчейн-адресом владельца
uint res; // переменная - результат матча, хранимый в блокчейне. Например, 1 – выиграла первая команда, 2 – выиграла вторая команда, 3 - ничья.
functionsk2 (){ owner = msg.snder; res = 0} // задаём владельца при создании контракта.
function getresult()constant returns(uint _res){ _res = res} // вызывается из SK1 для чтения переменной res.
functionsetresult(uint _res) _onlyowner{ res = _res} // вызывается интеграционным скриптом с внешней стороны блокчейна через web3.js. Записывает в SK2 в переменную res значение переданного извне (_res).
…}
После того, как sk2 будет добавлен в блокчейн, его реквизиты, а именно его адрес и ABI интерфейс, необходимо сохранить вместе с описанием его принципов работы. После завершения футбольного матча интеграционный скрипт на js посредством API из подключаемой стандартной для эфириума библиотеки web3.js вызовет метод sk2->setresult и запишет в блокчейн информацию о матче (внутрь переменной данного контракта). Для получения данного результата из SK1 и освобождения ставок в нужном направлении sk1 вызовет метод getresul и примет решение на основе его информации.
Как вы понимаете, для справедливого решения жизненно необходимо получить от брокера достоверную информацию. На уровне sk2 она не может исказиться, поскольку там есть проверка на разрешение изменения только для владельца, т.е. только обладатель закрытого ключа аккаунта сможет выполнить метод setresult. Букмекерская сторона обязана публиковать у себя на сайте достоверный результат матча. Это её прямая обязанность. В искажении информации она не заинтересована. На стороне интеграционного скрипта также не должно быть криминала, во всяком случае пока владелец этого скрипта или программист- разработчик не заинтересуется игрой на ставках…
Как видите, технология оракулов крайне востребована для децентрализованных приложений, но вместе с тем сопряжена с определёнными трудностями. В любом случае, при принятии решения «за» или «против» использования подобных механизмов, необходимо хорошо понимать описанные в данном материале нюансы.