What is the need for a pre-vote step in tendermint?

Archived Ethermint
1

I was going through the tendermint white paper (https://tendermint.com/static/docs/tendermint.pdf) - Couldn’t figure out why there is a need for a pre-vote and a pre-commit step? To me prevoted step seems redundant - As it just check if more than 2/3rd of nodes have prevoted. Why don’t just let all the nodes issue a pre-commit instruction and if more than 2/3 nodes have pre-committed then the nodes enter commit stage?

2

Please take a look at the latest version of the spec: https://github.com/tendermint/spec. We don’t explain directly your question in the paper (spec), but there is a reference to a paper which explains the intuition behind consensus basic mechanisms (https://infoscience.epfl.ch/record/146821/files/bcc-paper.pdf).

2 Likes
3

You might also find useful Chapter 3 of Ethan’s thesis: https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769.

1 Like
4

Thanks, will check this out and get back if I still have some doubts.

2 Likes
5

Found this in the thesis chapter you mentioned:

In asynchronous environments with Byzantine validators, a single stage
of voting, where each validator casts only one vote, is not sucient to ensure
safety. In essence, because validators can act fraudulently, and because there
are no guarantees on message delivery time, a rogue validator can co-ordinate
some validators to commit a value while others, having not seen the commit,
go to a new round, within which they commit a di fferent value.

Is this the key reason why both pre-vote and pre-commit are neeeded?

6

It’s a bit more involved but essentially yes. In a system with 3f+1 nodes (at most f faulty) having only Proposal and Precomit is not sufficient as faulty processes can send different messages to different processes, leaving system in a state where a correct process p1 can decide some value v1 in round r1 and being possible for other correct processes to decide on some value v2 in later rounds. This is avoided by having processes first preagree on a single value (with Prevote) and then confirm preagreement with Precommit messages. The other option is using 5f+1 nodes to tolerate f faulty nodes; then Prevote message is not needed due to higher quorums used. You have formal treatment of this subject here: [https://infoscience.epfl.ch/record/146821/files/bcc-paper.pdf ].