Oisín Kyne has a pretty great thread about why app-specific rollups are better than app-specific L1s for most usecases. I haven’t written about rollups for months now (outside of fractal scaling) and I haven’t kept up to date with the developments in the space. Also, as always (I know you’re tired of hearing this, but I’ll keep saying it) I have zero experience in software development and I’m just an amateur blogger and shitposter, so everything I say here may be bollocks.

But I think this post is a recap of some basics - a forgotten / underrated advantage of rollups - they have higher TPS potential than an L1. The simple reason rollups offer higher TPS than L1s, ceteris paribus, is they only need to do liveness; while L1s need to do both liveness and safety. A rollup only needs one honest party to remain safe, live and censorship resistant; while L1s need 33% for liveness and 67% for safety - high thresholds which require many validators active with a ton of money backing them for economic security. If that fails, you need a very messy social fork which can take a while to figure out; while a rollup can be resurrected by a single honest party.

Another forgotten advantage / common misconception is that a rollup can have have good liveness and CR while still having a single sequencer active at any given time. All you need is a rotation mechanism, and a transaction inclusion mechanism, and perhaps a redundancy track, all of which can be verified on its settlement layer (L1) with appropriate incentives & penalties.

Easier said than done, of course, and we’re still a while away from seeing novel sequencer decentralization mechanisms (I’m aware of at least Polygon Hermez and Optimism building these, but like I said, haven’t kept up with latest developments) built to take advantage of the efficiencies of the rollup paradigm. So, in the here and now, it’s likely some rollups use the same techniques as an app-specific L1 - i.e. some BFT consensus like Tendermint or LibraBFT. But even here, a rollup has the advantage of requiring far fewer validators, for all of the reasons mentioned above.

It’s important to note that it’s not just block producers, you also have infrastructure like dapps, wallets, users, explorers etc; but crucially for optimistic rollups you only need one honest party, while for L1s you need a large social layer running nodes. ZKRs take this further - most nodes just need to verify a succinct validity proof, no need for extensive recomputations. Yes, ZK-L1s have this advantage too, but they once again need to run many more full nodes to remain safe. There are some more nuances here, which I’ll skip for now.

So, we have established from every dimension that rollups need fewer nodes to be secure, live and censorship resistant. Intuitively, it should be obvious that if something requires fewer nodes to sync between, it can push throughput higher. But here are some examples anyway:

Ethereum today targets 60 TPS for transfers, 10 TPS for AMM swaps, with 10,000 nodes syncing. BNB Smart Chain, meanwhile, targets 120 million gas per 3.1 seconds, which equates to 1,800 TPS for transfers, 322 TPS for AMM swaps. They only have 20 validators to sync between and maybe a few dozen more infrastructure nodes - they really don’t care about anyone else. Another example is Solana mainnet vs Solana devnet; worth noting Solana doesn’t care about user nodes either, and Solana Foundation as a centralized entity subsidizes running nodes (and then chest thump on CT about number go up, of course). According to this benchmark by Dragonfly: Solana mainnet can do 273 TPS for AMM swaps - whereas the devnet can achieve 425 TPS. What about Arbitrum One? Currently, it targets 7x-10x Ethereum mainnet, which is somewhere between Ethereum and BSC. Why are they lower than BSC? Speculatively, because they are more cautious (in addition to being Nitro being brand new) about state growth - which is the primary bottleneck. Needless to say, there’s a ton of work happening to mitigate that bottleneck (Verkle tries live on devnets!), and I’m sure Arbitrum One will raise their limits once we’re closer to solving that. So, there are definitely more dynamics at play.

(Addendum: to state the obvious, we can have all sorts of novel VMs as rollups. Indeed, according to L2Beat, only 2 rollup projects are EVM today, 5 including forks, out of 25. If anything, non-EVM rollups are the norm. Consider Aztec, a UTXO-based privacy-exclusive zk-rollup; or StarkNet, a ZK-VM with parallelism to be implemented in the next upgrade; not to mention the many novel rollups in development. When I say ceteris paribus I mean comparing the same client software in an L1 configuration vs. rollup configuration.)

Consider that all of the above still assumes archaic BFT consensus being used. The real gains come when novel mechanisms are implemented which only require 1 or 2 or very few sequencers active at any given time; and most other nodes simply verify via validity proofs statelessly. A highly optimal rollup can be nearly as performant as a centralized server; though there will always be a cost overhead.

Finally, there’s the matter of L1 data bandwidth. Let’s take the most constrained L1 - Ethereum mainnet - as an example. Even now, Ethereum can handle 4,000-5,000 TPS across rollups assuming compression; and up to 15,000 TPS for highly compressible applications like StarkEx derivatives. We are a very, very long ways away from reaching this type of demand, outside of spam, all the while developers are hard at work on EIP-4844, and full danksharding after it; not to mention all of the off-chain data solutions live and being developed. E.g. Arbitrum Nova or the half dozen StarkEx projects do not need to wait for 4844/danksharding - of course with some compromises.

To be clear, app-specific L1s still have their place: a) they are further along in development and maturity, and b) some projects may want sovereignty for ideological or technical reasons. But it’s clear that for most projects in the long term, fractal scaling is the best approach to massive scale. (Yes, app-specific L1s will continue improving too, but the endgame for both as we anticipate it today is far off an app-specific rollup)

By the way, I don’t mention the security, composability and economics advantages - those are well understood (OK, maybe the atomicity/composability thing is still misunderstood) and illustrated by Oisín’s tweet which inspired this post.

Oisín Kyne has a pretty great thread about why app-specific rollups are better than app-specific L1s for most usecases. I haven’t written about rollups for months now (outside of fractal scaling) and I haven’t kept up to date with the developments in the space. Also, as always (I know you’re tired of hearing this, but I’ll keep saying it) I have zero experience in software development and I’m just an amateur blogger and shitposter, so everything I say here may be bollocks.

But I think this post is a recap of some basics - a forgotten / underrated advantage of rollups - they have higher TPS potential than an L1. The simple reason rollups offer higher TPS than L1s, ceteris paribus, is they only need to do liveness; while L1s need to do both liveness and safety. A rollup only needs one honest party to remain safe, live and censorship resistant; while L1s need 33% for liveness and 67% for safety - high thresholds which require many validators active with a ton of money backing them for economic security. If that fails, you need a very messy social fork which can take a while to figure out; while a rollup can be resurrected by a single honest party.

Another forgotten advantage / common misconception is that a rollup can have have good liveness and CR while still having a single sequencer active at any given time. All you need is a rotation mechanism, and a transaction inclusion mechanism, and perhaps a redundancy track, all of which can be verified on its settlement layer (L1) with appropriate incentives & penalties.

Easier said than done, of course, and we’re still a while away from seeing novel sequencer decentralization mechanisms (I’m aware of at least Polygon Hermez and Optimism building these, but like I said, haven’t kept up with latest developments) built to take advantage of the efficiencies of the rollup paradigm. So, in the here and now, it’s likely some rollups use the same techniques as an app-specific L1 - i.e. some BFT consensus like Tendermint or LibraBFT. But even here, a rollup has the advantage of requiring far fewer validators, for all of the reasons mentioned above.

It’s important to note that it’s not just block producers, you also have infrastructure like dapps, wallets, users, explorers etc; but crucially for optimistic rollups you only need one honest party, while for L1s you need a large social layer running nodes. ZKRs take this further - most nodes just need to verify a succinct validity proof, no need for extensive recomputations. Yes, ZK-L1s have this advantage too, but they once again need to run many more full nodes to remain safe. There are some more nuances here, which I’ll skip for now.

So, we have established from every dimension that rollups need fewer nodes to be secure, live and censorship resistant. Intuitively, it should be obvious that if something requires fewer nodes to sync between, it can push throughput higher. But here are some examples anyway:

Ethereum today targets 60 TPS for transfers, 10 TPS for AMM swaps, with 10,000 nodes syncing. BNB Smart Chain, meanwhile, targets 120 million gas per 3.1 seconds, which equates to 1,800 TPS for transfers, 322 TPS for AMM swaps. They only have 20 validators to sync between and maybe a few dozen more infrastructure nodes - they really don’t care about anyone else. Another example is Solana mainnet vs Solana devnet; worth noting Solana doesn’t care about user nodes either, and Solana Foundation as a centralized entity subsidizes running nodes (and then chest thump on CT about number go up, of course). According to this benchmark by Dragonfly: Solana mainnet can do 273 TPS for AMM swaps - whereas the devnet can achieve 425 TPS. What about Arbitrum One? Currently, it targets 7x-10x Ethereum mainnet, which is somewhere between Ethereum and BSC. Why are they lower than BSC? Speculatively, because they are more cautious (in addition to being Nitro being brand new) about state growth - which is the primary bottleneck. Needless to say, there’s a ton of work happening to mitigate that bottleneck (Verkle tries live on devnets!), and I’m sure Arbitrum One will raise their limits once we’re closer to solving that. So, there are definitely more dynamics at play.

(Addendum: to state the obvious, we can have all sorts of novel VMs as rollups. Indeed, according to L2Beat, only 2 rollup projects are EVM today, 5 including forks, out of 25. If anything, non-EVM rollups are the norm. Consider Aztec, a UTXO-based privacy-exclusive zk-rollup; or StarkNet, a ZK-VM with parallelism to be implemented in the next upgrade; not to mention the many novel rollups in development. When I say ceteris paribus I mean comparing the same client software in an L1 configuration vs. rollup configuration.)

Consider that all of the above still assumes archaic BFT consensus being used. The real gains come when novel mechanisms are implemented which only require 1 or 2 or very few sequencers active at any given time; and most other nodes simply verify via validity proofs statelessly. A highly optimal rollup can be nearly as performant as a centralized server; though there will always be a cost overhead.

Finally, there’s the matter of L1 data bandwidth. Let’s take the most constrained L1 - Ethereum mainnet - as an example. Even now, Ethereum can handle 4,000-5,000 TPS across rollups assuming compression; and up to 15,000 TPS for highly compressible applications like StarkEx derivatives. We are a very, very long ways away from reaching this type of demand, outside of spam, all the while developers are hard at work on EIP-4844, and full danksharding after it; not to mention all of the off-chain data solutions live and being developed. E.g. Arbitrum Nova or the half dozen StarkEx projects do not need to wait for 4844/danksharding - of course with some compromises.

To be clear, app-specific L1s still have their place: a) they are further along in development and maturity, and b) some projects may want sovereignty for ideological or technical reasons. But it’s clear that for most projects in the long term, fractal scaling is the best approach to massive scale. (Yes, app-specific L1s will continue improving too, but the endgame for both as we anticipate it today is far off an app-specific rollup)

By the way, I don’t mention the security, composability and economics advantages - those are well understood (OK, maybe the atomicity/composability thing is still misunderstood) and illustrated by Oisín’s tweet which inspired this post.