|
1 | 1 | --- |
2 | | -title: Weekly Summary - 2025-04-14 |
| 2 | +title: Weekly Summary – April 14, 2025 |
3 | 3 | authors: |
4 | 4 | - will |
5 | 5 | tags: [progress, update, weekly] |
6 | 6 | --- |
7 | 7 |
|
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. |
9 | 9 |
|
10 | 10 | ### Simulation improvements |
11 | 11 |
|
12 | 12 | #### 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 |
20 | 21 |
|
21 | 22 | #### Rust simulation |
22 | 23 | - Fixed conformance with shared trace format |
23 | 24 | - 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 |
25 | 26 |
|
26 | 27 | ### Revisions to cost dashboard |
27 | 28 |
|
28 | 29 | The [cost dashboard](https://leios.cardano-scaling.org/cost-estimator/) was updated with lower and more realistic IO estimates. |
29 | 30 |
|
30 | 31 | ### Analysis of transaction lifecycle |
31 | 32 |
|
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. |
33 | 34 |
|
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 |
39 | 40 |
|
40 | 41 | 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