Skip to main content

Interoperable State Machine Protocol

  • Team Name: Polytope Labs
  • Payment Address: 0x486cbad2d704bc76f8d0cdda6aa93c94d53297b9 (Ethereum DAI)
  • Level: 3

Project Overview 📄

Overview

The Interoperable State Machine Protocol, or ISMP for short, is the product of our research into state proofs. We show that state-proof based interoperability is possible and more efficient as the messages no longer need to be routed through the relay chain and can be exchanged independent of it, while still maintaining the same level of trustlessness and security. This protocol allows not just for messaging but also state reads of other parachains in a trustless and secure manner.

Unfortunately, Parachain-to-Parachain communication today relies on the relay chain for message routing. This is highly inefficient and relieving the relay chain of this burden will allow for better Parachain throughput and scalability. We believe ISMP is the end-game for parachain interoperability, with the relevant ISMP modules, each parachain can send and receive messages and assets to and from other parachains which also have the ISMP modules. Seconded by Rob Habermeier on twitter.

Project Details

ISMP is a simple protocol for state machines to send requests that can be handled by a counterparty chain. Akin to the HTTP paradigm in web2, parachains can issue GET-like requests for storage reads as well as POST-like requests for sending data.

Requests are stored in a merkle mountain range tree on the sending chain as this data structure provides some benefits, binary merkle trees have more compact proof sizes than patricia merkle tries, and in particular, merkle mountain range trees have much smaller proof sizes for recently inserted items in the tree. We believe this choice will enable higher bandwidth parachain <> parachain messaging with smaller proof sizes.

ISMP will also support request timeouts, allowing for more safer parachain <> parachain messaging.

Architecture

Use cases

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('s wallet) after observing that parachain A's headers have been finalized and made it's way into the relay chain state trie, 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. 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.

pallet-ismp

This serves as the foundational element for state-proof based messaging between parachains, enabling state reads of the relay chain directly from any given parachain, granting the ability to verify incoming messages and data from other parachains under the shared security umbrella of the relay chain.

Custom crates

  • ismp-rs - A set of primitives necessary for pallet-ismp
    • ISMPHost: Represents a state machine's core functionality
    • ISMPRouter: Embodies the request and response routing logic for parachain interactions
    • ConsensusClient: Logic for consensus proof verification

This module can also serve as an alternative transport layer for XCM programs.

Ecosystem Fit

Currently messages are sent over the Relay Chain through opening HRMP channels but through ISMP 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.

Team 👥

Team members

  • Leads: Seun Lanlege, David Salami
  • Members: Damilare Akinlose, Femi Bankole, Jesse Chejieh

Contact

  • Registered Address: Harneys Fiduciary (Cayman) Limited, 4th Floor, Harbour Place, 103 South Church Street, Cayman Islands
  • Registered Legal Entity: Polytope Labs Ltd.

Team's experience

Polytope Labs is a collective of core blockchain engineers, researchers & scientists from varying blockchain protocol backgrounds passionate about the proliferation of networks over platforms and enabling this future through blockchain research, education, tooling and core infrastructure development.

  1. Seun Lanlege - Founder, Mad Scientist at Polytope Labs and Polkadot Fellowship Member. Previously core developer at Parity Tech, Worked on Ethereum and Polkadot with over 4 years of industry experience.

  2. David Salami - Scientist at Polytope Labs and Polkadot Fellowship Member. Previously Senior Blockchain Engineer at Composable Finance and Webb.

  3. Damilare Akinlose - Lab Intern at Polytope Labs and Polkadot Fellowship Member. Previously Blockchain Engineer at Webb

  4. Femi Bankole - Blockchain engineer at Matchx_iot + MXC Foundation and Lab Intern at Polytope Labs.

  5. Jesse Chejieh - Polkadot Fellowship Member.

Research Publications

Team Code Repos

Team GitHub Profiles

Team LinkedIn Profiles

Development Status 📖

State-proof based parachain messaging has been discussed on the Polkadot Forum.

And some Updates to cumulus, required for parachains to read the relay chain state has been approved

Development Roadmap 🔩

Overview

  • Total Estimated Duration: 4.5 Months
  • Full-Time Equivalent (FTE): 3
  • Total Costs: 75,000 USD

Milestone 1 — ismp-rs

  • Estimated duration: 1.5 months
  • FTE: 3
  • Costs: 30,000 USD

In this milestone we develop the core primitives needed for pallet-ismp

NumberDeliverableSpecification
0a.LicenseApache 2.0
0b.DocumentationWe will provide both inline documentation of the code and a README stating objectives of this ISMP primitive on the project repository.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test functionalities delivered with this milestone.
0e.ArticleWe will publish an article that explains what was achieved as part of the grant.
0f.ISMP SpecificationWe will put together a technical specification detailing the ISMP protocol.
1.ismp-rsRust implementation of ISMP primitives for handling incoming messages to and from connected parachains.
1a.ISMPHostState machine host functionality required to support ISMP.
1b.ISMPRouterSub-component for routing incoming requests & response to the destination ISMP modules.
1c.ISMPModuleInterface modules/pallets must conform to in order to receive incoming ISMP requests/responses.
1d.ConsensusClientLogic for consensus proof verification, In the case of parachains, we will leverage the relay chain as a ConsensusClient through the new host functions in cumulus.
Request/Response proof verificationSub-component for verifying membership of proofs of a request/response in a merkle mountain range tree.
Request Timeout verificationVerifying non-membership of a request in the state trie of a parachain.
1e.HandlersLogic for handling varying types of incoming messages.
CreateConsensusClientFunctionality for creating a consensus client on the receiving state machine.
ConsensusMessageFunctionality for handling consensus update messages from other state machines.
RequestMessageFunctionality for handling request messages from other state machines.
ResponseMessageFunctionality for handling response messages from other state machines.
TimeoutMessageFunctionality for handling request timeout messages from other state machines.

Milestone 2 — pallet-ismp

  • Estimated duration: 3 months
  • FTE: 3
  • Costs: 45,000 USD

In this milestone we develop pallet-ismp

NumberDeliverableSpecification
0a.LicenseApache 2.0
0b.DocumentationWe will provide both inline documentation of the code and a README stating objectives of this ISMP primitive on the project repository.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test functionalities delivered with this milestone.
1.pallet-ismpBuilding the substrate pallet with above stated dependencies.
1b.HostISMPHost implementation for the pallet.
1c.RouterISMPRouter implementation for the pallet.
1c.ParachainConsensusClientConsensusClient implementation for the pallet-ismp, utilizing the relay chain as consensus client for parachains.
1d.RPCThis sub-crate will allow for users to query relevant ISMP data over RPC.
1e.Runtime-APIsThis sub-crate will expose relevant ISMP data from the runtime through runtime APIS.
1f.BenchmarksWe will benchmark pallet-ismp, providing a benchmark crate for parachain teams to run so as to generate the proper weights for their runtime.

Future Plans

We recognize the significant benefits that pallet-ismp offers to the ecosystem, and therefore, after the grant completion we plan to continue providing maintenance with support from the Polkadot/Kusama treasury.

Additional Information ➕

Solidity Trie Verifier