This isn’t really a DoS attack against ZK rollups in general. You don’t need to have an anything-goes-first-come-first-serve leader selection algorithm. I wrote about this further here, under the section “Merged Consensus”:
A commonly suggested scheme is something like a round-robin with stake. However, your attack is indeed a problem for two desirable features (and because of this attack, these features cannot be safely implemented with a ZK rollup):
- Force exit and continue. In this feature, a user can request an exit, and the rollup block producer(s) must service it in the next block, after which the rollup chain can continue as normal. This is a DoS vector, as you described the attack, any state transition will invalidate the proof you’re working on. The way force exits must be done is that the ZK rollup chain must be halted if an exit request isn’t processed within some timeout. Obviously not as good as continuing.
- Pipelining proof generation off-chain with more than one block producer. Having more than one block producer (not at one time, but in general) means that a system can be permissionless. However, since the next rollup block depends on the previous rollup block, the previous block producer can just…not share the block they’re proving with the next block producer, stalling the pipeline. The solution is to do a two-step process, whereby the block is first submitted on-chain, then the proof after a timeout. However, introducing a timeout now means you have a synchrony assumption, which means L1 miners can mess with things, and if you’re not careful your ZK rollup degrades to an optimistic rollup, making all this ZK stuff a waste of time. ZK rollups have a huge number of edge cases you need to be careful with if you don’t want to end up with an optimistic rollup.
These are some of the many downside of ZK rollups compared to optimistic rollups, which don’t have these issues.