Abstract
We introduce Mangata, a master-rollup interchain infrastructure for native cross-chain swaps. It leverages zero-knowledge proofs, decentralized sequencers, and two novel mechanisms for trustless cross-chain communication: proof of finality and rolldowns. The master-rollup provides a trust- and risk-minimized architecture compared to traditional bridges and avoids centralized parties or additional layers of economic security. It includes escape hatches in its framework and describes a new convenient way for users to expedite deposits: Ferries
Authors: Gleb Urvanov, Shoeb Siddiqui, Stanislav Vozarik, Tommi Enenkel, Peter Kris
Intro
Transferring value between big crypto ecosystems in a trust- and risk-minimized way is still an unsolved problem in 2023. While Layer 2 rollups are the go-to scaling solutions and have the basic bridging of tokens figured out, cross-chain transfers of value between L1s (“zones of sovereignty”) haven’t yet found their final form.
Existing cross-chain solutions rely on either centralized actors like CEXes or require additional trust assumptions like regular users having to hold bridged assets obtained from bridges. Both these solutions present risks that are deemed unacceptable by many in the long run.
Centralized exchanges are still the most popular solution for cross-chain transfers. If a user wants to send value from Ethereum to Polygon, they deposit their ETH to a CEX, swap it for MATIC, and then withdraw it to Polygon.
Despite being huge in TVL, bridges are not yet out of their incubation phase and might ultimately prove not to be the universal solution for cross-chain value transfer.
While bridge security is solved in theory, the practice looks different. 2b USD in value has been stolen from bridges through hacks in 2022. Bridges are massive infrastructure projects that essentially need to establish a bridgehead in every connected ecosystem, magnifying the risk with every additional L1 being added.
For this reason, many bridge projects opt to put decentralization in the back seat, generally by employing (albeit sophisticated) multi-sig mechanisms. This further hurts the image of bridges and allows labeling them as centralized.
Bridges add new risks and alter existing security assumptions. Rather than relying on the economic security of Ethereum, the bridge component itself becomes a potential target. The risks for bridge users are increased, while the risks for attackers decrease: if an attacker carries out a 51% attack on one of the ecosystems, it would cause economic damage to the corresponding token. On the other hand, exploiting a compromised bridge leaves the extracted value for the attacker intact.
The Problem with Bridged Tokens
Bridges are fundamentally limited, as Vitalik Buterin and others point out. If one of the L1s gets 51%-attacked, it could get rolled back and put bridged assets in question. Holding bridged tokens is at the center of the argument.
If the transfer of a token can be rolled back on the source chain, the bridged token on the target chain becomes unbacked. Bridged tokens represent a continuous risk for the user. Should a bridge hack occur, the user could lose all the value that their bridged tokens have.
It might be easy to assume that having to hold bridged tokens is a necessity, but we think otherwise. Regular users and traders should not be forced to hold bridged assets. There is no need to hold BTC on Ethereum or ETH on Cosmos, other than to trade it back and forth with other assets. No additional utility can be obtained by holding bridged tokens.
The OG Interchain: Atomic Swaps
One of the ways to exchange value between chains is atomic swaps. They allow users to securely swap an asset on one chain for an asset on another chain. Atomic swaps already have been performed between Bitcoin and Litecoin since 2017. They are one of the earliest interoperability mechanisms and could be considered as a proto cross-chain DEX.
But the more expressive second- and third-generation blockchains like Ethereum, Cardano, Solana, Polkadot, Cosmos, Avalanche & Co are still looking for an equally user-friendly solution. We argue that cross-chain exchange should be the standard instead of bridging. Users should not be forced to hold bridged tokens.
We believe the underlying motivations behind atomic swaps are great guiding principles. They provide the universal accessibility of tokens that are currently attributed to centralized exchanges while benefiting from the security, trustlessness, and decentralization that only distributed ledgers can offer.
Atomic Swaps and similar protocols allow liquidity that currently sits on CEXes to move to DeFi. Interchain settlement tears down the barriers of isolated blockchains and leads to new network effects.
Introducing the Master-Rollup Interchain Infrastructure
We’re proud to present the master-rollup interchain infrastructure, a solution for a cross-chain decentralized exchange that enables cross-chain swaps. Imagine a ZK-rollup that has universal connectivity to multiple EVMs and can coordinate transfers on those chains without the need to bridge and wrap assets in the traditional sense.
Our architecture offers an app-specific chain that is positioned as a layer on top of multiple blockchains. All tokens enjoy full L1 security. The chain has decentralized sequencing, supports cross-chain trading with native assets, provides escape hatches as a safety mechanism for traders, and thus lays the foundation for cross-chain atomic swaps.
The architecture offers these properties:
-
Decentralized sequencers - Mangata is launching with decentralized sequencers from day one.
-
Cross-chain trading with native assets - There will never be a need to hold bridged ETH in Polygon or bridged MATIC in Ethereum. Users will always be able to withdraw native assets.
-
App-specific chain - Mangata is a chain that only hosts one app: a DEX. As such, it can offer solutions that generic blockchains cannot offer, such as MEV-minimization, gas-free swaps, or proof-of-liquidity. Additionally, it does not suffer from having to share blockspace with other applications that diminish quality-of-service.
-
Master-rollup - Mangata rolls up into multiple ecosystems. It sends cryptographic proofs to all connected chains and thus enables us to have cross-chain trading with native assets and escape hatches
-
Tokens enjoy L1 security - Appchains that are only secured by their native token value are generally under significant risk. Instead, tokens on Mangata are secured by the security of their native chain. Additionally, execution correctness is secured by a re-execution chain.
-
Escape hatches - Safety mechanisms are in place to allow users to always withdraw their funds by only interacting with the base layers.
(high-resolution image)
Basic Architecture
Design Goals
The basic design goal we have solved was to construct an interchain DEX that does not rely on a bridge and the risks associated with it. Especially, we only wanted to rely on the security assumptions of the base layers and did not want to introduce or replace any security assumptions as is common with bridges.
We have arrived at a system that satisfies these requirements:
-
Allow users to deposit & withdraw assets to the master-rollup from all connected chains.
-
Allow users holding an asset to always rely on the security guarantees of the underlying L1. No security assumptions are introduced or replaced as it commonly happens with bridges.
-
Allow users to withdraw funds from connected chains that have smart contract capabilities under all circumstances.
-
The system is decentralized. It does not rely on centralized components.
The chain is assumed to be app-specific, so there is no requirement for Turing completeness.
From Single-Rollup to Master-Rollup
We achieve the stated design goals with a master-rollup infrastructure. To ensure a shared understanding, we will introduce the terminology and concepts that make up the master-rollup.
Standard Rollup Terminology
The common notion of one blockchain using the tokens and state of another blockchain is expressed in terms of layers. The blockchain making use of another blockchain is seen as sitting on top of it. A Layer 2 (L2) chain sits on top of a Layer 1 (L1) chain.
Most commonly, L2s are built as scaling solutions to make transactions on the L2 cheaper than the same transaction on the L1. Essentially, this state compression leads to lower fees. One of these mechanisms of compressing the state of the L2 for the L1 is referred to as a rollup.
The nodes that are responsible for block production by sequencing the transactions and executing them to produce state transitions on the L2 are referred to as sequencers. (for simplicity, we will not make a distinction between sequencers and provers for the bigger part of the article). Many rollups today still rely on a single sequencer and are thus generally considered to be still centralized. Mangata will use decentralized sequencers.
A core property of blockchains is that they continuously produce blocks: they maintain liveness. To ensure that users are still able to withdraw assets even if an L2 loses liveness, a fallback mechanism can be put in place that allows withdrawal directly from the L1. This is commonly referred to as an “escape hatch”.
Mangata will employ ZK-rollups. These are rollups that are based on zero-knowledge proofs. Zero-knowledge proofs are currently appreciated for allowing us to compress state and achieve performance improvements in terms of computational costs on the L1.
ZK-proofs (or just “proofs”) essentially allow us to batch multiple transactions together and prove to L1 what happened on L2. A change from a previous state to a new state is also referred to as a state transition. The writing of this state to the L1 is referred to as a state update.
External State
Rollups allow us to build and scale to L2s while relying only on the security of the underlying L1. Together they form an ecosystem. A problem occurs when we want to transact with the state and assets originating in other ecosystems like we would do when bridging tokens or doing cross-chain swaps.
In the case of transactions between ecosystems, communication between them becomes necessary. Let’s say for example that a user holds DOT and swaps it for ETH. From the perspective of Ethereum, ownership of DOT is external state information. This external state information originates from another chain, outside of Ethereum, and can thus not be proven by Ethereum.
Composing L2 state from multiple rollups
A single rollup obtains security from the L1 it is built upon. This has led to the notion that there is never a situation where it makes sense for an L2 to sit on top of multiple L1s, as a rollup cannot obtain additional security from multiple L1s. The argument is that rolling up the same state transition to multiple L1s could lead to situations where different L1s would contradict each other on such state and the L2 has to defer to the truth of only one L1. Consequently, if the L2 relies on a single L1 in such cases, the other L1s did not add to the rollup's security to begin with. Thus it is commonly assumed that only a single L1 can finalize state transitions of the L2 and verify the correct execution of the L2 rules.
This notion has to be deconstructed to discover a misconception. While most of it is true, there is a hidden assumption that all state on the L2 is a monolithic unit that can only be secured by a single L1. Instead, consider that the L2 state can be seen as a sum of all rollup states. This now opens the possibility to find more nuanced solutions that roll up the different state components of the L2 state into their respective L1s.
Master-Rollup
Mangata is a blockchain that orchestrates the state transitions of multiple rollups, thus being able to connect to multiple L1s. We will refer to this system as a master-rollup.
Through the use of ZK-rollups, we can create a system that guarantees the user that they will always be able to withdraw their tokens to the L1 they originate from. This guarantee relies on the security assumptions of the underlying L1, giving each user the choice to use the master-rollup without deferring different security assumptions. For example, Ethereum users will always get Ethereum-grade security for Ethereum-based tokens on the master-rollup.
Proof of Execution Correctness
To obtain strong security guarantees for the master-rollup, we designate one L1 that will provide proof of execution correctness of L2 rules. Proof of execution correctness ensures that the L2 rules are enforced by L1-grade security. Even if every L2 sequencer would be malicious, they could not create wrong state transitions.
Runtime & Rollups
The internal mechanics of the master-rollup design consists of these components:
-
The runtime: This is the core module coordinating block production and messaging between rollups.
-
The rollup: This module is responsible for the runtime aspects of the overall rollup mechanism, like reading its corresponding L1 state, executing rollup transactions, and proving the master-rollup state to its L1.
The runtime is deployed in a decentralized and trustless manner.
Runtime blocks & Rollup blocks
The master-rollup only operates a single actual blockchain that is distributed in the network. The rollups will maintain virtual blockchains embedded in the actual blockchain.
-
Runtime blocks are the actual blocks of the master-rollup that consist of wrapped rollup L1 handler transactions, wrapped rollup transactions, and the runtime state root, which accounts for the ephemeral rollup state and blocks in the runtime storage.
-
Rollup blocks are virtual blocks that among other things contain a rollup state root, rollup transactions, the rollup parent block hash, and rollup events.
Because we embed the rollup blocks and rollup state of the virtual blockchains in the master-rollup blockchain, only a single blockchain needs to be operated and distributed in the network.
Establishing Communication between Runtime & Rollups
Now that we have explored the two foundational components, runtime & rollups, we will address the fundamental communication challenge between them and present the two mechanisms that will allow the L1s to communicate in a trustless manner: Rolldown and Proof-of-Finality.
To communicate between ecosystems, we need to prove the state of one L1 to the others.
If a user deposits 100 ETH, this has to be read by a rollup. The rollup then needs to inform the runtime so that this state update can be put in a runtime block. Next, the user will swap their ETH for ATOM. The runtime executes the swap and notifies the corresponding rollups to update their state.
All of these activities require communication between the runtime and the rollups: Transactions executed by the runtime need to call functions from the rollup and the rollup's execution must be able to trigger function calls in the runtime.
We are essentially dealing with two problems:
-
How can we ensure the correctness of L1 state reads?
-
How can we prove runtime state finalization to the other L1s?
Solving these two problems will allow us to ensure a consistent and secure L2 state.
Additionally, this chapter features escape hatches and ferries as mechanisms that provide significant improvements to the user experience.
Correct L1 reads - Rolldowns
This chapter explains how we reliably ingest valid L1 state reads and process them into the runtime state.
In a traditional rollup scenario, withdrawals are typically processed on L1, where a verifier verifies the correctness of all L2 operations before releasing funds to the user's address. However, since Mangata operates as an interchain protocol, it enables value to cross ecosystem boundaries and be withdrawn to a different chain. This requires us to ensure the correctness of the L1 read to the runtime. For example, ETH can be swapped for MATIC and withdrawn to the Polygon network. This makes it critical to ensure that funds are correctly accounted for when entering and exiting an L1 domain.
In a single-rollup scenario, when verifying an L1 state update (”L1 write”), we can follow the chain of events since the last ingested L1 state (”L1 read”). If the previous L1 read was correct and all consecutive operations are valid, it follows that the incoming L1 write is also valid. Inversely, if there was an incorrect L1 read, all following operations have to be considered invalid. In the traditional rollup scenario, this eliminates a great range of malicious attack vectors.
In a master-rollup scenario, incorrect L1 reads pose a greater risk. If a wrongful L1 read in one domain is accepted, the polluted state could cross over into the other L1 domains via a token swap. Since the original L1 read would constitute external information there, it would not be possible to reject it during withdrawal verification in the other domain. Different L1 domains in the master-rollup have to trust that value crossing in from other domains, and by extension, all L1 reads, were correct. Therefore, the master-rollup must not allow incorrect L1 reads to be processed.
Introducing Rolldowns
We introduce Rolldowns as a solution to this problem. Rolldowns disincentivize incorrect L1 reads and prevent their eventual processing (accepting as a valid state) if at least one sequencer is honest. Similar to how rollups ensure only valid L1 writes are processed, Rolldowns ensure that only valid L1 reads are processed.
Rolldowns allow any sequencer to veto any L1 state ingestion.
To achieve this, L1 reads are not processed immediately, but instead are kept in a pending state on both L1 and L2. On L1, this state remains until a confirmation is received from L2. On L2, the pending state is held for a dispute period.
During this time, sequencers may read and write, as well as cancel pending reads. Canceling a read will remove it and any subsequent reads from the pending queue on the L2.
Game Theory of Rolldowns - One true voice is enough!
To secure the master-rollup, rolldowns are designed so that only one fair sequencer is needed. This is achieved by letting sequencers put capital at stake.
-
Sequencers have stake on L1.
-
Sequencers will have their L1 stake slashed if they are caught posting incorrect reads or unnecessary cancellations to the rollup.
-
Sequencers on Mangata form a permissionless closed set (the “active set”) elected in sessions of 4 hours in length that take turns in a pre-determined round-robin fashion to produce batches of transactions to update the L1 state.
-
To support the principle of 'One true voice is enough', each sequencer will be granted one read right and n cancellation rights per round, where n equals the number of the other sequencers of the active set.
Even if all but one sequencer acts maliciously, a single honest sequencer has the power to cancel all their reads. Eventually, an honest sequencer can post a proof of misbehavior to L1. The result would be that all misbehaving sequencers will get slashed while the honest ones will receive a reward.
Adversarial Scenarios
If a read is canceled on L2, it remains in a pending state on L1 and can therefore be read again. Therefore, even with an incorrect cancellation, an honest sequencer will pick it up and the L1 read is only delayed by a few blocks.
Following this approach, we need to consider the possibility of mass fake reads and cancels, varying numbers of colluding malicious actors/sequencers, and any combination thereof.
In extreme cases, this could potentially bring the rollup to a halt: Let’s consider that an attempt is made to read from L1 after slashing has occurred. Malicious sequencers can cancel a correct read. Given that they have already exhausted their read rights and the honest sequencer's read was also canceled, there is no one left to read from L1. In such a situation, L1 reads from this specific rollup would be temporarily stalled. Governance would intervene and force the correct L1 read. The malicious sequencers would get slashed and the rollup would be fully operational again.
L1 verified proofs of runtime finalized state transitions - Proof of Finality
How can we prove the runtime state transitions to other rollups and their corresponding L1s? Remember that state originating outside the zone of sovereignty of an L1 cannot directly be verified by the L1. Our solution needs to solve this issue in order to safely cross state from the runtime into the rollup.
We introduce proof of finality, a novel solution to this challenge. Our approach is to decompose the problem of proving the external state into two smaller problems:
-
Transactions originating from outside the rollup will be verified by the runtime.
-
The runtime will then only need to prove to the rollup that those transactions were executed as per the rules of the runtime and finalized by runtime consensus.
During the finalization of the runtime block, all transactions get re-executed to ensure execution correctness. Thus the process of finalization guarantees the correctness of state transitions within the runtime block.
Thus, if we can prove the finality of the runtime block, we prove the correctness of the state transitions of the state external to the L1.
Since the data availability for the runtime state is kept external from the perspective of the rollup, Proof-of-Finality is akin to a Validium from the perspective of Ethereum.
Additional details on the exact implementation are provided further down in this article in the “Implementation Details
Escape hatches
An escape hatch mechanism is desirable for any rollup solution. Essentially, the escape hatch allows users to withdraw assets from an L2 back to their corresponding L1 account if the rollup loses liveness.
It is dependent on the exact rollup mechanism in which network participants can act as sequencers. Restricting who may be a sequencer in a given time period is useful in controlling the conditions under which a rollup operates, such as to ensure the liveness of the updates and to reduce costs for the state transfer resulting from an update. Traditionally, this leads to a closed set of authorized participants that can act as sequencers. This authorization can, for example, be obtained by participating in Proof-of-Stake. In the instances where sequencers are unable to execute a state update and the rollup loses liveness, state updates affecting L2 and L1, such as withdrawals, become impossible.
A naïve escape hatch can be implemented by applying no restrictions on which actor can provide an update to L1. In this scenario, any network participant can function as a sequencer and provide an update. But this approach adds complexity to maintaining L2 state consistency, as it doesn't enforce consensus between sequencers and requires conflict resolution mechanisms in case several sequencers attempt to provide updates simultaneously.
In the case of Mangata’s master-rollup infrastructure, it is not possible to implement the naïve solution. Due to the challenges and solutions discussed in the rolldowns chapter, everyone wishing to become a sequencer first has to join the active set.
Our escape hatch solution instead gives any user the ability to “activate” the escape hatch in case the existing sequencers stop submitting updates to the L1.
To prevent double-spending while escape hatches are active, any operations involving the state from L1 will be paused on Mangata. A governance-forced update of the L1 state is required to resume normal operations with the L1 state. The escape hatch is deactivated once normal state transfer operations are restored following the update.
Activation of the Escape Hatch
Extended time between state updates on L1 serves as a trigger for the activation of the escape hatch mechanism. If a certain number of updates have not been provided to the L1 rollup mechanism (a contract in the case of EVM-based chains), the escape hatch can be activated by executing a corresponding transaction that can be sent by any network user. The absence of a series of updates provides a reliable indication that the L2 has lost its liveness and is no longer producing rollup blocks, as the creation and propagation of updates is a part of the normal block creation process on Mangata.
Recovery
We need to ensure that for the duration of the escape hatch being activated on L1, no operations on the corresponding state are performed in the rollup.
We need to assume that the blockchain wasn’t aware in the last valid block that it is going to lose liveness. Our first priority is to ensure that after the rollup regains liveness, it has to immediately go into the escape hatch mode in the next rollup block so that no additional operations on the rollup state can be performed.
This could be unsolvable for a traditional rollup. Thanks to finality being independent of the rollup being provided by the runtime, the rollup can independently determine the amount of elapsed time in terms of the execution chain’s blocks since the rollup was last active, and activate the escape hatch mode independent of the L1 state without any external intervention. The activation of the escape hatch mode is part of the block processing mechanism, does not require any transaction or user interaction, and cannot be omitted. Therefore, as soon as liveness is restored, it will not be possible to interact with the rollup state until the rollup regains synchronicity with the L1 state. From the application perspective, the mechanism described above allows users to withdraw their tokens from L1 even in the event of rollup shutdown, which is an essential security requirement for any rollup system.
Faster deposit times - Ferries
Because of the dispute period that is part of rolldowns, there is a delay introduced between an L1 interaction like a deposit and its successful processing in the rollup. Although the rollup cannot entirely trust all actors and the accuracy of their L1 reads, individual actors can trust their own reads and expedite the deposit for the user.
We introduce a new network actor - Ferry. They can expedite deposits from L1 to the rollup by fully backing it with their own funds, thereby assuming the risk of any economic discrepancy. We take inspiration from the concept of “liquidity providers” in optimistic rollups.
Let's consider a deposit: On L1, the deposit must have a dispute period during which other participants who have access to L1 can verify the authenticity of the deposit and cancel if it is invalid. Only after this period the rollup can confidently acknowledge the deposit as legitimate and release the funds to the user.
A Ferry, on the other hand, also has access to the L1 state and can confirm the validity of a deposit. Knowing that the funds will eventually be released by the rollup, the Ferry can independently release an equal amount of their own funds on the rollup and reclaim it from the rollup following the dispute period. The Ferry is incentivized by a commission since it essentially offers a short-term loan. This process ensures the rollup’s consistency with L1 while allowing the users to access their funds on the rollup without delay by paying a small fee to the Ferry.
Ferries present a new opportunity for fair actors to provide economic efficiency by warranting correct informational transfers with their own funds as temporary collateral. While the correctness of regular L1 reads which go via the dispute period is backed up by a sequencer's stake on the L1, for ferrying, or temporary collateralizing deposits, the exact asset type and the amount must be present. The demand for fast deposits opens up a new business opportunity for ferry providers.
Implementation Details
We will employ Starknet ZK-Rollups to make use of state compression. To get decentralized sequencing of Starkware ZK-Rollups for Ethereum on Substrate, we make use of Madara.
Tech we are building on
Mangata
Over the past 3 years, we’ve completed building the core engine of Mangata. The AMM DEX offers secure reliable trading and simple liquidity provision.
To achieve this, it needs to be a dApp sitting in an app-specific blockchain-compatible domain, have an AMM embedded design, have control of the cost structure (gas-free swaps), have MEV mitigation and encrypted transactions in the mempool, and have decentralized sequencers.
Starknet & Madara
We will first take a look at how rollup functionality can be included in Substrate-based architecture:
To generate and provide ZK-proofs to L1, we are leveraging Madara, a Starknet-compatible decentralized sequencer based on Substrate. We integrate Madara with the Mangata node by wrapping the Cairo VM within the Mangata runtime. Further modifications are introduced to achieve decentralized sequencers and remove dependency on a trusted prover.
The primary functional component of Madara is the Cairo VM - a virtual machine compatible with Starkware ZK prover. Essentially, any code executed in Cairo can be proven in a zero-knowledge way to EVM-compatible L1, like Ethereum. To leverage provability we need to mirror business logic related to L1 operations, like token transfers and swaps, from the Substrate runtime into the Cairo VM. From the user’s point of view, the code included in Cairo will execute the same set of operations as the native Mangata runtime and is required to provide a ZK proof of execution correctness of the mentioned operations. Users will in any case be communicating with the standard Mangata interface.
Since many operations executed on Mangata are not linked to the L1 state and should not be proved to any L1s connected, native logic implementation is still used for such operations. The very simple way to imagine this is to think of Cairo as a separate execution environment for dealing with EVM tokens, doing the same operations as Substrate Mangata runtime.
Blocks
Because Madara is completely embedded, state transfers created by it are part of a normal Mangata block. It includes the L2 state root, L2 transactions, the commitment of emitted Cairo VM events, and the L2 parent block hash as an L2 block (along with other relevant information). We refer to the Substrate block in which the L2 block was formed as the creating runtime block.
When a block is stored, it is intended to be read by a Starknet-compatible prover. The prover will then re-execute the block, generate the proof, and post it to L1.
Normally, this process would require a trusted centralized prover. If the prover is malicious, it can create a StarkNet block that uses L1 reads and user-signed L2 transactions as it chooses to create an L2 block. The prover can then present this block to L1, claiming it to be the latest L2 block in the canonical L2 chain. This can be seen as forking the L2 chain by a malicious prover. Our solution to this challenge is presented further.
The rollup mechanism described above can be used to connect to any EVM-compatible chain. Moreover, it is replicable within a Substrate node, allowing connection to multiple EVM L1s simultaneously, providing they are able to support the prover.
It is fairly straightforward to have a Mangata chain act as a rollup to a number of EVM-compatible chains by integrating Madara into it and replicating it for every individual rollup connection. These rollups can be used like any other rollup for efficient gas-efficient operations of a DEX, but only for swaps involving Ethereum tokens (with all value and its derivatives residing on L1).
Proof-of-Finality
To prove the finalized runtime state to a rollup, we define conditions under which a Proof-of-Finality is sufficient:
When creating a runtime block, the rollup's execution that forms the rollup block must be a part of the runtime execution and its resulting runtime state. Further, if a certain rollup block is found in the resulting state of a certain runtime block, then either that runtime block or its ancestor was the creating runtime block and that creating runtime block's ancestors were the ones that created the rollup block's ancestors. The ancestors of a rollup block are always embedded in the ancestors of a runtime block.
Thus if we prove that the resulting state of a finalized runtime block contains a certain rollup block, then we prove that not only this rollup block and its ancestors are part of the canonical chain, but also that the creating runtime block and its ancestors are part of the canonical runtime, and the runtime transactions claimed by the roll-up block and its ancestors were executed correctly and reflecting correctly on the resulting runtime state.
If these conditions are given, we can create a ZK-proof of the verification of the finalization proof from the re-execution chain. We do this because naively verifying finalization proofs on-chain on L1 is expensive.
To prove that a runtime block is finalized and contains a certain rollup block we need to
-
Acquire finalization justification data of the finalized re-execution chain block and verify all the signatures against the current validator set proving that the re-execution chain block is finalized.
-
Acquire the storage proof for the head data from the storage at the finalized re-exeuction chain block. And check it against the re-execution chain storage proof.
-
Prove that the runtime block we are interested in is an ancestor of the runtime block described by the above-acquired head data using a chain of headers, their hashes, and embedded parent hashes.
-
Prove that the storage state at the runtime block contains the L2 block (containing the L2 storage root) using the storage proof.
We anticipate that this process is very expensive to do on the Ethereum chain directly and so we intend to leverage Cairo VM again (or another ZK-proof mechanism) to perform these tasks verifiably.
We need to maintain the list of re-execution chain validators on L1, and update accordingly when it changes with the GRANDPA finalization for it.
There are two operations involved with having an L2 block accepted on L1, one is re-executing the L2 chain using the L2 blocks generating STARK proofs for the state update on L1, and the other is acquiring proof of state finality and executing them in an offchain Cairo VM generating the STARK proof of proof of state finality.
When the STARK proof for the state update on L1 is generated by the prover (either by a trigger or regularly) for an L2 block M, the prover posts it on L1. At this point, L1 marks L2 block M as pre-accepted by noting its state root and block hash. Then (or simultaneously) to generate the STARK proof for the proof of state finality, the prover reads the set of the re-execution chain validators from L1, provides it as an input along with the proof of state finality for L2 block M to an off-chain Cairo VM. The output includes the L2 block hash, state root, whether the proof is correct, the hash of the list of re-execution chain validators, and any re-execution chain validator set changes along with the hash of the updated list. When the STARK proof of the proof of state finality reaches L1, the STARK proof is verified and re-execution chain validator list hash is verified against the value stored on chain, and the provided L2 block hash and the state root is checked against the pre-accepted L2 block M. Once these checks are passed L1 marks the L2 block M as accepted.
So then at this point, we would have an L2 state that is proven, and all I/O operations until this point are proven to reflect correctly on the runtime since the state is proven and the proof of state finality claims that the creating runtime block for L2 block M was finalized on the re-execution chain.
Conclusion
The article covers the novel master-rollup interchain infrastructure, created by Mangata Finance. The benefits of native cross-chain swaps are highlighted, while the downsides of traditional bridge-based architectures are discussed. We have shown how it is possible to achieve reliable cross-rollup value transfers using proof of finality and ZKP. This way, no centralized parties or additional layers of economic security are required to achieve the goals. A number of mechanisms, such as escape hatches and rolldown, were introduced. We have presented implementation details allowing us to create the discussed architecture.
The next steps include the creation of a functional permissionless testnet which will highlight the functionality as a standalone product. It will also be used to develop integrations with third-party blockchain products, like UniswapX, and to extend and improve their cross-chain communication.
Finally, after the necessary verification and extensive security audits, Mangata will be launched as a permissionless platform for cross-chain integrations.