New Type? CRC: community standards & best practices

[rphair]

Continuing discussion from #1031 (comment) regarding this proposed model to separate standards & practices from the CIP stream, as per this tentative outline:

• CPS - generic problem statements that might have a variety of possible solutions
• CIP - specific changes to the protocol that all nodes would need to agree on and adopt (if approved)
• CRC - community standards, best practices, etc.

My response, in context:

---

It wouldn't "overhaul" the existing CIP process to add a CRC category as you describe: which I think would be an excellent idea.

• Under this model, some older CIP & CPS topics (documentation, design models & best practices) would likely be superseded by newer CRCs and this would be addressed by our usual pattern of deprecation: so existing content wouldn't need to be separated or reclassified as part of the effort.

The simplest way to get started might be 1. someone with the right clearance level on the cardano-foundation account creates another repository (e.g. CRCs, alongside CIPs) and assign some people with editorial privileges to it; although:

• Currently the CIP editors only have limited access even to the CIPs repository, and no current editor has even witnessed the actual process for elevating another GitHub user's privileges to Collaborator: which allows us to approve pull requests by consensus, perform merges, and update the Wiki... but not really anything else.

Or 2. we could operate CRCs through the CIPs repository — with the same roster of current editors (who would quickly need to recruit more editors to handle a greater volume & wider variety of material) — but there also might be an advantage to following a different life cycle for these documents, as we've tentatively agreed to do here for "Cardano Governance Propositions":

• New Category: Governance #937 (comment)

... with a different repository with a governance-focussed set of editors.

If comparisons are being drawn with Ethereum it would help to know whether the EIP and ERC editorial groups are the same and how the issue of scaling was addressed when ERCs really began to take off. The editor's group currently has no budget except what can be arranged for individuals by Catalyst funding or donated employee & professional time.

I don't see it as a requirement that CRCs be hosted on the Cardano Foundation repo (vs. a possible option 3. to start completely from scratch somewhere else) but I do think it would provide some cohesion, legitimacy, and community readiness for participation to keep any new repository here.

---

From my own reading of community feedback, these 3 goals are driving the evolution of a CRC process:

1. feedback from the "node diversity" working group (cc @Quantumplation @yHSJ @ch1bo @abailly): https://forum.cardano.org/t/managing-a-shared-ledger-new-cip-like-process/145575
2. feedback on continued Ledger evolution (cc @waalge @WhatisRT @lehins): Ledger rule changes: documentation & consistency? #1028
3. ongoing experience from CIP editors having trouble classifying & admitting "community standards" and "best practices" documents (cc @Ryun1 @Crypto2099).

I would happily make this topic the central issue of an upcoming CIP meeting if group discussion would be beneficial. In the meantime let's get some points of view accumulated here. @KtorZ if you have any idea how we can answer questions of repository architecture I hope you can also advise us in this thread.

[yHSJ]

I love the Ethereum model from the brief introduction we got in Paris from Ori Pomerantz (thanks to @ch1bo). I don't know enough about the history around it to answer your questions, but I will do some digging to see what I can find.

I think while we are doing this, it's worth revisiting the CIP process as a whole. I think it makes the most sense to have CRC editors and CIP editors, where CIP editors would be more knowledgable about the core technical components of the node and the CRC editors would be more knowledgable about the usage of the protocol (standards, best practices, etc.)

I would also suggest that the CIP process, specifically around ledger upgrades, could be redefined to handle the general categories that @WhatisRT proposed in the forum discussion differently to how they are currently handled. It really does seem like it makes the most sense to go through the process of this change at the same time if we're going to be creating a new CRC category.

@Crypto2099 has proposed organizing a working group to discuss the ideas around a new, ledger specific, CIP-like process. I still think that getting on the same page on a call is beneficial for something like this.

In short, I think this is a great proposition (effectively what I've been campaigning for since Paris), but I think it should involve more complexity than simply recategorizing and moving some stuff around.

[KtorZ]

1 - CIP vs CRC

Regarding "CIP - specific changes to the protocol that all nodes would need to agree on and adopt (if approved)"

I am afraid that this is simply impossible because the CIP process isn't authoritative, but in a way is only an opt-in process. No one can force a node implementer to follow a particular CIP, unless that particular CIP is part of the protocol. We historically tried to have CIP be authoritative; and it didn't work because it's the wrong vehicle for enforcing decisions.

So, in effect, CIPs are much closer to "community standards, best practices, etc." at this point; though some also contain specific solutions that have become or can become protocol features (think about CIP-0031, CIP-0032, CIP-0033 or CIP-0138 for example).

I strongly disagree with the idea that CIPs shouldn't contain implementation details. They SPECIFICALLY should. That's the intended purpose of a CIP; to be detailed enough that it can be implemented. A specification may leave room for implementation choices, but it may certainly specify constraints, expected behavior and very low-level details such as binary formats.

2 - CIP Editors

Regarding having "CIP editors [who] would be more knowledgable about the core technical components of the node"; I think it's a misunderstanding of the role of CIP editors here. Editors aren't (necessarily, although they can be) technical experts in the room. They are the guardian of the CIP Process. The role of an editor is to ensure that the process is diligently followed; and they help coordinate and facilitate reviews around CIPs.

The reviewers are the experts. And so far, it's always been a permissionless process. Wanna be a reviewer? Take a shovel and go provide feedback!

3 - CIP Improvement Proposal (CIPIP :D)

I only have one suggestion regarding improving the CIP process, which is to start thinking about having more diverse category champions for specific categories: ledger, plutus, consensus & network. By "diverse", I mean having people from different node workstreams. Although, it's important to keep in mind that:

1. We cannot force people to be champions if they don't want to;
2. I do feel that the current Plutus or Ledger champions are quite receptive to feedback and are very proactive in seeking expert opinions outside of their own teams when needed -- and I see a large overlap between CIP reviewers (occasional or recurring ones) and node implementers anyway.

So, it's also not a problem per se. I think the CIP process is fine and work as intended for that purpose. What could however need improvement and/or formalisation is the layer coming after the CIP process: how do we collectively decide and agree on the technical roadmap of Cardano and what it means to be "a cardano node". That privilege has so far been the one of IOG, which seems to be willing to share it with a broader community (judging by recent social media posts and initiatives such as the node diversity workshop and the blueprint project).

My "dream" would be that moving forward:

• ANY protocol (which includes the ledger rules, consensus algorithm and any observable changes in the networking interfaces) is first specified and discussed as a CIP.
• There exists another process for "bundling" CIPs together into milestones for Cardano. That process should ensure proper scoping, non-functional requirements such as performance targets, budget and approval of node implementers -- and ultimately, of DReps through the means of an Info Action (basically preceding and announcing a future hard fork).
• Once finalized and fully implemented, ensure that any change to the protocol is reflected in the Cardano blueprint project (not to be mixed up with CIP-0057!).

This way, the CIP can remain a place for technical solutions that have received some level of feedback and can be the go-to place for node implementers for (a) discussing/proposing technical changes and (b) seeking for guidelines/best practices.

The bargaining on the roadmap and authoritative aspects of which CIPs shall make it into the roadmap is best done separately from CIPs, as another layer with different processes and people.

[Quantumplation]

I am afraid that this is simply impossible because the CIP process isn't authoritative, but in a way is only an opt-in process.

In this case "specific changes to the protocol that all nodes would need to agree on and adopt (if approved)" is simply shorthand for "suggestions about specific changes to the protocol that all nodes would need to agree on and adopt for them to be effective, which can then be fed into a more authoritative process like on-chain governance". I'm trying to draw the distinction between CIPs that are only practical / worthwhile if they do reach a broad and authoritative consensus, and those that are useful regardless. For an example of this distinction, think reference scripts vs governance metadata. One is useless unless a plurality of nodes implement and hard fork to deploy it ("hard consensus"), the other just announces something that one or more people intend to do, and would be convenient if more people did consistnetly ("soft consensus").

I'm certainly not trying to make the CIP process authoritative for exactly the same reasons you outline.

I strongly disagree with the idea that CIPs shouldn't contain implementation details.

Everything you outline in the rest of this paragraph is things that I don't think of as "implementation details". 😅 Certainly taking a literal definition, things like CBOR formats are details of an implementation. But usually we use the term "implementation details" to refer to the things that are outside of the concern of the interface. Something is "just an implementation detail" because it's internal to the function, and not something the caller needs to be concerned about.

So, yes, I'm arguing that CIPs should contain the interface boundary: CDDL specs for binary formats, expected behavior, etc; but the details of how to implement that behavior (what you call "implementation choices") are more suggestions / reference implementations / etc. that don't need the kind of "hard consensus" I describe above that an on-the-wire binary format would need.

There exists another process for "bundling" CIPs together into milestones for Cardano. That process should ensure proper scoping, non-functional requirements such as performance targets, budget and approval of node implementers -- and ultimately, of DReps through the means of an Info Action (basically preceding and announcing a future hard fork).

This is a similar process to the one that Ori outlined at the node diversity workshop that Ethereum uses. And that's why I think dividing CIPs and CRCs would be beneficial: the "set of things" that that new authoritative process needs to haggle over, vs the things where the "authoritative process" is more about ecosystem adoption and organic competition.

[Quantumplation]

I will say, as the potential author of many CIPs over the last 4 years, the lack of this distinction has been the major psychological deterrent for me. IMO they each require different levels of scrutiny and exhaustive discussion. When I've thought about writing down small suggested improvements to try to gain social momentum behind, the thought of the level of effort and debate that would go into it has prevented me from participating.

Now, granted, part of that is likely just a few bad experiences I had very early on, and the CIP process has likely improved a lot since those days, but still, there's few things I dread more than getting stuck in design-by-committee debate hell with the same level of scrutiny and passion as a change to the core ledger, over something that I'm going to go and do on my own anyway and was just trying to document in case others wanted to use. 😅

[rphair]

added this issue to Tuesday's CIP meeting agenda (under Issues > Triage): https://hackmd.io/@cip-editors/112

[Crypto2099]

Just because I distinctly remember already having had this discussion in the past, I'll bring back this "oldie but a goodie" closed PR from the past that attempted to draw this ERC/EIP : CRC/CIP distinction once before. Whether through naming or categorization or whatever other factors, I'm sure we can find an acceptable solution to the overall problem that is enabling node implementors to filter out the noise and narrow down their area of focus.

I do agree with @KtorZ suggestion that expanding our list of champions beyond the existing IOG/Haskell implementor heavy current group is important and one that the current Editors body have discussed at length w.r.t. giving CIPs the "Active" status based on actual real-world implementation in a multi-node/node-diversity environment.

Definitely happy to spin this up into a dedicated CIP working group given this renewed interest in creating better definitions and processes.

#493

[yHSJ]

I am afraid that this is simply impossible because the CIP process isn't authoritative, but in a way is only an opt-in process. No one can force a node implementer to follow a particular CIP, unless that particular CIP is part of the protocol. We historically tried to have CIP be authoritative; and it didn't work because it's the wrong vehicle for enforcing decisions.

This is part of why my initial idea involved an entirely new process, so we don't bring along any "CIP baggage" that may exist. That being said, I think that of course any off chain consensus solution is not authoritative, because we cannot control what anyone does in the network. However, I do think they can become "de facto" authoritative. What I mean by that is if enough of the node maintainers participate in the new consensus solution, it becomes the solution for Cardano. Of course I expect disagreements and people to break off–just look at Intersect–but, generally, my vision was having each hard fork change log simply be a list of "CIP-like" documents describing the ledger changes (or consensus, or networking). None of it is forceful, Cardano is what is actually running on the network with more than 51% stake. But, in practice, I believe the node implementors can come together around this because it makes everyone's lives easier.

So, in effect, CIPs are much closer to "community standards, best practices, etc." at this point; though some also contain specific solutions that have become or can become protocol features (think about CIP-0031, CIP-0032, CIP-0033 or CIP-0138 for example).
I think this is a part of the "CIP baggage" I mentioned. Step away from the existing CIPs and consider what I'm proposing in terms of "specifications that define and explain changes to the protocol."

I strongly disagree with the idea that CIPs shouldn't contain implementation details. They SPECIFICALLY should. That's the intended purpose of a CIP; to be detailed enough that it can be implemented. A specification may leave room for implementation choices, but it may certainly specify constraints, expected behavior and very low-level details such as binary formats.
Pi said my piece, but I'll echo that "implementation details" is another overloaded term. We should define an interface and expected behavior, but you should not tell me how my software reaches that point. For example, Amaru is handling validation very differently than the Haskell node, but we're (hopefully?) coming to the same conclusion.

Regarding having "CIP editors [who] would be more knowledgable about the core technical components of the node"; I think it's a misunderstanding of the role of CIP editors here. Editors aren't (necessarily, although they can be) technical experts in the room. They are the guardian of the CIP Process. The role of an editor is to ensure that the process is diligently followed; and they help coordinate and facilitate reviews around CIPs.

The reviewers are the experts. And so far, it's always been a permissionless process. Wanna be a reviewer? Take a shovel and go provide feedback!
I think you're stuck in the existing framework of a CIP. I would agree that the CIP editors are simply guardians of the process, not the dictators of it. But there are two points:

1. There are fewer external reviewers in practice. From what I've seen, often the editors are the reviewers.
2. Having buy-in from node implementors would make reaching consensus around the protocol much easier. Obviously, it can't be required, but if a node wanted to have a say in the future of the protocol, they better get involved.

Ultimately, none of this is possible without the buy-in of the Haskell team at the moment. They are dictators of the network (I don't mean that in a bad way, but in the sense that whatever software they push, we have to follow) at the moment. They could totally ignore this process, until someone comes along and replaces that software in the network. Once we reach sufficient node decentralization, participation would be "required", otherwise you'd just fork off into the abyss (or into something else?).

That is exactly the reason I think a new process for coming to consensus on managing the protocol would really work. Unlike current CIPs, which are largely usage standards such as CIP-30, either you implement Cardano, or you implement something Cardano-like. And once there is a diverse node ecosystem, no one party could force the network in any direction.

My "dream" would be that moving forward:

• ANY protocol (which includes the ledger rules, consensus algorithm and any observable changes in the networking interfaces) is first specified and discussed as a CIP.
• There exists another process for "bundling" CIPs together into milestones for Cardano. That process should ensure proper scoping, non-functional requirements such as performance targets, budget and approval of node implementers -- and ultimately, of DReps through the means of an Info Action (basically preceding and announcing a future hard fork).
• Once finalized and fully implemented, ensure that any change to the protocol is reflected in the Cardano blueprint project (not to be mixed up with CIP-0057!).

This way, the CIP can remain a place for technical solutions that have received some level of feedback and can be the go-to place for node implementers for (a) discussing/proposing technical changes and (b) seeking for guidelines/best practices.

The bargaining on the roadmap and authoritative aspects of which CIPs shall make it into the roadmap is best done separately from CIPs, as another layer with different processes and people.

It sounds like we agree. I am simply proposing that we define a framework around this process that solidifies it. If it doesn't work out, it doesn't work out and we figure something else out. I just think you have to step outside the "what is the CIP process" box and think about how we could start from scratch. Once we know that, it's much easier to figure out how to modify the existing process to fit our needs.

[yHSJ]

And let me just add: I understand the framing of "stop thinking about CIPs" in the CIPs repository may be a bit strange and perhaps even hostile. That is certainly not the goal. I just think we have a unique opportunity in front of us in which we are about to experience a seismic shift in the network with node diversity and we have an opportunity to drop our "process debt" and start with a clean slate.

I love the CIP process. I think it is one of the most important pieces of Cardano. And, I believe we can do better for protocol upgrades in particular.

[rphair]

removing Triage tag since this is now explicitly on tomorrow's CIP meeting agenda as part of the more general Review topic: https://hackmd.io/@cip-editors/113

[Ryun1]

my two lovelace

I feel that the CIP process is a good place to improve the collaboration between Cardano node teams.

The IO haskell teams have been increasingly engaged in the CIP process, with core teams documenting major changes as well as dedicating time to reviewing community proposals.
From my perspective this has been great for all.

I feel that it would benefit all for this to continue and expand, to include engagement all node teams.
Without strong collaboration mechanisms we risk losing the benefits of a multi-node ecosystem.
This can only work if all teams are actively dedicating time to collaboration, with some of that through the CIP process.

and maybe the CIP process isn't the best place for this majority of the collaboration, but thats okay we will work it out as we go.

What can we do in the CIP process to improve things?

I feel we should re-define the core categories (those will require close collaboration between node teams)
so that these categories clearly define what sort of changes must be documented and which do not need it
this places guardrails on changes to core areas.
This will require all teams to work together on adding necessary guardrails within Plutus (CIP-35), Ledger (CIP-84), Consensus (CIPending), Networking (CIPending).

for example; all changes to ledger's serialisation, historically have not been documented via CIPs, but as it affects how nodes communicate, it should probably be documented moving forward.

Additionally, we should add tighter criteria on how CIPs in these cateogires become status: active.
i.e. all teams should probably sign off on an active status.

I would stress that we all will need to be stricter about the enforcement of agreed category guardrails.

Why like this?

One step at a time.
I like that the CIP process is slow.
I would avoid making big changes or adding a new type of CIP.
I feel its better to improve one small step at a time.

If we agree on the first step, we can then think about the next step.
One reasonable suggestion is creating different lanes or levels of core CIP,
where changes are differentiated and held to different standards based on their scale.

How can we make sure this will work?

We need to ensure that these core teams, have bought into this process.
they all MUST contribute, and agree on all important changes or this process does not work.
This will involve changes in working procedures for the IO Haskell teams.