**Problem Definition:** In common blockchains each block is defined by potentially a different miner, and the time slot between two blocks is relatively short (on the order of seconds to minutes). This property provides reasonable decentralization (and thus anti-censorship), and user experience (after at most a few minutes one has pretty high certainty their transaction is added to the chain and will stay there).

It is challenging to find robust construction having similar properties for L2 solutions using validity proofs, as generating a validity proof might take a long time (on the order of 10s of minutes to hours).

**Suggestion Scope:** This suggestion provides some level of decentralization while optimizing simplicity and robustness, over UX and time-critical censorship resistance. We start by formally describing the suggestion, and later analyzing the suggestion features.

**Suggestion:**

- The StarkNet core smart-contract (on L1) manages the leader election (could be PoW, PoS based, or other popular schemes).
- Each leader controls a timeslot (on the order of a few hours, in particular, longer than the time it takes to generate a proof) where only they can invoke
`state_update`

to the StarkNet contract. They can do as many such invocations as they chose to (similar to sending several in the same timeslot). - The validity of each
`state_update`

invocation, and consistency with previous invocations, is enforced by the StarkNet core contract (like it is done with a single sequencer).

**Pros:**

- Simplicity: no p2p protocol is required to synchronize the sequencers. It is sufficient for a sequencer to read the state from L1 (and if applicable an alternative data availability location).
- Robustness: No need to design/analyze any protocol to enhance the trust of one sequencer in other counterparties.
- High Throughput: assuming the time to sequence and separate transactions, and transmitting the proofs to L1 is negligible compared to the time it takes to generate a proof, it is easy (given enough servers) to distribute the proving-load to many servers, thus proving many blocks in parallel, with the total latency of ~ 1 proof. We assume that after this latency there is enough time left to submit all those proofs to L1 (each proof is ~5M gas, and currently Ethereum gas limit per block is ~30M, and block time is ~13 sec, thus one can submit proofs with throughput ~27 proof/min).

**Cons:**

- Censorship Resistance: a malicious leader can censor chosen transactions for an entire slot, which is relatively long (the order of hours).
- UX: Although a trusted leader can report in real-time what are the blocks they are proving, this protocol does not provide any guarantee to users it is indeed the case. In particular, a user needs to wait a relatively long time (the proof latency, which can be hours) before they are sure their transaction was indeed executed.
- UX even for trusted data: transaction submitted close to the end of a leader timeslot (closer than the time it takes to generate a proof) might not be taken by the leader of that timeslot (not to start proving a proof which wonâ€™t be ready in this timeslot) and might be taken by the next sequencer only in the next timeslot (as the next sequencer can not trust whether it is served or not by the current sequencer until the end of the current timeslot). This results in â€śdead time zonesâ€ť (which can last for 10s of minutes or even hours) where a user wonâ€™t know if their transaction is served (if send during the dead time zone), even based on trust in both the current and next sequencers.

**Future Improvements:**

- There is a work in progress to reduce the proving latency. This might improve this solution significantly, as all the issues raised are the result of the long latency of proof generation today.