This proposal is meant to define a variable bonding time (currently 0) and variable (extend only from current one) un-bonding time.
Purpose of this thread is to brainstorm proper algorithm which will help to define a good draft and final proposal.
What is the general idea ?
Based on one or more parameters (defined later) the bonding and unbonding time to particular validators and by particular delegators would dynamically vary. If delegators centralize and try to harm the network by irresponsible behavior they would be taxed (aka penalized by inflation) on the protocol level. For example blindly bonding to TOP1-X validators who account for more then 37% of voting power would require delegators to await period of time defined by some algorithm (which has to be determined). This way delegators will become more careful and diligent while distributing their stake and instantly notice that they do not receive rewards right away thus potentially research why what they are doing is taxed. Additionally poor distribution of stake by delegators could automatically extend un/bonding times, for example bonding 100% of wallet content into A might take time T while un/delegating 50% to A and 50% to B T/2 months.
The overall idea can be split into two separate sections.
Variable un/bond when delegating to particular validators
Variable un/bond when delegating by particular delegators
1. Delegators Bonding to lower ranked Validatators can expect to bond faster and unbond faster
2. Delegators Bonding to higher ranked Validators can expect to bond slower and unbound slower.
3. Delegators that centralize their stake can expect to bond slower and unbound slower.
4. Delegators that decentralize their stake can expect to bond faster and unbound faster.
Where unbound is never smaller then 21 days regardless if validator is hi rank or low rank.
Reason: If you put network in danger you should be taxed (during bonding) and your risk factor (unbonding period) extend. Additionally un/bound factors should be considered on both validator and delegator side. Desired behavior should be plainly stated by the chain logic.
What is this supposed to achieve ?
Ensure more more uniform distribution of the stake by having a protocol rule thus clearly states expected long term direction toward decentralization
Instantly increase awareness of delegators about the stake congestion.
Ensure more more active delegators behavior (they should monitor stake distribution if they want to have optimal access time to the funds)
Ensure hones carrot/stick behavior among both validators and delegators.
WAIT !!! Can this cause big validators to split into multiple nodes and perform sybil attacks ?
No if bonding algorithm is properly defined and ensures that sybil behavior is not worth its execution, for example cost of maintenance of additional setup exceeds potential increase in the number of delegations. One of the ideas how to solve it was proposed by @sunnya97 via equation: (sqrt(v_1) + sqrt(v_2) + ... + sqrt(v_N))^2.
What parameters could be used in the algorithm that defines bonding and unbolting time ?
% share of delegated stake (rank)
% share of self delegations
Number of unique delegations above certain amount or % share where delegators do not delegate “all in” into particular validator
Number of “all in” delegators above certain amount or % share
Commission Fees, change rates, max fee
Number of approved governance proposals created by the validator
Any others ?
What parameters should likely NOT be used in the algorithm that defines bonding and unbolting time ?
I have a verification question. In simplistic terms is the goal of the Algo to do the following ?
Delegators Bonding to lower ranked Validatators can expect to bond faster ,but unbond slower.
Delegators Bonding to higher ranked Validators can expect to bond slower ,but unbond faster.
ranked*—> At the moment implies voting power . But for the purpose of the algo , the params that @asmodat mentioned would create another set of ranking .
*21 days will be the minimum unbonding time.
Also , I would suggest adding , number of blocks missed in the last “X” amount of time as a param as well.
Delegators Bonding to lower ranked Validatators can expect to bond faster and unbond faster
Delegators Bonding to higher ranked Validators can expect to bond slower and unbound slower.
Where unbound is never smaller then 21 days regardless if validator is hi rank or low rank.
Reason: If you put network in danger you should be taxed (during bonding) and your risk factor (unbonding period) extend. Desired behavior should be plainly stated by the chain logic.
Rank in the context of algo would be always the voting power as baseline BUT the final value could also depend/be influenced based on additional parameters mentioned before.
IMO algo variation v0.1 under initial consideration could begin as:
final un/bond length = max(
minimum un/bond,
proportional to params related to non deisred behavior * inversely proportional to params related to non desired behavior )
with **exception** where:
Self boning is always instant
If the above is acceptable then we can spit params into two sections:
Props related to desired behavior: eg. self delegations
Props related to non desired behavior: eg. missed blocks
Missed blocks is a good idea I will add those including jail count.
I would also propose for final un/bond length to be dynamic that is change for all delegators dynamically as their validator changes the rank with following consequences:
Kick in the butt for large exchanges building staking services and wishing to operate in fractional reserve model. This would make their current reserve prediction algo useless. (We do already have one such adversary)
Inducing more active delegators behavior. Delegators needs to monitor their validators rank and entire staking distribution self balances without people just bounding to one person and forgetting they ever delegated - that is if they wish to have funds available within defined time period.
Simpler implementation, so we do not have to store/query info from the chain when the stake was bound for example.
We are frequently analyzing the Cosmos network topology (https://github.com/Ethermat/cosmos-topology), we have far more access to data than the peer list solely. Our analysis shows that bigger validators spend relatively little money on their infrastructure. Due to the sentry architecture we don’t expect high or even exponential costs for splitting up a bigger validator into smaller one.
Which parameters would make sense:
% share of self-delegated stake
validator rank
Commission Fees, change rates, max fee
What does not make sense:
“all in” into particular validator (a nominator can create multiple accounts and delegate…)
number of approved governance proposals created by the validator - governance should not be taken into account by the algorithm, it should be a social parameter for nominators
missed Blocks - issues for small validators (depending on peer list…) - slashing is sufficient
jail count - no incentives for new validators - slashing is sufficient
Thank you, this is really cool peer visualization: https://www.ethermat.com/peer_list.html I do think however that Sybil attacks if detected would have very negative influence especially if socially accepted and that’s why this proposal has to be carefully planned. The setup of sybils in secure way would however due to HSM requirements induce large costs thus if someone would openly perform such attack he could be considered operating non secure validation service, likely in the same data-center region.
Regarding parameters.
“all in” into particular validator - it can be used as an verifiable anti-rank factor and is sybil resistant if you consider it proportion wise not amount wise. Additionally it can be a property that changes the bonding and unbonding time on the delegator side not validator.
“all in” factor is positive when your stake is % wise distributed among multiple validators and is negative when you go “all in”. On top of this the weight could be proportional to your delegated stake that is the more you distribute from a single account the more positive this property can be.
I fully agree with removing number of approved proposals, will remove it from the list as likely not worth consideration and adding complexity. Unless we would count non abstain votes on proposals, but probably yes we can leave it be for the time being.
Missed blocks & Jails - yes lets not make it harder then it is already fro small fish t enter.
To summarize two cases should likely be considered:
Individual, per decelerator un/bonding times
proportional to amount staked (to eliminate sybil factor)
inversely proportional to how poorly that stake is distributed
What might be also worth to consider is variable jailtime, so that the higher up the ladder validator is the longer jailtime penalty could occur for downtime. However some could argue that this might decrease security of the network where eliminating top validators allows to decrease stake bound for longer time period thus allowing attacker higher chances of performing an attack. I would argue this is not true because delegators can always unbound.
As the foreword I would also want people arguing possibility of sybils to occur to consider not only cost of operating another validator node and securing a key but also maintaining a separate community, webpage and all other social aspects including threat of discovery of the sybil and destruction of public image resulting in social backslash and loose of stake.
That’s also a very interesting idea. As you already mentioned, variable jail time would introduce new attack vectors. The question is if the benefit of variable jail time is sufficient compared to potential impact(s) on the security.
To put it in a Yoda-way: More data on jailing of validators collect, we must.
Idea is to have those parameters easily configurable via governance so we would have almost no difference initially (hours instead of days or months) vs the defaults but the sole existence of those rules might induce huge changes in delegators behavior which is what I am counting on most. It’s just like everyone is fearful about downtime slashing while in reality the penalty is non existent however its psychological and social effects are major. This approach would also allow us to test waters what would work best slowly manipulate and observe the behavior.
We might also consider rewarding validators for self delegations. If we introduce another idea - The Guaranteed Minimum Income for validators using 1% of stake rewards (to give small fishes minimum of ~100 ATOM a month) we could also enforce that if validator self bonds then he would not pay this 1% to that pool of money from his delegations to himself thus making the idea more Sybil resistant - so by spiting your stake you would effectively gain less then when you are self-delegating.