The Graph – децентрализованный протокол индексирования блокчейн-данных. Он превращает последовательность блоков, транзакций, событий и вызовов контрактов в структурированные сущности, которые приложение запрашивает через GraphQL. Вместо самостоятельного сканирования всей цепочки разработчик публикует subgraph, а независимые Indexers обслуживают его за оплату и вознаграждения.
The Graph не является новым блокчейном, который заменяет Ethereum или Solana. Он строит проверяемый слой чтения поверх поддерживаемых сетей. Если приложение показывает историю обменов, позиции кредитного протокола или владельцев NFT, часть таких данных часто приходится вычислять из событий. Индекс делает этот результат быстрым и удобным для запроса.
Почему RPC недостаточно
Обычный RPC хорошо отвечает на точечные вопросы: баланс адреса в текущем блоке, receipt транзакции или значение storage. Сложный запрос вроде «все позиции пользователя с накопленными комиссиями» требует перебрать события нескольких контрактов, учесть обновления и сохранить промежуточное состояние.
Даже одинаково записанный адрес нужно индексировать отдельно для каждой сети: состояния Ethereum, Base и Arbitrum не объединяются. Почему совпадает строка адреса, но не его активы, объясняет материал про один адрес в разных EVM-сетях.
Централизованный backend может сделать это сам, но тогда приложение зависит от одной базы и одной команды. The Graph стандартизирует описание индексатора и создаёт рынок операторов. Приложение получает готовый GraphQL endpoint, а оператор получает экономический стимул поддерживать данные.
Что находится в subgraph
Subgraph manifest указывает сети, адреса контрактов, стартовые блоки и события, за которыми нужно следить. GraphQL schema описывает сущности: пользователя, пул, сделку, позицию или другой объект. Mapping содержит детерминированный код, который обрабатывает событие и обновляет сущности.
Graph Node читает поток блоков, вызывает нужный handler и сохраняет результат в базе. Когда появляется reorg, индексатор должен откатить данные до общей ветки и пересчитать их. Поэтому finality и устройство исходной сети влияют на то, насколько свежий результат безопасно показывать как окончательный.
Subgraph может быть корректно исполнен и всё равно давать неверную бизнес-метрику, если автор ошибся в mapping. Например, пропустил новый адрес контракта или дважды посчитал событие. Протокол проверяет детерминированность и работу индексатора, но смысл схемы остаётся ответственностью автора.
Запрос и путь данных
Приложение отправляет GraphQL query через gateway. Gateway выбирает подходящего Indexer, передаёт запрос и организует платёж. Indexer исполняет его по своей базе и возвращает результат. Платёжные receipts позволяют не проводить отдельную on-chain транзакцию за каждый небольшой запрос.
Клиент может сравнивать операторов, использовать несколько endpoints или закрепить критичный backend за собственной инфраструктурой. Децентрализованная сеть не означает, что каждый frontend автоматически опрашивает всех Indexers. Реальная отказоустойчивость зависит от настройки gateway и приложения.
Indexers
Indexer запускает Graph Node, базы данных и сетевую инфраструктуру, вносит GRT в stake и выбирает subgraphs для обслуживания. Он открывает allocations, сигнализирующие, куда направлена его работа, и получает query fees плюс indexing rewards. Минимальный self-stake и аппаратные требования создают экономический и технический барьер.
Неправильное обслуживание или доказанное нарушение правил способно привести к slashing. Сам stake не гарантирует быстрый ответ: нужно смотреть latency, uptime, цену, корректность и diversity источников chain data. Крупный оператор имеет экономию масштаба, поэтому рынок может концентрироваться даже при свободном входе.
Curators и signal
Curator вносит GRT в bonding curve выбранного subgraph и тем самым сообщает Indexers, что его стоит обслуживать. Взамен куратор получает долю query fees, связанную с сигналом. Ранняя полезная оценка может быть выгодной, но цена shares меняется по кривой.
Signal не является гарантией качества. Популярность можно переоценить, а subgraph – заменить новой версией. Выход после других участников способен дать худший результат. Поэтому curation ближе к экономическому прогнозу спроса на данные, чем к пассивному депозиту.
Delegators
Delegator передаёт GRT в делегацию Indexer и получает часть его чистых вознаграждений по заданным параметрам. Оператор не получает токены в личный кошелёк, но его комиссии, allocations и качество работы определяют результат. При выходе действует период ожидания, поэтому моментальная ликвидность отсутствует.
После перехода к Graph Horizon делегация может быть связана с конкретным data service. Это требует проверять не только имя Indexer, но и услугу, на которую направлен капитал. Старые статьи могут описывать delegation tax, однако в действующей модели Horizon этот налог убран. Актуальные правила важнее устаревшего калькулятора.
Graph Horizon
Horizon превращает базовую экономику The Graph в модульный протокол для нескольких data services. Вместо коротких одноцелевых allocations используются более гибкие долгоживущие механизмы, а правила slashing и делегации задаются для конкретной услуги. Первой основной службой остаётся SubgraphService.
Архитектура позволяет развивать Firehose, Substreams и будущие способы выдачи данных в общей системе staking и платежей. Но модульность усложняет анализ: спрос, безопасность и экономика одной службы не обязательно переносятся на другую.
Firehose и Substreams
Firehose выдаёт богатый последовательный поток блоков и изменений состояния, оптимизированный для индексирования. Он помогает быстро воспроизводить историю и корректно обрабатывать fork. Substreams позволяет выполнять параллельные преобразования данных и передавать уже подготовленный поток downstream-приложениям.
Эти инструменты не отменяют subgraphs, а решают более низкоуровневые и тяжёлые задачи. Разработчик выбирает GraphQL-сущности для прикладного API или потоковую обработку для аналитики и собственных сервисов.
История
Идея The Graph появилась у команды в июле 2017 года, а к концу того же года работа стала основной. В 2018 году был открыт код Graph Node, а в январе 2019 года запустился Hosted Service. Он дал разработчикам удобный индексатор ещё до децентрализованной сети и помог сформировать формат subgraph.
Mainnet The Graph стартовала 17 декабря 2020 года. GRT связал работу Indexers, Curators и Delegators с оплатой запросов и инфляционными наградами. В последующие годы протокол переносил subgraphs с Hosted Service в децентрализованную сеть и добавлял поддержку новых цепочек.
Firehose и Substreams расширили обработку потоков, а Graph Horizon сделал staking layer пригодным для нескольких data services. Поэтому современный проект следует оценивать не только по числу subgraphs, но и по фактическому платному спросу на весь набор служб.
Команда
Основателями The Graph стали Янив Таль, Яннис Польманн и Брэндон Рамирес. Они создали ранний Graph Node, Hosted Service и дизайн протокола. После формирования Foundation первоначальная компания получила название Edge & Node и продолжила разработку продуктов экосистемы.
The Graph Foundation поддерживает гранты, стандарты и координацию. Graph Council принимает ключевые решения управления. В разработке также участвуют StreamingFast, Semiotic Labs, GraphOps и другие независимые core developer teams. Indexers и subgraph developers формируют рабочий слой сети.
Это экосистема организаций, а не полностью безликий протокол. Edge & Node, Foundation, Council, gateways и крупные Indexers имеют разные полномочия. Для оценки децентрализации нужно смотреть, кто пишет клиенты, маршрутизирует запросы, контролирует upgrade и держит stake.
GRT и токеномика
GRT используется для stake Indexers, curation signal, delegation и оплаты запросов. Начальное предложение составляло 10 миллиардов токенов. Протокол ориентируется на ежегодную эмиссию для indexing rewards, а часть комиссий и отдельных экономических операций сжигается.
Инфляция субсидирует предложение индексирования до того, как query fees станут достаточными. Для держателя важен баланс: растёт ли реальная оплата запросов быстрее выпуска, насколько награды зависят от субсидии и какая доля GRT заблокирована. Высокий APR может отражать эмиссию, а не прибыльный data business.
Количество запросов тоже требует контекста: бесплатный или субсидированный трафик не равен выручке. Нужно сопоставлять query fees, indexing rewards, stake concentration и расходы операторов. Общая рамка есть в материале о том, как читать токеномику.
Что получает приложение
- Воспроизводимость. Manifest и mappings можно проверить и запустить независимо.
- Скорость. Сложные сущности читаются без полного сканирования блоков.
- Выбор оператора. Запросы способен обслуживать рынок Indexers.
- Единая схема. GraphQL упрощает frontend и аналитику.
Но индекс не заменяет block explorer и исходную транзакцию. Если интерфейс показывает неожиданный перевод токена, полезно сверить receipt, logs и contract address. Разница между trace и событиями объяснена в статье про внутренние транзакции и события токенов.
Что проверить разработчику
- Закрепить точные addresses, ABI и start blocks.
- Обработать upgrade контракта, reorg и повторное событие.
- Сравнить результаты subgraph с прямым RPC на контрольной выборке.
- Настроить fallback между Indexers или собственный резервный Graph Node.
- Отслеживать lag, failed queries и смену версии schema.
Основные риски
Ошибка mapping способна систематически исказить данные. Отставший Indexer покажет старое состояние, gateway создаст точку зависимости, а сбой RPC upstream нарушит синхронизацию. Реорганизация исходной сети временно изменит результат даже при исправной работе The Graph.
Экономика зависит от спроса на платные запросы, распределения GRT и поведения крупных операторов. Curators рискуют капиталом на bonding curve, Delegators – выбором Indexer и периодом выхода. Horizon расширяет рынок, но новые data services ещё должны доказать устойчивый спрос.
Итог: The Graph превращает необработанные blockchain events в удобный прикладной API и распределяет обслуживание между экономически мотивированными Indexers. Его сильная сторона – воспроизводимый стандарт индексирования. Главные компромиссы – доверие к mapping, путь через gateway, концентрация операторов и зависимость токеномики от реальной платы за данные.
