As every day in crypto is learning new things, it should seem obvious that today, I see the vision of “Rollup interoperability is crucial for Ethereum future“-era me as pretty outdated. From the POV of philosophy, I still follow the same vision - rollup interoperability is absolutely crucial for the future of Ethereum, and the entire ecosystem should work on solutions that improve it. From the POV of technology, however, I learned a lot of new ideas about this topic and changed my mind about some things.

To understand the material below, it’s helpful to have a basic understanding of rollups and the problem of their interoperability. If you don’t, my article “Dr. Dankshard or How I learned to stop worrying and love rollups“ is a great introduction.

Merhaba!

It’s the evening of 13th November, the first day of Devconnect Istanbul. As a massive fan of zkSync, I decided to attend zkSync Connect as my first event at this summit, the first of my life. There, I met a guy, and together, we headed to “Mosyo Coffee,“ as stated on the Luma page of zkCafe. There were two of them in that area, and we found the right place only by the evening.

It was much darker than in the photo above and was pouring downpour. Staying at the edge of the roof on which the food court was located and drinking a coffee we bought for free tokens on Clave, I told my new friend about my idea for a hackathon project.

There are “mini-accounts” - ERC-4337 (AA) accounts, whose validating logic is not a signature check but the existence of the operation’s hash in the single inbox bridge on its L2. The hash must be sent from its parent address on a specific source chain. The parent address is your main smart wallet on any L2 or Ethereum L1. To interact with another L2, you:

• Deploy the mini-account on it and set your main wallet as the parent address. Anyone can do the deployment; thus, it can be funded by the protocol or your wallet provider.

• Send the hash of the user operation you want to send to the inbox bridge on your L2 and set the destination chain ID.

• This hash gets bundled with other hashes and sent to the L1. The smart contract on L1 forwards this bundle to the destination L2, and the inbox bridge unbundles the hashes so that the mini accounts can read them.

• The sender adds a small fee to its hash to incentivize initiators of the transactions on the protocol’s smart contracts.

• When the hash reaches the destination L2, you send your user operation to the AA mempool on this L2. By utilizing the ERC-4337 standard, we don’t have to reimplement our own mini-account mempool and the protocol can be easily integrated into wallets with an already existing codebase.

Shortly speaking, I was going to create an L1-based bridge that sends transactions from the smart wallet on your L2 to any L2 you want to interact with. I ended up almost implementing it at the hackathon but couldn’t finish it due to having little experience and working solo. After explaining it to the friend, he asked me:

Why doesn’t one just change the network on their wallet and use token bridges to move the needed funds to the needed network?

I answered: This is absolutely an option if one uses an EOA wallet. EOA wallets act the same in all EVM networks and share the same address, so you can send transactions in all of them by just changing the network in your wallet settings.

However, the area is migrating to Account Abstraction-based smart accounts. These accounts allow us to add any functionality we want to our wallets programmatically. P256 signatures make it possible to use secure chips in our phones to sign transactions. Through social recovery, we can add our relatives as guardians authorized to recover our wallets, eliminating unsafe seed phrases. Paymaster technology allows us to pay the gas fee in any token or even make someone pay the fee for us. When quantum computers start breaking classic signature schemes, we can just change the scheme in our AA wallets to a quantum-safe one without creating a new wallet. This list can be continued endlessly, as Account Abstraction essentially allows us to use executable programs as full-fledged wallets.

All this comes at a cost: One can’t easily migrate their wallets to another chain because, besides moving the funds through the bridge, it requires redeploying the entire account with all the keys, guardians, and settings. In some cases, this might be too complicated or even impossible—say, in rollups that don’t support the P256 precompile, this signature scheme might be too expensive to use.

This is why I made that protocol. Essentially, you have AA accounts on many L2s. To send a transaction from them, you must verify your intent by sending a hash of it from your main account on a specific L2 to those “mini-accounts“ through the L1 bridge messaging. In fact, this way, you don’t get rid of multiple wallets; you simply move all the verification logic to a single “parent” account.

Another interesting detail of such a protocol is that it allows for interoperability not only with L2s but with all L1s sidechains, as they have enshrined bridges with Ethereum—Polygon PoS, Ronin, Gnosis, and Avalanche are what I can think of. However, it was designed as a rollup-centric interoperability protocol, so this is just a fun technological fact.

While the idea of the project was pretty clever, the practical implementation had a significant drawback: speed.

The entire design relies on canonical rollup bridges connected to Ethereum L1. Rollup bridges are peculiar in that they prove their state to their smart contracts on Ethereum to inherit its security. As you may already know, optimistic and ZK verification are the two most popular ways to do this.

Optimistic verification works by opening a “challenge window,“ usually about seven days, in which the challengers can send a fraud proof that points to any invalid part of the transaction batch. If this proof is valid, the rollup reorgs its blockchain to delete this batch. After seven days with no fraud proofs, the batch is automatically considered valid, and all messages and withdrawals are finalized on Ethereum.

You probably already figured it out. Due to a 7-day delay in messaging to L1, sending cross-chain transactions from an optimistic rollup is a terrible idea. Why? Well, will you wait for your DEX swap for a week? What’s going to happen with the price by this time?..

Sending cross-chain transactions to the optimistic rollup is much better. Even though the OP Stack sequencer waits a few blocks before processing the message to minimize the possibility of reorgs, waiting a few minutes for your transaction is already somewhat acceptable for some tasks. Moreover, the Ethereum community is currently working on single-slot finality, which will make every block finalize separately, making them irreversible by their next block. After it’s implemented, messaging from L1 to L2 will take about 12 seconds.

Hosting such accounts on ZK rollups would be better, but still not very usable. As we can see from the stats below, ZKsync Era finalizes in 21 hours, Linea in 5 hours, Starknet in 9 hours, etc.

But why is it like this? Isn’t ZK proof generation fast on powerful clusters? In short, there are two problems:

• Some ZK rollups, such as ZKsync Era, set execution delays so that the security council has time to revert some batches in case of a bug in their proof system. zkEVMs are really complicated pieces of technology, and due to this complexity, probabilistically preventing bugs by using multiple proof systems at once is not yet feasible.

• Even though ZK proof verification is very light compared to the computations it proves, verifying it on-chain is still pretty expensive. Depending on the proof system, it can take up to a million gas per verification. Taking the average gas price of 9 gwei and today’s ETH prices, a single proof costs about $30 only for verification on L1.

  Modern ZK rollups minimize these expenses by generating one proof for many batches once per a certain amount of time, but this slows bridge finality speed. Generating a batch and proving it every block makes $30 per block or $216,000 per day. At 100 TPS, this is about $0.025 per transaction just for verification costs. And we’ve also got to generate the proof and publish the batch on-chain!

Waiting an hour or two for a transaction is still too long. What can we do about it?

First of all, let’s forget my eight-month-old hackathon project and try to eliminate the mental model that every transaction needs to be initiated from our main smart wallet. Why do we even need to share our smart wallet logic in every rollup? Why don’t we just generate temporary EOAs, bridge the funds from our main smart wallet there, do some work we want to do, and bridge what’s left back?

My Clave (or whatever smart wallet you’re using) has Secure Enclave signing and social recovery, so I can always be safe about my funds there, even if I lose my phone. And who cares what happens with those temporary accounts? I’ve already done my stuff with them; all funds are on my Clave now.

However, this approach has a fundamental problem: the assumption that you can’t use the same wallet on other chains on a regular basis heavily restricts the number of tasks you can do on them. For example, you can’t create a deposit in a local lending platform because you can’t migrate it to your main network (ZKsync Era in this case). You can’t get tokens that don’t have a fungible equivalent in your main network (e.g., if they’re natively minted on that network). You can’t participate in a local DAO because your votes have to stay in that temporary account. Essentially, all you can do as a user is disperse funds to multiple recipients without bridging each time and get better liquidity for a swap to a token that can be bridged back to your main chain.

Thus, to make these wallets useful, we have to access them using the same rules we use on our main smart wallets—secure enclaves, social recovery, etc. So, we get back to the idea above and its infeasibility. There is, however, a feasible palliative that can give these mini-accounts only recovery properties of our main wallet:

We create the same mini-accounts described earlier but allow one key to send transactions from them directly. Our parent wallet can now change this key through the L1-based bridge or make the mini-account read it from the parent L2’s state. This way, if the temporary key is lost, the parent wallet can initiate a key change through the slow but atomic L1-based bridge.

Atomicity — the property of an action that doesn’t allow it to fail during execution. Either it wasn’t initiated, or it was done.

L1-based bridges are atomic because the message can’t be lost if it’s sent. Ordering, availability, and authenticity are guaranteed by the Ethereum L1.

This is much better! Now, ordinary transactions only take time for token bridging. After the tokens are at the destination, sending transactions is as fast as if it’s your main chain. If you lose the key, you’ll have to wait from several hours to 7 days, depending on the chain of your parent wallet, but you won’t use it very often, so the trade-off is acceptable for most use cases. Also, it’s feasible to implement in wallets even today. I even made my own implementation, but it’s not by any means secure or production-ready and is meant only for visualization purposes.

A similar technique is used in Web3 futures trading platforms: you approve the token in pair (usually USDC) to the smart contract and assign a temporary key for spending, which is stored on the platform’s frontend. This allows users to perform fast actions without signing each action with their main wallet. If you change your device or clear the data in your browser, you can just re-assign the key using your main wallet.

But, just as with everything in crypto, this approach is not perfect either. It has two disadvantages:

• Even though mini-accounts can be ERC-4337-compliant and thus support all its features, such as batching, paymasters, spending limits, etc, these features are no longer inherited from the parent account. In fact, the parent account just acts as a single social recovery guardian for the mini-account, but the guardian is the user themselves.

• Token bridging must be accomplished using external bridges. With cross-chain transaction initiation, we can carry our tokens with the message, receiving them practically 1:1 in an atomic way. However, with this solution, this is no longer an option, so external bridging is the only fast option left.

Even though modern bridges can transfer funds in a few seconds, they a) take a fee that can get awfully high on large transfers, b) are not atomic, and don’t inherit Ethereum’s security properties.

At this point, it’s worth taking a note about security properties. Using external bridges to transfer tokens is somewhat acceptable, unlike using them to pass messages to operate mini-accounts. The reason is their worst cases, likely due to an attack on them:

• In token bridging, the worst that can happen is that you won’t receive the tokens you sent. In such case, you lose X tokens you wanted to bridge and switch to another bridge.

• In cross-account messaging, the worst that can happen is that all your mini-accounts can be stolen by passing impersonating messages through the bridge. In such case, you lose your wallets on all chains with all their value, except your main one.

So, relying on external bridges for token bridging is pretty much an option as long as one has no efficient way to bridge them in an atomic way using L1.

Suppose we want to validate all transactions in a single place, for example, to natively transfer tokens between accounts or verify signatures with a unique precompile. In that case, we face the slow finality of today’s ZK rollups.

Let’s return for a little while to think of what can be improved with the previous technique. Why do rollups have slow bridge finality? We’ll take ZK rollups as a target because, with optimistic ones, the reason is already apparent:

• ZK proof systems for full-fledged VM environments are complicated, especially if the environment is not ZK-friendly (EVM). Therefore, there is a high chance that they will contain bugs. Multiple proof systems can prevent this, but such are very complicated to implement, and generating multiple proofs for a single batch may be too slow and expensive.

  As a workaround, rollup teams enable execution delays, which allow them to roll back the chain in an emergency. This is what slows the bridge finality in some rollups (e.g., ZKsync Era).

• Proposing the new state and ZK proving it to L1 are pretty expensive tasks, so to minimize costs, the rollup sequencers do it every few hours rather than every block.

  There is an exception, however; Scroll proposes the state about every minute, but a) proof verifying is still done every few hours, so it stays unverified, and b) Scroll is one of the most expensive rollups to use today.

If we rephrase it even more simply, the problems are proving costs and verifying costs. Let’s look at each problem and ways to solve it.

Essentially, our task is to make our smart wallet on a rollup quickly interoperate with other rollups without additional trust assumptions brought by external bridges. Smart wallets typically consist of a few usual AA features—paymasters, social recovery, secure enclaves, spending limits, etc.—and the main operation that allows us to send on-chain transactions from it.

Why do we need the main operation if we want to use the other rollups from our wallet? Because it is probably hosted on a multipurpose rollup—Arbitrum, Base, ZKsync Era—and we want to interact with users and smart contracts on this rollup, too.

This multipurposeness is what introduces complexity to the proof system of the rollups. Verifying the state of the entire virtual machine with lots of smart contracts and transactions happening every second is a pretty tall order. We want to execute two types of tasks that require a completely different set of features in the rollup: for an on-chain transaction, it is fast L2 inclusion, low L2 fees, and wide functionality of VM, and for a multi-rollup transaction, it’s fast bridge finality.

But what if we just get rid of the virtual machine and build a rollup that can only handle smart accounts and messaging to the other L2s? Vitalik Buterin proposed a similar technique at just about the time of Devconnect Istanbul:

Keystore rollups

The idea is to create a ZK rollup that can only store the account keys and change them using another key. This rollup pushes the root of the Merkle tree that contains all these keys to L1. Then, when you want to send a transaction from one of your smart accounts on L2s, you generate the Merkle proof of your current key, and your account verifies it against the keystore root available on the L1. Now, it knows your key and can use it to verify your signatures.

Such rollup is very simple, and multiple proof systems can easily be implemented, so keys stored in it are actually as secure as the L1.

Besides Vitalik’s original design, there are three leading ones for keystore rollups:

• Scroll’s approach is to store keystore data on L1 but allow updating it from their zkEVM rollup. For this, they’re introducing an L1SLOAD precompile that allows for cheap reads of L1 storage. Then, AA accounts on other L2s can read this data to synchronize their configuration—keys, guardians, etc.

• Base team is exploring a technique where only the state root is stored on L1, but transactions are sequenced using calldata, so the tree can always be rebuilt. Accounts on L2s are expected to fetch current keys using Merkle proofs.

• Stackr’s design is very similar to Base's or Vitalik's, but it utilizes its own framework of “micro-rollups“ with specialized minimal VMs.

Generally speaking, they differ in the number of tasks delegated to off-chain processing (in other words, how many things are on L2) and their implementation details.

We can expand this idea further by handling not only the keys but also the entire smart account logic. This wouldn’t be much more computationally difficult, either; essentially, we only need to handle these tasks:

• Sending data to L1: Accounts on the keystore rollup must be able to notify L1 about their transaction intent. Storing the entire transaction on L1 is not necessary; something like a root of a Merkle tree with all hashes of the user operations would be enough. Then, all that’s needed to send a transaction from a mini-account is reading the root from the destination L2 and making proof that a certain AA operation was actually requested from the parent account.

• Signature checks: The user signs the hash of the user operation they want to execute on a certain rollup. The keystore rollup verifies the signature to prove intent and adds the hash to the tree to then push it to the L1. A few signature schemes, such as ECDSA, P256, and quantum-safe ones, are enough.

• Social recovery: Make the other, purposefully chosen accounts, called “guardians,“ vote for the key change on the user’s account. The user can set the guardians and threshold and ask them for recovery in case of key loss. We can also implement veto-based recovery or alternative guardian schemes such as ZK-Email, ZK-OTP, or Web Proofs to expand social recovery outside the rollup’s users.

• Spending rules: In case the wallet is stolen, spending rules controlled by guardians can greatly decrease potential losses before the user recovers the wallet. This feature is also helpful for saving funds or, for example, making wallets for children—parents can send an allowance and restrict how much of it can be spent so that the child can learn to save.

• Token balances: This might seem unnecessary, but being able to store crypto inside the keystore rollup dramatically increases the security of users’ assets by not separating them into multiple mini-accounts. Also, it allows for many features that enhance user experience:

• Paymasters: The rollup may offer free transactions to attract new users or allow them to pay the fee with any token rather than only ETH. More complicated paymaster logic can be implemented, too—for example, the sequencer can take a fee from the swap on another chain when it’s bridged back to the keystore rollup.

• Internal token transfers: Besides instantly sending funds between rollup users, direct transfers are also helpful for implementing intent-based bridges with other rollups that have too slow finality to use L1 to bridge from the mini-account to the parent account on the keystore rollup. This way, the keystore rollup can essentially act as a hub to transfer tokens between mini-accounts on dozens of various L2s cheaply.

Such a system is much technically simpler than a full VM inside of a rollup, so it’s feasible to generate proofs for multiple proof systems simultaneously, and the complexity of proof generation will still be much less.

However, proof verification is still a problem. As we’ve calculated before, its gas cost can be up to 1M gas or ~$25-50, depending on the gas price. This cost is fixed and doesn’t depend on the number of transactions in the batch. This means that if there are too few transactions, the fee for each transaction can be very high. There are two main ways to reduce this cost:

Aligned Layer

Aligned is an EigenLayer AVS that utilizes restaking operators to verify ZK proofs cheaply. If you’re not familiar with EigenLayer, this is a simplified summary of how proofs are verified in Aligned:

1. A user sends the proof verification request to the network and pays the fee for it;

2. Aligned operators, each of which is an Ethereum validator with their deposits bonded, verify the proof on their nodes and sign for its validity;

3. When 2/3 operators sign for the proof, the aggregated signature is sent and verified on Ethereum L1.

4. If an invalid proof has reached finality, validators who signed for it can be slashed by verifying it on-chain. This way, the proof gets economic security equal to 2/3 of the total stake of Aligned operators.

This approach has an obvious drawback—Ethereum no longer guarantees proof validity. If the TVL of the rollup’s bridge is higher than 2/3 of the total Aligned stake, attacking it becomes profitable. And since we’re talking about the finality latency of 1-2 blocks, we can’t optimistically prevent the attack.

However, this might be a relatively safe option as long as the rollup doesn’t get too large. When it does, the transaction demand could already make L1 proof verification worthwhile. According to docs, verifying the ZK proof using Aligned costs about 3000 gas, which is nearly free even for Ethereum L1.

Proof aggregation layers

If you’re uncomfortable introducing additional trust assumptions to the system, or your protocol has already become too large, but its transaction demand has not, there’s an alternative.

ZK and rollup teams have recently started actively working on proof aggregation protocols. If you’re not very familiar with ZK, proof aggregation is when a ZK proof proves the validity of another ZK proof (that can, in turn, prove another proof, and so on), thus “aggregating“ them in the single proof and essentially moving all their verifying costs to proving costs. What’s left is verifying a single ZK proof on-chain and being sure about the validity of all the other ZK proofs it proves. Phew!

Proof aggregation makes sense where verifying costs are higher than proving aggregating proofs. That is, aggregation becomes profitable if the cost of generating a proof for ten proofs and verifying it is less than verifying these ten proofs independently. This is even more helpful in Ethereum L1, which is heavily restricted by computational capacity. Depending on the proof system, the entire block can only contain about 100 proof verifications, excluding all the other on-chain activities.

Generally, there are two types of proof aggregation protocols:

• General purpose (Universal) aggregation: Such projects usually support several of the most popular ZK protocols (Groth16, Halo2, Plonky), on top of which most ZK circuits are built and take a fee for processing. The dApps that need the proofs then reveal the data from the protocol and process it on their own. Nebra’s Universal Proof Aggregation system, currently in development, does exactly this. Aligned is also working on so-called “slow mode“ verification, which is, in fact, a proof aggregation system, too.

• Aggregating shared rollup bridges: Similarly to shared sequencing in optimistic rollups, ZK rollups with their stacks are working on shared bridges with aggregated state proofs for every ZK rollup in the bridge. This not only allows synchronous composability inside the stack ala shared sequencing but also minimizes the costs for proof verification. You might have heard of Polygon’s AggLayer or ZKsync’s Hyperbridge, which are shared rollup bridges that work on proof aggregation inside the bridge.

The advantages of universal aggregation systems are that they’re project-agnostic and only specialize in the aggregation process itself, which opens pretty fast verification of proofs and low costs. Also, it’s likely not to have training wheels because of the lack of the bridge component.

Aggregated rollup bridges, in turn, are helpful for the keystore rollup to have synchronous composability with an already existing rollup stack. For example, according to L2BEAT, 13 projects are currently built using Polygon CDK, and 11 use ZK Stack. When they all connect to a shared proof aggregating bridge, connecting the keystore rollup to one of them will open seamless interaction with many L2s without even touching the L1. For this to work, the bridge must support different state transition logic for its L2s because the keystore rollup’s logic differs from the other L2s in it.

However, these bridges are usually upgradable and controlled by its DAO or security council. Keystore rollup projects may not be comfortable with giving up their sovereignty to the operators of the bridge they’re connected to. Also, bridges may introduce execution delays as a training-wheels precaution, similar to how ZKsync Era operates now, which essentially kills the entire efficiency of this keystore rollup design.

This way, keystore rollups, like any other ZK rollups, can minimize proof verification costs and even combine this with synchronous composability with an already existing rollup stack.

Efficient intent-based bridging with “Keystore+” rollups

As previously discussed, bridging from L2 to L1 is not the only problem. Most rollup sequencers also apply delays to passing messages from L1 to L2. This is because when an Ethereum block is created, it’s not yet final and can be reversed within the following ~64 blocks (two epochs, about 13 minutes). These reorgs happen because of network latencies, causing some proposals to appear in the network too late when some nodes already consider them missed.

Even though most reorgs are no deeper than two blocks (a seven-block reorg even appeared in the news two years ago), rollup teams still don’t want to take risks related to missed messages and apply delays to bridging from L1. These delays are just about 1 minute on some rollups (OP Stack, ZK Stack) but can be up to 6 minutes, as in Arbitrum, or even ask for L1 finality, as in Linea.

Ethereum community is actively working on Single-Slot Finality, which will make each block finalize independently instead of once in an epoch. But we can say for sure that it isn’t planned for the next Pectra upgrade coming in Q1 2025, so it’ll be at least a year before SSF gets implemented.

If a team implementing this extended keystore rollup design isn’t comfortable with such transaction latency, it can implement a palliative described earlier. Every mini-account has a key authorized to send transactions or utilizes a static key from the keystore (as per Vitalik’s original design), but account management is still on the main keystore account. After SSF is implemented on L1, the rollup can remove the authorized spending keys, and users will get the entire AA customization functionality without significant speed degradation.

However, cross-rollup token transfers still present a problem. If we implement token vaults inside the keystore rollup, transferring tokens from it will take 1 to 15 minutes, depending on the recipient rollup. If we do not, splitting users’ balances into mini-accounts on multiple L2s can pose security risks and even lock some assets into illiquid L2s, bridging from which may cost too much or take too long.

As an alternative, we can integrate an intent-based bridge into the rollup and deploy it on all the other rollups or even reuse existing infrastructure, such as ERC-7683-compliant protocols.

— What's an intent-based bridge?

Most existing cross-chain bridges are based on messaging protocols. For example, Stargate uses LayerZero to pass messages about deposits to destination chains, relying on it as the source of trust. When you send tokens through such bridges, they lock your tokens on one side and send a message about your deposit on the other side, and the vault there unlocks the respective amount of tokens for you.

Intent-based bridges, in turn, do not send messages between two chains. Instead, funds being sent are locked in the vault as a “cross-chain order,“ and then anyone can fill the order by sending the requested amount of tokens on the destination chain. Whoever fills the order can then claim the locked tokens from the source chain when the vault in it gets informed about the finalized state of the destination chain and can confirm the transfer. This can happen either by waiting for the destination chain's objective (bridge) finality or via some external oracle protocol. For example, Across uses UMA’s optimistic oracle to fetch the state of not yet finalized L2s.

We can use the same design for these extended keystore rollups to implement trustless, fast, and cheap two-way bridging between the keystore and all other L2s. Fast bridge finality allows intent-based orders from the other L2s to be nearly free because proving the fulfillment on the L2 takes just a few minutes. Orders from the keystore will probably be cheap as well, as liquidity on the L2 can be supplied relatively fast through the keystore. This way, such keystore rollup design can become a hub for intent-based bridging, allowing users to send transactions instantly rather than in a few minutes, paying nearly nothing for bridging. The rollup team can also supply liquidity for bridging through the keystore 1:1, and this would not cost them a lot.

Unified ENS name for all chains

Imagine having a single username.eth that resolves to all your mini-accounts, no matter which chain the recipient is on. This design makes this possible. How?

As we already know the address of our main keystore account, we can use multichain factories and CREATE2 to make the addresses of our mini-accounts the same across all bytecode equivalent EVM chains, even including Ethereum L1. Then, we set the unified address in the ENS resolver, and our name works in all EVM L2s.

However, there are two exceptional cases:

• Bytecode inequivalent EVMs, such as ZK Stack. For them, we can generate a custom address according to their CREATE2 rules and add it to the ENS with their chain identifiers according to ENSIP-11.

• Non-EVM L2s, such as our keystore. The logic is the same for them, but instead, we add their custom addresses to the ENS according to ENSIP-9.

While being very UX-friendly, this approach uses a lot of expensive computation and storage on L1 because names and addresses are stored on L1 resolvers. This problem can be solved using CCIP Read, but I came up with another, more efficient on-chain resolution logic:

Every account on the keystore is registered and indexed by the namehash of its ENS name, registered under a single ENS name with a custom resolver. When its subdomain is resolved, the resolver contract checks if the account with such namehash exists in the rollup and uses the namehash to generate CREATE2-based mini-account addresses. When these are deployed, they will ask L1 for the keystore data belonging to the namehash they were deployed with. It can be the transaction intent itself or just the current signing key, depending on keystore implementation.

This way, we get keystore accounts, each with an ENS name resolving to itself and its mini-accounts on each rollup. These mini-accounts, in turn, will also rely on this ENS name when validating the transaction using the keystore rollup.

Sequencing mechanisms on “Keystore+“ rollups

As bridge finality on the extended keystore rollup is supposed to be a few L1 blocks, we may as well get rid of the centralized sequencers entirely, turning it into a based rollup. As we’ve discussed before, ~12 seconds of transaction speed is acceptable for the average user, but based sequencing would make the rollup much more resistant to censorship and single points of failure.

It’s worth considering that with based sequencing, internal transactions will take as long as external ones (excluding time to reach L2). This may be unacceptable for some teams, as centralized sequencing makes all internal operations instant.

Alternative advances in rollup interoperability or Why I did not mention shared sequencing

I wrote the entire article around ZK rollups and ZK technology. This is because optimistic rollups cannot fundamentally have fast objective finality, and such a property is only reachable using ZK. Today’s optimistic rollups understand their sealed position and are actively researching the feasibility of integrating validity-centric designs in their stacks, hence, for example, the recent partnership of Optimism and RISC Zero.

Optimistic design is fundamentally restrictive in that it will never handle interoperability with other rollups. However, interoperability within the optimistic ecosystem is developing rapidly. The primary technology for making optimistic rollups interoperable with each other is shared sequencing. Simply put, this is a mechanism where a sequencer can build a batch for multiple rollups simultaneously. If any transaction in any of the rollups sequenced is invalid, the entire batch can be disputed and reverted.

This gives all batches in this “mega-batch” the atomic property—either all batches are valid or none. This, in turn, allows for atomic synchronous composability inside the batch. Atomic—because nothing in the batch can be invalid if it is valid, synchronous—because all messaging is inside the batch, which is processed simultaneously by all its rollups’ nodes.

This technology basically turns all rollups in a certain optimistic stack into one big, sharded rollup. Why only one stack and not all of them? Because in order for this to work, rollups must be connected to a single bridge. Each stack has its own bridge, and there’s no reliable way to build batches in multiple bridges simultaneously. This means that shared sequencing allows OP Mainnet to seamlessly interoperate with Base and Zora but not Arbitrum or Metis, and vice versa.

Such consolidation creates a dangerous situation in the rollup ecosystem. New rollups have the option to either join the existing stack and be integrated with it but not with anyone else OR build on top of ZK and be integrated with anyone but the stack above. There is no such choice now because shared sequencing is not yet available, and each OP Stack or Arbitrum Orbit rollup is independent, with its own bridge. However, when they consolidate, they will form two solid organisms within the ecosystem, each holding about 40% of total L2s TVL.

— Okay. If they will hold the vast majority of total TVL, why don’t we get rid of ZK and build on top of them instead?

First of all, shared sequencers are a huge centralization driver. If you run an OP Mainnet sequencer, your batches won’t include transactions from other rollups in the stack; you’ll earn less in fees and eventually be outshined by large commercial sequencers that can handle the entire stack in their batches.

However, the most critical problem is that in such a case, the rollup ecosystem becomes enclosed within oligopolistic empires pursuing their own interests, seeking to establish more control over the capital, and slacking on technological progress in the ecosystem. We would then have to deal with Ethereum being crushed into a disjunct area where PR and intraspecific struggle are what matter, not technologies that actually change the world.

“Build tools, not empires. Empires try to capture and trap the user inside a walled garden; tools do their task but otherwise interoperate with a wider open ecosystem.”—Vitalik Buterin

— How are aggregating shared bridges in ZK better than optimistic shared sequencing?

In ZK rollups’ shared bridges, sequencing can be done independently from the other rollups in the bridge. Each rollup can have its own sequencer or implement shared sequencing. Proposers who assert the resulting state root after all sequenced batches and prove it using ZK are the ones doing aggregation.

Moreover, the characteristic of relatively fast objective finality in ZK rollups does not make them enclosed inside their ecosystem, no matter how large it grows or how centralized it is. When ZK is developed to the level when big zkVM proofs for multiple proof systems can be generated rapidly, all ZK-based rollup stacks will interoperate nearly seamlessly, just like theoretical keystore rollup described above sends transactions in all the other rollups in a matter of L1 blocks.

— But how come optimistic rollups still exist if they’re so evil, and there’s an alternative in ZK rollups?

Within our community of researchers and highly technical people, the consensus is that ZK is the best scaling solution. And you’ll be surprised to realize that for regular users and builders, optimistic rollups are much better than ZK! How come?

For users, there’s a well-established ecosystem. All platforms know what Arbitrum and Base are, dApps always have high liquidity, and the UX is fragrant. Try to name an application on Base, and you’ll instantly remember Friend.tech, Farcaster, Daimo, Time.fun, various NFT collections, ZKP2P. Even Mirror initially supported only OP Stack rollups for minting. Try to name an application on ZKsync Era. Uhhh…

For developers, there’s absolute Ethereum equivalence, so the entire Ethereum and EVM forks infrastructure works from the box. Besides that, the documentation scrupulously defines and explains all peculiarities and tooling of optimistic rollups. There are a lot of tutorials, courses, marathons, developer relations, and so on.

On the other hand, there are year-old zkEVMs, not all of which even have bytecode equivalence. They all have a long list of differences and difficulties when building on top of them. They’re mostly poorly documented, and there’s significant reliance on existing infrastructure that is barely compatible with the networks. Auditing “compatible“ VMs is very difficult and expensive, and you don’t even have a ChatGPT to ask. Its answer probably works for Base, but does it for Linea?

For users, ZK rollups have no ecosystem. There are no applications to use, no social, no popular NFTs or tokens, and all activity boils down to airdrop farming. You’ll barely find liquidity for pairs not in the top 10 of the Ethereum ecosystem, and DefiLlama starts showing ZK rollups when you get tired of scrolling.

— But optimistic rollups actually win by compatibility with existing infrastructure. How can ZK rollups beat them in it?

You don’t have to introduce bytecode equivalence, or blake2f precompile to attract developers and activity to your platform. ZK rollups are not supposed to be better in that. Instead, in their fast finality & interoperability, fully horizontal scalability, fundamentally higher security, and decentralization. This is what should be utilized in projects in the ecosystem of ZK rollups to make them advantageous in the ecosystem.

I wrote this article to put together a complete picture of all these technologies, including ZK rollups, that have appeared and developed in the area during this time and show how they can be used to solve today’s most important problem in the field—rollup interoperability. We have to embrace ZK and its limitless benefits. We have to use them to our advantage to build things that get us closer to making Web3 a place for everyone in the world.

This is perhaps the largest comparison table I’ve ever made. No wonder—in the last year, the Ethereum community has come up with many new ideas and technologies that can be flexibly combined and manipulated to create completely new solutions that solve the most pressing problems in the area, even with existing tech.

Yes, I am still convinced that rollup interoperability is the most pressing problem that prevents us from onboarding the entire world to Web3. Scaling is no longer so urgent—4844 allows us to handle up to a thousand transactions per second, comparable to financial activity in the largest countries in the world; PeerDAS, coming in a year, will increase this even further. Fragmentation, however, still poses a severe threat to the Ethereum ecosystem. No matter how large it grows, the ecosystem should not feel like a dozen distinct empires but as one large mechanism. So different, but so identical.

We are not early, and this article is supposed to show you that. We must use all our strengths to develop working systems that help the gigantic L2 ecosystem interoperate. This is possible right now. Soon, you should be able to participate in any DAO and send any assets to the ENS, the owner of which is several thousand kilometers from you. Geographical borders should not be replaced by digital ones.

If you liked this work, agree with its thesis, learned something new, or want to spread this message further—mint it below, share it on social media, leave your comments, and talk about the importance of rollup interoperability more.

Thank you for reading.

To understand the material below, it’s helpful to have a basic understanding of Merkle trees, Ethereum, and its rollup-centric scaling roadmap. My article “Dr. Dankshard or How I learned to stop worrying and love rollups” is a great introduction to the latter.

Special thanks to Proto for help with OP Stack

Data storage problem

If you try to summarise rollups in two sentences, you’ll get something like this:

Rollup is a separate blockchain network that verifies its own state using a smart contract on its parent, “layer one” chain rather than its own independent consensus.

In order to achieve this, rollup sequencers give the smart contract on L1 all necessary data to verify the state - for example, transaction data and (in case of ZK rollups) Zero-Knowledge cryptographic validity proof - and the smart contract uses it to generate blockchain-verified verdict about the canonical network state.

However, this definition lacks important details, because it’s worth noting how exactly optimistic and ZK rollups utilize L1 data.

• Optimistic rollups need to store transaction data on L1 so that people who want to challenge the state transition can always access everything necessary for challenging. The smart contract only needs a contested batch chunk to verify users’ fraud proofs.

• ZK rollups need to store transaction data on L1 so that people who want to generate the validity proof for the batch can always access the data for proving. The smart contract can verify the proof only by using a short cryptographic commitment to the data.

In fact, in both architectures, the “verifier” smart contract does not need all the data; it’s the off-chain “proving” entities that do. Data storage on L1 is preferred because it has the same trust assumptions as the output of any smart contract on it—in other words, the “verifier” smart contract verdict is as secure as all the data stored.

Interesting fact: L2 networks that store their data outside their L1 are called Validiums (ZK L2s) and Optimiums (optimistic L2s). Some people, including the L2BEAT team, do not consider them L2s because by using an external Data Availability system, they introduce additional trust assumptions into their system. Rollup is a universal term for L2s that store their data on their L1.

Another important thing you might already assume is that data is only needed until its batch is considered valid by the smart contract on L1. After that, all nodes will follow the Merkle root from the contract as the canonical one.

That is, we don’t need to store the rollup data forever as we do using calldata, so we can make some sort of temporary data storage, also secured by L1 but pruned after some time.

What’s a blob?

EIP-4844 introduces special consensus layer entities, called “blobs”.

At a high level, the blob is a 128kb binary object kept by the consensus layer. Its commitment’s hash is stored in the EVM, so anyone can reveal the commitment itself and use it to execute necessary computations. Blobs are pruned after 4096 epochs ~ 18 days, which is enough for both optimistic and ZK rollups to verify their batches.

How do rollups verify their state if the blob isn’t available in EVM? What’s the commitment? How come only its hash is stored in EVM? How does it all work? To answer all these questions, let’s explore the logic behind Protodanksharding.

KZG polynomial commitment scheme

Note: I won’t go into all cryptographic details to keep the article relatively simple. Rather, I will take a software-centric approach to explain solely where and how KZG is used within post-4844 Ethereum and rollups.

Technically, the blob is an array (list) of 4096 numbers from 0 to a very big number roughly equal to 2 to the power of 254.857. These numbers, called “field elements,” are packed in 32 bytes each, so the entire blob takes 128kb of disk space.

KZG commitment scheme allows conversion of an array of field elements (in our case, the blob) into a 48-byte short commitment which can be used to 1) authenticate blobs and 2) generate short proofs that any field element exists in the original array, which can be verified using only the commitment and thus without revealing the whole array.

The first feature is very similar to the logic of hash functions, but the second one is the most important for us (and is the reason why we didn’t just take any hash function!):

Remember how I said that only commitment hash is available in the EVM? Thanks to EIP-4844’s point evaluation precompile, we can verify KZG proofs on-chain, only using the commitment, supposed field element, and the proof itself. In the EIP-4844 implementation of KZG, all this data takes 32+48+32+32+48=192 bytes.

What is this needed for?

Even though all types of rollups can use this feature, it’s the most useful for optimistic rollups: fraud proofs only need one batch chunk which was executed incorrectly, and they can utilize KZG proofs to contest only necessary parts of the blob, leaving the rest outside the EVM (and thus allowing it to be pruned after challenge time passes).

ZK rollups can enshrine KZG proof verification inside the validity proof of their batch, but since the validity proof verifies the whole content of the blob, the more efficient solution should be enshrining blob proof verification instead, leaving the blob itself in the private input.

What’s a blob proof? It’s a cryptographic proof that some commitment corresponds to (that is, was derived from) a certain known blob. It’s not very useful with small 128kb blobs because we can simply perform an interpolation and compare the resulting commitment with the supposed one, but if (when?) we make blobs larger, blob proofs will win performance by a lot.

As you can see, the characteristics of the KZG commitment scheme allow for efficient blob utilization for both ZK and optimistic rollups.

Blob production

EIP-4844 introduces a new type of blob-carrying transactions. It’s almost the same as a normal (EIP-1559) transaction but has two new fields - max_fee_per_blob_gas and blob_versioned_hashes.

• max_fee_per_blob_gas - maximum fee per 1 blob gas (not to be confused with EVM gas!). The blob gas market follows EIP-1559-like logic, so the network won’t take more per 1 blob gas than the calculated blob base fee. Blobs have a fixed blob gas usage of 131072, that is, one blob gas per byte.

• blob_versioned_hashes - versioned hashes of blobs’ commitments. Each transaction can contain multiple blobs, hence “hashes.” When a validator decides whether to take a blob-carrying transaction, it asks its consensus layer client if the blob that has the commitment with a certain versioned hash is available (downloaded). The versioned hash is the simple SHA256 hash, but the first byte is version - 0x01.

Also, to send a blob-carrying transaction, you need to insert your blobs, their commitments, and corresponding blob proofs into the transaction envelope.

The common misconception is that blob production is expensive and, therefore, must be accomplished by a validator who takes the transaction. As we can see, the latter is impossible—the transaction creator has to set versioned hashes of their blobs, thus executing all interpolation into commitments themselves. Is it actually expensive to generate blobs, though?

To get a blob that can be published on-chain and which contents can be KZG proven, two steps are required:

• Convert a byte array into an array of field elements. Since the field element is slightly (~1.2 bits) less than the 32 bytes it’s packed into, we can’t just split our byte array into 32-byte chunks. However, it’s quite simple to implement necessary compression that, say, pads every 31 bytes with a zero byte to not exceed the limit. Such an operation shouldn’t be expensive, because the blobs are just 128kb each.

• Perform a KZG polynomial interpolation to generate the commitment to the blob which versioned hash needs to be set in your blob-carrying transaction.

Unless you’re a programmer, I guess you were confused with the first part. Let’s break it down!

Do you remember that field elements are packed in 32 bytes each? That’s because their limit, that large number called BLS modulus, roughly equals 2^254.857, so it fits in 255 bits. However, we can’t store bits, only bytes, so we add one more zero bit and fit it in 256 bits = 32 bytes.

Even though we pack field elements in 32 bytes, we don’t quite have all these 32 bytes available, because the first bit has to be set to zero and all remaining bits must be less than BLS modulus. Therefore, not all sequences of 32 bytes are suitable for field elements.

But what if we need to fit sequences larger than the BLS modulus? - We have to pad our values. This will result in slightly more bytes used and we’ll need to KZG prove two field elements to get a single 32-byte sequence, but our field elements won’t exceed the modulus.

Okay, making an array of field elements seems pretty trivial. What about interpolation?

I made blobs-benchmark, a Python script that generates 100 random blobs with their commitments and shows how fast this process was done. The script itself is pretty basic because the KZG Python library is available online. Let’s run it!

https://i.imgur.com/vWELjbW.mp4

My M1 laptop generates 100 EIP-4844 blobs in ~8.9 seconds or about 89 milliseconds per blob. The actual random blob generation happens instantly, so it’s all interpolation.

This script is open source, so if you had any experience running them before, you can have a try and check how long it takes on your machine. As we can see, blob production is practically free, so sequencers won’t need to handle any additional costs.

Going inside the rollups

Let’s see how rollups utilize blobs, what their proving mechanism is, and how they pack batches into field elements. Thankfully, all rollups are open source, so we can check all the code ourselves!

I took OP Mainnet for our pseudo-research because it’s based on OP Stack, so all OP Stack rollups with blob support (Base, Mode, Zora, etc) have the same logic.

OP Mainnet

At the time of writing, the OP sequencer creates new blobs by sending blob-carrying transactions from a special Batcher account to the vanity address.

Notice that the destination address is almost fully zero. It’s not someone’s wallet; rather, it is a sort of demonstrative burn address, hence the “10“ at the end, which is the chain ID of OP Mainnet.

Previously all these transactions contained batch data in their calldata. Now, all transactions have empty calldata, so technically they’re the same as a simple 0 ETH transfer, but also carry blobs.

(The info below is taken from OP Stack specs, specifically this and this page. It’s slightly technical and not really needed for understanding)

OP Stack uses channel encoding to convert transaction batches into data streams that can be fit into blobs on L1.

1. Firstly, the sequencer constructs the span batch - the range of multiple consecutive L2 blocks, with all their transactions and necessary metadata to reconstruct the network state.

2. Then it gets encoded using RLP and compressed using zlib stream compression. This was the last step before the blob upgrade, as L1 transaction calldata can accept raw bytes. However, this is not the case with blobs, so now it also goes through blob encoding.

3. The resulting byte sequence is split into chunks of 127 bytes = 1016 bits each, and each chunk is encoded in 4 field elements (254 bits per element).

4. While OP Stack technically supports sending multiple blob transactions to store the single channel, I couldn’t find such examples in the mainnet, so let’s assume the channel takes up to 6 blobs. If the last used blob isn’t full, it’s padded with field elements equal to zero.

I chose a random sequencer transaction and made a Python script that decodes its blobs back into the span batch and reads its contents.

Using the same logic as described above, I decoded the blobs into the span batch and read its contents. The batch also contains transactions themselves, but the script doesn’t print them for the brevity of the output.

If you want to run it yourself, here’s the link. I won’t describe its internals because this part will become too complicated to comprehend, but if you have some experience in Python, it shouldn’t be difficult for you to understand the script.

About every hour, the OP proposer (in fact, the same entity, since the rollup is centralized) pushes a new state root based on the execution of newly posted batches. OP Stack doesn’t have fault proofs yet, so the validity of the blobs’ content is not proven in any way.

OP Rollup Node is connected to the L1 (Ethereum) node and OP Execution Engine. Rollup Node constantly scans L1 blocks for new proposals and batch sequences and passes them to the Execution Engine, where they’re used to reconstruct the L2 chain.

As all OP batches are considered final after 7 days of challenge time, only finalized batches can become unavailable (because their blobs are pruned by L1 only after ~18 days). Thus, the OP node can safely follow the latest finalized output root and leave historical batches untouched. Elements of the state trie can be fetched P2P, and because the node always has the state root, only one honest node is enough to reconstruct the entire trie.

People are always asking me if I know Alex Hook…

Do you know what’s the first rule of the fight club?

• What’s the “fight club”?

I won’t tell you the whole thing, only the first rule. KZG commitments are going to help me.

Alex Hook

@alexhooketh

just posted the entire fight club script in two blobs and proved what's the first rule of fight club onchain :)

1/

blobscan.com/tx/0xc5c2e96c9…

6

4:07 PM • Mar 13, 2024

In my recent experiment, I posted the entire Fight Club script in two blobs on mainnet and sent a transaction to the point evaluation precompile with the proof that the “you do not talk about Fight Club” rule actually exists in one of those blobs. When I did this, there were no tools to build the blobs yourself, so I had to write a deployment script. Here’s how it works:

Firstly, I had to get a Fight Club script to put into the Python deployment script.

However, to put it into the blobs I needed to solve two problems.

1. The Fight Club script is too big to fit in the single blob (~160 KB, only text with all unnecessary symbols stripped)

2. It consists of ASCII printable characters that can be as big as 0111 1110 in binary form. If any field element starts with a character bigger than 0111 0011 (first bits of BLS modulus), the entire blob is invalid.

The first problem is easy - we can put up to 6 blobs in a single transaction. Here’s how I fixed the second one:

This part of the Python script splits the incoming data (in our case, the movie script) into chunks of 31 bytes each, pads every chunk with a null byte (thus, making them start with 0000 0000), and groups them into arrays of length 131072, essentially constructing the always-valid blobs.

Ok, now we’ve got blobs. How do we publish them?

This may seem weird. If you know no Python, this is what happens above:

• We build an array with all the data needed to construct the transaction. You may even notice familiar values - a gas limit of 21000 since we call no contracts, gas price, max priority fee, transaction count AKA nonce, but with versioned hashes of our blobs. Do you remember that, unlike blobs or commitments, they’re stored forever? Here’s why - they’re built in the transaction body, which is added to the block, which is added into the blockchain.

• We encode this array using RLP encoding and sign the result with our Ethereum private key. The signatures in Ethereum consist of three elements - two numbers (signature.r, signature.s) 32 bytes each, and a parity bit (signature.v).

  Notice the “03” number we add to the start of the array. This is the type of a blob-carrying (EIP-4844) transaction. Normal transactions have the type of 02 (EIP-1559).

• We build an array with our transaction, our blobs, its commitments, and proofs and pad them with the transaction type. This is a transaction envelope or packet, we should send it to our node provider so that it can be added to the mempool and distributed within the Ethereum P2P network.

Now we’re ready to send it. Ta-da!

The entire script took two blobs. The publication itself cost me 0.000000000000262144 ETH, which is virtually free. The main cost driver was sending the transaction to the network, which was about $5 at that moment.

You can send up to 6 blobs in the single blob-carrying transaction and, as it’s almost the same as the normal one, execute some other smart contract computations in the same transaction, distributing the costs.

The important thing to remember is that the EVM has no idea what the blobs were because I packed them into the networking packet. It only knows the hashes of the commitments, which is enough for me to verify blob proofs on it.

Here’s what the verification script looks like:

It’s very similar to the logic above. For a reason - what was changed is transaction type (now it’s 02, a normal EIP-1559 transaction), destination address (0x0A - point evaluation precompile), and the calldata (that is, transaction input) is not empty now. Everything else is the same.

The calldata is the sequence of the versioned hash, the field element existence of which we want to verify, the commitment, and the KZG proof. This is all the point evaluation precompile needs to verify our proof. As I already said, the blob is not needed to verify proofs.

Build, sign, pack, send. Voila.

The “Success“ label tells us that the precompile did not revert while verifying the proof, so it is valid. Yes, you got it right; this is just a smart contract call. Now the EVM knows the first rule of the fight club according to the scripts but no other rules or what the fight club is.

The source code of the scripts is available here.

Replace the first rule of the fight club with the forged batch element and the movie script with the batch of transactions, and that’s how optimistic rollups work. Make the proof a blob proof and wrap it into the validity proof so that it only needs the versioned hash as public input, and that’s how ZK rollups work. That’s it. That’s what the blobs changed in the rapidly moving Ethereum ecosystem.

In fact, the blob upgrade is nothing but using some cryptographic primitives to optimize the workflow of rollups, so that they can run more efficiently and give cheaper fees and smoother experience to end users. This is the whole crypto - huge engineering work taking a lot of man-hours that gives nothing but a better user experience in the completely trustless system slowly changing the entire world.

If you try to summarize this article, you’ll get completely different results based on who you’re trying to explain it to. For ordinary users, making the vast majority of the user base, “it makes the fees cheaper“ is enough. For curious minds, the concept of blobs being pruned after they’re not needed anymore should do the thing. If one is an engineer, however, you probably wouldn’t compress this material significantly much. I tried to cover everything you could be interested in if you wanted to know the blobs, but not going to write your own implementation of them. I hope this article gave you such kind of understanding and await your feedback on any socials or comments if they’re added to Mirror someday.

Thank you for reading.

I’ll keep the original article uploaded as it’s still a really good piece with numerous insightful observations. Also, it holds personal significance for me, as it’s the first article that garnered me some recognition and inspired me to pursue technical writing further.

You may notice how many people wonder why such a complicated solution was adopted for Ethereum scaling, maybe you’re even one of them. Like, why “rollups” if there are many other options, from Solana-style vertical scaling to block expiry and execution sharding?

In the past I was a huge fan of execution sharding and strongly opposed rollup scaling as too complex and meaningless if execution sharding exists. In response I always received non-exhaustive “it’s inefficient”. Time flies, and after reading dozens of topics, articles, rationales, sharding and danksharding designs, I can say that I changed my mind about it. I want to make a summary of rollup scaling from the point of comparison with other scaling designs, and show exact numbers and facts about their effectiveness to the same doubting people as me a year ago.

Special thanks to Domothy for feedback and review

Theory of scaling

Ethereum chain is slow.

It’s slow because all nodes have to execute all transactions happening on-chain themselves. All computers with running Ethereum EL+CL clients should download and re-execute all 18.5 million (at the time of writing) blocks and all transactions inside of them, and after they’re done, they do the same with newly created blocks, which are created every 12 seconds.

With this system it’s impossible to make weaker node execute less computations than stronger one. If on-chain computations are only within the power of stronger node, weaker node simply won’t keep up with the chain, eventually leaving the network only with powerful nodes. It follows that the entire network operates at the speed of one node of this network. The load can’t be distributed between the nodes.

It can be assumed that if the solid network can’t distribute the load between nodes, we must make node requirements as high as possible. By that we can make the network much faster, since modern enterprise-grade servers can let us process hundreds of thousands of transactions.

This is called vertical scaling - we make single instance of the system more powerful to increase capacity of the whole system. Among platforms that adopted this type of scaling - Solana.

However, this type of scaling is not perfect. By increasing node requirements, you respectively reduce the number of people that can afford running their own node. If ordinary users of the network can’t run the network themselves, they have to trust ones who do - block explorers, commercial projects, dApps, etc. Trust implies huge risks on the part of simple users, because they become easily vulnerable to malicious actors in the network infrastructure. Cryptocurrency as an idea strives for refusal of any type of trust by verifying your funds and other elements of the network that you may need yourself, which isn’t really possible with vertical scaling mechanism. That’s why Ethereum community refused this type of scaling since the launch and instead looks for other designs.

Ok. Let’s assume that we have hundreds or thousands of lightweight nodes that operate the solid chain on low speed. What stops us from making each node execute its own set of transactions, effectively distributing the load between all existing nodes?

One of old scaling mechanisms that followed this logic was sharding, or execution sharding. The mechanism works like this:

We make many parallel chains that are interoperable and coordinated by beacon chain that provides staking and controls validators. Then, we distribute all existing validators between all these chains, so each validator secures the chain it’s assigned to. Looks quite simple and natural - why should we all run the same chain if we can split into many groups and run our own chains that are interoperable?

Among the chains that adopted this mechanism - NEAR. At the time of writing, the network isn’t sharded due to low demand, but sharding system is integrated in protocol and may be used in the future.

What is a rollup

I’ll just assume optimistic rollups don’t exist because they’re pretty much obsolete and it’ll be much simpler to explain without them

Another scaling design which is currently chosen by Ethereum community is rollups. Rollups are separate blockchains that prove their state with transactions on the solid Layer 1 network, in our case it’s Ethereum chain. Each rollup has two way bridge built in the system, so they can interact with L1 and therefore with each other.

Re-executing all rollup transactions on L1 would be too expensive and thus would have no point, so rollups use other ways to prove their transactions’ validity without actually running them on L1. One of the ways that recently gained popularity and is recommended for new rollups is through zero knowledge proofs.

What’s zero knowledge proof? I’ll take an explanation from my previous article, because it’s useful here as well:

Well, my explanation will not be exhaustive at all, because it entirely sounds as a magic and to understand how it works internally, you should have strong knowledge in cryptography. ZK (Zero-Knowledge) proof is a set of mathematical equations that allow you to prove outputs of some computations without executing these computations yourself, either because they’re too hard for you to execute or because you don’t have some of necessary values to execute it.

“Foundations and orders of rollup-centric Ethereum“ - Alex Hook

In our case, we know all necessary values (rollup posts them on the L1 blockchain), but they’re too hard for L1 to execute so we want to avoid re-execution, that’s why we use ZK proofs.

The important characteristic of ZK proofs is that it’s hard to generate them (much harder than computations that they prove) but extremely simple (in comparison to computations that they prove) to validate. That’s because in order to generate a ZK proof to some computations, you have to “convert” all these computations to lots of mathematical equations. By that, we can move computation burden from all nodes to some sequencers with powerful machines, while nodes can enjoy low load.

Drawbacks and disadvantages (what’s worse?)

What’s the limitation of execution sharding? Let me explain using Ethereum as an example.

Currently the Ethereum network is secured by 28.2 million ETH. To attack it, you should burn 1/3 of it to prevent the chain from finalising and 2/3 of it to rollback blocks.

If we take USD and the price of 2050 USD per ETH, it’s 58 billion dollars of economic security for single chain.

All these validators secure the single chain. Let’s imagine that we create 100 shards and distribute validators between them. If previously we had 880k validators for the single chain, now we have 8.8k validators per each shard, or 580 million dollars of economic security, or at least 174 million dollars to attack one shard.

If one shard is secured by significantly less funds than it contains, it becomes profitable to attack the shard.

Therefore, sharded network can’t contain too many shards, because then their economic security will be too weak. It turns out that it’s impossible to really distribute the load among each network entity (validator node), because validators have to be divided into huge enough groups for network to remain secure.

We will rely on a number of 64 shards, because it’s used in most sharding specs and defining specific number will greatly help us with future calculations.

Ok. What about rollups? Let’s look at a lifecycle of rollup batches.

Currently, all data of L2 transactions is stored on L1.

1. Some rollup proposer (or proposers if we talk about decentralised rollups) sends the compressed batch of these transactions on L1 through calldata,

2. then some rollup sequencer (or sequencers) reads this batch from proposer's transaction on blockchain, re-executes it, generates a ZK proof of this batch’s validity and sends this proof on the smart contract on L1.

3. Smart contract executes the proof, and if it’s valid, then the batch that this proof proves is valid by definition. Smart contract updates canonical merkle root (very roughly speaking, hash of everything) of the state and then rollups nodes can keep up with the chain according to this root in the contract on L1.

Do you see a bottleneck here? Don’t worry, i’ll help you.

Storage in Ethereum blockchain is limited. I mean, very limited. How much?

One non-zero byte (you compress all zeroes down, right?) of calldata storage costs 16 gas. Ethereum block has soft limit of 15m gas. if we assume that 1/4 of all gas of the block is spent only on rollups data, we’ll be able to fit 375k/16=~229 KB of data per block.

I’ll take zkSync’s average transaction size of 177 bytes, so we get ~1324 transactions per block or ~110 TPS. This is obviously not much. And these transactions would be really expensive, because Ethereum block demand is always high, and you’ll have to pay really high fee to take 1/4 of all blockspace just for your rollup.

If Ethereum blockspace is limited, we probably have to somehow spend it more efficiently to fit more transactions? This is already made by many rollups using compression.

Wait, why do we even have to store rollups’ batches permanently, if in the end rollup nodes just listen to the latest root from the L1 smart contract?

If you already have this question, you’re right!

All rollups nodes by design use the rollup smart contract on L1 as a source of trust. If the contract isn’t buggy and L1 isn’t attacked (and it probably isn’t), then everything the contract says is truth. Therefore, thanks to the blockchain, everything the contract ever said is the truth too.

Scroll back to the scheme above. All transactions data is only used once - when sequencer takes it to generate the proof to the state they made. Then proof to the batch is verified and the system does not need these transactions anymore, because smart contract already accepted their execution in the rollup state.

Wait, doesn’t smart contract need the transaction data to execute the ZK proof to it? No! Everything the contract needs is a commitment to the data.

Explanation for people that don’t know anything about ZK cryptography: commitment is a really short data that is derived from the main data and is used to execute ZK proofs that belong to this data. However, commitment can’t be used to generate proofs, only to verify. That is, we don’t need smart contract to have the data, we can just give it the short commitment and we’re good.

Yeah, I know, it’s the freaking witchery, just believe that it works, if you want, you can read about it from people more techy than me later.

The only thing we should do is to make sure that sequencers have all necessary data to generate the proofs until they generate and send them to L1.

Sounds interesting! What if we make something on Ethereum that stores the data only as long as it’s needed?

We do! Currently Ethereum developers work (and they’re almost done!) on EIP-4844 update which enables blob transactions. Blob is some big amount of data which is stored separate from the blockchain, so it can be deleted later. The blockchain only stores the hash of the commitment to the blob, so sequencers can reveal the commitment to the contract and use it to prove the data inside the blob.

Blobs are only stored for 4096 epochs, or 131 072 blocks, or ~18.2 days. During this time, sequencers will obviously have time to generate the proof, many proving systems are already capable of generating proofs in a few minutes. And we even have some time for optimistic rollups that have to wait for 7 days, but we’ll leave it for now :)

Sounds cool! Let’s calculate how much transactions it allows us to make.

One blob is 128 KB in size, EIP-4844 (blobs spec) specifies conservative 3 blobs soft limit per block. We’ll keep 177 bytes per transaction average from above, so we get: 128 * 1024 * 3 / 177 = ~2221 transactions per block or ~185 TPS.

It’s worth noting that unlike blockspace, blobspace will only be used by rollups, so these transactions will be cheaper than blockspace ones. Also, 3 blobs soft limit was chosen for testing purposes and will be increased in the future. I expect this limit to be increased 3-4 times short-term, but I’m not a dev, so we’ll use these initial values for future computations.

Well, 185 TPS is better than 110, but still not really much. Is there anything we can do to increase this space? Hmm… What if I told you that we can divide this data into relatively small validator groups, so the system can store more data? :)

Yes, you got me right. I talk about sharding, but with data. This mechanism is called danksharding.

I won’t go into technical depths of this mechanism, especially when it’s not fully done yet and is generally quite complicated, so we likely won’t see it in the next 2-3 years, but it’s something Ethereum community actively works on, and blob transactions are obviously one of required steps for danksharding.

Basically the logic is very similar to execution sharding:

1. We split all validators into some sort of groups and distribute all incoming blobs to these groups equally.

2. They must store their blobs for certain amount of time. If any blob becomes unavailable (all validators in the group lost or pretend to lost it), these validators get slashed (deprived of the part of stake and kicked out)

3. Validators outside of this group can make sure that the data isn’t lost by asking committee for random small parts of the blob and applying some mathematical computations to them. If these points are valid, the whole blob is considered available, since it’s practically impossible for theoretical malicious actors to generate fake blobs that have same points of data as original blob. This mechanism is called Data Availability Sampling (DAS)

Wait, what? How is third part possible? Well, it’s ZK magic as well. You can read a paragraph below, but make sure that your brain won’t boil:

Remember how I told you that we can use commitment to the blob to ZK prove its contents in EVM? To make it possible, blobs were not just made as a chunk of bytes, but an array of mathematical points. All these points are provable through the commitment to the blob, therefore the more points you ask for, the less chance of malicious actor to generate all malicious points that are considered valid by the commitment.

This is very rough explanation that doesn’t do in depths, but the logic is like that. In fact, we don’t even need to know all the tech. You can read Blobspace 101 by Domothy to get a deeper techinical understanding of how it works.

So, basically danksharding is just fancy mechanism of distributing blobs to relatively small commitments of validators, so each validator don’t need to store all data. This way, the network can handle much more blobs. I’ll take the number of 192 blobs per block, because by that we form equal amount of ephemeral “groups” (64) both for execution sharding and data sharding.

Reveal your numbers!

Let’s summarise rollup scaling.

• There is a blockchain whose transactions must be confirmed by Ethereum blockchain.

• Since Ethereum network nodes are run on Raspberry Pi’s and such weak garbage for maximal possible decentralisation, we can’t just re-execute all transactions of L2 blockchain on L1, it would simply be too hard.

• Instead, we take one, two, five, doesn’t matter, expensive powerful clusters that execute extremely hard computations to generate small cryptographic proofs to transactions of our L2 blockchain.

• Then, we send this proof to special smart contract on Ethereum that verifies this proof by certain cryptographic rules. It’s much easier just to validate the proof than to re-execute these transactions, that is, we in fact move all computation burden to few powerful clusters, leaving Ethereum blockchain unloaded.

• By that, we get a blockchain that gets all security guarantees of Ethereum (because its validity is proven on it), but keeps all necessary load off Ethereum.

• However, we have to store our transaction data for some time so sequencers (these powerful clusters) can download the data and generate the proof to it. We don’t need the smart contract to have this data, since for ZK proof short commitment to data is enough.

• Storing all this data which is needed for an hour or two on the ledger that will outlive my grandchildren is a huge (and too expensive) overkill. So, we make special cells of data (blobs) that are deleted after 18 days.

• But these blobs are still not enough (they give us ~185 TPS by my computations) so we’re also going to make an update that will split all validators to some amount of groups and distribute all newcoming blobs to them. This way we can store significantly more blobs than if each validator kept all blobs.

Then, let’s summarise execution sharding scaling.

• Validators are weak because they work on cheap node hardware such as Raspberry Pi’s. Because of it, the Ethereum network can only handle, say, 15 TPS.

• We split all validators into 64 groups and make them build their own chains. All these chains are coordinated by a single beacon chain, which is run by all nodes and therefore makes all chains interoperable.

• ???

• Profit!

What do these designs have in common? It may seem that they’re completely different, but in the end we still split all validators into groups, each of which performs its own task.

The difference is, in execution sharding these groups handle execution - smart contracts, accounts, transactions, just as in the normal Ethereum chain. In danksharding, they handle temporary data for rollups.

And now, finally, side to side comparison.

Performance

Rollups: In EIP-4844 where the whole network handles 3 blobs per block, it will handle data enough for ~185 TPS, as we calculated earlier. But, if we take 64 “groups” and the same load per validator (3 blobs per block), danksharding would handle 192 blobs per block and therefore will allow rollups to perform 185*64 = ~11 840 transactions per second.

It’s worth noting that for small microtransactions such as gaming or tips it may be useful to use Validiums and off-chain data availability solutions, such as Celestia, EigenDA or Near DA. These solutions will allow us to perform much more transactions than this, while these ~12k TPS can be used for more serious payments, where full Ethereum security is necessary.

Also, blob limits will slowly be increased as tech improves. EIP-4844 limits were chosen as temporary to test the system and fix potential bugs on release. This means that with 2x increase we’ll have ~24k TPS, with 5x increase - ~60k TPS, and so on.

I believe that over time rollups teams will improve their compression mechanism as well, it’s generally a big field for potential improvements.

Sharding: It’s hard to approximate TPS limit for the single Ethereum chain since transactions take different computations - some of them are token transfers, trades on Uniswap, NFT trades, etc etc. But I think current TPS is quite accurate metric, since current demand always covers supply (all gas is spent) and it reflects average gas consumption per consumer transaction.

So, we have 12 TPS on the single chain, and we would have 64 parallel chains in execution sharding. Let’s add 3 more TPS, since we assume that rollups wouldn’t exist and therefore wouldn’t consume any gas. 15 * 64 = ~960 transactions per second.

So, we get at least ~12.3x difference in performance in favor of rollups.

Efficiency

By efficiency I mean how much work can be distributed among entities in the network.

In monolithic chain, no work is distributed. Each node has to execute all computations in the network. This way, the network can only work at the speed of the single instance of it.

In execution sharding, work can be distributed by splitting all validators into some amount of committees each working on its own chain. However, this distribution lowers economic security of each shard, because each shard has less validators than the monolithic network, and this security lowers proportionally with amount of shards.

People usually take the amount of 64 shards, because then each shard is secured by somewhat reasonable 1/64 of total stake = currently ~440k ETH = ~900m$. It means that distribution capacity doesn’t depend on amount of entities of the network, but on economical security. This way, the network can’t work at the speed of more than 64 instances of the network.

In rollup scaling with danksharding, the most computation burden is on some powerful entities that generate ZK proofs to rollup batches. All rollups work at the speed of proof generation. If proofs only for 20 transactions are generated per second, the network will handle 20 TPS, and so on.

However, proof generation speed is increased with each instance of sequencer system/s. The more provers there are, the more proofs are generated per second. The more proofs are generated, the higher is capacity of rollups. The only restriction is data availability which has practically unreachable limits mid-term.

It means that in rollup scaling, network scales with each new sequencer instance.

Tech stack

One of important technical differences of rollups and execution sharding is that while execution shards fully resemble the logic of Ethereum, rollups can be programmed to work on basically any existing stack, virtual machine, language, etc.

There are different types of zkEVMs, ZK rollups with ZK-friendly virtual machines that fully or partially resemble logic of EVM.

• Some of them, such as zkSync Era, provide only language-level compatibility, which means that you can use Solidity or Vyper for your zkSync smart contracts.

• Another rollups, such as Polygon zkEVM and Scroll, implement EVM compatibility, which means that you can re-use all existing infrastructure, including compilers, for their rollups, but they will have higher fees due to more prover complexity.

• Taiko, Type 1 zkEVM, resembles all logic of Ethereum blockchain including gas system and state trie. Because of that, it’s expected that their fees will be the highest among all zkEVMs, but that’s an option for those who need full equivalence with Ethereum tech.

There are also non-EVM rollups. Eclipse works on Solana VM, Fluent develops zkWASM, M2 is going to use Move VM which is used by Aptos and Sui, L1 blockchains. Starknet uses its own unique Cairo VM.

Besides virtual machines, there are also solutions with different DA systems. If you need full Ethereum security, you might want full rollups such as zkSync or Scroll. If you’re ok with data availability solutions based on external consensus, you can use Eclipse based on Celestia DA or Fluent based on Near DA. If you’re ready to trust single entity in exchange for near-zero fees, Validiums are your choice.

Different rollups have different decentralisation levels. zkSync currently works on switching to decentralised sequencing, which will be built in protocol. Taiko will be released with decentralised sequencing from day 0. Solutions such as Scroll and Starknet are using centralised sequencers, which may also be an option if you don’t want to take risks related to complex sequencing protocol or want to have pre-confirmations from single entity.

In turn, all shards of execution sharding resemble the same logic and work the same. You won’t be able to use different programming languages and VMs, have pre-confirmations, different gas tokens, in-built account abstraction, etc etc. Everything is Ethereum, nothing more, nothing less.

However, this diversity comes at the cost which I will cover later.

Security assumptions

ELI5 - How hard is it to attack the system, what are the losses from an attack and how easy is it to recover from an attack?

In case of execution shard, it’s just as vulnerable to finality (51%) attacks as the current Ethereum chain, which means that if certain shard is attacked, attacker can prevent shard from finalisation or roll back certain blocks, essentially stealing money. In case of attack on data availability, the worst that can happen is that rollups won’t be able to continue the chain and will likely require to roll back unconfirmed batches through their governance.

However, attack on execution shard and data availability looks completely different.

Technically, it’s much easier to store data than to run parallel execution layer. Instead of keeping up with the chain, possibly monitoring PBS, leader election, and all consensus burden, you just download some MBs of data and share with people when needed. Because of that, there would be more people storing all existing blobs from all committees than running all parallel chains. More RPCs, explorers, infrastructure solutions could afford to store everything for their products.

Moreover, unlike execution shard, data has 1/N trust assumptions. As long as any single entity stores required blob, it’s available, because you can prove that certain blob is valid with its commitment. Therefore, it becomes really hard to perform a censoring attack on blobs, because you have to somehow keep target blobs from all archive nodes. Just imagine - you can run a single archive node and you make any attack on blobs in the network impossible by oneself.

Interoperability

With execution sharding it’s obvious. All shards are interoperable by design, because they coordinate through single beacon chain and belong to the same consensus mechanism. What about rollups?

It’s completely possible to implement rollup interoperability protocol, however, such protocol requires fast finality, because we need to receive messages from L1 in the matter of blocks and be sure that message from one side won’t be reversed after its execution on the other side.

Modern proof systems already allow us to generate ZK proofs in seconds on consumer-grade PCs, but we have to remember that currently all rollups are in early stages and have “training wheels” - certain restrictions needed for fast and easy recovery of the chain in case of a bug or an exploit. One of these popular training wheels is proof delay. As example, Scroll delays batch finality by 30 minutes and zkSync delays it by ~24 hours. It’s obvious that rollups can’t effectively interact with each other with such delays.

So, in order to make rollups interoperable, we should wait until they leave their testing phase, which will probably take a long time. Why?

Consensus guarantees

In execution sharding, all shards are considered part of the Ethereum consensus. It means that if some of them contain a bug, or are attacked, it’s considered a fault of Ethereum consensus and therefore is a subject to a community fork.

It means that safety of users is guaranteed by community that will fork the chain in case of consensus fault. As example, if there was a bug that allowed malicious actor to steal ETH from people’s balances, community would make a fork update to fix this bug.

Rollups, in turn, are made by independent developers and do not count as the part of Ethereum protocol. This is not as big problem as if you had a sidechain that you can’t fork, because in rollups you at least don’t have a (attackable) consensus, but bugs still exist, and due to general complexity of modern ZK rollups, bugs are not a rare thing.

Currently rollups deal with potential bugs by running centralised sequencers (provers), having special upgradeable contracts, creating security councils that can stop the rollup in case of emergency, and other restrictions that help users not worry about security of their assets, but seriously harm trustlessness and decentralisation of protocols. These training wheels can’t last long, that’s why rollups teams spend the most money and time on bug bounties and audits in the whole ecosystem, but of course even that can’t make them sure about security of protocols that are expected to handle trillions of dollars and the whole world financial system. If they’re hacked, there’s nothing Ethereum community and consensus can help them with.

One of solutions that Aleks Gluchowski (zkSync) has suggested is the system of on-chain Courts in Ethereum. Basically the idea is to make some sort of community court that can fork L1 in case of a bug in some big protocol (DeFi or L2) important to Ethereum ecosystem. This is definitely a controversial idea, because it questions the whole “code is law” philosophy (which was already violated once) and in fact brings Ethereum back to the web2 world of human vices - corruption, corporation or government propaganda, etc etc.

Another, more technical solution is to enshrine some standardised zkEVM inside of Ethereum protocol in a form of precompile. The advantage of this idea is that we still have fork guarantees of L1, but they aren’t related to problems of certain rollup or Dapp. As long as bridge with proposing and sequencing works normally in the rollup, everything else is secured by L1 consensus.

However, its serious problem is that it doesn’t support any rollups that are different from standardised zkEVM, for optimisation reasons or because they work on a different VM. While there are ZK rollups that follow the philosophy of “as close to Ethereum as possible” such as Scroll or Taiko, rollups such as zkSync Era have their own version of EVM-like virtual machine with many features and peculiarities that don’t exist in canonical EVM, such as account abstraction and system contracts.

Conclusion

We can summarise this comparison with the table below:

While being native to Ethereum tech, execution sharding can’t scale to the levels of rollups and nearly isn’t as secure as rollups with danksharding. Danksharding, being a data sharding mechanism, is probably the most secure way to distribute data since it doesn’t rely on honest majority, blobs can be stored by anyone and single person can prevent any censoring attack on blobs this way.

In crypto, we don’t like “it works if nothing breaks”, but we have to admit that in comparison with execution sharding, danksharding is pretty much impossible to break in normal circumstances. And even if it’s broken, rollups don’t risk stolen funds, because consequences of an attack are easy to recover from, especially with well-built governance system. We still have a monolithic system secured by 60 billion dollars under the hood!

Rollups can allow developers to make their rollups fully based on their needs and easily configurable. They can create anything, from custom sequencing rules or account logic to a custom VM or a Linux runtime inside of a rollup. Rollups open actual blockchain parallelisation by allowing each entity, even if it’s your home PC, to contribute to execution of transactions in the network.

However, this all comes at a cost: rollups can’t have security guarantees of Ethereum consensus, so their development is really hard, expensive and takes long time. The work is going, and I think that in a year or two, we’ll already start to see fully interoperable rollups with shared liquidity and smart wallets that abstract the whole “rollups” term on UX side, so we can enjoy basically monolithic experience, but with distributed efficiency and bulletproof decentralisation.

Thank you for reading.

To my surprise, there are no guides of Ethereum scaling angle for developers. Yeah, you can find articles that explain what is a rollup, what are their differences, how to develop on rollups, etc. But all this looks like building on top of another chains and pretty much nothing related to what all these rollups have to do with Ethereum ecosystem and how to build your projects if you want to get the most out of Ethereum while reaching maximum scaling.

It’s expected that you have knowledge of how Ethereum works and all sharding/rollups explanations here are of a reminder nature.

What is scaling

We can define scaling as increasing blockchain network throughput without increasing node requirements, that is, how powerful PC you need to run a client of your network. Ethereum philosophy says that for the actual decentralised network, node requirements must stay at the level of consumer PCs. For example, full node takes slightly more than 1 TB of storage and such SSD can be found for ~100$. All other requirements are approximately at the level of Pi4 microcomputer.

From this fact it’s logical to assume that Ethereum network throughput is quite low. That’s right - it usually processes 12-15 transactions per second. We can’t calculate exact throughput in transactions per second, but if we assume that all transactions are ERC20 tokens transfers, we’ll have a number of 20 TPS.

Is it much? Well, if we take 100M users, it’s 0.017 transactions per day for one user or one transaction per 58 days. Obviously, this is not enough, not to mention all 8 billion people on the planet. To onboard 100M users each making 3 transactions per day, Ethereum network must process ~3472 TPS.

How’s it possible? That’s the task that Ethereum community was trying to solve for years. Previously we were working on sharding.

What is sharding

Sharding is a mechanism that splits the network into many interoperable chains, all of which are proven and coordinated by some central chain.

All of these chains should have been operated by validators distributed into small sections called committees. This system was expected to be released on Ethereum 2.0 upgrade, but it was abandoned in favor of rollups.

Rollups

Many people think that rollups are complicated, but in fact they’re even simpler than sharding mechanism. Rollups are independent blockchains whose validity is verified by the Ethereum blockchain. They’re often called Layer 2 because they in fact stay on top of Ethereum which acts as a Layer 1. How do they prove their validity? There are two basic methods.

ZK Rollups

Group of transactions is executed and bundled in the single structure called batch and sent to the Ethereum blockchain. Then, sequencer or group of sequencers generate a ZK proof of this transaction set’s validity and send this proof to the smart contract on Ethereum L1. Smart contracts executes (validates) this proof, and if it’s valid, then transactions it belongs to are valid by definition.

What is ZK proof? Well, my explanation will not be exhaustive at all, because it entirely sounds as a magic and to understand how it works internally, you should have strong knowledge in cryptography. ZK (Zero-Knowledge) proof is a set of mathematical equations that allow you to prove outputs of some computations without executing these computations yourself, either because they’re too hard for you to execute or because you don’t have some of necessary values to execute it.

In this case, we have a batch of X transactions. They all produce changes in the current network (L2 one) state. Sequencer generates ZK proof that states that if you execute all these transactions, they will all be valid and will produce required changes in the state (transfer some ETH, changing storage in some smart contract, etc).

ZK proof is crazy difficult to generate (it requires lots of GPU computations and some time), but extremely easy (compared to what computations it proves) to validate. That’s why they’re used here - we can execute all hard work off chain, and keep remaining easy work (proof execution) on chain. This way, we keep Ethereum network unloaded, but remain its security guarantees.

Optimistic rollups

ZK cryptography is really young, and when rollup scaling was just adopted, it was too undeveloped to actually prove EVM computations. Because of this, optimistic rollups were invented first.

The point of optimistic rollups is that they assume that loaded batch is valid by default, until some of rollup operators won’t prove the opposite. If some batch appears to be invalid (e.g it has a transaction that double-spent ETH), an operator sends a fault proof to L1 and if it’s valid, rollup’s smart contract on L1 reorgs the chain to remove invalid data. Fault proof is a message that asserts that some transaction inside the batch is invalid.

Among advantages, it’s lightweight. No one has to execute any hard computations and as long as one honest operator exists, the chain is safe.

However, its serious disadvantage is challenge time. In ZK rollups, batch is safe as soon as someone provides a ZK proof to it. In modern ZK rollups, it takes from 15 minutes to an hour and constantly improves. In optimistic rollups, batch is considered safe when no one has provided a fault proof to it in a certain period, which is called challenge time. Usually it’s 7 days and it can’t be lower than few hours because then it becomes possible to attack the chain.

Batch finalisation is a crucial requirement for rollup interoperability. L2→L1 messages are executed only after they’re finalised and safe. Rollup can’t effectively communicate with other rollups if its messages are delayed by 7 days each.

Here we go to the main part of article.

“Rollups are not Ethereum”

This really common point may seem fair, because unlike shard chains, which are interoperable and thus share the same liquidity, dApps, etc, rollups live completely on their own as entirely separate blockchains, and the only thing that they share is security.

However, I’d say that this is partially made by us. We’re not used to new rollup world and trying to build our projects just as we were doing it in alt-L1 era.

Here I’ll share some principles that you should follow as a developer to build efficient apps that are ready for cross-rollup interaction.

1) Be a ZK rollup maximalist

While choosing a rollup to build on, you may choose Arbitrum and Optimism for the single reason - they’re popular and already have many users, so it’ll be simpler to attract people. Now you’re trapped in the chicken-egg problem.

Arbitrum and Optimism are the most popular because they were first and attracted first people, which attracted first dApps, which attracted new people, which… you know what’s next. Arbitrum and Optimism are both optimistic rollups with 7 day challenge time, it means that they won’t effectively communicate with people on other rollups in the near future.

Ok, what’s wrong in only using these two and not using anything else? - In short, centralisation risks and stack limitations. Your project may require built-in account abstraction, general purpose languages, fast communication with L1, and other things that exist on other rollups, but not on Arbitrum and Optimism.

ZK rollup ecosystem is developing really actively. Most of them already have <=30 minutes finality. This means that no matter which ZK rollup you’ll take, as long as it’s ZK rollup, it is fast in finality and it will be even faster when technology improves.

This might all seem like a rude or biased statement, so I’ll clarify. Optimistic rollups have a right to exist, but ZK rollups are more modern in many ways and if you look for a rollup to build on, take a closer look at the rollups, even if they’re not so popular. You will not regret in the future.

2) Choose a rollup based on your needs

One non-obvious advantage of rollups over shard chains is that rollups are developed independently by various groups based on different paradigms and principles. All rollups are not alike - different zkVM/zkEVM types, account systems, proof systems, gas prices. They’re all different so that you, as a developer, can choose the one you need for your project.

If you want an experience close to Ethereum - use Scroll or Linea.
If you want an experience too close to Ethereum - use Taiko, it will cost you higher fees.
If your project is expected to execute many changes of same state elements - use zkSync, its state diff-based proof system lets you pay once for multiple state element changes. It also has built in account abstraction that you may need as well.

If you want to use WASM - use Fluent.
If you want to use Solana VM - use Eclipse.
If you want to build a private dApp - use Polygon Miden or Aztec.

There are many different systems with different features and drawbacks, and it’s worth exploring many options to choose the one that suits you best.

3) Application-specific Rollups or “RollApps”

If you feel that your project is going to be big, or you’re already the big project on Ethereum L1, it’s worth taking a look at rolling out your own rollup.

The huge advantage of this approach is that you can deal with the load yourself and you don’t have risks related to staying on general purpose rollups. Also, if your project is used really frequently, the rollup you stay on can overload and proof generation will significantly slow down, while on your own rollup you can set up sequencer rigs yourself. Users from all rollups can enjoy the same liquidity and prices, which isn’t possible when project is deployed on many chains raw.

You can make it open for everyone or restrict to your project, use EVM, SVM or no VM at all, possibilities are unrestricted. Whatever you implement, you still seriously reduce fees for users.

However, it leads to many difficulties. In particular, you have to develop and control your own chain, which is quite complex and expensive, even using existing stacks (ZK Stack, Polygon zkEVM Stack, etc). Also, you’ll probably have to make a web interface with built-in bridging to your rollup.

Generally, this approach isn’t for everyone, but for huge projects such as Uniswap, AAVE, Curve, that’s probably the best option.

4) Token-based projects

If you’re an RWA project, let’s say stablecoin, or liquid staking provider, consider not using rollups at all. If your project has a token for governance or utility purposes, deploy the token on L1. Why?

The main reason is that it’s way easier for cross-rollup transfer solutions to transfer tokens that only exist in the form of bridged L1 assets. All rollups have built-in ERC20 and ERC721 bridges, and the first liquidity that rollups gets after its launch is inherited liquidity from ERC20 tokens on L1. Mostly it’s stablecoins and liquid staking tokens.

You can always move a token to L2 if it’s deployed on L1, but not vice versa. For example, that’s the reason why native USDC on Arbitrum is still not really used compared to the natively bridged USDC.e that is also redeemed from the most bridges for the same reason. Natively deployed assets break inter-rollup supply chains by making it impossible to reorganise funds through common L1 by unbridging-bridging.

Same goes for RWAs and NFTs. You probably want your NFTs to be traded and transferred between different users on different rollups, and for these tasks it’s worth deploying on L1.

5) On cross-rollup protocols

It’s worth noting that currently no cross-rollup protocols were developed, it means that all wallets are tied to their chain and can’t use apps from another chains out of the box. Of course, such protocols will start releasing in the near future, but if you want to attract users from another rollups right now, you’ll have to implement algorithm of cross-rollup interaction with your project yourself.

I can note that such system can be built using L2→L1 and L1→L2 messages that exist in all rollups. You can use optimistic-style communication or transmit messages off-chain, the logic is on your side. However, I wouldn’t recommend using protocols that work on their own consensus such as Chainlink or LayerZero, because then you not only accept the risk of failure of Ethereum consensus, but also of the cross chain protocol.

Summary

We can summarise rules for building on rollup-centric Ethereum like this:

• Consider using ZK rollups for your project

• Choose a rollup based on your needs and not TVL or users

• If you’re a big project, consider running your own rollup

• Do not deploy to L2 tokens that you expect to be used outside this L2

• Use L1-L2 communication possibilities to unlock cross-rollup interaction

By following these rules we are paving the way to the interconnected, interoperable Ethereum future, and the solidity of Ethereum ecosystem is the key to the user experience and mass adoption.

Thanks for reading.

I’ll keep the original article uploaded for historical purposes.

Foreword: by “unavoidable“ I don’t mean that it’s impossible to get rid of some MEV, but that all smart contract networks with trustless sequencing have or will have it by default if they don’t fight it. In this article I’ll dispel some myths about MEV, particularly “Ethereum has MEV because it’s broken, chain X does not have it“ and look at different methods to fight MEV.

What do Bitcoin and high-TPS L1 maxis have in common? You probably won’t guess, so I’ll answer - they both use absence of MEV as an argument for their chains. Of course, I see these arguments as completely inappropriate. To prove it, let’s define MEV.

MEV (maximal extractable value) is a practice of block builders using their right to order transactions in their blocks at their discretion to insert certain transactions in certain positions to get additional profit.

As example, on Uniswap ETH costs 1500 USDC, and on Sushiswap it costs 1510 USDC. Block builder creates an arbitrage transaction and inserts it before anyone else’s transactions to prevent anyone from using this arbitrage opportunity before them. By that, block builder got profit from this arbitrage in addition to block reward and priority fees.

However, there are many ways how block builder can use transaction ordering for additional profit. I like this terminology from Domothy:

• Non-toxic MEV is MEV that does not affect specific users. An example above is example of such MEV.

• Toxic MEV is MEV that targets specific trades, affecting their initiators. Mostly it’s frontrunning (sandwich) attacks.

What’s frontrunning (sandwich) attack? It’ll be simpler to explain by example:

1. I want to buy 1 million USDC worth of ETH on Uniswap. I create such transaction with 1% slippage (slippage is maximum difference in price at which I’m still willing to make a trade).

2. Builder that creates a block sees my transaction in mempool, creates a transaction that buys maximum amount of ETH that does not increase the price more than by 1%, inserts it in their block, then inserts my transaction, then inserts their own transaction that sells ETH bought from their previous transaction.

3. Because my trade is large, it increases ETH/USDC ratio in the pool, which is in turn abused by the block builder. From the point of transaction ordering, it looks like that - they buy ETH cheap making it more expensive, I buy ETH for high price and make it even more expensive, they instantly sell those ETH for the new price, returning the price to previous values and receiving the profit at my expense.

It’s sometimes called sandwich attacks because our transaction is inserted right between two builder transactions, making it similar to sandwich.

While it may seem that both types of MEV are harmful, non-toxic MEV is actually helpful for users.

Before PoS, MEV was not as developed, mainly because the block reward (static 2 ETH/block) was much higher than potential MEV rewards. All arbitrages were happening with on-chain gas competition, which affected gas fees. With MEV, there is no competition for arbitrage, so users can enjoy nearly identical prices on all DEXs without suffering constant gas price “pallet“.

It looks like a great money generator, why don’t all chains have MEV-extracting builders?

With Bitcoin it’s simple. Bitcoin does not have decentralised exchanges because it does not have actual smart contracts. Bitcoin miners don’t extract MEV because there’s nothing to extract it from.

With high-TPS L1s (and by this term I mean dPoS chains), it’s because they are centralised and a right to build blocks is restricted to several entities. For example, BNB Chain has 61 validators, Polygon PoS has 100. They’re usually affiliated with chain team and have an obligation not to extract MEV.

Trustless networks are already starting to get their own MEV solutions. Solana, 3rd smart contract platform with trustless sequencing, has Jito, MEV-boosted validator client. I honestly don’t know why Avalanche, 2nd in this rating, doesn’t yet have its MEV, I assume that it’s because most of its TVL is concentrated in lending platforms and doesn’t circulate.

If we have a public transparent chain with large economic activity happening 24/7 where everyone can build their blocks how they want, it’s impossible to make sure no one’s extracting MEV or only extracting non-toxic MEV.

Is there anything we can do about it?

If we look at non-toxic MEV, I think it’s probably impossible to prevent it.

The point of arbitrage is that you buy for less in one place and sell for more in other place, leveling out supply-demand ratio and therefore price in these two places. To prevent it, arbitrager must not know what price can DEXs offer for certain pairs, which is obviously not possible.

However, preventing toxic MEV is more than possible.

One of solutions that Justin Drake (i don’t know if he was first) suggested is encrypted mempools. As far as I understood, the point is to make encrypted batch transactions which are decrypted only on execution. With this system, it’s not possible to attack certain transactions, only to make some work before and after batch execution, which greatly minimises toxic MEV possibilities.

One DEX that has similar algorithm is CoW Swap.

CoW Swap packs all trades in batches and executes them at one time, so it’s impossible to frontrun certain trade inside the batch. Batches can be created by anyone, so the system does not rely on trust.

It’s worth noting that encrypted mempools mostly are generally not intended to be enshrined in protocol, they can be used by certain protocols that want to protect their users from MEV.

MEV Burn

It’s quite off topic, because it doesn’t prevent MEV itself, but I still want to tell about it, because it’s interesting technology that can help turning MEV to something helpful for the network and from some side even for the users. Also, it’s mentioned in the Ethereum roadmap by Vitalik.

MEV Burn is the part of Proposer-Builder Separation, a proposal that separates block proposing and block building to different entities of the consensus. Its point is an election of block builder based on how much ETH they burn in their block. A simplified example:

1. Builder A has built a block that collects 1 ETH MEV and notifies the chain that their block can burn 0.5 ETH (they want to keep other 0.5 ETH for themselves)

2. Builder B has built a block that collects 0.8 ETH MEV and notifies the chain that their block can burn 0.6 ETH (that is, they’ll keep 0.2 ETH)

3. Builder bids time is ended, chain elects Builder B for building the block because it burns the most ETH.

How is it helpful for users?

Right now, ETH economics work like this: the more people use Ethereum, the higher the fees. The higher are fees, the more ETH is burned. The more ETH is burned, the higher deflation rate. If few people use Ethereum, fees become lower and ETH becomes inflationary, incentivising people to spend it more actively.

MEV burn pushes ETH economics forward: burn rate depends not only on gas usage, but also on economic activities happening on chain. The more trades, loans, etc happen on chain, the more MEV opportunities appear. The more MEV is extracted, the more ETH is burned. All next steps repeat steps from paragraph above :)

By that, Ethereum usage that affects ETH inflation/deflation rate is not just gas used, but actual economic usage by people. Roughly speaking, people can theoretically use 5m gas per block but execute so large amount of trades that ETH will still be deflationary.

In short, MEV burn raises “ultra sound money” to another level.

Summary

MEV will always exist on chains with high economic activities where block building is available for everyone, because MEV is not property of Ethereum, but property of market - making as much money as possible when possible. While it’s not possible to fully prevent MEV, we should seek for solutions that minimise damage from MEV, using encrypted mempools or any other technology. Some of them even already exist and you can use them today.

Thanks for reading.

So I’ll discuss the first thing that appeared in my twitter wall - Placeholder VC’s “Ethereum and Solana“ article. While in this article Ethereum and Solana are compared to iOS and Android and the whole point is quite abstract, I’ll talk about the main difference between them, not technical, but somewhat ideological.

The competition of most L1s comes down to solving blockchain trilemma. Blockchain trilemma says that there are three main characteristics of blockchains - security, scalability, and decentralisation. All modern blockchain systems can only have two of them, and we need to solve all three to make web3 happen.

As decentralisation is quite abstract metric, I’d change it here to Security (how much does it cost to hack the network and to recover from hacks) - Scalability - Users’ power (how many things in the network depend on ordinary users)

It’s worth noting that by power I don’t mean harmful actions of any specific person, but collective network management - in other words, how many things user community can control and change themselves if needed?

Different views on this factor, in fact, lead us to different scaling methods:

Ethereum

We can shortly define Ethereum’s scaling strategy as trying to squeeze out as much TPS as possible from Ethereum, while keeping node requirements at the level of home PCs and microcomputers not exceeding price of 100-200$ + consumer-grade SSDs.

By philosophy of Ethereum community, a real decentralised system must be possible to run by everyone, and only with this approach people can make worldwide computer compete with existing web2 world. It’s obvious that this approach imposes many difficulties to scalability that the community has been solving for a long time. In fact, all development in the Ethereum since its launch comes down to making the system more scalable while not increasing node requirements.
We can’t say that Ethereum community is done and they probably won’t be done for years, but right now they’re quite close to significant changes. Specifically, upcoming EIP-4844 update will increase bandwith in tens of times for rollups that already handle 5x TPS of Ethereum L1. This is the first significant step in solving this hard task of Ethereum philosophy.

Solana

Solana philosophy, in turn, says that technology is developing, and we should use it to the fullest. Solana node requirements are quite close to the power limit of modern server computers and the whole system is designed in the way that unnecessary load is stripped off. Needless to say that it’s impossible to run a node at home or on the average hardware, only the most powerful servers in large datacenters can handle the load.
Solana community believes that it’s completely fine if nodes are mostly run by projects on top of Solana, RPC providers etc, because they are also somewhat run by the community. In this view Ethereum vs Solana philosophy is quite close to 2017-era Bitcoin vs Bitcoin Cash philosophy.

This similarity is even reflected in the areas of development. It’s hard to say that now Bitcoin is developed at all, but in this 2017-era Bitcoin community was thinking how to scale the network keeping node requirements around microcomputer level (SegWit, Lightning, etc.), while Bitcoin Cash community was (and is) thinking how to use modern tech possibilities as efficient as possible (Xthinner, UTXO Fastsync, etc).

In case of Ethereum and Solana, Ethereum community is mostly working on ZK cryptography in rollups and Ethereum L1 itself, distributed provable storage via Danksharding - in short, technologies that help with scaling while keeping hardware requirements same. Solana community, in turn, mostly works on optimising its protocol. For example, Jump Crypto team develops Firedancer node client which is written entirely in C with Assembly and uses various memory and cryptography hacks for maximal client optimisation. It will allow protocol to work faster on modern professional-grade tech.

I consider it as the main difference between Ethereum and Solana.

A year or two ago it would be fair to simplify Ethereum vs Solana tech to decentralised vs centralised. However, if we look at the current state objectively, neither projects have single point of failure or controlled by anyone. Yes, it’s definitely simpler to control Solana than Ethereum, Solana is way more dependent on current state of tech and less “apocalypse-resistant“ than Ethereum, former also has some controversial design decisions in order to implement its view e.g leader mechanism, but I would say that now Ethereum vs Solana philosophy is something more complex than decentralised vs centralised, people vs companies, proletariat vs bourgeois (sic!), etc etc.
This leads to the fact that we can’t objectively say which approach is better. It depends on your opinion and life views, what you consider as web3 more.

What about me?

My views are closer to Ethereum philosophy. I very appreciate possibility of participating in the worldwide network even if you’re not running a commercial project or can’t afford renting a powerful server on your own. I also believe that trying to solve the main Ethereum challenge can lead to many scientific discoveries even outside the crypto space. I’m eager to help with difficulties that Ethereum community meets on its way, although I can’t say that I’m doing anything significant right now. :-)

The future will probably show who’s right. While we wait for the future, I’d like to hear your opinion about it. Mirror does not have comments, so you can comment in the posts with my article pinned.

Thanks for reading.

-

What is CBDC? CBDC (central bank digital currency) is a centralized payment system that is controlled by your country’s central bank. For its development central banks of different countries often reuse tech of existing cryptocurrency platforms, such as blockchain, elliptic curve cryptography, simple smart contracts that allow to assign purpose of payment, etc. Basically CBDC is PayPal or Visa but controlled by government rather than god knows who.

Why is it needed?
For government, it allows to easily track all criminal activities and facilitates tax collection.
For citizens, CBDC opens faster payments and usually less fees, because now you don’t have a bank or other intermediary structure that wants to get a profit, everything is unified.

Some people criticize CBDC because with it their finances are fully controlled and tracked by government. I mostly agree with this statement, however it’s worth noting that governments already do that by requesting information about certain accounts in banks, now it just becomes easier from bureaucratic point of view. Also, if we talk about democratic regimes, banks aren’t exploited to violate citizens rights, so I think CBDCs won’t be either.

Another advantage of CBDCs that mass media are talking about is simplifying the fight against corruption. When all transactions are in full view of governments’ anti-corruption agencies, it becomes really easy to find out if some contractor irrationally spent funds allocated from state budget. While I agree that it helps to fight corruption on low-level, local corruption, it does completely nothing for high, government-level corruption, which obviously accounts for the vast majority of misdirected funds.
Why? Well, if you’re a big executive guy, you can negotiate (read as “give a bribe“) with anti-corruption agency or put your people in place.

Here comes the main disadvantage of CBDCs - their privacy is reached by the total closedness and opacity of the system.

Ok, what does Ethereum have to do with it?

I think you already got me. What if we make CBDC an L2 on top of Ethereum? Now something like MetaMask or other crypto UX hell and then instant “it’s NGMI“ thought appeared in your head. To convince you, let me dream a little.

There is a Zcash-style Validium (or even a rollup if full danksharding throughput is enough) on top of some DA layer. Accounts are registered by ID, one per person and one per legal/government entity. It’s Zcash-style in the sense that there are private and public transactions protected by ZK cryptography. Individuals can send both transactions, legal and government entities (e.g companies) are forced to send and receive only public transactions by consensus. CBDC node is open-source and free to run. Projects that want to integrate CBDC can run their own nodes. Independent anti-corruption agencies can run their own nodes and check legal entities’ transactions for suspicious transfers and spendings. Emission is transparent. UTXO system can be used to assign transferred funds some sort of special code that indicates a payment purpose or spending rules (e.g government sends contractor 10 000 CBDC$ with purpose “budget for road construction“ that can only be spent on construction materials).

Government corruption

As in case of companies, we can also make state employees public.

Problem of using family members to hide bribes still exists in this system. However, in many countries state employees are forced to report about savings and property of all family members. I think a similar system could be used here. For example, we can make all family accounts public or restrict the receipt of funds not from companies/outside of work (in short, from private accounts).

Fair tenders

Did someone say smart contract?

We can use smart contracts for many things in state’s economy. For example, we can conduct fair self-executing tenders, where it’s impossible to bribe the right people to win the tender without any competition. Moreover, we can make use ZK cryptography to conduct tenders on private smart contracts, allowing us to use it for military contracts and other areas where confidentiality is required.

Because of a nature of Ethereum rollups, we aren’t restricted by Ethereum/EVM stack and can build basically any logic in our rollups, including fully functional CBDC platform on top of Ethereum L1. It means that possibilities are endless and thus building a CBDC on Ethereum isn’t really harder than another CashApp but located on central bank servers.

Fiatotokenomics

If we assume that CBDC in our ephemeral country is chosen as the main and only monetary system and put in place of cash, we can make emission fully transparent, which prevents government from hiding actual levels of inflation and where new money is going to.

More of that, we can, for example, inherit emission model from Ethereum, that is, print more money when people don’t spend it, and burn spare money when people spend it a lot. We can even stop printing money at all, but I’m not sure if it’s going to work, I’m not really an economist.

In other words, open and uncensored L2-CBDC prevents government from influencing the economy.

Yeah it sounds too good. Any disadvantages?

Of course.

The first one is that we still have to trust government to approve citizens’ IDs. It means that government agencies can create fake accounts. It can be prevented by adopting biometrical IDs but we’re really early with this one.

The second, simpler one, is that we have to make private transactions public for law enforcement agencies. It’s no secret that corruption is not the only crime that has to be tracked, for example, drug trafficking is mostly done by individuals, that is, all related transactions will be private. I’m not an expert in ZK cryptography but I think this problem can be solved by providing witnesses that are encrypted with LEA public keys along with transaction. Law enforcement agencies, in turn, can provide ZK proofs that this encrypted data is actually witness for this transaction when decrypted with their private keys.

Also, we must not forget that supervisory authority must be able to recover accounts, because phones are often stolen or broken and it’s not ok to lost your life savings because of this. We have to figure out how to prevent account recovery abuse.

What about corruption, it’s obvious that we cannot end it completely. There are still crypto, gold, cash and many other workarounds. However, I think that doesn’t mean we shouldn’t deal with it at all, and I see crypto-CBDCs as a very efficient thing for such purposes.

Conclusion

CBDCs are not so bad if implemented correctly. As a technology, CBDC is really helpful for people and national finances, but its closedness and reliance on trust to government authorities makes all of us question if it’s worth it. However, we can use Ethereum to fix CBDC and world finance in general.

Ethereum is the global unstoppable, unbreakable machine. It’s the most powerful world computer ran by independent people around the planet, and we must use it to make our countries’ economy and our finances more efficient, reliable and transparent. It’s time to use all these abstract technologies to make our everyday lives easier.

Unfortunately mirror does not have comments, but I’d like to hear your opinion and maybe some ideas about it. You can share it in comments to my posts with this article on reddit, twitter, etc.

Thank you for reading!

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