The Interoperable State Machine Protocol
In this article we explore The Interoperable State Machine Protocol (ISMP) and the value it unlocks for blockchain interoperability and the polkadot ecosystem.
Written by
Published on
Do not index
Do not index
We are proud to announce that Polytope Labs has completed the implementation of the the Interoperable State Machine Protocol (ISMP), with the help of the Web3 Foundation grant program.
What is ISMP?
ISMP is a novel transport protocol designed to enable trust-free interoperability between blockchains. The protocol relies on consensus clients and state machine clients to ensure the validity of consensus proofs and state proofs, respectively. This separation of concerns is critical, as it makes ISMP future-proof, as the industry embraces the modular blockchain paradigm pioneered by Polkadot.
Reasoning
We believe that HTTP is the gold standard of interoperability on the internet. With this in mind, the motivation was to design an equivalent protocol for multi-chain environments. ISMP has been crafted to be familiar to developers from a variety of backgrounds. To achieve this, the design incorporates some intuitive ideas from HTTP. This effectively allows developers to leverage their existing knowledge of HTTP when incorporating the protocol into their multi-chain applications.
ISMP is designed to be a request-response protocol allowing applications to make both POST-like and GET-like requests and receive responses to these requests in similar fashion as HTTP. We believe this unlocks new kinds of application architectures which will drive further adoption and usage of decentralised protocols, as applications can become sharded on multiple chains, serving more users than ever before.
Why not just use IBC? While it is a powerful protocol, IBC was designed for low trust environments. In an environment lacking shared security, the use of channels is necessary to track the trust assumptions of a packet. This is achieved through protocol layer authentication, which manifests as a 4-way handshake on a per-application basis. These extra messages for handshakes incur additional blockspace costs. More so, IBC was designed for monolithic blockchain architectures, and doesn’t perform well in modular architectures where a single consensus client can hold multiple state machines.
.png&optimizer=image&quality=80&width=280)
The team has spent over a year working on a substrate-IBC implementation that is currently used in Centauri, the Polkadot to Cosmos bridge. However, we're not confident that it will be feasible to use in expensive environments like the EVM, and it will likely only proliferate where blockspace is very cheap. This is one of the core reasons behind ISMP, a super lightweight protocol that can be implemented in any blockchain.
Deep dive
Lets take a quick look at how the protocol works.
Life Cycle of Requests and Responses
When a request is dispatched from a module on the source chain this can be either a POST or GET request, a commitment of that request which is a fixed-sized hash is stored in state trie as this reduces it’s storage footprint, next an event is emitted containing the full request this event informs any party that wishes to relay the requests of the existence of a new request.
For POST requests, a
RequestMessage that contains a state proof of membership is submitted to the destination chain. This proof of membership is linked to a previously verified header on the destination chain by a consensus client of the source chain. Upon verifying this state membership proof, the request is processed, and a receipt for the request is committed to storage. The destination module or contract can create a response synchronously or asynchronously. Whenever a response is available, it can be relayed back to the source chain.When a GET request is successfully dispatched on a source chain, it is never relayed to the counterparty chain, but rather, a relayer or any interested party fetches a state proof for the storage keys specified in the request and submits a response to the source chain. On the source chain, the state proof is verified and the values for the specified keys are extracted from the state proof. In essence the response to a GET request is a state proof.
Responses to POST requests have a similar life cycle to their request counterpart, when a response to a Post request is dispatched, a commitment of the response is inserted into the state trie and an event is emitted. A
ResponseMessage which contains a membership proof is submitted to the destination chain by a relayer, on successful processing of this message, a response receipt is committed to storage.
Timeouts
Timeouts are a mechanism that ensures requests are not left without a response indefinitely.
Both POST and GET requests can specify a timeout, a POST request timeout is evaluated based on the timestamp of the destination chain, this means that post requests cannot timeout if the destination chain does not make progress, using the destination chain timestamp prevents situations where a bad actor could submit a timeout for a request that was already successfully executed on the destination.
On the other hand, timeouts for GET requests are evaluated relative to the timestamp of the source chain, the timestamp represents the time on the source chain after which responses to a GET request will be rejected.
Security
Security is paramount in interoperability protocols because any loopholes will be swiftly exploited by bad actors as we have seen happen time and again with catastrophic ramifications. To mitigate this and keep the bad actors at bay, ISMP has incorporated sound security features.
Challenge periods
It is required that a challenge period is configured for every consensus client. The challenge period is the amount of time which must have elapsed before any consensus update can be used to verify validity of messages (requests & responses). This period provides time for honest parties to contest malicious consensus updates with Fraud Proofs.
Fraud Proofs
Consensus clients must explicitly define a fraud proof message and also implement a fraud proof verification mechanism. This mechanism would allow the client to be frozen if a valid fraud proof message is submitted. The nature of this fraud proof is discussed at length in our post on consensus proofs.
Unbonding period
The unbonding period for the consensus system must be configured correctly and this ensures a consensus client would not accept any new consensus update signed by a validator set that has been fully unstaked from the chain it’s tracking.
To learn more about the various attacks that on-chain consensus clients have to mitigate, check out this article.
Components of the implementation
A quick overview of the components of the ISMP stack.
ismp-rs
This is the rust implementation of the core ISMP specification. It provides various primitives that enable blockchain runtimes to incorporate ISMP, such as implementations of the consensus handler and request/response handler. It also describes the host requirements for a state machine to be compatible with ISMP.
pallet-Ismp
pallet-ismp is the
IsmpHost built for substrate runtimes, It acts as a wrapper around ismp-rs for substrate runtimes. It implements all the required host functions that the protocol requires, It also provides the required runtime apis and RPC apis that allows offchain components to interact with the protocol. This provides an API for pallets, and smart contracts of any kind to dispatch requests and receive responses from ISMP modules on any connected chain.ismp-evm
To enable EVM contracts deployed on Substrate to use ISMP, several components are necessary. These include a dedicated ISMP module that acts as a proxy for dispatching requests and responses to contracts on this chain, as well as a set of precompiles that allow contract access to the ISMP Dispatcher.
ismp-evm is an implementation of these components.
The EVM integration guide for
pallet-ismp can be found in the ISMP book.ismp-parachain
This contains the implementation of a parachain consensus client that allows parachains to verify the headers of selected counterparty parachains. It provides an inherent which the collators use to submit consensus messages that contain the headers and consensus proofs of these selected parachains. This inherent also provides responses to GET requests directed to the relay chain. Allowing storage reads of the relay chain and unlocking new kinds of applications on the parachain layer.
ismp-grandpa
This contains an implementation of a GRANDPA consensus proof verifier, a prover and a grandpa consensus client implementation for ISMP. These libraries enable standalone/solo chains to trustlessly interoperate with each other, parachains and also the relay chain over ISMP.
ismp-solidity
The
IsmpHost implementation for EVM environments, this allows contracts that live on EVM chains interoperate with every other ISMP supported environment. It provides interface that contracts can use to dispatch requests and receive responses from other ISMP modules on any connected chain.tesseract
The multi-dimensionalchain relayer for the ISMP stack. Built to be efficient and flexible, it achieves this by separating the consensus and general messaging relay into two independent processes allowing users to configure which process they want to run. The chain agnostic design makes it trivial to add support for more chains as ISMP adoption grows. Tesseract can be used by teams & application developers to relay ISMP messages across multiple chains.
What this means for parachain Interoperability
With the release of ISMP, parachains for the first time can establish direct connections with each other without the relay chain serving as a middleman. This greatly increases the bandwidth of messages that can be passed, eliminating the need for HRMP channels as well as relieving the relay chain of message passing. This will undoubtedly be a net positive for parachain scaling through asynchronous backing. ISMP also allows parachains read sibling parachains and relay chain state, which is currently impossible with the vanilla parachain stack.
Furthermore, ISMP opens the door for parachains to trustlessly interoperate with standalone/solo chains, stretching the reach of parachains past the core polkadot ecosystem and deep into the multi-chain.
The Road Ahead
ISMP is well positioned to become the HTTP for interoperability in multi-chain environments. To realise this vision, we are committed to expanding ISMP to more ecosystems, starting with the EVM.
Over the next few months, we will develop a variety of consensus and state machine clients to support additional ecosystems. ISMP is the most versatile and straightforward interoperability protocol for multi-chain environments.
Project Links
If you want to integrate ISMP or learn how ISMP can be useful to your product, get in touch with us on telegram.
Written by
