Ledger drop (future) constitutional committee member hot credential

[KtorZ]

Hello; I recently run into a surprising behavior which might be dismissed as "expected", but I'd still argue it is surprising and likely wrong.

Context:

• The ledger allows (for some reasons?) non-elected CC members to delegate their (potential future) cold credential to a hot credential. This is visible in the GOVCERT rule:

  https://github.com/IntersectMBO/cardano-ledger/blob/4b8d55d5284e2faef3a7ebde3ecd60c248362f49/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/GovCert.hs#L199-L201

• I have successfully proven that on mainnet: https://cardanoscan.io/transaction/d62db0b98b6df96645eec19d4728b385592fc531736abd987eb6490510c5ba50 (this delegation happens few epochs before the CC was effectively ratified and elected).

• However, inactive CC delegations are pruned at every epoch boundaries, in the EPOCH rule.

  https://github.com/IntersectMBO/cardano-ledger/blob/4b8d55d5284e2faef3a7ebde3ecd60c248362f49/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Epoch.hs#L349-L350

  https://github.com/IntersectMBO/cardano-ledger/blob/4b8d55d5284e2faef3a7ebde3ecd60c248362f49/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Epoch.hs#L426-L430

In this last step, there's no notion of potential future members. I also experienced this first hand, as I had to re-delegate when time to vote came few epochs later.

I guess the main surprising thing to me is that the ledger would authorize delegations prior to CC members being elected. I can only assume that this exists to allow CC members to register their hot keys in advance so that they can be "ready" to vote immediately when they enter in function.

Given that the CC voting threshold's denominator is determined by the the number of active members, and members without a hot delegation are NOT considered active; I could see how this could be a problem; but we do have a committeeMinSize protocol parameter for that reason.

So the current mechanism of registering keys in advance only really work should a member register their cold -> hot delegation in the same epoch that the (delayed) ratification / enactment occurs. I don't think anyone is really educated on that topic; nor that it is particularly useful?

I wonder if I am missing something and whether everyone is aware of this behavior.

[lehins]

This behavior you just described is indeed as expected. It was designed in such a way on purpose to give CC opportunity to cost a vote one full epoch before they get enacted, because at that point they know for a fact that they will be enacted.

I am boarding the plane now, so I can't really look it up, but from my memory it goes like this:

1. CC member can authorize a hot credential for any cold credential in the system, even if that credential was not enacted yet.
2. If on the epoch boundary cold credential is not enacted then the authorized hot credential is pruned, including all the votes that were cast by that credential
3. However, if cold credential was enacted then all the votes and hot credentials instantly become valid.

If it was not done that way then initial vote of a CC member when one was enacted would not be counted for a whole epoch.

I could see how this could be a problem

I am more than sure that it cannot be a problem, because during size calculation only enacted CC memebers that have a hot credential authorized are taken into concideration. In other words this pre-authorization has no impact on the size calculation.

I don't think anyone is really educated on that topic; nor that it is particularly useful?

If my memory serves me right this was a feature that was discussed very early on even when I was not leading the project. Despite that it was not my doing I do believe this is a useful feature, since CC is watching those CC Update actions like a hawk. Giving them ability to have their votes to be counted as soon as they are enacted is something they could care about.

In any case, this is the way it is today and I don't see any compelling reason why it should be changed.

I wonder if I am missing something and whether everyone is aware of this behavior.

I am sure not everyone knows about this feature, but many people do, including some members of ICC, since it has been diacussed on many occasions.

One very much valid complaint could be made about this feature, is that it is probably not documented or underdocumented