By 0xbrainjar
This article is a part of a series of articles discussing what Mantis believes an SVM rollup on Solana requires. In this series, we explore the different components that we needed to architect for the Mantis rollup.
Summary
True rollups are able to deliver the same security guarantees of their underlying L1. Without this characteristic, the Mantis rollup would simply be a sidechain and it would not inherit the security of Solana. This would have meant we would have needed to bootstrap our own security system. Instead, we implement all rollup requirements into the Mantis L2, including censorship resistance and forced withdrawals.
In this manner, the Mantis rollup is able to leverage the significant security of the Solana ecosystem immediately upon rollup launch.
Security on Solana
The Solana ecosystem offers many benefits. One key advantage of Solana is how well secured it is. This security is implemented via proof-of-stake (PoS): users stake assets to validators to provide crypto-economic security for the network.
Staking is massively popular on Solana. At the time of writing, 65% of SOL tokens (approximately 305 million SOL) are staked (source). This is around $43.7 billion worth of tokens - providing a significant amount of security for Solana. Accessing this security is one of the many reasons why Mantis chose to build a rollup on Solana.
Rollup Requirements
There are two main processes that must be upheld for an L2 to derive the same security as its L1 and be considered a rollup:
-
Censorship Resistance: Rollups implement censorship resistance by implementing rollback based on the L1. Rollup blocks are validated by their L1. If the L1 says the transaction is invalid and does not accept the transaction, the rollup rolls it back. This guarantees that nodes executing L2 transactions cannot prevent user transaction submissions - as blocks from L2 must match those on L1.
-
Forced Withdrawals: Rollups enable forced withdrawals from the L1 using the L2. This is critical in preserving users’ assets in the event that the L2 stops running. This is made possible because a rollup relies on the consensus of the underlying L1. Specifically, the state root can be used to make a forced withdrawal from the rollup to the L1 if the L2 goes down.
Meeting These Requirements on Mantis
Here’s how Mantis is able to meet the above two rollup requirements and leverage the security of the Solana L1:
-
Censorship Resistance
Mantis L2 transactions will be submitted on the L1. Thus, transactions cannot be censored at the L2 level and the Mantis rollup inherits the censorship resistance of the Solana L1. To facilitate this, we need there to be a way Solana can force the Mantis rollup to execute a transaction. We will accomplish this by making the Mantis rollup finality contingent upon IBC light client updates. Specifically, the IBC light client we have created on Solana will be able to reject updates even if it is valid according to the L2’s protocol. If there are valid transactions sent through the Mantis rollup, Solana will accept client updates only if they have proof that these valid transactions have been executed.
-
Forced Withdrawals
On Mantis, forced withdrawals will be facilitated by having Solana maintain the balances of accounts on the rollup. Solana will not have to replay the entire rollup history as it can use transaction and state proofs. This feature, in combination with the previously described light client update rejection mechanism, allows forced withdrawals: the light client on Solana can give assets to users without waiting for confirmation on the L2 that assets were burnt there. We address concerns of double spending here by introducing a long delay where Solana can confirm the Mantis rollup is nonfunctional.
Further Readings
Additional details on how and why Mantis implemented censorship resistance and forced withdrawals have been discussed by Michał Nazarewicz in the Composable Research Forum post here.
A good primer of sidechains and rollups (and how each uses the L1) is available by Infura here.