XCM provides a trustless way for relay/parachains to dispatch messages to each other. However, there is another common use case that’s not fully addressed by XCM, which is the ability to trustlessly read onchain state from another chain. While it is possible to create a protocol on top of XCM to allow chains to publish their onchain states, it may not necessary be the best way due to overheads of XCM. Especially at this stage we are still using XCM-lite that all the messages consumes relaychain block space, which makes it more costly to publish onchain state via XCM.
Interchain Proof Oracle Network
Bot network to allow parachains to asynchronously and trustlessly read eachother’s state.
Summary
Off-chain bots listen for (paid) proof requests on one chain to know information stored in another chain’s state. If the bot runs a client on the target chain, it creates a light-client proof that the other can interpret and places a free transaction into a new Proof-Receipts pallet. The transaction sees the bot get paid a small amount.
Components
Interchain oracle pallet
Installed on parachains that wish to read data from other chains
Expose interface for other pallets to post requests and handle responses
Handles fee charge and payment
Charge fee for making requests
Charge fee for invalid submission
Pay request fee to relayer
Allow parachain to customize the exact mechanism
Validate relayed data and translate them into a developer friendly data structure (instead of just passing bytes around)
Relayer bots
Monitor requests from parachains
Fetch data from source chains and relay to dest chains
Implemented with node.js and use smoldot as ligth client to be able to connect to multiple parachains without too much overhead
Collator integration (Optional)
For future version
Allow collators to integrate with relayer bots so they will be able to serve the relay requests before anyone else
Another source of income for collators
Parachains could want to only allow collators to relay the state to avoid duplicated submissions
Example use cases
After a XCM is dispatched, subscribe for the execution result.
Proof of reserve to ensure the data consistency.
Read staking reward amount on relaychain to correctly calculate the price of a staking derivative.
Crosschain automation via foreign chain smart contracts
Next step
Determine what’s missing from Cumulus side to make this possible
One big example use case that’s missing: smart contracts for chains without contracts!
With read/write XCM functionality (and when xcm for contracts goes live) it becomes possible to write smart contracts that use other parachain’s functionality without that parachain having a smart contract VM, which is very desirable since when you have a VM, your chain is open to anything, not necessarily using it’s unique pallets, so delegating contracts to parachains made for them is a great feature in my opinion.
Just to add that, while right now it would have to be implemented with node.js, eventually native light client support should be ready for use.
As I understand, the only blocker right now is that the pure Rust implementation of a smoldot client doesn’t support WSS, and because it can’t find any non-full WS peer, it just fails to sync.
But with that fixed, the implementation can be made in Rust and properly integrate into collators without much hassle.
For PoC it should be quicker to do with node.js but yeah as I already noted in Collator integration part we will want a Rust implementation that can be integrated into collator. But there are a lot of details that we need to figure out, such as if we do want to have smoldot included in parachain binary?
That should be an easy optional feature with a Rust compiler feature flag, not all binaries should include it, but if you’re compiling for this purpose, then a feature flag is the easiest way to include smoldot in the binary.
I really like the idea of integrating into the collator workflow, for my parachain I’d like to explore requiring collators to run relayer bots to be valid collator candidates.
And wouldn’t it be possible to get rid of the bot in the first version if the Interachain-Oracle-Pallet would simply start off-chain workers that return ReadProofs from rpc-queries which are submitted then? Could even be signed by the collators and then signature be validated against current active authorities.
Or why would there be any need for changes on the cumulus side?
It is easier (and likely safer with smoldot) to implement the bot with nodejs bot instead of offchain worker.
Offchain worker simply don’t have the ability to embed a light client of other parachains currently so without that collators have to configure trusted RPC endpoints of other parachains, that will just increase maintenance overhead.
But of course there is no reason why anyone cannot just start working on the offchain worker version. How the bots are implemented are just implementation details and it will be good if we have multiple implementations available.
So with less safer you are referring to the downside of having one/multiple hard-coded rpc endpoints, right?
What I still don’t understand is, why this would need changes on the cumulus side. For syncing with other networks in the background via light-clients or so?
So with less safer you are referring to the downside of having one/multiple hard-coded rpc endpoints, right?
Yes. Simply trust the RPC node is not as secure as using light client. But actually in this case because all the proof can be verified trustlessly so this isn’t really a good argument for this particular use case.
What I still don’t understand is, why this would need changes on the cumulus side. For syncing with other networks in the background via light-clients or so?
I don’t know if we need any changes at all and that’s why the step one is to find out if there are upstream changes required or not.
The same can be said about bootnodes, although those are bound to change a lot less, it would still require maintenance.
In order to avoid manual intervention and thus maintenance in general, it would be interesting to find a way to share addresses for active peers through the network, without relying on bootnodes. This may be achievable by instructing the target chain to somehow send new addresses to the chain attempting to read the target’s state.
According to my understanding the off-chain/relayer bot part could be done through Acurast.
In Acurast there are Data Transmitters that have a Trusted Execution Environment where arbitrary code can be executed. One chain can be observed and the verifiable result is pushed to the Acurast Pallet on the destination chain.
We would require having two proofs. One proof containing the others parachain storage root in the relay chain block. It would be required to use some recent relay chain block the initiating parachain knows the storage root of to verify the proof. Then the proof from the parachain about the requested data.
The only problem I see is that there is no “generalized proof format”. You will always need to use the same proof generation algorithm that the target parachain use to compare against the storage root. If I’m wrong here and there exists something, I would be interested to read about it.
We should do generalized proofs, as not having them makes things like async backing and xcmp harder, although not having them maybe helped us avoid doing painful and mostly unneeded things like remote disputes too. Anyways, there are several concerns like proving algorithms, like you say.