# Cross-Rollup Forced Transactions - Introduction *Thanks to Kobi Gurkan, Luozhu Zhang,* ## Content - [Introduction](#Introduction) - [Motivation](#Motivation) - [Comparison with other architectures](#Comparison-with-other-architectures) - [L2s in a shared prover](#L2s-in-a-shared-prover) - [L3s on an L2](#L3s-on-an-L2) - [Celestia and Sovereign SDK](#Comparison-to-Celestia-and-Sovereign-SDK) - [High level technical overview](#High-level-technical-overview1) - [Core Components](#Core-Components) - [Flow](#Flow) - [L1 settlement](#L1-settlement) - [Properties](#Properties) - [Summary](#Summary) ## Introduction Cross-rollup interoperability is a crucial part of scaling Ethereum. In particular cross-RU asynchronous atomicity, i.e. forced transactions would provide the best achievable interoperability between RUs (given that synchronicity is not possible between RUs with distinct validator sets). Existing architectures such as L2s do not solve this problem, as forced txs have to go through the expensive L1. L3s partially ease this problem, as the L2 is cheaper than the L1, but this does not work between L2s, and ultimately the L2 will still be a bottleneck. The path for cross-rollup messaging is state proof bridges, as described for example [here](https://era.zksync.io/docs/dev/fundamentals/hyperscaling.html) or [here](https://vitalik.ca/general/2022/09/17/layer_3.html). Ideally we would make these state proof bridges atomic. The way to do this is to utilise the DA layer, as described [here in Celestia](https://arxiv.org/abs/1905.09274): X-RU txs can be recorded and read from the DA layer. By adding ZKPs (like [Sovereign Labs](https://github.com/Sovereign-Labs/sovereign/blob/main/core/specs/overview.md)), the RUs can prove both that valid txs are sent, and that they are consumed in the receiving RU. Ethereum's DA layer is already on the [roadmap](https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1). This does not yet enable the last component of the Celestia vision: scalable X-RU atomic interoperability. To make this work securely we need a new architecture. This architecture needs to combine the DA layer, the shared proof, the state of the RUs, the X-RU txs, all in a scalable way. ## Motivation Why do we need cheap forced transactions? - First and foremost cheap forced txs are a security question. If a user has a small amount of funds in an L2 and the RU starts censoring transaction, then they can only access the funds via expensive forced tx through the L1. In this case the user effectively lost their funds, as it will not be worth it for them to save the funds. - The alternative approach to forced transactions is Censorship Resistance of L2s. This is a good intermediate step, it would mean making the L2's sequencer set and the locked stake large. With this approach, we can trust some of the L2 sequencers to not censor our tx. However, this is expensive as it requires lots of capital and a redundancy in the sequencers. So forced transactions allows easier bootstrapping of new rollups. - Finally in this context, forced transactions are equivalent to atomicity, a tx on one chain implies a tx on another chain. So we can say that this is also a UX problem for the users, they will not have to send different txs on different RUs to bridge. With cross-rollup forced transactions, the UX of bridging will be great: cheap, fast, atomic, secure. ## Comparison with other architectures ### L2s in a shared prover Multiple L2s inside a shared prover (e.g. [Starkexes](https://docs.starkware.co/starkex/architecture/solution-architecture.html)) are the simplest architecture for organising multiple RUs. Here a single RU is [applicatively recursed](https://www.starknet.io/en/posts/developers/recursive-starks) in a certain time frame, then these proofs are aggregated across rollups in a shared proof. This shared proof is published on L1. Here forced transactions have to go through L1, which is expensive. It is also slow, the txs can only be consumed once the shared proof is published on L1. ### L3s on an L2 Here the situation is similar to the previous one, just pushed up one layer, but this leads to big differences. Instead of verifying proofs on L1, we can verify them on L2, either with or without a shared proof. Then forcing txs through the L2 is much cheaper than on L1. It is also faster, as settlement of the L3s on the L2 can happen more often than of the L1. It is ultimately not scalable however, as the L2 will also have a txs bottleneck. It is also less secure, as an L2 is less secure than the L1. ### Comparison to Celestia and Sovereign SDK The combination of Celestia and [Sovereign Labs](https://github.com/Sovereign-Labs/sovereign/blob/main/core/specs/overview.md) is a workable method, with an emphasis on sovereignty rather than interoperability. Both of these protocols are still heavily under [development](https://forum.celestia.org/t/achieving-base-layer-functionality-escape-velocity-without-on-chain-smart-contracts-using-sovereign-zk-rollups/958?u=kelemeno), so this comparison might already be outdated. Given Celestia (a scalable DA layer), the Sovereign SDK would allow RUs to use the DA layer for sequencing (using [Named Space Merkle trees](https://celestia.org/glossary/namespaced-merkle-tree/)), enable them to scan the DA layer for these txs (including X-RU txs), prove using a ZKP that this scanning happened, and with a further ZKP the new state of the RU based on these txs. After this the RUs can verify each others proofs' (perhaps aggregate the proofs for efficiency), and based on these verify and process the X-RU txs. Here the problem is interoperability of the systems. The [Sovereign SDK](https://github.com/Sovereign-Labs/sovereign/tree/main) does not have a standard VM or a standard prover, they are merely providing a framework for these. Furthermore they will not have universally accepted state such as an L1, each RU will have to keep track of other RUs they are bridging with. This results in a patchwork of pairwise bridges between the RUs, instead of a unified ecosystem. In comparison the idea of [hyperbridging](https://era.zksync.io/docs/dev/fundamentals/hyperscaling.html#logical-state-partitions) is that a single VM and proof system are shared across RUs. These RUs settle in a common smart contract on L1 which hosts each RU's enshrined bridge and a common pool of funds. These funds can then be seamlessly transferred across the RUs. With this in mind our architecture will focus interoperability and have a single set of trust assumptions: a single standard VM, a single proof system, and a single enshrined shared proof. This will lead to other differences, such as separation of the X-RU txs from the normal txs, we will not have to use the DA layer for sequencing, and we will not have to prove that we scanned the DA layer. ## High level technical overview ### Technical details high level summary More details [here.](https://hackmd.io/@kalmanlajko/HyKxykOao) #### Core Components - DA layer, with its DA commitment - zk Rollups - Shared State Commitment, = ShSC, recording the state commitment of each RU - Shared Tx Commitment, = ShTxC, recording the X-RU txs - Shared Proof, = ShP, proves the current state of the system (the ShSC and the ShTxC) #### Flow 1. A RU running a zkEVM with its own PoS consensus mechanism creates some blocks, and proves them. This proof contains as public inputs the state diffs, the sent and received transactions to other L3s, all combined in a DA blob (unlike the traditional L1, L2 architecture, where only the state diffs are in the DA blob). 2. The blob is dumped on the DA layer. Other RUs will be able to read the sent txs from here. This means the consensus mechanism of the DA layer accepts a block containing the blob. 3. The Shared Proof can now be constructed. It consists of two layers, the *Base Proofs* that verify the proofs of the RUs, and the *Recursive Proofs* that aggregate these proofs. 1. For each RU a base proof verifies a smart contract similarly to how an L2's proof is verified on L1 today. To make this scalable, the smart contract has no permanent state, this is stored in the Shared State Commitment and Shared Tx commitment, these correspond to the current L2 state and the L2<>L1 txs stored on L1. The smart contract also needs the DA commitment as an input. This smart contract verifies that the DA commitment has the blob. It also verifies the proof contained in the blob, comparing it to the state of the RU inside the ShSC and ShTxC. A new commitment for the state and txs is an output (public input) to the proof, alongside the initial shared commitments and DA commitment and the blob's commitment. 1. Then the base proofs are aggregated in the recursive proofs. The used DA commitment, ShSC and ShTxC are checked to be the same in each recursive proof, and the State Commitments, and Tx Commitments, data blob commitments for each RU are aggregated across the recursive proofs. When fully aggregated, the State Commitment and Tx Commitment will become the ShSC and ShTxC. The final recursive proof proves that the DA blob updates the ShSC and ShTX. These will be used in the next round of the shared proof. To make sure that the shared proof is censorship resistant, the combination of the used DA blobs should match the original DA commitment (this is an implicit scan of the DA layer). 4. When the shared proof is finished the shared proof can be verified on the L1. #### L1 settlement Up to this point we didn't mention L1 settlement of the Shared Proof. The system has to be backward compatible with Ethereum L1 and [DA layer](https://notes.ethereum.org/@dankrad/new_sharding). This would effectively make this system an L2. When settling to L1, the shared proof of each DA block can be further aggregated. This aggregated proof can be sent to L1, outputting the used DA commitments, and the new ShSC and ShTxC. L3s will have the same right to join and exit this system as they had in the more traditional L2<>L3 architecture. We will be able to force txs from L1 to the L3s. We can also use the traditional non-atomic L2<>L3 messaging. ### Properties - Fast, cheap and atomic messaging between RUs - Settlement on L1 can be less often, as the Shared Proof allows aggregation. This makes the system cheaper - Backwards compatible. The solution allows an easy and secure way for existing dapps, users and funds on L1 to migrate. ## Summary We will want cheap cross-rollup forced txs. This is a security and UX question for users, and makes bootstrapping new rollups easier. We can achieve this by using the DA layer and a specialised Shared Proof, proving the transitions between Shared State Commitments and Shared Transaction Commitments. We outline in very broad terms the architecture of such a system. The result is also backward compatible. I describe the technical details [here](https://hackmd.io/@kalmanlajko/HyKxykOao).
Last changed by  
 
Kalman Lajko
2336

Read more

Slush, a proposal for Fractal scaling

2023, Edit: this construction is primarily a thought experiment showing the possibility for linear scaling, in a model where every RU is responsible for their own data. In practice the DA layer will allow the RUs access to each others data, and has great scaling properties, even if it is not linear, but \sqrt{N}, in the total number of light clients.

6/22/2023
WIP

Thanks to Kobi Gurkan, Luozhu Zhang,

6/20/2023
Research on fast cross-rollup messaging and settlement inside recursive proofs

I welcome all feedback, escpecially if it's negative! TLDR By importing the L1 state root and a corresponding state proof ZKRollups can have trustless bridges. This solution is cheap, however, it is slow, as the sending rollup needs to settle on L1. If we import the sending rollup's block hash directly, then it is risky. The best of both worlds happens when the rollups are settled to L1 using a shared proof aggregator mechanism. In this case it is possible to make the messaging faster, by accepting block hashes when they are settled inside this aggregator, and settlement here will also take care of messaging. There is a risk here if the proof aggregator fails. To decrease this risk, we provide an "intermediate proof" construction. These intermediate proofs are not settled on L1, but can be used to do so in case of an emergency. Intro to the post

2/18/2023
Societal reputation system

Here we are thinking about a reputation sytem for very big, general topics, that are hard to assess algorithmically, and need a more subjective and local assessment. Intuition behind reputation system There are different kinds of reputations for different use cases. From Uber rating, to the number of Twitter followers to politicians receiving some number of votes, these all confer some kind of repuation. What kind of repuation system do we want to build? Lets quickly have an overview of different reputation systems. Uber model Here Drivers and Riders are rated from 1-5, the ratings are averaged to give an average score. Here 1 is understood to be a bad rating, while 5 is good. This is a rating method used to evaluate a very simple thing, how good of a Driver/Rider the person is. This rating system is not a societal rating, it is based on one-off encounters which all conform to a very constrained segment of life. Twitter model In the twitter model, each person can follow other people, and can follow as many other people as they want to. In contrast to the Uber model, this model can be characterised as a societal repuation score, as people from differnt avenues of life (from politicians to scientists) all use Twitter, and their follower count can be directly compared.

9/19/2022
Read more from Kalman Lajko
Published on HackMD