Ion Stage 2: Toward a General Interoperability Protocol (Part 1)

This is the first of a series of blog posts that explores the latest developments in interoperability here at Clearmatics. Follow our progress on Github and check out the rest of this blog series!

Ion

Ion is the cross-chain interoperability research project currently in development at Clearmatics. Interoperability is the ability for two or more blockchains to interact with one another. Interoperation between blockchains can take the form of simple oracle bridges that update specific information between two platforms or more general solutions that allow for many use cases to be developed.

Previously, Clearmatics released Ion Stage 1 which explored the problems associated with cross-chain atomic swaps, where we tried to make a payment between Alice and Bob across separate blockchains. Development of Ion Stage 2 was directly influenced by the issues encountered performing atomic cross-chain swaps during Ion Stage 1.

Clearmatics has a vision of a Distributed Financial Market Infrastructure (dFMI) and Ion Stage 2 is heavily influenced by this with ongoing research into the development of PvP (payment versus payment) and XvP (anything versus payment) transactions using the Ion Interoperability framework. This article will introduce the thinking and key concepts of the framework. Ion Stage 2 is a use-case agnostic framework that allows developers to build contracts that interact cross-chain using a concept called continuous execution which we introduce later.

Why another Interoperability Framework?

Interoperability between blockchains has become an increasingly important part of the growth and development of the blockchain ecosystem. Not only is it important in terms of usability, but increased interoperability between chains will also yield dividends in the scalability of blockchain projects. However, the majority of the research being undertaken in the space is for public chains. The Ion Interoperability framework is focused upon performing interoperability primarily between permissioned or private blockchains, which can have vastly different use cases, legal frameworks, and consensus mechanisms.

The Ion framework has followed and taken inspiration from many projects, including Plasma, Polkadot and Cosmos, that have been making significant contributions towards the research of interoperability. Despite this, their focus on public chains means that they are not always directly transferable into the setting of permissioned chains. Moreover, given Clearmatic’s vision of the future financial market infrastructure the institutional actors on the permissioned blockchains will likely act and be constrained in different ways to the actors on public chains.

An example of the difference between public and permissioned chains is the use of value incentive mechanisms to maintain a well behaved network of nodes. On a permissioned network, with a known user base and the ability to remove Byzantine nodes, incentive mechanisms could differ to those on public networks. Additionally the reliance on bonds, which can be slashed if a user behaves maliciously as in projects such as Plasma, is potentially not acceptable in the case of Financial Market Infrastructure as this would create excessive or undersired liquidity constraints on users of the networks.

Despite the focus on permissioned blockchains, Ion stage 2 is also built with the possibility of the integration of public chains in the future financial market infrastructure. Therefore, Ion Stage 2 designs a generic framework to allow interoperation between any type of Turing-complete blockchain.

What is Ion Stage 2?

The Ion Stage 2 interoperability framework allows general interoperation between multiple Turing-complete blockchains. The framework allows developers to build contracts that execute dependent on proofs of state transition of an external chain. This concept is referred to as continuous execution, where continuous execution is defined as:

“The ability to execute a function on blockchain A if and only if a specific state transition is proven to have occured on blockchain B.”

A generic example of this is where Alice wishes to execute function ExecuteTransaction() on blockchain B which requires that she has executed function TriggerTransaction() on blockchain A.

The sequence diagram shows a basic implementation of continuous execution:

1. Alice executes a function TriggerTransaction() on blockchain A
2. Then she generates a proof of this transaction execution
3. Proof of TriggerTransaction() is submitted to blockchain B
4. Consumption of the proof cause the ExecuteTransaction() to execute on chain B

In practice continuous execution contracts rely upon:

• submission of valid external block headers
• generation of Merkle Patricia proofs
• development of an appropriate block validation module given a specific
• consensus mechanism

However, the Ion framework abstracts the validation of external blocks away from contract developers and allows them to concentrate on designing the logic for their specific use case. The initial release of Ion Stage 2 is available on Clearmatics’ Github and currently focuses on the core function of validating and verifying the state of another chain by submitting blocks with only a simple example of a continuous execution contract.

How does Ion Stage 2 Work?

The Ion Stage 2 framework is split into three components:

• Ion Hub Contract: stores validated blocks and responsible for verification of transactions and events inside a block
• Modular Validation Contract: responsible for validation of a submitted block
• Continuous Execution Contracts: implementation of business logic that executes upon successful checking of an event in a stored block

At a high level the components of the Ion framework interact as below.

Additionally for the Ion Interoperability Framework to function we assume:

• The Validation module contracts are implemented to a level where users can safely rely on blocks that are validated

The above assumption means that any blocks that are persisted by the Ion hub are valid on the chain being interoperated with. Though the way in which blocks are validated by a module can vary depending on implementation.

The Ion hub contract is the centre of interoperability on an individual blockchain and is the interface for all continuous execution contracts on a specific chain. Block validation modules and individual continuous execution contracts are independent and will have multiple implementations for each consensus mechanism being used and uses case required.

Any blocks that are submitted to the Ion hub contract through a validation module can then be used to verify transactions from an external chain. Continuous execution contracts must then make assertions against any valid blocks, as shown in the diagram above. Thus if the block is indeed valid we can safely execute our contract knowing the conditions required have actually been fulfilled on the external chain.

For a more detailed description of the Ion Stage 2 architecture and implementation specification please check the Ion wiki.

Conclusion

This was just a brief overview of the interoperability research currently being undertaken here at Clearmatics. Continuous execution is the high-level mechanism through which Clearmatics hopes to implement interoperability between mutliple chains. Having introduced the concept of continuous execution in this article, future publications will detail the core components underpinning the Ion Interoperability framework — including the Ion hub contract, block validation module, and Ion framework contract design.

Research is ongoing and in the near future Clearmatics is working to understand how end users will interact with the Ion framework, improving the threat model and developing additional use cases.

Please stay tuned for more information on our Medium publication and in the meantime please take the time to review Ion Stage 2 on Github and let us know your thoughts!

Friedrich Grabner, Blockchain Engineer, Clearmatics
Chris Chung, Blockchain Engineer, Clearmatics
Duarte Aragão, Senior Blockchain Engineer, Clearmatics

Tweet us @Clearmatics