No mechanism for rollup nodes to revoke submitted batches
Summary
There is no mechanism for rollup nodes to revoke the batches submitted from the batcher, which can be problematic if an undesired batch is submitted by an adversary who has control of the batcher.
Vulnerability Detail
When parsing batches from L1 and deriving the L2 chain, the rollup nodes remove invalid batches and keep the valid ones. However, valid batches can be malicious or undesirable, possibly submitted by a malicious or attacker-controlled batcher. For example, the malicious batch can include a severe attack or a multi-block MEV/price manipulation on some DeFi protocols.
Impact
In the current system design, there's no option to revoke a previously submitted batch, i.e., no way to fork or re-org the L2 chain when needed. As a result, the role of the batcher can easily become a single point of failure for the entire system. Its failure may cause irreversible damage to the L2 chain, which is not easy to recover.
Considering implementing logic to allow the rollup nodes to execute a fork after some specific block number in case a fork of L2 is needed. On the smart contract side, consider adding a block number in the ConfigUpdate() events (e.g., the batcher hash update) to timestamp the change of the batcher hash accurately.
shw
medium
No mechanism for rollup nodes to revoke submitted batches
Summary
There is no mechanism for rollup nodes to revoke the batches submitted from the batcher, which can be problematic if an undesired batch is submitted by an adversary who has control of the batcher.
Vulnerability Detail
When parsing batches from L1 and deriving the L2 chain, the rollup nodes remove invalid batches and keep the valid ones. However, valid batches can be malicious or undesirable, possibly submitted by a malicious or attacker-controlled batcher. For example, the malicious batch can include a severe attack or a multi-block MEV/price manipulation on some DeFi protocols.
Impact
In the current system design, there's no option to revoke a previously submitted batch, i.e., no way to fork or re-org the L2 chain when needed. As a result, the role of the batcher can easily become a single point of failure for the entire system. Its failure may cause irreversible damage to the L2 chain, which is not easy to recover.
Code Snippet
https://github.com/ethereum-optimism/optimism/blob/3f4b3c328153a8aa03611158b6984d624b17c1d9/packages/contracts-bedrock/contracts/L1/SystemConfig.sol#L148-L153
Tool used
Manual Review
Recommendation
Considering implementing logic to allow the rollup nodes to execute a fork after some specific block number in case a fork of L2 is needed. On the smart contract side, consider adding a block number in the
ConfigUpdate()
events (e.g., the batcher hash update) to timestamp the change of the batcher hash accurately.