Demystifying Multi-Chain Indexing

In the realm of blockchain technology, new networks are consistently emerging, each meticulously designed for specific functions. This trend extends beyond prominent Layer-1 blockchains, encompassing the rise of application-specific chains like Polkadot, Cosmos, Avalanche Subnets, Polygon Supernets, and Optimism Stack networks, among others. The expansion of these specialised chains is ongoing.

For developers, these autonomously operating blockchains present a significant operational challenge. Gaining seamless access to data across multiple networks can be challenging due to differences in data formats, RPC interfaces, and contract environments.

Within the web3 ecosystem, leading decentralised applications like Chainlink, USDT, Gnosis Safe are deployed across multiple blockchains. For developers aspiring to build the next decentralised application, this becomes a key requirement for their project.

SubQuery has stepped in to bridge this gap, offering a revolutionary solution - Multi-Chain Indexing. Multi-chain allows the developers to index data from different blockchains into a unified database that enables them to query a single endpoint to retrieve data from multiple blockchain networks simultaneously. It is a “write once, run anywhere” solution making it possible to deploy your indexing service to cover all chains with minimal marginal effort.

Use-Cases


One compelling use case that underscores the necessity of multi-chain indexing is cross-chain analytics. Imagine a scenario where you need to analyse Cross-Chain Message (XCM) transfers from one parachain to a smart contract residing on a different parachain, one that is EVM compatible. Without multi-chain indexing support, you would face the daunting task of managing two separate indexing projects, each dedicated to a different parachain. This approach would involve writing data to distinct tables, schemas, or even databases, necessitating subsequent external ETL processes to merge and consolidate data for comprehensive analysis.

Beyond analytics, the challenge also extends to dApp development, where real-time monitoring of cross-chain transactions could become cumbersome. Multi-chain indexing simplifies this by centralising data access, allowing developers to query and monitor transactions and events across chains efficiently. This streamlined approach eliminates the need for multiple connections and queries, significantly enhancing the development and analysis experience in a multi-chain environment.

Getting Started with Multi-Chain Indexing

To create a multi-chain project, you'll follow most of the same steps as you would for indexing a single chain. However, there are minor differences to consider when configuring a manifest file.

Each chain you intend to index will need its own manifest file. Additionally, you'll require a `multichain-project.yaml` file to specify the list of supported chain manifests.

The good news is that we've streamlined this process with CLI commands that automate manifest generation for each chain. For a hands-on guide to setting up multi-chain projects, refer to the official documentation (https://academy.subquery.network/build/multi-chain.html).

In most cases, the only variation in your manifest files will be in the `network` section. You may not need to make other changes, such as redesigning GraphQL schema or writing mapping files, unless your specific use case demands them.

Example

Explore a fully functional multi-chain project example here. This project indexes data from multiple networks (Polkadot, Kusama, AssetHub) into a single database. The example includes a `docker-compose.yaml` file with three subql/node images, one for each network being indexed, where each image consequently maps to a separate manifest file, ensuring a seamless indexing experience.

Using the provided example, you can initiate on-chain analysis. For instance, to retrieve all incoming transfers for a specific account across both Kusama and Polkadot, you would need to execute the following query:

query {
  transfers(filter: {to: {genericSubstrateAccountId: {equalTo: "5CmL8cuc1RPYusoix25VdL71g6dRUdJDMDp72fbKFP4QPbNp"}}}) {
    nodes {
      id
      blockNumber
      network
      amount
      from {
        id
        genericSubstrateAccountId
      }
      to {
        id
        genericSubstrateAccountId
      }
    blockNumber
    }
  }
}
```

Executing this specific query will yield the following results:

{
  "data": {
    "transfers": {
      "nodes": [
        {
          "id": "kusama-19602625-37",
          "blockNumber": "19602625",
          "network": "kusama",
          "amount": "5000000000000",
          "from": {
            "id": "F7fq1irK3J8tbBHJ2aeXJMAZTEXkoyPWPNJL1TTMhsjo6GZ",
            "genericSubstrateAccountId": "5Ec4AhNyggHD8wMqXKmbdLzAQrxHx9AD41XYwMBVsufF49RX"
          },
          "to": {
            "id": "DGwnwFUdnQUfXdAiitYXHU1pgufHJ7PoberRKsGjBGu8bS6",
            "genericSubstrateAccountId": "5CmL8cuc1RPYusoix25VdL71g6dRUdJDMDp72fbKFP4QPbNp"
          }
        },
        {
          "id": "polkadot-17272388-38",
          "blockNumber": "17272388",
          "network": "polkadot",
          "amount": "1000000000000",
          "from": {
            "id": "13YMK2eYoAvStnzReuxBjMrAvPXmmdsURwZvc62PrdXimbNy",
            "genericSubstrateAccountId": "5Ec4AhPUwPeyTFyuhGuBbD224mY85LKLMSqSSo33JYWCazU4"
          },
          "to": {
            "id": "1hdGxAfsCf2MQpEuf8VmUwAXid5AvrMRiYbBxafoU5vZuKL",
            "genericSubstrateAccountId": "5CmL8cuc1RPYusoix25VdL71g6dRUdJDMDp72fbKFP4QPbNp"
          }
        }
      ]
    }
  }
}
```

In the query provided above, we have utilised a filter to ensure that we obtain a corresponding `genericSubstrateAccountId` (you can find additional details in the Substrate documentation) stored within the `to` field of the transfer receiver object. The outcome reveals that the same `genericSubstrateAccountId` is present in both networks, although they possess distinct `id` values due to their occurrence in separate networks. These `id` fields correspond to the ones previously mentioned in reference to Subscan.

Furthermore, when you combine multi-chain capabilities with aggregations, it opens up significant possibilities for cross-chain analysis without a need to exit the GraphQL interface to gain insights into specific subject matters.

This example is accompanied by comprehensive documentation, which you can access here. It provides step-by-step instructions, Docker configuration details, and tips for configuring a running your own multi-chain project.

Conclusion

In conclusion, this article has provided insights into Multi-Chain indexing, highlighting its capabilities and practical applications. It offers developers, researchers, and businesses an invaluable tool to navigate the complexities of the ever-expanding blockchain ecosystem. This not only promotes interoperability but also facilitates cross-chain data analysis, enabling us to gain a holistic view of decentralised networks.

By following the outlined steps in the official documentation, you can harness multi-chain indexing to streamline cross-chain data aggregation using Subquery. Embrace the potential of multi-chain indexing and begin your journey toward mastering this revolutionary feature.

About SubQuery

SubQuery is a leading blockchain data indexer that provides developers with fast, flexible, universal, and decentralised APIs for web3 projects. We empower developers from over 100+ ecosystems including Ethereum, Polygon, Polkadot, Cosmos, Algorand, NEAR, and Avalanche with rich indexed data to allow them to build intuitive and immersive decentralised applications. This blockchain developer toolkit enables developers to focus on their core use case and front-end without wasting time building a custom backend for data processing activities. In the near future, the SubQuery Network will replicate this scalable and reliable solution in a completely decentralised manner.



  
     



Share this post