@@ -17,24 +17,24 @@ and endorser blocks (EBs) that validate them, enhancing the network’s capacity
1717
1818Leios offers several significant advantages:
1919
20- - ** Higher throughput and lower latency. ** By splitting transaction processing
20+ - ** Higher throughput and lower latency: ** by splitting transaction processing
2121 into IB and EB stages, Leios handles more transactions in parallel, enabling
2222 faster and more responsive applications
23- - ** Better user experience. ** Faster transaction processing means quicker
23+ - ** Better user experience: ** faster transaction processing means quicker
2424 confirmations for wallet users and DApp interactions
25- - ** Flexible diffusion strategies. ** Nodes can choose how to share blocks (e.g. ,
26- prioritizing newest or oldest data), optimizing network performance based on
25+ - ** Flexible diffusion strategies: ** nodes can choose how to share blocks (eg ,
26+ prioritizing the newest or the oldest data), optimizing network performance based on
2727 conditions
28- - ** Enhanced cryptography. ** Leios uses Boneh–Lynn–Shacham (BLS) signatures for
28+ - ** Enhanced cryptography: ** Leios uses Boneh–Lynn–Shacham (BLS) signatures for
2929 aggregated verification and verifiable random functions (VRFs) for fair leader
3030 selection
31- - ** Robust simulations and formal methods. ** Rust and Haskell simulations
31+ - ** Robust simulations and formal methods: ** Rust and Haskell simulations
3232 measure real-world performance, and executable specifications ensure
3333 correctness
34- - ** Scalable cost model. ** A cost calculator helps node operators estimate
35- expenses (For example, storage, CPU usage).
34+ - ** Scalable cost model: ** a cost calculator helps node operators estimate
35+ expenses (for example, storage and CPU usage).
3636
37- ## What does Leios mean for Cardano users (e.g. , wallet users, DApp developers)?
37+ ## What does Leios mean for Cardano users (eg , wallet users, DApp developers)?
3838
3939For everyday users, Leios means faster transaction confirmations and a smoother
4040experience in wallets and DApps—think near-instant payments or interactions
@@ -47,20 +47,20 @@ EBs, RBs), so expect some transition as it rolls out.
4747## What are the risks or trade-offs of Leios?
4848
4949Leios prioritizes scalability, but it’s not without trade-offs. Parallel
50- processing increases demands on node operators (e.g. , more CPU, bandwidth,
50+ processing increases demands on node operators (eg , more CPU, bandwidth,
5151storage), potentially raising costs or requiring better hardware. The complexity
52- of three block types (IBs, EBs, RBs) could also introduce new bugs or delays
52+ of the three block types (IBs, EBs, RBs) could also introduce new bugs or delays
5353during implementation. However, extensive simulations and formal methods aim to
5454minimize these risks, ensuring Leios remains secure and reliable as it matures.
5555
5656## What are IBs, EBs, and RBs in Leios?
5757
5858Leios uses three distinct block types:
5959
60- - ** IB (Input Block )** . A block that contains transactions. Produced by nodes
61- that win the IB sortition lottery
60+ - ** IB (input block )** . A block that contains transactions. Produced by nodes
61+ that win the IB sortition lottery.
6262- ** EB (endorser block)** . A block that references one or more IBs, providing
63- endorsements. Produced by nodes that win the EB sortition lottery
63+ endorsements. Produced by nodes that win the EB sortition lottery.
6464- ** RB (ranking block)** . A block that ranks or orders other blocks as part of
6565 the consensus mechanism.
6666
@@ -70,39 +70,36 @@ occur every ~20 seconds.
7070
7171## What is the relationship between Ouroboros, Peras, and Leios?
7272
73- ### Ouroboros: The foundation
73+ ### Ouroboros: the foundation
7474
7575- What it is: Ouroboros is the overarching family of proof-of-stake (PoS)
7676 consensus protocols that powers Cardano. It’s designed to be secure,
7777 energy-efficient, and provably fair, replacing proof-of-work (PoW) systems
7878 like Bitcoin’s.
79- - Key Features :
79+ - Key features :
8080 - Slot-based time division (epochs and slots, with slots typically 1 second
8181 long in earlier versions, now 20 seconds in Praos for block production)
8282 - Stake pool leaders elected based on stake to mint blocks
83- - Formal mathematical proofs of security (For example, resistance to attacks like
84- double-spending or chain forks).
83+ - Formal mathematical proofs of security (for example, resistance to attacks like
84+ double-spending or chain forks)
8585- Role: Ouroboros is the bedrock consensus mechanism that Peras and Leios build
8686 upon or refine.
8787
88- ### Peras: A modular upgrade
88+ ### Peras: a modular upgrade
8989
9090- What it is: Peras is a proposed evolution of Ouroboros aimed at improving
9191 efficiency and modularity.
9292- Key features:
93- <<<<<<< HEAD
9493 - Separation of concerns. Peras splits consensus into modular components, such
95- as transaction ordering, validation, and ledger state updates, to allow
96- parallel processing and flexibility
97- - Improved finality. It introduces mechanisms for faster confirmation times,
98- =======
99- - Separation of concerns: Peras splits consensus into modular components, such
10094 as transaction ordering, validation, and ledger state updates, to allow
10195 parallel processing and flexibility.
102- - Improved finality: It introduces mechanisms for faster confirmation times,
103- >>>>>>> ceaee0282f9c2d2f0b95d46c26e30d26e9f82847
96+ - Improved finality. It introduces mechanisms for faster confirmation times.
97+ - Separation of concerns. Peras splits consensus into modular components, such
98+ as transaction ordering, validation, and ledger state updates to allow
99+ parallel processing and flexibility.
100+ - Improved finality. It introduces mechanisms for faster confirmation times,
104101 potentially reducing the time to finality compared to Praos’ 20-second block
105- intervals
102+ intervals.
106103 - Adaptability. Designed to integrate with future scaling solutions (like
107104 Leios) and sidechains or layer-2 systems.
108105- Relationship to Ouroboros:
@@ -112,7 +109,7 @@ occur every ~20 seconds.
112109 - It serves as a bridge between the foundational Ouroboros Praos and more
113110 radical scalability-focused variants like Leios.
114111
115- ### Leios: A scalability leap
112+ ### Leios: a scalability leap
116113
117114- What it is: Ouroboros Leios is a specific variant of the Ouroboros family,
118115 designed to dramatically increase Cardano’s throughput (transactions per
@@ -121,13 +118,13 @@ occur every ~20 seconds.
121118 research community.
122119- Relationship to Ouroboros:
123120 - Leios is a specialized extension of Ouroboros, taking the core PoS mechanics
124- and rearchitecting block production for scalability.
121+ and re-architecting block production for scalability.
125122 - It retains Ouroboros’ security model but reimagines how transactions are
126123 ingested and validated, making it a next-generation Ouroboros variant.
127124
128125### The relationship
129126
130- - Ouroboros as the Core :
127+ - Ouroboros as the core :
131128 - Ouroboros (especially Praos) is the foundational consensus protocol that
132129 defines Cardano’s PoS system. Both Peras and Leios are built on this
133130 foundation, inheriting its security properties and stake-based governance.
@@ -139,25 +136,25 @@ occur every ~20 seconds.
139136- Leios as a scalability solution:
140137 - Leios takes Ouroboros further by addressing throughput limitations head-on.
141138 It uses the same PoS principles but introduces a parallel processing model
142- that Peras’ modularity could theoretically support or complement
139+ that Peras’ modularity could theoretically support or complement.
143140 - Leios can be seen as a 'plugin' or evolution that fits into the Ouroboros
144141 ecosystem, possibly relying on Peras’ groundwork for smoother integration.
145142- Timeline and evolution:
146- - Ouroboros Praos → Current live protocol
147- - Peras → A near-future refinement for flexibility and efficiency
148- - Leios → A long-term scalability solution, still in research/development,
143+ - Ouroboros Praos → current live protocol.
144+ - Peras → a near-future refinement for flexibility and efficiency.
145+ - Leios → a long-term scalability solution, still in research/development,
149146 aimed at making Cardano competitive with high-TPS blockchains like Solana or
150147 Ethereum layer-2s.
151148
152149## What's the state of an IB before an EB or RB gets created for it? Is it visible, is it usable?
153150
154- Before an Endorsement Block (EB) or Ranking Block (RB) is created, an Input
155- Block (IB) is a proposed set of transactions in a preliminary state. Here’s what
151+ Before an endorsement block (EB) or ranking block (RB) is created, an input
152+ block (IB) is a proposed set of transactions in a preliminary state. Here’s what
156153that means:
157154
158155### State of an IB
159156
160- An IB is minted by a node (e.g. , a stake pool operator) and contains unconfirmed
157+ An IB is minted by a node (eg , a stake pool operator) and contains unconfirmed
161158transactions from the mempool. It’s cryptographically signed for authenticity
162159but hasn’t been validated or finalized by the network, leaving it in a pending
163160state.
@@ -166,12 +163,12 @@ state.
166163
167164Once minted, the IB is broadcast and visible to all nodes. This allows them to
168165inspect its transactions and start validation, a key part of Leios’ parallel
169- processing design. However, visibility doesn’t mean it’s accepted— it’s just a
166+ processing design. However, visibility doesn’t mean it’s accepted — it’s just a
170167proposal.
171168
172169### Usability
173170
174- The IB isn’t usable yet— its transactions can’t be spent or relied upon because
171+ The IB isn’t usable yet — its transactions can’t be spent or relied upon because
175172they lack consensus and finality. Only after EBs endorse it and an RB finalizes
176173it does it become part of the blockchain’s official state. Until then, it could
177174still be discarded if it fails validation.
@@ -183,12 +180,11 @@ final confirmation still takes 20 seconds. Here’s how:
183180
184181### Parallel processing boost
185182
186- Think of Leios like a factory: In Ouroboros Praos, one worker (a slot leader)
183+ Think of Leios like a factory: in Ouroboros Praos, one worker (a slot leader)
187184builds a block every 20 seconds. In Leios, dozens of workers (nodes) create
188- Input Blocks (IBs) continuously, others check them with Endorsement Blocks
189- (EBs), and a supervisor (Ranking Block, RB) approves the batch every 20 seconds.
185+ IBs continuously, others check them with EBs, and a supervisor (RB) approves the batch every 20 seconds.
190186This parallelism lets the network handle far more transactions in that
191- time— potentially 10x to 100x more than Praos.
187+ time — potentially 10x to 100x more than Praos.
192188
193189### Splitting the work
194190
@@ -202,15 +198,14 @@ time—potentially 10x to 100x more than Praos.
202198
203199While IBs aren’t spendable until an RB confirms them, EBs provide early
204200confidence, letting apps (like wallets) act on them sooner for low-risk tasks
205- (For example, showing balances). The 20-second RB is a security anchor, not a
201+ (for example, showing balances). The 20-second RB is a security anchor, not a
206202limit—hundreds of IBs can queue up in that window, massively increasing
207203throughput.
208204
209205## How does Leios maintain security with parallel processing?
210206
211207Leios preserves Cardano’s strong security by combining parallel transaction
212- processing with a sequential finality layer. Input Blocks (IBs) and Endorsement
213- Blocks (EBs) are produced in parallel, but Ranking Blocks (RBs) finalize the
208+ processing with a sequential finality layer. IBs and EBs are produced in parallel, but RBs finalize the
214209ledger every 20 seconds, ensuring a single, consistent chain. This prevents
215210double-spending or forks by resolving conflicts at the RB stage. Additionally,
216211cryptographic tools like BLS signatures and VRFs ensure that only valid blocks
@@ -221,9 +216,9 @@ guarantees.
221216
222217Leios finalizes blocks through a structured voting mechanism. Nodes may adopt:
223218
224- - ** Single-stage voting** . All votes are broadcast in one phase, possibly
219+ - ** Single-stage voting** : all votes are broadcast in one phase, possibly
225220 resulting in a longer CPU usage 'tail' during high throughput
226- - ** Send-recv (two-stage) voting** . Votes are first sent, then a follow-up
221+ - ** Send-recv (two-stage) voting** : votes are first sent, then a follow-up
227222 receive phase ensures broader propagation before final tallies.
228223
229224You can configure voting through parameters such as leios-vote-send-recv-stages
@@ -240,9 +235,9 @@ sortition' because once a node proves it was selected to produce a block or vote
240235
241236Leios supports multiple strategies for propagating blocks and votes:
242237
243- - ** Oldest-first** . Prioritizes older blocks or transactions
244- - ** Freshest-first** . Focuses on the newest blocks or transactions first
245- - ** Peer-order** . Requests blocks in the order peers announce them.
238+ - ** Oldest-first** : prioritizes older blocks or transactions
239+ - ** Freshest-first** : focuses on the newest blocks or transactions first
240+ - ** Peer-order** : requests blocks in the order peers announce them.
246241
247242Your choice of strategy can affect latency, network load, and overall
248243throughput.
@@ -260,11 +255,11 @@ sharding, but it is not yet part of Leios.
260255Leios incorporates multiple cryptographic techniques to ensure security and
261256efficiency:
262257
263- - BLS signatures. Allows efficient aggregation of many signatures into one,
258+ - BLS signatures: allow efficient aggregation of many signatures into one,
264259 reducing verification overhead
265- - Mithril or Musen protocols. Used for voting and proof aggregation, depending
260+ - Mithril or Musen protocols: used for voting and proof aggregation, depending
266261 on the context
267- - VRFs. Ensures fair selection of nodes for block production.
262+ - VRFs: ensure fair selection of nodes for block production.
268263
269264Recent benchmarking shows that aggregated BLS verification significantly speeds
270265up certificate validation.
@@ -297,11 +292,11 @@ Developers continually refine these simulations based on real-world data.
297292
298293Based on preliminary internal testing and simulations:
299294
300- - ** Block size** . Commonly set to about one-third of the available link capacity
295+ - ** Block size** : commonly set to about one-third of the available link capacity
301296 for IBs
302- - ** Voting stages** . Choose single-stage or send-recv, depending on reliability
297+ - ** Voting stages** : choose single-stage or send-recv, depending on reliability
303298 and speed requirements
304- - ** Diffusion strategy** . Many operators use 'freshest-first,' though
299+ - ** Diffusion strategy** : many operators use 'freshest-first,' though
305300 'peer-order' may help maintain compatibility with older setups.
306301
307302Operators can adjust these parameters, which evolve through community votes.
@@ -322,9 +317,9 @@ These resources provide transparency and regular updates on ongoing development.
322317Leios changes how transactions are validated and how blocks and memory pools
323318operate, potentially affecting:
324319
325- - ** Wallets and SDKs** . Which need to accommodate new block types (IBs and EBs)
326- - ** Explorers** . Which must handle higher throughput and multi-block referencing
327- - ** Indexers and APIs** . Which will see more granular block and vote data.
320+ - ** Wallets and SDKs** , which need to accommodate new block types (IBs and EBs)
321+ - ** Explorers** , which must handle higher throughput and multi-block referencing
322+ - ** Indexers and APIs** , which will see more granular block and vote data.
328323
329324Weekly updates provide a deeper analysis of these topics, including how advanced
330325indexing and potential sharding solutions might eventually mitigate challenges.
0 commit comments