atomone-hub / genesis

genesis for AtomOne
Other
123 stars 58 forks source link

Improving Delegators and chain Safety #74

Open stevenoruzi opened 9 months ago

stevenoruzi commented 9 months ago
  1. Validators acting maliciously or negligently leading to slashing predominantly affects delegators, a significant concern within the Cosmos ecosystem. Many validators merely meet the minimal self-bond requirement, a practice that can be detrimental. While delegators should ideally choose the most reliable validators, they often lack the necessary expertise to do so. Smaller delegators, in particular, tend to trust validators implicitly, without frequent verification. In such cases, it is the delegators, not the validators, who bear the brunt of any loss in value. To address this, one potential solution is a variable minimum self-bond requirement. Validators could be required to maintain a self-bonded token amount equal to the potential slashing penalty (thus directly linking their stake to their behavior) or a significant percentage, such as 50%. Additionally, validators might be restricted from withdrawing commissions if their self-bond falls below this floating minimum. The case of the Notional validator on Osmosis exemplifies this issue. Despite its inactivity and jailed status, it still holds 3.83 million bonded tokens, underscoring the urgent need for tighter control and greater awareness among delegators.

  2. The practice of creating new validators with the same name after one is jailed, as observed in some chains, should be disallowed. This would prevent confusion and potential misuse of trust.

  3. To reduce risks in the chain, imposing a cap on the amount of bonded tokens held by a single validator might be effective. For example, limiting a validator to a maximum of 10% of staked tokens would prevent excessive centralization of power. Once this threshold is reached, no further delegations would be permitted, encouraging delegators to seek alternative validators, thus promoting a more equitable and secure network.

  4. Finally, addressing the issue of jailed validators, they should not be allowed to undelegate their tokens. It would also be prudent to implement a comprehensive undelegation function for validators. In cases where a validator is jailed, they could issue a full undelegation request to the chain, automatically returning all delegated tokens to the respective owners' wallets. This would enhance the security and fairness of the staking process.

jaekwon commented 9 months ago

In such cases, it is the delegators, not the validators, who bear the brunt of any loss in value.

and the validators could have no self-delegation at all...

To address this, one potential solution is a variable minimum self-bond requirement.

or we could just display the self-bond amount, and, what if somebody wants to delegate anyways even if the self-bond was small? this could be the case for any validator just getting started... startups eat ramen for dinner, speaking from experience.

if somebody wanted to delegate to a validator that had no self-delegation at all, then shouldn't they be free to? perhaps the validator is a general partnership and the stakers have their own addresses.

If we force self-delegation minimums, it would create a situation where people would pool tokens when they otherwise before didn't have to, or they would be forced to get a loan, again when they don't want to. The result is that it doesn't accomplish what you want, and it creates worse distortions.

That said, how about the following?

The practice of creating new validators with the same name after one is jailed, as observed in some chains, should be disallowed. This would prevent confusion and potential misuse of trust.

Yes please make a new issue or PR with the proposed policy, and what must stay immutable by the constitution.

This sounds like generally an automatic name-registration system, that has the capabilities of a trademark office and court, and later offers self-registration too but somehow synchronized with international trademark standards, for not just validator names, but also chain and token names too.

The Founding Documents can include such a thing as an experiment, with loose or no coupling with AtomOne so that its failure does not limit AtomOne, and AtomOne can also fund other experiments too. The AtomOne hub may be "minimal" in its function, but the things that we fund for the common goods is ideally rich and varied, and proves itself over time.

Yet the Constitution can give AtomOne the ability to appoint one or more as "official", but after competition has had a chance to prove itself; say no sooner than 7 years, but if a new significant contender emerges and is "approved" by AtomOne, then it can be given 3 years trial, and what is "officially" supported can change at any time as long as the transition plan is first "approved" as well as a viable transition plan.

jaekwon commented 9 months ago

To reduce risks in the chain, imposing a cap on the amount of bonded tokens held by a single validator might be effective. For example, limiting a validator to a maximum of 10% of staked tokens would prevent excessive centralization of power. Once this threshold is reached, no further delegations would be permitted, encouraging delegators to seek alternative validators, thus promoting a more equitable and secure network.

a 10% cap is interesting. this would be a rule that prohibits any validator that already has 10% from receiving more. at genesis, it could be 25% each, but a new validator would not be able to achieve 1/5 because that would be 20%. so maybe as an exception, anyone can grow to become as large as the second smallest validator, because that only helps decentralization and is a simple rule that makes sense with genesis.

We can also put a little bit of wiggle room so that there can be a bit of over-subscription, and under-subscription AND a grace period before a validator is removed from the set. Say the first 25% of over-subscription is only nominally punished, but then any amount above 25% is progressively punished for new stakers, and over-subscribers become regular subscribers when there is available room (it is a waiting queue system), and when there over-subscription, the original subscribers can be incentivized by over-subscribers to leave. And when there is over-subscription, there is more slashed than the nominal maximum amount (they are all still at stake). And over-subscribers otherwise have full voting rights.

I think we could maybe do better... why not a 1% cap? Then there would be many top level validators. The cap should be determined ultimately (when t is in the far future) by how many equal full sized validators we want in the world. There are 195 countries in the world, so a 0.33% cap is compatible with every country having at least one full validator.

Large stakers can split their validators but we should have validators declare any such conflicts and associations, if not on chain, at least to any staker that asks, because stakers should know such associations, and then they can decide to avoid staking to them on their own (or not). This should be possible with a well written constitution.

As a function of time, it would make sense for a chain to start less decentralized, but grow its decentralization over time. So at first it could be 10%, but really it makes more sense for it to go below 1%. with 10 equal nodes, you need 4 to fail at a time. with 100 you need 34. 4 is easy to coordinate with any single malicious actor. 34 is reasonably difficult. With 0.33% you need 101.

I'd say, after a number of years we expect a certain amount of countries to have full sized validators, and to hold some body to account for this. If it doesn't happen, it would be because another branch did it, and that's better than overspecifying it and getting it wrong for AtomOne, so I suggest we make it a stretch goal and incentive to accomplish.

The GovNo chain should decide on whether to take this on. I believe the ATONE distribution would be best suited for creating an intentional global validator set, and the world needs an alternative to the UN which can't even prevent a genocide from happening due to a single veto from the US. We can demonstrate transcendence and constructive progress by giving every country a node they can choose to use, where no single country or validator can veto a whole.

Flip it. Does your chain require global decentralization by constitutional mandate? If not, then how do you know it's decentralized?

ABCharlieEth commented 9 months ago

Interesting idea to achieve decentralization, maybe you are aware that Sifchain implemented this in 2022, the implemented with 6% and the aim was to reduce it to 3%. But, issue they were facing at the moment was the resistance from the top validators among other issues. I believe we should start from lower than 10% as it will be hard to reduce it much in the later stage.

Ideally, for a perfect scenario all val set should be global and equally talented with equal VP, but due to many reasons we can not achieve this but we should try to get close to the target as much as possible. On code level if we could implement the max-vp-cap we should, and cap should be lower than 10% from the start with the intention the go lower in the future.

jaekwon commented 9 months ago

Yes and if we just have the right dashboard it should be good to incentivize world-wide decentralization and participation. The stakers can choose for themselves, or else risk a split doing it better.

hsibai commented 9 months ago

I propose a variable rewards system affecting the rewards a validator receives based of preset rules such as:

  1. A validator whose self bonded to delegated ratio is below a preset min parameter received less rewards. The clawed/taxed amount goes to comm pool.
  2. A validator whose total bonding grows to more than 1% (for example) of supply also receives diminishing rewards on the excess amount above 1%. Aim is to discourage centralization.
  3. The above will encourage them to remain in "The Goldilocks Zone" to receive 100% of the rewards.
stevenoruzi commented 9 months ago

or we could just display the self-bond amount, and, what if somebody wants to delegate anyways even if the self-bond was small? this could be the case for any validator just getting started... startups eat ramen for dinner, speaking from experience.

you are right, it might seem unfair to the small fish. We could consider offering support to them in the Genesis phase, perhaps through an airdrop to validators involved in the testing phase. Additionally, we could introduce a new risk factor on UI that is a result of multiple parameters such as missed blocks, self-bond, participating governance (, etc.) to make it more practical for the users.

That said, how about the following?

  • [ ] Make self-staking take longer to unbond. Say twice as long.
  • [ ] With the above ensure that delegators can unstake first if self-staking decreases.
  • [ ] Create tooling to alert stakers about self-staking changes.

I think none of them would work. also as you said stringent minimum requirements on self-bond won't work as we want. I would like to find a better validator guarantor. or we should leave this part and try to make it simpler for the user from UI to decrease their risk as mentioned above.

jaekwon commented 9 months ago

A validator whose self bonded to delegated ratio is below a preset min parameter received less rewards

A minimum self-bond ratio will create a marketplace of loans where stakers loan some amount for the validator to "self-delegate", for some slightly less than favorable terms as opposed to the validator simply staking themselves. "Self-delegation" precludes ICA, but there are other ways to create auto-loans, and also it is easy enough to do with the existing legal system (sidechannels). These sidechannel loans would not be traceable in general, and we would lose any insight from self-delegation ratios. So I think this is possibly practically self-defeating depending on how easy it is to get a loan. (And, it isn't sufficient to declare it illegal in the constitution if it will be practically impossible to regulate; that only undermines the constitution). So we would have to ensure that it is not easy/possible to create contracts based on the future revenue of a validator (for one). Even though self-delegation precludes ICA, if it were possible for a validator to set the reward-output address immutably to a destination smart contract, it would be easy to construct an automatic loan which defeats the purpose of the minimum self-bond ratio.

Validators do have something at stake; they have the future positive revenue/inflation at stake. Arguably this is fleeting as the delegators may undelegate at any time, but if the unbonding period were optionally allowed to be significantly longer (but with no extra incentive), then this is arguably a stronger guarantee and it is also open to anyone. But I don't think I would want to require a minimum % to be long-bonded either because of the distortions that it might introduce. We could disable long-bonding from ICA accounts to discourage distortion markets (a problem which doesn't exist with "self-bonding"). And only then, might I say, that I think off-chain sidechannel distortion markets are less likely to appear with a minimum long-bond % as opposed to a minimum self-bond %, and so is less self-defeating, but I am not entirely sure about this either.

Who knows what ratio is more important, whether self-bond or long-bonding? Letting the delegator decide might be the better strategy. And maybe the self-bond can also be long-bonded (why not?). Now we have a third category of long-self-bonded stake.

If we want to make sure a validator is healthy, I think we would require a few things besides imposing self-bonding or long-self-bonding requirements. For example, it must not take on significant debt obligations in such a way that it jeopardizes its short term and long term sustainability. A Validator should not take a loan of ATOMs for terms that are no better than staking itself (otherwise as mentioned above it defeats the purpose of the self-bond ratio), but how much better do the terms need to be? If the validator is punished upon slashing, how do we prevent the loan terms from unreasonably encumbering the safe operations of the validator after slashing?

Related note: What sort of requirements do banks have? Maybe some are relevant.

COverS8 commented 6 months ago

In Cosmos Hub, many delegators usually delegates to the lowest commission validators to maximise their rewards. What if AtomOne Hub validators were set the same commission rate that could not be changed without a proposal and the commission change proposal could not apply to just one particular validator but to the whole set, plus a scoring system based on reputation that would give an indication of a validator's reliability. The scores would not rank the validators e.g. 1-50 to avoid delegators to delegating just for the Top validators but e.g. in two separate baskets. Basket 1 for validators who performs their duty (uptime/creating blocks) and basket 2 for validators who don't, misses the blocks/slashed/jailed. Another duty of the validator is to participate in the governance which should also be linked to the scoring. By eliminating the advance with the commission, the decision of the delegators would be based on the reliability of the validator which should be visible to delegators when making a delegation decision, either directly in the wallet if possible or on the dashboard. The delegators can then decide between the basket 1 validators where to base delegation by this scoring system and also by doing own research by visiting on validators websites and social medias to see how dedicated and engaged the validators are with their contributions to the Cosmos Network and AtomOne. Ending up in Basket 2 would incentivise the validators to perform better and the basket may even be empty if everyone performs their duty.

ABCharlieEth commented 6 months ago

Yes and if we just have the right dashboard it should be good to incentivize world-wide decentralization and participation. The stakers can choose for themselves, or else risk a split doing it better.

Can you explain what you meant when you said the "the right dashboard"?