Relayer DPoS

[4meta5]

Goal: configure simple, efficient DPoS to enable relayer revenue sharing

requirements

• use accrued relayer fees for collator stake
• permissionless delegations
• slashing?

implementation ideas

Early idea is to add a new pallet-delegate which (in)directly uses/requires polkadot-sdk/collator-selection pallet (and also configure pallet-collator-selection in the runtime). Building on this pallet for the initial implementation is safe because it is already audited as well as tested by widespread ecosystem usage.

pallet_delegate::Config:

• Currency
• MinDelegation

pallet_delegate::Calls:

• delegate: increase/initiate delegation
• undelegate: decrease/remove delegation

[seunlanlege]

I think it makes sense to try to leverage pallet-collator-selection in some way, the only thing to keep in mind is, relayers won't bid with the native token to become a collator. They'll bid with their "accrued revenue", which is the revenue they've accrued relaying for hyperbridge. This revenue accrual is currently tracked in pallet-ismp-relayer, although it is deleted when relayers make a withdrawal. I think it makes sense to figure out how to use it for collator selection

https://github.com/polytope-labs/hyperbridge/blob/main/modules/ismp/pallets/relayer/src/lib.rs#L82-L86

[Wizdave97]

We'll need some form of identity pallet that relayers can use to associate a hyperbridge account to any number of accounts that have successfully accumulated fees in pallet-ismp-relayer

[4meta5]

Thanks for the feedback @seunlanlege @Wizdave97 !

Is there a preferred way for estimating the value of the accrued fees in terms of the native asset (to represent accrued fees as stake to bid for a collator spot in pallet-collator-selection)? This would have to be in the runtime. Maybe there is some fee conversion config that could be reused for this purpose?

Another idea is to fork pallet-collator-selection and make it work with more than one currency by adding an associated type like xcm_executor::Trader. The changes could be upstreamed eventually, but one concern is the complexity of representing minimum stake and ordering stake in the context of multi-asset deposits; value comparisons across assets would still be necessary.

[Wizdave97]

The accrued fees are are already denominated in USD, we would not need to know the equivalent in terms of the native asset. We only need to use for the accrued fees to know the relayers that have been active in the previous session, these are the only relayers eligible to be part of the next collator set. We want to reward relayers who have committed the most to facilitating cross chain message delivery.

The conditions for selecting relayers would be in the following order:

1. Select all relayers who have accrued some fees in the previous session(we'll need to modify pallet-ismp-relayer to preserve this data), the list will be sorted by fees accrued.
2. Select those who have the native asset staked from the previous set to be the new collators(selected number would be dependent on max number of collators configured in the runtime).

For nominations, nominators are not directly staking on relayers but are contributing their nominations to a global nomination pool, the goal is to allow any account who has some amount in the pool to receive some portion of the protocol revenue.

We would use some sort of curve to gradually increase the minimum amount to be staked or nominated gradually as the network grows.

[seunlanlege]

Another idea is to fork pallet-collator-selection and make it work with more than one currency by adding an associated type like xcm_executor::Trader

Likely we don't need this and we can maybe track the accrued fees in pallet-assets and use fungible::ItemOf to get the Currency interface.