[AIP-6][Discussion] Delegation pool for node operators

[alexfilip2]

AIP-6: Delegation pool for node operators

Summary

Currently, only token owners with 1M APT are able to stake their tokens and earn staking rewards. We want to enable everyone in the community to have access to staking rewards as well. We propose adding a delegation contract to the framework. This extension enables multiple token owners to contribute any amount of APT to the same permissionless delegation pool. As long as the total amount of APT in a delegation pool meets the minimum stake required for staking, the validator node on which it is set on will be able to join the active set and earn staking rewards.

Participants (delegators) would be rewarded proportionally to their deposited stake at the granularity of an epoch. Delegators will continue to have the same stake management controls (such as add_stake, unlock, withdraw etc.) in the delegation pool, similar to pool owners in the existing staking-contract implementation.

For the P0, existing stake pools cannot be converted into a delegation stake pool. A new delegation stake pool would have to be created. However, this could be a future development.

Motivation

The current staking mechanism puts the community at a disadvantage, as it is less probable that a single individual has 1M APT tokens to start their own validator.

Given this functionality is enabled, the community can participate in staking activities and incentivize validators thus adding value to the ecosystem.

On the other hand, the entry stake requirement makes it difficult for some actors, possibly experienced in maintaining and securing blockchain validators, to join the network as node operators. With this new functionality, they can get support from the community to enter the active set.

In the current staking implementation, the activeness of a validator is influenced by a single entity's stake (stake-pool owner) which can leave the node unstaked at any time (actually on lockup period expiration). In the new implementation, this scenario is less likely to occur.

Rationale

This feature has the potential to increase the number of validators in the ecosystem leading to further decentralization and a higher amount of tokens staked on the protocol.

Specification

A detailed specification of the proposed solution can be found here.

To summarize, the following behavior would be supported:

• Admin of the delegation pool = node operator
• Initiates delegation pool
• Join validator set
• Leave validator set
• Set commission rate at the start of contract
  • Contract will pay commission out first, then rewards to principal
  • Commission rate cannot be changed
• Delegators = token owners
  1. Add stake
  2. Schedule stake for unlocking
  3. Cancel unlocking of stake (moves stake to previous state)
  4. Withdraw stake
• Reset-lockup = No one
• Delegated voter = Admin

The operator fee, previously configured by the owner, will be immutably set at pool's creation by the node operator itself. Therefore, delegators have the option to participate in pools of their choice with regard to commission fee.

Reference Implementation

There is a reference implementation, integrated directly into the framework, treating aptos_framework::stake module as a black box, at https://github.com/bwarelabs/aptos-core/tree/bwarelabs/shares_based_delegation_pool.

Risks and Drawbacks

The staking API initially exposed would incur a higher gas cost (only for delegation pools) as additional resources have to be stored and maintained in order to keep track of individual delegators' stakes and rewards earned by pool's aggregated stakes.

Future Potential

We could uniformly enforce that a delegator cannot decrease the total stake on the pool below the active threshold or decide to fully unstake the delegation pool.

We could restrict the node operator to deposit a minimum stake amount in order to allow its pool to accept delegations.

Suggested implementation timeline

We hope to get it on the mainnet in Q1, but this is pending further technical scoping.

[alexfilip2]

AIP PR - #21

[wintertoro]

PR approved - AIP link: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-6.md

[BondCrypto]

Hi there!

I think making an immutable fee for a public pool is a kinda controversial idea in the long term. It can potentially limit flexibility for validators to reflect changing market conditions and staking revenues.

For example, changing the fee to 0% can be a good option to compensate for a short-term weak performance/incident that led to a reward loss without the need to send and calculate rebates per user, imposing a legal risk of a custodial transfer.

Curious if the decision to make an immutable fee is based on tech limitations, or are there other reasons for that?

[wintertoro]

Given the nascency of delegation on aptos blockchain, I would suggest an immutable fee helps to protect the stakers by ensuring that the operator doesn't suddenly raise fees without notice / public announcements. This is important given that many stakers might leave their tokens in a pool and not pay attention for a long while. However, I agree that potentially allowing operators to have the ability to change fees based on market conditions might be a useful feature in the longer term. But I would class this as a P2?

[iicc1]

Great initiative and good work. I think this feature is highly needed.

I don't think that commission modifications are a priority either, but as an idea to solve the issues you are mentioning, other networks implement a commission change cooldown, a max commission change per period, and a maximum commission. Thanks to this, users can be protected and you don't limit the flexibility of the pools too much.

[Rob-StakingCabin]

Thank you guys for putting effort into making it happen. It's something we all need. I am just curious to find out some details.

Will there be a minimum delegate amount for a delegator?
Will there be an auto-stake function after community members delegate to a validator node?
Where community members can get access to this awesome smart contract?

Thanks.

[alexfilip2]

hello @Rob-StakingCabin, to answer your questions:

1. I think it is recommended to have a symbolic minimum delegation amount to ensure pools are not flooded (especially for off-chain introspection in an explorer)
2. Rewards are automatically restaked for delegators as it happens for the stake-pool owner currently
3. As mentioned above, we hope to get it to mainnet in Q1. The up-to-date implementation can be found at the aptos-core fork referenced in the 'Reference Implementation' section (branch bwarelabs/shares_based_delegation_pool

[Rob-StakingCabin]

Thank you @alexfilip2 for the answer. Looking forward to it.

[kinrokinro]

Finally! Looks ok to me, looking forward 👀

[alejopinto77]

I think another risk to consider is that there is currently no slashing (only missed rewards). Curious to understand whether slashing is also in roadmap or what the considerations are for not having it.

Intuitively, it seems like end users would action more quickly on switching validators when getting slashed rather than just missing out on rewards.

[Proskhmer08]

Yes. This is needed.

[the-frey]

We could restrict the node operator to deposit a minimum stake amount in order to allow its pool to accept delegations.

This would probably be sensible, although setting the bar would be tricky as the cost of minimum delegation would fluctuate with market conditions.

RE:

Given the nascency of delegation on aptos blockchain, I would suggest an immutable fee helps to protect the stakers

From @wintertoro - other networks have solutions like setting a max change param for the operator which is the maximum % change allowed in one go. An operator also has to set a ceiling of %. I believe @iicc1 is also referring to the same mechanism.

e.g. I could say my commission is 5%, my max commission threshold is 15% and my change is 2%. So delegators can expect what my bear market commission might be, as well as the max speed that commission could be changed.

Agree it's a P2 though.

Would say that the ceiling is the more useful thing, not sure your average delegator selects based on the change %, from what I've seen.

Final thing on fees - 0% commission can become quite toxic, as it results in a "race to the bottom" for validators and defeats the object of the exercise, so it's good to set a sensible lower bound.

I think another risk to consider is that there is currently no slashing (only missed rewards). Curious to understand whether slashing is also in roadmap or what the considerations are for not having it.

We've talked about this a lot on the validators podcast that we do, but slashing tends to overwhelmingly affect delegators rather than node operators unless the operator has a lot of tokens staked to their node. (see my first point). However, by increasing the stress involved in maintenance (risk of slash) the irony is probably that best practices sometimes are not followed.

I guess the broad point I'm trying to make there is that the desired incentive that slashing represents has in practice been supplanted often by unintended side effects. Node operators seek to stay up because of rewards. Slashing often just seems to be an arbitrary penalty when it does happen.

Final thing - on voting, there haven't been any controversial props on Aptos yet. There probably will one day, and in that scenario voters are going to want to override their validator's vote, or it will be a bloodbath. That's from direct experience in Cosmos, where the chain-level DAO democracy can get really quite wild (to put it mildly).

Apologies for the brain dump!

[mathiyarasu65]

looks Good to me.

[GPvalidator]

I think it was necessary for a long time. to maintain decentralization it is essential to maintain a variety in the set. that seems fine to me.

[jay-a41]

First of all, this work is a great initiative! Appreciate your work :)
However, for the benefit of validators and delegators, you can work on some features to be more flexible.

1. (NECESSARY) Commission Change

• Flexible commission setting is essential from an operational/strategic perspective for protocols and validators. For instance, in some protocols in the Cosmos ecosystem, there have been some proposals to force minimum commission above a certain percentage to all validators to guarantee the continuous operation of small validators with low stakes. Therefore, even in Aptos, validators should be able to adjust their commissions on the scheduled epoch freely. Of course, there is a risk of validators' sudden change in the fee without any notice/disclosure, but the benefit of flexible setting on commission is greater than this risk. If a validator uses the commission maliciously, the validator will be naturally left behind in the community. (+ The minimum commission criteria for each validator can be discussed in a separate agenda)

2. (OPTIONAL) Implement Re-delegation

• In chains adopting DPoS, re-delegation is very widely used. However, implementing the re-delegation feature can be complex, especially in chains managed on an epoch basis (i.e., Aptos). Nonetheless, the feature is needed for Aptos since the re-delegating process without the re-delegation feature requires two steps (i.e., unstake -> stake) for delegators, degrading the delegators' UX.
  To handle this, we can devise a separate Re-delegation Pool (e.g., RDP) so that delegators can easily re-delegate to other validators on scheduled epochs. This RDP interacts with all DPs, and only contains meta-information about which validator a specific address intends to re-delegate to in a specific epoch.

3. (This is a question) Why do we need Minimum Staking Amount?

• I looked at the discussion above, but I still don't understand why there should be a minimum delegation amount. No matter how minimum the delegation amount is set, the amount will still be debatable. Could you elaborate more?

Thank you :)

[alejopinto77]

Final thing on fees - 0% commission can become quite toxic, as it results in a "race to the bottom" for validators and defeats the object of the exercise, so it's good to set a sensible lower bound.

I think having flexibility for immutable or mutable with multisig is good. As others mentioned, there could be times when a validator might want to change even to 0% for a short period of time. Would not recommend setting limits to changes in thresholds and would let just free market dynamics play out.

For fees, same as a module, validators could choose mutable or immutable. Best practice could be to have a guarded launch that is mutable and then over time remove safety limits and make immutable. More flexibility in the standard allows for more use cases.