Generalized multichain monitoring solution

It is clear that an onchain data monitoring solution is super critical. I believe every parachains have built some in house monitoring solution. It will be great if we can work together to avoid duplicated work.

Especially with XCM and have all the parachains interconnected, it is not enough to just monitor data on a single parachain. All the connected parachain data are also important. For example, to ensure the reserve assets matches to XCM reserved transferred asset amount. For such monitoring, we will need to be able to pull data from multiple parachains.

In additional to that, each parachain would have its own way of storing data. For example, for token data, some parachains could use pallet-assets or orml-tokens or their own multi-token pallet. Therefore, it is hard to have a generalized way to process those data without getting to implementation details of each parachain.

It will be great if we can all work together to build a generalized multichain monitoring solution that allow anyone to easily create monitor for any parachains and reuse / composite / collaborate monitors together.

Some tech stack ideas:

  • Use smoldot to connect to all the chains at once
  • Use wasm view function to write accessors & assertions and have them compiled as wasm
  • Monitors are compiled as a wasm and we can have shared hosted service running the user provided wasm
1 Like

I’ll share about our project that I think could be relevant. We have been working for a while on different ways to integrate Substrate and Matrix as there are lots of benefits the decentralized communications protocol can bring to the table. One such benefits being monitoring on-chain data where Matrix can take care of publishing insights in rooms that anyone can join to monitor and get notified automatically.

Our PoC is a container with a Substrate node, a lightweight homeserver like dendrite/conduit and a general purpose appservice that comes with its own WASM runtime to extend the homeserver functionality with plugins that can be composed. One such plugins is a Substrate client that talks to the node via RPC to let other plugins submit transactions, query or subscribe to state changes. The next stage of this project is to pack everything in a single lightweight and easy to deploy binary where the WASM runtime also hosts the homeserver and a smoldot light/full node as plugins. Chains will also have a pallet-summa(substrate meets matrix) that couples the two ecosystems further adding nice extra features.

Having a general purpose WASM runtime where plugins can subscribe to events happening in a chain(or multiple) and then be able to publish the result of a computation on a storage that anyone can replicate in a decentralized way is a great solution to this kind of problem.

1 Like

I briefly presented Moonbeam’s in-house monitor solution for this, and the way we set up our monitor to track Sovereign Account balances on each chain and total supply of the representation asset. You can find the slides here: 20221129 - Moonbeam XCM Sub0 [External] - Google Slides

We rely on public endpoints (with redundancy and we check for endpoint health), and programming how each asset is defined as a multilocation, and how to read the sovereign account’s balance on each specific chain.

The idea’s mentioned seem good but it might take some time to implement.

1 Like