[WIP] CIP specification section

[will-break-it]

• early structural review
• Motivation
  • Economical sustainability vs. Competitive throughput vs. Impact/ Cost
• Specification
  • Non-normativ protocol overview (pending diagram)
  • Normative specification
  • Constraints on Leios protocol parameters (to be updated for linear leios)
  • Specification of votes and certificates
  • CDDL schema for ledger
  • Mini protocols
  • Node changes
  • Mempool
• Rational (Structure TBD)
  • Phases
  • Challenge(s)
  • Variants Overview
  • Trade-Offs
  • Why phase-1 Leios is practical?
  • Evidence/ Simulation Analysis
  • Feasible protocol parameters
  • Threat Model
  • Resource requirements
• Path to active
  • Acceptance criteria
  • Implementation plan
• Versioning
• References
• Appendix

[rphair]

thanks @will-break-it for inviting review from the CIP community. I've also read through the rest of the text in the same branch and it looks like it will be well in order for posting as a CIP pull request as soon as the bulk of TODO items are completed.

[rphair]

Suggested change

	**Five-Stage Pipeline**: The protocol operates through a structured five-stage pipeline: (1) **Propose** - IBs generated uniformly, (2) **Deliver 1** - IB diffusion using freshest-first strategy, (3) **Deliver 2** - complete IB delivery, (4) **Endorse** - EBs generated at stage start, (5) **Vote** - voting on EBs and certificate creation. This pipeline approach enables concurrent transaction processing while maintaining deterministic ordering and conflict resolution.
	**Input Blocks (IBs)**: Transaction-containing blocks produced at a uniform rate during the "Propose" stage of each [pipeline](#pipeline). IBs are generated by stake pools that win VRF-based [sortition](#sortition), with the protocol utilizing approximately one-third of available network bandwidth for IB traffic. Multiple IBs can be produced concurrently across the network.
	**Endorser Blocks (EBs)**: Aggregation blocks that reference multiple IBs from the current pipeline. EBs are produced at the beginning of the "Endorse" stage by selected stake pools. An EB represents a consensus view of which IBs should be included in the permanent ledger, referencing all IBs that were delivered by specific pipeline deadlines.
	**Votes and Certificates**: During the "Vote" stage, stake pools [vote](#vote) on EBs if they meet strict criteria: all referenced IBs must be available, all IBs seen by the "Deliver 1" deadline must be referenced, and all referenced IBs must validate. When enough votes are collected (achieving a [quorum](#quorum)), a [certificate](#certificate) is created and included in an RB.
	**Ranking Blocks (RBs)**: The main Praos consensus chain blocks that contain at most one certificate per block, attesting to the validity of an EB. RBs anchor the Leios consensus into the established Praos security model and may also contain regular transactions.
	##### Five-Stage Pipeline
	The protocol operates through a structured five-stage pipeline: (1) **Propose** - IBs generated uniformly, (2) **Deliver 1** - IB diffusion using freshest-first strategy, (3) **Deliver 2** - complete IB delivery, (4) **Endorse** - EBs generated at stage start, (5) **Vote** - voting on EBs and certificate creation. This pipeline approach enables concurrent transaction processing while maintaining deterministic ordering and conflict resolution.
	##### Input Blocks (IBs)
	Transaction-containing blocks produced at a uniform rate during the "Propose" stage of each [pipeline](#pipeline). IBs are generated by stake pools that win VRF-based [sortition](#sortition), with the protocol utilizing approximately one-third of available network bandwidth for IB traffic. Multiple IBs can be produced concurrently across the network.
	##### Endorser Blocks (EBs)
	Aggregation blocks that reference multiple IBs from the current pipeline. EBs are produced at the beginning of the "Endorse" stage by selected stake pools. An EB represents a consensus view of which IBs should be included in the permanent ledger, referencing all IBs that were delivered by specific pipeline deadlines.
	##### Votes and Certificates
	During the "Vote" stage, stake pools [vote](#vote) on EBs if they meet strict criteria: all referenced IBs must be available, all IBs seen by the "Deliver 1" deadline must be referenced, and all referenced IBs must validate. When enough votes are collected (achieving a [quorum](#quorum)), a [certificate](#certificate) is created and included in an RB.
	##### Ranking Blocks (RBs)
	The main Praos consensus chain blocks that contain at most one certificate per block, attesting to the validity of an EB. RBs anchor the Leios consensus into the established Praos security model and may also contain regular transactions.

The rest of the document currently has no sections for elaboration of these components. Therefore these should have their own headers — rather than inline headings — to make these definitions deep-linkable. I believe making this information accessible is more important than any goal of keeping this information textually dense.

[rphair]

References

Optional

• ...
• Leios R&D web site

There is such abundant information here for readers at any level — including development & discussion history for so much of this material — that I would editorially support adding a link here from the Abstract to ensure the reader knows early that it's available... rather than having them wait until the final References section.

[ch1bo]

FWIW, I have started to write down more things on this branch and my approval is moot. @will-break-it should we create a new branch / PR for our soon-to-be-more-complete specification section with the phased approach?