26 posts tagged with "rust-simulation"

This week, the Leios team conducted comprehensive attack parameter analysis, released updated simulation tools, and performed detailed analysis of Cardano mainnet validation performance. The team successfully characterized the effectiveness of late-release attacks across different parameter ranges and established baseline performance metrics for ledger operations critical to proposed Leios implementation.

Attack analysis and parameter optimization​

Parameter-sweep experiment for late-EB attacks​

The team conducted a comprehensive parameter-sweep experiment to determine optimal adversarial strategies for late Endorser Block (EB) attacks. The experiment systematically varied EB delay timing from six to eight seconds with adversaries controlling 33% of stake, examining both diffusion parameter configurations (L_diff on/off) under the txs-received propagation scheme.

Critical findings from the parameter sweep analysis demonstrate that efficiency degradation begins when EBs and transactions are delayed 6.5 seconds, with minimal additional impact beyond 7-second delays. The analysis revealed that L_diff = 0s configurations perform better than L_diff = 7s under adversarial conditions. Importantly, none of the tested scenarios using txs-received propagation resulted in transaction loss or protocol breakdown, indicating robust behavior under these attack conditions.

Simulation infrastructure improvements​

Rust simulation releases​

The team released versions 1.1.0 and 1.2.0 of the Rust simulation infrastructure, incorporating updated transaction validation CPU models that improve accuracy of performance predictions. These releases enhance the fidelity of proposed Leios simulations and provide more reliable computational cost estimates for protocol analysis.

Regression analysis framework​

The team implemented a comprehensive regression analysis framework comparing behavior across all tagged versions of the Rust simulator sim-cli. This systematic approach enables rapid detection of behavioral changes in the simulator across development iterations, ensuring consistency and reliability in experimental results.

Mainnet performance analysis​

Cardano mainnet validation timing analysis​

The team extended the analysis of ledger operations with comprehensive linear statistical models predicting Apply and Reapply phases of ledger updates. These regressions provide crucial input for proposed Leios performance studies, particularly scenarios involving higher Plutus execution limits.

Empty block diffusion analysis​

The team completed analysis of empty block diffusion on Cardano mainnet using data from pooltool.io. This analysis establishes empirical estimates for the Δ_hdr parameter required by the proposed Leios protocol. The findings demonstrate that 94.0% of empty Praos blocks arrive at nodes within one second of their slot start time, providing critical timing constraints for protocol parameter selection.

Next steps​

• Continue refinement of attack resistance analysis based on parameter sweep findings
• Integrate updated CPU models into comprehensive protocol performance evaluations
• Extend mainnet analysis to inform proposed Leios parameter optimization
• Prepare comprehensive attack analysis documentation for CIP inclusion.

This week, the Leios team advanced the Cardano Improvement Proposal (CIP) documentation, conducted comprehensive attack analysis experiments, and continued cross-validation between simulation implementations. The team successfully demonstrated resilience characteristics of proposed Leios under adversarial conditions and refined protocol specification components for the formal CIP submission.

CIP development progress​

The team made substantial progress on the Ouroboros Leios CIP proposal. The draft specification section is now complete except for the network and incentives components. The motivation and abstract sections have been refined for clarity, enhancing the document's accessibility and technical precision. The first of four main rationale subsections has been fully drafted, providing evidence-based arguments for the necessity and viability of the proposed Leios protocol enhancement.

Attack resistance analysis​

Initial adversarial simulation experiments​

The team conducted the first simulation experiment for attacks, examining late Endorser Block (EB) and transaction diffusion scenarios where adversaries control timing of critical protocol messages. The experiment varied the diffusion parameter L_diff and EB propagation schemes to assess protocol robustness under different adversarial strategies.

Key findings from the initial attack analysis include successful demonstration that late-release attacks can impact proposed Leios throughput under specific conditions. The analysis revealed that transaction loss occurred in some scenarios due to memory pool rule formulations in the simulator, leading to important insights for protocol hardening and implementation requirements.

Cross-simulation validation​

Haskell versus Rust comparison​

The team completed another comprehensive comparison between Haskell and Rust simulation implementations at analysis/sims/202532b. Results indicate successful resolution of previous discrepancies in vote diffusion behavior between the two simulation environments. This validation ensures both implementations produce consistent results for protocol analysis and strengthens confidence in the simulation-based evidence supporting the CIP.

CIP figure preparation​

The experiment for draft figures for CIP progressed with updated simulation runs designed to generate publication-quality performance charts and protocol behavior visualizations for inclusion in the formal CIP documentation.

Next steps​

• Complete the remaining network and incentives sections of the CIP specification
• Conduct follow-up analysis on attack experiment findings to refine protocol parameters
• Continue refinement of memory pool rules based on adversarial scenario insights
• Finalize CIP figures and supporting analysis for submission preparation.

This week, the Leios team made significant progress on the Cardano Improvement Proposal (CIP) documentation, conducted extensive Plutus validation experiments, and resolved outstanding discrepancies between simulation implementations. The team successfully demonstrated Linear Leios performance under various Plutus workloads and completed comprehensive protocol parameter analysis for CIP inclusion.

CIP development progress​

The team completed substantial portions of the Leios CIP draft, bringing it closer to submission readiness. The specification section is now complete except for network and incentives components, with the motivation and abstract refined for clarity. The first of four main rationale subsections has been fully drafted, providing evidence-based arguments for Leios necessity and viability.

Plutus validation experiments​

The team conducted comprehensive experiments examining Linear Leios performance under varying Plutus computation loads using 6-vCPU nodes at 100 TPS. Key findings from the Plutus validation analysis include:

• Linear Leios successfully supported doubling the Plutus per-transaction budget
• Protocol breakdown occurred at sixfold increases in Plutus budgets due to validation bottlenecks
• Endorser blocks could handle approximately 5,000 execution steps of Plutus computation, representing 250 times the current Praos per-block budget
• This capacity could support either a handful of transactions with 20x greater Plutus budgets or increasing every Plutus transaction budget by 50%
• Late diffusion of Plutus-heavy transactions poses potential risks to EB adoption timing.

The analysis revealed significant variability in CPU time requirements for Plutus scripts relative to their execution steps, highlighting the need for careful resource planning in high-throughput scenarios.

Simulation improvements and comparisons​

Cross-simulation validation​

The team completed another comprehensive comparison between Haskell and Rust simulations at analysis/sims/202532b, successfully resolving previous discrepancies in vote diffusion behavior. This validation ensures both simulation implementations produce consistent results for protocol analysis.

Protocol parameter optimization​

The 2025w32 experiment established a comprehensive set of protocol parameters and throughput scenarios for inclusion in the CIP Evidence section:

• Protocol variant: Linear Leios with conservative resource allocation
• Resource requirements: 4 vCPU per node, 10 Mb/s bandwidth
• Stage configuration: 7 slots each for voting and diffusion stages
• Block limits: Maximum 12 MB transaction references per EB
• Transaction size: 1,500 bytes per transaction with normal Plutus frequency

Key performance findings demonstrate that modest computational resources adequately support throughput up to 0.3 TxMB/s, with 7-slot stages providing sufficient diffusion time while minimizing EB discard probability. The 12 MB EB limit allows occasional peak utilization to compensate for unlucky sortition periods.

Implementation enhancements​

Haskell simulation​

The team addressed head-of-line blocking issues in Linear Leios by implementing message slicing capabilities in the mini-protocol multiplexer, eliminating unexpected delays in vote diffusion. Additional work focused on developing new mini-protocols for enhanced Linear Leios simulation fidelity, with ongoing refinements to balance protocol granularity and sophistication.

Rust simulation​

Implementation of transaction withholding attack scenarios for Linear Leios, where EB producers delay transaction publication until EB release. The simulation also received updates to improve handling of late transactions, EBs, and RBs in Linear Leios scenarios.

Next steps​

• Complete remaining network and incentives sections of the CIP specification
• Finalize mini-protocol designs for enhanced simulation accuracy
• Continue investigation of mempool rule adequacy for high-throughput scenarios
• Expand Plutus validation analysis to cover additional execution budget scenarios.

This week, the Leios team focused on comparative analysis between simulation implementations and conducted experiments examining the impact of protocol parameters and network topology on Linear Leios performance. The team made progress in cross-validation between Haskell and Rust simulations while investigating protocol behavior under different network conditions.

Cross-simulation analysis​

Haskell vs Rust Linear Leios comparison​

The team completed a comprehensive comparison between the early draft Haskell simulator and the more mature Rust simulator for Linear Leios. Key findings from the analysis documented in analysis/sims/2025w31b/analysis.ipynb revealed several discrepancies requiring investigation:

• CPU usage patterns differed between implementations
• Network usage showed variations across simulators
• Vote diffusion behavior exhibited inconsistencies
• Active investigation underway to resolve implementation differences.

Protocol parameter experiments​

Stage length analysis for "No IBs" Leios​

The team conducted experiments varying the stage-length protocol parameter from 5 to 12 slots per stage in "No IBs" Leios. Results documented in analysis/sims/2025w31/analysis.ipynb showed:

• Settlement time remains relatively stable across the tested parameter range
• Stage length has minimal impact on transaction processing times within 5-12 slot range
• Larger stage lengths result in less frequent voting periods
• Protocol performance appears robust to moderate stage length variations.

Network topology validation​

Mini-mainnet vs pseudo-mainnet comparison​

The team completed a comparative analysis of Linear Leios performance across different network topologies using the Rust simulator. Key findings from analysis/sims/2025w30b/analysis.ipynb include:

• The 750-node mini-mainnet network proved slightly more stressful to the protocol than the 10,000-node pseudo-mainnet
• No substantial differences in simulation results between the two network configurations
• Both networks produce equivalent findings and conclusions for protocol analysis
• Validation confirms the mini-mainnet topology as a suitable proxy for larger-scale analysis.

Rust simulation enhancements​

Linear Leios attack modeling​

• Added equivocation voting delay functionality to Linear Leios implementation
• Implemented attack scenario modeling where endorser block (EB) diffusion is deliberately delayed until the last moment
• Enhanced simulation capabilities for security analysis and adversarial behavior testing.

Next steps​

• Continue investigation of discrepancies between Haskell and Rust Linear Leios implementations
• Expand parameter sensitivity analysis for additional protocol variants
• Refine attack modeling capabilities for comprehensive security assessment
• Apply lessons from network topology comparison to future experimental design.

This week, the Leios team achieved a significant milestone by successfully demonstrating protocol viability at 1,000 TPS. They also completed a comprehensive attack surface analysis and made substantial improvements to simulation and verification tools.

High-throughput demonstration​

• Successfully completed a 1,000 TPS experiment using basic 300-byte non-Plutus transactions
• Demonstrated the viability of Leios protocol operation at extremely high throughput levels
• Validated protocol performance under stress conditions significantly beyond current Cardano capacity
• Documented detailed findings in the 1,000 TPS analysis.

Security analysis​

• Completed a comprehensive attack surface analysis for the second technical report
• Defined terminology and taxonomy for potential Leios attack vectors
• Categorized major attack types and their potential impacts on protocol security
• Enhanced understanding of protocol vulnerabilities and mitigation strategies.

Rust simulation enhancements​

• Finished implementing support for input block (IB) equivocations in the simulation
• Added capability to model and analyze protocol behavior under adversarial conditions
• Enhanced simulation fidelity for security-related protocol testing.

Trace verifier performance optimization​

• Achieved 3x performance improvement by configuring minimum heap size to 1GB
• Reduced garbage collection overhead from 75% to 2% of execution time
• Enhanced profiling capabilities with detailed performance analysis tools
• Improved verification efficiency for large-scale simulation trace analysis.

Protocol convergence for CIP​

• Intensified efforts to converge on a specific Leios variant for the Cardano Improvement Proposal (CIP)
• Applied systematic evaluation methodology to rank protocol candidates from multiple angles
• Evaluated efficiency metrics, including temporal efficiency versus storage optimization trade-offs
• Assessed attack surface and security vectors across different protocol variants
• Analyzed utility factors, including quality of service, developer friendliness, user experience, and downstream ecosystem impacts
• Focused on eliminating candidates through evidence-based assessment of valuable protocol characteristics.

This week, the Leios team focused on infrastructure improvements, formal methods advancement, and large-scale network simulation. The team successfully resolved outstanding CI issues, enhanced the formal specification with Full-Short Leios support, and began simulating a realistic 10,000-node pseudo-mainnet topology.

Infrastructure improvements​

• Fixed outstanding CI bugs #368 and #379, enabling all CI checks to pass.

Formal methods advancement​

• Added Full-Short Leios as a special case of Short Leios to the formal specification
• Implemented trace verification capabilities for Full-Short Leios.

Pseudo-mainnet topology simulation​

• Designed and initiated comprehensive simulations from 1 to 300 TPS using the new pseudo-mainnet topology
• Created a realistic 10,000-node network with:
  • 2,657 block producers and 7,343 relay nodes
  • Realistic stake distribution and geographic distribution
  • Two relays per block producer with realistic latencies
  • 298,756 total connections with 6-hop network diameter
• Observed significant performance challenges within the large-scale simulation:
  • Rust simulation: six minutes of network time in 10 hours at one TPS
  • Performance degradation at higher TPS rates (one minute network time in 10 hours at 300 TPS)
  • Haskell simulation requires optimization for practical large-network analysis.

Rust simulation enhancements​

• Implemented random sampling of transactions from the Leios memory pool to ensure different IBs contain different transactions when possible
• Added simulation support for the Leios variant, where IBs contain transaction references rather than full transaction bodies
• Enhanced transaction handling for high-traffic scenarios.

Analysis of conflicts and incentives​

• Completed comprehensive analysis of transaction conflicts, ledger design, and fee incentives
• Key findings on conflict management:
  • Honest duplicates and conflicts are unavoidable with local sortition
  • Memory pool rules can minimize conflicts through prompt transaction removal
  • Collateral requirements for failed transactions conflict with Cardano's guarantees
• Identified block producer compensation strategies for handling conflicting transactions
• Proposed EB-level optimization through bitmap-based transaction validation to reduce persistent storage of duplicates and conflicts.

The Leios team completed a significant analysis of overcollateralization schemes and continued advancing the Rust simulation infrastructure. They also focused on understanding transaction duplication and conflict probabilities in shardless scenarios while enhancing simulation tooling to better track transaction lifecycle events.

Overcollateralization analysis​

• Completed comprehensive analysis of shardless overcollateralization, where transactions are randomly sampled from the memory pool
• Found that probabilities of duplication and conflicts are minimized when the concurrency period is as short as possible
• Determined that conflict probability is always greater than duplication probability
• Identified that longer transaction residence times correspond to lower probabilities of duplication or conflict, where transaction residency time is defined as the average time a transaction stays in the memory pool before reaching an IB (calculated as memory pool size divided by transaction throughput)
• Discovered that spatial efficiency is greater for longer residence times
• Found that the tradeoff between probabilities of duplication and conflict is insensitive to protocol parameters
• Showed that the expected number of conflicts in IBs scales proportionately with the fraction of conflicting transactions and transaction throughput
• Identified that, at a given throughput, reducing the probability of duplicates or conflicts can be at odds with minimizing the total number of conflicts
• Found that probabilistic computation of conflicts is about 20% lower than naive estimates
• Determined that at 100 TPS with favorable protocol parameters, an overcollateralization factor of nearly 400x is necessary in adversarial scenarios where the memory pool is filled with conflicting transactions
• Concluded that having successful transactions pay for all conflicting ones is too risky due to potential attacks on honest transactions using common UTXO inputs
• Identified that consuming collateral from conflicted transactions in IBs is more viable, though it breaks existing UX guarantees
• Noted ongoing discussions about the realism of creating 400 mutually conflicting transactions, given that individual mempools would not include conflicting transactions, and attack scenarios would require coordination across multiple nodes
• Documented detailed findings in the overcollateralization analysis notebook.

Simulation development​

Transaction lifecycle analysis​

• Analyzed protocol performance across transaction throughput scenarios up to 300 TPS
• Found that the protocol performs well with essentially every transaction reaching the ledger up to 300 TPS, where breakdown occurs
• Noted that the 100-node network is more stressful than a realistic mainnet would be
• Achieved space efficiency above 80% for moderate-throughput scenarios
• Measured average transaction latency of about 100 seconds (95th percentile at 200 seconds) to reach the ledger.

Rust simulation improvements​

• Added 'TXLost' events to the simulation output to detect transaction loss scenarios
• Enhanced the ability to track where Leios can lose transactions with various parameter choices.

Data processing optimization​

• Developed a new leios-trace-processor tool to replace script-based analyses
• Achieved significantly faster processing of simulation results compared to previous scripts
• Enabled analysis of much longer and larger simulation datasets
• Created standardized CSV output format for transaction lifecycle data, including creation, IB inclusion, EB inclusion, and RB inclusion timestamps.

This week, the Leios team focused on improving simulation capabilities, enhancing transaction processing, and expanding the test coverage. The team also made significant progress in addressing transaction inclusion rates and developing a comprehensive conformance testing framework.

Simulation improvements​

Rust simulation​

• Investigated and addressed poor transaction inclusion rates
• Implemented 'late IB inclusion' extension to Full Leios, significantly improving transaction ledger inclusion odds
• Identified and addressed issues with non-sharded input transactions causing excessive duplication
• Made several key enhancements:
  • Enabled late IB inclusion by default
  • Fixed the off-by-one error in late IB inclusion logic
  • Added praos-fallback-enabled setting for throughput investigation
  • Improved transaction deduplication in Praos blocks.

Testing framework​

Conformance testing​

• Developed a comprehensive catalog of potential conformance tests
• Implemented a property-based testing suite for trace verification
• Added both positive and negative test cases covering:
  • Genesis slot operations
  • Block production (RB, IB, EB)
  • Vote generation
  • Various production patterns (sporadic, noisy)
  • Invalid scenarios (equivocation, gaps)
• Successfully verified golden traces against the Agda specification.

Documentation​

Formal specification​

• Launched comprehensive web-based documentation for the Ouroboros Leios formal specification at leios.cardano-scaling.org/formal-spec
• Enhanced documentation features:
  • Interactive exploration of Leios modules
  • Type linking between related components
  • Full text search capabilities
  • Improved accessibility of formal specification details.

Transaction lifecycle analysis​

• Conducted detailed analysis of transaction processing efficiency
• Generated a cumulative probability model for transaction ledger inclusion
• Analyzed the relationship between IB production rate and stage length
• Created visualization of transaction-to-block inclusion probabilities.

Next steps​

• Continue monitoring and optimizing transaction inclusion rates
• Expand conformance test coverage as the Agda specification evolves
• Further investigate transaction sharding strategies
• Refine transaction lifecycle model based on simulation results.

This week, the team made significant progress on simulation improvements, trace verification, and a 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 a 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 adding 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 its statistics, organization, code quality, design, implementation, and documentation aspects.

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 ran higher excess-capacity simulations to test hypotheses about transaction inclusion. The transaction lifecycle simulations raised the question of whether duplicated transactions in IBs were preventing other transactions from ever being included. The team ran simulations with IBs produced at three times the normal rate to test this, 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.