Maximum validator count for PoS

[mrwillis]

If it's not already in the works, it would really valuable to have a node-set maximum validator count for PoS

To be more specific, define n as the maximum amount of validators, define the amount s as the minimum of all the amounts staked in the validator set. Then,

1. Not elect anyone to be a validator if their staked amount was below s and the amount of validators was equal to n
2. Automatically drop validators from the set after the epoch if they are below s

Probably some missing logic here, but that's the general idea.

I would go further to say it's a required feature for a permission-less PoS network.

The reasoning is it allows there to be some implicit minimum in the staking amount to become a validator (they have to have more staked than the lowest staked validator), otherwise even someone with a small amount of tokens could be elected to become a validator, which could result in DoS.

It provides teams with control at the beginning to slowly expand their validator count as they become more comfortable with running the chain.

Examples for public PoS chains:

Matic: 100
Luna: 120
BSC (not 100% sure on this): 21
EOS: 21

[zivkovicmilos]

Hey @mrwillis,

Thank you for opening up a discussion regarding this 🙏

I can try to answer some of these suggestions.

Not elect anyone to be a validator if their staked amount was below s and the amount of validators was equal to n

Suggestion 1 is something that already happens on the Smart Contract for our staking implementation (check out the repo here).

Automatically drop validators from the set after the epoch if they are below s

Suggestion 2 is covered by the PoS implementation in code in the Polygon SDK - nodes only update their validator sets during epoch blocks (which you can set even now).

I like the idea of having a configurable minimum required staking balance. Right now it's 1ETH per address, if I remember correctly.

Adding a maximum number of validators is also possible, and wouldn't be to much of a hassle to implement PSDK wise (since adding it to the Smart Contract is easy).

What do you think @lazartravica @Kourin1996 ?

[mrwillis]

I would note that a maximum validator count with that logic does implicitly imply a minimum (the min of all the staked amounts) but this is also probably a good feature in conjuction.

…

On Tue., Dec. 14, 2021, 7:20 a.m. Miloš Živković, ***@***.***> wrote: Hey @mrwillis <https://github.com/mrwillis>, Thank you for opening up a discussion regarding this 🙏 I can try to answer some of these suggestions. Not elect anyone to be a validator if their staked amount was below s and the amount of validators was equal to n Suggestion #1 <#1> is something that already happens on the Smart Contract for our staking implementation (check out the repo here <https://github.com/0xPolygon/staking-contracts>). Automatically drop validators from the set after the epoch if they are below s Suggestion #2 <#2> is covered by the PoS implementation in code in the Polygon SDK - nodes only update their validator sets during epoch blocks (which you can set even now). I like the idea of having a configurable minimum required staking balance. Right now it's 1ETH per address, if I remember correctly. Adding a maximum number of validators is also possible, and wouldn't be to much of a hassle to implement PSDK wise (since adding it to the Smart Contract is easy). What do you think @lazartravica <https://github.com/lazartravica> @Kourin1996 <https://github.com/Kourin1996> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUHUCZV7PGMYZMHGOGOTOTUQ4Y67ANCNFSM5J6SSZMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[zivkovicmilos]

Hey @mrwillis,

Just to update you here, we've started looking into these PoS feature requests extensively this week, and will update you as soon as we have a clear picture on what will be implemented first, along with a general timeline 🚀

[Kourin1996]

@mrwillis Thank you for opening the suggestion! Let me clarify this.
(cc: @zivkovicmilos)

Currently, there is only one threshold, which is 1 Ether as default and the contract doesn't have a limit of validators. It means any account that staked the threshold will be a validator. Please note validator set in contract updates immediately, but node updates own validator set at the beginning of the next epoch.

Dynamic threshold sounds good. With this, only the top n stakers will be validators.

n: max amount of validators
s: minimum staked amount by a current validator

1. if there are open slots in validator set then
   (1) Append account to validator set in contract
   (2) Update s only if the total amount the account staked is less than current s

2. if there are no slots in validator set
   (1) Rejects if the total amount the account staked is less than current s
   (2) Remove the validator with lowest staked amount from validator set
   (3) Append account to validator set in contract
   (4) Find the lowest staked amount among validators and update s

I think (4) needs to loop, it takes much gas. We need to find better solution.

In addition, let's say we're reducing n (maximum amount of validators)
(1) num_kick = old_n - new_n
(2) Find the num_kick validators with lowest staked amount and remove them from validator set
(3) Find the lowest staked amount among validators and update s
It should take gas as well.

[mrwillis]

Thanks @Kourin1996. Yes 2. is a loop but it is O(n) complexity. You can make some optimizations such as storing the index/balance of the lowest validator and updating that every time. I don't think the gas consumption should be that high if the chain is sub 100 validators.

An unrelated thought - I'm not sure how you would dynamically change the validator count or staked minimum without forking the chain. Is it possible? cc @zivkovicmilos

[zivkovicmilos]

Hey @mrwillis,

I just want to add one more thing to @Kourin1996's comments.
We actually have 1 more limitation in the staking SC, and it concerns the minimum number of validators - Addresses can't unstake their balances if that action would cause the minimum number of required validators to fall below a certain threshold (4):
https://github.com/0xPolygon/staking-contracts/blob/3ee3c488389bd293d13a413bcb71ad57c1b8e972/contracts/staking.sol#L81-L84

Dynamically changing the validator count or staked minimum would be tricky without forking the chain - or deploying a new SC.
One other solution would be to define a SC owner that would be able to call SC methods for changing these limits. It's definitely something that can be done in the predeploy state - you'd pass in which address you want to be the owner of the contract (authorized to make these kind of changes), and we'd modify the staking SC to only accept calls from that address.

What do you think @Kourin1996?

[Kourin1996]

@zivkovicmilos Not sure if we have always admin accounts. In most scenario, changing such parameters would be done by votes.

[mrwillis]

Ah yes. Agreed with @Kourin1996 . Typically these public chains have votes on changing these parameters.

[mrwillis]

@zivkovicmilos @Kourin1996 have you guys decided what to do on this front? If the min/max number of validators and minimum staking amounts can't be changed on the fly, can they be implemented in the SC?

Regarding changing them on the fly yea seems tricky. @Kourin1996 argued and I agree with that these parameters are mostly changed by votes. I think that might be tricky as per the case where you're voting down (i.e., current validators < new maximum validator count).

[Kourin1996]

@mrwillis You might have seen them but @ptitluca opened new PR for min/max validator limits.
0xPolygon/staking-contracts#10
#397

This adds min/max limitation and prevent account from joining/leaving from validator set. If the number of validator change to out of the range, the transaction will fail. Doesn't consider staked amount right now.