Skip to content

Commit 419caf7

Browse files
committed
docs: weekly update
1 parent 7e3e09f commit 419caf7

File tree

1 file changed

+41
-66
lines changed

1 file changed

+41
-66
lines changed
Lines changed: 41 additions & 66 deletions
Original file line numberDiff line numberDiff line change
@@ -1,90 +1,65 @@
11
---
2-
title: Weekly Summary - 2025-04-14
2+
title: Weekly Summary – April 14, 2025
33
authors:
44
- will
55
tags: [progress, update, weekly]
66
---
77

8-
This week, the team made significant progress in various areas, resulting in improved simulations, better analysis workflow, and key findings from the Edinburgh workshop.
8+
This week, the team achieved significant milestones in both the Haskell and Rust simulations, improved cost estimates, and conducted comprehensive analyses of transaction lifecycle and Full Leios simulations.
99

1010
### Simulation improvements
1111

1212
#### Haskell simulation
13-
- Completed the first draft of new mini protocols for leios diffusion
14-
- See `simulation/docs/network-spec` for the protocol details, modeled after BlockFetch and node-to-node Tx-Submission ones from ouroboros-network.
15-
- IB-relay, EB-relay, Vote-relay for header diffusion and body (for IB and EB) announcements.
16-
- IB-fetch, EB-fetch, for body diffusion.
17-
- CatchUp protocol for older blocks.
18-
- Renamed `short-leios` command to `leios` since it covers full variant too.
19-
- `short-leios` is kept as alias for compatibility.
13+
- Completed first draft of new mini protocols for leios diffusion
14+
- Protocols modeled after BlockFetch and node-to-node Tx-Submission from ouroboros-network
15+
- IB-relay, EB-relay, Vote-relay for header diffusion and body announcements
16+
- IB-fetch, EB-fetch for body diffusion
17+
- CatchUp protocol for older blocks
18+
- See `simulation/docs/network-spec` for complete protocol details
19+
- Renamed `short-leios` command to `leios` since it now covers full variant as well
20+
- `short-leios` is kept as alias for compatibility
2021

2122
#### Rust simulation
2223
- Fixed conformance with shared trace format
2324
- Fixed bug with voting logic which was preventing EBs from receiving enough votes to get on-chain
24-
- Updated visualization to use smaller trace files, to prepare for hosting on docs site
25+
- Updated visualization to use smaller trace files to prepare for hosting on docs site
2526

2627
### Revisions to cost dashboard
2728

2829
The [cost dashboard](https://leios.cardano-scaling.org/cost-estimator/) was updated with lower and more realistic IO estimates.
2930

3031
### Analysis of transaction lifecycle
3132

32-
The Jupyter notebook [Analysis of transaction lifecycle](analysis/tx-to-block.ipynb) estimates the delay imposed by each of the seven stages of Full Leios as a transaction moves from memory pool to being referenced by a Praos block.
33+
The Jupyter notebook [Analysis of transaction lifecycle](https://github.com/input-output-hk/ouroboros-leios/blob/leios-2025w17/analysis/tx-to-block.ipynb) estimates the delay imposed by each of the seven stages of Full Leios as a transaction moves from memory pool to being referenced by a Praos block.
3334

34-
The plot hints at the following:
35-
1. There seems little advantage to moving to stage lengths less than 10 slots.
36-
2. The number of shards should be kept small enough so that the IB rate per shard is high relative to the stage length.
37-
3. Low EB rates result in many orphaned IBs.
38-
4. Realistic parameter settings result in an approximately two-minute delay between transaction submission and its referencing by an RB.
35+
Key findings from the analysis:
36+
1. There seems little advantage to moving to stage lengths less than 10 slots
37+
2. The number of shards should be kept small enough so that the IB rate per shard is high relative to the stage length
38+
3. Low EB rates result in many orphaned IBs
39+
4. Realistic parameter settings result in an approximately two-minute delay between transaction submission and its referencing by an RB
3940

4041
Potential next steps:
41-
- Translating this model into Delta QSD, so that network effects can be included.
42-
- Compare this model's results to output of the Rust simulator.
43-
- Elaborate the model in order to represent the memory-pool and ledger variants under consideration.
44-
45-
## Key findings from Edinburgh workshop recaps
46-
47-
Key discussions, decisions, and findings include:
48-
- Labeled UTXOs (explicit shards) vs accounts (implicit shards) approaches for ledger design.
49-
- Conformance testing strategies including QuickCheck dynamic and trace verification approaches.
50-
- Critical edge cases for user onboarding and system properties.
51-
52-
The team conducted a detailed analysis of Leios node costs across different TPS levels. Key findings include:
53-
- At 10 TPS: 1.8x increase in egress and 6x increase in compute compared to Praos
54-
- At 1K TPS: significant scaling improvements with better resource efficiency.
55-
56-
Recommendations for potential integration with Peras include optimizing the voting mechanism.
57-
58-
The team also discussed performance characteristics at both high and low throughput levels, held an in-depth discussion on optimistic ledger state references, and explored the potential of EB-DAG approach for achieving low latency while maintaining security.
59-
60-
## Detailed Edinburgh workshop highlights
61-
62-
The detailed Edinburgh workshop recaps have been made available, covering key discussions, decisions, and findings.
63-
64-
### Day 1 highlights
65-
- Explored ledger design options comparing labeled UTXOs (explicit shards) vs accounts (implicit shards) approaches
66-
- Discussed conformance testing strategies including QuickCheck dynamic and trace verification approaches
67-
- Analyzed critical edge cases for user onboarding and system properties.
68-
69-
### Day 2 highlights
70-
- Conducted a detailed analysis of Leios node costs across different TPS levels
71-
- Key findings on resource usage include:
72-
- At 10 TPS: 1.8x increase in egress and 6x increase in compute compared to Praos
73-
- At 1K TPS: significant scaling improvements with better resource efficiency
74-
- Provided recommendations for potential integration with Peras, particularly to optimize the voting mechanism
75-
- Discussed performance characteristics at both high and low throughput levels
76-
77-
### Day 3 highlights
78-
- Held an in-depth discussion on optimistic ledger state references
79-
- Explored three main approaches:
80-
1. RB reference: highest security but highest latency
81-
2. EB reference: balanced approach with medium security and latency
82-
3. EB-DAG: advanced approach using directed acyclic graph structure
83-
- Key advantages of the EB-DAG approach:
84-
- Achieves low latency while maintaining security
85-
- Provides strong inclusion guarantees for EBs
86-
- Enables efficient state management and reconstruction
87-
- Creates a complete, verifiable chain history
88-
- Discussed implementation considerations for state management and block ordering under the EB-DAG model
89-
90-
For more information, please see the full workshop recaps in the [Leios documentation](https://github.com/input-output-hk/ouroboros-leios/tree/main/docs/workshop).
42+
- Translating this model into Delta QSD to include network effects
43+
- Comparing this model's results to output of the Rust simulator
44+
- Elaborating the model to represent the memory-pool and ledger variants under consideration
45+
46+
### Simulation and analysis of Full Leios
47+
48+
The team conducted comprehensive simulations using both Haskell and Rust simulators at tag [leios-2025w16](https://github.com/input-output-hk/ouroboros-leios/releases/tag/leios-2025w16). The simulations covered 648 scenarios of Full and Short Leios with varied parameters:
49+
- IB production rate
50+
- IB size
51+
- EB production rate
52+
- Stage length
53+
- CPU constraints
54+
55+
Two new output files were generated:
56+
1. Summary of network, disk, and CPU resource usage over the course of the simulation
57+
2. Vertices and edges of the "Leios graph" showing linkages between transactions, IBs, EBs, RBs, and votes (can be visualized as an interactive web page)
58+
59+
Key findings:
60+
- Agreement between Rust and Haskell simulations is generally quite close
61+
- The Haskell simulation experiences network congestion at 16 IB/s, but the Rust simulation does not
62+
- The Rust simulation uses more CPU at high IB rates than the Haskell simulation
63+
- The Rust simulation sometimes does not produce enough votes to certify an EB
64+
65+
Detailed results are available in the Jupyter notebook [analysis/sims/2025w16/analysis.ipynb](https://github.com/input-output-hk/ouroboros-leios/blob/leios-2025w17/analysis/sims/2025w16/analysis.ipynb).

0 commit comments

Comments
 (0)