# Rollups do not reduce latency
The **success of Solana** took the Ethereum ecosystem by storm, leading to the re-thinking of the perspective taken to tackle the [Blockchain trilemma](https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#this-sounds-like-theres-some-kind-of-scalability-trilemma-at-play-what-is-this-trilemma-and-can-we-break-through-it) in the Ethereum roadmap: from decentralization and security first and foremost, Ethereum's **rollup-centric roadmap** has taken a more pragmatic approach: **prioritize scalability**, even if at the cost of some of the security and decentralization.

It is however currently **impossible to get unlimited throughput at sub-second latencies** with the security and decentralization that Ethereum advertises, contrary to what it may seem by the way rollups are being used. A trilemma is a trilemma for a reason, and compromises must be made, but the path the Ethereum ecosystem has been taking so far might be misleading to some users and applications building on top of it, and I think it is worth explaining to the non-experts the dangers of using Ethereum as it stands now.

## What are L2s

From the perspective of the Ethereum blockchain, L2s are smart contracts. Those smart contracts enjoy the commitment credibility that the Ethereum blockchain poses as a [**credible commitment machine**](https://docs.onebalance.io/technical-details/credible-commitment-machine-ccm), which offers arguably the greatest level of decentralization and one of the greatest levels of security currently available.

Like any other smart contract, users can call functions of this smart contract. Users can choose to deposit their funds into this smart contract, known as **bridge contract**, and in exchange, they get credited the same amount of funds in an **alternative execution environment** that represents the L2. From that moment on until users withdraw their funds back to L1 (Ethereum), users stop moving their funds at the Ethereum blockchai. Still, they can instead **interact** with any other account or contract **in the same execution environment** of that same L2.

Interactions that take place in an execution environment outside of Ethereum are however **not necessarily protected** by the credible commitment machine of Ethereum, and may thus be operating at **different security assumptions**. However, rollups (once they reach stage 2, at least), the most popular type of L2, eventually inherit the security of Ethereum via proving systems (based on zero-knowledge or optimistic designs).

## Why a rollup-centric roadmap?

Perhaps the best explanation for the appearance of L2s in the Ethereum ecosystem can come from some of the most experienced voices. At the recent Ethereum interops forum (November 16, 2024) [Mark Tyneway, Co-founder of Optimism](https://youtu.be/VCxv1s_hz54?t=242) said "I do not think we would be here right now if it was not for Solana". He was shortly followed by Marcin Michalski, Chief Protocol Architect at ZKsync: "We are all here maybe **sponsored by Solana**".

Though these are but opinions, I share the sentiment that the fact that Solana offered incredibly low latency, transaction costs, and high throughput, capturing with this trade-off of the trilemma an astonishing amount of activity, even if **re-adjusting** the stance on **security and decentralization**, **shaped the Ethereum roadmap** to become rollup-centric. Nevertheless, why the roadmap came to be is but a contextualization of this write-up, and I would rather the reader not fixate on his potentially disagreeing opinion here and instead invite him to agree to disagree while bearing with me.

So what does the rollup-centric roadmap have to do with Solana? The answer lies in the **user experience** of a user when its funds are in L1 compared to when they are in a rollup, let us use an example. Suppose Alice has 10 ETH and over time wants to make 5 simple transfers for 5 coffees (priced at $5 per coffee) at Starbucks over the scope of a week (Alice has a coffee at Starbucks every morning):
- If Alice has these 10 ETH **in L1**, then every morning that Alice makes her order:
- Alice will need to wait **~12 seconds** until Starbucks can even see her transaction at a 0-confirmation level on L1, which may be acceptable for this example but for other automated processes it is far **too much time**. Besides, this transaction may end up outside of the canonical chain (Starbucks does not get paid). Preconfirmations can offer subsecond guarantees, at even lower commitment credibility. The greatest level of security takes **~12 minutes** if Starbucks wants to make sure this transaction will not suffer a reorg.
- Alice will need to pay the equivalent of [$1.10](https://l2fees.info/) (as of November 25, 2024) per transaction, so by the end of the week Alice will have spent more than the price of a coffee **just in fees**. If using preconfirmations, Alice will pay even a bit more.
- If instead Alice has these 10 ETH **in a rollup** where Starbucks accepts payments (say Scroll), then:
- Starbucks can verify and accept the payment with a **negligible delay** (in the order of a second), if it trusts Scroll (more on this later).
- The cost per transaction is in the order of **less than a penny** ($0.01), which Alice does not care about.

Clearly, out of the two user experiences, the latter one is preferable for Alice, as it aligns with her familiarity with Visa or Mastercard. This is the reason that many applications, like [ether.fi](https://www.ether.fi/), a crypto-backed, non-custodial card provider, launched its services in Scroll, and not in Ethereum's L1.

### Rollups vs other options

Note that this example is only a simplification, other L2/off-chain solutions that have existed for a long time may do the job just at competitive trade-offs, like payment/state channels and networks, or subnets/childchains, for example. Of course, Alice could just use Solana instead, or some other ecosystem.

Without getting into too many details:
- Rollups, subnets, sharded solutions, and other L1s offer a **more blockchain-like user experience** compared with payment/state channels and networks, where users have to worry about whom to open and rebalance channels with, how to route channels while preserving payments private (along with their balance and IP, that they must advertise), or which watchtowers to outsource the fraud-proving to, among others.
- Using other L1s means not being able to easily tap into **the greatest Turing-complete execution environment** in the world: Ethereum.
- Subnets/childchains do not **prove their state transitions** on Ethereum, meaning that their operators can easily steal user funds if they so desire.
- Sharded solutions are significantly complex and modify the L1 architecture whereas rollups can **comfortably explore different trade-offs** of the trilemma without affecting the core L1 architecture's.

As a result, rollups offer an incredible opportunity for the Ethereum ecosystem to achieve the same goals while **outsourcing challenges** from L1's protocol to the community (rollups).

It is not the purpose of this document to detail all challenges that come with the rollup-centric roadmap, like fragmentation ([more on that in this other doc](https://hackmd.io/L9It-uy2QgiMIHL3TB94ug?both)). We will only focus here on the dangers to users from a **safety perspective**, because it is a challenge that we, as a community, are not voicing enough.

## What rollups can do inheriting Ethereum security

I said before that rollups prove their state transitions on the Ethereum L1. Does this mean that we can use all the benefits of rollups while inheriting the security and decentralization of Ethereum? Unfortunately, the answer to this is no, not all of them.

The first reason why **rollups may not be as safe** as I have previously said are **training wheels**. L2beats is doing fantastic work at tracking the [different stages of rollups](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) w.r.t. training wheels, being stage 2 the last stage without any training wheel.

A stage 2 rollup is then supposed to be safe and to inherit the security of Ethereum. This is true, but not for all use cases. There are three use cases of stage 2 rollups that completely inherit Ethereum-level security. Let us describe them in the example above of Alice:
- If Alice made the payment in a **zk rollup**, then Starbucks must wait for the **L1 finalization** of the transaction that **proves the state transition** containing the payment to Starbucks.
- If Alice made the payment in an **optimistic rollup**, then Starbucks can either:
- Wait for **finalization of the commitment** of the state transition containing the payment to Starbucks, download the entire state **and verify its execution** locally, or
- Wait for the **fraud-proving period** to finish.

In these three cases, it is clear that for Starbucks to inherit the **security of Ethereum** it **must bear** at least the **latency of Ethereum** (or even more in the optimistic case if waiting for the fraud-proving period). It is for this reason that, from the perspective of inheriting Ethereum's security and decentralization, **rollups increase throughput and reduce costs, but do not reduce latency**. Starbucks should not give Alice her coffee for ~12 minutes if Starbucks wants to get the security of Ethereum finality for her payment. It can however perform the payment in a stage 2 rollup while enjoying Ethereum-level security.

## What rollups cannot do inheriting Ethereum security

If the reader wants a takeaway from this document, let me restate it again: **stage 2 rollups increase throughput and reduce costs, but do not reduce latency** (at the level of security of Ethereum). We do not have the technology to provide infinite throughput at subsecond latencies at the security level of Ethereum finality.

And yet, we see more and more applications like **ether.fi**, that, as mentioned above, offers real-world crypto-backed, non-custodial credit cards that users can use to perform payments that take in the order of a second. There are also app-chain rollups like [**Aevo**](https://www.conduit.xyz/dex), a DEX that, in their own words, offers "decentralized Trading With CEX-Like performance", and a hot topic at the moment is [**app-specific sequencing**](https://www.youtube.com/watch?v=lLR_6tnKL2I) (dedicated mini-subnets in that they only do sequencing and not proving). **Preconfirmations** also came to offer lower latency than the usual Ethereum blocktime to based rollups like [**Taiko**](https://taiko.xyz/) (rollups whose sequencers are L1 proposers). How can ether.fi, Aevo, app-specific sequencers, or Taiko, to name a few, **inherit Ethereum level security at subsecond latencies**? the answer is **they cannot**.

### Safety risks with subsecond latencies

**Stage 2 rollups cannot prevent liveness**. In other words, they cannot lock or censor the movement of their users' funds forever. They also cannot forge signatures to withdraw their user funds (because of the proving systems). What they can do if their users and apps do not wait for Ethereum-level security (and instead perform real-world, offchain actions after subsecond latencies) is to **break safety by equivocating**. This is what is commonly known as a **double spend**. It should be noted though that a double spend is only one type of equivocation. Equivocations can cause triple, quadruple, quintuple, or any number of multiple spends. Equivocation in the context of a rollup involves the following:

1. Alice and the rollup's commitment machine (i.e. the centralized sequencer in most rollups) **collude together**,
2. Alice **sends to Starbucks 10 ETH** worth of coffee, and suppose Starbucks only checks for the subsecond latency of the rollup's sequencer confirming a state transition containing Alice's payment,
3. Alice colludes now with the sequencer to create an alternative, conflicting state transition in which instead it gets **the same 10 ETH** worth of coffee at **Tim Horton's**.
4. The result is **Alice getting 20 ETH worth of coffee with only 10 ETH**.

No human needs 10 ETH worth of coffee at the current valuation. I intentionally did not want to pick a real-world application for this malicious scenario. But feel free to replace coffee with DEX transactions (like Aevo's), payments made via a crypto-backed credit card (like ether.fi's), or generic payments made in any generic rollup and its many applications (like Scroll's).

The above example was a double spend, but Alice could have continued colluding with the sequencer to get its 10 ETH worth of coffee **again at Costa coffee** (triple spend), **again at Mcdonald's** (quadruple spend), and again and again and again (multiple spend). So long as there are different coffee shops (clients) to equivocate to in the span of a few seconds, and so long as these coffee shops simply trust what the sequencer says without waiting for commitments on L1, or checking results with each other, Alice will be **able to keep spending her 10 ETH** worth of coffee and walking away with an **offchain** representation of her 10 ETH (coffee) that, unlike state transitions, **cannot be reverted**.

### Has this ever happened though?

No, **no rollup has maliciously reverted state** to equivocate yet. Even if this had happened already, rollups are **still on training wheels** and not stage 2, so there would be a **plausible justification**, even if this attack can be performed for stage 2 rollups.

However, there are **numerous examples** of equivocation attacks that are possible in rollups that took place **in L1s**, followed by examples like the one I outlined above (but more realistic than coffee shops). I will list here three: double spendings of [US$70,000](https://news.bitcoin.com/bitcoin-gold-51-attacked-network-loses-70000-in-double-spends/) and [US$18](https://news.bitcoin.com/bitcoin-gold-hacked-for-18-million/) million in Bitcoin Gold, and of [US$5.6](https://news.bitcoin.com/5-6-million-stolen-as-etc-team-finally-acknowledge-the-51-attack-on-network/) million in Ethereum Classic. Notably, these attacks required **at least controlling 51% of the power** in the system (actually less than 51%, but let us not get into this now), as these systems had a **decentralized consensus** mechanism as the first line of **defense for equivocation** prevention. With app-specific sequencing, rollup SDKs, or in fact for most main rollups at the moment, we can have low latency off-chain actions via **centralized sequencing**, making **attacks** like the ones mentioned above **much easier** to perform, since they do not require coordination of multiple actors.

## So what now? The spectrum of economic security
Are we then doomed? What should we do? Why can Solana do this but when rollups do it I am raising concerns?

To be clear, I do not think we should not continue on the same path we are going, as long as we, as a community, are **clear about the dangers of the different levels of latency**. A credible commitment machine is whatever system we use for commitments (call them preconfs, confirmations, or finality) that the observer is happy with believing (non-equivocation is ruled out by the observer).

**No system makes a perfect credible commitment machine**. There are always security considerations. All we want is a system where breaking security is not really cost-effective given the assumptions we create (or that the observer has). This is where economic security comes in.

We can see the **security-latency** trade-off of the different options in Ethereum as a **spectrum**. On the left end, we have the **lowest latency** that preconfs (whether by L1 proposers or L2 sequencers) give, which typically comes with the **lowest level of security**, only backed by the **slashable stake** of the preconfer, if any. The level of security for these is, thus, the amount of stake slashed to the preconfer (or preconfers, if the preconf derives from a consensus protocol run by multiple entities) if it dishonors the preconf. The **less stake, the less security**. Typically, the **more stake**, the more security, but it is also expected that **more latency** will be associated with this, or security can suffer from the lack of **decentralization**. The level of security provided by a slashable stake of 1k ETH, all controlled by the same entity, is typically considered less than that of the same amount of slashable stake but in a decentralized scenario where an equivocation attack requires coordination across hundreds or thousands of different entities (what is commonly known as no honor among thieves).

On the other far end of the spectrum, we have **L1 finality**, at the **greatest latency**, at 12-24 minutes latency at the moment (Note: this will possibly be reduced to 36 seconds via 3-slot finality, or even 12 seconds if slot-time is reduced to 4 seconds as proposed by Justin Drake's Beam chain).

Somewhere in the **middle of the spectrum**, we have L1 confirmations (1-confirmation, 2-confirmations, etc.), with each confirmation increasing in latency and security if the block remains as part of the heaviest chain. Also somewhere in the middle of the spectrum, we find decentralized rollups/L2s with significant slashable stake. For example, a rollup in which 10 entities stake 32 ETH and run consensus has lower latency but less security than a rollup with 100 entities, each staking 32 ETH and running the same consensus.

Decentralization and slashable stake via equivocation proofs will be key to increasing confidence in off-chain actions at low latency as rollups want to do. Many rollups and architectures will compete here for a reasonable portion of the spectrum, each with their trade-offs. But at the moment this is a path that is not thoroughly explored by most rollups given the **incentive misalignment** caused by the community: **nobody cares** about this level of **security** but **everybody cares** about **cheaper fees, lower latencies, and greater throughputs**.

## Mitigations: low-hanging fruits
Regardless of the approach for lower latency, there are low-hanging fruits and other remarks to consider for this trade-off between security and latency. Besides the already mentioned decentralization and slashable stake via equivocation proofs, we list a few others:
- **DA Inclusion preconfs**: via inclusion preconfs of the next state transition from the next L1-sequencer, a centralized L2-sequencer can increase the confidence in L2-level preconfs, as an equivocation would then require collaboration from the L1 proposer via dishonoring the inclusion preconf.
- **Out-of-protocol incentives**: it should be noted that the reputation of centralized sequencers is a non-negligible actor in trusting their L2 preconfs. Scroll's centralized sequencer has the most interest in the success of the Scroll ecosystem. People prefer to follow the law given the punishment strategies implemented in the real world, so this reputation and web2 level of trust is probably enough for many applications. This is harder to argue for based rollups and L1 preconfs, whose preconfers are entities that may not have any out-of-protocol incentive to preserve the reputation of the particular based rollups. Out-of-protocol incentives can also play against security, though, as real-world incentives are much harder to map than in-protocol ones. This is the reason why people are deceived in the real world (miscalculation of utility functions of the party we interact with and that lies to us).
- **Public commitments**: a vital layer of security involves requiring preconfers to publicly commit to a preconf via distributing it through a gossip network (e.g. Eth's GossipSub). Although this is not yet consensus, it can be a useful metric for off-chain action providers to track the confidence in the preconfs being honored and an effective deterrent against a malicious adversary that cannot easily manipulate the network. This is one way in which multiple clients and users can quickly contrast their views of the given preconfs without having to run a slow consensus protocol.
- **Layered latencies per app/rollup/preconfer**: it is just not possible to make an infinite amount of preconfs secure (i.e. incentive-compatible) at subsecond latencies. But a number of them may be (whatever number is enough given the observer's assumptions and the amount of slashable stake). Paired with some other mitigations like the ones shown above, applications may **offer a limit on the number of off-chain actions they recommend per unit of time**. For example, Aevo can perhaps accept the first DEX movements of up to an equivalent of 100,000 ETH in one second, but the next 100,000 to 1M ETH are purposedly warned to their respective users to wait for another 15 seconds before carrying off-chain actions, and the next 1M to 10M may want to wait for 3 confirmations of the corresponding commitment on L1 (36 seconds from commitment). This helps align incentives and rescue the spirit of trustless interactions that justifies Blockchains.

## Is it that much of a problem?

No, it is not a problem to have **training wheels** temporarily for economic security and incentive compatibility of ridiculously low latencies, much like stage 0,1 or 2 rollups. This **is normal**. There is a reason why finality takes longer: preconfs are not a confirmation and confirmations are not finality. Regardless, credit cards like ether.fi (or potentially Starbucks) are great products and it makes me excited that we enable more applications already, this is much better than waiting to having everything figured out. In any case, the worst-case scenario is that the systems we build fall back to web2-level, real-world law enforcement guarantees.

Nevertheless, same as it is fine to use stage 0 or 1 rollups while we figure it out and warn apps and users that they are not using stage 2 rollups, we should **warn apps and users of the dangers of faster-than-Ethereum latencies for stage 2 rollups**. I would be embarrassed if a set of users/apps angrily trashed on Ethereum after they suffered a double spend when they did everything the community was telling them to do to be completely safe: use/build on a stage 2 rollup. We have to be careful not to mislead, as a community, and be more transparent about the security implications, so let me say it again: **rollups do not reduce latency from the perspective of L1-level security**, but they do increase throughput and offer varying levels of security at different lower latency trade-offs.

Warning apps and users as a standard will put pressure on rollups to finally care about security for faster-than-Ethereum latencies, preventing the embarrassment of future potential attacks to us, the Ethereum community.

## What next?
A few weeks back at devcon I took the chance to create **more awareness** and discuss this with Ethereum colleagues. I was glad to hear from Luca Donnoh that **L2beats is already working** on something along these lines, and I look forward to seeing what comes out of it. I plan to continue my contribution on this subject while at Scroll by proposing (perhaps jointly with other colleagues in the community, feel free to ping) a **framework to analyze the economic security and incentive-compatibility of rollups** for apps and users that need to operate **at faster-than-Ethereum latency**, and making sure that we at Scroll uphold a level of security that is transparent and reasonable for our users and builders. Fortunately, I do not come barehanded into this task, as much of the work we did at [Filecoin for IPC subnets' collateral and their incentive compatibility](https://github.com/ranchalp/collateral-analysis?tab=readme-ov-file) can be reused in this case. Further outlining this framework will be the scope of a different write-up. Stay tuned!