By 0xbrainjar

This article is a part of a series of articles discussing what Mantis believes a rollup on SVM requires. In this series, we explore the different components that we needed to architect for the Mantis rollup.

What is Finality?

Finality is an essential feature in blockchain systems: it is the assurance that a transaction will not be reverted after being added to a block. Without finality, blockchains would not be immutable—which is a major selling point of this technology.

Thus, in architecting an SVM rollup, finality was a critical concern.

IBC-Compliant Finality

Ensuring finality on our rollup is a bit more complicated than usual. This is because the Mantis rollup is IBC-enabled. The Inter-Blockchain Communication (IBC) Protocol has a number of requirements such as those described in Interchain Standards 23 and 24.

One requirement is that chains must have light clients that support state proofs in order to interoperate with IBC. State proofs serve as a verifiable mechanism for summarizing the state of a blockchain. A more technical definition of state proofs is that they are a method for succinctly proving a specific key on the blockchain ledger has a specific value (a membership proof) or does not exist (a non-membership proof). Light clients on IBC use state commitments from a chain’s verified block to verify proofs. As a result, light clients can trust key-value mapping on counterparty chains without having to trust these chains itself.

Yet, a number of blockchains such as Solana and TRON lack state proofs. The Mantis rollup is built on the Solana Virtual Machine, and thus this is a critical problem for us to overcome. So far, we have been able to come up with two solutions to blockchains lacking these IBC requirements:

1. A guest blockchain

2. Alternative proofs

In this article, we detail these alternative mechanisms for facilitating finality in a manner compliant with IBC requirements.

1. The Guest Blockchain

We have already reported upon our guest blockchain design in detail here and here. The guest blockchain was developed in conjunction with our collaborators on the research team at INESC-ID Distributed Systems Group, associated with the University of Lisbon.

To summarize, this design includes the creation of a new blockchain (the guest blockchain) that functions atop a non-IBC-compatible chain (the host blockchain). The guest blockchain functions similarly to a layer 2 of the underlying host chain, but meets all IBC requirements by implementing state proofs. Thus, the host chain is able to interoperate with the IBC via the guest chain. Initially, we have implemented this approach for the Solana blockchain.

2. Alternative Proofs

The guest blockchain solution is quite developmentally intensive, and must be customized for each chain and whatever IBC requirements the chain is missing. Thus, we have sought a means to replicate state proofs on the SVM itself (including on the Mantis rollup).  We use the following main mechanisms to deliver IBC-compatible proofs on Solana:

The Accounts Delta Hash

This alternative proof system uses Solana’s accounts delta Merkle tree. The tree stores all accounts which have changed within a particular Solana slot. This enables proof generation of an account's value whenever it changes. The commitment of the accounts delta tree (an accounts delta hash) is encoded within Solana’s bankhash which allows light clients to verify such proofs.

However, this process alone is not enough.  If an account hasn’t changed, it’s not possible to prove the account’s value.  Moreover, it is inefficient to have to create a new Program Derived Address account (PDA) for each key-value pair an IBC module might need to store.

A Witnessed Trie

Therefore, we also introduce an on-chain, witnessed sealuable trie. This is the same trie we leverage in the guest blockchain solution. This trie offers state proofs. Therefore, the only remaining factor needed for finality is this trie’s state commitment. To address this, we introduce a witness account storing state commitment that stays in sync with the trie. As a result, the trie’s state commitment is provable via the account’s delta hash.

By combining these components, we have created an alternative proof that meets the state proof requirements of the IBC. Thus, the SVM rollup is able to have finality. For more technical details on this alternative proof mechanism, reference this research forum post by Michał Nazarewicz.