This week, the team made significant progress on simulation improvements, trace verification, and comprehensive analysis of Leios transaction processing capacity.

Trace verification​

• Improved the trace verifier with better error handling and reporting
• Added support for starting verification from non-initial states
• Created manually curated test cases for the Leios trace verifier
  • Valid traces
  • Invalid traces
• Integrated the trace verifier into Nix infrastructure and CI builds
• Removed deterministic conformance testing in favor of trace-based approach.

Simulation improvements​

Haskell simulation​

• Conducted an informal review assessing code quality, design, and implementation
• Analyzed the simulation organization and identified areas for future improvement
• Found that most prospective changes to the Leios protocol would only involve a small fraction of the codebase
• Determined that addition of memory pool and transactions would take approximately 100-200 hours of labor.

The review of the Haskell simulator was documented in detail in PR#353, covering statistics, organization, code quality, design, implementation, and documentation aspects of the simulator.

Rust simulation​

• Added tx-start-time and tx-stop-time parameters to avoid effects of slow starts or sudden terminations on transaction analysis
• Created a new Leios variant full-without-ibs where endorser blocks directly reference transactions.

Documentation and analysis​

• Relocated the original Leios report to avoid confusion, while preserving valuable background information
• Added partially-drafted technical reports on Haskell simulations to Nix and CI builds:
  • Ouroboros Leios Network Specification
  • Ouroboros Leios simulation: building confidence in the performance results

The team conducted higher excess-capacity simulations to evaluate transaction inclusion hypotheses. The transaction lifecycle simulations raised the question of whether duplication of transactions in IBs was starving other transactions from ever being included in an IB. To test this, simulations were run with IBs being produced at three times the normal rate, providing ample space for transaction duplication.

Detailed analysis showed that transaction loss persisted despite increased capacity, indicating that other factors are preventing transactions from reaching the ledger. The results are documented in:

• Analysis overview
• Results at 1x IB capacity
• Results at 3x IB capacity

This week, the team focused on simulation analysis, security improvements, and protocol documentation, making significant progress across multiple areas.

Simulation analysis and performance​

The team executed the first high-throughput simulations of Leios using the Rust simulator, with transaction rates reaching up to 1,000 TPS. They introduced two key efficiency metrics to quantify system performance:

• Temporal efficiency, which measures the fraction of submitted transactions that make it into the ledger, with nearly 100% indicating optimal transaction inclusion
• Spatial efficiency, which represents the ratio of transaction size to total ledger size (including IBs, EBs, and RBs), with higher values indicating better storage optimization.

Recent revisions to Full Short Leios have shown promising improvements in both efficiency metrics. The simulations revealed an average transaction lifecycle of approximately 100 seconds from submission to ledger inclusion.

The analysis produced several key visualizations that demonstrate the system's performance:

Protocol documentation and analysis​

The team conducted an extensive analysis of transaction throughput and block characteristics, producing several key visualizations:

The team also completed a comprehensive profitability analysis for Leios SPOs, considering various deployment scenarios:

• Evaluated infrastructure costs across premium and value cloud providers
• Demonstrated profitability without reserve contributions at 50+ TPS
• Documented the impact of diminishing future rewards due to reserve depletion
• Analyzed comparative economics between Praos and Leios SPOs.

Security and infrastructure improvements​

The team addressed several security vulnerabilities in web applications through a series of patches:

• Fixed minor and moderate security issues in #321, #322, #323, and #325 pull requests.

Protocol enhancements​

Recent protocol improvements include:

• Implementation of revisions to Full Short Leios design to enhance both temporal and spatial efficiency
• Optimization of protocol parameters for improved transaction processing
• Development of a new sharding strategy in Rust simulation
• Enhanced logging system for tracking spatial efficiency metrics.

For more detailed information about the simulations and analysis, please refer to the analysis documentation and the profitability analysis notebook.

This week, the Leios team made significant progress in protocol documentation, simulation improvements, and transaction lifecycle analysis. The team completed a draft of the Leios CIP, enhanced simulation visualization capabilities, and conducted detailed analysis of transaction processing times in Full Leios.

Simulation and analysis​

• Completed simulation of 270 Full Leios scenarios at tag leios-2025w17
• Resolved all outstanding discrepancies between Rust and Haskell simulation results
• Conducted detailed transaction lifecycle analysis:
  • Average IB inclusion time: 2.4 seconds
  • Average EB referencing time: 27.6 seconds
  • Average RB referencing time: 67.2 seconds
  • Identified issues with transaction referencing and duplication in current Full Leios implementation.

Protocol documentation​

• Drafted major sections of the Leios CIP using standard CIP template
• Documented evidence-based arguments for Leios necessity and viability
• Pending completion of Full Leios protocol sections due to ongoing discussions.

Rust implementation​

• Publicly hosted visualization as part of the Leios documentation
• Added new "transactions" view showing transaction state graphs over time
• Fixed stability issues in long-running simulations
• Implemented leios-late-ib-inclusion extension for referencing older pipeline IBs.

Plutus benchmarking​

• Documented workflow for benchmarking Plutus
• Prepared methodology for potential experiments with increased Plutus execution budgets
• Established framework for relating Plutus execution units to CPU time measurements.

Next steps​

• Address transaction referencing and duplication issues in Full Leios
• Complete remaining Full Leios protocol sections in CIP
• Investigate higher transaction rates after resolution of #305
• Continue monitoring and optimizing transaction lifecycle performance.

This week, the Leios team made significant progress in protocol development, focusing on simulation improvements, network protocol design, and economic analysis. The team completed extensive simulations across 648 scenarios, implemented new mini-protocols for Leios diffusion, and conducted important economic analysis regarding future reward sustainability.

Simulation and analysis​

• Completed comprehensive simulation of 648 scenarios for Full and Short Leios at tag leios-2025w16
• Generated new analysis outputs:
  • Network, disk, and CPU resource usage summaries
  • Interactive "Leios graph" visualization showing transaction, IB, EB, RB, and vote linkages
• Key findings from simulations:
  • Strong agreement between Rust and Haskell implementations
  • Haskell simulation shows network congestion at 16 IB/s
  • Rust simulation demonstrates higher CPU usage at elevated IB rates
  • Identified voting certification issues in Rust implementation.

Protocol development​

Haskell implementation​

• Completed first draft of new mini-protocols for Leios diffusion:
  • IB-relay, EB-relay, Vote-relay for header diffusion
  • IB-fetch, EB-fetch for body diffusion
  • CatchUp protocol for historical blocks
• Renamed short-leios command to leios to reflect full variant support.

Rust implementation​

• Fixed conformance with shared trace format
• Resolved voting logic bug affecting EB certification
• Updated visualization system for documentation site integration.

Economic analysis​

The team conducted a detailed analysis of transaction lifecycle and future reward sustainability:

• Analyzed seven stages of Full Leios transaction processing
• Identified optimal stage lengths and shard configurations
• Estimated two-minute average delay from transaction submission to RB reference
• Projected future IB rates needed to maintain current reward levels:
  • Current Reserve depletion rate: 12.8% per year
  • Required IB rates increase from 0.008 to 0.634 blocks/slot by 2035
  • Analysis assumes constant fee-related protocol parameters.

Next steps​

• Translate transaction lifecycle model to Delta QSD for network effects analysis
• Compare model results with Rust simulator output
• Develop memory-pool and ledger variant models
• Continue investigation of voting certification issues in Rust implementation.

This week, the team made substantial progress in both the Haskell and Rust simulations, refined cost estimates, and carried out detailed analyses of the transaction lifecycle and Full Leios simulations.

Simulation improvements​

Haskell simulation​

• Completed the first draft of new mini protocols for Leios diffusion
  • Modeled protocols after block-fetch and node-to-node transaction submission from ouroboros-network
  • Included IB relay, EB relay, and vote relay for header diffusion and body announcements
  • Included IB fetch and EB fetch for body diffusion
  • Worked on the CatchUp protocol for older blocks
  • See simulation/docs/network-spec for full protocol details
• Renamed short-leios command to leios as it now covers the full variant as well
  • short-leios is kept as alias for compatibility.

Rust simulation​

• Fixed conformance issues with the shared trace format
• Fixed a bug in the voting logic that prevented EBs from receiving enough votes to be included on-chain
• Updated visualizations to use smaller trace files in preparation for hosting on the documentation site.

Revisions to the cost dashboard​

The cost dashboard was updated with lower and more realistic IO estimates.

Transaction lifecycle analysis​

The Jupyter notebook Analysis of transaction lifecycle estimates the delay introduced at each of the seven stages of Full Leios as a transaction progresses from the memory pool to being referenced by a Praos block.

Key findings from the analysis:

1. Reducing stage lengths below 10 slots offers little benefit
2. The number of shards should remain low enough to maintain a high IB rate per shard relative to the stage length
3. Low EB rates result in many orphaned IBs
4. With realistic parameters, the delay from transaction submission to its inclusion in an RB is approximately two minutes.

Potential next steps:

• Translate the model into Delta QSD to capture network effects
• Compare the model’s output with results from the Rust simulator
• Extend the model to account for different memory pool and ledger variants under evaluation.

Simulation and analysis of Full Leios​

The team conducted comprehensive simulations using both Haskell and Rust simulators at tag leios-2025w16. The simulations covered 648 scenarios of Full and Short Leios with varied parameters:

• IB production rate
• IB size
• EB production rate
• Stage length
• CPU constraints.

Two new output files were generated:

1. A summary of network, disk, and CPU resource usage over the course of the simulation
2. The vertices and edges of the Leios graph, showing linkages between transactions, IBs, EBs, RBs, and votes (can be visualized as an interactive web page).

Key findings:

• The Rust and Haskell simulations show generally close agreement
• The Haskell simulation encounters network congestion at 16 IB/s, while the Rust simulation does not
• The Rust simulation consumes more CPU at high IB rates than the Haskell simulation
• In some cases, the Rust simulation does not produce enough votes to certify an EB.

Detailed results are available in the Jupyter notebook analysis/sims/2025w16/analysis.ipynb.

This week, the team continued refining the protocol and its simulation capabilities, making significant progress in addressing various topics.

Simulation improvements​

Haskell simulation​

• Started specifying a new relay protocol for IB header diffusion without the body
• Improved the shared log format by removing redundancies and harmonizing naming
• Added support for additional events required by conformance testing, including SlotEvent and NoBlockEvent
  • These events can be enabled using the --conformance-events flag with --shared-log-format.

Rust simulation​

• Updated traces to match the new standardized trace format
• Fixed a critical bug in CPU scheduling where nodes were using more cores than allocated.

Analysis of workflow optimization​

The team significantly improved the workflow for analyzing both Haskell and Rust simulations:

• Replaced MongoDB with more efficient jq queries using map-reduce operations
• Created reusable library functions for plotting with R
• Revised and streamlined scripts for creating, executing, and analyzing simulations
• Made the Jupyter notebook for analyses more generic and reusable
• Successfully tested the new workflow on tag leios-2025w15.

These improvements will enable faster setup and execution of future simulation experiments, with quicker turnaround times for analysis. During this optimization work, several discrepancies between the Haskell and Rust simulations were identified and documented as GitHub issues for future investigation.

Edinburgh workshop recaps​

The Edinburgh workshop documentation has been made available, covering key discussions and decisions:

Day 1 highlights​

• Explored ledger design options comparing labeled UTXOs (explicit shards) vs accounts (implicit shards) approaches
• Discussed conformance testing strategies including QuickCheck dynamic and trace verification approaches
• Analyzed critical edge cases for user onboarding and system properties.

Day 2 highlights​

• Conducted a detailed analysis of Leios node costs across different TPS levels
• Key findings on resource usage:
  • At 10 TPS: 1.8x increase in egress and 6x increase in compute compared to Praos
  • At 1K TPS: significant scaling improvements with better resource efficiency
• Provided recommendations for potential integration with Peras, particularly to optimize the voting mechanism
• Discussed performance characteristics at both high and low throughput levels.

Day 3 highlights​

• Held an in-depth discussion on optimistic ledger state references, exploring three main approaches:
  1. RB reference: highest security but highest latency
  2. EB reference: balanced approach with medium security and latency
  3. EB-DAG: advanced approach using directed acyclic graph structure
• Key advantages of the EB-DAG approach:
  • Achieves low latency while maintaining security
  • Provides strong inclusion guarantees for EBs
  • Enables efficient state management and reconstruction
  • Creates a complete, verifiable chain history
• Discussed implementation considerations for state management and block ordering under the EB-DAG model.

For more information, please see the full workshop recaps in the Leios documentation.

This week, the Leios team met for an in-person workshop in Edinburgh and continued their efforts in refining the protocol and its simulation capabilities. The team made significant progress in addressing various topics.

On day one, the team discussed topics such as ledger design and trade-offs, as well as two different ways to link the formal specification to the simulations. They explored various ledger design options, including labeled UTXOs and accounts approaches, with detailed consideration of fees, collateral, and conflict prevention mechanisms. The team also discussed conformance testing approaches, including QuickCheck dynamic and trace verification methods.

On day two, the team made significant progress towards estimating the cost of running a Leios node, considering different cost items such as network egress, CPU, and storage. They analyzed resource usage across different TPS levels, from 10 TPS to 1K TPS, and discovered that while there’s significant overhead at low throughput, the protocol becomes more efficient at higher TPS levels. The team hasn’t been able to finish all the cost items yet. The last two, IOPS and memory cost, will be added during this month.

On the last and third day, the team consolidated their options for how optimistic validation of input blocks can be accomplished. They defined three candidates, with one being favored. The main goal was to support the chaining of transactions with Leios, which requires defining a 'point in time' or stage of the protocol at which a subsequent or chained transaction can be built on top of an already submitted transaction. This can be achieved by having the node optimistically compute prospective ledger states using its local knowledge of input blocks referenced in certified endorser blocks or possibly ranking blocks.

• Day 1

• Day 2

• Day 3.

Simulation progress​

• Haskell simulation
  • Added support for dishonest nodes that diffuse an unbounded amount of old IBs, enabling further analysis of freshest-first and oldest-first vote delivery scenarios
  • Identified and fixed a bug in configuration generation for simulation runs, which was causing inconsistencies in vote delivery between default and uniform/extended voting schemes
  • Added an adversarial field to the network topology schema, allowing for the simulation of unbounded IB diffusion by dishonest nodes.

Ongoing investigations​

• Investigating the effects of unbounded IB diffusion on IB delivery reliability and protocol performance under such conditions
• Working on quantifying settlement times and their impact on protocol performance
• Exploring integration possibilities with Ouroboros Peras, mainly focusing on potentially reusing their voting mechanism to reduce resource consumption.

Additional resources​

• GitHub discussions – EB ledger states and 'history rewriting' effects
• The First Full Leios simulation analysis – detailed analysis of the latest simulation results.

This week, the Leios team continued working on various aspects of the protocol and its simulation capabilities. They made progress in implementing and testing the Haskell and Rust simulators, focusing on protocol behavior under different network conditions.

Simulation progress​

• Haskell simulation

  • Moved configuration and topology parsers to the leios-trace-hs package for reuse in formal methods
  • Investigated differences in IBs referenced with Rust simulation: identified that inconsistencies were caused by the same sequence of random samples being used across different runs
  • Simplified sortition code by using an external statistics package
  • Tested Full Leios, resolving tension between r_EB/eb-max-age-slots and praos-chain-quality/η
  • Fixed cabal run ols -- generate-topology close-and-random, listing producers properly and decreasing variance in upstream peers.

• Rust simulation

  • Investigated anomalies in simulation results: identified that earlier IB production failures were caused by low connectivity and lower CPU usage compared to the Haskell simulation
  • Refined Full Leios implementation
  • Added Full Leios support to the visualizer
  • Migrated the visualizer from Next.js to Vite.

Analysis of simulations​

• Tag leios-2025w13: simulated 198 Short Leios scenarios, varying IB production rate, IB size, network topology, CPU limits, and protocol flags
• CPU limits: analyzed the impact of CPU constraints on IB propagation, finding that diffusion can be affected under stress conditions
• Vote propagation: compared freshest-first and oldest-first vote propagation, with freshest-first potentially improving IB delivery reliability
• Extended voting period: compared an extended voting period to a limited one in the Haskell simulation, observing minimal differences except for occasional improvements in reliable vote delivery.

Ongoing investigations​

• Investigating qualitative discrepancies between Haskell and Rust simulation results to determine whether they stem from differences in simulator resolution or simulation infidelities.

Additional resources​

• Monthly review meeting – March 2025.

This week, the Leios team made significant progress in protocol development, focusing on improving simulation capabilities and analyzing protocol behavior under various network conditions. A comparison of Haskell and Rust simulations across 18 scenarios demonstrated that the Leios protocol scales effectively to mainnet-sized networks. However, congestion occurs when the input block rate reaches 30 IB/s.

Simulation comparison​

• Compared 18 scenarios between Haskell and Rust simulations at tag leios-2025w12
• Recent fixes and adjustments enabled meaningful comparison between simulations
• Identified differences when comparing the Haskell and Rust results, which are under active investigation.

Analysis of simulations​

• Completed the first simulation of Short Leios, evaluating IB production rate, IB size, and network topology
• Demonstrated that the Leios protocol scales effectively to mainnet-sized networks
• Identified congestion occurring when the input block rate exceeds 30 IB/s
• Suggested that allowing IBs larger than current Praos RBs may have advantages in TCP efficiency, network usage, and adapting to fluctuating transaction loads.

Peak CPU	Mean CPU

Haskell simulation​

• Implemented expiration of blocks:
  • Blocks are removed from the relay buffer once diffusion stops and cleared from other states as specified
• Developed an initial Full Leios implementation:
  • Currently in early testing
  • Added the praos-chain-quality configuration parameter for the \eta parameter from the specification.

Rust simulation​

• Developed an initial Full Leios implementation using estimated values for some parameters.

Formal methods​

• Short Leios trace verification: modeling local state evolution of a node
• Developed an initial trace verifier for Short Leios simulation traces in leios-trace-verifier.

This week, the Leios team made significant progress in simulation capabilities, with a successful comparison of Rust and Haskell simulations across 90 scenarios. A mainnet-scale analysis of Leios on a realistic 3,000-node network revealed unexpected performance benefits from network topology. Insights from sharding performance analysis provided important optimization strategies. Finally, the team refined both simulation implementations for greater realism and comparability, while the formal methods team developed initial trace verification tools for Short Leios.

Simulation comparison​

• Compared 90 scenarios between Rust and Haskell simulations at tag leios-2025w11
• Recent fixes and adjustments enabled meaningful comparison between simulations
• Identified issues requiring further investigation.

Analysis of mainnet-scale simulation​

• Completed the first analysis of Leios on a mainnet-scale network simulation using the Rust simulator
• Discovered that a 3,000-node mainnet-scale network transports IBs faster than an artificial 100-node network
• Identified 'shortcut' edges in larger networks as a likely factor in the improved transport speed.

Performance analysis of sharding​

• Created computational models to analyze the relationship between the fraction of shards without an IB and the expected number of extra IBs
• Evaluated performance characteristics of the simplest sharding scheme.

Haskell simulation​

• Fixed a bug in the relay protocol that prevented full diffusion of votes
• Adjusted the priority of certified EBs for inclusion in RBs
• Added support for an output log format that shares a common subset with the Rust simulator
• Analyzed TCP realism in comparison to idealized diffusion:
  • Discovered that higher IB rates and sizes improve diffusion times
  • Identified ledger state access as a significant source of latency.

Rust simulation​

• Expanded logs to include total IB size and parent ID of RBs
• Implemented the same EB selection strategy as in the Haskell simulation
• Added validation of IB headers before propagation to neighbors
• Investigating lower congestion in the Rust simulation compared to Haskell.

Formal methods​

• Developed the initial trace verifier for Short Leios simulation traces in leios-trace-verifier.

Research​

• Progressing on ledger design by exploring options and trade-offs
• Analyzing how concurrent input blocks in Leios create unique ledger-level challenges not present in Praos
• Evaluating approaches that balance multiple properties, including:
  • Conflict avoidance in the blockchain
  • Guaranteed fee payment for block producers
  • Transaction eligibility and inclusion speed
  • User experience regarding fee payment
• Investigating sharding-based solutions with various optimization strategies
• Planning to share more detailed findings at Leios public meeting by the end of March
• Targeting a comprehensive recommendation for implementors by the end of April.

From Short Leios to Full Leios​

• Planning the simulation roadmap for transitioning from Short Leios (currently implemented) to Full Leios
• Developing implementation guidelines for simulators to incorporate the pipeline referencing scheme specified in the papers
• Identifying key components needed to simulate the complete ledger inclusion guarantees of Full Leios.