A pessimistic future for optimistic rollups

“The absence of evidence is not the evidence of absence”
- Carl Sagan

Optimistic rollups like Arbitrum and Optimism have been gaining increasing attention lately, and many dApps and users have begun considering migrating to optimistic solutions as momentum for Layer 2 adoption builds.

At a glance, it looks like Optimistic rollups may soon secure a permanent role within the greater blockchain ecosystem as a scaling layer for Ethereum’s rock solid consensus, delivering the best of both worlds to users: Ethereum-level security and high transaction capacity — Providing a great service to the blockchain industry as a whole.

But looks, alas, can be deceiving.

In fact, as we look closer, it becomes increasingly clear that Optimistic rollups neither provide a meaningful increase in blockchain scale nor do they guarantee or even approximate the security of Ethereum.

Methodology

In this blog post, we will consider Arbitrum as it is the largest Optimistic Rollup at the time of writing, but most if not all of the points made are generally applicable to other Optimistic rollups.

In the spirit of objectivity and fairness, we will focus on evaluating the two key value propositions/claims of made on the Arbitrum official website:

1. Optimistic Rollups are a “Secure Scaling Solution for Ethereum” with innovative high-throughput
2. Optimistic Rollups have “Ethereum-level” security (or as the Arbitrum team puts it, the claim that Arbitrum “inherits Ethereum-level security”)

Source: https://arbitrum.io/

Source: https://developer.arbitrum.io/intro#q-hello-whats-arbitrum

Finally, we will finish the post on an Optimistic note for the future of blockchain security and scalability, powered by ZK:

While Optimistic rollups don’t meaningfully contribute to blockchain security or scalability, there is an rising technology that can: Zero Knowledge Proofs (ZKP)

Optimistic Security Fallacy 1: AIT AIT AIT AIT

At the core of Optimistic rollup’s claim to “inherit Ethereum”’s security is the way in which fraudulent transactions can be stopped from gaining finality. Let’s consider Aribtrum’s security model:

1. The Arbitrum internal team operates a centralized sequencer node that orders the transaction. This node centrally decides which transactions are processed at a what time, and can any transactions it likes (we have already sacrificed Ethereum’s censorship resistance)
2. The centralized sequencer operated by the Arbitrum internal team submits the call data need to reconstruct the L2 transactions to L1 (this is necessarily faster than actually executing the transactions, otherwise everyone might as well just execute on L1).
3. A group of “defensive validators” picked by the Arbitrum internal team listen to transactions from the centralized sequencer operated by the Arbitrum internal team and process the transactions locally.
4. The defensive validators picked by the Arbitrum internal team then execute the transactions sent to them by the Arbitrum internal team and make sure the execution data matches the data submitted on chain by the Arbitrum internal team.
5. If the Arbitrum internal team submits incorrect information about a transaction, the the defensive validators picked by the Arbitrum internal team can challenge the execution, but once the challenge occurs, the challenge is paused to give time for the Arbitrum internal team to upgrade the smart contracts in collaboration with the close partners of the Arbitrum Security Council (a group of folks well connected and including the Arbitrum internal team).

Sounds like Ethereum-level security to me!

A helpful list of the defensive validators selected by the Arbitrum internal team: https://docs.arbitrum.foundation/state-of-progressive-decentralization#arbitrum-one

When the Arbitrum internal team submits a fraudulent transaction and is challenged, it is clearly a great time to allow for updating the logic of the contract which processes the challenge (hmmmmmmm): https://developer.arbitrum.io/proving/challenge-manager

hmmmmmm…… (https://developer.arbitrum.io/proving/challenge-manager)

https://docs.arbitrum.foundation/state-of-progressive-decentralization#2-validator-ownership

Dr. Evil agrees that the Arbitrum Internal Team could never steal your money.

Optimistic Security Fallacy 2: Self Inconsistency

In our second note we mentioned that “The centralized sequencer operated by the Arbitrum internal team submits the call data need to reconstruct the L2 transactions to L1 (this is necessarily faster than actually executing the transactions, otherwise everyone might as well just execute on L1).”.

Let’s dive into that a bit more deeply, noting that this describes the call to the function addSequencerL2BatchFromOrigin on chain:

1. The call to addSequencerL2BatchFromOrigin must contain all the data necessary to reconstitute the state, as the centralized sequencer could just decide not to send anyone the data necessary to check if they were submitting fraudulent transactions (otherwise no one could create a challenge/fraud proof or even verify if fraud had occurred).
2. The execution running time of addSequencerL2BatchFromOrigin must be faster than the sum of the running time of all the transactions it attests to (otherwise you might as well just execute the transactions on Ethereum instead of on Arbitrum).

So if the data feed from the Arbitrum internal team is cut off, the validators get the execution data to check the validity of l2 batches posted by the arbitrum internal team. They can derive the EVM transactions from the stuff posted on chain, and execute locally.

But, by the time the validators have derived and executed one batch of transactions posted on L1, the sequencer could have posted 5 more batches on chain.

Ethereum-level security

Are Optimistic Rollups Scaling Ethereum?

Now that we know Optimistic rollup’s core thesis is self-inconsistent due to the inability of validators to ever catch up if the sequencer is compromised, we can at least give them some points for scale, right? Unlike some adjectives that blockchains like to describe themselves with (innovative, revolutionary, etc.), the word scale describes something we can measure and compare how well Arbitrum using unimpeachable, real world data.

To judge claim that a side chain X is a “Scaling Layer” for chain Y, we need to measure how much more scalable chain X is than chain Y (is it 10 times as scalable, 100 times as scalable, etc).

To measure the veracity of the scalability claim made by optimistic rollups, we can find the maximum scalability factor (a number that tells us how much better chain X is at scaling than chain Y) by dividing the maximum sustained TPS of side chain X by the maximum sustained TPS of chain Y:

We can measure how much better chain X is at scaling than chain Y calculating the Scalability Factor

Knowing how much investor money has been poured into Optimistic rollup technology and the bold claims made by projects like Arbitrum, we know that the world’s most popular optimistic rollup will be far more scalable than Ethereum. But, just to be sure, let’s calculate and see for ourselves.

To do our scaling analysis, we can use a great tool called Dune.com to run a SQL query on all of the historical data to precisely calculate the Scalability Factor for Aribtrum and others:

WITH bt AS (
SELECT
    DATE_TRUNC('{{Time Granularity}}', NOW()) - interval '{{Trailing Num Periods}}' {{Time Granularity}} AS dtmin,
    DATE_TRUNC('{{Time Granularity}}', NOW()) AS dtmax
)

SELECT 
chain
, cast(num_txs as double)/90.0 AS num_txs_per_day
, cast(num_txs as double)/(90.0 * (60.0*60.0*24.0) ) AS num_txs_per_second
FROM
(
    SELECT 'Optimism' as chain ,COUNT(*) AS num_txs FROM optimism.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    AND to NOT IN (SELECT address FROM labels.system_addresses WHERE blockchain = 'optimism' )
    UNION ALL
    SELECT 'Arbitrum' as chain ,COUNT(*) AS num_txs FROM arbitrum.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    AND to NOT IN (SELECT address FROM labels.system_addresses WHERE blockchain = 'arbitrum' )
    UNION ALL
    SELECT 'Ethereum' as chain ,COUNT(*) AS num_txs FROM ethereum.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    AND to NOT IN (SELECT address FROM labels.system_addresses WHERE blockchain = 'ethereum' )
    UNION ALL
    SELECT 'Solana' as chain ,COUNT(*) AS num_txs FROM solana.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    UNION ALL
    SELECT 'Polygon' as chain ,COUNT(*) AS num_txs FROM polygon.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    AND to NOT IN (SELECT address FROM labels.system_addresses WHERE blockchain = 'polygon' )
    UNION ALL
    SELECT 'BNB' as chain ,COUNT(*) AS num_txs FROM bnb.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    AND to NOT IN (SELECT address FROM labels.system_addresses WHERE blockchain = 'bnb' )
    UNION ALL
    
    SELECT 'Avalanche C-Chain' as chain ,COUNT(*) AS num_txs FROM avalanche_c.transactions WHERE block_time > (SELECT dtmin FROM bt) AND block_time < (SELECT dtmax FROM bt)
    AND to NOT IN (SELECT address FROM labels.system_addresses WHERE blockchain = 'avalanche_c' )
    ) as tps_info

Ok, now let’s run our query and check the results!

Reproducable Query: https://dune.com/cjf/scaling-stats

We now know the average TPS for Ethereum is 12.11, so we can also calculate the scaling factors for Aribtrum and Optimism:

• Aribtrum Average TPS = 11.24, ARB Scaling Factor = 11.24/12.11 = 0.928
• Optimism Average TPS = 3.95 OP Scaling Factor = 3.95/12.11 = 0.326

Hence, Optimistic rollups have not come close to providing anything like a significant leap forward in scale for Ethereum.

You would need 30 isolated Arbitrum’s (no communication between rollups) to approach Solana scale let alone the Web2 scale that many fans expect Layer 2’s to one day deliver.

A Slow AWS: #NotMyL2

Blockchain has value because people know that transactions are final, computation is secure, and state integrity is preserved at all costs. No one can ever touch their money as long as they have their own keys.

People only put up with our low scalability and poor user experience because of this.

So Optimistic rollups beg the question:

Is it a prudent idea for the Blockchain community to surrender our only advantages for such a pitiful increase in scalability?

But we need to scale up as a community, so are we doomed to transform into slow AWS controlled by cabals/DAOs less trustworthy than Amazon?

Don’t trust AIT, Trust Math

Zero Knowledge Proofs can provide off chain computation without the need for an Arbitrum internal team or security council, and recursive ZKP can provide far higher scale than these “Optimistic” chains.

In a future article we will discuss some of these solutions, but in general:’

If you want to build a dApp, build it on Scroll, Kakarot, QED, Starknet, Polygon or zkSync.

Sleep well at night knowing the only think you will need to trust is Math.