The Graph: великий, но не такой уж и ужасный
Всем привет! В этой статье мы рассмотрим The Graph, зачем он нужен и как у блокчейна может быть API.
Введение
Давайте представим, что мы делаем приложение, которое будет считать объем торгов на Uniswap за последний месяц.
Uniswap это и без нас делает вот тут, используя The Graph, но опустим этот момент.
Так вот, встает вопрос: как же это сделать?
Способ №1
Давайте напишем простой скрипт, который будет с какой-то периодичностью получать текущий номер блока и искать ивенты “Swap” на заранее заданном контракте пула.
- RPC: они имеют свойство ломаться, и мы рискуем пропустить несколько блоков, тем самым на выходе получить некорректные данные.
- Масштабируемость: когда мы захотим отслеживать не только один пул, а все возможные новые, то тут придется заморочиться.
- Архитектура: вставлять модуль, который как-то циклично собирает данные в основное приложение, не очень хорошая идея, нужно его куда-то выносить.
Подход 2
Делать как Aerofrome/Velodrome - свой отдельный контракт с аналитикой.
Вот тут можно посмотреть код: https://github.com/aerodrome-finance/sugar
Вызвав метод epochLatest, мы можем получить данные по последней эпохе или получить данные по каждой эпохе для пула, вызывая epochByAddress.
Таким образом, мы плавно переходим к The Graph.
Subgrpaph
The Graph - это протокол, который включает в себя такие сущности, как сабграфы (subgraph).
Каждый сабграф представляет из себя набор логики, позволяющий обрабатывать набор контрактов.
Если приводить очень простой пример
Представьте, что у вас есть большая библиотека, наполненная большим количеством книг на разные темы. Эта библиотека настолько большая, что поиск информации по определенной теме может оказаться очень сложным и отнять много времени. И руководство библиотеки решает нанять библиотекарей, чтобы каждый отвечал за отдельный раздел этой библиотеки: выдавал нужные книги, сортировал и следил за порядком.
В этом примере библиотека - это блокчейн, а библиотекари - это сабграфы.
Каждый сабграф отслеживает emit событий на контрактах и сохраняет их в свою внутреннюю базу данных, чтобы потом любое приложение могло получить данные о свапах, транзакциях пользователя или еще о каких-либо действиях, произошедших в контрактах, используя GraphQL.
Важно понимать, что сабграф - это больше data layer, чем полноценный бэкенд.
Если логика не требует дополнительных расчетов, то можно обойтись только сабграфом и веб-интерфейсом, но если вам необходимо отсылать какие-то уведомления в Slack или как-то по-хитрому агрегировать уже полученные данные, то будет необходимо построить бэкенд, который будет заниматься промежуточной обработкой, прежде чем отдавать их на фронт.
Создание сабграфа
Чтобы развернуть свой сабграф, вам необходимо сделать следующие вещи:
- Создать обработчики событий, используя AssemblyScript (TypeScript, но с определенными ограничениями).
- Задеплоить код в Subgraph Studio - это среда (по сути staging environment) для тестирования и отладки работы сабграфа.
- Опубликовать в Subgraph Network, для этого необходимо ~3000 GRT, которые вы залочите, но в любой момент сможете вытащить.
YAML
Первым компонентом необходимо создать .yaml файл, где будет указано, какие события, как часто мы “слушаем”, и какую логику мы хотим с ними сделать.
В качестве примера я взял код PancakeSwap: GitHub PancakeSwap.
Schema
Также для создания сабграфа нам нужна схема сущностей, чтобы сгенерировать типы.
Handler
Далее нам необходимо создать обработчик, который будет сохранять события в базу данных.
Указанных выше компонентов нам будет достаточно, чтобы создать полностью рабочий сабграф.
Все остальные шаги в полной мере описывает документация: https://thegraph.com/docs/en/.
Рекомендую читать английскую версию, так как в русской есть места, которые еще не переведены.