Description of a round-robin filter on top of the current cbc-casper layer

Since cbc-casper assumes an asynchronous network, we can create a filter in front of the casper layer that drops blocks and still preserve consensus safety. We can use this filter to simulate a round-robin block proposal scheme. While it might seem unintuitive to intentionally drop blocks to speed up the consensus process, as Vlad shows in his CasperTFG paper, a round-robin block proposal scheme can allow for an amortized O(1) messages received per finalized block.

Canonically sort the validators by validator id. Each validator gets a "wait time" to broadcast a new block that builds on the previous validator's block. If a validator sends you a block out of turn, drop the block. If a validator sends you a block that doesn't build on the previous validator's block according to the sorting (the exception being if you didn't receive the previous validator's block), also drop that block. After 100 full rounds, recalibrate the "wait time" to be twice the time it took to execute 100 full rounds divided by 100 times the number of validators; the goal here is to dynamically adjust the block propagation time to be the "average" block propagation time of all the validators.

Validator A can try to grief the next validator B in the sorting by withholding blocks to B. Validator B would then by policy just create a new block that builds on the block created by the validator before A. To the other validators it may seem like B unjustly ignored A's block when in fact B just didn't receive A's block. In general, I don't think anything can be done about this besides just ignoring both A and B's block when validator B cries foul. We can also try shuffling the ordering once in a while. There might be other subtle attacks but the important aspect is that none of them endanger consensus failure as this is just a filter in front of the cbc-casper layer.