Shard block staggering for faster block times
One of the more interesting ideas that has been floating around Ethereum research circles for a while is the idea of staggering shard blocks. That is, instead of all shard proposers publishing blocks around the same time, some would publish blocks earlier in a slot and some would publish later. Ideally, any timespan of a few hundred milliseconds would have some proposer scheduled to publish a shard block during that timespan.
This can be combined with rollups to create a system where the "de-facto" block time can be reduced to far less than a single slot, perhaps to as little as one second. The way that this would work is that rollups could accept data from multiple shards, and process the data in sequence. Although on-chain calculation of the state would not happen until a few slots in the future, clients can predict the state by seeing what shard blocks are expected to get in and calculating the state themselves.
In this diagram, "X: A -> B" means "rollup X declares that its pre-state hash is A and it's making a transition with post-state hash B". Blocks in green are blocks that get processed; blocks in grey are blocks that do not get processed because their pre-state hash is incorrect (eg. the A -> C block is incorrect because at that point the state hash had already changed to B). As mentioned above, this can all be computed on-chain retroactively, so there is no need for the chain itself to have sub-slot synchrony, but clients who are seeing shard blocks come in in real time can pre-compute what the final state will be.
There are two main challenge points:
If we solve these challenges, however, then users of rollups on Ethereum could experience block times that are competitive with more centralized chains!
submitted by /u/vbuterin