CIP-0154? | Orthogonal Certificates

[yHSJ]

NOTE: This CIP was initially suggested and discussed in person during the Node Diversity Workshop in Paris, France, April 7-9, 2025.

---

The transaction is the most important interface in Cardano. Therefore, we should strive to make it as simple as possible without sacrificing functionality or security.

This CIP proposes a change to the ledger: replacing the certificates introduced in the Conway era with much orthogonal certificates, each scoped to a single action. This change significantly simplifies certificates, making them easier to use, document, and implement—which is especially important as alternative nodes are being implemented.

---

(rendered version)

[Ryun1]

hey @yHSJ

Thanks for the proposal
See a few minor editorial comments

Overall, I think this is well written and motivated proposal
One thing i may suggest adding is some numbers on how many times these 'combination certificates' have been used on mainnet
as I suspect that these certificates havent been widely adopted, maybe in-part because hardware wallets don't support them

[WhatisRT]

Thank you for submitting this! I think to allow for more discussions and for completeness sake, it would be good to mention the alternative option which we originally discussed, that would have one certificate with optional entries for stake & vote delegation. The upside of this would be that it's purely a CDDL change.

[rphair]

@yHSJ @WhatisRT it's great to see that you've preloaded this with Ledger feedback & looking forward to introducing this at tomorrow's CIP meeting (tagged Triage): https://hackmd.io/@cip-editors/110

[KtorZ]

For completeness, it would be worth highlighting how many bytes in the Rationale section, to show that the original motivation for introducing those numerous certificates was likely a bit misguided.

[yHSJ]

Good point, added the worst case numbers.

[KtorZ]

For backward-compatibility reason, it would be necessary here to specify the new indices, and makes sure that they don't clash with the current ones. This way, one could virtually still deserialise a compound certificate into two orthogonal ones; and ensure that we don't needlessly break all transaction builders once again.

[lehins]

There is no need to break existing specification. All you trying to do is remove some certificates, while leaving others unchanged.

Suggested change

	stake_registration_cert = (N, stake_credential, coin)
	stake_deregistration_cert = (N+1, stake_credential, coin)
	stake_delegation_cert = (N+2, stake_credential, pool_keyhash)
	vote_delegation_cert = (N+3, stake_credential, drep)
	stake_registration_cert = (7, stake_credential, coin)
	stake_deregistration_cert = (8, stake_credential, coin)
	stake_delegation_cert = (2, stake_credential, pool_keyhash)
	vote_delegation_cert = (9, stake_credential, drep)

Otherwise we would have to keep old certificates for one more era to avoid breakage, just to replace certificates with equivalent ones

[yHSJ]

I decided to go with this in the CIP. I left them intentionally ambiguous so that others could weigh in on whether we want to simply rename existing certs or introduce new ones (for consistency or whatever)

[lehins]

I am weighing in. Renaming (changing the tag) will require old certificates to be retained for a whole new era. So, it makes no sense to introduce new identical replacement certificates. Please adjust the CIP to retaon the old tags.

Actual names of cddl bindings are irrelevant and can be discussed at a any point, since they do not require a HF.

[KtorZ]

This will also require a hard-fork, and the CIP can only be active once the hard-fork has been enacted.

[rphair]

Confirmed as candidate at CIP meeting today, with some background given about how the proposal originated at a working group with the initial reviewers in common. Therefore @lehins it would be great timing for you to also enter the discussion & review.

Please @yHSJ also rename the containing directory to CIP-0154 🎉 & update the proposal link in the top comment.

[WhatisRT]

Note that hardforking into this can't immediately remove the current certificates, they can only be deprecated since otherwise downstream tooling would immediately break. So it needs to be done in two steps, implementing the new CDDL & deprecating the old one, and then removing the old one later.

[yHSJ]

I asked a clarifying question about this in the Cardano scaling discord, but I'm not sure why this has become the process only for some changes.

[lehins]

This two certificates are from the Shelley era and were already planned for removal. They were kept around in Conway for ease of transition and preventing breakage of tooling while this transition is under way.

[lehins]

There is no need to break existing specification. All you trying to do is remove some certificates, while leaving others unchanged.

Suggested change

	stake_registration_cert = (N, stake_credential, coin)
	stake_deregistration_cert = (N+1, stake_credential, coin)
	stake_delegation_cert = (N+2, stake_credential, pool_keyhash)
	vote_delegation_cert = (N+3, stake_credential, drep)
	stake_registration_cert = (7, stake_credential, coin)
	stake_deregistration_cert = (8, stake_credential, coin)
	stake_delegation_cert = (2, stake_credential, pool_keyhash)
	vote_delegation_cert = (9, stake_credential, drep)

Otherwise we would have to keep old certificates for one more era to avoid breakage, just to replace certificates with equivalent ones

[lehins]

Here is my general view on this CIP: I am not really sure if it was worth writing the CIP, since this is fairly simple concern and a ticket on ledger repo would have probably suffice. That being said, there is nothing wrong with creating a CIP, since it will give more visibility to the proposed change.

In a nutshell, we already had plans on removing couple of old certificates, namely stake_regestration and stake_deregistration, since they were kept around temporarily for backwards compatibility with prior era and allowed users for easier transition to new ones that require a deposit. The only real new thing that that this CIP requests is to remove few redundant certificate types that allow register and delegate at the same time.

In other words, in the next era, we just want to remove all of these certificates: https://github.com/IntersectMBO/cardano-ledger/blob/49623962445143680dd725ebbf812c37e099b65c/eras/conway/impl/cddl-files/conway.cddl#L677-L687

Just to confirm, this is what we want plus some consistent naming for the next era from this CIP

certificate = [
-                stake_registration
-             // stake_deregistration
-             // stake_delegation
+                stake_delegation
              // pool_registration
              // pool_retirement
              // reg_cert
              // unreg_cert
              // vote_deleg_cert
              // stake_vote_deleg_cert
-             // stake_reg_deleg_cert
-             // vote_reg_deleg_cert
-             // stake_vote_reg_deleg_cert
              // auth_committee_hot_cert
              // resign_committee_cold_cert
              // reg_drep_cert
              // unreg_drep_cert
              // update_drep_cert]

If my understanding of this CIP is correct then you have my full support.

[rphair]

@yHSJ @lehins @WhatisRT I think the remaining Ledger confirmation was the main thing we were looking for so I'm marking this Last Check because I think @yHSJ all that remains are settling some cosmetic / clarity review points, given #1021 (review).

Therefore this should be ready with plenty of time to spare, since due to Builder Fest overlap our next meeting isn't for 3½ weeks: https://hackmd.io/@cip-editors/111

I'm ready to approve this in the meantime if @yHSJ you can update Path to Active at least according to these 2 suggestions (or equivalent):

#1021 (comment) (time separation between relevance for Haskell vs. future nodes)

#1021 (comment) (clarity about whether / how a hard fork is required, even if "doing it anyway")

[yHSJ]

Here is my general view on this CIP: I am not really sure if it was worth writing the CIP, since this is fairly simple concern and a ticket on ledger repo would have probably suffice. That being said, there is nothing wrong with creating a CIP, since it will give more visibility to the proposed change.

Thanks for taking the time to review it! I agree, it's a rather simple change. That being said, I think it is important that, as an ecosystem, we move towards ledger changes being clearly documented in a CIP (or CIP like process) to help facilitate changes across all the different nodes. It's a big shift, but I truly believe it's important that the ledger is no longer owned by a single entity, but a shared resource. Also, this should be the first CIP in a family of "ledger simplification CIPs" that come about as a result of the node diversity workshop.

In a nutshell, we already had plans on removing couple of old certificates, namely stake_regestration and stake_deregistration, since they were kept around temporarily for backwards compatibility with prior era and allowed users for easier transition to new ones that require a deposit. The only real new thing that that this CIP requests is to remove few redundant certificate types that allow register and delegate at the same time.

Yes, generally it's just removing redundant certificates to simplify the ledger (along with consistent naming).

Just to confirm, this is what we want plus some consistent naming for the next era from this CIP

It looks like you're missing a few of the "composite" certificates in that diff. For clarity sake, I am suggesting:

removing:

stake_registration, (already happening)
stake_deregistration, (already happening)
stake_vote_deleg_cert,
stake_reg_deleg_cert,
vote_reg_deleg_cert,
stake_vote_reg_deleg_cert,

introducing (or renaming, the arrows here represent equivalency):

reg_cert -> stake_registration_cert
unreg_cert -> stake_deregistration_cert
stake_delegation -> stake_delegation_cert
vote_deleg_cert -> vote_delegation_cert

There is no need to break existing specification. All you trying to do is remove some certificates, while leaving others unchanged. Otherwise we would have to keep old certificates for one more era to avoid breakage, just to replace certificates with equivalent ones

Having the indexes of each of these "account management" certificates be sequential just feels like a simpler API. Ultimately, I am of the opinion it is better to have a more "painful" change in order to make the ledger as simple as possible for the future.

[rphair]

approved as per #1021 (review) 🚀

[lehins]

I just realized that we might never be able to remove those certificates, since some PlutusV3 scripts could depend on them. This means that if we completely remove these certificates, outputs that are locked by scripts that depend on these certificates being available:

stake_vote_deleg_cert,
stake_reg_deleg_cert,
vote_reg_deleg_cert,
stake_vote_reg_deleg_cert,

will become unspendable.

I am afraid that we might have to keep them around forever unless we have full support of all DApp writers out there that it is safe to remove these certificates.

The only safe thing that I can think of is to disable such certificates, unless a transaction uses PlutusV3 scripts. Which I am not sure is that much better, since tooling would still have to support all those certificates 😢

[rphair]

@yHSJ the CIP meeting today recognised the rounds of approval but also confirmed that the last #1021 (comment) suggests an unaddressed backward compatibility problem (please @lehins correct us if wrong about that, because otherwise we were ready to sign off on this).

I proposed that we might merge this if some mass deprecation warning were given to withdraw use of the affected certificates in advance of making this change... to be included very clearly in the Path to Active about how the developer community would be involved. I pointed out this could well leave it in Proposed state forever: but if so then this wouldn't be the first merged CIP for which this has happened.

Therefore we're updating the tags accordingly and editors will watch out for a solution that addresses both the Ledger feedback and our usual requirements for versioning and community acceptance.

[lehins]

please @lehins correct us if wrong about that, because otherwise we were ready to sign off on this).

Yes, I do confirm that if we remove these four certificates:

stake_vote_deleg_cert,
stake_reg_deleg_cert,
vote_reg_deleg_cert,
stake_vote_reg_deleg_cert,

there is a danger of locking funds in an unrecoverable manner, similar to what has happened in this issue: IntersectMBO/cardano-ledger#5009 and was also discussed in #1028

We still can and will remove these two certificates:

stake_registration,
stake_deregistration,

since backwards compatibility is achieved through translation of newer certificates that have the deposit to plutus context. Same trick unfortunately cannot be applied to the aforementioned four certificates, since their equivalent representation requires multiple simpler certificates.

Naturally, we can and should also rename certificates in CDDL in more consistent manner.

if some mass deprecation warning were given to withdraw use of the affected certificates in advance of making this change...

There is certainly this option of communicating and warning the community about this. Question is whether this is worth the hassle. Naturally, this is not my call. My job is only to warn about the dangers and y'all deal with the community 😁

[WhatisRT]

I thought I had commented this earlier, but apparently I didn't. This backwards compatibility issue makes me think that the original suggestion from the node diversity workshop is better in this context because it doesn't suffer from that, being purely a CDDL change. I referenced it in a previous post already: #1021 (comment)

To give a bit more detail, the original proposal there was to make the CDDL mirror the structure we have in the Conway spec for certificates, see e.g. https://github.com/IntersectMBO/formal-ledger-specifications/blob/conway-v1.0/src/Ledger/Certs.lagda#L76 This also avoids the issue of non-linear growth when we add features and has some other upsides that the proposal here as as well. It might be a less intuitive interface for people outside the functional programming space, but that seems like an ok price to pay for backwards compatibility.

pending resolution of backward compatibility issue

[Crypto2099]

Given that it's been more than two months without any movement against this CIP... can we get a status check from @yHSJ @WhatisRT and/or @lehins in regards to whether or not this CIP should be merged but marked invalid, changed to only reflect the renaming scheme, or if it still has a path to active?

cc: @rphair @Ryun1

[rphair]

@Ryun1 @Crypto2099 - @WhatisRT @lehins - just to make sure this proposal gets merged one way or another — according to the Ledger opinion about validity — since there is only that 1 issue remaining I've tagged this Last Check so we can keep reviewing that opinion biweekly, in case we don't get a ruling on that before the next meeting... with a note to change to Status: Invalid if necessary before merge: https://hackmd.io/@cip-editors/116

[yHSJ]

I would argue there is still a path to active. I think this is still something worthwhile to invest some time into. While this particular change may be minor, I think it's part of a focus on simplifying the ledger that is important while we work on alternative node implementations (as brought up by @KtorZ in the Paris workshop).

As far as addressing the breaking of plutus scripts, I think there are a number of solutions. I know @KtorZ mentioned he had a solution to me in a private message, but never explained his solution. The naive approach would be to just translate the individual certificates into the old "complex" certificates when constructing a PlutusV3 script context, and then provide both the original certificates and the "translated" certificate(s). That would still potentially break scripts that rely on the presence of some combination of all of those certificates, but I think the likelihood such a script exists is rather low. Ultimately, it's a question for the community.

I will find some time early this week to write a query to find how many scripts have been executed on mainnet for the "complex" certificates. That will overestimate (as those scripts still may not rely on the complex transactions), but at least we'll have some rough numbers to consider.

[lehins]

The naive approach would be to just translate the individual certificates into the old "complex" certificates when constructing a PlutusV3 script context ...

That would be a pretty dangerous route.

Imagine a script that locks a staking credential and relies on presence of this multi-function certificate that can register and delegate at once. If you artificially combine a sequence of two certificates: [cert_0, cert_1_register_A, cert_2_delegate_A, cert_3] into [cert_0, register_and_delegate_A, cert_3], you are now having serious issues:

1. Supplying a redeemer for all three cert_1_register_A, cert_2_delegate_A and cert_3 is no longer correct, since index in redeemer pointer is off by one
2. Script is executed twice instead of once, unless we hack around it somehow
3. Script will not see what was actually supplied
4. We would inadvertently be preventing a potentially expected behavior, where such order of certificates: [cert_0, cert_1_register_A, cert_2_delegate_A, cert_3] was desired by the user, but ledger all of a sudden changed it from underneath them.

Most importantly it would have the opposite result: we would make the ledger implementation more complex with hacks like this, not simpler.

then provide both the original certificates and the "translated" certificate(s).

You can't do that, since that implies change to PlutusV3 script context, which is not allowed.

I will find some time early this week to write a query to find how many scripts have been executed on mainnet for the "complex" certificates.

The fact that you will be able to find all scripts that rely on such certificate on mainnet today, does not rule out all possible scripts like that from ever existing, because they might not have been used on chain yet. In other words someone could have registered a staking credential without providing the preimage of the hash, because today registration certificate does not require a witness. Also someone could have locked an input with a script that relies on a presence of such certificate, which you will not know until such input is spent and it might not happen for many years to come. So, this information cannot possibly serve as proof that your suggestion is sound.

I am now of a much stronger opinion that the change that this CIP proposes is dangerous.

[yHSJ]

Most importantly it would have the opposite result: we would make the ledger implementation more complex with hacks like this, not simpler.

Yes, this is a good point. That was just a stream of consciousness, trying to think of an example solution. You're absolutely right, that is a bad solution. I am curious to hear what @KtorZ's solution was.

I am now of a much stronger opinion that the change that this CIP proposes is dangerous.

I think that is an unfair conclusion. Yes, the solution I just proposed was not a sound one, but that does not mean that a change that simplifies the certificates in general is dangerous.

[WhatisRT]

I am curious to hear what @KtorZ's solution was.

The original proposal was purely a CDDL change with no change in the ledger logic. Instead of having stake_vote_deleg_cert, stake_reg_deleg_cert, vote_reg_deleg_cert etc. there'd just be one certificate with optional fields. It would follow the structure of the specification just in CDDL form. This avoids the issue of combinatorial explosion (and in my opinion also improves on the other items in the motivation, but people are free to disagree).

[rphair]

@yHSJ the CIP editors resolved around a meeting a few weeks ago — when this was still up for Last Check but recently having the above irreconcilability pointed out — to give you and @lehins @WhatisRT some time to decide between yourselves how to go ahead with this proposal.

Our "backup plan" if this didn't happen — to document the premise of this CIP, while indicating that it can't (currently) be done & indexing this discussion to indicate why and so avoid duplication of effort in other proposals — has been to merge this as Inactive: (reason) with a concise, mutually acceptable reason why it can't (currently) be done.

Please indicate whether you agree that we have gotten to this point. I think it would be a great loss to simply close this PR: otherwise please all reviewers so far post your favourite short phrase for the "reason" this should be Inactive and editors will update it as such before merge, as planned for Last Check at the next meeting: https://hackmd.io/@cip-editors/118

[lehins]

The original proposal was purely a CDDL change with no change in the ledger logic. Instead of having stake_vote_deleg_cert, stake_reg_deleg_cert, vote_reg_deleg_cert etc. there'd just be one certificate with optional fields.

This would just introduce breakage for no good reason. Which means it would not be a simplification, but rather introduction of more work for everyone involved.

It would follow the structure of the specification just in CDDL form

I get a 404. In any case, I can imagine what is in the link and again changing CDDL in a way that doesn't make it simpler and increases the size is counterproductive IMHO.

Our "backup plan" if this didn't happen — to document the premise of this CIP, while indicating that it can't (currently) be done

@rphair Some parts of this CIP can be done, in particular removal of registration and unregistration certificates that do not have a deposit in them are already in the process of being removed for Dijkstra era: IntersectMBO/cardano-ledger#5137

[yHSJ]

Please indicate whether you agree that we have gotten to this point. I think it would be a great loss to simply close this PR: otherwise please all reviewers so far post your favourite short phrase for the "reason" this should be Inactive and editors will update it as such before merge, as planned for Last Check at the next meeting: https://hackmd.io/@cip-editors/118

I think in general the idea is one that is still worth exploring, but my proposed solution clearly isn't quite the right one. So whether that means we mark this as inactive or not is more of a organizational question.

[rphair]

OK then @yHSJ if you wish to pursue this it sounds like we can merge a properly Proposed CIP (scratching the Inactive classification) if your proposal can be refactored according to what @lehins says in #1021 (comment):

Some parts of this CIP can be done, in particular removal of registration and unregistration certificates that do not have a deposit in them are already in the process of being removed for Dijkstra era: IntersectMBO/cardano-ledger#5137

I'll mark this Waiting for Author so this can persist with that footnote until such a reconciliation is made. And if you have other ideas that would be helped with active review please post and/or recommend a CIP meeting discussion and we'll schedule it.