# How are frequency of getting selected as a proposer and voting power relate , or do they?

**URL:** <https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704>\
**Category:** Tendermint\
**Created:** [August 7, 2018, 7:25am UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704 "2018-08-07T07:25:15Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![vaibhavchellani](https://avatars.discourse-cdn.com/v4/letter/v/ecc23a/32.png) [@vaibhavchellani](https://forum.cosmos.network/u/vaibhavchellani)\
**Post date:** [August 7, 2018, 7:25am UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704/1 "2018-08-07T07:25:15Z")

</div>

It has been mentioned in the paper that the frequency of getting selected as a proposer is dependent on voting power , but as i understand if the proposers are selected in a round robin fashion , each validator will get its turn to be proposer once ?  
I wanted to have more clarity on this , maybe i am perceiving wrongly.

---

<div class="post-metadata">

**Author:** ![jdkanani](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@jdkanani](https://forum.cosmos.network/u/jdkanani)\
**Post date:** [August 7, 2018, 9:25am UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704/2 "2018-08-07T09:25:53Z")

</div>

Just found out doc which might help [https://github.com/tendermint/tendermint/blob/master/docs/spec/reactors/consensus/proposer-selection.md](https://github.com/tendermint/tendermint/blob/master/docs/spec/reactors/consensus/proposer-selection.md)

---

<div class="post-metadata">

**Author:** ![katernoir](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/katernoir/32/96_2.png) [@katernoir](https://forum.cosmos.network/u/katernoir)\
**Post date:** [August 7, 2018, 12:54pm UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704/3 "2018-08-07T12:54:06Z")

</div>

If I write something wrong, please correct me. But I think the [following function](https://github.com/tendermint/tendermint/blob/c64a3c74c870d725ba1356f75b4afadf0928c297/types/validator_set.go#L51) in the Tendermint Repo makes this quite easy. This also explains the meaning of _Accum_, which has often been discussed in the chat.

Every validator starts with his personal _Voting Power_ and _Accum_ 0. Every round the _IncrementAccum_ function gets called and increases each validators _Accum_ by its _Voting Power_. Then, the validator with the highest _Accum_ is selected as the proposer for this round and his _Accum_ gets decreased by the **total** voting power of **all** validators, therefore most likely being negative.

Let’s do a little example and say the total voting power is 100. The example is quite long and a little simplified, but I hope this makes sense and helps people to understand it.

**Validator A** has 10 Steak Voting Power  
**Validator B** has 20 Steak Voting Power  
**Validator C** has 30 Steak Voting Power  
**Validator D** has 40 Steak Voting Power

In the first round, the _Accum_ of each Validator will be increased, resulting in the following Accums:  
A -\> 10  
B -\> 20  
C -\> 30  
D -\> 40  
Now, **D** has the highest _Accum_ and will be the Proposer for the round. His _Accum_ will be decreased by the total voting power (100), resulting in this:  
A -\> 10  
B -\> 20  
C -\> 30  
D -\> -60 _(40 - 100 = 60)_  
We enter round 2 and _Accum_ of each validator will be increased by their _voting power_ again.  
A -\> 20  
B -\> 40  
C -\> 60  
D -\> -20  
This time, **C** has the highest _Accum_ and will be the proposer, resulting in the following:  
A -\> 20  
B -\> 40  
C -\> -40 _(60 - 100 = -40)_  
D -\> -20  
Entering round 3, increasing _Accum_ by _voting power_ again:  
A -\> 30  
B -\> 60  
C -\> -10  
D -\> 20  
Now, **B** will be Round Proposer:  
A -\> 30  
B -\> -40 _(60 - 100 = -40)_  
C -\> -10  
D -\> 20  
Round 4:  
A -\> 40  
B -\> -20  
C -\> 20  
D -\> 60  
Now **D** is again at the top and will be proposer. **A** has not been the proposer yet because its _voting power_ is too small. **A** will be at the top at one point, but **D** will be the proposer much more often because of the higher _voting power_.

---

<div class="post-metadata">

**Author:** ![jdkanani](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@jdkanani](https://forum.cosmos.network/u/jdkanani)\
**Post date:** [August 7, 2018, 5:38pm UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704/4 "2018-08-07T17:38:52Z")

</div>

Thanks @katernoir for the explanation.

I quickly coded what you said and from `validator_set.go`:

```javascript
function sortValidators(validators) {
  validators
    .sort((v1, v2) => v2.address < v1.address)
    .sort((v1, v2) => v2.accumulator - v1.accumulator)
}

function getProposer(validators, times = 1) {
  validators.forEach(validator => {
    validator.accumulator =
      (validator.accumulator || 0) + validator.power * times
  })

  sortValidators(validators)

  // calculate total voting power
  const totalVotingPower = validators.reduce((result, validator) => {
    return result + validator.power
  }, 0)

  const mostest = validators[0]
  mostest.accumulator = mostest.accumulator - totalVotingPower
  return mostest.address
}

function getProposers(validators, rounds = 20) {
  const result = []
  for (let index = 0; index < rounds; index++) {
    result.push(getProposer(validators))
  }

  return result
}

// This prints
// p0 p1 p2 p3 p0 p0 p1 p2 p3 p0 p0 p1 p2 p3 p0 p0 p1 p2 p3 p0

console.log(
  getProposers(
    [
      { address: 'p0', power: 4 },
      { address: 'p1', power: 2 },
      { address: 'p2', power: 2 },
      { address: 'p3', power: 2 }
    ],
    20
  ).join(' ')
)

// This prints
// p0 p1 p0 p2 p3 p0 p0 p1 p0 p2 p3 p0

console.log(
  getProposers(
    [
      { address: 'p0', power: 3 },
      { address: 'p1', power: 1 },
      { address: 'p2', power: 1 },
      { address: 'p3', power: 1 }
    ],
    12
  ).join(' ')
)

```

---

<div class="post-metadata">

**Author:** ![bharvest](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/bharvest/32/1042_2.png) [@bharvest](https://forum.cosmos.network/u/bharvest)\
**Post date:** [August 11, 2018, 4:07am UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704/5 "2018-08-11T04:07:40Z")

</div>

Thank you for clear explanation!

But I am not sure why tendermint does not use any kind of random probabilistic approach.  
If it is deterministic, it has extremely weak point to be hacked because everyone knows  
who is the next proposer and hacker only need to attack current proposer for every block.  
Hence it is much easier to break the chain.

If we use random number with probability distribution then, hacker cannot get any clue who is the  
next proposer, only he knows probability, so weakening the hacking power.

Any thoughts on this??

---

<div class="post-metadata">

**Author:** ![valardragon](https://avatars.discourse-cdn.com/v4/letter/v/e0b2c6/32.png) [@valardragon](https://forum.cosmos.network/u/valardragon)\
**Post date:** [August 11, 2018, 3:29pm UTC](https://forum.cosmos.network/t/how-are-frequency-of-getting-selected-as-a-proposer-and-voting-power-relate-or-do-they/704/6 "2018-08-11T15:29:58Z")

</div>

There have been many discussions for ways to do randomized proposer selection via a VDF. These aren’t prelaunch. VRF style proposals end up being unsafe in asynchrony, e.g. Algorand. That is an extremely undesirable property, hence the inclination towards VDF’s.

However my take on the whole randomized proposer selection is that it really is _not_ an issue. We’re in a p2p network, _not_ the classic client server model. This means that it is quite viable for a validator to hide their real IP, making them resilient to attacks. We heavily recommend that everyone use a sentry node. This means that to DDOS the actual validator, you would have to hack the sentry (or be the sentry’s ISP) in order to glean the info for the real validator. However suppose you _DDOS’d_ the sentry. As a validator, I would have a “Slow” sentry, which basically broadcasted my proposed blocks 2-3 round trips later than my main sentry. This makes it harder to figure out that its my main sentry when beginning the DOS attack. (You would then have to retarget it) You could even put this one behind cloudflare.

Additionally you would likely have private sentries / relay nodes, to make this DDOS attack even less viable. (So even if you did DDOS all public facing sentries, it won’t really cause a problem)