Вот, к слову, прямо копирую из дискордача разговор разраба и чела со стороны:

themistocles — Today at 4:14 PM
Usually when there are too many txs and a network becomes congested, you can either increase the fees (users don't like this), or you can lower the difficulty or increase the block size.
If the difficulty is lowered, I assume clusters will get wider. Block size increase is similar I suppose because propagation of the blocks becomes slower so more parallel blocks.
So my question is what are the limits in this regard. How many blocks per second is safe and why? Is it related to interconnectivity parameter k?

someone235 — Today at 4:21 PM
When you're saying lower the difficulty do you mean increasing the block rate?
If in normal situations (and not only on rare occasions) there are blocks with more than K blocks parallel to them, it means the propagation delay bound we calculated was too low. So in order to fix it we need to choose between:
1) Increasing K (this will increase the confirmation times as well).
2) Decreasing the block rate.
3) Decreasing the block size.
Once we optimize the code we can choose between (or make some kind of combination):
1) Decreasing K (which will result in shorter confirmations times) - this can be done because the optimization decreased the propagation delay.
2) Increasing the block rate (because propagation delay is lower, we'll have less parallel blocks, so we can increase the block rate until we have the same amount of parallel blocks we had before).
3) Increasing the block size (same idea, but it will increase the propagation delay again until we have the same amount of parallel blocks as we had before).

themistocles — Today at 4:35 PM
I see so it's a trade-off of various things, involving finality as well
well yes I assumed the block rate depends on the difficulty of the mining

hauntedcook — Today at 4:37 PM
it's kinda the opposite - difficulty is changed to match a fixed block rate

themistocles — Today at 4:38 PM
yes yes, that's what I meant

someone235 — Today at 4:38 PM
It's technically right, it's just not the kind of terminology I'm used to
Anyway, if the network is congested we'll need to hardfork if we wanna change block size/rate. This is not done automatically.

themistocles — Today at 4:41 PM
so typically K would be tuned instead? And you mentioned a sort of indication of too much propagation delay is having more than K blocks parallel (regularly). Does that mean honest miner blocks would also start getting discarded?
I am just thinking hypothetically to understand the limits of the system btw

someone235 — Today at 4:48 PM
1) "So typically K would be tuned instead?" K in constant and is not automatically tuned. We calculated the propagation delay in a way that fits full blocks, not current near empty blocks, and also gave some slack. So I wouldn't expect we will need to increase it, unless we change other network params (block rate/size).
2) "Does that mean honest miner blocks would also start getting discarded?" Yes
3) The paper that @msutton will hopefully publish soon is suggesting an algorithm where K is actually auto-tuned according to network conditions. So if propagation delay is lower than expected we can actually can faster confirmation times.