Краткое резюме

Добро пожаловать в серию GCC Research «Крипто-трагедия общественных благ».

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

В данном выпуске внимание уделяется одному из самых известных приложений Ethereum — Polymarket, а также инструментам индексации данных. С начала года вокруг Polymarket неоднократно возникали скандалы — от вмешательства в работу оракулов при ставках на шансы Трампа, до пари на украинские редкоземельные элементы и политических ставок, касающихся цвета костюма Зеленского. Объём и влияние вовлечённых денежных средств делают эти споры особо значимыми.

Однако реализовал ли ведущий «децентрализованный предсказательный рынок» подлинную децентрализацию на ключевом уровне — индексации данных? Почему децентрализованные инструменты, такие как The Graph, не оправдывают ожиданий? Каким должно быть действительно удобное и устойчивое публичное решение для индексации данных?

I. Эффект домино после сбоя централизированной платформы данных

В июле 2024 года Goldsky — инфраструктурная платформа потоковых данных для Web3-разработчиков, предоставляющая индексацию, Subgraph и потоковые сервисы — испытала шестичасовой сбой. Это привело к частичной остановке экосистемы Ethereum: фронтэнды DeFi перестали отображать балансы и позиции пользователей, рынки предсказаний, такие как Polymarket, не смогли корректно выводить данные, а многие пользовательские интерфейсы стали полностью недоступными.

Подобные сбои должны предотвращаться архитектурой децентрализованных приложений — ведь основная задача блокчейна как технологии заключается в устранении единых точек отказа. Инцидент с Goldsky показал тревожный факт: несмотря на децентрализованную основу самих блокчейнов, большая часть инфраструктуры, на которой работают on-chain приложения, по сути остаётся централизованной.

Это связано с тем, что индексация и запросы к блокчейн-данным — это цифровые общественные блага: они признаны неисключаемыми и неконкурентными, а пользователи ожидают бесплатный или почти бесплатный доступ. Поддержка такой инфраструктуры требует постоянных инвестиций в серверы, хранилища, пропускную способность и инженерные ресурсы. Без устойчивой экономической модели сектор быстро превращается в игру «победитель получает всё»: как только провайдер получает преимущество в скорости или финансировании, разработчики полностью переключают нагрузку на него, создавая новую точку зависимости. Gitcoin и другие некоммерческие организации неоднократно указывали: «Открытая инфраструктура приносит миллиарды долларов стоимости, но её создатели зачастую не могут оплатить даже жильё».

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

II. Откуда ваш DApp реально получает данные?

Чтобы понять инциденты, подобные сбою Goldsky, важно рассмотреть архитектуру DApp глубже. Для большинства пользователей приложение делится на две части: on-chain контракт и фронтэнд. Обычно они проверяют статус своих транзакций через Etherscan, просматривают данные на фронтэнде и проводят операции через интерфейс. Но где фронтэнд получает данные на самом деле?

Значение сервисов извлечения данных

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

В таких случаях необходима специализированная инфраструктура. Поставщики типа Goldsky предоставляют услугу индексации данных, многократно ускоряя доступ. На схеме ниже показано, какие типы данных становятся доступны для приложений благодаря таким сервисам.

Читатели могут спросить: разве The Graph не предоставляет децентрализованные сервисы извлечения данных для Ethereum? Как соотносятся решения Goldsky и The Graph, и почему так много DeFi-проектов выбирают Goldsky вместо The Graph?

Структура The Graph, Goldsky и SubGraph

Разъясним основные технические понятия:

• SubGraph — это фреймворк для разработки, позволяющий командам агрегировать on-chain данные для фронтэнда.
• The Graph — ведущая децентрализованная платформа извлечения данных, которая создала SubGraph на AssemblyScript. С помощью SubGraph разработчики фиксируют события контрактов и записывают их в базу данных, доступную через GraphQL или SQL.
• Поставщики, запускающие SubGraph, называются операторами SubGraph. И The Graph, и Goldsky предоставляют услуги хостинга для проектов SubGraph, поскольку код SubGraph всегда работает на сервере. Пример из документации Goldsky:

Зачем нужны разные операторы SubGraph?

Потому что фреймворк определяет только извлечение и запись данных из блоков, но не специфицирует детали потоков данных и выдачи. Каждый оператор реализует их самостоятельно.

Операторы могут внедрять свои модификации и оптимизации производительности. Например, The Graph использует Firehouse для ускоренной индексации; runtime SubGraph от Goldsky закрыт для внешних разработчиков.

The Graph — фактически децентрализованный хаб операторов SubGraph. Так, subgraph Uniswap v3 поддерживается многими операторами; это превращает The Graph в маркетплейс, где пользователи размещают код SubGraph и несколько операторов обслуживают запросы.

Модель оплаты Goldsky

Goldsky — централизованный сервис по модели SaaS, использующий известную схему «плати за ресурсы». Многим инженерам это знакомо. Пример калькулятора цен:

Модель оплаты The Graph

Модель оплаты The Graph уникальна: комиссии за запросы и стимулы интегрированы в токеномику GRT. Основные параметры:

• Каждый запрос к SubGraph делит комиссию: 1% GRT сжигается; 10% поступает в пул кураторов (разработчиков); около 89% получают индексаторы и делегаторы по алгоритму.
• Индексаторы должны застейкать минимум 100 000 GRT и несут штрафы за ошибочные результаты. Делегаторы размещают GRT с индексаторами и получают свою долю из пула 89%.
• Кураторы (как правило, разработчики) сигналят о значимости своего SubGraph, размещая GRT на бондинговой кривой. Чем больше стейкинг — тем выше ресурсы индексаторов. В сообществе рекомендуют размещать 5 000–10 000 GRT для надёжного индексаирования.

Комиссии за запросы:

Для обращения к The Graph разработчикам требуется зарегистрировать API-ключ и заранее оплатить GRT, стоимость рассчитывается по количеству запросов.

Комиссии за сигналирование:

Для индексации SubGraph разработчики стейкивают GRT, чтобы «посылать сигнал» и привлекать операторов. Индексация начинается только после накопления необходимого объёма GRT (например, 10 000).

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

Почему разработчики и бухгалтеры недовольны токеновой моделью оплаты

Для большинства проектов процесс работы с The Graph слишком сложен. Покупка GRT проста для Web3-команд, но процесс кураторства — медленный и запутанный. Главные сложности:

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

«Централизация — просто удобнее?»

Для большинства разработчиков Goldsky значительно проще: модель оплаты прозрачна, сервис запускается мгновенно после оплаты, нет неопределённости. Это и стало причиной высокой зависимости Web3 от единственного поставщика индексации.

Токеномика GRT в The Graph, несмотря на хорошие намерения, излишне сложна и не должна ложиться на конечного клиента – кураторский стейкинг стоит скрыть за простым платёжным интерфейсом.

Это объективно подтверждается: Пол Разван Берг, ведущий инженер смарт-контрактов и основатель Sablier, публично заявил о крайне неудобном пользовательском опыте публикации SubGraph и оплаты GRT.

III. Текущие решения при сбоях индексаторов данных

Как экосистема может устранить единые точки отказа в индексации? Как показано выше, разработчики могут использовать The Graph, но для этого требуется стейкинг GRT и кураторство для оплаты доступа к API.

Экосистема EVM предлагает множество альтернативных решений для индексации данных. Рекомендуем ознакомиться с The State of EVM Indexing от Dune, обзором инструментов индексирования EVM от rindexer и последним тредом.

В статье не анализируется техническая причина сбоя Goldsky; согласно их отчёту, подробности предоставляются только корпоративным клиентам. Указывается, что проблема возникла при записи индексированных данных в базу, а восстановление доступа было достигнуто после взаимодействия с AWS.

Вот альтернативные решения:

• ponder — простой, интуитивно понятный и легко разворачиваемый инструмент для индексации данных. Разработчики могут самостоятельно размещать его на арендованных серверах.
• local-first — принцип разработки, предполагающий, что DApp должен сохранять функциональность даже без интернет-соединения. Для блокчейна это означает, что пользовательский опыт сохраняется при доступе к цепи — даже при недоступных индексаторах.

Ponder: Индексация данных DIY

Почему стоит выбрать ponder?

• Нет зависимости от сторонних сервисов: изначально независимая разработка, ponder требует только RPC-эндпоинт Ethereum и базу данных Postgres; управляющий сервис не нужен.
• Высокий комфорт для разработчиков: продукт написан на TypeScript с использованием библиотеки Viem и отличается удобством (автор неоднократно применял его в работе).
• Отличная производительность.

Минусы: продукт быстро развивается, из-за этого иногда появляются несовместимости с прежними деплойментами. Рекомендуем обращаться за деталями и best practices к официальной документации.

Особо важно, что недавно ponder начал коммерциализацию, что соответствует «теории разделения», ранее описанной в статье.

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

Реализация этой теории в ponder:

• Для деплоймента требуются технические навыки — необходимо настроить зависимые ресурсы (RPC, база данных).
• Требуется поддержка (например, прокси для балансировки нагрузки и контроль потоковых запросов к данным). Это может быть сложно для части разработчиков.
• Ponder теперь предлагает автоматизированный деплой по модели beta через Marble: код отправляется на платформу для однокликового запуска.

Подход позволяет «отделить» тех, для кого комфорт важнее — они платят за решение Marble, а все остальные используют ponder бесплатно.

Сравнение применимости ponder и Goldsky:

• Самостоятельно разворачиваемые, permissionless-инструменты типа ponder востребованы у небольших проектов, ценящих гибкость и независимость.
• Крупные проекты с высокими нагрузками предпочитают управляемые сервисы типа Goldsky, обеспечивающие большую доступность и резервирование.

Оба подхода несут риски. Сбой Goldsky показал: каждому разработчику стоит держать резервный ponder-индексатор. Используя ponder, обращайте внимание на достоверность RPC-ответов — недавно команда safe зафиксировала сбой индексатора из-за некорректных RPC-данных. Нет прямых подтверждений, что инцидент Goldsky был вызван сбоями RPC, но это остаётся вероятной причиной.

Парадигма local-first в разработке

Local-first — одна из наиболее обсуждаемых концепций последних лет. Основные требования:

• Доступность приложения офлайн
• Совместная работа между клиентами

В технической дискуссии local-first часто упоминают CRDT (конфликтонезависимые реплицируемые типы данных) — структуры, позволяющие автоматически разрешать конфликты в процессе распределённого редактирования. Это облегчённые консенсус-протоколы, обеспечивающие согласованность данных на всех устройствах.

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

На практике, local-first DApp может:

• Кэшировать ключевые данные — балансы, позиции — чтобы пользователь видел последнее корректное состояние независимо от работы индексатора.
• Обеспечить плавную деградацию: при недоступности индексаторов предоставлять часть необходимых данных напрямую через RPC, показывая актуальную информацию on-chain.

Такой подход заметно увеличивает отказоустойчивость приложений. В идеале лучшая модель local-first DApp — запуск локального узла пользователем с обращением к инструментам вроде TrueBlocks. Подробнее о децентрализованной и локальной индексации — тред «Literally no one cares about decentralized frontends and indexers».

IV. Выводы

Шестичасовой сбой Goldsky стал серьёзным предупреждением для всей Web3-экосистемы. Несмотря на архитектурную децентрализацию и устойчивость блокчейнов, большинство современных проектов работают на централизованных инфраструктурных платформах данных, что создаёт новые системные риски.

В материале рассмотрено, почему The Graph, несмотря на авторитет, сталкивается с низким уровнем внедрения из-за сложной токеномики GRT и неудобства для разработчиков. Также приведены стратегии повышения устойчивости индексации: рекомендуется резервное применение самостоятельных решений типа ponder, разобрана инновационная коммерческая модель ponder. Подчёркнута ценность парадигмы local-first для DApp, гарантирующей работоспособность приложения даже при недоступности индексаторов данных.

Всё больше разработчиков Web3 отмечают единые точки отказа в индексации как серьёзнейший риск. Команда GCC призывает сообщество сконцентрироваться на решении этой фундаментальной инфраструктурной задачи и экспериментировать с децентрализованными индексаторами данных или разрабатывать фреймворки, обеспечивающие стабильную работу фронтендов DApp даже при сбоях индексаторов.

Правовая информация:

1. Материал опубликован повторно с TechFlow. Все авторские права принадлежат оригинальному автору shew. Для решения вопросов по перепубликации обращайтесь к команде Gate Learn.
2. Дисклеймер: Оценки и мнения, изложенные в статье, отражают позицию автора и не являются инвестиционной рекомендацией.
3. Переводы Gate Learn не подлежат копированию, распространению или плагиату без прямой ссылки на Gate.com как источник.