Создание гибридных блокчейн / облачных приложений с Ethereum и Google Cloud

Принятие блокчейн-протоколов и технологий может быть ускорено путем интеграции с современными интернет-ресурсами и публичными облачными сервисами. В этом сообщении мы расскажем о нескольких приложениях, позволяющих сделать данные, размещенные в Интернете, доступными в неизменяемой общедоступной цепочке блоков: размещение данных BigQuery в цепочке с использованием интеллектуального контракта Chainlink oracle. Возможных приложений неисчислимо, но мы сосредоточили этот пост на нескольких из них, которые, по нашему мнению, имеют высокую и непосредственную полезность: рынки прогнозирования, фьючерсные контракты и конфиденциальность транзакций.

Гибридные приложения облачно-блокчейн
Blockchains сосредоточены на математических усилиях для создания общего консенсуса. Вскоре возникли идеи по расширению этой модели, позволяющей заключать соглашения между сторонами, т.е. заключать контракты. Эта концепция умных контрактов была впервые описана в статье 1997 года ученым Ником Сабо. Ранний пример записи соглашений в блоки был популяризирован такими усилиями, как «Цветные монеты» в цепочке блоков биткойнов.
nakamotoinstitute.org/the-idea-of-smart-contracts/
cloud.google.com/public-datasets

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

Но ничего из этого не решает фундаментальную проблему: где взять переменные, с которыми оценивается контракт. Если данные не получены из недавно добавленных данных в цепочке, требуется надежный источник внешних данных. Такой источник называется оракулом.

В предыдущей работе мы делали общедоступные данные блокчейна в BigQuery через Программу общедоступных наборов данных Google Cloud для восьми различных криптовалют. В этой статье мы будем называть эту работу криптографическими наборами данных Google. Вы можете найти более подробную информацию и образцы этих наборов данных на GCP Marketplace. Этот ресурс набора данных привел к тому, что ряд клиентов GCP разработали бизнес-процессы, основанные на автоматическом анализе индексированных данных блокчейна, таких как распределение прибыли SaaS, смягчение злоупотреблений услугами путем определения характеристик участников сети и использование методов статического анализа для обнаружения уязвимостей программного обеспечения и вредоносных программ. Однако эти приложения имеют общий атрибут: все они используют криптографические общедоступные наборы данных в качестве входных данных для бизнес-процесса вне цепочки.

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

Ниже мы покажем, как конкретная платформа интеллектуальных контрактов (Ethereum) может взаимодействовать с нашим облачным хранилищем корпоративных данных (BigQuery) через промежуточное программное обеспечение Oracle (Chainlink). Эта сборка компонентов позволяет «умному контракту» предпринимать действия на основе данных, извлеченных из цепного запроса в интернет-хранилище данных. Наши примеры обобщают шаблон гибридных приложений облачной блокчейн, в которых интеллектуальные контракты могут эффективно делегировать облачным ресурсам для выполнения сложных операций. Мы рассмотрим другие примеры этого шаблона в будущих сообщениях в блоге.
ethereum.org/
cloud.google.com/bigquery
chain.link/

Как мы это построили
На высоком уровне Ethereum Dapps (то есть приложения с умным контрактом) запрашивают данные из Chainlink, которая, в свою очередь, получает данные из веб-службы, созданной с помощью Google App Engine и BigQuery.

Чтобы извлечь данные из BigQuery, приложение Dapp вызывает контракт оракула Chainlink и включает в себя оплату за параметризованный запрос, который должен быть обслужен (например, цена на газ в определенный момент времени). Один или несколько узлов Chainlink прослушивают эти вызовы, и после наблюдения один выполняет запрошенное задание. Внешние адаптеры — это сервис-ориентированные модули, которые расширяют возможности узла Chainlink для аутентифицированных API, платежных шлюзов и внешних блокчейнов. В этом случае узел Chainlink взаимодействует со специально созданным веб-сервисом App Engine.
cloud.google.com/appengine/docs/the-appengine-environments

На GCP мы реализовали веб-сервис, используя стандартную среду App Engine. Мы выбрали App Engine за его низкую стоимость, высокую масштабируемость и модель развертывания без сервера. App Engine извлекает данные из BigQuery, в котором размещаются общедоступные наборы данных криптовалюты. Данные, которые мы сделали доступными, получены из постоянных запросов, то есть мы не разрешаем запрашивать произвольные данные из BigQuery, а только из результатов параметризованных запросов. В частности, приложение может запросить среднюю цену на газ либо (A) для конкретного номера блока Ethereum, либо (B) для конкретной календарной даты.

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


Как использовать оракула BigQuery Chainlink
В этом разделе мы опишем, как можно создавать полезные приложения, используя Google Cloud и Chainlink.

Вариант использования 1: рынки прогнозирования
Участники рынков прогнозирования выделяют капитал, чтобы спекулировать на будущих событиях в целом. Одной из областей, представляющих большой интерес, является то, какая платформа интеллектуальных контрактов будет преобладать, потому что, будучи сетевыми экосистемами, их ценность будет подчиняться степенному закону (то есть победителю — все). Есть много разных мнений о том, какая платформа будет успешной, а также как можно количественно оценить успех.

Используя криптографические общедоступные наборы данных, можно даже успешно прогнозировать сложные цепочки прогнозов, такие как недавняя ставка в 500 000 долларов США на будущее состояние Эфириума. Мы также задокументировали, как можно измерить разнообразие, объем, время и частоту использования Dapp, извлекая 1-, 7- и 30-дневную активность для конкретного Dapp.
www.coindesk.com/maximum-pain-joe-lubin-jimmy-song-strike-500k-crypto-bet-on-ethereums-future
www.investopedia.com/terms/m/monthly-active-user-mau.asp
mixpanel.com/topics/mobile-app-analytics-metrics/

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

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

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

Мы задокументировали, как умный контракт Ethereum может взаимодействовать с оракулом BigQuery для получения данных о цене на газ в определенный момент времени. Мы также реализовали заглушку опции умного контракта, показывающую, как оракул может быть использован для реализации обеспеченного контракта на будущие цены на газ, что является критически важным входом для функционирования Dapp.
docs.chain.link/docs/big-query-chainlink-testnet
github.com/smartcontractkit/bq-example-contract
kb.myetherwallet.com/posts/transactions/what-is-gas/

Вариант использования 3. Включение фиксации / раскрытия в Эфириуме с использованием подводных отправок
Одним из обычно упоминаемых ограничений в самом Ethereum является отсутствие конфиденциальности транзакций, что дает злоумышленникам возможность воспользоваться преимуществами утечки данных по цепочке для использования пользователями часто используемых интеллектуальных контрактов. Это может принимать форму предварительных транзакций, включающих адреса распределенного обмена (DEx). Как описано в статье «Потопить передовиков», «Отправка на подводных лодках», проблема опережающего запуска преследует все текущие DEx и замедляет прогресс движения Децентрализованные финансы, поскольку биржи являются ключевым компонентом многих продуктов / приложений DeFi.
hackingdistributed.com/2017/08/28/submarine-sends/

Используя подход отправки с подводной лодки, пользователи смарт-контрактов могут повысить конфиденциальность своих транзакций, успешно избегая противников, которые хотят их запустить, что делает DEx более полезными. Хотя этот подход уникально полезен для предотвращения злонамеренного поведения, такого как фронтальный запуск, он также имеет свои собственные ограничения, если он выполняется без оракула.

Реализация субмарины посылает без оракула, выдает блокчейн-блат. В частности, виртуальная машина Ethereum позволяет контракту видеть максимум 256 блоков вверх по цепочке или примерно один час. Этот максимальный объем ограничивает практическую полезность отправки подводных лодок, поскольку он создает ненужную денормализацию, когда требуется ретрансляция данных. В отличие от этого, благодаря реализации субмаринных отправлений с оракулом, раздувание исключается, потому что операционная область увеличена, чтобы включить все исторические данные цепочки.

Заключение
Мы продемонстрировали, как использовать сервисы Chainlink для предоставления данных из криптографических общедоступных наборов данных BigQuery в цепочке. Этот метод можно использовать для уменьшения неэффективности (случай использования для отправки с подводной лодки) и в некоторых случаях для добавления совершенно новых возможностей (вариант использования для хеджирования) Интеллектуальные контракты Ethereum, позволяющие появиться новым бизнес-моделям в сети (пример использования рынков прогнозирования).

Суть нашего подхода заключается в обмене небольшого количества времени ожидания и накладных расходов на транзакции на потенциально большую экономическую выгоду. В качестве конкретного примера, обычные отправки подводной лодки требуют хранения в цепочке, которое масштабируется O (n) с блоками, добавленными в цепочку блоков, но может быть уменьшено до O (1), если вызывающий контракт ожидает дополнительных двух блоков для вызова оракула BigQuery.

Мы ожидаем, что этот метод взаимодействия приведет разработчиков к созданию гибридных приложений, которые используют лучшее из того, что могут предложить интеллектуальные контрактные платформы и облачные платформы. Мы особенно заинтересованы в предоставлении сервисов ML облачной платформы Google Google (например, AutoML и Inference API).
cloud.google.com/automl/
cloud.google.com/inference/

Разрешая ссылаться на данные, находящиеся вне цепочки, мы повышаем операционную эффективность платформы интеллектуальных контрактов. В случае отправки с подводной лодки потребление памяти, которое масштабируется O (n) с высотой блока, уменьшается до O (1) за счет компромисса с дополнительной задержкой транзакций для взаимодействия с оракулом.