The Great Consensus Cleanup (revival) proposal attempts to address worst case block validation time through a consensus change. This is fundamentally a whack-a-mole game, as there could always be some unknown unknown method out there to produce blocks that take a long time to validate.
Every whack takes years and can be difficult to execute without disclosing the vulnerability.
And with every future soft fork we need to deeply worry about block validation time. Although SegWit and Taproot have made it easier to reason about this sort of thing, and entirely new schemes like Simplicity take full account of it.
It would be really nice if we can make slow blocks a problem only for the miner who produced one. That would make them a useless instrument for attacks, leaving only a concern for accidents (and protecting miners through standardness rules, but those can be changed more quickly).
Perhaps parallel block validation can achieve this.
The idea of parallel block validation is that if your node sees two blocks competing for the same height, it tries to validate both in parallel and picks whichever it finishes first, which it then announces and builds on.
In the current situation Bitcoin Core will evaluate whichever block is sees first, and completely ignore the outside world until it’s done validating. It only matters which block reaches the node first.
Instead, parallel block validation should cause fast-to-validate blocks to propagate better when they’re directly competing with a slow-to-validate block. This increases the stale risk for slow-to-validate blocks, which increases the cost of any attack that involves such blocks.
Pure parallel validation is very complicated to implement. Instead, a simpler approach could be that while the node is busy validating a block, it keeps listening to announcements for competing blocks. If such a block appears, it aborts the ongoing validation and tries the new block instead.
This approach could be problem if a slow block arrives immediately after a normal block (perhaps intentionally). So maybe the following heuristic can be used: keep track of average (weight adjusted) validation time and when validation takes more than five standard deviations longer, abort if a competing block is seen.
The slow block would not be marked invalid. If another block is mined on top of it, we’ll try validation once more. But if a third block builds on the fast chain, we abort again, etc.
One problem with this solution is that it is really difficult to build, at least in Bitcoin Core. It would also leave older Bitcoin Core nodes vulnerable, as well as any alternative implementation that didn’t implement parallel validation.
But putting that aside, I’m unsure if it actually solves the problem in the first place. In part because I don’t fully understand the attacks that people are worried about.
Does the large miner advantage stay in place even if their blocks are at increased risk of reorg?
If miners typically run higher end hardware for their node, does that mean slow blocks propagate just fine between miners, with the other nodes in the network being out of the loop?
Does it create an incentive for miners who trust each other (or collude) to skip validation so they always build on the first-seen block, ignoring a fast-to-validate competitor block?
Does this accidentally introduce an incentive to produce empty blocks? Or is the five-sigma threshold enough to prevent that? There used to be a slight advantage for smaller blocks due to the time it takes to transmit the bytes, but that’s been thwarted by compact blocks (when they work). Slow validation seems to be an orders of magnitude bigger bottleneck than bandwidth (seconds or minutes vs. a few dozen milliseconds).
I’m unsure how to best analyse this.
) between them. But i don’t think we can assume such a network topology.