Skip to content

Commit f9db123

Browse files
authored
Update faq.md
1 parent cdcc338 commit f9db123

File tree

1 file changed

+56
-61
lines changed

1 file changed

+56
-61
lines changed

site/docs/faq.md

Lines changed: 56 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -17,24 +17,24 @@ and endorser blocks (EBs) that validate them, enhancing the network’s capacity
1717

1818
Leios 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

3939
For everyday users, Leios means faster transaction confirmations and a smoother
4040
experience 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

4949
Leios 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,
5151
storage), 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
5353
during implementation. However, extensive simulations and formal methods aim to
5454
minimize these risks, ensuring Leios remains secure and reliable as it matures.
5555

5656
## What are IBs, EBs, and RBs in Leios?
5757

5858
Leios 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
156153
that 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
161158
transactions from the mempool. It’s cryptographically signed for authenticity
162159
but hasn’t been validated or finalized by the network, leaving it in a pending
163160
state.
@@ -166,12 +163,12 @@ state.
166163

167164
Once minted, the IB is broadcast and visible to all nodes. This allows them to
168165
inspect its transactions and start validation, a key part of Leios’ parallel
169-
processing design. However, visibility doesn’t mean it’s acceptedit’s just a
166+
processing design. However, visibility doesn’t mean it’s acceptedit’s just a
170167
proposal.
171168

172169
### Usability
173170

174-
The IB isn’t usable yetits transactions can’t be spent or relied upon because
171+
The IB isn’t usable yetits transactions can’t be spent or relied upon because
175172
they lack consensus and finality. Only after EBs endorse it and an RB finalizes
176173
it does it become part of the blockchain’s official state. Until then, it could
177174
still 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)
187184
builds 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.
190186
This parallelism lets the network handle far more transactions in that
191-
timepotentially 10x to 100x more than Praos.
187+
timepotentially 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

203199
While IBs aren’t spendable until an RB confirms them, EBs provide early
204200
confidence, 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
206202
limit—hundreds of IBs can queue up in that window, massively increasing
207203
throughput.
208204

209205
## How does Leios maintain security with parallel processing?
210206

211207
Leios 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
214209
ledger every 20 seconds, ensuring a single, consistent chain. This prevents
215210
double-spending or forks by resolving conflicts at the RB stage. Additionally,
216211
cryptographic tools like BLS signatures and VRFs ensure that only valid blocks
@@ -221,9 +216,9 @@ guarantees.
221216

222217
Leios 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

229224
You 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

241236
Leios 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

247242
Your choice of strategy can affect latency, network load, and overall
248243
throughput.
@@ -260,11 +255,11 @@ sharding, but it is not yet part of Leios.
260255
Leios incorporates multiple cryptographic techniques to ensure security and
261256
efficiency:
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

269264
Recent benchmarking shows that aggregated BLS verification significantly speeds
270265
up certificate validation.
@@ -297,11 +292,11 @@ Developers continually refine these simulations based on real-world data.
297292

298293
Based 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

307302
Operators can adjust these parameters, which evolve through community votes.
@@ -322,9 +317,9 @@ These resources provide transparency and regular updates on ongoing development.
322317
Leios changes how transactions are validated and how blocks and memory pools
323318
operate, 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

329324
Weekly updates provide a deeper analysis of these topics, including how advanced
330325
indexing and potential sharding solutions might eventually mitigate challenges.

0 commit comments

Comments
 (0)