Source: Bankless, compiled by: BitpushNews Mary Liu
It is said that the Ethereum L2 solution inherits the “security” of Ethereum, but what does this mean? Depending on the Rollup, the answer varies.
While every Rollup aspires to full trust, all optimistic and zero-knowledge (ZK) scaling solutions on Ethereum currently rely on some form of “training wheels”.
Vitalik (V God) provides an excellent framework to help rollup users understand their trust in centralized actors or transparent code. The ultimate goal of rollup security is to reach the Stage 2 milestone, which requires completely getting rid of the “training wheels” mentioned in Vitalik’s paper – the L2Beat diagram below nicely summarizes this.
Few Rollups have achieved Stage 2 as defined by Vitalik, but Arbitrum is making strides towards becoming the first notable. In early August, Offchain Labs (the team that built Arbitrum) announced a new on-chain permissionless verification scheme — Delayed Bounded Liquidity (BOLD), which fortifies its controversial protocol against an attack" denial of service attack.
However, each L2 develops at different speeds, and this article will explore the five largest generalized L2s in Ethereum, which are committed to eliminating the centralization risk factor in rollup and moving towards the goal of Stage 2.
Decision One
Risk Stage: 1
Type: Optimistic
TVL (Total Value Locked): $5.41 billion
Arbitrum One has successfully reduced centralization risk more than any other chain in this article, and if ArbitrumDAO adopted BOLD on One, the chain would turn the state verification part green, but moving to Phase 2 would require the entire risk graph to change into green.
Improving upgradeability will require two changes. First, the implementation delay for governance-initiated upgrades must be extended from 12 days to 30 days. Second, no participant should upgrade Arbitrum’s code at will unless the verification is error-free.
The final training wheels, Arbitrum’s Security Council, are directly elected by the DAO and have the ability to bypass governance to implement upgrades immediately. Despite Arbitrum One’s best efforts to reduce centralization risk, the security of on-chain assets still depends on the honesty of this almighty 9/12 multi-signature.
Given the risks of operating a rollup, the safety committee is considered positive for the Arbitrum ecosystem, but to move to Phase 2, Arbitrum needs to limit it to only responding to on-chain provable errors.
This will further secure users’ Arbitrum One and ensure (in the absence of errors) that a participant cannot issue a stateRoot that overrides the rollup proof system.
Optimism
Risk Stage: 0
Type: Optimistic
TVL: $2.67 billion
Crypto watchers generally consider Arbitrum and Optimism to have similar security guarantees, since both employ optimistic rollups. Security-conscious users know this couldn’t be further from the truth!
On the optimistic side, fraud proofs (tools used to challenge incorrect information issued by the chain orderer to Ethereum) do not work. There is no way to dispute an incorrect stateRoot, users must blindly trust that the block proposer submitted the correct stateRoot.
Additionally, only whitelisted proposers can publish stateRoot, which means that if a proposer fails, there is no way to exit from Optimism to Ethereum L1.
While Fraud Proofs are currently under active development with no clear timeline for their deployment, they are critical to the decentralization of any Optimistic Rollup and are required for Optimism to move past Stage 0 in its current configuration.
Alternatively, Optimism can choose to be a zero-knowledge rollup by implementing proofs of validity. Just last month, the Optimism Foundation awarded contracts to two teams to develop zero-knowledge proof modules for the OP Stack.
The Optimism Foundation plans to hand over control of multisig to a council of community members in 2024, which will help decentralize control of chain keys.
In addition to implementing fraud proofs, Optimism requires at least a 7-day upgradeability lock to become a phase 1 rollup.
zkSync Era
Risk Stage: 0
Type: Zero Knowledge (ZK)
TVL: $399 million
Zero-knowledge proofs ensure that every stateRoot published to Ethereum is correct and allow state verification segments to be green, but zkSync users still risk orderer or proposer failures.
zkSync builds a queue for transactions committed on L1 that the orderer needs to process to mitigate censorship risk. While this doesn’t guarantee that the transaction is included, it means that if the orderer censors or shuts down a single user, everyone gets shut down.
In the future, zkSync, in addition to working on decentralizing the orderer, will also update its system to force the orderer to handle the L1 transaction queue. These efforts will help mitigate the risks associated with malicious or downed sequencers.
Every update to the zero-knowledge rollup state is accompanied by a zero-knowledge proof (ZKP) to guarantee the correct derivation of the new state; this is the magic of ZKPs, but it means that the only way to include a transaction is to include it in the generated proof In , zkSync’s increased decentralization will require anyone to create proofs without going through a centralized rollup operator.
Similar to Optimistic’s Arbitrum and Optimism, zkSync needs to implement upgrade time locks and restrictions on multi-signatures to reduce the risk of upgradeability.
Base
Risk Stage: 0
Type: Optimistic
TVL: $246 million
Notice how the risk graphs for Optimism and Base look the same?
This is because they are all built from the same blockchain Lego brick: the OP Stack. Instead of building a custom solution, Coinbase chose to develop L2 on top of Optimism’s modular rollup framework.
Advances in decentralization will allow Coinbase to strengthen security guarantees for users, which means that Base may follow a similar security path as Optimism, implementing OP Stack innovations such as fraud or zero-knowledge proofs (when they become available).
Starknet
Risk Stage: 0
Type: Zero Knowledge
TVL: $110 million
Zero-knowledge rollup faces a different set of challenges than its optimistic counterparts. While ZKPs ensure that every state root published to Ethereum is correct and allow state verification to be partially green, zero-knowledge rollups face their own challenges in mitigating the risk of orderer or proposer failure.
Providing an “escape hatch” for users is critical to enhancing the trustless nature of Starknet, and can be achieved by enabling users to force transactions or withdraw to L1 in the event of a sequencer or prover failure. Currently, there are no escape hatches enabled on Starknet, but enabling just one would largely cut users off from centralized aggregation operators.
Forcing the network to accept transactions opens the door to denial of service attacks if a malicious attacker forces the network to try to accept invalid transactions. The implementation first requires proofs to be generated without going through a StarkWare prover, and that all transactions on Starknet can be attested.
Alternatively, Starknet could opt for a bridging solution known as an “app escape hatch”. This solution can be implemented today, but at the cost of network simplicity, as it requires the implementation of an Ethereum-to-Starknet account registry and a mechanism for handing control of assets in L2 to rollup’s L1 smart contracts.
Like all the chains listed above, Starknet needs to implement upgrade time locks and restrictions on multisig to reduce the risk of upgradeability.
Starknet will fully open-source its prover on August 31, which the team says will help mitigate the risk of orderer or proposer failures by allowing users to submit their own proofs.
