CIP-0161? | Ouroboros Phalanx - Breaking Grinding Incentives

[nhenin]

We propose a new Ouroboros extension titled Ouroboros Φalanx (pronounced Phalanx), which addresses two critical Cardano Problem Statements:

• CPS-0021: Ouroboros Randomness Manipulation
• CPS-0017: Settlement Speed

Ouroboros Φalanx enhances Ouroboros Praos by mitigating grinding attacks through a strategic increase in the computational cost of leader election manipulation. It extends the nonce generation process from 1 to 2 epochs, introducing a verifiable delay function (VDF) that remains efficient for honest participants, while making it significantly more expensive for adversaries to bias the outcome.

• Rendered CPS-0021: Ouroboros Randomness Manipulation
• Rendered CPD-0021: Ouroboros Randomness Generation Sub-Protocol - The coin-flipping Problem
• Rendered CIP-0161 Ouroboros Phalanx - Breaking Grinding Incentives

[rphair]

Thanks again @nhenin for another intriguing submission. There are a number of editorial issues in common with your earlier & related submission:

• #1009

so rather than a detailed elaboration of each point I'll just propose a discussion agenda of potential issues (with checklist, to update when they start to get resolved) & tag it for Triage at our next CIP meeting: https://hackmd.io/@cip-editors/117

As before & always, you will be welcome to attend to introduce the proposal: not for technical review, but certainly a good chance to discuss some preliminaries like writing style, title, target audience, scope & nomenclature.

---

• For CIP review & posting we will have to retitle this — for consistency with reader & developer expectations — to use the English spelling rather than the Greek / Cyrillic letter.

  • If the CIP title "Phalanx" appears differently in marketing materials then this stylisation can also be mentioned, if considered relevant by editors & reviewers (it might not be).

• Please consider the title change of the PR also for your document: or something else more concise and less figurative (e.g. CIP-0140 = Ouroboros Peras - Faster Settlement).

• README (in the main directory & every subdirectory) should be in all capitals.

• There is no Security CIP category, so this is just Consensus.

• It's OK to force push at first (i.e. while getting your branch in order) but please avoid it from then on, since during review it's important to individually discuss & attribute changes to the document; as requested here: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#1a-authors-open-a-pull-request

• Illustrations are generally prohibited in an Abstract: often in academics & publishing web sites it's copied into other documents so an image creates problems for text copying & interpretation.

  • The term Phalanx is considered general knowledge and doesn't have to be defined, let alone illustrated.

• As with CPS-0021 I would editorially recommend (and insist unless other editors object) that the academically themed and styled content be moved a separate README in a subdirectory: with simply enough practical detail left behind in the Specification so node implementors can understand what is involved in the implementation: without necessarily all the mathematical underpinnings.

  • Whatever remains should be formatted as Markdown headings without the number.number.number format used in academic papers. This is essential for:
    • consistency with other CIPs;
    • automatic provisioning of deep links into the document... which you have now, but should be indexed by text rather than number (since sending links online is easier overall than referring by section number);
    • not having to renumber the whole document every time a section is inserted or deleted (maybe not a problem for you at this stage... but generally would be for maintainers & editors in the long term)

• The Rationale also has numbered headings and these are problematic for the same reasons.

• The Rationale is unlikely to be understood, as currently written, by anyone but a handful of industry experts... it would be very generous of you, and helpful to the community, to provide colloquially understandable justifications here & leave the brilliant but esoteric detail to a full "Rationale" in the "breakout" document already recommended.

• Editors have since recommended — and, I thought, you & I tentatively agreed on — adding a statement in or near the Copyright section about how AI was used in the production of the document. From the formatting, emphasis & embellishments it seems as certain as for CPS-0021 that AI has also produced the final product here. As you yourself stressed the value of before, it is now your responsibility to prove to your target audience that your ideas are humanly creative and original and weren't simply written by a machine.

---

I have already mentioned in CIP meetings — with consensus from Cardano standards veterans —that I am opposed to dumping academic papers into CIPs for all these reasons mentioned and more. The beauty of the CIP platform is that it presents standards which different elements of a community can understand and adopt... and I am seeing none of that here yet.

Whatever "equity" is perceived for Cardano agencies developing these research topics, and having a "CIP" posted (perhaps to attract funding, or simply to designate a hardfork), to fairly build that equity they will also have to keep in mind the community & target audience in writing & submitting these documents: not just splicing academic papers into the CIP template.

@nhenin I'll keep an eye out for revisions in the week ahead before the next CIP meeting — happily allowing one or more "force pushes" for substantial rearrangements & rewrites —but will wait to respond until my comments above can be validated by editors at or before that meeting. I don't want these suggestions to be taken as personally as last time & so hope that pre-validating them with other editors & reviewers will help set a cooperative tone going forward & save time for everyone in the long run. 😎

[rphair]

@Ryun1 @Crypto2099 @perturbing one thing at least one editor should set aside time for (not during the meeting!) is to read this material side-by-side with CPS-0021 to see if there are redundancies to suggest trimming (though I think @nhenin will have already prepared for that) & generally to see how well the documents work together.

I would postpone this effort, though, until the "separate README" item on the checklist above has been fully considered & after any agreed-upon adjustments have been made.

[rrtoledo]

Thanks again @nhenin for another intriguing submission. There are a number of editorial issues in common with your earlier & related submission:

• CPS-0021? | Ouroboros Randomness Manipulation #1009

so rather than a detailed elaboration of each point I'll just propose a discussion agenda of potential issues (with checklist, to update when they start to get resolved) & tag it for Triage at our next CIP meeting: https://hackmd.io/@cip-editors/117

As before & always, you will be welcome to attend to introduce the proposal: not for technical review, but certainly a good chance to discuss some preliminaries like writing style, title, target audience, scope & nomenclature.

• For CIP review & posting we will have to retitle this — for consistency with reader & developer expectations — to use the English spelling rather than the Greek / Cyrillic letter.

  • If the CIP title "Phalanx" appears differently in marketing materials then this stylisation can also be mentioned, if considered relevant by editors & reviewers (it might not be).

• Please consider the title change of the PR also for your document: or something else more concise and less figurative (e.g. CIP-0140 = Ouroboros Peras - Faster Settlement).

• README (in the main directory & every subdirectory) should be in all capitals.

• There is no Security CIP category, so this is just Consensus.

• It's OK to force push at first (i.e. while getting your branch in order) but please avoid it from then on, since during review it's important to individually discuss & attribute changes to the document; as requested here: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#1a-authors-open-a-pull-request

• Illustrations are generally prohibited in an Abstract: often in academics & publishing web sites it's copied into other documents so an image creates problems for text copying & interpretation.

  • The term Phalanx is considered general knowledge and doesn't have to be defined, let alone illustrated.

• As with CPS-0021 I would editorially recommend (and insist unless other editors object) that the academically themed and styled content be moved a separate README in a subdirectory: with simply enough practical detail left behind in the Specification so node implementors can understand what is involved in the implementation: without necessarily all the mathematical underpinnings.

  • Whatever remains should be formatted as Markdown headings without the number.number.number format used in academic papers. This is essential for:

    • consistency with other CIPs;
    • automatic provisioning of deep links into the document... which you have now, but should be indexed by text rather than number (since sending links online is easier overall than referring by section number);
    • not having to renumber the whole document every time a section is inserted or deleted (maybe not a problem for you at this stage... but generally would be for maintainers & editors in the long term)

• The Rationale also has numbered headings and these are problematic for the same reasons.

• The Rationale is unlikely to be understood, as currently written, by anyone but a handful of industry experts... it would be very generous of you, and helpful to the community, to provide colloquially understandable justifications here & leave the brilliant but esoteric detail to a full "Rationale" in the "breakout" document already recommended.

• Editors have since recommended — and, I thought, you & I tentatively agreed on — adding a statement in or near the Copyright section about how AI was used in the production of the document. From the formatting, emphasis & embellishments it seems as certain as for CPS-0021 that AI has also produced the final product here. As you yourself stressed the value of before, it is now your responsibility to prove to your target audience that your ideas are humanly creative and original and weren't simply written by a machine.

I have already mentioned in CIP meetings — with consensus from Cardano standards veterans —that I am opposed to dumping academic papers into CIPs for all these reasons mentioned and more. The beauty of the CIP platform is that it presents standards which different elements of a community can understand and adopt... and I am seeing none of that here yet.

Whatever "equity" is perceived for Cardano agencies developing these research topics, and having a "CIP" posted (perhaps to attract funding, or simply to designate a hardfork), to fairly build that equity they will also have to keep in mind the community & target audience in writing & submitting these documents: not just splicing academic papers into the CIP template.

@nhenin I'll keep an eye out for revisions in the week ahead before the next CIP meeting — happily allowing one or more "force pushes" for substantial rearrangements & rewrites —but will wait to respond until my comments above can be validated by editors at or before that meeting. I don't want these suggestions to be taken as personally as last time & so hope that pre-validating them with other editors & reviewers will help set a cooperative tone going forward & save time for everyone in the long run. 😎

Hi @rphair, thanks a lot for the review!

@nhenin is on PTO for the next two weeks, so I will try to answer when I can general comments on the documents. I was in charge of the cryptography, so I shall answer these directly however.

First of all, I am sorry for the acamedic style and paper dumping. I definitely should have reworked my report for it to be more accessible before merging it with the CIP. I will follow your advice and move most of the content in a new subdirectory, with academic references, while leaving the core points in the main document.

I will also update the document with the minor changes that you mentioned regarding the picture in the abstract, the hard links, numbered headings. As for the CIP's title, I will update it to the style you mentioned and update the PR name in consequence (I prefer the term "mitigating" rather than "avoiding").

I will force push any change after I get to go ahead from yourself and other editors.

[rphair]

thanks very much @rrtoledo, that will definitely be of great help to editors & this CIP... while you're sifting through that content, could you please also check for continuity (and for any redundancy) between this & CPS-0021 as requested in #1065 (comment)?

I'm not expecting any problems, but it's something that we'd have to do before merging this: to ensure that both documents are maintainable (i.e. changes to duplicated material in only one document would not leave the other one incorrect).

p.s. You can go ahead and force push any changes you make in the meantime... just please let us know when such a rewrite is finished & then we'll to back to the cooperative changes in-branch as usual. 😎

[nhenin]

Hi @rphair, thanks for your feedback. The title you suggested, “Ouroboros Phalanx – Avoiding Grinding Attacks”, doesn’t quite convey what Phalanx ultimately represents. I’ve gone ahead and shortened the title and removed the Greek letter, as you suggested.

As @rrtoledo mentioned, I’m currently on vacation and will address your points more thoroughly once I’m back (after August 17). I don’t have strong objections to most of your comments, except the following section:

I have already mentioned in CIP meetings — with consensus from Cardano standards veterans —that I am opposed to dumping academic papers into CIPs for all these reasons mentioned and more. The beauty of the CIP platform is that it presents standards which different elements of a community can understand and adopt... and I am seeing none of that here yet.

Whatever "equity" is perceived for Cardano agencies developing these research topics, and having a "CIP" posted (perhaps to attract funding, or simply to designate a hardfork), to fairly build that equity they will also have to keep in mind the community & target audience in writing & submitting these documents: not just splicing academic papers into the CIP template.

I’ll bring this up directly during your CIP weekly (after August 17th), but in the meantime, I want to crystallize a few thoughts here on this PR:

First, this CIP is not an academic paper. It’s a piece of engineering . So I’m genuinely surprised by how you're characterizing it, and I find myself wondering why. It’s a complete specification of an extension to Ouroboros (the Consensus category), and it clearly justifies how it addresses two specific CPS:

• CPS-0017 / Settlement Speed
• CPS-0021 / Ouroboros Randomness Manipulation

It follows both the CIP template and the guidelines you've defined.

1. So my first question is: are you questioning the completeness of the proposal, are you challenging the usefulness of certain sections ? Are we saying there’s too much information for a change at the core of Cardano? The CIP template asks for a precise specification and a rationale that addresses the CPS, which is exactly what this document provides. If the issue is the document size, what’s “too big”? Splitting it into sub-Readmes, as you suggested, is a formatting comment. So: is your feedback mostly about formatting, or are there semantic concerns as well? That’s the first clarification I’d like to understand.
2. Regarding the "community & target audience" point — what do you see as the primary goal of a CIP? Is it to propose a technical solution to a problem, or to market that solution? I’m genuinely unsure based on your comment. This is, first and foremost, a technical document. The Abstract and Motivation sections provide the high-level framing, while the Specification includes visuals and diagrams specifically aimed at making the proposal more understandable which, frankly, isn’t something you’d typically find in an academic paper. This document is designed to provide all the necessary information (a Protocol Specification Document) for another team (for example, the Intersect Consensus Team) to implement the proposal. The intent is to avoid a scenario where such a team would begin integration work without first having a solid foundation on whether the proposal truly addresses the issues it claims to solve at a protocol level. It’s written for engineers and consensus product owners first, but in a generous and accessible way so that any curious member of the community can follow and deepen their understanding of the topic. Again, I have the impression it aligns with the CIP guidelines, so I’m a bit puzzled by your comments here as well.

[rphair]

@nhenin the point of these questions about target audience and "academic" vs. "community" appeal is mainly to answer this one question:

Does the document have any relevance to those besides the author(s) and team members who produced it?

You have given us some reasons why it might, as well as a suggestion that the way it's organised already is broken down by progressive levels of detail (though I personally don't see this yet). Of course that's also up to fellow editors who are likely to be asking the same questions originally posted above. Please don't "shoot the messenger" for my being the first one to bring these common review questions into the process.

For the sake of those interested engineers, scientists, developers, and community members who try to stay ahead of the 110+ CIPs and 15+ CPSs we have now (and growing) we try to make sure exhaustive detail is going to serve some practical purpose. Editorially it always helps for the deeper detail to be in sub-documents rather than in the main document, and it was very encouraging when @rrtoledo offered to help with that.

There is no "too much" information to be in a CIP: but its presentation is a courtesy to the reader and hence our (my) suggestion to sift it between general & specific into 2 separate documents. I would happily wait for the results of the redraft suggested in #1065 (comment) because I think that same effort you performed for CPS-0021 produced something much more reader-friendly and accessible. 🙏

As with the related CPS, @nhenin if you pressed for merging this document as-is, you would likely get it. As you say we do need to record these achievements of engineering and right now the CIP repository suits your subject matter & application best. But without some editing you might then be in a situation of having produced a public document that would only be read by those who share & can follow your academic interest. That's exactly what happens with "academic papers": hence the basis for that comparison.

Since I don't want you to be worried ("puzzled") anymore by suggestions like this, I would rather wait until Tuesday when we can get a broader range of eyes on the document. If I have said anything unreasonable... or suggested refinements that aren't necessary or wouldn't benefit readers... that should come out fairly soon in the initial review & hope to see you there in any case.

[rphair]

@nhenin @rrtoledo FYI tomorrow's regular CIP meeting (where this was on the agenda for Triage) has been postponed until the next biweekly CIP meeting slot on 19 August (https://hackmd.io/@cip-editors/117) due to general attendance at Rare Evo this week. Editors were comparing some notes about this submission in messaging today & are planning a more well-rounded review here on GitHub in the days ahead.

[nhenin]

Related to that point:

[ ] There is no Security CIP category, so this is just Consensus.

That was just a "reminder to myself", which I forgot to remove. I’ve now addressed it separately as an issue: #1076

[rphair]

@nhenin @rrtoledo thanks again for bringing this practical part of your achievement to the community & the CIP meeting yesterday. The editors more generally confirmed the advantages of having this proposal exist at two levels:

• an entry level: allowing non-specialist readers to more easily confirm this proposal in governance decisions: regarding both inclusion in hard forks and potential funding propositions
• a full specification level: with everything as you have written to make this proposal understood & implemented by responsible stakeholders, as you originally conceived (with already given apologies for using the word "academic" to refer to the density of detail × esoteric subject matter)

It remains at your discretion whether this would have to exist as 2 separate documents, as opposed to a single document with an appendix. As you know (cc @aldo555) we're still awaiting cips.cardano.org support for inter-document links to README.md files in subdirectories, as in CPS-0021 (though links to other-named files, like SPEC.md as @Crypto2099 suggested, should work at least in the top level directory):

• cardano-foundation/cf-cip-frontend#51

So please @rrtoledo we will watch out for your proposed update as per your #1065 (comment) and whatever feedback you & @nhenin have taken on from yesterday's CIP meeting.

Please let us know when it's been updated to your satisfaction and we will put it up for Review on the agenda or tag Last Check depending on how happy everyone seems to feel with it at that point. And thanks again to you & your team for the extraordinary work and special attention. 🙏

in the short term

Please update the directory name to CIP-0161 🎉 and

• rename your top level file from Readme.md to README.md
• update the "Rendered" link in the OP to point to the new pathname
• (if & when creating another spec file as above) add another "rendered" link to this in your OP

It also came up at the meeting for CIP editors to preemptively address the potential complexity issues affecting longer & more detailed CIPs, which anyone following or advocating this proposal is welcome to help us address (in a planned update to CIP-0001) via this issue:

• #1075

[rphair]

@nhenin the last hour's CIP meeting admitted that other CIP editors have not had enough time to review this proposal in proper depth and will be taking some time soon to go over the material with due attention to detail: with of course not enough time to do that at the meeting.

I'll keep an eye out for any editor consensus that would allow us to merge it earlier & otherwise it'll remain at Last Check for the meeting in 2 weeks' time.

[Ryun1]

another phenomenal body of work
amazing work @nhenin and co-authors

(giving this one the green tick preemptively of final minor comment resolution)

[nhenin]

Hi, I’ve added all your feedback @Ryun1 in this last commit. FYI, I force-pushed, but it didn’t affect the history of our comments (I had pushed some unnecessary commits earlier...). if I understood correctly @rphair, the deadline for merging this PR is tomorrow?

[rphair]

yes, it's fine @nhenin since you force-pushed a branch that contained all commits that we already had in the commit history. In the interest of brevity we often have to say "no force push" even though what we really mean is "don't force push from a reset branch that has your updated content without all the commits that created it" 🤓

• @Ryun1 @Crypto2099 @perturbing maybe we should update the CIP-0001 language accordingly? (I'll put that review on my TODO)

We don't have a "deadline for merging" at any time, and since our CIP meeting is biweekly the Last Check status would next be applied at this meeting next week: https://hackmd.io/@cip-editors/119 — so at this point we are just waiting for @perturbing @Crypto2099 so have a comprehensive look & review. If they have no objections by next Tuesday we can merge it at that meeting... or earlier if they indicate approval or consent here.

[perturbing]

I apologize for the late review; I have it on the to-do list for later today

[perturbing]

Hi, here's an initial part of my review; the rest will come later.

It's a big doc, so this will take some time to go through in full.

Perhaps this VDF usage is also interesting to @L-as ? Care to make a review?

[perturbing]

How will this shift be handled at the epoch boundary of the hard fork enabling this all?

I found a later section mentioning that this change will need a hardfork, but not how it will be addressed.

Furthermore, one of the acceptance criteria is

• The hard fork is successfully executed and the protocol transition is secure.

but should the latter transition not be part of the spec?

[rrtoledo]

We did not write about the transition indeed.

One way to do it would be to have a hybrid period where the seed at epoch e we compute both the randomness of epoch e+1 normally as well as the randomness of epoch e+2 with Phalanx.

Another way would be to not mix the two phases and directly use Phalanx, in which case the randomness of epoch e+1 would be computed as the fallback of Phalanx (since no computation would have been submitted).

[perturbing]

Given that there are two ways, is it then not good to have this specified in the CIP? Perhaps @lehins can advise on this

[rrtoledo]

If you are happy with adding this information, I'll add a subsection with this in the specifications. In term of complexity, the second option seem simpler but I have to double check the security of it.

Is there anything else you think is missing for the transition?

[nhenin]

So the idea was to delegate these concerns to the next phase of the proposal, focused on node integration of the protocol. We’ve documented those details in the implementation plan.

Implementation Plan

To fulfill the above criteria, the following steps are planned:

• Triage and scope confirmation by Intersect’s Core Infrastructure and Consensus teams.

• Coordination with ongoing workstreams on consensus protocol enhancements:

  • Compatibility with Peras
  • Compatibility with Leios
  • Compatibility with Ouroboros Genesis

• Development and publication of a community communication plan covering:

  • The initial values of Phalanx parameters
  • The procedure for evaluating and updating these parameters

• Integration of a Wesolowski-style VDF library into cardano-crypto-class

• Implementation of the node-level logic, including support for the hard fork mechanism

• Construction and execution of a comprehensive node-level conformance test suite

[perturbing]

@bwbush, just to be certain, how would such a change impact Leios?

Given that both Leios and Phalanx have been deemed secure additions to Proas, is their combination also considered?

[perturbing]

@KtorZ, can you find the time to review this, given that it will impact the implementation of Amaru. And tagging other interested parties is much appreciated!

[rrtoledo]

LGTM

[rphair]

@rrtoledo thanks for the confirmation, though @nhenin based on editors' pre-meeting consensus in need of a more comprehensive review I have to dial this back from Last Check for today's meeting.

To ensure this remains on a solid track toward merging as Proposed I've added it explicitly to the Review section of the meeting after that (https://hackmd.io/@cip-editors/120) so, no matter what state it's in at that time, we can at least rigorously look at the issues raised so far & enumerate these for further review or confirmation.

Part of recent editor feedback is that set of reviewers should be enlarged, given that the impact of this proposal would be similar to that of Leios itself which is getting more robust community review (#1078); e.g. Phalanx is proposing to "change stake snapshots, which directly affects vendors and Amaru/Acropolis".

@KtorZ (among others): we still hope you might set the trend by submitting a review of your own. Assuming similar target audiences I'll therefore also tag the reviewers @will-break-it suggested in #1078 (comment) to hopefully get comprehensive and energetic review and settlement before this can merged with confidence.

@abailly @kevinhammond @dcoutts @jpraynaud @SebastienGllmt @Quantumplation @simonjohnthompson @rhyslbw @semanticphilosopher @wolf31o2 @jesusdiazvico @curiecrypt @michele-nuzzi (adding: @polinavino @dnadales) (p.s. adding [re: e.g. "stake snapshots"] @lehins @WhatisRT)

[nhenin]

@rphair,

Do we have any kind of SLA or time-boxing in place for CIP/CPS reviews? I’m asking because it seems like some proposals stay in “Review” for many months, sometimes even over a year. Looking through the repo’s history, I keep finding examples in that situation. E.g When I search for related work to my next initiative, a great majority of them are in this same position :
• CPS-0015 “Intents for Cardano” Problem Statement : closed but have opened CIPs related to it
• CIP-0118? | Nested Transactions #862 : created on on Jul 23, 2024 relying on the closed CPS-0015
• CIP-???? | Merkle Root of Transactions in Block Header : created on Jan 19 2025
• CPS-0019? | Light Client Protocols : created on Nov 2024

I wouldn’t like this to happen for the Phalanx one, which is already almost 2 months old. I understand this particular PR was posted right in the middle of the summer, which is not the best moment… But nevertheless, I’d rather anticipate a potential issue now than wait for it to happen.

Should I open an issue to discuss this, or is there already one in flight?

[rphair]

@nhenin we follow a convention of applying a Waiting for Author tag when we can document that the author needs more time to respond to reviews and/or to develop methods for a proposal before it can be reviewed further (e.g. Merkle Root [cc @aslesarenko @colll78]) and Light Client Protocols [cc @cleanerm5])).

• This categorisation is described here, which is the closest thing to an SLA we currently have about it: https://github.com/cardano-foundation/CIPs/wiki/301.-State-tagging#state-tag-details

Conversely: we don't apply that tag when the CIP PR is in a state when general review is still possible... and therefore potentially applicable to whatever deliberations the author may currently be going through before progressing their proposal (e.g. Nested Transactions [cc @lehins] who's taken it over from @polinavino).

Separately: when subsequent CIPs go beyond, or redefine, the scope of an apparently related CPS (e.g. Intents for Cardano [cc @michaelpj]) the expectation — from authors, not editors — is that authors or advocates of those CIPs will either (with the applicable CPS remaining closed or tagged as stalled / deprecated until then):

• recognise the connection with some already submitted CPS, open that PR (if closed) & offer to maintain it (I did exactly this with CPS-0003? | Smart tokens #947); or
• submit a new CPS that redefines the problem in a more readily & currently applicable way.

None of these conditions apply to this PR for Phalanx: therefore it's fine that we discuss it here rather than opening up a separate issue over what's already understood through community practice and documentation on the CIP Wiki. This PR only remains unmerged because both these conditions are true:

1. half the CIP editors haven't had the time to review it to their satisfaction;
2. the same community of Consensus reviewers, and those in related disciplines, have not endorsed this with the same level of attention that's been paid to Leios... keeping in mind it's still only 2 days since I posted this wider call for review and even Leios took a couple weeks to pull the review train up to full speed after the author's similar request (CIP-0164? | Ouroboros Linear Leios - Greater Transaction Throughput #1078 (comment): cc @will-break-it).

Therefore @nhenin if you consider # 1 to be a bottleneck, since technically this proposal is ready to merge with its current 2 editor endorsements, the best way to move it forward — if editors can observe evidence that subject matter experts are generally providing favourable peer review — would be to use your own influence to make progress on # 2.

[nhenin]

@rphair thanks for the clarification. Let’s give reviewers time to look over this PR

[rphair]

@nhenin cross-referencing this Cardano Forum posting which I believe could be effective as another call for feedback & review: https://forum.cardano.org/t/join-us-for-a-live-discussion-on-cip-0161-ouroboros-phalanx/149902

[rphair]

@nhenin - Review at CIP meeting tonight stressed that we would have appreciated more stakeholder review of this proposal... though in fact we made substantial efforts to engage both advocates and critics of the current Leios CIP candidate, with numerous invitations for cross-review both on GitHub and via community channels.

The consensus was that both authors and editors have done "due diligence" to identify any objections to this proposal: which now may stand on its own as something that can either be included in long-term Consensus development or not; while as a technical and standard document it is agreed fit for purpose.