Sorry @rickymac, I hadn’t noticed this discussion thread before but I have commented on @Quantumplation’s thread.
Something I have been at pains to point out is that the effect of increased block propagation delays is not evenly felt across the network. Unfortunately increased delays causes the protocol to unfairly disadvantage the more physically remote pools. This effect arises from the fact that slots are only 1 second in duration and “fork battles” are settled using the block VRF.
I explained the cause and how it works against decentralisation in this comment to @Quantumplation’s thread.
In summary, any increase in the block size will exacerbate this protocol design unfairness which is already quite significant. See for example my analysis of a recent block with a breakdown of production, propagation and validation times for 3 machines with different computation speed.
A correct fix for this design problem might involve two changes combined:
- Modify how slot leadership is determined so that only every 3rd or 4th slot is valid
- Only settle “fork battles” using block VRF if slot is identical (otherwise prefer current chain)
If such changes were instituted first, then increasing the block size wouldn’t produce such an uneven and unfair effect, which works against decentralisation.