SIMD-0218: Intermediate vote credits

[AshwinSekar]

No description provided.

[bji]

As the author of the public mods that most are using to perform the vote-stuffing/backfilling for extra credit, I thoroughly support this proposal.

[michaelh-laine]

100% support this, thank you Ashwin

[hawkins65]

This will make accounting much ,much easier - thank you!

As a validator in the example you illustrate do I even need to vote on slot 102 (there's no credit for it) but rather just wait a bit longer to see which fork gets heavier quicker?

A somewhat common voting behavior I've observed is:

L1-1      L1-2    L1-3 delay L1-4     L2-2    L2-3     L2-4
[100] - [101] - [102] ---- [103] - [105] - [106] - [107] 
                      \                               /
                       \          L2-1           /
                        \         [104]        / 

Where L1-1 is Leader 1's first leader slot, etc.

We see certain leaders taking longer to build their fourth leader slot (slot 103 in this example) causing the next leader (L2 in this case) to start building based on L1's third slot but L1 gets their fourth slot committed before L2 gets their first slot committed causing L2-1 (slot 104 in the example) to be skipped.

Given a known list of skip_blame validators (those who do this often) I should be smart enough to wait just a bit longer to wait for their fourth slot when they are the leader in front of me.

[Spud957]

If I understand this correctly, the penalty for voting on a bad fork will only be a higher latency for the missed slots on the correct fork?

[bji]

As a validator in the example you illustrate do I even need to vote on slot 102 (there's no credit for it) but rather just wait a bit longer to see which fork gets heavier quicker?

Because of TVC, waiting costs vote credits. So yeah if you think on average you will earn more credits from waiting than not waiting, you would wait; but this is by no means a given, and my personal belief is that it would be a losing strategy most of the time.

[bji]

If I understand this correctly, the penalty for voting on a bad fork will only be a higher latency for the missed slots on the correct fork?

The primary "penalty" for being on the wrong fork is not being allowed to vote for a span of slots on the right fork.

[Spud957]

If I understand this correctly, the penalty for voting on a bad fork will only be a higher latency for the missed slots on the correct fork?

The primary "penalty" for being on the wrong fork is not being allowed to vote for a span of slots on the right fork.

That's what I'm wondering, doesn't this almost get rid of that penalty? You get to implicitly vote on all the slots you would have missed from the correct fork, it's just at a higher latency. Or will slots you would be locked out from not be included in the implicit votes?

[AshwinSekar]

You get to implicitly vote on all the slots you would have missed from the correct fork, it's just at a higher latency. Or will slots you would be locked out from not be included in the implicit votes?

That's correct, once you vote after a gap it will count as implicitly voting on all the intermediate slots.

Thank you guys for the support. Please give me a couple weeks to additionally address the lockout expiry mod as well in this SIMD. Will update when it's ready.

[diman-io]

You propose storing credits alongside latency in LandedVote and are not suggesting increasing the number of lockouts in the state, correct?
I understand that you’re not offering a specific implementation, but explaining it through an example makes it easier for me to grasp.

Because, in reality, the current backfilling in the modes carries the risk of making voting impossible.

So, if I understood correctly, your proposal eliminates this risk factor when it’s necessary to limit backfilling due to potential "future" lockouts.
So it’s better than the current backfilling modes, although it also makes them unnecessary.

[AshwinSekar]

You propose storing credits alongside latency in LandedVote and are not suggesting increasing the number of lockouts in the state, correct?

There's actually no extra storage that needs to occur. Essentially when we root a slot we update credits based on latency. At this point we should also issue credits for any intermediate slots between the old root and the new root.

[jstarry]

You get to implicitly vote on all the slots you would have missed from the correct fork, it's just at a higher latency. Or will slots you would be locked out from not be included in the implicit votes?

That's correct, once you vote after a gap it will count as implicitly voting on all the intermediate slots.

Another thing I'd add is that if you vote multiple times on a fork that doesn't get confirmed, you will have a longer lockout period before you can switch to the canonical fork. For example, 4 consecutive votes on a bad fork would lead to the first bad vote to having a lockout of 2^4 = 16 slots and therefore you could miss out on almost all of the credits for a particular slot even after you later implicitly vote on it due to this SIMD.

I support this proposal since I think it makes sense to a have lighter vote credit penalty for temporarily voting on a competing fork that doesn't get confirmed. If you vote a lot on a competing fork, you would get a heavier vote credit penalty.

[lidatong]

approving for FD

[Spud957]

You get to implicitly vote on all the slots you would have missed from the correct fork, it's just at a higher latency. Or will slots you would be locked out from not be included in the implicit votes?

That's correct, once you vote after a gap it will count as implicitly voting on all the intermediate slots.

Another thing I'd add is that if you vote multiple times on a fork that doesn't get confirmed, you will have a longer lockout period before you can switch to the canonical fork. For example, 4 consecutive votes on a bad fork would lead to the first bad vote to having a lockout of 2^4 = 16 slots and therefore you could miss out on almost all of the credits for a particular slot even after you later implicitly vote on it due to this SIMD.

I support this proposal since I think it makes sense to a have lighter vote credit penalty for temporarily voting on a competing fork that doesn't get confirmed. If you vote a lot on a competing fork, you would get a heavier vote credit penalty.

Why does it make sense to have a lower penalty for lockouts? Doesn't this incentivize a new type of mod that recklessly votes on all slots since the penalty is so low?

[jstarry]

Why does it make sense to have a lower penalty for lockouts? Doesn't this incentivize a new type of mod that recklessly votes on all slots since the penalty is so low?

No, it won't incentivize that behavior because there is still a penalty. Also the longer your lockout on an unconfirmed fork, the greater the penalty. So as before, validators are incentivized to quickly switch forks as soon as they detect that another fork has a heavier weight and higher chance of getting confirmed.

Because the penalty is lower for temporarily voting on the wrong fork, everyone should be a little more incentivized to vote eagerly when there is a fork. This should lead to forks getting resolved sooner because fewer validators will be tempted to withhold their votes and wait to see which fork the cluster is more likely to confirm. @AshwinSekar does this sound correct?

[AshwinSekar]

Because the penalty is lower for temporarily voting on the wrong fork, everyone should be a little more incentivized to vote eagerly when there is a fork. This should lead to forks getting resolved sooner because fewer validators will be tempted to withhold their votes and wait to see which fork the cluster is more likely to confirm. @AshwinSekar does this sound correct?

In general yes this is correct. IVC slightly lowers the penalty for voting on a wrong fork initially, and helps prioritizes timely votes over being always correct.

[Spud957]

Why does it make sense to have a lower penalty for lockouts? Doesn't this incentivize a new type of mod that recklessly votes on all slots since the penalty is so low?

No, it won't incentivize that behavior because there is still a penalty. Also the longer your lockout on an unconfirmed fork, the greater the penalty. So as before, validators are incentivized to quickly switch forks as soon as they detect that another fork has a heavier weight and higher chance of getting confirmed.

Because the penalty is lower for temporarily voting on the wrong fork, everyone should be a little more incentivized to vote eagerly when there is a fork. This should lead to forks getting resolved sooner because fewer validators will be tempted to withhold their votes and wait to see which fork the cluster is more likely to confirm. @AshwinSekar does this sound correct?

It absolutely does incentivize mods that prioritize voting faster over voting on the correct fork. If you vote on the wrong fork one time, there is no penalty as long as you vote on the next correct slot within one slot (2 slot grace period). As TVC (as well as some stake pools) puts a premium on low latency, there is definitely an incentive to vote first and make sure it was the correct vote later. As long as you don't follow a bad fork for more than a couple slots, the penalty for voting on a bad fork is much less than taking a longer time to vote.

[jstarry]

It absolutely does incentivize mods that prioritize voting faster over voting on the correct fork. If you vote on the wrong fork one time, there is no penalty as long as you vote on the next correct slot within two slots (2 slot grace period). As TVC (as well as some stake pools) puts a premium on low latency, there is definitely an incentive to vote first and make sure it was the correct vote later. As long as you don't follow a bad fork for more than a couple slots, the penalty for voting on a bad fork is much less than taking a longer time to vote.

I think you mean that it incentivizes mods that prioritize voting on blocks with lower slots when there is a fork. This is because a vote on a block with a lower slot might not lock you out of voting on the fork with a higher (more recent) slot. But this is actually the happy path and the default voting strategy already covers this well, you wouldn't need a mod to vote quickly on forks with a low slot.

The hard part is that a quick voting strategy could lead you to voting on a wrong fork which has a higher slot than the correct fork, and the you lock yourself out of receiving some vote credits on the correct fork. The "vote first, make sure later" strategy doesn't work in this case.

The default voting strategy already basically does the eager voting strategy that you're describing but with an added stake weighted fork selection algorithm and lockout threshold checks. So relative to that default strategy, I was explaining that there isn't really a new incentive to make a mod based on the changes from this SIMD.

That said, this SIMD isn't really able (or trying) to eliminate all of the different potential mods. Consensus is a game which rewards the participants who correctly predict what the confirmed chain will be and there will always be people looking for an edge and I think that's a good thing as long as those mods help consensus. I support this SIMD because it removes a particular modding incentive which doesn't help consensus in any way and I don't think it really adds any additional incentives to mod beyond what already existed before.

[Spud957]

It absolutely does incentivize mods that prioritize voting faster over voting on the correct fork. If you vote on the wrong fork one time, there is no penalty as long as you vote on the next correct slot within two slots (2 slot grace period). As TVC (as well as some stake pools) puts a premium on low latency, there is definitely an incentive to vote first and make sure it was the correct vote later. As long as you don't follow a bad fork for more than a couple slots, the penalty for voting on a bad fork is much less than taking a longer time to vote.

I think you mean that it incentivizes mods that prioritize voting on blocks with lower slots when there is a fork. This is because a vote on a block with a lower slot might not lock you out of voting on the fork with a higher (more recent) slot. But this is actually the happy path and the default voting strategy already covers this well, you wouldn't need a mod to vote quickly on forks with a low slot.

The hard part is that a quick voting strategy could lead you to voting on a wrong fork which has a higher slot than the correct fork, and the you lock yourself out of receiving some vote credits on the correct fork. The "vote first, make sure later" strategy doesn't work in this case.

The default voting strategy already basically does the eager voting strategy that you're describing but with an added stake weighted fork selection algorithm and lockout threshold checks. So relative to that default strategy, I was explaining that there isn't really a new incentive to make a mod based on the changes from this SIMD.

That said, this SIMD isn't really able (or trying) to eliminate all of the different potential mods. Consensus is a game which rewards the participants who correctly predict what the confirmed chain will be and there will always be people looking for an edge and I think that's a good thing as long as those mods help consensus. I support this SIMD because it removes a particular modding incentive which doesn't help consensus in any way and I don't think it really adds any additional incentives to mod beyond what already existed before.

That makes sense, I’m supportive of the simd in general, I just think slots where the validator would be locked out shouldn’t be backfilled.

[jstarry]

That makes sense, I’m supportive of the simd in general, I just think slots where the validator would be locked out shouldn’t be backfilled.

I think this is fair but I think it's sufficient that they just can't get full credits for slots that they were locked out of. At this point it's difficult to implement a change that prevents backfilling slots that a validator is locked out of.