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

Author: will-break-it

docs/cip/README.md

@@ -72,6 +72,80 @@ Ouroboros Praos cannot support the high transaction volume needed to generate th
 > 
 > - [ ] Write this section after the details of the recommended variant of Full Leios have been settled.
 
+### Ledger design challenges and properties
+
+#### Leios protocol overview
+
+To understand the ledger design challenges, it's essential first to understand the key components of the Leios protocol:
+
+**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.
+
+#### Fundamental challenges
+
+The concurrent nature of input block (IB) production in Leios introduces fundamental challenges that don't exist in sequential blockchain protocols like Praos. Unlike Praos where blocks are produced sequentially, Leios allows multiple input blocks to be created concurrently within the [network diffusion time](#network-diffusion-time) window. This creates new challenges that must be addressed at the ledger level.
+
+#### Core challenges
+
+The primary challenges introduced by concurrent block production include:
+
+- **Conflicts**: Multiple IBs may include transactions spending the same UTxO
+- **Duplicates**: The same transaction may appear in multiple IBs  
+- **Fee payment**: How to guarantee SPOs are compensated for their work when conflicts occur
+- **Inclusion delays**: Balancing immediate inclusion with conflict prevention mechanisms
+
+These challenges arise because blocks produced within the network diffusion time cannot coordinate to avoid conflicts, creating an inherent concurrency window where conflicts are inevitable. In typical Leios deployments with stage lengths of 10-30 seconds, this results in approximately 3-5 concurrent IBs per pipeline, with additional concurrency across multiple pipeline instances.
+
+#### Design properties framework
+
+The ledger design aims to satisfy seven key properties, though not all can be achieved simultaneously due to fundamental trade-offs:
+
+**Conflict and duplicate properties:**
+- **(P1)** The blockchain does not contain conflicting transactions
+- **(P2)** The blockchain does not contain the same transaction more than once
+
+**Fee payment properties:**
+- **(P3)** Block producers are compensated for processing, storing, and forwarding transactions
+- **(P4)** Users only pay fees if their transaction is executed by the ledger
+
+**Latency properties:**
+- **(P5)** Non-conflicting transactions are included in blocks within time T
+- **(P6)** Non-conflicting transaction sequences can be submitted in one batch
+- **(P7)** Transactions can reference recently submitted UTxOs
+
+#### Fundamental trade-offs
+
+The concurrent nature of Leios creates inherent trade-offs between these properties:
+
+```
+No conflicts (P1) ⟹ No duplicates (P2), Fees paid (P3), Users only pay for executed txs (P4)
+
+Conflicts exist ⟹ Either fees not always paid (¬P3) OR users pay for unexecuted txs (¬P4)
+
+No conflicts (P1) ⟹ Cannot have immediate inclusion (¬P5)
+```
+
+The key insight is that to achieve low latency (P5), we must accept the possibility of conflicts, which then requires careful handling of fee payment mechanisms.
+
+#### Main design approaches
+
+Three primary approaches have been identified to address these challenges:
+
+**Full sharding**: Eliminates conflicts by partitioning the UTxO space into shards, ensuring IBs with the same shard-id appear sequentially. This guarantees properties P1-P3 but introduces inclusion delays (¬P5) as transactions must wait for their assigned shard.
+
+**Over-collateralization**: Allows conflicts but requires transactions to post collateral proportional to concurrency level. This maintains immediate inclusion (P5) while ensuring economic compensation for wasted resources, though it may violate strict conditional fee payment (P4).
+
+**Minimized wasted work**: Delays expensive validation until transaction likelihood of inclusion is high, reducing computational waste while accepting some resource inefficiency. This approach balances multiple properties by optimizing the validation pipeline.
+
+Each approach offers different trade-offs between the seven properties, and the choice depends on the specific requirements and constraints of the deployment scenario.
+
 ### Normative Leios specification in Agda
 
 > [!IMPORTANT]
@@ -106,17 +180,17 @@ Ouroboros Praos cannot support the high transaction volume needed to generate th
 
 ### Specification for votes and certificates
 
-The next section outlines the requirements for Leios sortition, voting, and certificates. Although these are stringent, several proposed schemes meet the criteria. Ideally, a common Cardano voting infrastructure would be used across Leios, Peras, Mithril, and partner chains. For concreteness, however, this section also documents a BLS approach that is feasible for Leios.
+The next section outlines the requirements for Leios [sortition](#sortition), voting, and [certificates](#certificate). Although these are stringent, several proposed schemes meet the criteria. Ideally, a common Cardano voting infrastructure would be used across Leios, Peras, Mithril, and partner chains. For concreteness, however, this section also documents a BLS approach that is feasible for Leios.
 
 #### Requirements
 
-Leios is flexible regarding the details of votes, certificates, and sortition. The key requirements in this regard follow.
+Leios is flexible regarding the details of [votes](#vote), certificates, and sortition. The key requirements in this regard follow.
 
 1. *Succinct registration of keys:* The registration of voting keys should not involve excessive data transfer or coordination between parties. Ideally, such registration would occur as part of the already existing operational certificates and not unduly increase their size.
 2. *Key rotation:* The cryptographic keys used to sign Leios votes and certificates *do not* need to be rotated periodically because the constraints on Leios voting rounds and the key rotation already present in Praos secure the protocol against attacks such as replay and key compromise.
 3. *Deterministic signatures:* Deterministic signatures can guard against attacks that weakening key security. 
 4. *Local sortition:* Selection of the voting committee should not be so deterministic and public as to open attack avenues such as denial-of-service or subversion.
-5. *Liveness:* Adversaries with significant stake (e.g., more than 35%) should not be able to thwart a honest majority from reaching a quorum of votes for an EB.
+5. *Liveness:* Adversaries with significant stake (e.g., more than 35%) should not be able to thwart a honest majority from reaching a [quorum](#quorum) of votes for an EB.
 6. *Soundness:* Adversaries with near majority stake (e.g., 49%) should not be able to form an adversarial quorum that certifies the EB of their choice.
 7. *Small votes:* Because vote traffic is large and frequent in Leios, the votes themselves should be small. Note that the large size of Praos KES signatures precludes their use for signing Leios votes.
 8. *Small certificates:* Because Leios certificates are frequent and must fit inside Praos blocks, they should be small enough so there is plenty of room for other transactions in the Praos blocks. Note once again that certificates based on Praos KES signatures are too large for consideration in Leios.
@@ -602,6 +676,35 @@ The following plots show number of persistent votes and votes, along with certif
 | -------------------------------------------------------- | ---------------------------------------------------------------- |
 | ![Fait-accompli voters](images/fait-accompli-voters.svg) | ![Fait-accompli certificate size](images/fait-accompli-cert.svg) |
 
+### Glossary
+
+#### Certificate
+A cryptographic proof that attests to a quorum of votes for an endorser block, included in ranking blocks to finalize transaction settlement.
+
+#### Endorser Block (EB)
+A block that references multiple input blocks from the current pipeline, representing a consensus view of which IBs should be included in the permanent ledger.
+
+#### Input Block (IB)
+A block containing transactions, produced during the Propose stage of each pipeline by stake pools that win VRF-based sortition.
+
+#### Network Diffusion Time
+The maximum time required for a message (block, vote, or certificate) to propagate to all honest nodes in the network, typically ~5 seconds. This creates a concurrency window where blocks produced cannot coordinate to avoid conflicts.
+
+#### Pipeline
+A structured sequence of five stages (Propose, Deliver 1, Deliver 2, Endorse, Vote) that enables concurrent transaction processing while maintaining deterministic ordering.
+
+#### Quorum
+The minimum threshold of votes (typically 60% of committee votes) required to certify an endorser block and create a valid certificate.
+
+#### Ranking Block (RB)
+A Praos consensus chain block that contains at most one Leios certificate, anchoring Leios consensus into the established Praos security model.
+
+#### Sortition
+A VRF-based probabilistic method for selecting nodes to produce input blocks, endorser blocks, or cast votes, based on their delegated stake.
+
+#### Vote
+A cryptographically signed message from an eligible committee member attesting to the validity of an endorser block during the Vote stage.
+
 ## Copyright
 
 > [!NOTE]