Introduce a two phased approach as part of specification

Author: ch1bo

docs/cip/README.md

@@ -70,15 +70,18 @@ Ouroboros Praos cannot support the high transaction volume needed to generate th
 > 
 > If a proposal defines structure of on-chain data it must include a CDDL schema.
 
-### Non-normative overview of Leios
+Given the problem statement and motivation given above, but also considering our [analysis]() and identified [trade-offs](), we propose to implement Leios in a phased approach:
 
-> [!IMPORTANT]
-> 
-> - [ ] Write this section after the details of the recommended variant of Full Leios have been settled.
+- **Phase 1**: enable economically sustainable throughput targeting `100 TPS` (average sized) with minimal compromises
+- **Phase 2**: further enhance concurrency to allow for higher order of magnitude throughput `1000+ TPS`, but with significant changes required
+
+Consequently we will give a detailed specification for a **Phase 1 Leios** protocol and while only sketching options for **Phase 2 Leios**.
 
-### Ledger design challenges and properties
+> [!WARNING]
+>
+> TODO: cover phase1/2 split this idea into rationale and path to active sections
 
-#### Leios protocol overview
+### Leios protocol overview (Phase 1)
 
 To understand the ledger design challenges, it's essential first to understand the key components of the Leios protocol:
 
@@ -89,25 +92,31 @@ To understand the ledger design challenges, it's essential first to understand t
 4. **Endorse** - EBs generated at stage start
 5. **Vote** - voting on EBs and certificate creation
 
-##### Five-Stage Pipeline
+#### 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)
+#### 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)
+#### 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
+#### 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)
+#### 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
+
+### 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
+### Core challenges
 
 The primary challenges introduced by concurrent block production include:
 
@@ -118,7 +127,7 @@ The primary challenges introduced by concurrent block production include:
 
 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
+### Design properties framework
 
 The ledger design aims to satisfy seven key properties, though not all can be achieved simultaneously due to fundamental trade-offs:
 
@@ -135,7 +144,7 @@ The ledger design aims to satisfy seven key properties, though not all can be ac
 - **(P6)** Non-conflicting transaction sequences can be submitted in one batch
 - **(P7)** Transactions can reference recently submitted UTxOs
 
-#### Fundamental trade-offs
+### Fundamental trade-offs
 
 The concurrent nature of Leios creates inherent trade-offs between these properties:
 
@@ -149,7 +158,7 @@ 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
+### Main design approaches
 
 Three primary approaches have been identified to address these challenges: