[WIP] CIP draft #396

will-break-it · 2025-06-10T11:17:10Z

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.

docs/cip/README.md

rphair · 2025-06-12T01:48:55Z

docs/cip/README.md

+**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.


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 · 2025-06-17T13:36:03Z

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?

cip: apply review Co-authored-by: Robert Phair <[email protected]>

* docs(CDDL): added base definitions for blocks, votes & certificates and sharding-specific definitions

* docs: add collateralized transaction * docs: fix source links * docs: shorten notes * docs(cddl): remove uneeded block body hash * docs(cddl): remove IB header shard id as it can be derived from the VRF * docs: headline fix * docs(cddl): add sharded reward account * docs(cddl): fix formula * docs(cddl): add collateral tx field for reward accounts * docs(cddl): add more context for sharded reward account * docs(cddl): clarify sharding benefits * docs(cddl): clarify shard assignment for reward account

docs/cip/README.md

bwbush · 2025-08-14T15:24:47Z

docs/cip/README.md

+
+When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to certify one EB and announce another EB. The EB is a larger block containing additional transaction references. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate header distribution mechanism for rapid EB discovery and equivocation detection.
+
+<a id="rb-header-diffusion" href="#rb-header-diffusion"></a>**RB Header Diffusion**: RB headers diffuse via a new [RbHeaderRelay mini-protocol](#rbheaderrelay-mini-protocol) independently of standard ChainSync (steps 2a and 2b). This separate mechanism enables rapid EB discovery within the strict timing bound $\Delta_\text{hdr}$. Headers are diffused freshest-first to facilitate timely EB delivery, with nodes propagating at most two headers per (slot, issuer) pair to detect equivocation—where an attacker creates multiple EBs for the same block generation opportunity—while limiting network overhead. The header contains the EB hash when the block producer created an EB, allowing peers to discover and fetch the corresponding EB.


We seem to be using en dashes in some places and em dashes in others. Perhaps a technical editor could reconcile all of that before we finalize.

bwbush · 2025-08-14T15:28:17Z

docs/cip/README.md

+
+Whenever an EB is announced through an RB header, nodes must fetch the EB content promptly (step 6), such that they receive it within $L_\text{vote}$ and consequently enables them to vote. Only the EB body corresponding to the first EB announcement/RB header received for a given RB creation opportunity should be downloaded (freshest-first diffusion). The EB contains references to transactions, and nodes do not serve the EB to peers until they have all referenced transactions.
+
+<a id="eb-chain-selection" href="#eb-chain-selection"></a>**EB Propagation for Chain Selection**: To support efficient chain selection, nodes must receive **all EBs from competing forks**, not only those in their current preferred chain. This ensures that when a node switches to a different fork due to the longest-chain rule, it can immediately validate the new chain without additional EB propagation delays. EBs are forwarded before complete validity checks when full ledger state validation is impossible, with only lightweight verification (VRF checks, hash consistency, basic structure validation) performed initially to prevent DoS attacks.


Does this introduce a vulnerability? Adversarial nodes could build on their own fork and honest nodes would have to do network and CPU work just in case it ever becomes the longest chain, even though there would be a vanishingly small probability of that happening.

docs/cip/README.md

bwbush · 2025-08-14T15:35:14Z

docs/cip/README.md

- Triage by intersect Core Infrastructure, Consensus, Ledger, and Network functions.
+  - Compatibility between Peras, Leios, and Genesis.
+  - Common design and implementation for certificates, voting, and related key
+    registration: Mithril, Peras, Leios, and partner chains.


https://github.com/berewt/CIPs/blob/master/CIP-xxxx/CIP-xxxx.md is relevant for key registration.

bwbush · 2025-08-14T15:41:31Z

docs/cip/README.md

+
+As shown in Figure 4, EBs may be announced in either CM or HTM - the protocol does not require being in HTM to announce an EB. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate header distribution mechanism for rapid EB discovery and equivocation detection.
+
+Due to the voting overhead per EB, nodes announce an EB only when the RB is full, they do not announce empty EBs.


Requiring that the RB is full before putting anything in the EB will mean that we cannot have a higher per-transaction Plutus execution limit in EBs. Users wouldn't want to submit a tx that has too much Plutus for an RB and then wait until there is an EB that can accommodate it.

Perhaps we could define "full RB" not in terms of bytes but in terms or bytes and Plutus. That way, the RB would be considered "full" if there was a heavy Plutus tx in the mempool that wouldn't fit in the RB but would fit in the EB.

bwbush · 2025-08-14T15:45:09Z

docs/cip/README.md


-As a result of this decoupled approach, Leios can utilize nearly the full bandwidth available to the network of nodes without requiring unrealistically fast propagation of blocks: Leios employs a structured, multi-stage process where input blocks are produced rapidly and then aggregated and voted upon in subsequent stages before being referenced by a Praos block. Think of Praos as a single-lane highway where every car (block) needs to travel the entire length before the next can start. Leios, in contrast, is like having many local roads (input blocks) feeding into a larger, slower-moving but higher-capacity highway (endorser block aggregation and Praos anchoring).
+On the other hand, the minimum economic requirement establishes the lower bound. As the Cardano Reserve diminishes, transaction fees must replace rewards to maintain network security and SPO profitability. Currently, the Reserve contributes more than 85% of epoch rewards, with less than 15% coming from transaction fees. By 2029, to compensate for Reserve depletion, the network requires approximately 36-50 TPS with average-sized transactions - roughly 10 times current mainnet throughput. This conservative lower bound represents the breakeven point for running the protocol sustainably.


We don't need to acknowledge it here, but an argument has been voiced that fee revenue does not have to replace the reserve because nodes will gain profitability from ancillary services: i.e., nodes could run at a loss with respect to fees but still be profitable because of the other services they provide.

bwbush · 2025-08-14T15:45:32Z

docs/cip/README.md


-In analogy, imagine Praos as a single courier diligently collecting and delivering individual letters one by one, limiting the delivery speed to their individual capacity. Ouroboros Leios, however, operates like a mail sorting office where numerous local branches rapidly collect and bundle letters (input blocks) before a central team efficiently processes and dispatches these aggregated bundles (endorser blocks), achieving a significantly higher delivery volume.
+However, TPS isn't a good metric for defining these bounds. To properly assess economic breakeven points, we measure throughput in Transaction Bytes per second (TxB/s) rather than Transactions per second (TPS). TPS doesn't account for transaction size or computational complexity, making systems with smaller transactions appear "faster" while providing less utility. Current Cardano mainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000 TxB/s (equivalent to roughly 100-200 TPS) - a 30-65x increase sufficient for economic sustainability.


Suggested change

However, TPS isn't a good metric for defining these bounds. To properly assess economic breakeven points, we measure throughput in Transaction Bytes per second (TxB/s) rather than Transactions per second (TPS). TPS doesn't account for transaction size or computational complexity, making systems with smaller transactions appear "faster" while providing less utility. Current Cardano mainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000 TxB/s (equivalent to roughly 100-200 TPS) - a 30-65x increase sufficient for economic sustainability.

However, TPS is not a good metric for defining these bounds. To properly assess economic breakeven points, we measure throughput in Transaction Bytes per second (TxB/s) rather than Transactions per second (TPS). TPS does not account for transaction size or computational complexity, making systems with smaller transactions appear "faster" while providing less utility. Current Cardano mainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000 TxB/s (equivalent to roughly 100-200 TPS) - a 30-65x increase sufficient for economic sustainability.

bwbush · 2025-08-14T15:47:09Z

docs/cip/README.md


-In analogy, imagine Praos as a single courier diligently collecting and delivering individual letters one by one, limiting the delivery speed to their individual capacity. Ouroboros Leios, however, operates like a mail sorting office where numerous local branches rapidly collect and bundle letters (input blocks) before a central team efficiently processes and dispatches these aggregated bundles (endorser blocks), achieving a significantly higher delivery volume.
+However, TPS isn't a good metric for defining these bounds. To properly assess economic breakeven points, we measure throughput in Transaction Bytes per second (TxB/s) rather than Transactions per second (TPS). TPS doesn't account for transaction size or computational complexity, making systems with smaller transactions appear "faster" while providing less utility. Current Cardano mainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000 TxB/s (equivalent to roughly 100-200 TPS) - a 30-65x increase sufficient for economic sustainability.


300,000 TxB/s

That's probably the upper limit of Linear Leios unless we allow EBs of 15 MB or more.

bwbush · 2025-08-14T15:49:05Z

docs/cip/README.md


-The performance of a protocol like Leios can be characterized in terms of its efficient use of resources, its total use of resources, the probabilities of negative outcomes due to the protocol's design, and the resilience to adverse conditions. Metrics measuring such performance depend upon the selection of protocol parameters, the network topology, and the submission of transactions. The table below summarizes key metrics for evaluating Leios as a protocol and individual scenarios (parameters, network, and load).
+The most obvious approach to increasing throughput while minimizing disruption would be simply increasing Praos block sizes. However, this naive alternative would create proportionally longer propagation times that violate Praos timing assumptions and lack sufficient scalability for long-term viability.


Should we note that Praos blocks of more than 3 MB would pose a security risk due to an increase of short forks that adversaries could exploit?

bwbush · 2025-08-14T15:49:33Z

docs/cip/README.md

+
+<a name="competitiveness"></a>**4. Competitive positioning**
+
+The coupled block production design can be extended towards higher concurrency models, as demonstrated in simulation results. It maintains compatibility with more aggressive scaling approaches including full Leios variants, EB and IB (input block) decoupling, and sharding extensions, ensuring current throughput gains don't preclude 100x+ improvements when chain growth solutions mature.


Suggested change

The coupled block production design can be extended towards higher concurrency models, as demonstrated in simulation results. It maintains compatibility with more aggressive scaling approaches including full Leios variants, EB and IB (input block) decoupling, and sharding extensions, ensuring current throughput gains don't preclude 100x+ improvements when chain growth solutions mature.

The coupled block production design can be extended towards higher concurrency models, as demonstrated in simulation results. It maintains compatibility with more aggressive scaling approaches including full Leios variants, EB and IB (input block) decoupling, and sharding extensions, ensuring current throughput gains do not preclude 100x+ improvements when chain growth solutions mature.

bwbush · 2025-08-14T15:54:51Z

docs/cip/README.md

+network traffic, of course.
+
+<a name="operating-costs"></a>**Operating costs**
+


Suggested change

> [!IMPORTANT]

>

> TODO: **@bwbush**

>

> - [ ] Revise this section and the computations to align with Linear Leios

bwbush

I've commented from the start through just before Trade-offs & Limitations.

The motivation and explanation of the modes and linear leios is compelling and clear. 🎉

Highlighted a few technical concerns about the protocol itself
Suggested or requested clarification of potentially ambiguous text
Need to be precise about words like "may", "must", "should", "shall", "can": sometimes these are requirements for honest nodes, sometimes they are constraints on validity, etc. It will be interesting to see how the Agda handles these distinctions.
Avoid contractions and slang.
I didn't see any big gaps other than what is already in progress (incentives, mini-protocols).

* docs(cip): refactor specification for L_recover without modes

yveshauser

The CIP is well written and covers the protocol in detail. As soon as we have the formal spec of Linear Leios, we could additionally

Emphasize more the formal specification
Add a section about conformance testing / trace verification

yveshauser · 2025-08-15T08:54:50Z

docs/cip/README.md

+of stakepool operations.
+
+A major protocol upgrade like Leios will take
+significant time to implement, test, and audit, it is important to began


Suggested change

significant time to implement, test, and audit, it is important to began

significant time to implement, test, and audit, it is important to begin

yveshauser · 2025-08-15T09:26:33Z

docs/cip/README.md

-## Specification
+<a id="bitmap-size-constraint" href="#bitmap-size-constraint"></a>**Bitmap Size Constraint**: The transaction execution bitmap size $S_\text{bitmap}$ (see [Protocol Parameters](#protocol-parameters)) must fit within $S_\text{RB}$ alongside other required data. This is ensured by bounding $L_\text{recover}$ implicitly via $S_\text{bitmap} < S_\text{RB}$ (see [Bitmap Size Relationships](#bitmap-size-relationships)).
+
+<a id="cost-proportionality" href="#cost-proportionality"></a>**Cost Proportionality**: The first block after the certificate-active window expires pays a cost proportional to the **uncorrected** transactions - i.e., RB transactions since the last EB certificate. EB corrections already included during the certificate-active period reduce this cost; only the remaining transactions require an RB-side bitmap.


Suggested change

<a id="cost-proportionality" href="#cost-proportionality"></a>**Cost Proportionality**: The first block after the certificate-active window expires pays a cost proportional to the **uncorrected** transactions - i.e., RB transactions since the last EB certificate. EB corrections already included during the certificate-active period reduce this cost; only the remaining transactions require an RB-side bitmap.

<a id="cost-proportionality" href="#cost-proportionality"></a>**Cost Proportionality**: The first block, after the certificate-active window expires, pays a cost proportional to the **uncorrected** transactions - i.e., RB transactions since the last EB certificate. EB corrections already included during the certificate-active period reduce this cost; only the remaining transactions require an RB-side bitmap.

The sentence reads better with a comma

yveshauser · 2025-08-15T10:00:05Z

docs/cip/README.md

+### How Leios addresses CPS-18 and increases throughput
+
+The [Leios research paper][leios-paper] describes a highly concurrent protocol with three block types - Input Blocks (IBs), Endorser Blocks (EBs), and Ranking Blocks (RBs)-produced independently across decoupled, pipelined stages. This specification simplifies that design by eliminating IBs and coupling EB production with RB production, reducing complexity while preserving substantial throughput gains.
+


Would be great to have summarizing statement of the idea behind Linear Leios, something like: Linear Leios introduces a voting layer over Nakamoto-style consensus for dealing with transaction surplus.

yveshauser · 2025-08-15T10:03:07Z

docs/cip/README.md

+> - [ ] Add a paragraph about the recovery period.
+> - [ ] Are the per-transaction Plutus limits appropriate?
+
+Simulations on mainnet-like topologies indicate that seven slots is more than sufficient to diffuse the transactions, blocks, and votes required by Leios. Most nodes receive these in one second or less and even the tardiest nodes receive them in under two seconds. Similarly, the cryptography involved can be easily executed within the CPU budget. Seven-second voting periods provide a long safety margin for the transport and computation. A longer voting period would increase the probability that a ranking block is forged during the voting period: in such a situation, the endorser block would have to be discarded. Thus there is a tradeoff between allowing enough time for diffusion and computing but not so much time that endorser blocks are too frequently discarded. Higher-fidelity simulators, better empirical data on mainnet performance, and Leios testnet operations will can test the appropriateness of this parameter and refine its value for a final recommendation.


Suggested change

Simulations on mainnet-like topologies indicate that seven slots is more than sufficient to diffuse the transactions, blocks, and votes required by Leios. Most nodes receive these in one second or less and even the tardiest nodes receive them in under two seconds. Similarly, the cryptography involved can be easily executed within the CPU budget. Seven-second voting periods provide a long safety margin for the transport and computation. A longer voting period would increase the probability that a ranking block is forged during the voting period: in such a situation, the endorser block would have to be discarded. Thus there is a tradeoff between allowing enough time for diffusion and computing but not so much time that endorser blocks are too frequently discarded. Higher-fidelity simulators, better empirical data on mainnet performance, and Leios testnet operations will can test the appropriateness of this parameter and refine its value for a final recommendation.

Simulations on mainnet-like topologies indicate that seven slots is more than sufficient to diffuse the transactions, blocks, and votes required by Leios. Most nodes receive these in one second or less and even the tardiest nodes receive them in under two seconds. Similarly, the cryptography involved can be easily executed within the CPU budget. Seven-second voting periods provide a long safety margin for the transport and computation. A longer voting period would increase the probability that a ranking block is forged during the voting period: in such a situation, the endorser block would have to be discarded. Thus there is a tradeoff between allowing enough time for diffusion and computing but not so much time that endorser blocks are too frequently discarded. Higher-fidelity simulators, better empirical data on mainnet performance, and Leios testnet operations will test the appropriateness of this parameter and refine its value for a final recommendation.

bwbush · 2025-08-15T14:35:51Z

docs/cip/README.md

+> 
+> The requirement that $S_\text{bitmap} < S_\text{RB}$ creates an upper bound on the recovery period:
+> 
+> $$L_\text{recover} < \frac{8 \times T_\text{min}}{f_\text{RB}}$$


Suggested change

> $$L_\text{recover} < \frac{8 \times T_\text{min}}{f_\text{RB}}$$

> $$L_\text{recover} < \frac{8 \times T_\text{min}}}$$

The worst case scenario is that and RB is forged in every slot, not the fraction $f_\text{RB}$ of the slots.

SupernaviX · 2025-08-15T15:15:37Z

docs/cip/README.md

+A voting committee of stake pools validates the EB. As depicted in Figure 4, votes are collected during the $L_\text{vote}$ period following the EB announcement. Committee members are [selected via sortition](#committee-structure) (lottery based on stake). A committee member votes for an EB only if:
+
+  1. It has received the EB within $L_\text{vote}$ slots from its creation,
+  2. It has **not** received an equivocated RB header for this EB within $L_\text{vote}$ slots,


Should we mention here that a node shouldn't vote until 3 Δhdr after the EB was produced, for equivocation protection? This section talks about L_vote as a permitted voting window, but doesn't mention the start of that window.

SupernaviX · 2025-08-15T17:53:04Z

docs/cip/README.md

+EBs are produced by the same stake pool that created the corresponding announcing RB and reference additional transactions to increase throughput beyond what can be included directly in the RB.
+
+<a id="eb-structure" href="#eb-structure"></a>**EB Structure**: EBs have a simplified structure without header/body separation:
+- `transaction_references`: List of transaction references (transaction ids)


A "transaction id" is just the hash, right?

SupernaviX · 2025-08-15T17:57:47Z

docs/cip/README.md

+| Characteristic            |       Symbol        | Units | Description                                                 |          Typical Range          | Notes                                              |
+| ------------------------- | :-----------------: | :---: | ----------------------------------------------------------- | :-----------------------------: | -------------------------------------------------- |
+| RB diffusion time         | $\Delta_\text{RB}$  | slot  | Observed upper bound for RB diffusion and adoption to all nodes     |            2-6 slots            | Depends on network topology and conditions         |
+| RB header diffusion time  | $\Delta_\text{hdr}$ | slot  | Observed time for RB headers to reach all nodes                 |     $\leq \Delta_\text{RB}$     | Usually faster than full block diffusion           |


This is an observed property of the network, but EB equivocation protection requires nodes to wait $3\Delta_\text{hdr}$ after an EB is created before voting for it. I think we need another protocol parameter to represent that.

SupernaviX · 2025-08-15T18:02:37Z

docs/cip/README.md

+
+</div>
+
+<a id="protocol-parameters" href="#protocol-parameters"></a>**Protocol Parameters**


I remember in Edinburgh, someone mentioned that there had to be a way to gracefully enable and disable Leios. Do we need some protocol parameter for that? (is setting $S_\text{EB-tx}$ to 0 good enough?)

SupernaviX · 2025-08-15T18:08:01Z

docs/cip/README.md

+
+</div>
+
+<a id="protocol-parameters" href="#protocol-parameters"></a>**Protocol Parameters**


How are memory/CPU execution constrained? Praos has a "maxBlockExecutionUnits" parameter, but we're expecting to include many more TXs in EBs than Praos could; do we need a dedicated "maxEndorserBlockExecutionUnits" parameter?

SupernaviX · 2025-08-15T18:31:04Z

docs/cip/README.md

+
+#### Transaction Diffusion
+
+<a id="transaction-propagation" href="#transaction-propagation"></a>**Transaction Propagation**: Uses the TxSubmission mini-protocol exactly as implemented in Praos. Transactions flow from downstream to upstream nodes through diffusion, where they are validated against the current ledger state before being added to local mempools. The protocol maintains the same FIFO ordering and duplicate detection mechanisms.


I don't think TX propagation works exactly the same as in Praos. Nodes must propagate any transactions which belong to an EB, even if their mempools are full or contain conflicting TXs.

After reading further: I think that the "Transaction Retrieval" section implies that the TxSubmission protocol works exactly the same way it does today, but in addition there's another set of TX miniprotocols which don't interact with the mempool. Is that the case? If so, might be worth mentioning that section here.

SupernaviX · 2025-08-15T18:36:22Z

docs/cip/README.md

+
+#### RB Block Production and Diffusion
+
+When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection.


Suggested change

When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection.

When a stake pool wins block leadership (step 1), they simultaneously create two things: a ranking block (RB) and an endorser block (EB). The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection.

if you're (re)introducing concepts here, I think it's a good idea to (re)define the acronyms

SupernaviX · 2025-08-15T19:13:44Z

docs/cip/README.md


+<a id="VotingEB" href="#VotingEB"></a>**Voting Process**: Committee members [selected through a lottery process](#votes-and-certificates) vote on EBs as soon as vote requirements are met according to protocol (step 9). An honest node casts only one vote for the EB extending its current longest chain.


The rust simulation handles voting in Linear Leios the same way as in every other variant; pools with sufficiently high stake can win multiple voting opportunities from a VRF lottery, and if they do then they produce multiple votes in favor of that EB.

Does "An honest node casts only one vote for the EB extending its current longest chain" imply that this voting strategy is incorrect, and that every pool produces at most one unweighted vote for an EB?

SupernaviX · 2025-08-15T19:52:04Z

docs/cip/README.md


-### Specification for votes and certificates
+<a id="certificate-inclusion" href="#certificate-inclusion"></a>**Certificate Inclusion**: Block producers creating new RBs include certificates for EBs where the full stage duration ($L_\text{vote}$ slots) has elapsed since the EB's creation (step 12). The producer may also announce a new EB extending their RB. Including a certificate resets the $L_\text{recover}$ rolling window, either extending an existing enhanced throughput period or starting a new one (as detailed in [Rolling Window Rules](#rolling-window-rules)). 


I thought we got rid of this $L_\text{vote}$ waiting rule.

will-break-it changed the title ~~Cip/review~~ [WIP] CIP Jun 10, 2025

rphair reviewed Jun 12, 2025

View reviewed changes

ch1bo approved these changes Jun 12, 2025

View reviewed changes

ch1bo changed the title ~~[WIP] CIP~~ [WIP] CIP specification section Jun 12, 2025

ch1bo force-pushed the cip/review branch 2 times, most recently from 452236a to 737b8ec Compare June 12, 2025 12:16

will-break-it and others added 7 commits June 23, 2025 19:39

docs(cip): add protocol overview and ledger design section

313b664

Update docs/cip/README.md

a882ba6

cip: apply review Co-authored-by: Robert Phair <[email protected]>

cip: apply review

b68571d

Fix a few typos

58ab653

Introduce a two phased approach as part of specification

4e0b55a

Re-organize and sketh specification section

13c2b35

CDDL (#420)

5d55a1b

* docs(CDDL): added base definitions for blocks, votes & certificates and sharding-specific definitions

ch1bo force-pushed the cip/review branch from cce0368 to 5d55a1b Compare June 23, 2025 17:41

will-break-it and others added 14 commits June 26, 2025 10:20

docs: added linear & eb-only cddls

1d143da

cip: add CDDL specification (linear)

840aac0

cip: add CDDL specification descriptions

4d12b5a

cip: clean up & ordering sections

f64f25f

cip: non-normative overiew of protocol

96bfeb4

cip: non-normative key constraints of protocol

339c4df

cip(fix): github markdown formula error for underscore use

9919677

docs(cip): simplified protocol overview

d19f645

docs(cip): rephrase EB

d17020c

docs(cip): introduce acronyms only once

f360cf0

docs(cip): add protocol flow

65284f0

docs(cip): fix image anchor

2fe160e

docs(cip): fix formula

9951487

bwbush reviewed Aug 14, 2025

View reviewed changes

docs/cip/README.md Show resolved Hide resolved

bwbush reviewed Aug 14, 2025

View reviewed changes

docs/cip/README.md Outdated Show resolved Hide resolved

bwbush reviewed Aug 14, 2025

View reviewed changes

bwbush approved these changes Aug 14, 2025

View reviewed changes

will-break-it and others added 14 commits August 14, 2025 19:43

doc(cip): update figures for L_recover specification approach

63a77ca

docs(cip): refactor specification for L_recover

e84c8e0

docs(cip): update figures

8034766

docs(cip): add EB availability limitations

9e59ae8

Cip/l recover (#496)

ec3ae79

* docs(cip): refactor specification for L_recover without modes

docs(cip): trim to two key factors

98f10d6

docs(cip): fix formula in subcaption

d5be1fb

docs(cip): fix pp section

ff5aa72

docs(cip): fix pp section

0bd85df

docs(cip): integrate Nicks feedback on node behavior

0800fb9

docs(cip): draft incentives

1c63a75

docs(cip): fix section headline

dbcb255

docs(cip): add node behavior sequence svg

abeaeae

docs(cip): update node behavior sequence svg

2fc40df

yveshauser approved these changes Aug 15, 2025

View reviewed changes

bwbush reviewed Aug 15, 2025

View reviewed changes

SupernaviX reviewed Aug 15, 2025

View reviewed changes


		When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to certify one EB and announce another EB. The EB is a larger block containing additional transaction references. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate header distribution mechanism for rapid EB discovery and equivocation detection.

		<a id="rb-header-diffusion" href="#rb-header-diffusion"></a>RB Header Diffusion: RB headers diffuse via a new [RbHeaderRelay mini-protocol](#rbheaderrelay-mini-protocol) independently of standard ChainSync (steps 2a and 2b). This separate mechanism enables rapid EB discovery within the strict timing bound $\Delta_\text{hdr}$. Headers are diffused freshest-first to facilitate timely EB delivery, with nodes propagating at most two headers per (slot, issuer) pair to detect equivocation—where an attacker creates multiple EBs for the same block generation opportunity—while limiting network overhead. The header contains the EB hash when the block producer created an EB, allowing peers to discover and fetch the corresponding EB.


		Whenever an EB is announced through an RB header, nodes must fetch the EB content promptly (step 6), such that they receive it within $L_\text{vote}$ and consequently enables them to vote. Only the EB body corresponding to the first EB announcement/RB header received for a given RB creation opportunity should be downloaded (freshest-first diffusion). The EB contains references to transactions, and nodes do not serve the EB to peers until they have all referenced transactions.

		<a id="eb-chain-selection" href="#eb-chain-selection"></a>EB Propagation for Chain Selection: To support efficient chain selection, nodes must receive all EBs from competing forks, not only those in their current preferred chain. This ensures that when a node switches to a different fork due to the longest-chain rule, it can immediately validate the new chain without additional EB propagation delays. EBs are forwarded before complete validity checks when full ledger state validation is impossible, with only lightweight verification (VRF checks, hash consistency, basic structure validation) performed initially to prevent DoS attacks.


		As shown in Figure 4, EBs may be announced in either CM or HTM - the protocol does not require being in HTM to announce an EB. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate header distribution mechanism for rapid EB discovery and equivocation detection.

		Due to the voting overhead per EB, nodes announce an EB only when the RB is full, they do not announce empty EBs.


		As a result of this decoupled approach, Leios can utilize nearly the full bandwidth available to the network of nodes without requiring unrealistically fast propagation of blocks: Leios employs a structured, multi-stage process where input blocks are produced rapidly and then aggregated and voted upon in subsequent stages before being referenced by a Praos block. Think of Praos as a single-lane highway where every car (block) needs to travel the entire length before the next can start. Leios, in contrast, is like having many local roads (input blocks) feeding into a larger, slower-moving but higher-capacity highway (endorser block aggregation and Praos anchoring).
		On the other hand, the minimum economic requirement establishes the lower bound. As the Cardano Reserve diminishes, transaction fees must replace rewards to maintain network security and SPO profitability. Currently, the Reserve contributes more than 85% of epoch rewards, with less than 15% coming from transaction fees. By 2029, to compensate for Reserve depletion, the network requires approximately 36-50 TPS with average-sized transactions - roughly 10 times current mainnet throughput. This conservative lower bound represents the breakeven point for running the protocol sustainably.


		In analogy, imagine Praos as a single courier diligently collecting and delivering individual letters one by one, limiting the delivery speed to their individual capacity. Ouroboros Leios, however, operates like a mail sorting office where numerous local branches rapidly collect and bundle letters (input blocks) before a central team efficiently processes and dispatches these aggregated bundles (endorser blocks), achieving a significantly higher delivery volume.
		However, TPS isn't a good metric for defining these bounds. To properly assess economic breakeven points, we measure throughput in Transaction Bytes per second (TxB/s) rather than Transactions per second (TPS). TPS doesn't account for transaction size or computational complexity, making systems with smaller transactions appear "faster" while providing less utility. Current Cardano mainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000 TxB/s (equivalent to roughly 100-200 TPS) - a 30-65x increase sufficient for economic sustainability.


		The performance of a protocol like Leios can be characterized in terms of its efficient use of resources, its total use of resources, the probabilities of negative outcomes due to the protocol's design, and the resilience to adverse conditions. Metrics measuring such performance depend upon the selection of protocol parameters, the network topology, and the submission of transactions. The table below summarizes key metrics for evaluating Leios as a protocol and individual scenarios (parameters, network, and load).
		The most obvious approach to increasing throughput while minimizing disruption would be simply increasing Praos block sizes. However, this naive alternative would create proportionally longer propagation times that violate Praos timing assumptions and lack sufficient scalability for long-term viability.


		<a name="competitiveness"></a>4. Competitive positioning

		The coupled block production design can be extended towards higher concurrency models, as demonstrated in simulation results. It maintains compatibility with more aggressive scaling approaches including full Leios variants, EB and IB (input block) decoupling, and sharding extensions, ensuring current throughput gains don't preclude 100x+ improvements when chain growth solutions mature.

		network traffic, of course.

		<a name="operating-costs"></a>Operating costs

+> [!IMPORTANT]
+>
+> TODO: **@bwbush**
+>
+> - [ ] Revise this section and the computations to align with Linear Leios

	significant time to implement, test, and audit, it is important to began
	significant time to implement, test, and audit, it is important to begin

		### How Leios addresses CPS-18 and increases throughput

		The [Leios research paper][leios-paper] describes a highly concurrent protocol with three block types - Input Blocks (IBs), Endorser Blocks (EBs), and Ranking Blocks (RBs)-produced independently across decoupled, pipelined stages. This specification simplifies that design by eliminating IBs and coupling EB production with RB production, reducing complexity while preserving substantial throughput gains.

	> $$L_\text{recover} < \frac{8 \times T_\text{min}}{f_\text{RB}}$$
	> $$L_\text{recover} < \frac{8 \times T_\text{min}}}$$


		</div>

		<a id="protocol-parameters" href="#protocol-parameters"></a>Protocol Parameters


		#### Transaction Diffusion

		<a id="transaction-propagation" href="#transaction-propagation"></a>Transaction Propagation: Uses the TxSubmission mini-protocol exactly as implemented in Praos. Transactions flow from downstream to upstream nodes through diffusion, where they are validated against the current ledger state before being added to local mempools. The protocol maintains the same FIFO ordering and duplicate detection mechanisms.


		#### RB Block Production and Diffusion

		When a stake pool wins block leadership (step 1), they simultaneously create two things: a RB and an EB. The RB is a standard Praos block with extended header fields to reference one EB and announce another EB. The EB is a larger block containing references to additional transactions. The RB chain continues to be distributed exactly as in Praos, while Leios introduces a separate mechanism to distribute the same headers for rapid EB discovery and equivocation detection.


		<a id="VotingEB" href="#VotingEB"></a>Voting Process: Committee members [selected through a lottery process](#votes-and-certificates) vote on EBs as soon as vote requirements are met according to protocol (step 9). An honest node casts only one vote for the EB extending its current longest chain.


		### Specification for votes and certificates
		<a id="certificate-inclusion" href="#certificate-inclusion"></a>Certificate Inclusion: Block producers creating new RBs include certificates for EBs where the full stage duration ($L_\text{vote}$ slots) has elapsed since the EB's creation (step 12). The producer may also announce a new EB extending their RB. Including a certificate resets the $L_\text{recover}$ rolling window, either extending an existing enhanced throughput period or starting a new one (as detailed in [Rolling Window Rules](#rolling-window-rules)).

[WIP] CIP draft #396

Are you sure you want to change the base?

[WIP] CIP draft #396

Uh oh!

Conversation

will-break-it commented Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rphair left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rphair left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

References

Uh oh!

ch1bo commented Jun 17, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bwbush Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bwbush left a comment

Choose a reason for hiding this comment

Uh oh!

yveshauser left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

will-break-it commented Jun 10, 2025 •

edited

Loading

rphair left a comment •

edited

Loading

rphair left a comment •

edited

Loading

bwbush Aug 14, 2025 •

edited

Loading