DONOTMERGE a place to discuss my draft enrollment CIP #1559
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| In my current estimation, compared to the Plutus- and Ledger-enrolling CIPs above, any CIP enrolling Consensus would be trivial. | ||
| We've simply had many less contributors and many fewer design iterations, each of which has been a massive investment. | ||
|
There was a problem hiding this comment. @perturbing said #1559 (comment):
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.
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. There was a problem hiding this comment.
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 There was a problem hiding this comment. We do not hold Office Hours yet, but are considering setting up a recurring meeting.
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. There was a problem hiding this comment. I pushed up a commit with the edits implied by our discussion in this thread 👍 Thanks! There was a problem hiding this comment.
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. There was a problem hiding this comment. 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. |
||
| 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 various existing implementations. | ||
| > 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; Amaru does not hold Office Hours yet, but is planning to). | ||
|
There was a problem hiding this comment. This CIP could be the seed from which to grow a proper process that would outlive the people actually implementing consensus now, which requires defining rules and process to change the rules. There was a problem hiding this comment. To draw the analogy with research: you want to do some research, you publish a paper in some venue, the reviewers review your paper, possibly requesting changes and explanations, you update your paper, you get final approval or rejection. |
||
| > | ||
| > 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. | ||
| > | ||
| > In our experience, the cognitive load of all the requirements on the consensus protocol is enormous. | ||
| > Many newcomers would bounce off of that intimidating list and a even diligent newcomer with a relatively small change would probably find most of that list to be irrelevant. | ||
| > An "open door" policy among the Cardano consensus experts, on the other hand, seems much more plausible to increase the likelihood of promising consensus CIPs being developed. | ||
| > The experts welcome newcomers to sketch their idea and will happily offer the initial guidance of a specific subset of relevant concerns to consider. | ||
| > | ||
| > The only apparent risk to this plan is if there's an overwhelming influx of dead-end ideas. | ||
| > That doesn't seem likely at the moment, and we would adapt the scheme if it happens. | ||
|
Comment on lines
+16
to
+17
There was a problem hiding this comment. Over the years we've had some CIP submissions (and a CPS) intended to solve other perceived protocol or operations problems, but would in fact influence Consensus behaviour (e.g. adjusting parameters like block size / frequency or VRF function). These won't come from Consensus subject matter experts and generally the authors won't be aware they have stepped into the "enormous" list of things that real Consensus changes would consider: in fact they'll likely be submitted in a different category altogether. Therefore our editorial process (in this case, "screening" out inadmissible CIPs) would be helped if there were a section of the Then editors could provide that deep link in the review process as a means of either impartially dropping the proposal or, maybe in some rare cases, pointing them to further resources to help them develop it into a real Consensus proposal. |
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@perturbing said #1559 (comment):
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.