DLT Interoperability and More ⛓️#25— Cross-Rollup Communication Protocol⛓️
In this series, we analyze papers on blockchain and interoperability.
This edition covers a paper that proposes a protocol for rollups on different chains to communicate.
➡️ Title: Cross-Rollup Communication (CRC) Protocol
➡️ Authors: Limechain
➡️ Paper source: https://limechain.notion.site/Cross-Rollup-Communication-CRC-Protocol-Extended-7a10883e7847493dbe9f4ca421976983#ed2749983ff544228a985f9498e30e39
➡️ Background:
Rollups are layer-2 systems that allow the scalability of networks, namely, increase their throughput. By offloading transactions from the source chain, the amount of computation is reduced; therefore, the throughput can increase. Conceptually, layer-2 systems are sidechains, where an external system (typically blockchain-like, but not necessarily) performs the offloaded computation, bundles several transactions together, and communicates them back to the original blockchain, typically as a single transaction. These tasks are executed by actors called sequencers. The specifics of the roll-up protocol dictate how secure it is (is the offloaded computation properly executed and valid? are the economic guarantees of the project design such that a roll-up participant is not incentivized to cheat?) and how scalable they are.
Rollups derive their security from slower (and more decentralized) source chains, i.e., the source of truth is the state of the source chain, which the rollup operators regularly sync.
Of course, the processes behind the functioning of a roll-up imply interoperability between the source chain and the rollup and, as this paper proposes, across rollups. There are two families of rollups — Optimistic rollups (OR) and pessimistic rollups, e.g., zero knowledge rollups. From the paper, “On a high level, the Optimistic roll-ups take an “innocent-until-proven-guilty” stance. Once a rollup data (called block) is posted to the L1, it is considered valid. However, a grace period exists where any actor can post proof of fraud — fraud-proof.
ZK roll-ups take the reverse “invalid-until-proven-otherwise” stance. Rollup blocks are only finalized on L1 once a validity proof is posted. This proof is usually in the form of ZK proof, hence the name of the rollups.”
Onto the paper!
➡️ Motivation:
Why do we need bridging and possibly other cross-chain applications across rollups instead of layer-1s? Rollups are fundamentally different and have different properties (please check this great resource on comparing rollups). Now, if you already have your funds in a rollup, to take them out, you might need to wait a considerable amount of time (Polygon Hermez introduces a 7-day delay, while Immutable X can take up to 14 days). What if you could securely bridge your rollup tokens across rollups without 1) waiting, 2) paying fees at least twice (withdrawing roll-up funds from the first rollup and load funds into the second roll-up). If bridging tokens needs to be done you might need to perform 1 or 2 transactions, depending on the bridge.
➡️ Contributions:
- A permissionless protocol for cross-rollup communication.
💪 Strong points:
- Timely tackling of a very relevant problem, especially because the industry is finally moving toward enhancing the user experience of products like rollups to the end user.
🤞 Suggestions for improvement:
- A more detailed comparison of the cross-rollup communication problem with the bridge problem could help clarify if the solution space is conceptually different or not. According to the authors: “In a sense, the problem of CRC can be boiled down to the destination rollup having an on-chain light client of the source rollup.”, which is a subset of the bridging problem.
- There are no considerations on what the relayer fees are or what is the cross-chain throughput or latency, which would be important to compare this solution to others systematically.
🔥 Points of interest:
From the paper “Ethereum’s focus on light clients was showcased with the Altair hard fork where the system introduced a “sync committee” and a protocol called “sync protocol”. As stated in the specification, this is a committee of 512 Ethereum Proof-of-Stake validators that are randomly selected every sync committee period (~1 day). While a validator is part of the currently active sync committee, they are expected to continually sign the block header that is the new head of the chain at each slot.
The purpose of the sync committee is to allow light clients to keep track of the chain of the consensus block headers. Block headers can be used to verify claims of a given state (e.g, account balance or a contract’s state) since they represent the state of Ethereum.
In order for an Ethereum light client to trust the block headers sent to them through a full node, they can check if at least 2/3 of the sync committee validators have signed the header.
The Ethereum Light Client mechanism is important for the research, as being able to verify the state of Ethereum inside a rollup will mean, by proxy, that the rollup is able to trust the state of any other rollup connected to Ethereum.”
- This means that a rollup will trust another rollup because the latter is doing computation using the same verifiable source of truth (in this case, the Ethereum network).
- The protocol: “Protocol for data transfer between Ethereum rollups, based on Computational Integrity (SNARK/STARKs) proving the state of Ethereum inside the destination rollup and acting as an on-chain Light Client.”. This protocol would rely on a SNARK-based light client, such as the one we are actively developing. The data transfer part of the protocol is then similar to IBC or even SATP (our attempt to standardize asset transfers between centralized and decentralized systems), defining what the message flow and format that relayers send to each other, resource identifiers, security considerations, and so on is.
- Architecture:
The flow of operations of the CRC protocol has four stages: Initiation, State Relay, Delivery, and State Relay Payment.
First, “the user triggers message transfer through the CRC protocol (in the whitepaper’s example, an asset deposit on a bridge, for more, see the lock-unlock mechanism, page 14 onwards). Normally, this is done with the intent to perform some business logic operation across rollups”. In the state relay phase, relayers monitor the L1 contract that “rolls up” the state of the source rollup, akin to how a relayer would monitor a bridge contract for deposits. Once one has been detected, the relay creates a light client SNARK of the L1 and provides it to the SNARK verifier deployed on the target rollup. The SNARK is verified, and, by transitivity, the source rollup state is verified as well (because its state is pegged to the L1, and the SNARK the relayer created accounts for the current validity of the L1 state). This process can be incentivized with a fee model for better decentralization.
After the state of the source rollup is validated on the target rollup (I will not go into details here, but it is verifying a SNARK if the SNARK captures the EVM runtime, or verifying a SNARNK + a Merkle proof, in case the SNARK just validates the new minted blocks on the source chain), minting a representation of the tokens locked on the state rollup can happen (requested by the user, which provides the Merkle proof).
After that, the relayer collects its fees (it proves it relayed messages by providing a Merkle proof of the transaction inclusion on the rollup contract).
🚀 What are the implications for our work?
- The proposed protocol is a good example of protocols that can be built on top of our ongoing work. A scalable protocol, it allows developers to integrate their roll-up apps with other rollups, bringing up a cross-rollup marketplace.
