# Sequencer Decentralization

One apparent question that arises when designing a rollup is: who should we allow to submit data/proofs to L1?

In regular rollups, there might be a mechanism that chooses a sequencer per some timeframe or be completely centralized. [Vitalik elaborates](https://vitalik.ca/general/2021/01/05/rollup.html) on different ways to decide who can submit a batch in rollups.

However, [for a rollup that only verifies proofs/signatures](https://hackmd.io/Dbzg1am4SQCR7yE4fUQT0g), the batch submissions could be a total anarchy.

In regular rollups, total anarchy is extremely inefficient because the sequencers cannot know the would-be state at the time of their batch being processed. In other words, batching transactions on top of the correct prev_tire_root will be hard, since other sequencers could update the prev_tire_root at any moment.

Although in a rollup that only verifies proofs, we can separate the prev_tire_root s per sequencer. The idea behind this is: we can take advantage of the fact that transactions aren’t related to each other. In other words, we don’t need to have a consensus on when proofs get into the state.

## Overview of the anarchy:

The state will be managed by a Verkle trie. (details [here](https://hackmd.io/Dbzg1am4SQCR7yE4fUQT0g))

**Verkle branch per sequencer**

Every sequencer is expected to have an Ethereum address. And the Verkle path that corresponds to the address will be the sequencer’s branch that it can add any valid data.

**The rollup smart contract**

The rollup smart contract (the smart contract that sequencers submit things to), updates the root of the Verkle trie, according to the submitted branch root.

This decouples each sequencer’s state updates, allowing anyone to submit any valid data at any time.

**Example**

User 0xdd submits a proof (key: ee, value: “some cid”) to the sequencer 0x02. The proof will be stored at 0x02ddee. The path denoted in pink.


If the user 0xdd submits the same proof to the same sequencer (0x02), the sequencer will simply reject it since the proof has already been included. Although, if the user submits the same proof to a different sequencer, that sequencer might include the proof again. Unlike regular rollups, there are no “double-spending”-like issues in proof/sig verifications, so such duplication wouldn’t be a fault.

- The key size will be 256bits * 3 = 768bits
- 256bits each for the sequencer address, end user address, and cid

## Verkle trie update verification

As in regular zk rollups, a sequencer needs to provide a SNARK that proves
- the validity of the Verkle trie update.
- the validity of each leaf (e.g. signature is correct, proof is correct, etc)

## Grieving attack on the trie

Even though we have a large key (768bits), the effect of a key collision attack on the trie is the same as Ethereum’s Verkle trie implementation. And in [Dankrad’s analysis](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html), it is considered that such an attack would not cause any issues.

## The case for this approach

- This rollup is radically simple compared to others. We should value simplicity.
- We have sequencer decentralization from day 1.

## The case against this approach

- Tons of projects are working on general-purpose zkVM rollups, so why bother building a rollup that the only thing it can do is verify proofs/sigs?
- _There redundant trie structure might cause some scalability issues_. (probably need to do a more rigorous analysis)