The Graph (GRT): протокол индексирования и запросов Web3

The Graph — децентрализованный протокол индексирования и запросов к блокчейн-данным. Он решает проблему «сырых» данных: блокчейны хранят транзакции и события в форме, неудобной для приложений, аналитики и интерфейсов. The Graph позволяет разработчикам описывать схемы извлечения и агрегирования, а сети независимых операторов — индексировать цепочки и обслуживать запросы GraphQL с предсказуемой задержкой. Экономика протокола строится на токене GRT, который используется для стейкинга индексерами, сигналов кураторов и делегирования.

Для AI/данных The Graph можно рассматривать как «канал доставки фактов» в продуктовые пайплайны: индексы субграфов превращают события блокчейна в удобные сущности (позиции, пулы, голосования, метрики), которые затем легко подмешивать в поисковые/аналитические контуры, включая ретривер из RAG и векторные индексы (см. эмбеддинги и обзор векторных БД). Это снижает затраты на собственные ETL и улучшает воспроизводимость данных.

Кому и зачем нужен The Graph (GRT)

• Разработчикам dApp и протоколов. Удобный слой данных поверх событий/логов, единый API (GraphQL), ускорение фронтенда и интеграций.
• Аналитикам/BI. Быстрые сводки по пулам, позициям, протоколам без ручного парсинга блоков; унификация схем.
• Поставщикам данных/операторам. Возможность монетизировать работу по индексированию и обслуживанию запросов.
• Исследователям/контент-командам. Реплицируемые цифры и источники: метрики берутся из конкретных субграфов.

Ключевая идея: описываем схему и логику извлечения как код (сабграф), публикуем её в реестр — и получаем сетевую «машину» для поддержания индекса в актуальном состоянии.

Базовые понятия: сабграфы и роли участников

Сабграф (subgraph) — это декларативное описание:

• какие события/сущности из блокчейна извлекать;
• как их трансформировать/агрегировать;
• какие типы данных и связи представлять через GraphQL.

Роли в протоколе:

• Индексеры (Indexers). Запускают узлы индексирования, стейкают GRT, обслуживают запросы; получают плату за запросы и инфляционные награды; рискуют слешингом при злонамеренной/некачественной работе.
• Кураторы (Curators). Сигнализируют, какие сабграфы ценны рынку (экономические «лайки») — размещают GRT на криваях бондинга субграфов и получают долю комиссий за запросы.
• Делегаторы (Delegators). Передают свой GRT индексерам (без запуска узлов) и получают долю доходов пропорционально делегированию с учётом комиссий индексера.
• Потребители (Consumers). Платят за запросы к субграфам (через шлюз/маршрутизатор) и получают ответы GraphQL с нужными SLA.
• Авторы сабграфов (Developers). Пишут схемы/мэппинги, публикуют их и поддерживают версионность.

Таким образом, протокол формирует рынок данных: сигнал — какие индексы нужны, капитал — кто готов обеспечить SLA, спрос — кто платит за доступ.

Архитектура и поток данных

1. Публикация сабграфа. Разработчик описывает схему (GraphQL-типы) и мэппинги для событий/вызовов контрактов, регистрирует сабграф в каталоге.
2. Курация. Кураторы вкладывают GRT на бондинговой кривой сабграфа — сигнализируя индексерам, что спрос вероятно будет.
3. Выбор индексерами. Индексеры поднимают/обновляют индексы субграфов с максимальной ожидаемой доходностью (спрос × качество сигнала × комиссии).
4. Обслуживание запросов. Потребители посылают GraphQL-запросы через шлюз; маршрут выбирается среди индексеров, выполняющих сабграф.
5. Расчёты. Комиссии за запросы распределяются между участниками; инфляционные награды стимулируют индексирование «общественно полезных» сабграфов.

Почему это быстрее «ручного» парсинга блоков? Сабграф — это готовая предвычисленная витрина. В прикладных системах это похоже на материализованные представления и OLAP-кубы.

Сабграфы как интерфейсы данных

Сабграф описывает понятные сущности (например, «Пул», «Позиция», «Ордер», «Голосование», «Эпоха»), которые строятся из низкоуровневых логов. Это уменьшает площадь ошибок и повышает повторное использование. Для аналитики и смешанных пайплайнов (ETL → индексы → ретривер → генерация) сабграфы становятся источниками истины, которые легко объединять с векторными индексами (см. эмбеддинги и RAG).

*Практическая рекомендация:* проектируйте схему так, чтобы API возвращал минимально достаточные структуры для ваших экранов/отчётов. Длинные «жадные» запросы ухудшают задержки и цену эпизода.

Токен GRT: для чего он нужен

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

Как формируется цена запроса

На стоимость влияют:

• Сложность GraphQL-запроса (глубина, связь, агрегации).
• Популярность сабграфа и конкуренция индексеров.
• SLA/приоритет (регионы, лимиты, квоты).
• Кэширование на стороне шлюза/клиента.

Надёжная практика — держать контракты запросов: фиксировать шаблоны и верхние лимиты (количество элементов, глубина вложенности). Это снижает «взрывы» цены.

Качество и верификация данных

В протокол заложены механизмы:

• Детерминированность мэппингов. Одна и та же версия сабграфа при корректной обработке даёт одинаковое состояние.
• Дискуссии/диспуты. В случае расхождения данных возможны разбирательства; злонамеренные индексеры рискуют стейком (слешинг).
• Версионирование. Миграции схем с привязкой к коммитам исходников/контрактов.

С точки зрения пользовательских пайплайнов это значит: можно строить проверяемые отчёты и таблицы, где каждая цифра восходит к версии сабграфа.

Примерный жизненный цикл запроса в продукте

• Формулировка задачи. Приложение/отчёт требует метрики: «ликвидность пула X за неделю», «топ N адресов по активности», «результаты голосования Y».
• Запрос GraphQL. Клиент шлёт запрос к конкретному сабграфу (или через шлюз), указывая поля/фильтры.
• Ответ и кэш. Индексер возвращает результат; на стороне клиента сохраняется кэш (по ключу запроса и версии сабграфа).
• Пост-обработка. Аггрегирование, визуализация, экспорт. Если ответ идёт в AI-сценарий, дальше включается ретривер RAG.

Практика внедрения: чек-лист разработчика сабграфа

• Схема. Опишите типы/связи под конкретные экраны/отчёты. Избегайте лишних полей и «жадных» связей.
• Мэппинги. Держите код детерминированным, используйте явные преобразования, фиксируйте версии контрактов.
• Индексация. Разбейте начальную синхронизацию на этапы; следите за ресурсами (CPU/IO).
• Кэш. Проектируйте страницы/виджеты так, чтобы повторно использовать ответы и не перегружать индексеров.
• Нагрузка. Напишите тесты на worst-case запросы, установите лимиты глубины/размеров.
• Версии. Пропишите стратегию миграций и обратной совместимости.
• Наблюдаемость. Логи запросов, частота ошибок, P50/P95 задержек, доля кэш-хитов.
• Документация. Примеры запросов/ответов, оговорки по точности/задержкам.

Практика эксплуатации: чек-лист потребителя данных

• Минимизируйте глубину GraphQL-запросов, используйте пагинацию и фильтры.
• Кэшируйте результаты, особенно для дашбордов/лендингов.
• Фиксируйте версию сабграфа; при изменениях запускайте регрессионные проверки.
• Отделяйте тяжёлые отчёты (офлайн/пакеты) от интерактивных экранов.
• Сверяйте критические цифры на независимом источнике при спорных кейсах.
• Держите аварийный режим: упрощённые запросы или заглушки при временной недоступности.

Риски и модель угроз

Сценарии использования

DeFi-дашборды. Пулы ликвидности, объёмы, fee-APR, позиции пользователей. Сабграфы скрывают сложность контрактов и «переводят» события в бизнес-метрики.

Голосования/управление. Срезы по кворуму, делегатам, результатам. Важна детерминированность и привязка к блокам.

NFT/коллекции. История листингов/продаж, редкость, атрибуты. Экран каталогов может работать на кэшированных запросах.

Комбинированные AI-пайплайны. Сабграф → ретривер/векторный индекс → подсказка модели → генерация отчётов/сводок. Здесь полезны эмбеддинги и дисциплина RAG.

Таблица ролей и стимулов

Советы по экономии и производительности

• Контракты запросов: чётко определите разрешённые поля/пределы.
• Декомпозируйте экраны: несколько маленьких запросов могут обойтись дешевле одного гигантского.
• Учитывайте «холодный старт» индекса при миграциях; планируйте кэш-прогрев.
• Планируйте кэш-ключи по версии сабграфа и параметрам запросов.
• Рассматривайте «плоские» виды данных под часто используемые агрегаты.

Частые ошибки (анти-паттерны)

• Схема, «зеркалящая» контракт без бизнес-смыслов → трудные запросы, дорогие джоины.
• Отсутствие версий и миграций → ломаются дашборды при обновлениях.
• «Жадные» запросы без пагинации → рост задержек и цены запроса.
• Отсутствие кэша → повторяющиеся одинаковые запросы бьют по бюджету.
• Сигналы кураторов «ради доходности» без анализа спроса → замороженная ликвидность.

FAQ

Чем сабграф отличается от «самописного» ETL? Сабграф — открытый, воспроизводимый слой с единым API (GraphQL), поддерживаемый сетью индексеров. Собственный ETL даёт полный контроль, но требует постоянной поддержки и редко бывает так же легко повторим.

Как рассчитывается вознаграждение индексеров? Из комиссий за запросы и инфляционных наград, распределяемых по правилам протокола. Конкретные доли зависят от стейка, спроса и политики делегирования.

Что делает куратор и зачем его сигнал? Куратор вкладывает GRT в субграфы, тем самым «голосуя» рублём за их полезность. Сигнал помогает индексерам выбирать приоритеты и участвует в распределении комиссий.

Чем делегирование отличается от стейкинга индексера? Делегатор не запускает узлы: он передаёт свой GRT индексеру в обмен на долю дохода. Индексер рискует стейком и отвечает за операционную часть.

Почему мои запросы «дорогие»? Скорее всего, они слишком глубокие/широкие. Введите пагинацию, ограничьте поля, используйте кэш и пересмотрите схему.

Можно ли использовать данные сабграфов в AI-сценариях? Да. Сабграфы дают структурированные факты, которые удобно подмешивать в ретривер/векторные индексы (см. эмбеддинги и RAG), а затем использовать в генерации отчётов/ответов.

Словарь терминов

• Сабграф (subgraph) — схема и мэппинги для извлечения/агрегации on-chain данных с интерфейсом GraphQL.
• Индексер — оператор, который стейкает GRT и обслуживает запросы к сабграфам.
• Куратор — участник, сигнализирующий ценность сабграфов через вложение GRT.
• Делегатор — держатель GRT, делегирующий индексеру для доли дохода.
• Слешинг — штраф/сжигание стейка за злонамеренную работу индексера.
• GraphQL — язык запросов/схем для API; в The Graph — интерфейс к индексированным данным.
• OLAP-витрина — предвычисленный слой агрегатов под аналитические запросы.

См. также

• Векторные базы данных: обзор
• Эмбеддинги
• RAG (retrieval-augmented generation)
• Машинное обучение
• Векторные базы данных