# What is the need for a pre-vote step in tendermint? **URL:** \ **Category:** Ethermint\ **Created:** [July 18, 2018, 3:11pm UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533 "2018-07-18T15:11:36Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pranay01](https://avatars.discourse-cdn.com/v4/letter/p/a8b319/32.png) [@pranay01](https://forum.cosmos.network/u/pranay01)\ **Post date:** [July 18, 2018, 3:11pm UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533/1 "2018-07-18T15:11:36Z")
I was going through the tendermint white paper ([https://tendermint.com/static/docs/tendermint.pdf](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? ---
**Author:** ![zmilosevic](https://avatars.discourse-cdn.com/v4/letter/z/a183cd/32.png) [@zmilosevic](https://forum.cosmos.network/u/zmilosevic)\ **Post date:** [July 18, 2018, 6:10pm UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533/2 "2018-07-18T18:10:23Z")
Please take a look at the latest version of the spec: [https://github.com/tendermint/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](https://infoscience.epfl.ch/record/146821/files/bcc-paper.pdf)). ---
**Author:** ![zmilosevic](https://avatars.discourse-cdn.com/v4/letter/z/a183cd/32.png) [@zmilosevic](https://forum.cosmos.network/u/zmilosevic)\ **Post date:** [July 18, 2018, 6:16pm UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533/3 "2018-07-18T18:16:12Z")
You might also find useful Chapter 3 of Ethan’s thesis: [https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769](https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769). ---
**Author:** ![pranay01](https://avatars.discourse-cdn.com/v4/letter/p/a8b319/32.png) [@pranay01](https://forum.cosmos.network/u/pranay01)\ **Post date:** [July 19, 2018, 2:40am UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533/4 "2018-07-19T02:40:53Z")
Thanks, will check this out and get back if I still have some doubts. ---
**Author:** ![pranay01](https://avatars.discourse-cdn.com/v4/letter/p/a8b319/32.png) [@pranay01](https://forum.cosmos.network/u/pranay01)\ **Post date:** [July 20, 2018, 4:38pm UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533/5 "2018-07-20T16:38:37Z")
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 different value. Is this the key reason why both pre-vote and pre-commit are neeeded? ---
**Author:** ![zmilosevic](https://avatars.discourse-cdn.com/v4/letter/z/a183cd/32.png) [@zmilosevic](https://forum.cosmos.network/u/zmilosevic)\ **Post date:** [August 6, 2018, 8:53am UTC](https://forum.cosmos.network/t/what-is-the-need-for-a-pre-vote-step-in-tendermint/533/6 "2018-08-06T08:53:34Z")
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](https://infoscience.epfl.ch/record/146821/files/bcc-paper.pdf) ].