В основі архітектури The Graph лежить Графовий вузол (Graph Node). Цей ключовий компонент відповідає за індексування підграфів і робить отримані дані доступними через GraphQL API. Це ядро стека індексатора, і його ефективна робота має вирішальне значення для успішної роботи індексатора. Graph Node працює універсально, здатний працювати як на "голому" металі, так і в хмарному середовищі, що відображає адаптивність, необхідну в динамічному ландшафті технології блокчейн.
Невід'ємною частиною роботи Графового вузла є база даних PostgreSQL, яка виступає в якості основного сховища. Ця база даних містить не лише дані підграфів, але й метадані про підграфи та важливі мережеві дані, такі як кеші блоків та eth_call. Організація та управління цією базою даних є життєво важливими для безперебійної роботи Графового вузла, забезпечуючи цілісність та доступність даних.
Для індексування блокчейн-мереж Graph Node підключається до мережевих клієнтів через EVM-сумісний JSON-RPC API. Таке налаштування може варіюватися від підключення до одного клієнта до більш складної схеми, що передбачає розподіл навантаження між кількома клієнтами. Крім того, The Graph розробив Network Firehoses - gRPC-сервіс, який забезпечує впорядкований потік блоків з урахуванням форків. Хоча наразі Firehose не є обов'язковою вимогою для індексаторів, він являє собою значний прогрес у підтримці масштабного індексування перформерів.
Взаємодія Graph Node з мережею IPFS має вирішальне значення для зберігання метаданих розгортання підграфів. Вузол IPFS, розміщений на мережевому рівні, спрощує цей процес для індексаторів. Крім того, додаткова інтеграція з сервером метрик Prometheus для моніторингу та звітності додає ще один рівень складності, дозволяючи індексаторам відстежувати і оптимізувати продуктивність графічного вузла.
Гнучке налаштування Graph Node, від варіантів встановлення до можливостей масштабування, підкреслює прагнення The Graph задовольнити різні операційні потреби. Система може бути горизонтально масштабована за допомогою декількох графічних вузлів і баз даних, що дозволяє задовольнити зростаючі потреби мережі. Досвідчені користувачі можуть використовувати параметри конфігурації графічного вузла, керовані за допомогою TOML-файлу або змінних середовища, для оптимізації обробки даних і розподілу робочого навантаження.
Firehose, концептуально розроблений StreamingFast, знаменує собою революцію у видобутку даних з вузлів блокчейну. Цей інноваційний інструмент розбиває кожну транзакцію в блоці блокчейну на найдрібніші елементи, зберігаючи їх у вигляді простих пласких файлів. Ці плоскі файли - не просто формат зберігання, вони втілюють зміну парадигми індексування даних. Вони полегшують паралельну обробку, що значно прискорює операції індексування. Ця технологія забезпечує передачу багатих даних з урахуванням форків з інструментальних вузлів блокчейну безпосередньо споживачам. На практиці Firehose продемонстрував свою доблесть, пропонуючи швидкості збору та обробки даних, які колись вважалися недосяжними, тим самим встановивши нові стандарти для вилучення даних в екосистемі The Graph.
Підпотоки, розширення можливостей Firehose, призначені для високопродуктивної обробки даних у паралельному, потоковому режимі. Ці модулі, написані на Rust, дозволяють розробникам компонувати, сортувати, зберігати та трансформувати дані блокчейну для різних цілей. Винахідливість Substreams полягає в тому, що вони можуть використовувати плоскі файли Firehose для індексування даних на надзвичайно високих швидкостях. Такий підхід гарантує, що підпотоки не тільки високоефективно обробляють дані, але й розподіляють їх, як тільки вони стають доступними, замість того, щоб покладатися на постійні запити.
Інтеграція Firehose та підпотоків в екосистемі The Graph забезпечує потужну комбінацію для обробки даних. Firehose забезпечує швидку доставку даних блокчейну в оптимізованому форматі, в той час як підпотоки надалі уточнюють і обробляють ці дані. Цей синергетичний зв'язок призводить до безпрецедентної ефективності в обробці великих обсягів блокчейн-даних, що значно розширює можливості The Graph.
Підграфи стали галузевим стандартом в індексації даних блокчейну з моменту їх впровадження компанією The Graph у 2018 році. По суті, це відкриті API, які витягують, обробляють і зберігають дані з блокчейнів, роблячи їх легко доступними для запитів через інтерфейс GraphQL. Підтримуючи понад 85 000 підграфів у більш ніж 40 ланцюжках, підграфи стали незамінними для web3-розробників. Вони дозволяють швидко розгортати базу даних Postgres, наповнену індексованими даними, готовими до запитів за допомогою шару GraphQL. Підграфи дозволяють розробникам організовано і ефективно відображати широкий спектр даних блокчейну в своїх DApp, від транзакцій DeFi до походження NFT.
У постійно мінливому ландшафті технології блокчейн підграфи стали ключовою концепцією, яка трансформує спосіб взаємодії з даними блокчейну та їх використання. Ці відкриті API діють як посередники, легко долаючи розрив між децентралізованим світом блокчейнів і звичним світом структурованих даних. Витягуючи, обробляючи та організовуючи дані блокчейну у формат, придатний для запитів, підграфи дають розробникам можливість створювати інноваційні додатки, керовані даними.
Підграфи мають безліч переваг, що робить їх привабливим вибором як для розробників, так і для користувачів. Їх децентралізований характер забезпечує стійкість до цензури та простоїв, сприяючи створенню безпечної та надійної екосистеми даних. Крім того, підграфи за своєю природою є масштабованими, здатними обробляти величезні обсяги даних без шкоди для продуктивності. Економічна ефективність - ще одна ключова перевага, оскільки підграфи часто є більш доступними, ніж традиційні API даних.
Підграфи складаються з трьох основних компонентів, які працюють у гармонії, щоб реалізувати свій трансформаційний потенціал:
Маніфест: Маніфест слугує планом підграфа, окреслюючи його джерела даних, схему та код на Асемблері. Він визначає межі даних, які буде індексувати підграф, гарантуючи, що буде зібрана лише релевантна інформація.
Схема: Схема визначає структуру даних, подібно до плану будівлі. Вона описує сутності, поля та зв'язки між сутностями, забезпечуючи чіткий та організований спосіб представлення даних.
Асемблерний код: Цей виконуваний код діє як робоча конячка підграфа, переводячи необроблені дані з блокчейнів у формат, який може зрозуміти механізм GraphQL. Він також займається індексацією та зберіганням даних, забезпечуючи їхню доступність і надійність.
Створення підграфа передбачає ряд кроків, кожен з яких ретельно продуманий для забезпечення функціональності та ефективності підграфа:
Концептуалізація та дизайн: Подорож починається з чіткого уявлення про дані, які потрібно індексувати, і про додатки, для яких вони будуть використовуватися. Це передбачає визначення сутностей, полів і зв'язків між ними, гарантуючи, що структура підграфа відповідає його призначенню.
Розробка маніфесту та схеми: Маніфест і схема ретельно розробляються, забезпечуючи основу для архітектури даних підграфа. Маніфест визначає джерела даних, в той час як схема описує структуру даних, забезпечуючи цілісність та узгодженість даних.
Реалізація коду AssemblyScript: Написання коду на Асемблері, який переводить необроблені дані блокчейну у формат, зрозумілий GraphQL. Вона виконує індексування, зберігання та пошук даних, забезпечуючи ефективний доступ до проіндексованих даних.
Після того, як підграф розроблено, він проходить процес розгортання, який представляє його світу:
Інтеграція з Subgraph Studio: Subgraph Studio слугує централізованою платформою для керування підграфами. Це полегшує процес розгортання, дозволяючи розробникам публікувати свої підграфи в децентралізованій мережі.
Індексування та кураторство: Індексатори, відповідальні за отримання та зберігання даних блокчейну, необхідні для того, щоб зробити підграфи доступними для розробників. Кураторство, яке зазвичай здійснюється за допомогою токенів GRT, стимулює індексаторів надавати пріоритет підграфам з високим попитом.
Запити та використання: Розробники тепер можуть запитувати розгорнутий підграф за допомогою запитів GraphQL, отримуючи конкретні дані, адаптовані до потреб їхніх додатків. Ця безшовна інтеграція дозволяє розробникам використовувати дані блокчейну для інновацій.
Оскільки граф вступає в свою нову еру (ми розглянемо її в Уроці 5), ми з нетерпінням чекаємо на подальший розвиток цих основних технологій - підграфів, пожежних шлангів і підпотоків. Ці компоненти розширюватимуться і розвиватимуться, відіграючи життєво важливу роль у впровадженні нових послуг передачі даних і забезпеченні швидших, більш модульних потоків даних. Наприклад, Verifiable Firehose може стати революційним рішенням для доступу до історичних даних Ethereum, вирішуючи проблеми, пов'язані з розвитком стандартів блокчейну.
Дуже важливо розрізняти підграфи і підпотоки, оскільки вони служать різним цілям. Підграфи ідеально підходять для стандартного пошуку та управління даними, пропонуючи простоту налаштування та використання з шаром запитів GraphQL. І навпаки, підпотоки призначені для більш складної аналітики та великих даних, пропонуючи паралельну обробку даних і більшу гнучкість в обробці та зберіганні даних. Підпотоки дозволяють розробникам перетворювати дані з базових форматів файлів у більш зручні для використання форми, задовольняючи складні вимоги до обробки даних.
Граф, традиційно відомий своєю майстерністю в організації он-лайн даних, тепер розширює свої горизонти, освоюючи сферу позамережевих даних. Такий підхід відповідає довгостроковій місії The Graph - надавати легкий доступ до світових публічних знань та інформації.
В архітектурі Web3, хоча користувачі можуть безпосередньо взаємодіяти з блокчейном через сервіси проміжного програмного забезпечення, існує певний компроміс, особливо коли мова йде про вартість. Транзакційні витрати в ланцюжку, які часто називають платою за газ, можуть бути непомірно високими для складних обчислень або великого обсягу зберігання даних. Історично це обмеження обмежувало складність додатків або змушувало розробників створювати власні позамережеві API, відходячи від моделей з відкритим кодом.
Graph представляє унікальне рішення цієї проблеми, дозволяючи організовувати та обслуговувати позамережеві дані через свою децентралізовану мережу. Цей метод передбачає робочий процес, в якому традиційно поза ланцюжком дані розміщуються в IPFS (Міжпланетна файлова система), а хеші IPFS потім записуються в ланцюжок. Згодом ці дані можна індексувати за підграфами і зробити доступними для запитів. Цей підхід пропонує масштабований і економічний спосіб публікації та обслуговування складних, динамічних даних без витрат на створення і підтримку власних API.
Cron-завдання для обчислення та публікації даних: Позаланцюгове завдання cron виконує складні обчислення і публікує результати до пермавеб-джерела, наприклад, IPFS, що індексується The Graph. Це завдання також генерує ланцюгову транзакцію для публікації хешу файлу IPFS і будь-яких відповідних метаданих.
Публікація підграфа для індексації: Наступний крок передбачає публікацію підграфа, який індексує ці IPFS-файли на основі хешів файлів, розміщених у ланцюжку. Після публікації підграфа його можуть підхоплювати і обслуговувати індексатори в мережі The Graph, що дозволяє стороннім розробникам і користувачам запитувати дані.
Надійний і безпечний доступ до даних: Завдяки використанню розподіленої мережі індексаторів The Graph, доступ до даних залишається надійним і надійним без додаткових зусиль з боку видавця даних. Така децентралізована структура значно підвищує доступність та цілісність даних.
Практичним прикладом в екосистемі The Graph є оракул, розроблений Edge & Node для публікації мережевих показників вартості та якості послуг. Цей оракул відправляє агреговані дані в IPFS кожні п'ять хвилин і реєструє хеш файлу IPFS в ланцюжку Gnosis. Потім ці дані індексуються в підграфі, який може бути використаний зацікавленими сторонами протоколу. Витрати, пов'язані з цим робочим процесом, напрочуд низькі, що робить його привабливим варіантом для видавців даних.
Цей метод використання The Graph для динамічних даних відкриває нові захоплюючі можливості для перманет-сайтів, в тому числі ощадливі бекендери для блогів, алгоритмічну курацію контенту та системи моніторингу в реальному часі. Він являє собою значний зсув у способах публікації, індексації та доступу до даних, сприяючи більш відкритій та спільній екосистемі web3.
Розширення Графа на управління позамережевими даними відкриває нові можливості в екосистемі Web3, створюючи міст між децентралізованою та традиційною сферами даних. Ця ініціатива відображає місію The Graph - зробити ширший спектр інформації доступним у децентралізований спосіб, усуваючи обмеження, притаманні мережевому зберіганню даних та обчисленням.
Графік відображає компроміси, пов'язані з витратами на зберігання даних і обчислення в ланцюжку в архітектурі Web3. Хоча безпосередня взаємодія з блокчейном є простою, складні обчислення та зберігання великих обсягів даних можуть стати непомірно дорогими. Щоб обійти ці обмеження, The Graph впроваджує метод, який поєднує позамережеве зберігання даних з мережевими посиланнями на дані, тим самим зберігаючи децентралізовану суть і водночас розширюючи функціональність.
Обчислення поза ланцюжком і розміщення в IPFS: Складні обчислення виконуються поза ланцюжком, а отримані дані розміщуються в IPFS, децентралізованому сховищі даних. Цей крок гарантує, що дані, хоч і зберігаються поза ланцюжком, але їх можна перевірити та децентралізовано.
Зв'язування в ланцюжку за допомогою транзакцій: Поряд зі зберіганням даних на IPFS, виконується відповідна транзакція в ланцюжку для реєстрації хешу IPFS та інших відповідних метаданих. Цей метод прив'язує позаланцюгові дані до блокчейну, забезпечуючи рівень довіри та відстежуваності.
Індексування підграфів для доступності: Останній крок передбачає індексування даних, що зберігаються в IPFS, за допомогою підграфів. Цей процес робить позамережеві дані легкодоступними для запитів і доступними через децентралізовану мережу The Graph.
Практична реалізація: Edge & Node's Oracle
Практичним застосуванням цієї методології в екосистемі The Graph є оракул, розроблений Edge & Node. Цей оракул кожні п'ять хвилин публікує метрики вартості мережі та якості обслуговування наступним чином:
Агреговані дані розміщуються в IPFS.
Відповідний хеш файлу IPFS записується в ланцюжок Gnosis за допомогою контракту DataEdge.
Ці файли IPFS індексуються в підграфі, що робить дані доступними для зацікавлених сторін у децентралізований спосіб.
Ця реалізація демонструє недорогий, масштабований та ефективний підхід до публікації та обслуговування складних даних без необхідності використання пропрієтарних API. Він ілюструє, як метод The Graph може бути використаний для створення динамічних джерел даних для різноманітних додатків.
Витрати, пов'язані з цим робочим процесом, напрочуд низькі, що робить його привабливим рішенням для видавців даних. Наприклад, реалізація оракула на вузлі Edge & несе мінімальні витрати на внутрішньоланцюгові транзакції та пінінг вузлів IPFS, а витрати на обслуговування несе споживач даних. Ця модель ефективно знижує операційні витрати для видавців даних, забезпечуючи при цьому надійний і надійний доступ до даних.
Цей метод відкриває нові можливості для додатків permaweb, такі як динамічний бекенд для блогів, алгоритмічна курація контенту та системи моніторингу в реальному часі. Це дозволяє відокремити видавців даних від операторів додатків/фронт-енду, заохочуючи спеціалізацію та розподіл праці у спільноті з відкритим вихідним кодом. Цей підхід є перспективним для децентралізованих соціальних додатків і протоколів, пропонуючи новий шлях для децентралізованої публікації та споживання даних.
Інтеграція GraphQL як мови запитів. Це рішення суттєво змінює спосіб доступу до даних та взаємодії з ними через API інтерфейси The Graph, забезпечуючи спрощений та ефективний метод запитів до даних блокчейну.
GraphQL знаходиться в авангарді сучасного дизайну API, пропонуючи гнучкий та ефективний підхід до пошуку даних. У контексті блокчейну, де структури даних є складними і постійно змінюються, здатність GraphQL отримувати саме те, що потрібно, стає безцінною.
Адаптовані запити до даних: В основі привабливості GraphQL лежить його здатність дозволяти клієнтам точно визначати структуру даних, які їм потрібні. Ця можливість є значним відходом від традиційного реагування з фіксованою структурою, що дозволяє більш цілеспрямовано та ефективно взаємодіяти з даними.
Покращення взаємодії в реальному часі: GraphQL in The Graph підтримує не тільки запити, але й підписку на дані в реальному часі. Ця функція є життєво важливою для блокчейн-додатків, де своєчасні оновлення та швидкість реагування є ключовими для користувацького досвіду.
Децентралізований та надійний доступ до даних: Використання GraphQL розширює філософію децентралізації в Graph на сферу доступу до даних. Взаємодіючи з мережею децентралізованих вузлів, запити GraphQL гарантують, що дані залишаються відкритими, прозорими і стійкими до цензури.
Конвергенція API та GraphQL
В екосистемі The Graph поєднання API з GraphQL створює гармонійну та потужну систему для пошуку даних:
Визначення схеми та відображення даних: Розробники визначають схему GraphQL в межах свого підграфа, окреслюючи структуру даних, що підлягають запиту. Потім схема складним чином зіставляється з подіями блокчейну, переводячи дії в ланцюжку в структуровані дані.
Виконання запитів через індексатори: Коли GraphQL-запит надсилається до API підграфа, він обробляється децентралізованою мережею індексаторів The Graph. Цей процес є прикладом того, як запити виконуються розподілено, дотримуючись принципів технології блокчейн.
Обробка складних зв'язків між даними: Оскільки складні взаємозв'язки даних є звичайним явищем у блокчейні, здатність GraphQL обробляти складні запити, включаючи різні форми фільтрації та сортування даних, є особливо корисною.
Переваги для розробників та кінцевих користувачів
Інтеграція GraphQL в The Graph дає безліч переваг:
В основі архітектури The Graph лежить Графовий вузол (Graph Node). Цей ключовий компонент відповідає за індексування підграфів і робить отримані дані доступними через GraphQL API. Це ядро стека індексатора, і його ефективна робота має вирішальне значення для успішної роботи індексатора. Graph Node працює універсально, здатний працювати як на "голому" металі, так і в хмарному середовищі, що відображає адаптивність, необхідну в динамічному ландшафті технології блокчейн.
Невід'ємною частиною роботи Графового вузла є база даних PostgreSQL, яка виступає в якості основного сховища. Ця база даних містить не лише дані підграфів, але й метадані про підграфи та важливі мережеві дані, такі як кеші блоків та eth_call. Організація та управління цією базою даних є життєво важливими для безперебійної роботи Графового вузла, забезпечуючи цілісність та доступність даних.
Для індексування блокчейн-мереж Graph Node підключається до мережевих клієнтів через EVM-сумісний JSON-RPC API. Таке налаштування може варіюватися від підключення до одного клієнта до більш складної схеми, що передбачає розподіл навантаження між кількома клієнтами. Крім того, The Graph розробив Network Firehoses - gRPC-сервіс, який забезпечує впорядкований потік блоків з урахуванням форків. Хоча наразі Firehose не є обов'язковою вимогою для індексаторів, він являє собою значний прогрес у підтримці масштабного індексування перформерів.
Взаємодія Graph Node з мережею IPFS має вирішальне значення для зберігання метаданих розгортання підграфів. Вузол IPFS, розміщений на мережевому рівні, спрощує цей процес для індексаторів. Крім того, додаткова інтеграція з сервером метрик Prometheus для моніторингу та звітності додає ще один рівень складності, дозволяючи індексаторам відстежувати і оптимізувати продуктивність графічного вузла.
Гнучке налаштування Graph Node, від варіантів встановлення до можливостей масштабування, підкреслює прагнення The Graph задовольнити різні операційні потреби. Система може бути горизонтально масштабована за допомогою декількох графічних вузлів і баз даних, що дозволяє задовольнити зростаючі потреби мережі. Досвідчені користувачі можуть використовувати параметри конфігурації графічного вузла, керовані за допомогою TOML-файлу або змінних середовища, для оптимізації обробки даних і розподілу робочого навантаження.
Firehose, концептуально розроблений StreamingFast, знаменує собою революцію у видобутку даних з вузлів блокчейну. Цей інноваційний інструмент розбиває кожну транзакцію в блоці блокчейну на найдрібніші елементи, зберігаючи їх у вигляді простих пласких файлів. Ці плоскі файли - не просто формат зберігання, вони втілюють зміну парадигми індексування даних. Вони полегшують паралельну обробку, що значно прискорює операції індексування. Ця технологія забезпечує передачу багатих даних з урахуванням форків з інструментальних вузлів блокчейну безпосередньо споживачам. На практиці Firehose продемонстрував свою доблесть, пропонуючи швидкості збору та обробки даних, які колись вважалися недосяжними, тим самим встановивши нові стандарти для вилучення даних в екосистемі The Graph.
Підпотоки, розширення можливостей Firehose, призначені для високопродуктивної обробки даних у паралельному, потоковому режимі. Ці модулі, написані на Rust, дозволяють розробникам компонувати, сортувати, зберігати та трансформувати дані блокчейну для різних цілей. Винахідливість Substreams полягає в тому, що вони можуть використовувати плоскі файли Firehose для індексування даних на надзвичайно високих швидкостях. Такий підхід гарантує, що підпотоки не тільки високоефективно обробляють дані, але й розподіляють їх, як тільки вони стають доступними, замість того, щоб покладатися на постійні запити.
Інтеграція Firehose та підпотоків в екосистемі The Graph забезпечує потужну комбінацію для обробки даних. Firehose забезпечує швидку доставку даних блокчейну в оптимізованому форматі, в той час як підпотоки надалі уточнюють і обробляють ці дані. Цей синергетичний зв'язок призводить до безпрецедентної ефективності в обробці великих обсягів блокчейн-даних, що значно розширює можливості The Graph.
Підграфи стали галузевим стандартом в індексації даних блокчейну з моменту їх впровадження компанією The Graph у 2018 році. По суті, це відкриті API, які витягують, обробляють і зберігають дані з блокчейнів, роблячи їх легко доступними для запитів через інтерфейс GraphQL. Підтримуючи понад 85 000 підграфів у більш ніж 40 ланцюжках, підграфи стали незамінними для web3-розробників. Вони дозволяють швидко розгортати базу даних Postgres, наповнену індексованими даними, готовими до запитів за допомогою шару GraphQL. Підграфи дозволяють розробникам організовано і ефективно відображати широкий спектр даних блокчейну в своїх DApp, від транзакцій DeFi до походження NFT.
У постійно мінливому ландшафті технології блокчейн підграфи стали ключовою концепцією, яка трансформує спосіб взаємодії з даними блокчейну та їх використання. Ці відкриті API діють як посередники, легко долаючи розрив між децентралізованим світом блокчейнів і звичним світом структурованих даних. Витягуючи, обробляючи та організовуючи дані блокчейну у формат, придатний для запитів, підграфи дають розробникам можливість створювати інноваційні додатки, керовані даними.
Підграфи мають безліч переваг, що робить їх привабливим вибором як для розробників, так і для користувачів. Їх децентралізований характер забезпечує стійкість до цензури та простоїв, сприяючи створенню безпечної та надійної екосистеми даних. Крім того, підграфи за своєю природою є масштабованими, здатними обробляти величезні обсяги даних без шкоди для продуктивності. Економічна ефективність - ще одна ключова перевага, оскільки підграфи часто є більш доступними, ніж традиційні API даних.
Підграфи складаються з трьох основних компонентів, які працюють у гармонії, щоб реалізувати свій трансформаційний потенціал:
Маніфест: Маніфест слугує планом підграфа, окреслюючи його джерела даних, схему та код на Асемблері. Він визначає межі даних, які буде індексувати підграф, гарантуючи, що буде зібрана лише релевантна інформація.
Схема: Схема визначає структуру даних, подібно до плану будівлі. Вона описує сутності, поля та зв'язки між сутностями, забезпечуючи чіткий та організований спосіб представлення даних.
Асемблерний код: Цей виконуваний код діє як робоча конячка підграфа, переводячи необроблені дані з блокчейнів у формат, який може зрозуміти механізм GraphQL. Він також займається індексацією та зберіганням даних, забезпечуючи їхню доступність і надійність.
Створення підграфа передбачає ряд кроків, кожен з яких ретельно продуманий для забезпечення функціональності та ефективності підграфа:
Концептуалізація та дизайн: Подорож починається з чіткого уявлення про дані, які потрібно індексувати, і про додатки, для яких вони будуть використовуватися. Це передбачає визначення сутностей, полів і зв'язків між ними, гарантуючи, що структура підграфа відповідає його призначенню.
Розробка маніфесту та схеми: Маніфест і схема ретельно розробляються, забезпечуючи основу для архітектури даних підграфа. Маніфест визначає джерела даних, в той час як схема описує структуру даних, забезпечуючи цілісність та узгодженість даних.
Реалізація коду AssemblyScript: Написання коду на Асемблері, який переводить необроблені дані блокчейну у формат, зрозумілий GraphQL. Вона виконує індексування, зберігання та пошук даних, забезпечуючи ефективний доступ до проіндексованих даних.
Після того, як підграф розроблено, він проходить процес розгортання, який представляє його світу:
Інтеграція з Subgraph Studio: Subgraph Studio слугує централізованою платформою для керування підграфами. Це полегшує процес розгортання, дозволяючи розробникам публікувати свої підграфи в децентралізованій мережі.
Індексування та кураторство: Індексатори, відповідальні за отримання та зберігання даних блокчейну, необхідні для того, щоб зробити підграфи доступними для розробників. Кураторство, яке зазвичай здійснюється за допомогою токенів GRT, стимулює індексаторів надавати пріоритет підграфам з високим попитом.
Запити та використання: Розробники тепер можуть запитувати розгорнутий підграф за допомогою запитів GraphQL, отримуючи конкретні дані, адаптовані до потреб їхніх додатків. Ця безшовна інтеграція дозволяє розробникам використовувати дані блокчейну для інновацій.
Оскільки граф вступає в свою нову еру (ми розглянемо її в Уроці 5), ми з нетерпінням чекаємо на подальший розвиток цих основних технологій - підграфів, пожежних шлангів і підпотоків. Ці компоненти розширюватимуться і розвиватимуться, відіграючи життєво важливу роль у впровадженні нових послуг передачі даних і забезпеченні швидших, більш модульних потоків даних. Наприклад, Verifiable Firehose може стати революційним рішенням для доступу до історичних даних Ethereum, вирішуючи проблеми, пов'язані з розвитком стандартів блокчейну.
Дуже важливо розрізняти підграфи і підпотоки, оскільки вони служать різним цілям. Підграфи ідеально підходять для стандартного пошуку та управління даними, пропонуючи простоту налаштування та використання з шаром запитів GraphQL. І навпаки, підпотоки призначені для більш складної аналітики та великих даних, пропонуючи паралельну обробку даних і більшу гнучкість в обробці та зберіганні даних. Підпотоки дозволяють розробникам перетворювати дані з базових форматів файлів у більш зручні для використання форми, задовольняючи складні вимоги до обробки даних.
Граф, традиційно відомий своєю майстерністю в організації он-лайн даних, тепер розширює свої горизонти, освоюючи сферу позамережевих даних. Такий підхід відповідає довгостроковій місії The Graph - надавати легкий доступ до світових публічних знань та інформації.
В архітектурі Web3, хоча користувачі можуть безпосередньо взаємодіяти з блокчейном через сервіси проміжного програмного забезпечення, існує певний компроміс, особливо коли мова йде про вартість. Транзакційні витрати в ланцюжку, які часто називають платою за газ, можуть бути непомірно високими для складних обчислень або великого обсягу зберігання даних. Історично це обмеження обмежувало складність додатків або змушувало розробників створювати власні позамережеві API, відходячи від моделей з відкритим кодом.
Graph представляє унікальне рішення цієї проблеми, дозволяючи організовувати та обслуговувати позамережеві дані через свою децентралізовану мережу. Цей метод передбачає робочий процес, в якому традиційно поза ланцюжком дані розміщуються в IPFS (Міжпланетна файлова система), а хеші IPFS потім записуються в ланцюжок. Згодом ці дані можна індексувати за підграфами і зробити доступними для запитів. Цей підхід пропонує масштабований і економічний спосіб публікації та обслуговування складних, динамічних даних без витрат на створення і підтримку власних API.
Cron-завдання для обчислення та публікації даних: Позаланцюгове завдання cron виконує складні обчислення і публікує результати до пермавеб-джерела, наприклад, IPFS, що індексується The Graph. Це завдання також генерує ланцюгову транзакцію для публікації хешу файлу IPFS і будь-яких відповідних метаданих.
Публікація підграфа для індексації: Наступний крок передбачає публікацію підграфа, який індексує ці IPFS-файли на основі хешів файлів, розміщених у ланцюжку. Після публікації підграфа його можуть підхоплювати і обслуговувати індексатори в мережі The Graph, що дозволяє стороннім розробникам і користувачам запитувати дані.
Надійний і безпечний доступ до даних: Завдяки використанню розподіленої мережі індексаторів The Graph, доступ до даних залишається надійним і надійним без додаткових зусиль з боку видавця даних. Така децентралізована структура значно підвищує доступність та цілісність даних.
Практичним прикладом в екосистемі The Graph є оракул, розроблений Edge & Node для публікації мережевих показників вартості та якості послуг. Цей оракул відправляє агреговані дані в IPFS кожні п'ять хвилин і реєструє хеш файлу IPFS в ланцюжку Gnosis. Потім ці дані індексуються в підграфі, який може бути використаний зацікавленими сторонами протоколу. Витрати, пов'язані з цим робочим процесом, напрочуд низькі, що робить його привабливим варіантом для видавців даних.
Цей метод використання The Graph для динамічних даних відкриває нові захоплюючі можливості для перманет-сайтів, в тому числі ощадливі бекендери для блогів, алгоритмічну курацію контенту та системи моніторингу в реальному часі. Він являє собою значний зсув у способах публікації, індексації та доступу до даних, сприяючи більш відкритій та спільній екосистемі web3.
Розширення Графа на управління позамережевими даними відкриває нові можливості в екосистемі Web3, створюючи міст між децентралізованою та традиційною сферами даних. Ця ініціатива відображає місію The Graph - зробити ширший спектр інформації доступним у децентралізований спосіб, усуваючи обмеження, притаманні мережевому зберіганню даних та обчисленням.
Графік відображає компроміси, пов'язані з витратами на зберігання даних і обчислення в ланцюжку в архітектурі Web3. Хоча безпосередня взаємодія з блокчейном є простою, складні обчислення та зберігання великих обсягів даних можуть стати непомірно дорогими. Щоб обійти ці обмеження, The Graph впроваджує метод, який поєднує позамережеве зберігання даних з мережевими посиланнями на дані, тим самим зберігаючи децентралізовану суть і водночас розширюючи функціональність.
Обчислення поза ланцюжком і розміщення в IPFS: Складні обчислення виконуються поза ланцюжком, а отримані дані розміщуються в IPFS, децентралізованому сховищі даних. Цей крок гарантує, що дані, хоч і зберігаються поза ланцюжком, але їх можна перевірити та децентралізовано.
Зв'язування в ланцюжку за допомогою транзакцій: Поряд зі зберіганням даних на IPFS, виконується відповідна транзакція в ланцюжку для реєстрації хешу IPFS та інших відповідних метаданих. Цей метод прив'язує позаланцюгові дані до блокчейну, забезпечуючи рівень довіри та відстежуваності.
Індексування підграфів для доступності: Останній крок передбачає індексування даних, що зберігаються в IPFS, за допомогою підграфів. Цей процес робить позамережеві дані легкодоступними для запитів і доступними через децентралізовану мережу The Graph.
Практична реалізація: Edge & Node's Oracle
Практичним застосуванням цієї методології в екосистемі The Graph є оракул, розроблений Edge & Node. Цей оракул кожні п'ять хвилин публікує метрики вартості мережі та якості обслуговування наступним чином:
Агреговані дані розміщуються в IPFS.
Відповідний хеш файлу IPFS записується в ланцюжок Gnosis за допомогою контракту DataEdge.
Ці файли IPFS індексуються в підграфі, що робить дані доступними для зацікавлених сторін у децентралізований спосіб.
Ця реалізація демонструє недорогий, масштабований та ефективний підхід до публікації та обслуговування складних даних без необхідності використання пропрієтарних API. Він ілюструє, як метод The Graph може бути використаний для створення динамічних джерел даних для різноманітних додатків.
Витрати, пов'язані з цим робочим процесом, напрочуд низькі, що робить його привабливим рішенням для видавців даних. Наприклад, реалізація оракула на вузлі Edge & несе мінімальні витрати на внутрішньоланцюгові транзакції та пінінг вузлів IPFS, а витрати на обслуговування несе споживач даних. Ця модель ефективно знижує операційні витрати для видавців даних, забезпечуючи при цьому надійний і надійний доступ до даних.
Цей метод відкриває нові можливості для додатків permaweb, такі як динамічний бекенд для блогів, алгоритмічна курація контенту та системи моніторингу в реальному часі. Це дозволяє відокремити видавців даних від операторів додатків/фронт-енду, заохочуючи спеціалізацію та розподіл праці у спільноті з відкритим вихідним кодом. Цей підхід є перспективним для децентралізованих соціальних додатків і протоколів, пропонуючи новий шлях для децентралізованої публікації та споживання даних.
Інтеграція GraphQL як мови запитів. Це рішення суттєво змінює спосіб доступу до даних та взаємодії з ними через API інтерфейси The Graph, забезпечуючи спрощений та ефективний метод запитів до даних блокчейну.
GraphQL знаходиться в авангарді сучасного дизайну API, пропонуючи гнучкий та ефективний підхід до пошуку даних. У контексті блокчейну, де структури даних є складними і постійно змінюються, здатність GraphQL отримувати саме те, що потрібно, стає безцінною.
Адаптовані запити до даних: В основі привабливості GraphQL лежить його здатність дозволяти клієнтам точно визначати структуру даних, які їм потрібні. Ця можливість є значним відходом від традиційного реагування з фіксованою структурою, що дозволяє більш цілеспрямовано та ефективно взаємодіяти з даними.
Покращення взаємодії в реальному часі: GraphQL in The Graph підтримує не тільки запити, але й підписку на дані в реальному часі. Ця функція є життєво важливою для блокчейн-додатків, де своєчасні оновлення та швидкість реагування є ключовими для користувацького досвіду.
Децентралізований та надійний доступ до даних: Використання GraphQL розширює філософію децентралізації в Graph на сферу доступу до даних. Взаємодіючи з мережею децентралізованих вузлів, запити GraphQL гарантують, що дані залишаються відкритими, прозорими і стійкими до цензури.
Конвергенція API та GraphQL
В екосистемі The Graph поєднання API з GraphQL створює гармонійну та потужну систему для пошуку даних:
Визначення схеми та відображення даних: Розробники визначають схему GraphQL в межах свого підграфа, окреслюючи структуру даних, що підлягають запиту. Потім схема складним чином зіставляється з подіями блокчейну, переводячи дії в ланцюжку в структуровані дані.
Виконання запитів через індексатори: Коли GraphQL-запит надсилається до API підграфа, він обробляється децентралізованою мережею індексаторів The Graph. Цей процес є прикладом того, як запити виконуються розподілено, дотримуючись принципів технології блокчейн.
Обробка складних зв'язків між даними: Оскільки складні взаємозв'язки даних є звичайним явищем у блокчейні, здатність GraphQL обробляти складні запити, включаючи різні форми фільтрації та сортування даних, є особливо корисною.
Переваги для розробників та кінцевих користувачів
Інтеграція GraphQL в The Graph дає безліч переваг: