Can continuous BP voting interfere with finality?

[liviu-]

Assuming good network connection and 100% honest BPs, is it theoretically possible that no block gets 2/3+1 commitments because every round the BPs who pre-committed to the blocks in the previous round are voted out in the round that follows?

[jgiszczak]

Change of producer schedule itself requires a confirmed transaction. Until 2/3+1 of current producers confirm the change in schedule, the previous schedule remains current. Continuous schedule changes would simply take effect one by one as the producers in the previous schedule each confirm the changes. This could indeed cause the last irreversible block to start lagging further and further behind the head block, since each new schedule starts at the beginning. To help mitigate this, the supported system contract throttles producer schedule changes to update no more than once per minute. EOS.IO-based networks may deploy modified system contracts with different throttles.

The only way to stall a network entirely is if malicious voters vote in 1/3 or more registered producers that are not actually running and producing, a scenario experienced by Jungle Testnet not so long ago.

[liviu-]

To help mitigate this, the supported system contract throttles producer schedule changes to update no more than once per minute.

I don't believe this mitigates the problem as a round takes 6s x 21 = 126s, so each round can still have a different set of producers, no?

[jgiszczak]

Mitigate in this case meaning "diminish" rather than "cure". You are correct that LIB will still fall behind. It was not deemed necessary to try to entirely prevent an extremely unlikely scenario. EOS.IO-based networks who are convinced their users are intensely malicious are welcome to deploy a modified system contract with a longer throttle.

[liviu-]

Right, thanks!