Шифрування громадських трагедій: Дилема індексації даних ринку прогнозів
Резюме
Ласкаво просимо до серії "Трагедія спільного блага". Ця серія зосереджується на "публічних товарах", які опинилися на критичних етапах у світі шифрування, але поступово втрачають свою норму. Ці інфраструктури часто стикаються з проблемами недостатніх стимулів, дисбалансу в управлінні та навіть поступової централізації.
У цьому випуску ми зосередимося на одному з найвідоміших застосувань в екосистемі Ethereum: Polymarket та його інструментах індексації даних. Окремі події, такі як перемога Трампа та маніпуляції оракулів навколо торгівлі рідкоземельними елементами в Україні, зробили Polymarket предметом обговорення. Однак чи дійсно цей продукт, що представляє "децентралізований ринок прогнозів", реалізував справжню децентралізацію у своїй ключовій основній модулі — індексації даних? Чому такі публічні інфраструктури, як The Graph, не змогли виконати очікувану роль? Якими повинні бути справжні корисні та стійкі публічні блага для індексації даних?
Один. Ланцюгова реакція, спричинена збоєм централізованої платформи даних
У липні 2024 року Goldsky сталася аварія, яка тривала шість годин, внаслідок чого велика частина проектів екосистеми Ethereum опинилася в стані паралічу. Передня частина DeFi не могла відобразити дані про позиції та баланси користувачів, ринок прогнозів Polymarket не міг відобразити правильні дані, безліч проектів здавалося повністю недоступними для користувачів.
Це не повинно було статися в світі децентралізованих застосунків. Чи не було задумом технології блокчейн усунути єдину точку відмови? Інцидент з Goldsky виявив тривожний факт: хоча сам блокчейн досяг максимальної децентралізації, інфраструктура, на якій розгортаються застосунки, часто містить велику кількість централізованих сервісів.
Індексування та пошук даних блокчейну належать до "неконкурентних, неексклюзивних" цифрових суспільних продуктів, користувачі зазвичай очікують безкоштовного або дуже низького тарифу, але за цим стоять постійні витрати на потужне обладнання, зберігання, ширину каналу та людські ресурси для обслуговування. Відсутність стійкої моделі прибутку призводить до концентрації, коли один переможець отримує все: якщо один постачальник послуг досягає переваги в швидкості та капіталі, розробники схиляються до того, щоб перенаправити весь потік запитів до цього сервісу, що знову формує залежність від єдиного постачальника.
Це застерігає нас, що децентралізованому світу терміново потрібне фінансування через громадські продукти, перерозподіл або ініціативи, керовані спільнотою, щоб збагачувати різноманітність інфраструктури Web3, інакше виникнуть проблеми централізації. Ми закликаємо розробників DApp створювати продукти з пріоритетом для місцевих потреб, а також закликаємо технологічну спільноту враховувати ситуації, коли служби для отримання даних не працюють під час проектування DApp, щоб користувачі могли взаємодіяти з проектами навіть без інфраструктури для отримання даних.
!
Дослідження джерел даних Dapp
Щоб зрозуміти виникнення таких подій, як Goldsky, нам потрібно глибше зрозуміти механізм роботи DApp. Для звичайного користувача DApp зазвичай складається лише з двох частин: смарт-контрактів на ланцюгу та фронтенд-сторінки. Але звідки насправді походять ці дані, що відображаються на фронтенді користувача?
Необхідність послуг з пошуку даних
Наприклад, у випадку створення кредитного договору, цей договір повинен відображати інформацію про позиції користувача, а також маржу та борговий статус кожної позиції. Пряме зчитування цих даних з блокчейну на практиці часто є недоцільним, оскільки контракти зазвичай пропонують функції для запиту конкретних даних лише за ідентифікатором позиції. Щоб відобразити інформацію про позиції користувача на фронтенді, необхідно отримати всі позиції в системі, а потім відфільтрувати ті, що належать поточному користувачу. Цей процес, навіть якщо на сервері виконувати його безпосередньо за допомогою локального вузла, часто займає кілька годин.
Тому необхідно впровадити інфраструктуру для прискорення отримання даних. Компанії, такі як Goldsky, якраз і надають ці послуги з індексації даних.
TheGraph / Відносини між Goldsky та SubGraph
SubGraph є розробницьким фреймворком, який використовується для читання та узагальнення даних з блокчейну та відображення цих даних на фронтенді. TheGraph і Goldsky насправді є хостингами для SubGraph. Програми, розроблені на платформі SubGraph, потрібно запускати на сервері, і різні оператори мають різні стратегії та технічні рішення.
Модель збору коштів Goldsky
Goldsky використовує стандарт обліку на основі використання ресурсів, що є найпоширенішим способом обліку на платформах SaaS в Інтернеті.
Модель оплати TheGraph
TheGraph має набір тарифних планів, які відрізняються від звичайних способів оплати, пов'язаних з економікою токенів GRT. Включає плату за запит за раз та плату за заставу Signal.
Виклики, з якими стикаються розробники
Для більшості розробників використання TheGraph є відносно незручним. Існує дві основні проблеми:
Невизначеність кількості GRT, що підлягає стейкінгу, та часу, необхідного для залучення операторів.
Складність обліку витрат та бухгалтерії
У порівнянні з цим, вибір Goldsky є простішим, спосіб нарахування зрозумілий, майже можна використовувати миттєво, невизначеність значно знижена. Це призвело до ситуації, коли на послуги індексації та пошуку даних блокчейну виникла залежність від єдиного продукту.
!
Три, наявні рішення
роздуми
ponder є простим, з хорошим досвідом розробки та легким у розгортанні програмним забезпеченням для пошуку даних. Його переваги включають:
Без залежності від постачальників
Хороший досвід розробки
Вища продуктивність
комерційний шлях ponder відповідає "теорії ізоляції", реалізуючи ціноутворення шляхом стягнення зборів з частини однорідних груп.
концепція розробки local-first
У розробці блокчейну концепцію local-first можна реалізувати наступним чином:
Кешування ключових даних
Дизайн функції зниження
Цей дизайн може суттєво підвищити стійкість застосунку, запобігаючи його недоступності після збою служби пошуку даних.
!
Чотири, висновок
Інцидент з Goldsky став тривожним сигналом для екосистеми. Хоча блокчейн сам по собі має характеристики децентралізації та стійкості до єдиного пункту відмови, додаткова екосистема, що будується на ньому, все ще сильно залежить від централізованих інфраструктурних послуг, що створює системні ризики для всієї екосистеми.
Ця стаття обговорює причини, чому TheGraph не використовується широко, представляє рамки самообслуговування ponder як аварійний варіант і досліджує концепцію розробки, орієнтовану на локальність. Ми закликаємо більше розробників звернути увагу на інфраструктуру для отримання даних, спробувати створити децентралізовані послуги або розробити рамки, які дозволяють фронтенду DApp працювати навіть без послуг отримання даних.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
8 лайків
Нагородити
8
5
Репост
Поділіться
Прокоментувати
0/400
WealthCoffee
· 3год тому
Централізація чи децентралізація? Кажучи правду, це все ж не стало централізацією.
Переглянути оригіналвідповісти на0
FloorPriceWatcher
· 08-08 05:21
Ну й справді, так важко налаштувати індекс?
Переглянути оригіналвідповісти на0
Fren_Not_Food
· 08-08 05:15
Великий капітал контролює ринок прогнозів [开心]
Переглянути оригіналвідповісти на0
DaisyUnicorn
· 08-08 05:09
Блокчейн даних маленький садівник, цілий день шукає квітучу Децентралізація маленьку ромашку~
Polymarket困境：ринок прогнозів даних індексу Децентралізація труднощі
Шифрування громадських трагедій: Дилема індексації даних ринку прогнозів
Резюме
Ласкаво просимо до серії "Трагедія спільного блага". Ця серія зосереджується на "публічних товарах", які опинилися на критичних етапах у світі шифрування, але поступово втрачають свою норму. Ці інфраструктури часто стикаються з проблемами недостатніх стимулів, дисбалансу в управлінні та навіть поступової централізації.
У цьому випуску ми зосередимося на одному з найвідоміших застосувань в екосистемі Ethereum: Polymarket та його інструментах індексації даних. Окремі події, такі як перемога Трампа та маніпуляції оракулів навколо торгівлі рідкоземельними елементами в Україні, зробили Polymarket предметом обговорення. Однак чи дійсно цей продукт, що представляє "децентралізований ринок прогнозів", реалізував справжню децентралізацію у своїй ключовій основній модулі — індексації даних? Чому такі публічні інфраструктури, як The Graph, не змогли виконати очікувану роль? Якими повинні бути справжні корисні та стійкі публічні блага для індексації даних?
Один. Ланцюгова реакція, спричинена збоєм централізованої платформи даних
У липні 2024 року Goldsky сталася аварія, яка тривала шість годин, внаслідок чого велика частина проектів екосистеми Ethereum опинилася в стані паралічу. Передня частина DeFi не могла відобразити дані про позиції та баланси користувачів, ринок прогнозів Polymarket не міг відобразити правильні дані, безліч проектів здавалося повністю недоступними для користувачів.
Це не повинно було статися в світі децентралізованих застосунків. Чи не було задумом технології блокчейн усунути єдину точку відмови? Інцидент з Goldsky виявив тривожний факт: хоча сам блокчейн досяг максимальної децентралізації, інфраструктура, на якій розгортаються застосунки, часто містить велику кількість централізованих сервісів.
Індексування та пошук даних блокчейну належать до "неконкурентних, неексклюзивних" цифрових суспільних продуктів, користувачі зазвичай очікують безкоштовного або дуже низького тарифу, але за цим стоять постійні витрати на потужне обладнання, зберігання, ширину каналу та людські ресурси для обслуговування. Відсутність стійкої моделі прибутку призводить до концентрації, коли один переможець отримує все: якщо один постачальник послуг досягає переваги в швидкості та капіталі, розробники схиляються до того, щоб перенаправити весь потік запитів до цього сервісу, що знову формує залежність від єдиного постачальника.
Це застерігає нас, що децентралізованому світу терміново потрібне фінансування через громадські продукти, перерозподіл або ініціативи, керовані спільнотою, щоб збагачувати різноманітність інфраструктури Web3, інакше виникнуть проблеми централізації. Ми закликаємо розробників DApp створювати продукти з пріоритетом для місцевих потреб, а також закликаємо технологічну спільноту враховувати ситуації, коли служби для отримання даних не працюють під час проектування DApp, щоб користувачі могли взаємодіяти з проектами навіть без інфраструктури для отримання даних.
!
Дослідження джерел даних Dapp
Щоб зрозуміти виникнення таких подій, як Goldsky, нам потрібно глибше зрозуміти механізм роботи DApp. Для звичайного користувача DApp зазвичай складається лише з двох частин: смарт-контрактів на ланцюгу та фронтенд-сторінки. Але звідки насправді походять ці дані, що відображаються на фронтенді користувача?
Необхідність послуг з пошуку даних
Наприклад, у випадку створення кредитного договору, цей договір повинен відображати інформацію про позиції користувача, а також маржу та борговий статус кожної позиції. Пряме зчитування цих даних з блокчейну на практиці часто є недоцільним, оскільки контракти зазвичай пропонують функції для запиту конкретних даних лише за ідентифікатором позиції. Щоб відобразити інформацію про позиції користувача на фронтенді, необхідно отримати всі позиції в системі, а потім відфільтрувати ті, що належать поточному користувачу. Цей процес, навіть якщо на сервері виконувати його безпосередньо за допомогою локального вузла, часто займає кілька годин.
Тому необхідно впровадити інфраструктуру для прискорення отримання даних. Компанії, такі як Goldsky, якраз і надають ці послуги з індексації даних.
TheGraph / Відносини між Goldsky та SubGraph
SubGraph є розробницьким фреймворком, який використовується для читання та узагальнення даних з блокчейну та відображення цих даних на фронтенді. TheGraph і Goldsky насправді є хостингами для SubGraph. Програми, розроблені на платформі SubGraph, потрібно запускати на сервері, і різні оператори мають різні стратегії та технічні рішення.
Модель збору коштів Goldsky
Goldsky використовує стандарт обліку на основі використання ресурсів, що є найпоширенішим способом обліку на платформах SaaS в Інтернеті.
Модель оплати TheGraph
TheGraph має набір тарифних планів, які відрізняються від звичайних способів оплати, пов'язаних з економікою токенів GRT. Включає плату за запит за раз та плату за заставу Signal.
Виклики, з якими стикаються розробники
Для більшості розробників використання TheGraph є відносно незручним. Існує дві основні проблеми:
У порівнянні з цим, вибір Goldsky є простішим, спосіб нарахування зрозумілий, майже можна використовувати миттєво, невизначеність значно знижена. Це призвело до ситуації, коли на послуги індексації та пошуку даних блокчейну виникла залежність від єдиного продукту.
!
Три, наявні рішення
роздуми
ponder є простим, з хорошим досвідом розробки та легким у розгортанні програмним забезпеченням для пошуку даних. Його переваги включають:
комерційний шлях ponder відповідає "теорії ізоляції", реалізуючи ціноутворення шляхом стягнення зборів з частини однорідних груп.
концепція розробки local-first
У розробці блокчейну концепцію local-first можна реалізувати наступним чином:
Цей дизайн може суттєво підвищити стійкість застосунку, запобігаючи його недоступності після збою служби пошуку даних.
!
Чотири, висновок
Інцидент з Goldsky став тривожним сигналом для екосистеми. Хоча блокчейн сам по собі має характеристики децентралізації та стійкості до єдиного пункту відмови, додаткова екосистема, що будується на ньому, все ще сильно залежить від централізованих інфраструктурних послуг, що створює системні ризики для всієї екосистеми.
Ця стаття обговорює причини, чому TheGraph не використовується широко, представляє рамки самообслуговування ponder як аварійний варіант і досліджує концепцію розробки, орієнтовану на локальність. Ми закликаємо більше розробників звернути увагу на інфраструктуру для отримання даних, спробувати створити децентралізовані послуги або розробити рамки, які дозволяють фронтенду DApp працювати навіть без послуг отримання даних.
!