remove ranking code

[JaredCorduan]

After we have the new stake pool ranking in place, and once Daedalus is not using any of the old ranking support, we need to remove all remnants of the old ranking. This includes the parts of the ledger state that are used only for ranking.

[jiagengliu]

Hello Jared, I am wondering when did Daedalus update to use the new ranking? Can I still find the old ranking in any design spec?

[JaredCorduan]

Hi @jiagengliu , we are still using the original stake pool ranking design, as described here: https://hydra.iohk.io/job/Cardano/cardano-ledger/specs.pool-ranking/latest/download-by-type/doc-pdf/pool-ranking

[jiagengliu]

Thank you, @JaredCorduan . I try to replicate the Daedalus ranking but I think the ranking spec is outdated.

1. I don't see the applyDecay function mentioned in the document.
2. The prior and percentile are now Beta(40,1) and 50% but the document is not updated?

I wonder if anything else is missing? If there's any script or API available for computing the pool ranking, I'd appreciate it if you can share it with me. Thanks!

[JaredCorduan]

You're right about applyDecay, we added it to the implementation but never updated the pool ranking document, apologies. We are going to deprecate the whole thing (hopefully) soon (hence this github issue), so we probably won't update the document.

As for the prior and the percentile, we left it intentionally unspecified in the document. My hope at the time was that we would be able to add toggles to Daedalus so that folks could chose their own. But this never happened, and the plans are now to go with a much different plan.

The wallet uses this API function: https://github.com/input-output-hk/cardano-ledger/blob/dd13fadabfe6760ec88caa9d605a67018633212b/eras/shelley/impl/src/Cardano/Ledger/Shelley/API/Wallet.hs#L362-L371

I appreciate your interest in the topic, and it's great to see someone from the community putting the spec and the code together, that makes me really happy! So sorry if it's a bit disappointing that this is all being retired.

[jiagengliu]

Thank you so much @JaredCorduan! I appreciate your help and I am able to get the list of current stake pools via the API. Sorry to hear that it's being retired. What is the new ranking algorithm going to be?

[JaredCorduan]

@jiagengliu - I don't want to steal the researchers thunder, and I've only seen a draft that has probably changed since I saw it. Hopefully we can share a document soon!

[PhilippeLeLong]

@JaredCorduan when I checked the ranking in Daedalus it seems like it's using current stake instead of assuming non-myopic stake, i.e. a fully saturated pool.

Also you mention that this will be depracted in favor of a new ranking system. Where can I find a description of this new system?

[JaredCorduan]

I honestly do not know what the status of that is, @PhilippeLeLong , I'm sorry I can't be more helpful. Over a year ago, I had thought that we were close to adopting this: https://github.com/input-output-hk/cardano-ledger/pull/2410, but that seems to have not gone anywhere. I will ask around and see if I can learn anything.

@HeinrichApfelmus do you know anything about potential new rankings?

[PhilippeLeLong]

No worries @JaredCorduan . I do feel however that this topic is not unimportant. In the design specifiactions it's explicitly mentioned that a non-myopic pool ranking is vital for educated delegator decisions and reaching nash equilibrium. Having a fully functioning reference implementation that could be adopted by other ranking sites and wallets would be very helpful for our ecosystem and increasing decentralization/nakamoto coefficient in my opinion.

[HeinrichApfelmus]

Having a fully functioning reference implementation that could be adopted by other ranking sites and wallets would be very helpful

I agree.

I was responsible for working on the stake pool rankings in cardano-wallet, but my efforts (e.g. https://github.com/input-output-hk/cardano-wallet/pull/2781 , https://github.com/input-output-hk/cardano-wallet/pull/3195 ) mostly died at the time, as the cardano-node was too slow to provide aggregated stake pool data.

However! I did manage to implement the formulas for ranking, even though I was lacking the data to apply them to. If you want to implement your own light wallet, you can get the data from providers such as Blockfrost (but do keep in mind that you have to trust Blockfrost to provide correct data), and apply the following code:

• Cardano.Pool.Rank
• Cardano.Pool.Rank.Likelihood

The new rankings of interest are currentROS and saturationROS. The redelegationWarning is necessary to penalize pools that do not produce blocks.

I implemented them from an internal document prepared by R & D, but I do not know if I am allowed to make this document public.

[PhilippeLeLong]

Thanks @HeinrichApfelmus. So how does dadelus ranking work right now? From the outside it seems it does aggregate the data but just doesn't interpret it "correctly".

I'm not a developer myself but I'll try to share this information with some of our ecosystem's wallet and ranking providers.

PS: Happy to see you're still working on Cardano. We met on the train ride to the summit in Berlin in 2021.

[HeinrichApfelmus]

So how does Daedalus ranking work right now?

I actually do not know what ranking is displayed in Daedalus right now — cardano-wallet provides several rankings, but it's up to Daedalus to display it. Last time I looked at it, I think you could sort the table by current rewards or non-myopic rewards.

From the outside it seems it does aggregate the data but just doesn't interpret it "correctly".

Yes, that's one way to put it. The non-myopic rewards are deprecated. The new, simpler, "correct" ranking is this:

• currentROS = return of investment (percentage yearly) on your stake that you would get if you were to delegate to this pool now
• saturationROS = return of investment (percentage yearly) on your stake that you would get if the pool were fully saturated (i.e. in a future where the pool attracts a lot of delegations)
• redelegationWarning = a message sent to the user if the pool either does not produce blocks, or does not provide enough rewards compared to other pools.

PS: Happy to see you're still working on Cardano. We met on the train ride to the summit in Berlin in 2021.

Haha, nice! A pleasure to meet you again. 😊

[PhilippeLeLong]

saturationROS sounds like it's pretty much the same as non-myopic stake. Daedalus only shows the currentROS, which does not lead to k fully saturated pools since the current RoS is heavily influenced by minPoolCost and current saturation, thus making pledge largeley irrelevant for pools with low saturation.

Does current and saturation ROS still consider pool performance/hit rate, i.e. some form of average perceived performance (actual blocks / expected blocks based on relative stake)?

[HeinrichApfelmus]

saturationROS sounds like it's pretty much the same as non-myopic stake.

Almost, but there is an important difference — the non-myopic rewards assume that only the first k (= 500 at the moment, I believe) stake pools are going to be saturated, and the others will not attract any stake. This leads to a sharp drop in the score for any pool below the top, which — as far as I understand — has been a source of frustration for SPOs.

The new saturationROS does not attempt to make predictions about the pool compared to others.

Daedalus only shows the currentROS, which does not lead to k fully saturated pools since the current RoS is heavily influenced by minPoolCost and current saturation, thus making pledge largely irrelevant for pools with low saturation.

Yes. If I remember correctly, simulations suggested that showing the currentROS only will lead to frequent redelegation to the point that the system never stabilizes. Some leap of faith concerning the behavior of others is necessary in order to move the system to stable state — this leap can be as simple as choosing a pool that will do well in the future according to saturationROS and then stopping to care about it.

Does current and saturation ROS still consider pool performance/hit rate, i.e. some form of average perceived performance (actual blocks / expected blocks based on relative stake)?

No, and that's also new compared to the previous ranking. In order to account for performance, R&D recommends to use the redelegationWarning instead.

[PhilippeLeLong]

No, and that's also new compared to the previous ranking. In order to account for performance, R&D recommends to use the redelegationWarning instead.

So the estimated ROS will assume 100% pool performance? How does redelegationWarning tie into this? Looking at the code it does look like the warning is based on a calculated pool performance estimate, but does it affect the ranking in any way or is it just used as a visual indicator? It wouldn't make much sense if the user is informed about this after delegating based on saturationROS

This leads to a sharp drop in the score for any pool below the top, which — as far as I understand — has been a source of frustration for SPOs.

This seems like a good compromise for a less opinionated ranking.

[HeinrichApfelmus]

So the estimated ROS will assume 100% pool performance?

Yes.

How does redelegationWarning tie into this? Looking at the code it does look like the warning is based on a calculated pool performance estimate, but does it affect the ranking in any way or is it just used as a visual indicator?

The warning makes a lot of sense by itself — it alerts a user who has delegated to a pool that performed well once, but performs poorly recently. The same goes for a pool that has increased their margin too much. In that sense, having this warning is almost necessary in order to detect pool issues long after delegation, and one may as well use it for performance issues and simplify the rankings instead. That's the reasoning by R&D, but I can try to contact them directly for more background, if you want.

It wouldn't make much sense if the user is informed about this after delegating based on saturationROS

If the pool has a history of not producing any blocks at all, then I suppose the warning would trigger immediately — and could be shown even before delegating, or rather, worked into the ranking. The key point is that instead of affecting pool ranking in a continuous fashion, performance issues have become a "yes/no" indicator.

[PhilippeLeLong]

Thanks Heinrich, really appreciate the input. Getting more info from R&D regarding this topic would be very welcome by the whole community!