Feature Gate: Additional Vote Stake Threshold

[bw-solana]

SIMD

None

Description

#34120 adds an additional vote lockout stake threshold to try and minimize the number of votes a validator might cast voting down the "wrong" minority fork.

Feature gate is needed because there is a desire to keep the voting behavior consistent between validators as part of rolling out to reduce the chances of consensus problems. That said, it is possible the cluster can survive okay with mixed voting thresholds. In fact, some modded validators have already tweaked these thresholds.

Feature ID

CvgUdmzBnu4kwtL1nurkhK7iXPAdY6QnTKS41H3Jz574

Activation Method

Single Core Contributor

Deployment Considerations

Need to monitor partitioning and associated partition time resolution metrics. Intention is for this feature to help reduce long lockout times in some cases.

Minimum Beta Version

No response

Minimum Stable Version

No response

Testnet Activation Epoch

No response

Devnet Activation Epoch

No response

Mainnet-Beta Activation Epoch

No response

[CantelopePeel]

Hi Liam from Firedancer here. This feature likely requires a SIMD and will require a formal spec in order for the Firedancer to implement this change. It also affects vote economics and needs to have community input.

[bji]

Hi Liam from Firedancer here. This feature likely requires a SIMD and will require a formal spec in order for the Firedancer to implement this change. It also affects vote economics and needs to have community input.

This is not a protocol change though is it? It's just an implementation detail of how the Solana Labs validator implementation chooses to vote and when.

[bji]

BTW it's my opinion that it would be safer to roll this out incrementally. Maybe having the implementation only enable the behavior if the validator's vote account pubkey starts with 'A' or something like that. Whatever would capture a subset of 10% or less. I'd rather see the changed voting behavior incrementally roll out in this fashion than all at once via a feature. The cluster can survive 10% of stake going AWOL because of a consensus change; but can't handle 100% doing that.

[bji]

Maybe like 10 features. Each one enabling the behavior for some incremental subset of the cluster. Then ramp it up one feature flag per epoch or something.

[bw-solana]

Hi Liam from Firedancer here. This feature likely requires a SIMD and will require a formal spec in order for the Firedancer to implement this change. It also affects vote economics and needs to have community input.

This is not a protocol change though is it? It's just an implementation detail of how the Solana Labs validator implementation chooses to vote and when.

Right, not a protocol change. In fact, several validators run with modded thresholds already.

I'm sort of on the fence on this one. I'm happy to write up a SIMD and solicit input if others think it's valuable. I also agree with @bji that a more gradual rollout (either organically or via some tightly controlled feature gate) might actually help prevent testnet from falling over.

[bw-solana]

Closing as this feature gate was removed from the code. Vote threshold changes were pushed in unconditionally