Резюме

Вас вітає серія «Криптотрaгедія спільного ресурсу» від GCC Research.

У цій серії аналізуються ключові загальнодоступні блага блокчейн-індустрії — ті основні складові криптоекосистеми, які дедалі частіше відхиляються від децентралізованих принципів. Саме ці блага забезпечують фундамент Web3, але вони часто стикаються з браком стимулів, складнощами управління та ризиками централізації. Тут розрив між ідеалами децентралізації крипти й надійною надмірністю, необхідною для стійкості у реальному світі, досягає критичного рівня.

У цьому випуску ми розглядаємо одну з найпомітніших застосунків на Ethereum: Polymarket і його інструменти індексації даних. Від початку року низка скандалів — від маніпуляцій оракулами щодо шансів Трампа на виборах, ставок на рідкоземельні ресурси України до політичних парі про колір костюма Зеленського — не раз виводила Polymarket у центр криптосуспільства. Обсяги й вплив задіяних коштів роблять ці суперечки неможливими для ігнорування.

Але чи справді флагманський «децентралізований ринок прогнозів» ефективно реалізував децентралізацію на критичному рівні — рівні індексації даних? Чому децентралізована інфраструктура на кшталт The Graph не відповідає очікуванням? Якою має бути по-справжньому придатна до використання та стійка публічна система індексації даних?

I. Ефект доміно від збою централізованої платформи даних

У липні 2024 року Goldsky — платформа інфраструктури блокчейнових даних у реальному часі для розробників Web3 із сервісами індексації, підграфів і потокових даних — зазнала шестигодинної відмови. Внаслідок цього значна частина екосистеми Ethereum вийшла з ладу: DeFi-фронтенди не відображали позиції та баланси користувачів, такі сервіси, як Polymarket, не могли коректно показувати дані, а для користувачів інтерфейси багатьох проєктів стали майже непридатними.

Саме подібних ситуацій повинні уникати децентралізовані застосунки. Ключова мета дизайну блокчейнів — усунення єдиних точок відмови. Інцидент із Goldsky виявив неприємну реальність: хоча блокчейни сконструйовані як децентралізовані, левова частка інфраструктури, що забезпечує роботу on-chain-застосунків, залишається централізованою.

Причина така: індексація та запити блокчейнових даних — це цифрові публічні блага (неконкурентні, невиключні), і користувачі зазвичай очікують доступу без оплати або за мінімальної плати. Однак підтримка цієї інфраструктури вимагає постійних інвестицій у обладнання, зберігання, пропускну здатність і розробку. За відсутності життєздатної фінансової моделі сектор врешті тяжіє до монополії: коли провайдер отримує перевагу у швидкості та ресурсах, розробники переорієнтовують всі запити до нього — і виникає нова критична точка залежності. Gitcoin і низка благодійних ініціатив не раз наголошували: «Відкрите інфраструктурне програмне забезпечення створює мільярдну цінність, але його творці часто не здатні навіть оплатити іпотеку».

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

II. Звідки насправді надходять дані для вашого DApp?

Щоб збагнути наслідки збою Goldsky, варто заглибитися в механіку DApp. Більшість користувачів розпізнають лише дві складові: контракт у мережі та фронтенд. Вони звикли перевіряти транзакції через Etherscan, бачити дані у фронтенді, здійснювати дії через UI. Але де фронтенд бере свої дані?

Вирішальна роль сервісів отримання даних

Уявіть, що ви розробляєте кредитний протокол, який мав би відображати позиції, маржу та борг користувачів. Найпростіша ідея — запитувати дані з блокчейна безпосередньо у фронтенді. Але контракти більшості протоколів не дозволяють отримати всі позиції адреси, а лише за ідентифікатором позиції. Щоб зібрати перелік позицій конкретного користувача, спершу потрібно перебрати всі відкриті позиції та вручну відфільтрувати його записи — це як шукати у мільйонних реєстрах. Технічно це можливо, але неймовірно повільно й неефективно; навіть на backend-серверах найбільші DeFi-проєкти можуть виконувати такі операції годинами, отримуючи дані з локального вузла.

Саме тому життєво необхідна спеціалізована інфраструктура. Провайдери як Goldsky пропонують сервіси індексації, які суттєво прискорюють доступ. Діаграма нижче показує типи даних, які вони забезпечують для застосунків.

Частина читачів запитає: Невже The Graph не забезпечує децентралізоване отримання Ethereum-даних? У чому різниця із Goldsky — і чому так багато DeFi-проєктів віддають перевагу Goldsky над The Graph?

Взаємосумісність The Graph, Goldsky і SubGraph

Пояснімо основи:

• SubGraph — це фреймворк для розробників, який дозволяє писати код для зчитування та агрегування on-chain-даних задля відображення у фронтенді.
• The Graph — провідна децентралізована платформа отримання даних, яка створила SubGraph-фреймворк на основі AssemblyScript. З SubGraph розробники зчитують події смарт-контракту й записують їх у базу для подальших запитів через GraphQL або SQL.
• Сервіси, що запускають SubGraph, називають операторами SubGraph. І The Graph, і Goldsky є хостинг-провайдерами для SubGraph-проєктів, оскільки кінцевий код має запускатися на серверах. Ось фрагмент документації Goldsky:

Чому існує кілька операторів SubGraph?

Бо фреймворк визначає лише спосіб вилучення даних з блоків і запису у базу, але не диктує точний механізм потоків чи видачі даних. Кожен оператор реалізує це по-своєму.

Оператори можуть змінювати вузли та оптимізувати їхню продуктивність. The Graph зараз використовує Firehouse для пришвидшеної індексації; Goldsky тримає runtime SubGraph як закритий.

The Graph де-факто є децентралізованою платформою операторів SubGraph. Так, Uniswap v3 SubGraph обслуговують різні оператори — The Graph виступає хабом, де користувачі подають SubGraph-код, а декілька операторів можуть здійснювати обробку запитів.

Модель ціноутворення Goldsky

Goldsky, будучи централізованим сервісом SaaS-типу, використовує класичну модель «плати за ресурси». З нею добре знайомі більшість інженерів. Ось калькулятор вартості Goldsky:

Модель ціноутворення The Graph

Ціноутворення The Graph унікальне: плата за запити і стимули інтегровані у токеноміку GRT. Суть моделі така:

• Плата за запит до SubGraph розподіляється так: 1% GRT спалюється, 10% іде до пулу кураторів (зазвичай це розробники), близько 89% алгоритмічно ділиться між індексаторами та делегаторами.
• Індексатори мають застейкати мінімум 100 000 GRT для участі і штрафуються за некоректні результати. Делегатори делегують свої GRT індексаторам і ділять між собою 89% винагороди.
• Куратори (часто розробники) сигналізують цінність SubGraph, стейкуючи GRT за бондінг-кривою. Чим більший stake, тим більше індексаційних ресурсів залучається. Рекомендації спільноти: для гарантованого індексування потрібно 5 000–10 000 GRT.

Оплата за запити:

Розробник реєструє API-ключ і передоплачує GRT, а витрати нараховуються по кожному запиту.

Плата за staking сигналу:

Щоб SubGraph був проіндексований, розробник має застейкати GRT задля «сигналу цінності» і залучення операторів. Лише після досягнення певного порогу (наприклад, 10 000 GRT) індексатори беруть SubGraph у роботу.

Під час тестування SubGraph можна безкоштовно розгорнути через staging-оператор The Graph — це не для продакшену. Для продуктивного використання потрібно публікувати SubGraph у мережу та дочекатися вибору оператором після сигналу stake.

Чому розробники (і бухгалтери) критично ставляться до токенового ціноутворення

Для більшості продуктів робота з The Graph є надто заплутаною. Власне купівля GRT для Web3-команди — дрібниця, але курація триває довго й залишається невизначеною. Основні проблеми:

• Невизначеність: розробник не має чітких інструкцій щодо суми staking чи строку до запуску індексації.
• Бухгалтерський облік: токенова модель ускладнює фінансовий облік витрат, через що компаніям і бухгалтерам непросто класифікувати такі витрати.

«Централізація просто вигідніше?»

Для більшості розробників Goldsky — значно зручніше рішення: прозоре ціноутворення, миттєвий доступ після оплати, мінімум невизначеності. Це спричинило масову залежність Web3 від одного провайдера індексації.

Токеноміка GRT у The Graph з хорошими намірами, але її складність відштовхує, і вона не повинна лягати на кінцевих користувачів; особливо курацію варто ховати за простим платіжним інтерфейсом.

Це не лише приватна думка: Пол Разван Берг, відомий інженер смарт-контрактів і засновник Sablier, публічно розкритикував UX публікації SubGraph та процес оплати GRT як украй незручний.

III. Чинні рішення для виходу з ладу індексаторів даних

Як екосистема має реагувати на єдині точки відмови в індексації? Розробник може інтегрувати The Graph, але зіткнеться з GRT-стейкінгом і курацією в оплаті API.

В екосистемі EVM є чимало альтернатив індексування даних. Корисні джерела: огляд Dune The State of EVM Indexing, довідник rindexer EVM Indexing Tools Overview, цей тред.

Ця стаття не розбирає технічної причини збою Goldsky: згідно звітності, Goldsky розкриває подробиці лише своїм корпоративним клієнтам. Йдеться про збій при записі індексованих даних у базу; доступ вдалося відновити лише завдяки підтримці AWS.

Ось життєздатні підходи:

• ponder — простий у використанні і швидкий для самостійного розгортання індексатор даних. Можна розмістити на власній або орендованій інфраструктурі.
• local-first — це підхід розробки, за яким DApp має зберігати функціональність навіть без мережі. У blockchain це означає, що користувач отримує гідний досвід, якщо може підключитись до ланцюга, навіть за відсутності індексатора.

Ponder: самостійне індексування даних

Чому варто звернути увагу на ponder?

• Відсутність vendor lock-in: інструмент створено незалежним розробником, йому потрібен лише Ethereum RPC-ендпоінт і база Postgres — не потрібні керовані сервіси.
• Високий комфорт для девелопера: TypeScript і бібліотека Viem забезпечують чудову зручність (автор має тривалий досвід використання).
• Відмінна продуктивність.

Але є і недоліки: ponder швидко розвивається, тому інколи зміни можуть порушити сумісність із попередніми версіями. Деталі й практики — на офіційному сайті.

Важливо: нещодавно ponder почав комерціалізацію відповідно до «теорії сегментування», яку описували в попередньому матеріалі.

Суть: публічні блага створюють цінність для всіх, але монетизація відсікає частину користувачів — це не Парето-оптимум. Диференційоване ціноутворення здатне максимізувати виграш, але складне й дороге; теорія сегментування радить виділяти окремий сегмент і брати оплату лише з нього.

Як це реалізували у ponder:

• Для розгортання потрібна технічна експертиза — слід налаштувати залежності (RPC-з’єднання, базу даних).
• Потрібна постійна підтримка (наприклад, проксі для балансування навантаження, моніторинг запитів). Для деяких розробників це складно.
• Ponder пропонує автоматичне розгортання (бета) через Marble: досить відправити код, і платформа запустить індексатор у один клік.

Таким чином, хто цінує зручність — платить Marble, а самостійне розгортання ponder залишається безкоштовним.

Ponder чи Goldsky: що і кому підходить?

• Self-hosting інструменти без дозволів, як ponder, вибирають переважно невеликі команди, яким важлива гнучкість і незалежність.
• Великі проєкти з високим навантаженням звертаються до керованих сервісів типу Goldsky — вони забезпечують відмовостійкість і SLA.

Обидві моделі мають ризики. Збій Goldsky показав: кожний розробник має мати резервний індексатор на базі ponder. Також варто перевіряти валідність RPC-відповідей: нещодавно safe повідомляв про збій індексатора через некоректні RPC-дані. Прямих доказів, що збій Goldsky спричинили саме RPC, немає, але це не виключено.

Local-first як стандарт розробки

Local-first — популярна тема останніх років. Суть підходу:

• Робота без мережі
• Крос-клієнтська синхронізація

У технічних колах local-first часто пов’язують із CRDT — структурами даних, що автоматично вирішують конфлікти при розподіленому редагуванні. Це спрощені протоколи консенсусу для підтримки цілісності даних на різних пристроях.

У блокчейн-розробці ці вимоги пом’якшуються: головне — забезпечити користувачу хоч мінімальний функціонал навіть за збою бекенду, адже блокчейн і так гарантує крос-клієнтську узгодженість.

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

• Зберігати ключові дані локально — баланси, позиції, статуси — щоб користувач бачив останній стан навіть без індексатора.
• Плавно знижувати функціонал: отримувати мінімум даних напряму через RPC, якщо індексатор недоступний, щоб показати частину актуальної інформації.

Такий підхід значно підвищує надійність додатків. В ідеалі найкращий local-first DApp запропонує користувачу запускати власний вузол і отримувати дані через рішення на кшталт TrueBlocks. Більше про децентралізовану чи локальну індексацію — у цьому треді.

IV. Висновки

Збій Goldsky протягом шести годин став тривожним дзвінком для Web3. Архітектурна децентралізація блокчейна забезпечує стійкість, але на рівні застосунків більшість команд і досі спирається на централізовану інфраструктуру даних, що створює нові системні ризики.

У статті пояснено, чому The Graph зазнав труднощів із масовим застосуванням попри гарну репутацію — причиною стали складна GRT-токеноміка та бар’єри для розробників. Обговорено й стратегії підвищення надійності індексації: стимулювання self-hosting інструментів, таких як ponder, як резервних рішень, а також інноваційний комерційний шлях ponder. Нарешті, розглянуто підхід local-first і закликано розробників забезпечувати роботу DApp навіть у разі збою індексаторів.

Все більше Web3-розробників визнає єдині точки відмови в індексації даних критичною вразливістю. GCC закликає спільноту зосередитись на цій інфраструктурній проблемі та експериментувати з децентралізованими індексаторами або розробляти фреймворки, які зберігають працездатність DApp навіть за недоступності індексаторів.

Відмова від відповідальності:

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