Ensure that dRep ID exists prior to delegation

[Crypto2099]

Delegation to a non-existent or retired stake pool is already blocked by the ledger.

However, it is possible to delegate to a non-existent dRep. This seems to circumvent the spirit of CIP-1694 in blocking the withdrawal of rewards given that I can delegate to an impossible to exist dRep that will never take any action in the governance system.

Expected Behavior: A user delegating to a non-existent or retired dRep should fail at the ledger level.

Example: https://cardanoscan.io/transaction/cf9ae712270a0b5de6f3f41f8a1b640d7412e8bbba4253eaf8b78bc589a6a094?tab=voteDelegations

[dmitrystas]

some example of cardano-cli (mainnet) queries

$ cardano-cli conway query stake-address-info --mainnet --address stake1u8eq8dc6qtxsu47lhthv3nadrq84uxsgfqe5pl54vrq6v3g32208l 
[
    {
        "address": "stake1u8eq8dc6qtxsu47lhthv3nadrq84uxsgfqe5pl54vrq6v3g32208l",
        "delegationDeposit": 2000000,
        "rewardAccountBalance": 0,
        "stakeDelegation": "pool15f9qklmaajysmwx9n3rkgc5s2g3rfffz4x8spnedtzdgq43tpe2",
        "voteDelegation": "keyHash-e5ab37261b3d63600d566564879370aea031ea3108b0a6bd8cef58aa"
    }
]

$ cardano-cli conway query drep-state --mainnet --drep-key-hash e5ab37261b3d63600d566564879370aea031ea3108b0a6bd8cef58aa
[]

$ cardano-cli conway query drep-state --mainnet --drep-script-hash e5ab37261b3d63600d566564879370aea031ea3108b0a6bd8cef58aa
[
    [
        {
            "scriptHash": "e5ab37261b3d63600d566564879370aea031ea3108b0a6bd8cef58aa"
        },
        {
            "anchor": {
                "dataHash": "a214b912ae98087dbc83cffc62f2c6ca878b5ef9c15d3d7b92b0ed64ef1d6981",
                "url": "https://raw.githubusercontent.com/perturbing/DutchRep/main/data/drep.jsonld"
            },
            "deposit": 500000000,
            "expiry": 527
        }
    ]
]

[lehins]

This decision of allowing delegation to non-existent pools came from the formal ledger specification. However, after some back and forth with formal methods team we've realized the same thing, that it was a bad idea indeed, especially since it is inconsistent with delegation to stake pools. Problem was that we realized this a bit too late in the game, so we had to launch Conway with this approach. All this means is that we are planning on fixing this. So, thank you for opening this ticket.

This seems to circumvent the spirit of CIP-1694 in blocking the withdrawal of rewards given that I can delegate to an impossible to exist dRep that will never take any action in the governance system.

It doesn't really circumvent it, since delegation to a non-existent DRep still requires an explicit action on the user's part. So, if you delegate to an "always abstain" or non-existent DRep it will have the same affect.

[lehins]

A bit of detail for the future dev that will be implementing this:

We also need to cleanup all delegations for every DRep unregistration certificate.

[perturbing]

It doesn't really circumvent it, since delegation to a non-existent DRep still requires an explicit action on the user's part. So, if you delegate to an "always abstain" or non-existent DRep it will have the same affect.

How will the stake delegated to a non-existing DRep be counted in the total delegated stake, and how does this work regarding the thresholds for various gov actions?

[lehins]

How will the stake delegated to a non-existing DRep be counted in the total delegated stake,

It won't be counted at all. That is why it would be equivalent to delegating to a DRep that votes Abstain or to a predefined DRep that votes AlwaysAbstain, since abstain votes do not affect the total stake that is used in voting. This also means that stake does not affect the ratio that is being compared with the thresholds.

To put it simply, delegating to a non-existent DRep or to a predefined AlwaysAbstain DRep is like not delegating to any DRep at all.

[lehins]

This issue is blocked on #4621, since we need a mechanism to clear out all dangling delegations upon an intra-era hard fork

[Crypto2099]

If I read this right then we'll have to wait until the next HFC/Era transition to implement this?

[lehins]

This issue is blocked on #4621, since we need a mechanism to clear out all dangling delegations upon an intra-era hard fork

Slight correction. Fixing this ticket will result in a change to ledger state serialization, therefore all nodes will be forced to replay from genesis, thus we can put the necessary logic into the translation from Babbage to Conway. #4621 would probably be necessary if we already had #3220 implemented and we no longer required a replay from genesis on changes to ledger state serialization.

[lehins]

Spoke to soon. We do need the HARDFORK rule from #4621 in order to cleanup any delegations to non-existent DReps.

[lehins]

One interesting consequence of this change that people should be aware of is that with current semantics unregistration followed by a re-registration of the same DRep does not remove any delegations, while with the change proposed in this issue DReps will start with a clean slate when they re-register. Which is a good thing IMHO, but that is something DReps should be aware of, since wrongful unregistration will result in loosing all delegations.