CIP-35? | Plutus Core Evolution

[michaelpj]

This CIP proposes a process for making CIP proposals to change Plutus
Core or its interface to the ledger.

[kozross]

In general, I think it's a good idea to have a more specified and clear structure around modifying Plutus and the libraries it depends on. However, I am concerned at the degree of bureaucracy this adds, and what we actually gain by it. Consider, for example, this issue here. Based on the current write-up, I see the process looking like this:

1. CIP for this gets sent. We await its approval, however long that takes, deal with whatever discussions and concerns arise, etc. This is complicated by the fact that we have to modify cardano-base as well, which by my reading, requires a separate CIP.
2. Once accepted, the process for getting to Draft must be completed. Some as-yet-unclear party decides when this goal is met, which may require more discussion, dealing with more concerns, etc.
3. Once gotten to Draft, the process for Proposed must be completed. Assuming costing can be done at all (see my note), it's yet another round of the same.
4. Once gotten to Proposed, the process for getting to Active must be completed. You get the idea by now.

This would take something that is already a lengthy and complex process, make it lengthier and more complex, while arguably as-written still failing to solve key issues (for example, see my statement regarding testing). Additionally, a document such as this should document proper practices and give specifics about what needs to be done (again, see my comment regarding testing): at the moment, it's not even clear who gets to decide when we can move, for example, to Draft. Additionally, if my reading is correct, for something like the linked task, this process might have to be completed twice.

In short, much more clarity is needed, and the amount of steps specified here need to be considered for usefulness: personally, they seem excessive, and fairly unclear, at this stage.

[michaelpj]

However, I am concerned at the degree of bureaucracy this adds, and what we actually gain by it.

Partially, the bureaucracy is the point. I believe that the bar for changing the blockchain should be higher. We should be sure that many people in the community want the change, and that the change is well-specified.

Moreover, the idea is for the development of Cardano to be increasingly driven by people other than IOG, and that includes the design work. It's an easier process for the community to say "we want X" and get IOG to do the design work, but we want the community to do the design work!

Consider, for example, IntersectMBO/plutus#4233.

That's a great example. Let me sketch out what I think the process for that would have been:

1. You open a Draft CIP, which is more-or-less like the issue that you opened, but with more details.
2. There is discussion on the CIP. Hopefully, this will surface any difficulties due to the increased number of eyes, for example, it might have identified the fact that you wanted Schnorr signatures.
3. In parallel with that, you can start on the implementation work. The CIP doesn't say anything about when the implementation has to happen. If you can persuade the cardano-base maintainers to merge your PR with the implementation etc. then you can go ahead and do that.
4. The remaining details are hammered out in discussion on the CIP and potentially the prototype implementation. Somewhere around here the design is completed enough that the CIP becomes Proposed.
5. The implementation gets reviewed and accepted (or not! making a CIP doesn't guarantee that something will get accepted! it's just an open design doc), and the CIP gets changed to Active.

I think this would have been not that much more onerous than what actually happened. The main differences would be:

• More design work up front for the proposer. This is, as I said, deliberate, but is annoying for you.
• More eyes on the proposal by the community. This is important: part of the point is that we shouldn't just be changing the blockchain because one community member makes a plutus issue and I go "seems fine".

This is complicated by the fact that we have to modify cardano-base as well, which by my reading, requires a separate CIP.

Why do you think that? That wasn't the intention.

Some as-yet-unclear party decides when this goal is met

As I commented inline, it's the CIP editors, who are in general responsible for assessing the progression of CIPs.

Additionally, a document such as this should document proper practices and give specifics about what needs to be done

Unfortunately, this document can't be as precise as I would like, since implementation is out of scope for CIPs. A lot of requirements are buried in "it is the responsibilty of the implementor to get their change accepted", such as testing. I agree that that makes it less helpful than it could be. When I realised this I considered not even making a CIP and just adding this to the plutus CONTRIBUTING doc or something. But I think it's still valuable to use the CIP process for the design part of the process, even if it has to leave something out.

At least, I'll try and clarify the text to make the implementation requirements more obvious.

[L-as]

I think this is fine honestly.

[michaelpj]

Updated:

• I've attempted to clarify the scope of the CIP a bit more, and that it applies only to the listed types of change.
• I've made it clearer that implementation is out of scope and may introduce more work. I've also removed the requirement that the CIP include named implementors: now it just says that in order to reach Active, it must have been implemented. How that happens (who does it, how they manage it), doesn't need to be specified.

[rhyslbw]

CIP Identifier clash with #137

[michaelpj]

CIP Identifier clash with #137

My understanding is that the Editors are responsible for allocating a CIP number anyway: I've only picked one here because otherwise you can't put it in a logical subdirectory 🤷

We can change the number of whichever one doesn't get merged first ;)

[michaelpj]

Given the lack of further comments and the approvals from the editors, I've changed the status to Active to represent that fact that we will be using this process going forwards.

[KtorZ]

@michaelpj whatever you did, you might want to push it 😊 ?

[michaelpj]

Wrong remote 🤦 Done.