उन्नत Subgraph विशेषताएँ

Overview

अपने Subgraph के निर्माण को उन्नत करने के लिए उन्नत सबग्राफ सुविधाएँ जोड़ें और लागू करें।

specVersion 0.0.4 से शुरू होकर, सबग्राफ सुविधाओं को स्पष्ट रूप से विशेषता अनुभाग में शीर्ष स्तर पर घोषित किया जाना चाहिए, जो उनके camelCase नाम का उपयोग करके किया जाता है, जैसा कि नीचे दी गई तालिका में सूचीबद्ध है:

instance के लिए, यदि कोई सबग्राफ Full-Text Search और Non-fatal Errors सुविधाओं का उपयोग करता है, तो मैनिफेस्ट में विशेषता फ़ील्ड इस प्रकार होनी चाहिए:

1specVersion: 1.3.02description: Gravatar for Ethereum3features:4  - fullTextSearch5  - nonFatalErrors6dataSources: ...

Timeseries और Aggregations

पूर्व आवश्यकताएँ:

• सबग्राफ का specVersion ≥1.1.0 होना चाहिए।

Timeseries और aggregations आपके Subgraph को दैनिक औसत मूल्य, प्रति घंटे कुल ट्रांसफर और अन्य आँकड़े ट्रैक करने में सक्षम बनाते हैं।

यह सुविधा दो नए प्रकार की सबग्राफ entity पेश करती है। Timeseries entities समय मुहर (timestamps) के साथ डेटा पॉइंट्स रिकॉर्ड करती हैं। Aggregation entities पहले से घोषित गणनाएँ करती हैं, जो Timeseries डेटा पॉइंट्स पर प्रति घंटे या दैनिक आधार पर की जाती हैं, फिर परिणामों को आसान पहुंच के लिए GraphQL के माध्यम से संग्रहीत किया जाता है।

उदाहरण स्कीमा

1type Data @entity(timeseries: true) {2  id: Int8!3  timestamp: Timestamp!4  price: BigDecimal!5}67type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {8  id: Int8!9  timestamp: Timestamp!10  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")11}

टाइमसीरीज़ और एग्रीगेशन को कैसे परिभाषित करें

टाइमसीरीज़ entities GraphQL स्कीमा में @entity(timeseries: true) के साथ परिभाषित की जाती हैं। हर टाइमसीरीज़ entities को अवश्य:

• एक अद्वितीय आईडी हो जो int8 प्रकार की हो।
• टाइमस्टैम्प प्रकार का एक टाइमस्टैम्प रखें।
• गणना के लिए अभिग्रहण entities द्वारा उपयोग किए जाने वाले डेटा को शामिल करें।

इन टाइमसीरीज़ entities को नियमित ट्रिगर handler में सेव किया जा सकता है और ये एग्रीगेशन entities के लिए “कच्चे डेटा” के रूप में कार्य करती हैं।

एग्रीगेशन entities को GraphQL schema में @aggregation के साथ परिभाषित किया जाता है। प्रत्येक aggregation entity उस साधन को परिभाषित करती है जिससे वह डेटा एकत्र करेगी (जो कि एक timeseries entity होनी चाहिए), अंतराल सेट करती है (जैसे, घंटे, दिन), और उस aggregation function को निर्दिष्ट करती है जिसका वह उपयोग करेगी (जैसे, sum, count, min, max, first, last)।

एग्रीगेशन entities निर्दिष्ट साधन के आधार पर आवश्यक अंतराल के अंत में स्वचालित रूप से गणना की जाती हैं।

उपलब्ध Aggregation अंतराल

• hour: हर घंटे, ठीक घंटे पर, टाइमसीरीज़ अवधि सेट करता है।
• day: टाइमसीरीज़ अवधि को हर दिन सेट करता है, जो 00:00 पर शुरू और समाप्त होती है।

उपलब्ध Aggregation फ़ंक्शन

• sum: सभी मानों का कुल योग।
• count: मानों की संख्या।
• min: न्यूनतम मान।
• max: अधिकतम मान।
• first: अवधि में पहला मान।
• last: अवधि में अंतिम मान।

उदाहरण Aggregations queries

1{2  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {3    id4    timestamp5    sum6  }7}

और पढ़ें⁠ समय श्रृंखला और संक्षेपण के बारे में।

गैर-घातक त्रुटियाँ

indexing त्रुटियाँ, जो पहले से सिंक हो चुके सबग्राफ पर होती हैं, डिफ़ॉल्ट रूप से सबग्राफ को विफल कर देंगी और सिंकिंग रोक देंगी। वैकल्पिक रूप से, सबग्राफ को इस तरह कॉन्फ़िगर किया जा सकता है कि वे त्रुटियों की उपस्थिति में भी सिंकिंग जारी रखें, उन परिवर्तनों को अनदेखा करके जो उस handler द्वारा किए गए थे जिसने त्रुटि उत्पन्न की। यह सबग्राफ लेखकों को अपने सबग्राफ को सही करने का समय देता है, जबकि नवीनतम ब्लॉक के विरुद्ध क्वेरीज़ दी जाती रहती हैं, हालांकि परिणाम उस बग के कारण असंगत हो सकते हैं जिसने त्रुटि उत्पन्न की थी। ध्यान दें कि कुछ त्रुटियाँ फिर भी हमेशा घातक होती हैं। गैर-घातक होने के लिए, त्रुटि को निर्धारक (deterministic) रूप से ज्ञात होना चाहिए।

सबग्राफ मैनिफेस्ट पर निम्नलिखित फीचर फ्लैग सेट करके नॉन-फैटल एरर सक्षम किया जा सकता है

1specVersion: 1.3.02description: Gravatar for Ethereum3features:4    - nonFatalErrors5    ...

क्वेरी को subgraphError आर्ग्यूमेंट के माध्यम से संभावित असंगतियों वाले डेटा को क्वेरी करने के लिए भी ऑप्ट-इन करना आवश्यक है। साथ ही, यह अनुशंसित है कि _meta को क्वेरी किया जाए ताकि यह जांचा जा सके कि सबग्राफ ने किसी त्रुटि को छोड़ दिया है या नहीं, जैसा कि निम्न उदाहरण में दिखाया गया है:

1foos(first: 100, subgraphError: allow) {2  id3}45_meta {6  hasIndexingErrors7}

यदि सबग्राफ को कोई त्रुटि मिलती है, तो वह क्वेरी डेटा के साथ एक GraphQL त्रुटि वापस करेगी, जिसमें संदेश “indexing_error” होगा, जैसा कि इस उदाहरण प्रतिक्रिया में है:

1"data": {2    "foos": [3        {4          "id": "0xdead"5        }6    ],7    "_meta": {8        "hasIndexingErrors": true9    }10},11"errors": [12    {13        "message": "indexing_error"14    }15]

IPFS/Arweave फ़ाइल डेटा स्रोत

फाइल डेटा स्रोत एक नया सबग्राफ कार्यक्षमता है जो इंडेक्सिंग के दौरान ऑफ-चेन डेटा तक पहुँचने के लिए एक मजबूत और विस्तारित तरीका प्रदान करता है। फाइल डेटा स्रोत IPFS और Arweave से फ़ाइलें प्राप्त करने का समर्थन करता है।

Overview

“लाइन” में हैंडलर कार्यान्वयन के दौरान फ़ाइलों को लाने के बजाय, यह टेम्पलेट्स को पेश करता है जिन्हें एक दिए गए फ़ाइल पहचानकर्ता के लिए नए डेटा स्रोतों के रूप में उत्पन्न किया जा सकता है। ये नए डेटा स्रोत फ़ाइलों को लाते हैं, यदि वे असफल होते हैं तो पुनः प्रयास करते हैं, और जब फ़ाइल मिलती है तो एक समर्पित हैंडलर चलाते हैं।

यह existing data साधन templates के समान है, जिन्हें नए chain-based data साधन को डायनामिक रूप से बनाने के लिए उपयोग किया जाता है।

अपग्रेड गाइड

graph-ts और graph-cli को अपडेट करें

फ़ाइल डेटा साधन के लिए graph-ts >=0.29.0 और graph-cli >=0.33.1 की आवश्यकता होती है।

एक नया इकाई प्रकार जोड़ें जो फ़ाइलें मिलने पर अपडेट किया जाएगा

फ़ाइल डेटा स्रोत श्रृंखला-आधारित संस्थाओं तक पहुँच या अद्यतन नहीं कर सकते हैं, लेकिन फ़ाइल विशिष्ट संस्थाओं को अद्यतन करना चाहिए।

इसका मतलब हो सकता है कि फ़ील्ड को मौजूदा इकाइयों से अलग-अलग इकाइयों में विभाजित करना, एक साथ जुड़े हुए।

मूल संयुक्त इकाई:

1type Token @entity {2  id: ID!3  tokenID: BigInt!4  tokenURI: String!5  externalURL: String!6  ipfsURI: String!7  image: String!8  name: String!9  description: String!10  type: String!11  updatedAtTimestamp: BigInt12  owner: User!13}

नई, विभाजित इकाई:

1type Token @entity {2  id: ID!3  tokenID: BigInt!4  tokenURI: String!5  ipfsURI: TokenMetadata6  updatedAtTimestamp: BigInt7  owner: String!8}910type TokenMetadata @entity {11  id: ID!12  image: String!13  externalURL: String!14  name: String!15  description: String!16}

यदि पैरेंट इकाई और परिणामी फ़ाइल डेटा स्रोत इकाई के बीच संबंध 1:1 है, तो सबसे सरल पैटर्न मूल इकाई को लुकअप के रूप में IPFS CID का उपयोग करके परिणामी फ़ाइल इकाई से लिंक करना है। यदि आपको अपनी नई फ़ाइल-आधारित संस्थाओं को मॉडलिंग करने में कठिनाई हो रही है, तो डिस्कॉर्ड पर संपर्क करें!

एक नया टेम्पलेटेड डेटा साधन स्रोत जोड़ें जिसमें kind: file/ipfs या kind: file/arweave हो।

यह वह डेटा स्रोत है जो ब्याज की फ़ाइल की पहचान होने पर उत्पन्न होगा।

1templates:2  - name: TokenMetadata3    kind: file/ipfs4    mapping:5      apiVersion: 0.0.96      language: wasm/assemblyscript7      file: ./src/mapping.ts8      handler: handleMetadata9      entities:10        - TokenMetadata11      abis:12        - name: Token13          file: ./abis/Token.json

फाइल डेटा साधन को विशेष रूप से उन सभी entities प्रकारों का उल्लेख करना चाहिए जिनके साथ यह entities. के तहत इंटरएक्ट करेगा। अधिक विवरण के लिए [ limitations] (#limitations) देखें।

फ़ाइलों को संसाधित करने के लिए एक नया हैंडलर बनाएँ

यह handler एक Bytes पैरामीटर स्वीकार करना चाहिए, जो उस फ़ाइल की सामग्री होगी, जब यह पाई जाएगी, जिसे फिर से प्रोसेस किया जा सकेगा। यह अक्सर एक JSON फ़ाइल होगी, जिसे graph-ts हेल्पर्स के साथ प्रोसेस किया जा सकता है (documentation).

फ़ाइल का CID एक पठनीय स्ट्रिंग के रूप में dataSource के माध्यम से निम्नलिखित तरीके से प्राप्त किया जा सकता है:

1const cid = dataSource.stringParam()

उदाहरण हैंडलर:

1import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'2import { TokenMetadata } from '../generated/schema'34export function handleMetadata(content: Bytes): void {5  let tokenMetadata = new TokenMetadata(dataSource.stringParam())6  const value = json.fromBytes(content).toObject()7  if (value) {8    const image = value.get('image')9    const name = value.get('name')10    const description = value.get('description')11    const externalURL = value.get('external_url')1213    if (name && image && description && externalURL) {14      tokenMetadata.name = name.toString()15      tokenMetadata.image = image.toString()16      tokenMetadata.externalURL = externalURL.toString()17      tokenMetadata.description = description.toString()18    }1920    tokenMetadata.save()21  }22}

आवश्यक होने पर फ़ाइल डेटा स्रोत स्पॉन करें

अब आप चेन-आधारित हैंडलर के निष्पादन के दौरान फ़ाइल डेटा स्रोत बना सकते हैं:

• ऑटो-जनरेटेड templates से टेम्पलेट आयात करें।
• मानचित्रण के भीतर TemplateName.create(cid: string) को कॉल करें, जहाँ cid एक वैध कंटेंट पहचानकर्ता है IPFS या Arweave के लिए।

IPFS के लिए, ग्राफ-नोड [v0 और v1 कंटेंट आइडेंटिफायर्स] का समर्थन करता है(https://docs.ipfs.tech/concepts/content-addressing/⁠), और डायरेक्ट्रीज़ के साथ कंटेंट आइडेंटिफायर्स (जैसे bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json)।

Arweave के लिए, संस्करण 0.33.0 के अनुसार, ग्राफ-नोड Arweave गेटवे से उनके [ लेन-देन(transaction) ID] (https://docs.arweave.org/developers/arweave-node-server/http-api#transactions⁠) के आधार पर संग्रहित फ़ाइलों को प्राप्त कर सकता है (उदाहरण फ़ाइल⁠). Arweave उन लेन-देन(transaction) का समर्थन करता है जो Irys (पूर्व में Bundlr) के माध्यम से अपलोड की गई हैं, और ग्राफ-नोड Irys manifests⁠के आधार पर भी फ़ाइलों को प्राप्त कर सकता है।

उदाहरण:

1import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'23const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'4//This example code is for a Crypto coven Subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.56export function handleTransfer(event: TransferEvent): void {7  let token = Token.load(event.params.tokenId.toString())8  if (!token) {9    token = new Token(event.params.tokenId.toString())10    token.tokenID = event.params.tokenId1112    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'13    const tokenIpfsHash = ipfshash + token.tokenURI14    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"1516    token.ipfsURI = tokenIpfsHash1718    TokenMetadataTemplate.create(tokenIpfsHash)19  }2021  token.updatedAtTimestamp = event.block.timestamp22  token.owner = event.params.to.toHexString()23  token.save()24}

यह एक नया file data source बनाएगा, जो Graph Node के configured किए गए IPFS या Arweave endpoint का सर्वेक्षण करेगा, यदि यह नहीं मिलता है तो पुनः प्रयास करेगा। जब file मिल जाती है, तो file data source handler execute किया जाएगा।

यह उदाहरण पेरेंट टोकन entities और परिणामी TokenMetadata entities के बीच लुकअप के रूप में CID का उपयोग कर रहा है।

बधाई हो, आप फ़ाइल डेटा स्रोतों का उपयोग कर रहे हैं!

अपने सबग्राफ को परिनियोजित करना

आप अब अपने सबग्राफ को किसी भी ग्राफ-नोड >=v0.30.0-rc.0 पर build और deploy कर सकते हैं।

परिसीमन

फ़ाइल डेटा स्रोत handlers और entities अन्य सबग्राफ entities से अलग होते हैं, जिससे यह सुनिश्चित होता है कि वे निष्पादन के समय निर्धारक (deterministic) बने रहें और चेन-आधारित डेटा स्रोतों में कोई मिलावट न हो। विशेष रूप से:

• फ़ाइल डेटा स्रोतों द्वारा बनाई गई इकाइयाँ अपरिवर्तनीय हैं, और इन्हें अद्यतन नहीं किया जा सकता है
• फ़ाइल डेटा स्रोत हैंडलर अन्य फ़ाइल डेटा स्रोतों से संस्थाओं तक नहीं पहुँच सकते
• फ़ाइल डेटा स्रोतों से जुड़ी संस्थाओं को चेन-आधारित हैंडलर द्वारा एक्सेस नहीं किया जा सकता है

इसके अतिरिक्त, फ़ाइल डेटा स्रोत से डेटा स्रोत बनाना संभव नहीं है, चाहे वह ऑनचेन डेटा स्रोत हो या अन्य फ़ाइल डेटा स्रोत। भविष्य में यह प्रतिबंध हटाया जा सकता है।

सर्वोत्तम प्रथाएं

यदि आप NFT मेटाडेटा को संबंधित टोकन से लिंक कर रहे हैं, तो टोकन इकाई से मेटाडेटा इकाई को संदर्भित करने के लिए मेटाडेटा के IPFS हैश का उपयोग करें। एक आईडी के रूप में IPFS हैश का उपयोग करके मेटाडेटा इकाई को सहेजें।

आप DataSource context का उपयोग कर सकते हैं जब आप File Data साधन बना रहे हों ताकि अतिरिक्त जानकारी पास की जा सके जो File Data साधन handler में उपलब्ध होगी।

यदि आपके पास ऐसी entities हैं जो कई बार रिफ्रेश होती हैं, तो IPFS हैश और entity ID का उपयोग करके unique file-based entities बनाएं, और उन्हें chain-based entity में एक derived field का उपयोग करके संदर्भित करें। entities

ज्ञात समस्याएँ

फ़ाइल डेटा साधन को वर्तमान में ABIs, की आवश्यकता होती है, हालांकि ABIs का उपयोग नहीं किया जाता है ([issue])(https://github.com/graphprotocol/graph-cli/issues/961)।⁠ इसका समाधान यह है कि कोई भी ABI जोड़ें।

फ़ाइल डेटा साधन लिए handler उन फ़ाइलों में नहीं हो सकते जो eth_callcontract बाइंडिंग्स को आयात करती हैं, जिससे “unknown import:ethereum::ethereum.call has not been defined” त्रुटि होती है (issue⁠. वर्कअराउंड के रूप में फ़ाइल डेटा साधन handler को एक समर्पित फ़ाइल में बनाना चाहिए।

उदाहरण

Crypto Coven सबग्राफ migration⁠

संदर्भ

[GIP File Data साधन ] (https://forum.thegraph.com/t/gip-file-data-sources/2721⁠)

सूचीकृत तर्क फ़िल्टर / विषय फ़िल्टर

Topic filters, जिन्हें indexed argument filters के रूप में भी जाना जाता है, सबग्राफ में एक शक्तिशाली विशेषता हैं जो उपयोगकर्ताओं को उनके indexed arguments के मूल्यों के आधार पर ब्लॉकचेन घटनाओं को सटीक रूप से फ़िल्टर करने की अनुमति देती हैं।

• ये फ़िल्टर ब्लॉकचेन पर बड़ी संख्या में घटनाओं की धाराओं से विशिष्ट घटनाओं को अलग करने में मदद करते हैं, जिससे सबग्राफ अधिक कुशलता से काम कर सकते हैं और केवल प्रासंगिक डेटा पर ध्यान केंद्रित कर सकते हैं।

• यह विशिष्ट पतों और उनके विभिन्न स्मार्ट contract के साथ इंटरैक्शन को ट्रैक करने वाले व्यक्तिगत सबग्राफ बनाने के लिए उपयोगी है।

शीर्षक फ़िल्टर कैसे काम करते हैं

जब कोई स्मार्ट contract कोई इवेंट एमिट करता है, तो कोई भी आर्ग्यूमेंट जो indexed के रूप में चिह्नित होता है, उसे एक सबग्राफ के मैनिफेस्ट में फ़िल्टर के रूप में उपयोग किया जा सकता है। यह सबग्राफ को उन इवेंट्स को चयनित रूप से सुनने की अनुमति देता है जो इन indexed आर्ग्यूमेंट्स से मेल खाते हैं।

• इस आयोजन का पहला इंडेक्स किया गया तर्क topic1, से संबंधित है, दूसरा topic2, से और इसी तरह, topic3, तक, क्योंकि Ethereum Virtual Machine (EVM) प्रत्येक आयोजन में तीन तक इंडेक्स किए गए तर्कों की अनुमति देता है

1// SPDX-License-Identifier: MIT2pragma solidity ^0.8.0;34contract Token {5    // ईवेंट की घोषणा जिसमें पते के लिए इंडेक्स्ड पैरामीटर हैं6    event Transfer(address indexed from, address indexed to, uint256 value);78    // टोकन ट्रांसफर करने की क्रिया को सिमुलेट करने के लिए फ़ंक्शन9    function transfer(address to, uint256 value) public {10        // from, to, और value के साथ Transfer ईवेंट को उत्सर्जित करना11        emit Transfer(msg.sender, to, value);12    }13}

इस उदाहरण में:

• Transferआयोजन घटना का उपयोग पते के बीच टोकन log लेन-देन को लॉग करने के लिए किया जाता है।
• The from और to पैरामीटर सूचकांकित होते हैं, जिससे आयोजन लिस्नर्स को विशिष्ट पतों से जुड़ी ट्रांसफर को फ़िल्टर और मॉनिटर करने की अनुमति मिलती है।
• transfer फ़ंक्शन एक साधारण प्रतिनिधित्व है एक टोकन ट्रांसफर क्रिया का, जो हर बार इसे कॉल किए जाने पर Transfer आयोजन को उत्पन्न करता है।

सबस्पष्ट में कॉन्फ़िगरेशन

टॉपिक फ़िल्टर्स को सीधे इवेंट हैंडलर कॉन्फ़िगरेशन के भीतर सबग्राफ मैनिफेस्ट में परिभाषित किया जाता है। इन्हें इस प्रकार कॉन्फ़िगर किया जाता है:

1eventHandlers:2  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)3    handler: handleSomeEvent4    topic1: ['0xValue1', '0xValue2']5    topic2: ['0xAddress1', '0xAddress2']6    topic3: ['0xValue3']

इस सेटअप में:

• topic1 इवेंट के पहले आयोजन किए गए तर्क के अनुरूप है, topic2 दूसरे के अनुरूप है, और topic3 तीसरे के अनुरूप है।
• प्रत्येक विषय में एक या अधिक मान हो सकते हैं, और एक घटना केवल तभी प्रोसेस की जाती है जब वह प्रत्येक निर्दिष्ट विषय में से किसी एक मान से मेल खाती है।

फ़िल्टर लॉजिक

• एकल विषय के भीतर: लॉजिक एक OR स्थिति के रूप में कार्य करता है। यदि यह किसी दिए गए विषय में सूचीबद्ध मूल्यों में से किसी एक के साथ मेल खाता है, तो इवेंट को प्रोसेस किया जाएगा।
• विभिन्न विषयों के बीच: लॉजिक एक AND स्थिति के रूप में कार्य करता है। एक घटना को संबंधित हैंडलर को ट्रिगर करने के लिए विभिन्न विषयों में सभी निर्दिष्ट शर्तों को संतोषजनक रूप से पूरा करना चाहिए।

उदाहरण 1: ‘पता A’ से ‘पता B’ के लिए प्रत्यक्ष स्थानांतरण का ट्रैकिंग

1eventHandlers:2  - event: Transfer(indexed address,indexed address,uint256)3    handler: handleDirectedTransfer4    topic1: ['0xAddressA'] # Sender Address5    topic2: ['0xAddressB'] # Receiver Address

इस कॉन्फ़िगरेशन में:

• topic1 को Transfer आयोजन को फ़िल्टर करने के लिए कॉन्फ़िगर किया गया है जहाँ 0xAddressA भेजने वाला है।
• topic2 को इस प्रकार से कॉन्फ़िगर किया गया है कि यह Transferआयोजन घटनाओं को फिल्टर करता है जहां 0xAddressB रिसीवर है।
• सबग्राफ केवल उन्हीं लेन-देन को इंडेक्स करेगा जो सीधे 0xAddressA से 0xAddressB तक होते हैं।

उदाहरण 2: दो या अधिक ‘पते’ के बीच किसी भी दिशा में लेन-देन को ट्रैक करना

1eventHandlers:2  - event: Transfer(indexed address,indexed address,uint256)3    handler: handleTransferToOrFrom4    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # प्रेषक पता5    topic2: ['0xAddressB', '0xAddressC'] # प्राप्तकर्ता पता

इस कॉन्फ़िगरेशन में:

• topic1 को Transferआयोजन को फिल्टर करने के लिए कॉन्फ़िगर किया गया है जहाँ 0xAddressA, 0xAddressB, 0xAddressC प्रेषक हैं।
• topic2 को Transfer आयोजन को फिल्टर करने के लिए कॉन्फ़िगर किया गया है, जहाँ 0xAddressB और 0xAddressC रिसीवर हैं।
• सबग्राफ उन सभी पतों के बीच दोनों दिशाओं में होने वाले लेन-देन को अनुक्रमित करेगा, जिससे सभी पतों के बीच होने वाली अंतःक्रियाओं की व्यापक निगरानी संभव हो सकेगी।

घोषित eth_call

Declarative eth_calls एक मूल्यवान सबग्राफ विशेषता है जो eth_calls को पहले से निष्पादित करने की अनुमति देती है, जिससे graph-node उन्हें समानांतर रूप से निष्पादित कर सकता है।

यह फ़ीचर निम्नलिखित कार्य करता है:

• यह Ethereum ब्लॉकचेन से डेटा प्राप्त करने के प्रदर्शन में महत्वपूर्ण सुधार करता है, जिससे कई कॉल के लिए कुल समय कम हो जाता है और सबग्राफ की समग्र दक्षता में वृद्धि होती है।
• यह तेजी से डेटा फ़ेचिंग की अनुमति देता है, जिससे तेजी से क्वेरी प्रतिक्रियाएँ और बेहतर उपयोगकर्ता अनुभव मिलता है।
• कई Ethereum कॉल्स से डेटा को एकत्रित करने की आवश्यकता वाली अनुप्रयोगों के लिए प्रतीक्षा समय को कम करता है, जिससे डेटा पुनर्प्राप्ति प्रक्रिया अधिक प्रभावी हो जाती है।

मुख्य अवधारणाएँ

• घोषणात्मक eth_calls: एथेरियम कॉल्स जिन्हें अनुक्रमिक रूप से निष्पादित होने के बजाय समानांतर में निष्पादित किया जाना परिभाषित किया गया है।
• समानांतर निष्पादन: एक कॉल समाप्त होने की प्रतीक्षा करने के बजाय, कई कॉल एक साथ आरंभ किए जा सकते हैं।
• समय दक्षता: सभी कॉल के लिए कुल समय व्यक्तिगत कॉल के समय के योग (अनुक्रमिक) से बदलकर सबसे लंबे कॉल के द्वारा लिए गए समय (समानांतर) में बदल जाता है।

केवल eth_calls के बिना परिदृश्य

मान लीजिए कि आपके पास एक सबग्राफ है जिसे किसी उपयोगकर्ता के लेन-देन, बैलेंस और टोकन होल्डिंग्स के बारे में डेटा लाने के लिए तीन Ethereum कॉल करने की आवश्यकता है।

परंपरागत रूप से, ये कॉल क्रमिक रूप से की जा सकती हैं:

1. कॉल 1 (लेनदेन): 3 सेकंड लेता है
2. कॉल 2 (शेष): 2 सेकंड लेता है
3. कॉल 3 (टोकन होल्डिंग्स): लेता है 4 सेकंड

कुल समय लिया गया = 3 + 2 + 4 = 9 सेकंड

परिदृश्य डिक्लेरेटिव eth_calls के साथ

इस फीचर के साथ, आप इन कॉल्स को समानांतर में निष्पादित करने के लिए घोषित कर सकते हैं:

1. कॉल 1 (लेनदेन): 3 सेकंड लेता है
2. कॉल 2 (शेष): 2 सेकंड लेता है
3. कॉल 3 (टोकन होल्डिंग्स): लेता है 4 सेकंड

चूंकि ये कॉल समानांतर में निष्पादित होते हैं, कुल समय लिया गया सबसे लंबे कॉल के समय के बराबर होता है।

कुल समय = max (3, 2, 4) = 4 सेकंड

कैसे कार्य करता है

1. सबग्राफ manifest में, आप Ethereum कॉल्स को इस तरह घोषित करते हैं जिससे संकेत मिलता है कि वे समानांतर रूप से निष्पादित किए जा सकते हैं।
2. पैरलेल निष्पादन इंजन: The Graph Node का निष्पादन इंजन इन घोषणाओं को पहचानता है और कॉल को समानांतर में चलाता है।
3. परिणाम एकत्रीकरण: सभी कॉल पूरे होने के बाद, परिणाम एकत्र किए जाते हैं और आगे की प्रोसेसिंग के लिए सबग्राफ द्वारा उपयोग किए जाते हैं।

उदाहरण कॉन्फ़िगरेशन Subgraph मैनिफेस्ट में

निर्धारित eth_calls underlying आयोजन के event.addressके साथ-साथ सभी event.params तक पहुँच सकते हैं।

subgraph.yaml का उपयोग करते हुए event.address:

1eventHandlers:2event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)3handler: handleSwap4calls:5  global0X128: Pool[event.address].feeGrowthGlobal0X128()6  global1X128: Pool[event.address].feeGrowthGlobal1X128()

उदाहरण उपरोक्त के लिए विवरण:

• global0X128 घोषित eth_call है|
• यह टेक्स्ट (global0X128) उस eth_call के लिए लेबल है जिसे त्रुटियों को log करते समय उपयोग किया जाता है।
• यह पाठ (Pool[आयोजन.address].feeGrowthGlobal0X128()) वह वास्तविक eth_call है जो निष्पादित किया जाएगा, जो Contract[address].function(arguments) के रूप में है।
• address और arguments को उन वेरिएबल्स से बदला जा सकता है जो handler के निष्पादन के समय उपलब्ध होंगे।

subgraph.yamlका उपयोग करते हुए event.params

1calls:2  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()

मौजूदा सबग्राफ पर ग्राफ्टिंग

जब कोई सबग्राफ पहली बार डिप्लॉय किया जाता है, तो यह संबंधित चेन के जेनेसिस ब्लॉक (या प्रत्येक डेटा स्रोत के साथ परिभाषित startBlock) से इवेंट्स को indexing करना शुरू करता है। कुछ परिस्थितियों में, मौजूदा सबग्राफ से डेटा को पुन: उपयोग करना और किसी बाद के ब्लॉक से इंडेक्सिंग शुरू करना फायदेमंद होता है। इस indexing मोड को Grafting कहा जाता है। उदाहरण के लिए, विकास के दौरान, यह मैपिंग में छोटे एरर्स को जल्दी से पार करने या किसी मौजूदा सबग्राफ को फिर से चालू करने के लिए उपयोगी होता है, यदि वह फेल हो गया हो।

एक सबग्राफ को एक बेस सबग्राफ पर graft किया जाता है जब subgraph.yaml में सबग्राफ manifest में शीर्ष स्तर पर एक graft ब्लॉक होता है।

1description: ...2graft:3  base: Qm... # Subgraph ID of base Subgraph4  block: 7345624 # Block number

जब कोई सबग्राफ , जिसकी मैनिफेस्ट में graft ब्लॉक शामिल होता है, डिप्लॉय किया जाता है, तो ग्राफ-नोड दिए गए block तक base सबग्राफ के डेटा को कॉपी करेगा और फिर उस ब्लॉक से नए सबग्राफ को इंडेक्स करना जारी रखेगा। base सबग्राफ को लक्षित ग्राफ-नोड इंस्टेंस पर मौजूद होना चाहिए और कम से कम दिए गए ब्लॉक तक इंडेक्स किया जाना चाहिए। इस प्रतिबंध के कारण, ग्राफ्टिंग का उपयोग केवल डेवलपमेंट के दौरान या किसी आपात स्थिति में एक समान गैर-ग्राफ्टेड सबग्राफ को जल्दी से तैयार करने के लिए किया जाना चाहिए।

ग्राफ्टिंग मूल डेटा के बजाय प्रतिलिपियाँ बनाता है, इसलिए यह शुरू से इंडेक्सिंग करने की तुलना में सबग्राफ को वांछित ब्लॉक तक पहुँचाने में कहीं अधिक तेज़ होता है, हालाँकि बहुत बड़े सबग्राफ के लिए प्रारंभिक डेटा कॉपी करने में अभी भी कई घंटे लग सकते हैं। जब तक ग्राफ्ट किया गया सबग्राफ प्रारंभिक रूप से स्थापित हो रहा होता है, तब तक The ग्राफ नोड उन entity प्रकारों के बारे में जानकारी लॉग करेगा जिन्हें पहले ही कॉपी किया जा चुका है।

ग्राफ्टेड Subgraph एक ग्राफक्यूएल स्कीमा का उपयोग कर सकता है जो बेस Subgraph के समान नहीं है, लेकिन इसके अनुकूल हो। यह अपने आप में एक मान्य Subgraph स्कीमा होना चाहिए, लेकिन निम्नलिखित तरीकों से बेस Subgraph के स्कीमा से विचलित हो सकता है:

• यह इकाई के प्रकारों को जोड़ या हटा सकता है|
• यह इकाई प्रकारों में से गुणों को हटाता है|
• यह प्रभावहीन गुणों को इकाई प्रकारों में जोड़ता है|
• यह प्रभाव वाले गुणों को प्रभावहीन गुणों में बदल देता है|
• यह इनम्स में महत्व देता है|
• यह इंटरफेस जोड़ता या हटाता है|
• यह कि, किन इकाई प्रकारों के लिए इंटरफ़ेस लागू होगा, इसे बदल देता है|