I feel anxious about current state of rollup evolution. No, it’s not about rollups’ training wheels or too high fees. I’ll talk about why we don’t feel Ethereum when we’re on rollups. Why don’t we feel the breathtaking massiveness and solidity (no, not that one) of Ethereum that we all felt when it all was on L1, regardless of whether you were here before bullruns or survived from fees after.

You could probably argue, “But I feel!“, and I'd be almost one hundred percent sure that you’re either on Arbitrum or Optimism. And I know exactly why.
If you’ve ever paid for something with crypto, payment provider that were sent to probably only supported Ethereum, Arbitrum and Optimism. It was once, twice, couple times, certain dapp that you wanted to interact to also had only these three, one of which isn’t suitable for you because of huge fees. Your friend probably once wanted to send you some ethers to pay you back but couldn’t because they were on Optimism and you were on Starknet or Loopring or, most likely, Ethereum L1. Screwing with bridges wasn’t an option because one of you were in a hurry or just not techy enough. You decided that there’s no point to be in a niche platform and suffer from all these difficulties and switched to one of those rollups. Natural monopoly grows.

Have you ever wondered why do you even have to choose between Ethereum, Arbitrum, Optimism, Base, zkSync, and tons of other rollups when you select a network in your wallet or payment gateway, if they all, in fact, should be Ethereum itself, just scaled? By that logic you should have just chosen “Ethereum” in pop-up and started doing whatever you needed to do. But in reality the only thing the rollups have in common is security assumptions of Ethereum. From the point of user experience, rollups are same as alt-L1 networks, so many people just don’t see any reason in using rollups instead of alt-L1s, if they also have less liquidity and smaller ecosystem than Ethereum (and not that much less), but are still cheaper to use.

“But is there anything we can do about it? Rollups are actual separate blockchains and only nest on the same L1, Ethereum” - Yes. We really underestimate the power of nesting on the same network. Here’s what we can do with it: Unstoppable cross-rollup messaging.

All existing cross-chain or cross-rollup messaging protocols are either custodial or rely on its own consensus to work. Needless to say that we have Ethereum L1 that can help us to get rid of them. The simplest one - Send L2→L1 messages and forward them to destination L2 through L1. Forwarding full data through L1 is expensive asf, but, for example, we can send only a hash of data and send the data itself some other way. The point is that this is completely possible, and L1 can greatly help us with this.

What is the practical use of cross-rollup messaging? Let me show a few examples:

Cross-rollup transfers

What comes to mind first - we can send money between rollups by transmitting ETH to a “bridge“ with instructions of how much of them transfer to whom (in case of ether).
If we talk about ERC20 tokens, we can lock natively bridged asset from one side and send natively bridged version of the same asset on another side. Then, when one of endpoints runs out of this asset, we execute reallocation of assets through L1. That’s the case with assets that have its natively bridged version on all rollups, e.g USDC.e on Arbitrum and USDbC on Base.
In a case of assets that exist only on one rollup, we can provided wrapped versions of them. In my opinion, wrapped asset that is ran by smart contract on L2 and controlled by controller contract on L1 is safe enough, if we assume that all smart contracts contain no vulnerabilities.

But only transfers are not enough, because we could also want to interact with other rollups’ ecosystems entirely. And here’s what we can do about it:

Stay in one chain, use all chains

Let’s imagine that I have an account on zkSync Era (I’ll take it because it has built-in account abstraction, keep it in mind). I want to interact with Uniswap on Arbitrum.

Status quo
To do it, I need to switch the network to Arbitrum or create new account if my wallet is chain-bound and top up my new account on Arbitrum with ETH either via bridging from my existing wallet, or asking someone for some. Then, if I want to use some of my funds from my existing zkSync wallet on Uniswap on Arbitrum, I need to bridge them too. After bridging it’s also worth to revoke all approvals, because my first wallet probably contains if not my life savings then at least more funds that I wanted to spend on this cross-rollup adventure.
After doing everything I needed to do on Arbitrum, I need to bridge received or remaining funds back to zkSync and change the network or wallet back. To be honest, even writing this part made my eye twitch.

How can it look
To do it, I firstly connect my wallet to a dapp's frontend. Wallet backend can edit contents of dapp calls to itself (e.g if it asks for USDC balance on Arbitrum, return USDC balance on zkSync) to make dapp frontend work without changing the chain in wallet settings. Then wallet backend checks if there’s its proxy contract on Arbitrum, and if not, requests its deployment.
When dapp requests transactions (or, to be more precise, I make something that initiates transaction, e.g swap or approval), wallet backend checks if there are any interactions with token allowance, and if there are, bridges required amount of tokens from itself to proxy on Arbitrum, then sends proxy transaction request to the controller on Arbitrum. After everything is made, wallet backend can either leave remaining funds in proxy or bridge them back.
From the point of view of user experience, it looks like that: I connect my wallet, see all my funds in the dapp’s frontend although they technically don’t exist in this chain, initiate a transaction, confirm it, done. Everything looks like I’m on my native chain.

Sounds nice! You don’t have to deal with tokens on different chains, find gas on these chains, etc, now all this mess can be easily abstracted away on UX.

But why should we keep our main wallet in one chain? Now it all sounds like overcomplicated paymaster system that allows us to get rid of gas mess, but for some reason also connected to some main wallet. This is where account abstraction comes in.

I’m writing this article in a “language” that, if you understand it, you should already know what AA is. But i’ll explain it anyway.
Account abstraction is a technology that allows you to use smart contract as a normal wallet. This is useful for customizing your wallet or adding arbitrary logic in it. For example, you can authorize some of your trusted people to reset access to your wallet in case you lose your phone or someone steals your seed phrase. To decrease losses from potential hack, you can set up daily spending limit. Basically AA allows you to program your wallet and possibilities are only restricted by possibilities of your programming language.

And how does it matter in our case? - With that cross-rollup interaction logic you can, in fact, use your single wallet with all its funds, customizations and security settings in all existing rollups. If you create a new EOA each time you interact with new rollup, it does not inherit all these things. If you use a single AA wallet in all chains, your funds in all these chains are as secure as funds in your wallet’s native chain and follow same spending rules.

Why hasn’t anyone done this yet

The reason is terribly simple.

L2→L1 messages follow same proving rules as rollup batches. It means that, if it takes 24 hours to prove the batch, then the message will either be sent or be secure to consume only after 24 hours. To make such cross-rollup messaging system, it needs to be fast enough. Batches should be proven within several minutes. How far are we at the current point?

Well, with ZK rollups we’re, in fact, done. Despite the fact that some of ZK rollups’ devs intentionally delay batches proving for bug hunting purposes (for example, zkSync Era validator proves batches after 24 hours after their submission), ZK rollup batch is proven as soon as anyone generates a proof to it and executes it on L1. When zkSync and other rollups open proving to everyone, it will become much faster and eventually will fit in a couple minutes.

With optimistic rollups it’s more complicated. Two most popular rollups on Ethereum, Arbitrum and Optimism, are optimistic, and they’re quite far from even opening proving to everyone. Arbitrum has fraud proving system, but it can only be ran by whitelisted entities. Optimism develops Cannon, but it’s not ready yet and will take long time until it ships to mainnet and becomes permissionless to use.
Even when they will open fraud proving to everyone, challenge time should be long enough to prevent massive DoS attacks against provers and other attacks aimed at taking provers down. Now it’s 7 days in both Arbitrum and Optimism.
In decentralized future, I don’t see realistic challenge time as less than 1 hour. Though I’m not an expert in optimistic rollups and may be wrong. If you’re interested in it, I’d recommend to read something from optimistic rollups developers.

However, all is not lost. For example, OP Labs is now looking at ways to ZK prove outputs of Cannon fault prover. I didn’t understand much from this topic, but as far as I understood, OP Labs wants to make system that allows (not forces) network participants to create ZK proofs of Cannon output on certain batch and send it on chain to immediately prove this batch without waiting for the challenge time to end. This may help Optimism to join us on the way of connecting Ethereum back.

In general, I would say that the problem of interconnecting rollups comes from decentralization sacrifices in favor of setting up training wheels.
And I totally understand it. If you build a system that is expected to handle billions of dollars and move huge elements of current financial system to itself but still don’t have any recovery guarantees from your settlement layer, it’s extremely hard and expensive to develop such things fast, efficient and straightaway decentralized.

I would like to thank all developers that work on Ethereum rollups and rollup ecosystem. You are those who move an entire industry forward and help us all to change the world to better. No matter if you’re CEO, team lead or simple coding plankton working on some small part of your project. You matter.

Thank you for reading.

I spent 2x more time to fix all writing mistakes than to write this article lmao

I feel anxious about current state of rollup evolution. No, it’s not about rollups’ training wheels or too high fees. I’ll talk about why we don’t feel Ethereum when we’re on rollups. Why don’t we feel the breathtaking massiveness and solidity (no, not that one) of Ethereum that we all felt when it all was on L1, regardless of whether you were here before bullruns or survived from fees after.

You could probably argue, “But I feel!“, and I'd be almost one hundred percent sure that you’re either on Arbitrum or Optimism. And I know exactly why.
If you’ve ever paid for something with crypto, payment provider that were sent to probably only supported Ethereum, Arbitrum and Optimism. It was once, twice, couple times, certain dapp that you wanted to interact to also had only these three, one of which isn’t suitable for you because of huge fees. Your friend probably once wanted to send you some ethers to pay you back but couldn’t because they were on Optimism and you were on Starknet or Loopring or, most likely, Ethereum L1. Screwing with bridges wasn’t an option because one of you were in a hurry or just not techy enough. You decided that there’s no point to be in a niche platform and suffer from all these difficulties and switched to one of those rollups. Natural monopoly grows.

Have you ever wondered why do you even have to choose between Ethereum, Arbitrum, Optimism, Base, zkSync, and tons of other rollups when you select a network in your wallet or payment gateway, if they all, in fact, should be Ethereum itself, just scaled? By that logic you should have just chosen “Ethereum” in pop-up and started doing whatever you needed to do. But in reality the only thing the rollups have in common is security assumptions of Ethereum. From the point of user experience, rollups are same as alt-L1 networks, so many people just don’t see any reason in using rollups instead of alt-L1s, if they also have less liquidity and smaller ecosystem than Ethereum (and not that much less), but are still cheaper to use.

“But is there anything we can do about it? Rollups are actual separate blockchains and only nest on the same L1, Ethereum” - Yes. We really underestimate the power of nesting on the same network. Here’s what we can do with it: Unstoppable cross-rollup messaging.

All existing cross-chain or cross-rollup messaging protocols are either custodial or rely on its own consensus to work. Needless to say that we have Ethereum L1 that can help us to get rid of them. The simplest one - Send L2→L1 messages and forward them to destination L2 through L1. Forwarding full data through L1 is expensive asf, but, for example, we can send only a hash of data and send the data itself some other way. The point is that this is completely possible, and L1 can greatly help us with this.

What is the practical use of cross-rollup messaging? Let me show a few examples:

Cross-rollup transfers

What comes to mind first - we can send money between rollups by transmitting ETH to a “bridge“ with instructions of how much of them transfer to whom (in case of ether).
If we talk about ERC20 tokens, we can lock natively bridged asset from one side and send natively bridged version of the same asset on another side. Then, when one of endpoints runs out of this asset, we execute reallocation of assets through L1. That’s the case with assets that have its natively bridged version on all rollups, e.g USDC.e on Arbitrum and USDbC on Base.
In a case of assets that exist only on one rollup, we can provided wrapped versions of them. In my opinion, wrapped asset that is ran by smart contract on L2 and controlled by controller contract on L1 is safe enough, if we assume that all smart contracts contain no vulnerabilities.

But only transfers are not enough, because we could also want to interact with other rollups’ ecosystems entirely. And here’s what we can do about it:

Stay in one chain, use all chains

Let’s imagine that I have an account on zkSync Era (I’ll take it because it has built-in account abstraction, keep it in mind). I want to interact with Uniswap on Arbitrum.

Status quo
To do it, I need to switch the network to Arbitrum or create new account if my wallet is chain-bound and top up my new account on Arbitrum with ETH either via bridging from my existing wallet, or asking someone for some. Then, if I want to use some of my funds from my existing zkSync wallet on Uniswap on Arbitrum, I need to bridge them too. After bridging it’s also worth to revoke all approvals, because my first wallet probably contains if not my life savings then at least more funds that I wanted to spend on this cross-rollup adventure.
After doing everything I needed to do on Arbitrum, I need to bridge received or remaining funds back to zkSync and change the network or wallet back. To be honest, even writing this part made my eye twitch.

How can it look
To do it, I firstly connect my wallet to a dapp's frontend. Wallet backend can edit contents of dapp calls to itself (e.g if it asks for USDC balance on Arbitrum, return USDC balance on zkSync) to make dapp frontend work without changing the chain in wallet settings. Then wallet backend checks if there’s its proxy contract on Arbitrum, and if not, requests its deployment.
When dapp requests transactions (or, to be more precise, I make something that initiates transaction, e.g swap or approval), wallet backend checks if there are any interactions with token allowance, and if there are, bridges required amount of tokens from itself to proxy on Arbitrum, then sends proxy transaction request to the controller on Arbitrum. After everything is made, wallet backend can either leave remaining funds in proxy or bridge them back.
From the point of view of user experience, it looks like that: I connect my wallet, see all my funds in the dapp’s frontend although they technically don’t exist in this chain, initiate a transaction, confirm it, done. Everything looks like I’m on my native chain.

Sounds nice! You don’t have to deal with tokens on different chains, find gas on these chains, etc, now all this mess can be easily abstracted away on UX.

But why should we keep our main wallet in one chain? Now it all sounds like overcomplicated paymaster system that allows us to get rid of gas mess, but for some reason also connected to some main wallet. This is where account abstraction comes in.

I’m writing this article in a “language” that, if you understand it, you should already know what AA is. But i’ll explain it anyway.
Account abstraction is a technology that allows you to use smart contract as a normal wallet. This is useful for customizing your wallet or adding arbitrary logic in it. For example, you can authorize some of your trusted people to reset access to your wallet in case you lose your phone or someone steals your seed phrase. To decrease losses from potential hack, you can set up daily spending limit. Basically AA allows you to program your wallet and possibilities are only restricted by possibilities of your programming language.

And how does it matter in our case? - With that cross-rollup interaction logic you can, in fact, use your single wallet with all its funds, customizations and security settings in all existing rollups. If you create a new EOA each time you interact with new rollup, it does not inherit all these things. If you use a single AA wallet in all chains, your funds in all these chains are as secure as funds in your wallet’s native chain and follow same spending rules.

Why hasn’t anyone done this yet

The reason is terribly simple.

L2→L1 messages follow same proving rules as rollup batches. It means that, if it takes 24 hours to prove the batch, then the message will either be sent or be secure to consume only after 24 hours. To make such cross-rollup messaging system, it needs to be fast enough. Batches should be proven within several minutes. How far are we at the current point?

Well, with ZK rollups we’re, in fact, done. Despite the fact that some of ZK rollups’ devs intentionally delay batches proving for bug hunting purposes (for example, zkSync Era validator proves batches after 24 hours after their submission), ZK rollup batch is proven as soon as anyone generates a proof to it and executes it on L1. When zkSync and other rollups open proving to everyone, it will become much faster and eventually will fit in a couple minutes.

With optimistic rollups it’s more complicated. Two most popular rollups on Ethereum, Arbitrum and Optimism, are optimistic, and they’re quite far from even opening proving to everyone. Arbitrum has fraud proving system, but it can only be ran by whitelisted entities. Optimism develops Cannon, but it’s not ready yet and will take long time until it ships to mainnet and becomes permissionless to use.
Even when they will open fraud proving to everyone, challenge time should be long enough to prevent massive DoS attacks against provers and other attacks aimed at taking provers down. Now it’s 7 days in both Arbitrum and Optimism.
In decentralized future, I don’t see realistic challenge time as less than 1 hour. Though I’m not an expert in optimistic rollups and may be wrong. If you’re interested in it, I’d recommend to read something from optimistic rollups developers.

However, all is not lost. For example, OP Labs is now looking at ways to ZK prove outputs of Cannon fault prover. I didn’t understand much from this topic, but as far as I understood, OP Labs wants to make system that allows (not forces) network participants to create ZK proofs of Cannon output on certain batch and send it on chain to immediately prove this batch without waiting for the challenge time to end. This may help Optimism to join us on the way of connecting Ethereum back.

In general, I would say that the problem of interconnecting rollups comes from decentralization sacrifices in favor of setting up training wheels.
And I totally understand it. If you build a system that is expected to handle billions of dollars and move huge elements of current financial system to itself but still don’t have any recovery guarantees from your settlement layer, it’s extremely hard and expensive to develop such things fast, efficient and straightaway decentralized.

I would like to thank all developers that work on Ethereum rollups and rollup ecosystem. You are those who move an entire industry forward and help us all to change the world to better. No matter if you’re CEO, team lead or simple coding plankton working on some small part of your project. You matter.

Thank you for reading.

I spent 2x more time to fix all writing mistakes than to write this article lmao