Thanks for the reply.
Yeah, I forgot that zk-rollups don’t need to include enough data to be able to make a fraud proof. I guess you could include all transaction data with the rollup block, like in optimistic rollups, and then you avoid the complexities with timeouts, but then you lose some of the efficiency of zk-rollups.
True, I was thinking about zk-rollups since the original post is about zk-rollups. But for optimistic rollups I think the situation would be similar. You probably still need some bond otherwise it would be too cheap to attack the chain. And then the rest follows from there.
The most naive tx supply chain isn’t through an L1 mempool IMO, it’s still through sequencers (but permissionless), which may or may not spin up an L2 mempool.
Something like, to become a sequencer you create a sequencer contract on L1:
if (rollupContract.lastTouchedBlock < targetBlock) {
rollupContract.postBlob(blob);
block.coinbase.transfer(topOfBlockFee);
} else {
rollupContract.postBlob(blob);
block.coinbase.transfer(midOfBlockFee);
}
and L2 txns can similarly define L2fee(timesIncludedInBlockBefore, timesIncludedInBlockTotal) for censorship resistance. Then sequencers just submit Flashbots bundles.
This could potentially be better than going through the L1 crList alone, which I assume would be the only way in the “at most one rollup block per L1 block” approach, which I assume does not apply to crLists, i.e. crLists are allowed to add nth rollup blocks per L1 block.
Of course, I’m not sure if anyone would spin up an alternative sequencer just to batch otherwise-censored transactions. Maybe in practice you’d have to go through the L1 crList with a singleton batch regardless.
Yes, “Each block will include the SNARK proof for the previous block” should be removed (not sure what benefit it would have anyway). Doing it fully async would be better probably.
Since it takes time for the L1 chain for finalize, the time between rollup blocks will need to be more than L1 finalization time. This is because to build a valid block one needs to know the previous block, which needs to be final if one wants operator software to be simple. Otherwise, the operator will need to keep making multiple proposals corresponding to non-finalized branch forks
So lets say, if you wait 5 min to finalize between blocks, and you submit a 100KB block to the mainnet each five minutes, and each transaction is 100 bytes, you get 4 TPS.
If you do not wait for blocks to finalize, then there is still network propagation time.
So if operator2 gets the previous block from operator1 one minute after operator 1 creates it,
then in the example above you get 20 TPS
I think this shows that if someone wants to get a really fast decentralized rollup, the sequences needs to be a fast finalizing PoS chain
If the operators run a fast finalizing PoS chain to order transactions, then blocks on the chain can be finalized in seconds
The L2 contract can enforce this imo.