Is it correct to say that rounds are needed as nonces: to cancel previous prevotes so they are not reused later to create a deadlock? If so, why not just use timestamp()/blocktime as an always increasing round.
Normally blocks are uniquely referred as block_number + round. Block_number is needed because round is normally just 0.
But with timestamp()/blocktime you could set some syncronization epoch (~ equal actual blocktime) so when GST happens everyone would give same number, and it’s always different.
Not saying that it’s any better way, just seems easier to implement than resetting round counter every time.
1 Like
It seems, the round design vs nonce is better when you plan to change the blocktime.
E.g. when your blocktime was 5s but now you made it 10s suddely your nonce dropped in half and that’s not good, though solvable. With round design, blocktime doesn’t matter.
1 Like
Round is a strictly incrementing integer used to mark our attempts to come to consensus. If we fail the first round, we can try again in another round.
Rounds are mostly asynchronous - we can only move to the next round after we’ve heard from +2/3 of the validators.
Note the round is actually very important to the protocol because we need to track two variables called the “lock round” and the “valid round”. These are the rounds at which we locked a block, or saw a valid block, respectively. If we use timestamp, we wouldn’t be able to rely on these values the same way. For much more details, see the paper: https://arxiv.org/abs/1807.04938
I get it, rounds are more convenient. Is it possible that rounds are increased quicker than timeout interval? What stops validators from crafting 1000 blocks in 1 second, making it impossible to sync / verify ever?
I believe you should jump to next round not once you have +2/3 but when the timeout has finished too. Otherwise validators can “get rid” of all independent auditors by crafting very long chains.
Is it possible that rounds are increased quicker than timeout interval?
If all the validators are skipping their timeout and voting nil right away, yes the rounds can increase quickly. But that would require validators ignoring timeouts and just maliciously attacking the protocol.
What stops validators from crafting 1000 blocks in 1 second, making it impossible to sync / verify ever?
They have to gossip and agree on blocks over the internet, so there are natural physical limits to how fast they can go.
making it impossible to sync / verify ever?
Syncing should always be able to happen faster than consensus itself because it requires less msgs to be gossipped and less data to be processed (ie. just blocks, rather than blocks + proposals + votes)
I believe you should jump to next round not once you have +2/3 but when the timeout has finished too. Otherwise validators can “get rid” of all independent auditors by crafting very long chains.
This creates too strong of a dependence on time and synced clocks and can make the protocol much slower.
Is it possible that rounds are increased quicker than timeout interval?
I worded it wrong, actually I meant:
Is it possible that blocks are produced quicker than timeout interval?
Syncing should always be able to happen faster than consensus itself
Validators can have gigabit connection between them and stronger hardware, while independent auditors will fail to follow them.
Is there any gas/blocksize limit to prevent chain getting too big?
This creates too strong of a dependence on time and synced clocks and can make the protocol much slower.
Partial synchrony is essentially synchrony already.
1 Like