Skip to content

DONOTMERGE a place to discuss my draft enrollment CIP #1559

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

DONOTMERGE a place to discuss my draft enrollment CIP #1559

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2ddc629
DONOTMERGE WIP
nfrisby Jun 11, 2025
98da9e5
edits for Thomas's comments
nfrisby Jun 11, 2025
d49ab38
Arnaud clarified the Amaru office hours TODO
nfrisby Jun 11, 2025
79ae878
typo
nfrisby Jun 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions WIP-enrollment-CIP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
In my current estimation, compared to the Plutus- and Ledger-enrolling CIPs above, any CIP enrolling Consensus would be trivial.
Copy link
Contributor Author

@nfrisby nfrisby Jun 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@perturbing said #1559 (comment):

any CIP enrolling Consensus would be trivial.

Can you expand on this statement?

By "it would be trivial" I mean it would just be the quoted paragraphs below, which is the slightest fraction of the Plutus and Ledger enrollment CIPs.

We've simply had many less contributors and many fewer design iterations, each of which has been a massive investment.
Copy link
Contributor Author

@nfrisby nfrisby Jun 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@perturbing said #1559 (comment):

We've simply had many less contributors and many fewer design iterations, each of which has been a massive investment.

Note that in the future, there will be another node (Amaru), this project is making heavy investments in their knowledge of the consensus stack. So it is not far-fetched that other contributors to the consensus stack can be expected. A result of this will be suggestions on how to improve it as well.

It makes sense that thus far only plutus and ledger were involved in such an "enrollment" CIP process, as both have direct users. With a second node, there is a direct user of consensus that can produce improvements. So, in this case, is the above addition you made enough to guide a CIP for consensus?

Yes, it's my intention that "available experts on the existing implementation" included CF. I should reword it, eg to "experts on the existing implementationS".

I'm hoping @abailly et al hold similar Office Hours as we do, and so I could included that in the list of relevant meetings as well.

I am not an expert, but I can imagine that a proposal for consensus might require some checks or basic requirements to call it a proper improvement (which might require significant effort from the author). Similarly, in the plutus "enrollment" CIP, it tries to express what things should be checked and thought about when dealing with plutus improvements, this so that the experts can easily verify that the CIP really improves things and also gives a solid argument for it.

Given this, is such an CIP also not needed for consensus?

In my experience, the cognitive load of "all the things consensus needs to worry about" is just huge. An exhaustive list wouldn't help people---it'd be intimidating and people would bounce off it. My opinion is that inviting them to talk to us and trying to share a specific subset of our concerns (edit: relevant to their idea) with them to start with is much more likely to lead to useful consensus CIPs.

If people find that argument compelling, I could add a paragraph saying as much.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my experience, the cognitive load of "all the things consensus needs to worry about" is just huge. An exhaustive list wouldn't help people---it'd be intimidating and people would bounce off it. My opinion is that inviting them to talk to us and trying to share a specific subset of our concerns with them to start with is much more likely to lead to useful consensus CIPs.

I think this will be a wonderful addition that makes it explicit why no other checks are there.

Also tagging some of the other CIP editors for suggestions. @Ryun1 @rphair @Crypto2099

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not hold Office Hours yet, but are considering setting up a recurring meeting.

the cognitive load of "all the things consensus needs to worry about" is just huge

Is it true if you remove the "implementation details" of the existing consensus from the equation? In my modest experience with consensus, the level of complexity one has to deal with comes from a large part from having to deal with 6-7 years of accumulated and dense non-boring Haskell code. I am not discussing whether or not this is a good thing, just suggesting the conceptual aspects alone are probably much more manageable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed up a commit with the edits implied by our discussion in this thread 👍 Thanks!

Copy link
Contributor Author

@nfrisby nfrisby Jun 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the level of complexity one has to deal with comes from a large part from having to deal with 6-7 years of accumulated and dense non-boring Haskell code

The Hard Fork Combinator is one thing, but what I wrote above is not about the implementation. It's more about the ~10-15 people across multiple teams I ultimately have to talk when anyone wants to change any Consensus behavior: networking concerns, ledger concerns, incentive concerns, attack vectors the Researchers know about that I didn't yet, limits on the SPOs' patience for interface changes, dApps' patience, deployment burdens, etc, etc, etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What you describe does not seem very specific to Cardano, it's the standard situation for any significantly used piece of distributed system: there are a lot of stakeholders whose needs and requirements one needs to address, and yes, that's complex like any social system.
Perhaps the problem is that this load is concentrated on the shoulders of a handful of persons, or even one person, you? I have worked for company running software comprising millions of line of codes and responsible for trading billions of dollars every day and one thing I have learned there is that no-one can know everything and the knowledge has to spread and codified in the form of documents, processes, etc.

My relevant suggestions are essentially just a few sentences.

> The authors of any CIP that explicitly affects the Cardano consensus protocol will need to communicate early and often with some combination of the IOG Researchers and the available experts on the existing implementation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you considered adding the TSC too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I didn't want to dilute the list. I think of the Researchers and the engineers as the end points of the spectrum of experts regarding the existing protocol, and in my mind the TSC is somewhere in the middle of that spectrum.

... but maybe that's naive, in particular "experts on usability/incentives/etc" might also need to be there. EG "product"? Hmm 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are already discussions happening in the "Node diversity forum", see e.g https://forum.cardano.org/t/node-diversity-online-show-tell-session-2/146548/3 and we (my team) are working towards making available a language-agnostic testing environments (Antithesis and Tartarus) which could be leveraged to experiment and validate early proposals.

We should find a way to express a reasonably objective process to assess any submission under the Consensus CIP.

> We suggest beginning by scheduling a discussion on the agenda of a session of INTERSECT's Consensus Technical Working Group.
> The discussion there will likely involve scheduling additional discussions with the aforementioned Researchers and experts (eg the IOE Consensus Team holds weekly office hours for this sort of communication).
>
> As the Cardano consensus protocol undergoes additional evolutions over the coming years, hopefully this CIP can be expanded to include some lessons learned that will help CIP authors usefully describe consensus changes even before entering discussions with the contemporary experts.
Loading