Ethereum’s L2s are said to inherit its “security,” but what exactly does that mean? Depending on which rollup you ask, you may receive a different answer!
While every rollup aspires towards complete trustlesness, all of Ethereum’s optimistic and zero-knowledge scaling solutions are currently dependent on some form of training wheels.
Vitalik provides an excellent framework to help rollup users understand to what extent they are trusting centralized actors or transparent code. The Stage 2 milestone-based category in this taxonomy is the end-game for rollup security and requires the complete removal of the centralized dependencies Vitalik terms “training wheels” – which the L2Beat diagrams further below encapsulate so well.
Few rollups hold the prestigious Stage 2 designation, but Arbitrum is making strides towards becoming the first of note! At the start of August, Offchain Labs (the team building Arbitrum) announced a new permissionless validation scheme for the chain – the Bounded Liquidity Delay (BOLD), which harden its dispute protocol against a form of denial of service attack known as a “delay attack.”
Each L2 is taking off their training wheels at a different pace, however, and today, we’re exploring the journey that lies ahead for Ethereum’s five largest generalized L2s as they work to eliminate centralized risk vectors from their rollups in the pursuit of the elusive Stage 2 designation!
⚪ Arbitrum One
Risk Stage: 1
Type: Optimistic
TVL: $5.41B
Source: L2Beat
Arbitrum One has successfully mitigated more centralization risks than any other chain on this list! Should the ArbitrumDAO move to adopt BOLD on One, the chain will turn the state validation segment green, but advancing to Stage 2 requires the entire risk diagram to become green.
Progressing upgradability will require two changes to occur. First, the implementation delay for governance-initiated upgrades must be extended from 12 to 30 days. Second, no actor should be able to immediately upgrade Arbitrum’s code in the event there are no provable bugs.
The ultimate training wheel, Arbitrum’s security council, is directly elected by the DAO and has the ability to bypass governance to implement upgrades without delay. In spite of Arbitrum One’s best efforts to mitigate centralization risks, the security of your assets on the chain are dependent on the honesty of this omnipotent 9-of-12 multisig!
Given the risks of operating a rollup, the Security Council is accepted as a net positive for the Arbitrum ecosystem, however to become a Stage 2 rollup, Arbitrum will need to restrict it to only responding to onchain provable bugs.
This will further secure Arbitrum One for users and ensure that (in the event there are no bugs) actors cannot post state roots that override the rollup’s proof system.
🔴 Optimism
Risk Stage: 0
Type: Optimistic
TVL: $2.67B
Source: L2Beat
Casual crypto observers often assume Arbitrum and Optimism have similar security guarantees, as both style themselves optimistic rollups. Security conscious users know this could not be further from the truth!
On Optimism, fraud proofs, the tool used to challenge incorrect information posted by the chain’s sequencer to Ethereum, are not operational. There is no way to dispute an incorrect state root and users must have blind faith that the block proposer submits the correct one!
Further, only a whitelisted proposer is allowed to publish the state root, meaning in the event of a proposer failure, it would not be possible to withdraw from Optimism to the Ethereum L1.
While fraud proofs are currently under active development, there is no clear timeline for their deployment, but they are essential for the decentralization of any optimistic rollup and are required for Optimism in its current configuration to progress beyond Stage 0.
Alternatively, Optimism could choose to become a zero-knowledge rollup by implementing validity proofs. Just last month, the Optimism Foundation awarded contracts to two teams developing the zero-knowledge proof module for the OP Stack.
The Optimism Foundation is slated to transfer control of the multisig to a security council composed of community members in 2024, which will help to decentralize control over the chain’s keys.
In addition to implementing fraud proofs, Optimism will need an upgradability lock of at least 7 days to become a Stage 1 rollup.
↔️ zkSync Era
Risk Stage: 0
Type: Zero-Knowledge
TVL: $399M
Source: L2Beat
Zero-knowledge proofs ensure each state root posted to Ethereum is correct and allow the state validation segment to be green, but zkSync users still face risks of a sequencer or proposer failure..
zkSync establishes a queue for transactions submitted on the L1 that the sequencer is required to process to mitigate censorship risks. While this does not guarantee transaction inclusion, it does mean that if the sequencer is censoring or down for an individual user, it is down for everyone.
In the future, zkSync will be updating their system to force the sequencer to process the L1 transaction queue, in addition to working towards decentralizing the sequencer. These efforts will help to mitigate the risks associated with a malicious or downed sequencer.
Every update to the state of a zero-knowledge rollup is accompanied by a zero-knowledge proof (ZKP) that guarantees the new state was derived correctly; this is the magic of ZKPs, but means that the only way to get a transaction included is to have it included in the generated proof! Increasing decentralization on zkSync will require that anyone can create proofs without needing to go through the centralized rollup operator.
Similar to its optimistic counterparts Arbitrum and Optimism, zkSync will need to implement upgrade time locks and restrictions on the multisig to decrease the risk posed by upgradability.
🔵 Base
Risk Stage: 0
Type: Optimistic
TVL: $246M
Source: L2Beat
Notice how the risk diagrams for Optimism and Base look the same?
It’s because they are both constructed from the same blockchain Legos: the OP Stack! Instead of building out a custom solution, Coinbase chose to develop their L2 on top of Optimism’s modular rollup framework.
Progressing towards decentralization will allow Coinbase to strengthen the security guarantees for users, meaning Base will likely follow a similar security path forwards as Optimism, implementing OP Stack innovations, like fraud or zero-knowledge proofs, as they become available.
✨ Starknet
Risk Stage: 0
Type: Zero-Knowledge
TVL: $110M
Source: L2Beat
Zero-knowledge rollups are faced with a different set of challenges than their optimistic counterparts. While ZKPs ensure each state root posted to Ethereum is correct and allow the state validation segment to be green, zero-knowledge rollups face their own challenges to mitigate the risks of a sequencer or proposer failure.
Providing “escape hatches” for users is essential to bolster the trustless nature of Starknet and can be accomplished by enabling users to force transactions or withdrawals to the L1 in the event of a sequencer or prover failure. Currently, Starknet has no escape hatches enabled, but turning on just one will go a long way in severing user's dependance on centralized rollup operators.
Forcing the network to accept transactions opens the door for a denial of service attack should a malicious attacker force the network to attempt to accept an invalid transaction. Implementation will first require that proofs can be generated without needing to go through a StarkWare prover and that all transactions on Starknet can be provable.
Alternatively, Starknet could opt for a bridge solution, termed the “Applicative Escape Hatch.” This solution could be implemented today, but would come at the cost of network simplicity, as it would require the implementation of an Ethereum-to-Starknet account registry and a mechanism to cede control of assets in the L2 to the rollup's L1 smart contract.
Like all of the chains listed above, Starknet will need to implement upgrade time locks and restrictions on the multisig to decrease the risk posed by upgradability.
Starknet will be fully open-sourcing its prover by August 31, the team says will help to mitigate the risks of a sequencer or proposer failure by allowing users to submit their own proofs.
