Туторіал по файловим джерелам даних: Використання підграфів для індексації офф-чейн даних

https://thegraph.com/blog/file-data-sources-tutorial/

TLDR: Поєднуючи файли IPFS та Arweave з інформацією в мережі, підграфи можуть надавати нові рішення для даних у децентралізованих додатках. Читайте цю статтю блогу, щоб дізнатися про методи вирішення проблем, з якими може зіткнутися розробник підграфів, а також про створення підграфа File Data Sources, який індексує повідомлення Lens Protocol.

Готовий репозиторій підграфа File Data Sources цього туторіала.

Опублікований підграф File Data Sources доступний в мережі The Graph.

Технологія та термінологія цього туторіала

File Data Sources - функція підграфа, призначена для індексації офф-чейн файлів та їх вмісту. Наразі File Data Sources може індексувати файли, що зберігаються на Arweave та IFPS.

Arweave - децентралізована мережа зберігання даних, спрямована на забезпечення постійного й незмінного зберігання даних. На відміну від інших сховищ, вона пропонує модель одноразової оплати, гарантуючи постійне зберігання даних без повторних платежів.

IPFS (InterPlanetary File System) - однорангова мережа, яка дозволяє децентралізовано обмінюватися файлами та зберігати їх, маючи на меті зробити Інтернет швидшим, безпечнішим та відкритішим. На відміну від моделі постійного зберігання Arweave, IPFS дозволяє динамічне оновлення та отримання даних, але не гарантує вічного зберігання даних.

Lens Protocol - децентралізований соціальний граф, призначений для надання користувачам контролю над їхнім контентом та зв'язками у просторі, орієнтованому на web3. Lens Protocol зберігає контент як на Arweave, так і на IPFS, що значно вигідніше, ніж зберігати ці дані в мережі.

ABI (Application Binary Interface) - це стандартизований метод взаємодії зі смарт-контрактами в блокчейні, який визначає, як викликати функції, як структурувати дані і як інтерпретувати результати. Підграфи використовують ABI для декодування та індексації подій смарт-контрактів і викликів функцій, що дозволяє ефективно і структуровано запитувати дані блокчейну.

Шаблони джерел даних (DST) - використовуються для індексації динамічних джерел даних. Існує два способи використання шаблонів джерел даних в підграфах: для індексації файлів поза мережею і для програмного додавання нових контрактів для індексації під час виконання, наприклад, проксі-смарт-контрактів або фабрик.

Смарт-контракти з проксі-шаблоном - ця архітектура смарт-контрактів складається з одного реалізованого смарт-контракту і, можливо, багатьох проксі-смарт-контрактів. Дізнайтеся більше про проксі-смарт-контракти, переглянувши відеоурок Patrick Collins та прочитавши документацію від OpenZeppelin.

Варіант використання File Data Sources

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

Давайте почнемо з прикладу використання. Чи не було б чудово зібрати всі записи на Lens Protocol, включно з іменами користувачів, які їх опублікували?

Використовуючи цей підграф ми могли б провести численні аналізи, такі як аналіз трендів, ідентифікація інфлюенсерів, рекомендація контенту тощо, використовуючи такі бібліотеки, як Playgrounds, або навіть створити дашборди без коду за допомогою DappLooker.

Підтвердження архітектури даних і специфікацій нашого підграфа

Перед тим, як розпочати розробку, нам потрібно переконатися, що існують як он-чейн, так і офф-чейн джерела даних, щоб запустити індексацію нашого підграфа File Data Sources.

Більшість NFT, включно з деякими публікаціями Lens Protocol V1, зберігають свій вміст та метадані в JSON-файлах поза мережею, тоді як їхній стан зберігається в мережі. Переконавшись, що Lens використовує IPFS і Arweave, а також має свій проксі-смарт-контракт і реалізаційні смарт-контракти на Polygon, ми готові перейти до створення характеристик нашого підграфа.

Ось дві основні операції, які буде виконувати наш підграф для належної індексації даних поза мережею:

Збір ідентифікаторів файлів з події в мережі

Ми зберемо ідентифікатори файлів з офф-чейн файлу події PostCreated. Ця подія визначена в реалізаційному смарт-контракті LensHub і генерується з проксі-смарт-контракту LensHub.
- Ми запустимо індексацію файлових джерел даних за цими ідентифікаторами файлів.

2. Індексація офф-чейн файлів з Arweave та IPFS за допомогою File Data Sources

Ми будемо збирати вміст публікації з JSON-файлу, збереженого на Arweave або IPFS, і зберігати метадані файлу в змінній PostContent в нашому підграфі.

Офф-чейн ідентифікатори файлів, які запускають File Data Sources

Arweave

Починаючи з версії 0.33.0, нода Graph може отримувати файли, що зберігаються на Arweave, на основі їх ідентифікатора транзакції від шлюзу Arweave (приклад файлу). Arweave підтримує транзакції, завантажені через Irys (раніше Bundlr), і нода Graph також може отримувати файли на основі маніфестів Irys.

IPFS

Нода Graph підтримує ідентифікатори вмісту (CID) версій v0 і v1, а також CID з такими каталогами, як Qm.../metadata.json.

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

Збір ідентифікаторів файлів з подій в мережі

Якби ми створювали власний смарт-контракт, то було б досить легко створити подію, що видає ідентифікатор файлу для File Data Sources. Оскільки ми не створюємо власний смарт-контракт, нам доведеться дослідити смарт-контракти Lens, щоб знайти подію, яка видає ідентифікатор файлу для нашого підграфа File Data Sources.

Давайте дослідимо реалізаційний смарт-контракт LensHub events.sol, щоб знайти подію, яка може містити ідентифікатор файлу, який ми можемо використати для запуску офф-чейн індексування File Data Sources.

Якщо ми подивимося на подію PostCreated, то побачимо, що вона видається кожного разу при створенні поста. Ми також бачимо, що вона має поле contentURI, яке може містити ідентифікатори файлів, які нам потрібні для запуску File Data Sources.

event PostCreated(
  uint256 indexed profileId,
  uint256 indexed pubId,
  string contentURI,
  address collectModule,
  bytes collectModuleReturnData,
  address referenceModule,
  bytes referenceModuleReturnData,
  uint256 timestamp
);

Давайте розгорнемо підграф, який індексує цю подію PostCreated і її поле contentURI, щоб перевірити, чи містить воно ідентифікатори файлів, які нам потрібні для запуску індексації File Data Sources. Після того, як ми переконуємося, що цей contentURI містить ідентифікатор потрібного нам файлу, ми можемо розширити цей підграф далі, щоб запустити індексацію цього файлу через File Data Sources.

Розгортання нашого підграфа для індексування події PostCreated

Розпочнемо з www.thegraph.com/studio і створимо новий підграф, який вибере Polygon в якості блокчейну для індексації, оскільки Polygon - це мережа, в якій розгорнуті смарт-контракти.

Використовуючи graph-cli, ініціюємо наш підграф за допомогою команди graph-init, яка знаходиться в правому нижньому куті Subgraph Studio.

Коли CLI попросить вказати адресу смарт-контракту, вказуємо адресу проксі-смарт-контракта LensHub (0xDb46d1Dc155634FbC732f92E853b10B288AD5a1d) і підтверджуємо, що ми хочемо індексувати події як джерела даних. Ми хочемо націлитися на проксі-смарт-контракт, оскільки це смарт-контракт, з яким взаємодіють учасники Lens, і він буде випускати події як від реалізаційного смарт-контракту, так і від проксі-смарт-контракту.

Якщо CLI запитає нас про стартовий блок і ABI, ми можемо перейти на https://miniscan.xyz/ і ввести адресу проксі-смарт-контракту, щоб отримати ці дані.

Після авторизації розгортайте підграф!

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

Перейдемо до вивчення цього питання:

Проблема №1: Індексація смарт-контракту з проксі шаблоном

Проксі-смарт-контракти генерують як свої події, так і події реалізації.

При створенні підграфа в graph-cli, CLI створює обробники подій і змінні за допомогою наданого ABI контракту. Цей ABI отримується з експлорера блоків, в якому розгорнуто смарт-контракт. Якщо CLI вказано на проксі-смарт-контракт, він отримає цю інформацію тільки з проксі, а не з його реалізації.

Це означає, що наш поточний підграф не знає про подію PostCreated реалізованого смарт-контракту! Йому потрібні ABI, обробники подій і змінній цієї події PostCreated**!**

Можливий варіант вирішення A: Надати CLI і проксі, і реалізаційні смарт-контракти

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

Коли CLI запитує “Додати ще один контракт?”, ми можемо відповісти “так”, і просто індексувати обидва смарт-контракти і бачити всі події, випущені обома смарт-контрактами.

На жаль, можливий варіант вирішення А може не працювати у специфічних рідкісних випадках! У рідкісних випадках ABI в експлорері блоків не відображає реальний стан смарт-контракту.

Якщо ми розглянемо код реалізаційного смарт-контракту Lens Protocol, то побачимо, що подія PostCreated міститься у файлі events.sol, однак її немає в ABI експлорера блоків.

Це означає, що використання CLI для отримання ABI реалізації не вирішить цю проблему, оскільки отриманий ABI не матиме важливих даних про подію PostCreated.

Давайте спробуємо інше рішення:

Можливий варіант вирішення B: Ручне створення запису ABI PostCreated

Давайте вручну створимо ABI реалізації так, щоб наш підграф правильно фіксував подію PostCreated.

Щоб отримати запис ABI, який відображає PostCreated належним чином, ми скомпілюємо events.sol в Remix (можна і будь-який інший фреймворк для смарт-контрактів), а потім скопіюємо і вставимо визначення події PostCreated в ABI нашого підграфа. Це має вирішити нашу проблему!

Розпочнемо з копіювання смарт-контракту events.sol з реалізаційного смарт-контракту LensHub і розмістимо його в папці contracts нової сесії Remix IDE .

Ви повинні побачити кілька рядків коду, що видає помилку. Ми можемо закоментувати ці рядки.

Причина, по якій ми можемо просто закоментувати ці частини, полягає в тому, що нам не потрібен весь файл для компіляції, лише подія PostCreated.

Перейдемо до компіляції events.sol:

Після компіляції знайдімо у папці artifacts ваш PostCreated ABI у Events.json:::

{
  "anonymous": false,
  "inputs": [
    {
      "indexed": true,
      "internalType": "uint256",
      "name": "profileId",
      "type": "uint256"
    },
    {
      "indexed": true,
      "internalType": "uint256",
      "name": "pubId",
      "type": "uint256"
    },
    {
      "indexed": false,
      "internalType": "string",
      "name": "contentURI",
      "type": "string"
    },
    {
      "indexed": false,
      "internalType": "address",
      "name": "collectModule",
      "type": "address"
    },
    {
      "indexed": false,
      "internalType": "bytes",
      "name": "collectModuleReturnData",
      "type": "bytes"
    },
    {
      "indexed": false,
      "internalType": "address",
      "name": "referenceModule",
      "type": "address"
    },
    {
      "indexed": false,
      "internalType": "bytes",
      "name": "referenceModuleReturnData",
      "type": "bytes"
    },
    {
      "indexed": false,
      "internalType": "uint256",
      "name": "timestamp",
      "type": "uint256"
    }
  ],
  "name": "PostCreated",
  "type": "event"
}

Отже, ось запис ABI, якого нам бракує!

Візьміть цей запис ABI, скопіюйте і вставте його в abi.json нашого підграфа. Тепер ABI нашого підграфа готовий, оскільки він може бачити подію PostCreated, що випускається реалізаційним смарт-контрактом, який проходить через проксі-смарт-контракт.

Проблема №1 вирішена!

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

Як ми пам'ятаємо, початковим наміром створення нашого підграфа було перевірити, чи зможемо ми знайти ідентифікатор файлу для запуску File Data Sources. Однак, оскільки нам довелося вручну генерувати наш ABI, ми зіткнулися з іншою цікавою проблемою, яку потрібно вирішити.

Проблема #2: Обробка події PostCreated

Тепер, коли наш підграф може бачити подію PostCreated, потрібно розширити його для обробки даних події PostCreated. Зазвичай CLI робить це автоматично, але оскільки нам довелося вручну оновлювати ABI, також слід вручну розширити наш підграф. Це буде хорошою вправою для вивчення того, як обробляються дані в підграфах.

Розв'язання: Розширення підграфа для індексації події PostCreated

Почнемо з нашого файлу subgraph.yaml, давайте додамо обробник події PostCreated, а також визначимо його змінну PostCreated:

specVersion: 0.0.5
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum
    name: Contract
    network: matic
    source:
      address: "0xDb46d1Dc155634FbC732f92E853b10B288AD5a1d"
      abi: Contract
      startBlock: 29735286
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.7
      language: wasm/assemblyscript
      entities:
        - PostCreated
      abis:
        - name: Contract
          file: ./abis/Contract.json
      eventHandlers:
        - event: PostCreated(indexed uint256,indexed uint256,string,address,bytes,address,bytes,uint256)
          handler: handlePostCreated
      file: ./src/contract.ts

Тепер перейдемо до schema.graphql.

Тут ми додамо змінну PostCreated, яку щойно визначили у файлі subgraph.yaml. Ми не будемо включати всі поля події PostCreated, оскільки нам не потрібні всі ці дані. Нам потрібно лише перевірити, чи містить поле contentURI ідентифікатор файлу, щоб запустити File Data Sources.

type PostCreated @entity(immutable: true) {
  id: Bytes!
  ownerId: BigInt!
  contentURI: String!
  timestamp: BigInt!
}

За допомогою маніфеста subgraph.yaml і schema.graphql готовими для обробки події PostCreated в мережі, ми можемо створити обробник handlePostCreated в нашому mappings.ts.

Перш ніж ми це зробимо, ми повинні запустити граф-код у нашому терміналі.

Порада*: кожного разу, коли ми змінюємо schema.graphql, ми повинні запускати граф-код, щоб оновити наші типи, оскільки ми імпортуємо ці автоматично згенеровані файли у верхній частині нашого *mappings.ts .

Прочитайте коментарі, щоб детальніше дізнатися про логіку нашого mappings.ts.

// Import the event helper code and rename to improve readability.
import { PostCreated as PostCreatedEvent } from "../generated/Contract/Contract";

// Import the types generated from the schema we created.
import { PostCreated } from "../generated/schema";

// Create a new entity with a unique ID. This unique ID is important,
// as it must be the same ID used in our `handlePostContent` handler built later
// in this tutorial.
export function handlePostCreated(event: PostCreatedEvent): void {
  let entity = new PostCreated(
    Bytes.fromUTF8(
      event.params.profileId.toString() + "-" + event.params.pubId.toString(),
    ),
  );

  // Send the `contentURI` emitted as an event parameter into our defined entity.
  // When this subgraph is deployed and indexing this property, we will look through
  // `contentURI` to see if we can find some IDs.
  entity.contentURI = event.params.contentURI;

  // Assign other parameters emitted from the event that might be helpful when
  // filtering.
  entity.ownerId = event.params.profileId;
  entity.timestamp = event.params.timestamp;

  entity.save();
}

Ми оновили наші файли subgraph.yaml, schema.graphql та mappings.ts, щоб правильно відобразити наш оновлений ABI.

Проблему №2 вирішено!

Ми зіткнулися з двома проблемами і вирішили їх! Тепер настав час повторно розгорнути наш підграф.

Поверніться до Subgraph Studio і запустіть команду graph-deploy для повторного розгортання.

Після розгортання запустіть ці два запити на Playground вашого підграфа, щоб побачити різні URI, які передаються через contentURI:

Приклад запиту і відповіді Arweave

{
  postCreateds(where: {contentURI_contains: "arweave"}, first: 1) {
    id
    contentURI
  }
}

{
  "data": {
    "postCreateds": [
      {
        "id": "0x312d313030",
        "contentURI": "https://arweave.net/UjlOEosUyYqZ8oWlTi879YRTg9xyd5gUtKQ2zMSHQEg"
      }
    ]
  }
}

Приклад запиту і відповіді IPFS

{
  postCreateds(where: { contentURI_contains: "ipfs" }, first: 1) {
    id
    contentURI
  }
}

{
  "data": {
    "postCreateds": [
      {
        "id": "0x312d31",
        "contentURI": "https://ipfs.infura.io/ipfs/QmR7baNsHXNXEThcZNSw1SpRu1ZvKjaCnakEemT94Ur9Pn"
      }
    ]
  }
}

Ми знайшли ідентифікатори файлів у цих URI!

Приклад ідентифікатора файлу Arweave: s9qinED7mYvrNrYTEbRlNb60bVT754LkVpQoW7Ffi24
Приклад ідентифікатора файлу IPFS: QmTWJEzcxxcPjnB8Xj8S4EUJ7RxHGkfcDfMZyYRcQz7eYN

Переходимо до другої специфікації нашого підграфа: індексація цих офф-чейн файлів з Arweave і IPFS за допомогою File Data Sources.

Індексація офф-чейн файлів з Arweave та IPFS за допомогою File Data Sources

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

Почнемо цей процес зі створення двох шаблонів підграфів для даних Arweave та IPFS:

Специфікація шаблонів File Data Sources

Ми створимо два шаблони. Один шаблон для Arweave, інший для IPFS. Кожен шаблон буде:

мати унікальну назву.
називати змінну PostContent як сутність, що отримуватиме дані з Arweave та IPFS.
називати обробник handlePostContent як обробник для даних Arweave та IPFS, який передаватиме дані змінної PostContent.
підтримувати поділ даних в мережі та поза мережею. Детальніше про поділ даних та інші обмеження File Data Sources можна прочитати тут.

Додавання двох шаблонів до subgraph.yaml

Ми додамо шаблони ArweaveContent і IpfsContent під проксі-смарт-контрактом, який ми вже індексуємо:

specVersion: 0.0.5
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum
    name: Contract
    network: matic
    source:
      address: "0xDb46d1Dc155634FbC732f92E853b10B288AD5a1d"
      abi: Contract
      startBlock: 29735286
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.7
      language: wasm/assemblyscript
      entities:
        - PostCreated
      abis:
        - name: Contract
          file: ./abis/Contract.json
      eventHandlers:
        - event: PostCreated(indexed uint256,indexed uint256,string,address,bytes,address,bytes,uint256)
          handler: handlePostCreated
      file: ./src/contract.ts
templates:
  - kind: file/arweave
    name: ArweaveContent
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.7
      language: wasm/assemblyscript
      entities:
        - PostContent
      abis:
        - name: Contract
          file: ./abis/Contract.json
      handler: handlePostContent
      file: ./src/contract.ts
  - kind: file/ipfs
    name: IpfsContent
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.7
      language: wasm/assemblyscript
      entities:
        - PostContent
      abis:
        - name: Contract
          file: ./abis/Contract.json
      handler: handlePostContent
      file: ./src/contract.ts

Розширення нашого підграфа для відображення нових шаблонів

Наші шаблони посилаються на сутність PostContent і обробник handlePostContent. Давайте розширимо наш підграф, щоб відобразити ці зміни. Ми:

Створимо PostContent в schema.graphql

Це місце, де будуть зберігатися офф-чейн дані.

Оновимо handlePostCreated в mappings.ts

Сюди ми передамо ідентифікатори файлів, зібрані з мережевої події, у шаблон, використовуючи DataSourceTemplate.createWithContext().

Створимо handlePostContent у mappings.ts

Після того, як File Data Sources спрацював, нам потрібно передати ці дані в змінну PostContent, яку ми раніше створили в schema.graphql .

Давайте приступимо до роботи!

Створення змінної PostContent у schema.graphql

Ця змінна буде зберігати вміст та ідентифікатор файлу, який запустив індексування File Data Source з файлів Arweave та IPFS.

type PostCreated @entity(immutable: true) {
  id: Bytes!
  ownerId: BigInt!
  contentURI: String!
  timestamp: BigInt!
}

type PostContent @entity(immutable: true) {
  id: Bytes!
  hash: String!
  content: String!
}

Зверніть увагу: ідентифікатор змінної є ідентифікатором самої змінної, а не офф-чейн файлу. Ідентифікатор офф-чейн файлу буде зберігатися як хеш.

Порада*: Кожного разу, коли ми створюємо змінну, яка є журналом подій, що містить мережеві або офф-чейн дані, без змін у mappings.ts, найкраще включити (immutable: true), як показано у фрагменті нижче, оскільки це значно пришвидшує індексацію. Читайте цей запис у блозі David Lutterkort, щоб дізнатися більше про незмінні змінні та їхні переваги для продуктивності, .*

Тепер у нашому subgraph.yaml є готові шаблони File Data Source, а наш schema.graphql готовий приймати дані як з мережевих, так і з офф-чейн джерел.

Перейдемо до розширення наших обробників в mappings.ts .

Оновлення handlePostCreated в mappings.ts

Заради цього туторіала, ми залишимо його простим, просто зібравши певні ідентифікатори з однієї визначеної структури URI для Arweave і IPFS. Просто знайте, що якби ми хотіли зібрати всі файли Arweave і IPFS, довелося б розробити більше стратегій для збору всіх різних повернених URI.

Читайте коментарі, щоб отримати покрокове пояснення.

// POST_ID_KEY will be used as the key for a key-value pair passed into the
// `context` argument in the createWithContext(name: string, params: string[], context: DataSourceContext)
const POST_ID_KEY = "postID";

export function handlePostCreated(event: PostCreatedEvent): void {
  let entity = new PostCreated(
    Bytes.fromUTF8(
      event.params.profileId.toString() +
      "-" +
      event.params.pubId.toString()
    )
  );

  entity.ownerId = event.params.profileId;
  entity.contentURI = event.params.contentURI;
  entity.timestamp = event.params.timestamp;

  entity.save();

  // EXTRACT THE ID FROM OUR ENTITY
  // Find the index of where "arweave.net" or "/ipfs/" is within the contentURI.
  // This is a relatively naive way of finding whether the content is from
  // Arweave or IPFS. Feel free to extend this further to capture all the various
  // ways that IDs present in the Arweave and IPFS URIs.
  let arweaveIndex = entity.contentURI.indexOf("arweave.net/");
  let ipfsIndex = entity.contentURI.indexOf("/ipfs/");

  // If both arweave and ipfsIndex return -1, which means the strings were not found.
  // At that point, there's nothing else to do, so the function ends.
  if (arweaveIndex == -1 && ipfsIndex == -1) return;

  // PREPARE `CONTEXT` - PASS IN OUR ID
  // DataSourceContext() is passed in a key,value pair that is converted into Bytes
  // to be passed into other handlers. The key was defined outside this function as
  // POST_ID_KEY and the value is the entity.id. This allows consistency between
  // handlers as the data is being indexed.
  let context = new DataSourceContext();
  context.setBytes(POST_ID_KEY, entity.id);

  // If Arweave data or IPFS data is found in the URI, the data hash is extracted
  // from contentURI. We now have the three variables we need! Pass them into
  // .createWithContext() to trigger File Data Sources indexing!
  if (arweaveIndex != -1) {
    let hash = entity.contentURI.substr(arweaveIndex + 12);
    DataSourceTemplate.createWithContext("ArweaveContent", [hash], context);

    return;
  }

  if (ipfsIndex != -1) {
    let hash = entity.contentURI.substr(ipfsIndex + 6);
    DataSourceTemplate.createWithContext("IpfsContent", [hash], context);
  }
}

Тепер, коли ми запустили наші шаблони, вони шукають обробник handlePostContent, який буде обробляти отримані від них офф-чейн дані.

Створіть handlePostContent у файлі mappings.ts

export function handlePostContent(content: Bytes): void {
  // Remember DataSourceTemplate.createWithContext()? We can access
  // everything we just passed into that method here!
  // Gather the `hash` aka the ID with dataSource.stringParam()
  // Gather the `context` that has our ID encoded as Bytes as dataSource.context(),
  // then decode it.
  let hash = dataSource.stringParam();
  let context = dataSource.context();
  let id = context.getBytes(POST_ID_KEY);

  // We pass in the same ID used in the previous `PostCreated` handler here to
  // link the on-chain PostCreated ID with the off-chain PostContent id.
  let post = new PostContent(id);

  post.hash = hash;
  post.content = content.toString();

  post.save();
}

Перейдіть до розгортання підграфа, щоб почати індексацію за допомогою File Data Sources!

Надішліть цей запит через Playground від Subgraph Studio, щоб переконатися, чи отримуємо ми дані з Arweave та IPFS.

{
  postCreateds(first: 100) {
    id
    contentURI
  }
  postContents(first: 100) {
    id
    hash
    content
  }
}

Тепер ми індексуємо за допомогою File Data Sources!

Ось наш підграф File Data Sources, опублікований в мережі The Graph, а також фінальна версія репозиторію.

Звідси ми можемо зробити ще так багато речей!

Розширюйте підграф далі, щоб розбирати дані JSON і заповнювати змінні. Погляньте, як це можна зробити у цьому прикладі.
Що, якщо ми захочемо створити децентралізований додаток з цими даними? Можна підключити цей підграф до ScaffoldEth і продовжити розробку!
Використовуйте python для запиту цього підграфа за допомогою Playgrounds і аналізу даних.
Створюйте дашборди без коду за допомогою DappLooker.
Запускайте індексацію File Data Sources іншого офф-чейн файлу з іншого офф-чейн обробника. Ознайомтеся з цією функцією.

Дякую, що приєдналися до мене в цій подорожі по індексації за допомогою File Data Sources. Я з нетерпінням чекаю на ваші розробки!

Marcus Rein

Developer Relations and Success

Edge & Node - працює на The Graph

smth0x

smth0x

No comments yet

smth0x

smth0x

No comments yet

Туторіал по файловим джерелам даних: Використання підграфів для індексації офф-чейн даних

Туторіал по файловим джерелам даних: Використання підграфів для індексації офф-чейн даних

No comments yet

No comments yet