Что такое The Graph, как создать subgraph, и как это поможет Вашему dApp?
Большинство Ethereum dApps состоят из двух частей (простая версия):
- Front-end (запуск в браузере)
- Узел Ethereum (интерфейс с сетью ETH)
Когда транзакция происходит в Ethereum, происходит генерация транзакций. Front-end отслеживает эти события и соответствующим образом обновляет пользовательский интерфейс. dApps могут выполнять ограниченные типы запросов к узлу Ethereum для отображения данных во Front-end.
Но dApps не могут существовать только на основе транзакций, событий и минимальных запросов. Чтобы обеспечить полноценный пользовательский интерфейс, dApp должно обрабатывать как минимум свои собственные данные, отображать активность конкретного пользователя, создавать профиль пользователя, показывать аналитику и включать несколько функций … Как мы можем сделать все это сейчас?
Ряд команд разработчиков dApp делают это, создавая свои собственные индивидуальные решения — очищая данные блокчейна, отслеживая события, транзакции и сохраняя их в традиционной централизованной базе данных. Но мы же хотим минимизировать доверие к web3, верно?
Подводя итог -
«DApps нуждаются в индексированных данных для выполнения крупномасштабных запросов, чтобы обеспечить полноценное взаимодействие с пользователем с минимальным доверием»
Введение: The Graph.
Что такое The Graph?
Команда Graph решает проблему, создавая децентрализованный протокол, который будет активирован узлами Graph, обрабатывающими события Ethereum и сохраняющими их в виде индексированных данных, которые dApps могут запрашивать через конечную точку API.
Graph Protocol попадает в категорию, которую мы называем layer 2 read-scalability solution. Его цель состоит в том, чтобы позволить децентрализованным приложениям (dApps) эффективно и без доверия запрашивать данные общедоступной цепочки блоков через службу, которая, подобно цепочкам блоков и самому Интернету, работает как общественная утилита. Это делается в интересах сведения к минимуму роли хрупкой централизованной инфраструктуры, наблюдаемой сегодня во многих «децентрализованных» архитектурах приложений. — Спецификация Graph Protocol
Эти индексы (“subgraphs”) в настоящее время находятся на хостинге команды The Graph. Но в будущем эти индексы будут существовать на полностью децентрализованной сети графических узлов.
Как работает The Graph ?
Давайте разберемся, как на самом деле работает “Граф”:
- dApps (через свои смарт-контракты) создают транзакции Ethereum, которые генерируют события.
- Graph Nodes сканируют каждый блок Ethereum в поисках событий.
- Graph Nodes находят события для вашего подграфа в блоках Ethereum и запускают предоставленные вами обработчики mappings. Mapping определяет, как данные будут храниться и обновляться в узлах графиков.
- Ваше dApp может запрашивать эти данные через API GraphQL, которые переводятся узлами Graph для получения индексированных данных.
Так чего же мы ждем? Давайте создадим subgraph!
Создание Subgraph
Давайте воспользуемся образцом “умного” контракта с проектом Truffle и создадим Subgraph.
Graph Explorer
С помощью Graph Explorer вы можете исследовать другие Subgraph, созданные сообществом. Мы также можем запрашивать с используя Graph Explorer UI.
Нам нужно создать учетную запись в Graph Explorer и получить Access token, который будет использоваться при развертывании нашего подграфа на Graph Nodes (размещенных командой Graph). Итак, давайте создадим учетную запись в Graph Explorer.
Создайте Subgraph с помощью Graph Explorer UI с именем «example».
Теперь нам нужно установить Graph-CLI в нашу систему (я использую Ubuntu 16.10):
sudo yarn global add @graphprotocol/graph-cliСоздадим пример-субграф, используя команду ниже:
graph init buddies2705/example-subgraph example-subgraph// Command Syntax graph init <GITHUB_USER>/<SUBGRAPH_NAME> <DIRECTORY>// Here Direcotry is optional, if you don't pass it it will create a directory with SUBGRAPH_NAME
Давайте установим зависимость и сгенерируем mappings:
//Install Dependencies yarn//Generate Mappingsyarn codegen
Давайте установим Auth с помощью Access token (мы можем получить Access token из панели управления Graph Explorer):
graph auth https://api.thegraph.com/deploy/<ACCESS_TOKEN>Теперь мы можем развернуть наш Subgraph в Graph Explorer, используя следующую команду:
graph deploy --debug --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ buddies2705/example
//You can see we are using buddies/example where "buddies2705" is my //github username and "example" is our subgraph name create using //Graph explorer UI.
Теперь откройте Graph Explorer, и вы увидите свой Subgraph. Вы также можете запросить свой Subgraphс помощью the Graph Explorer UI. Вы также можете видеть конечные точки для программного взаимодействия с вашим Subgraph.
Under the Hood
Давайте углубимся и разберемся, что произошло “Under the Hood”. У нас был проект Truffle с контрактом Gravity.sol, который просто создает Gravatar (ваш аватар в Интернете) на Ethereum.
В рамках данного контракта происходит два действия:
- NewGravatar - когда создается новый Gravatar
- UpdatedGravatar - при обновлении существующего Gravatar
event NewGravatar(uint id, address owner, string displayName, string imageUrl);event UpdatedGravatar(uint id, address owner, string displayName, string imageUrl);
Если мы проиндексируем эти два действия Data, то сможем отвечать на запросы типа:
- Сколько Gravatar было создано в прошлом году?
- Сколько Gravatar обновляется в среднем в день?
- Какие 10 лучших хостов изображений для всех наших Gravatars? (это будет IPFS 😎)
- Каковы наиболее распространенные названия Gravatars?
Некоторые из этих запросов должны выполняться с полными данными контракта с момента его развертывания, а это невозможно из обычных запросов web3. Вам нужны индексированные данные.
С помощью The Graph вы можете создавать mappings для индексации этих данных, которые будут находиться в the Data-store (в настоящее время Postgres). Итак, давайте посмотрим, как создаются mappings:
Important Files
Давайте сначала посмотрим на subgraph.yaml, который определяет все mappings:
Давайте посмотрим на важные поля этого файла:
dataSources: Data sources будут иметь все смарт-контракты, которые вы хотите отслеживать. (В нашем случае только 1).
Все остальные поля говорят сами за себя, поэтому давайте рассмотрим поле eventHandlers, которое определяет mappings:
eventHandles: В этом поле мы определим наши отображения. Мы добавим события и функции, которые будут обрабатывать эти события. Например, мы определяем handleNewGravatar для NewGravatar.
file: В этом поле будет находиться наш Mapping file, содержащий функции обработчика событий, в нашем случае это mapping.ts.
mapping.ts - это то место, где вы реализуете event handlers ... event handlers будут выполняться всякий раз, когда будут генерироваться наши события Gravatar, создавая объекты и сохраняя их в хранилище, как мы описали в наших функциях event handlers.
Вы можете видеть, что мы импортируем два файла, Gravity.ts и Schema.ts - оба файла создаются, когда мы запускаем yarn codegen. Эти файлы содержат типы, которые упрощают работу с контрактами, событиями и объектами. У нас также есть schema.graphql, который будет содержать сущности.
type Gravatar @entity {
id: ID!
owner: Bytes!
displayName: String!
imageUrl: String!
}Наш файл schema.ts создается с использованием этого schema.graphql, а наш файл Gravity.ts создается на основе смарт-контракта Gravity.sol.
Существует множество концепций GraphQL. Если вы не знаете о GraphQL, вы можете создать базовый subgraph с минимальным пониманием GraphQL.
Создайте subgraph для dApp
Если вы используете dApp, вы, вероятно, столкнулись с Data problem
Ниже приведены шаги, которые вам нужно будет выполнить для создания настраиваемого subgraph для вашего dApp (как описано выше)..
- Установите Graph-CLI и другие dependencies
- Создайте subgraph.yaml
- Создайте schema.graphql
- Создайте schema files
- Создайте Mapping file с event handlers
Полезные команды
Graph-CLI предоставляет полезные команды, которые вы можете записать в package.json.
Мы создали базовый subgraph FOMO3d, проверьте его!
Заключение
Лучшее свойство, которое люди до сих пор не осознают, - это то, что инфраструктура Web3 позволит создавать автономные интернет-приложения, которые могут работать в обозримом будущем без какого-либо обслуживания.
Децентрализация и минимизация доверия - это сложная проблема. Команда Graph пытается сделать это и построить важную часть инфраструктуры dApp. Если вы создаете масштабируемое децентрализованное приложение, вам следует изучить протокол The Graph!
