Polytope Labs is actively researching blockchain interoperability and in this article, we show that trustless blockchain <> blockchain interaction is a possible using state proofs.
Given this possibility we’d like to propose a new set of primitives for parachain <> parachain interoperability that will serve as an alternative to atomic interactions over hrmp and xcm.
Polkadot parachains already exist within a shared trust (security) zone, as such, this removes the need for parachains to “handshake” with each other over channels. Assets and data should be able to move freely across parachains unencumbered by the need for xcm channels.
By committing outgoing messages to the state trie and verifying the state proofs of these messages on the receiving parachain, we can facilitate trustless parachain <> parachain messaging.
This approach also serves as an optimization to the current parachain interoperability model. Previously, messages were sent over the relay chain via HRMP. However, by leveraging state proofs that can be exchanged without touching the relay chain, we can increase the bandwidth of messaging between parachains without burdening the relay chain with these messages. This allows the relay chain to focus on its main task: enforcing the validity of parachain state transitions.
We propose for new primitives which will exist inside of cumulus allowing parachains to read the relay chain state, via a host function. This host function is possible because parachain nodes already maintain a full relay chain node and so already has access to the full relay chain state. Subsequently, during POV validation, the relay chain can override the host function and provide access to it’s own state to the parachain state transition function.
This will in turn allow for any parachain to access the finalized headers of it’s sibling parachains which are stored on the relay chain. Using these finalized headers, it can verify state proofs and trustlessly read the state of it’s sibling parachains.
Given these APIs we can now build a messaging and state querying protocol for parachains based on state proofs that can be exchanged independent of the relay chain.
Proof verification is one thing. On top of that, there should be a way to relay the plain messages to the destination chain. In XCMP, I believe the collator should connect to the full node of other chains to fetch the data by p2p connection. If the connection is not reliable, it may block the block production (correct me if it’s wrong), or at least block the messagea from other chains if the messages are processed in order.
I think oracles may not be needed here actually, for relay chain state, collators already have access to it.
As for parachain state, we can add a new inherent provider which listens to state proof requests or messaging from other parachains over wss and includes those state proofs in the runtime as inherents.
I’m favouring wss over p2p connections over libp2p as this puts less networking load on parachain collators. The maximum connections they’d maintain would be 100 wss connections. Whereas over p2p that number may grow to be well over 1000s of connections.
AFAIK the latest iteration was that messages are fetched through availability protocol from the relay chain. In general you are right and we will need to buffer the messages until they are all ready and don’t block block production.
I don’t get why you need more P2p connections than wss? You will also not need to be connected to collators, you will just need to connect to any full node to fetch the messages.
To clarify, I’m envisioning that the parachain block producers themselves are the ones who will watch the other parachains for messages and include state proofs of those messages as inherents.
Yeah for sure will collators do this, but this doesn’t explain the stuff about the connections. In polkadot each validator is also connected to each other validator, which also brings you to 1000+ connections. Nodes also don’t have any real upper bound on connections, only the individual protocols put a bound on how many slots they have for nodes. I also don’t see any difference in using libp2p vs wss, because the dominating part will be the reading of the messages from the state and not the connection handling.
I’m not saying that there’s a limit, I’m just saying this introduces unnecessary networking load.
If we used libp2p for this, then every collator needs to participate in the swarm for every other parachain, this is in my view, unnecessary seeing as we can swap this out with a single wss jsonrpc connection for every parachain.
