Skip to content

Latest commit

 

History

History
62 lines (33 loc) · 3.86 KB

102.md

File metadata and controls

62 lines (33 loc) · 3.86 KB
Raw

Shambolic Banana Barbel

High

Sequencers can retroactively reorder transactions to steal funds from users

Summary

Because BLS signatures are not implemented in the protocol, the sequencer is given unlimited power to retroactively (a) reorder L2 transactions, (b) skip and reorder L1 messages and (c) perform multiblock MEV (even inserting their own transactions into the past after the fact).

This breaks the assumptions required for a system with decentralized sequencers to run, and also causes risks to users regarding the stability of the chain.

Root Cause

Currently, the BLS signature process is not implemented in the protocol. According to the README:

The missing of signature verification process does not affect layer2 correctness since the validity is ensured by zkEVM.

While it is accurate that L2 correctness is enforced by the zkEVM, a sequencer without the requirements of aligning with consensus is given a large amount of power that is not intended by the protocol.

Specifically, we are concentrating the power to perform three actions in one entity:

  1. The sequencer determines the blob to post to L1, which determines the L2 transactions that will be included in each block in the batch.

  2. The sequencer controls which L1 to L2 messages are skipped. This allows them to not just reorder L2 transactions, but reorder deposits as well.

  3. The sequencer submits full batches, which will include ~100 blocks. Controlling multiple consecutive blocks gives the sequencer a large amount of malicious MEV opportunity that wouldn't otherwise be possible.

Most importantly, these actions happen on a delay. Fundamentally, this means users do not have any assurances in the state of the chain until commitBatch() is called on L1, and up until that point, the sequencer can reorder any L2 or L1 transactions (including retroactively including their own) in order to extract funds from users.

As some examples of extreme behavior the sequencer could perform:

  • Wait for a prediction market to resolve, then go back and insert a transaction to bet on the winning outcome.
  • Buy up all of a governance token in advance of a proposal, and sell it after the tokens are checkpointed, without allowing any arbitrage transactions to occur in between these actions. This would allow taking over any open governance system on L2.
  • Move the price for a TWAP oracle and don't allow transactions to resolve it until after the oracle price has adjusted and been exploited.

Importantly, there is no safe way for a user to interact with the protocol without trusting the sequencer. This is because, even if they wait the full ~5 minutes until commitBatch() is called, there is still another 5 minutes until their transaction will be included, and the sequencer can reorder transactions in that time.

While this may be acceptable in systems that explicitly have centralized sequencers, a system that claims to have decentralized sequencers must have systems in place to ensure such an attack is not possible. This is especially critical because the trust assumption to avoid this attack is "zero dishonest sequencers", which is even more stringent than the trust assumption for a single centralized sequencer.

Internal Preconditions

  1. Sequencer needs to either want to extract funds from the system (either explicitly in a large way, or more subtly in a small way).

External Preconditions

None.

Attack Path

N/A

Impact

All users are at risk of their transactions being majorly reordered within a batch, which makes all transactions on the chain fundamentally unsafe without major trust in all sequencers.

PoC

N/A

Mitigation

Implement BLS signatures prior to Prague. It will make the chain more expensive to run, but is necessary to ensure the security of the system.