Interoperable State Machine Protocol

[Doordashcon]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[semuelle]

Hi @Doordashcon, thank you for your application! We will look into it as soon as possible.

[keeganquigley]

Thanks for the interesting application @Doordashcon this looks like very interesting tech. Just one initial comment:

• I see the individual milestone costs but it looks like the Overview section is missing. Can you add this to include the total costs for the project?
• I also don't see a "Future Work" section. Could you perhaps add a description of how you plan to maintain the project after the grant? Thanks!

[Doordashcon]

Hello @keeganquigley and thanks for the review! I have added the missing sections. Please review

[keeganquigley]

Thanks for the changes @Doordashcon I will go ahead and mark the application as ready for review and ping the committee.

[burdges]

At first blush I assumed this related to either our planned XCMP or else a state channel idea that benefits from parachains. We're interested in both of those, and more broadly in teams trying to do this sort of thing. After a closer look however..

We already do everything until the phrase "Proofs of Computational Integrity Schemes", which then cites the PCP paper and STARK paper. Is the plan that somehow STARKs or similar help with bridges?

We should clarify one thing: "Polkadot relay chain re-executes parachain blocks with their given state proofs" is not technically correct. The relay chain never re-executes parachain candiates per se. Instead, we already have an interactive protocol which proves correctness of the parachain candidates, under some byzantine assumptions. In this, 40+ random polkadot validators re-execute parachain candiates, and we block polkadot finality upon their validating the parachain block, but all this stays off-chain, and attackers cannot have much advance knowledge of the these approval checkers. It'll be hard for "zk roll ups" to compete with this "cut n choose roll up" design, but yeah bridges bring more complexity.

[seunlanlege]

Thanks for the review ser @burdges

We already do everything until the phrase "Proofs of Computational Integrity Schemes", which then cites the PCP paper and STARK paper. Is the plan that somehow STARKs or similar help with bridges?

The state machine proofs article simply reviews the different applications of state proofs as they relate to trustless bridges, stateless clients, fraud proofs and zk-state-machines (aka zk-rollups).

At first blush I assumed this related to either our planned XCMP or else a state channel idea that benefits from parachains

ISMP is very much a state "channel" protocol, If you review the rest of the grant application we describe how it can enable SPREE-based messaging and storage reads among parachains under the shared security umbrella. Infact the next logical step after the implementation of ISMP is SPREE on the relay chain to protect the ISMP module.

[Doordashcon]

Good day sers @semuelle @keeganquigley @burdges, lightly pinging to get an update on the application.

[burdges]

Ask @AlistairStewart but I think he looks pretty busy this week and next.

[Noc2]

Thanks a lot for the application, and sorry for the delay here. This looks really interesting. If I remember correctly, this is the long-term goal of xcmp from the beginning. I have one question here: how would the message actually be relayed or sent to the other chain? Could you describe the "relayer" part of your diagrams in a little bit more detail?

[seunlanlege]

how would the message actually be relayed or sent to the other chain? Could you describe the "relayer" part of your diagrams in a little bit more detail?

We leverage an offchain component ("relayer" as we describe it) which is responsible for reading the source chain and composing the appropriate extrinsic along with the neccessary state proofs to be sent to it's destination chain.

We did not include it as part of the grant, because it's design is still in flux. We are currently investigating a self-relay alternative where users (or their wallets specifically) are responsible for relaying their messages to the destination chain. This way we avoid the philosophical dilemna of relayer incentivization.

[Noc2]

I shared it again with the rest of the team.

[Doordashcon]

Thank you @Noc2, looking forward to the reviews.

[dsm-w3f]

Thank you for the application. I think the technology is very interesting since it opens new possibilities in the ecosystem. Exploring a bit more on the relayers. Currently, the relayer for XCMP is Polkadot. With this new technology developed, would be self-relayed, or open for new relayers, correct me if I'm wrong. What would be the possible economic impact for Polkadot, for example, caused by this new technology being available? Could elaborate a bit on that?

[seunlanlege]

With this new technology developed, would be self-relayed, or open for new relayers, correct me if I'm wrong.

The on-chain protocol doesn't make any enforcements on how requests & responses are to be relayed, so there's opportunities for both dedicated relayers and self-relaying. We believe self-relaying provides a better UX rather than users having to bid to have their packets relayed. Their wallet simply submits the request to the destination chain.

What would be the possible economic impact for Polkadot, for example, caused by this new technology being available? Could elaborate a bit on that?

Relaying parachain messages is a free service the relay chain currently provides. This is also not efficient as the relay chain forms a bottleneck in parachain messaging.

By unburdening the relay chain of parachain messages and allowing parachains to exchange state proofs of messages, this significantly increases the bandwidth of parachain messaging to orders of magnitude not achievable by the relay chain. This also provides benefits to the relay chain allowing it to increase the throughput of parachain & parathread block validation, services which actually "consume" the dot token.

[AlistairStewart]

Of course we were always planning in XCMP to move message passing off the relay chain and deal with more complex use cases. This protocol is aiming to give a simple version of that.

In the diagram, it is not clear what is on-chain or off-chain. Clearly the relayer can read chain B's state off-chain, as long as it is actually running a cumulus node for B. So maybe nothing needs to be on-chain on chain B at all. Then the question is why have requests on-chain on chain A? That depends on the workflow you imagine for using this. In some cases, when a transaction involving a proof would pay the relayer, then there would be no need for an explicit request. This is often how bridges work. But then maybe a user who is not running a node of chain B would want to do some action that needs data from chain B. What would the flow for this look like? Please think of some use cases before finalising the architecture.

What is stored in the relay-chain state and how? Right now, the relay chain has head data for each parachain. Using that would require state proofs on both the relay chain and chain B and they would have to be in sync, i.e. using the state root of B in that relay chain block. If you wanted to reference an old root for chain B, that wouldn't work. We were using MMRs on the relay chain to solve exactly this problem for the Ethereum bridge. There should be a way of putting some kind of root from a parachain into leaves of the BEEFY MMR on the relay chain. Because this hasn't been deployed yet, I couldn't tell you exactly how to do this, but any parachain should be able to when it is deployed.

Proofs being arbitrary state proofs from the state root of chain B is the most powerful architecture, but offers little in the way of security. Basically, a protocol on chain A can depend on how chain B stores an arbitrary part of its state. Substrate chains should be able to regularly run complex state migrations and change how and what any piece of data is stored. This is Substrate, the philosophy is not the same as trying to do cool stuff with Bitcoin, a protocol that we can expect will never change and so we have to come up with really clever ways of doing what we want. If the state format of B does change, then it is up to the devs of the protocol on A to keep up with any such changes, and maybe the devs of chain B don't even know that other chains are relying on this. Clearly an alternative is for B to publish a root of some subtree of its state that it expects to be read, or otherwise indicate which parts of its state or what type of key it expects to be read. Then at least the devs of chain B would know what might break stuff on other chains. A lot of the effort in XCM is to come up with sensible cross-chain standards and deal with permissions

[seunlanlege]

Thanks for the review @AlistairStewart

In regards to this

Please think of some use cases before finalising the architecture.

The protocol allows for both "POST" & "GET" requests.

For instance a user wanting to transfer their funds from parachain A to parachain B will initiate a post request on parachain A. This post request is stored in an mmr maintained in the state trie on parachain A. Parachain A's headers also contain the root for this mmr structure.

The user after observing that parachain A's headers have been finalized and made it's way into the relay chain state trie, they can present a merkle proof of parachain A's header in the relay chain state trie which parachain B can verify using it's access to the latest relay chain state root. Next they present the mmr proof for the request which they had previously initiated on parachain A. After verifying this mmr proof, parachain B can "execute" the request. In this case minting the equivalent asset that was burnt on parachain A.

There are of course other use cases that can be built on POST requests, but this is the simplest case.

For GET requests, a different mechanism is at play. Perhaps a user wants to settle a bet they had made in a prediction market in parachain A. The data that is needed to settle this bet is on parachain B where we regard parachain B as the oracle parachain. The user initiates a GET request, with it's content the keys of the storage items they need to settle their bet. This of course like you noted relies on the storage addresses not changing. Which shouldn't be an issue in this case, becasue the oracle parachain can leverage a child trie to store data that is intended to be provided to other parachains such that the addresses are immutable. ideally parachains should only depend on storage addresses in other parachains that are intended to be exposed and as such will not change as often.

After initiating the request, the request is stored in the parachain A's mmr trie, but it is never relayed anywhere. Instead, the user('s wallet) then reads the state trie of parachain B and provides the state proof for the appropriate data that was requested.

[Noc2]

Thanks for the reply here. Could you try to clarify this also as part of the application?

[seunlanlege]

Could you try to clarify this also as part of the application?

I've added a use-case section to the grant application 🙏🏿

[seunlanlege]

Good day sers, Happy to address any other concerns about the protocol.

[Noc2]

Thanks. I will share it again with the rest of the team, and I'm also pinging @AlistairStewart here in case he has additional comments.

[keeganquigley]

Thanks for answering all the questions. LGTM

[semuelle]

The totals don't match the sum of the milestones.

[Doordashcon]

Hello @semuelle, This was an oversight, we previously had three milestones, the last milestone included configuration to cumulus which has been implemented and merged.

The estimated duration has been updated, pls review.

[takahser]

@seunlanlege sorry for the delay and thanks for your patience as well as the clarifications and updates to the application. It's great to see the use-case section added, and the explanation of the relayer and message passing mechanism is helpful. I'm therefore happy to approve as well.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀