40 posts tagged with "update"

This week, the Leios team achieved significant milestones in protocol development and analysis, successfully demonstrating high-throughput capabilities and exploring new protocol variants. The team completed comprehensive experiments with the Stracciatella variant, conducted analytical analysis of Linear Leios throughput efficiency, and implemented new simulation capabilities.

HIGH-THROUGHPUT DEMONSTRATION​

• Successfully completed experiments demonstrating 1,000+ TPS capability with the Stracciatella variant of Leios.
• Achieved spatial efficiency better than 95% with transaction lifecycle times under two minutes.
• Validated protocol performance under extreme throughput conditions significantly beyond current Cardano capacity.
• Documented detailed findings in the Stracciatella analysis notebook.

PROTOCOL VARIANTS ANALYSIS​

Stracciatella Variant​

• Completed comprehensive analysis of the Stracciatella variant (no IBs, transaction references in EBs, two-stage pipeline).
• Key findings:
  • 5 slot/stage performs less well but scales better than 8 slot/stage.
  • Only minimal fraction of transactions fail to reach ledger, likely due to EB expiration.
  • Network usage is slightly heavy while CPU usage appears suspiciously light.
  • Congestion appears at 1,000+ TPS throughput levels.

Linear Leios Throughput Efficiency​

• Conducted analytical analysis of Linear Leios variant's probability of including certified EBs on-chain.
• Results show Linear Leios could achieve approximately 500 times the throughput of Praos at over 50% network resource efficiency.
• 500 times Praos throughput would exceed 1,000 historically typical transactions per second.
• Generated comprehensive throughput and efficiency visualizations available in the analysis repository.

CDDL SPECIFICATIONS​

• Added CDDL specifications for Linear and Stracciatella protocol variants.

SIMULATION IMPROVEMENTS​

Rust Simulation​

• Implemented first pass at Linear Leios variant in Rust simulation.
• Enhanced simulation capabilities for protocol variant testing and analysis.
• Continued optimization of simulation performance for high-throughput scenarios.

Small Transaction Experiments​

• Completed analysis of small-transaction, high-throughput experiments with 300-byte non-Plutus transactions.
• Key findings:
  • 1,000 tx/s with 300 B/tx is feasible in Leios variants.
  • Clear time vs space tradeoff between variants.
  • full-with-ib-references uses space more efficiently than full-without-ibs.
  • full-without-ibs has shorter transaction lifecycle than full-with-ib-references.
  • 2 CPU cores are sufficient for high-throughput operation.
  • Network usage remains modest under high load.
• Supporting materials available in analysis documentation and analysis notebook.

NEXT STEPS​

• Continue investigation of protocol variants for CIP convergence.
• Expand simulation capabilities for additional protocol variants.
• Refine performance optimization strategies for high-throughput scenarios.
• Complete documentation of protocol variant comparisons and recommendations.

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 conducted comprehensive experiments examining protocol variants, conflict handling, and bandwidth requirements. The team also completed the analysis of nine candidate Leios variants with different sharding strategies, performed detailed conflict experiments at 100 TPS, and validated bandwidth requirements across multiple throughput scenarios.

Simulation analysis of protocol variants​

• Completed a comprehensive analysis of nine candidate variants of Leios, examining three basic variants and three sharding strategies:
  • Basic variants: Full, Full without IBs, Full with transaction references
  • Sharding strategies: unsharded, sharded, overcollateralized 1x
• Identified significant differences in spatial and temporal efficiencies across variants:
  • Full with transaction references achieved the highest spatial efficiency (95.999-96.466%)
  • Full without IBs demonstrated the fastest time to the ledger (43.052-43.057s)
  • Sharded variants generally showed improved spatial efficiency but increased latency
• Documented detailed findings in the analysis notebook.

Conflict experiments​

• Conducted experiments exploring the effect of conflicting transactions at 100 TPS using the simplest Leios variant
• Tested scenarios with 0%, 25%, and 50% of transactions conflicting with other transactions
• Key findings from the conflict analysis:
  • Spatial efficiency can be as low as 55% due to occasional IB production before the previous reception
  • All non-conflicted transactions reach the ledger within 75 seconds
  • NIC bandwidth of 20 Mb/s is sufficient for protocol operation
  • Four vCPU cores provide adequate processing capacity
  • Large IBs (up to 2 MB) diffuse globally within five seconds
  • IB traffic does not interfere with other protocol message types.

Bandwidth experiments​

• Completed experiments exploring bandwidth limitations at 100 TPS and 300 TPS documented in the bandwidth analysis
• Validated protocol parameters for high performance: mini-mainnet topology, 1-2 IB/s, 10 slot/stage, 328 kB/IB maximum, 1.5 EB/stage, and multiple shards
• Key performance findings:
  • Achieved 80% spatial efficiency across tested scenarios
  • All transactions reach the ledger within two minutes
  • 30 Mbps NIC bandwidth is sufficient for Leios node operation
  • Four-core vCPU provides adequate processing capacity
  • Insensitive results to inter-nodal link bandwidths above 50 Mb/s
  • Even 10 Mb/s links show minimal impact on protocol performance.

Rust simulation improvements​

• Added support for IB equivocation (work in progress, evaluating impact)
• Implemented minor usability improvements to the CLI tool
• Added sharding support to the 'full without IBs' variant of Leios.

CDDL Version 1​

• finalized and merged a first version of the CDDLs for the current variants in discussion for CIP, here in PR-396.

This week, the Leios team conducted extensive experiments using the previously developed network topologies to study transaction and input block throughput limits under realistic conditions. The team also conducted empirical bandwidth measurements between data centers, advanced formal methods capabilities, and created initial CDDL specifications for core Leios components.

CDDL specification draft​

• Created initial CDDL specifications for core Leios components:
  • Input blocks with VRF lottery and single IB/slot limits
  • Endorser blocks as a new aggregation block type
  • Ranking blocks as Conway extension with optional certificates
  • BLS voting system with persistent/non-persistent voters and key registration
• Followed crypto-benchmarks implementation approach while maintaining Conway CDDL compatibility
• Established foundational structures in the first draft covering common base components
• Future iterations will add detailed specifications for design variants, including full sharding, overcollateralization, and protocol extensions.

Formal methods​

• Added support for Late IB inclusion to the formal specification of Full-Short Leios
• Profiled leios-trace-verifier performance, identifying that approximately 60% of execution time is spent in garbage collection
• Improved performance significantly by switching to --nonmoving-gc garbage collection strategy.

Bandwidth measurements​

• Conducted empirical bandwidth measurements using iperf3 between data centers in North America and Europe
• Measured bidirectional connections across multiple cloud providers (OVH, AWS, CenturyLink)
• Results ranged from 95 Mbps to 973 Mbps, depending on geographic distance and the provider
• Identified 100 Mbps as a conservative lower bound for inter-datacenter connections
• Observed 5-20% reduction in individual link speeds when multiple simultaneous connections are active.

Large-scale network experiments​

• Conducted comprehensive experiments using both the 750-node and 10,000-node network topologies with Haskell and Rust simulations
• Studied transaction and IB throughput limits for realistic scenarios up to 300 TPS and 32 IB/s
• Key findings from the 750-node mini-mainnet experiments are documented in analysis results and summary slides:
  • The 750-node mini-mainnet serves as a suitable replacement for the 10,000-node pseudo mainnet for performance measurements
  • Substantial agreement between Haskell and Rust simulations for mini-mainnet scenarios
  • Block propagation times under one second, consistent with empirical observations from pooltool.io
  • Protocol can support 25 MB/s throughput with 1 Gb/s links before degradation
  • Mean transaction time from mempool to ledger is approximately 150 seconds
  • Achieved 80% disk-space efficiency with ~20% network traffic overhead
  • Six-core VM is sufficient for peak demand at 300 TPS, with average demand under two cores
• Results from 10,000-node pseudo-mainnet experiments are available in analysis documentation and presentation slides:
  • Average transaction lifecycle of 100 seconds from mempool to ledger
  • Approximately 80% efficiency for both disk and network usage
  • Six CPU cores are sufficient for peak load handling even at high TPS rates
  • Block propagation time averaged under one second across the large network.

This week, the Leios team focused on improving simulation analysis tools and creating more practical network topologies. Key achievements include enhancing the trace processor with additional data extraction capabilities and developing a smaller, more efficient 'miniature mainnet' topology for repeated experimentation.

Trace processor enhancements​

• Enhanced the leios-trace-processor to extract CPU, resource, and message-receipt data from simulation trace files
• Eliminated the need for using older, lower-performance scripts for analyzing simulation results
• Added comprehensive data output options:
  • Transaction lifecycle data
  • CPU utilization metrics
  • Resource consumption data
  • Message receipt tracking
• Improved analysis efficiency for large simulation datasets.

Miniature mainnet topology​

• Created a more practical 750-node topology that faithfully mimics mainnet characteristics while addressing performance limitations of the 10,000-node pseudo-mainnet
• Achieved a network diameter, stake distribution, and edge degree closely matching those of the mainnet
• Key network metrics:
  • 216 block producers and 534 relay nodes
  • 19,314 total connections with 5-hop network diameter
  • Average of 25.75 connections per node
  • Clustering coefficient of 0.332
  • Average latency of 64.8ms with maximum of 578.3ms
  • 84.85% asymmetry ratio
• Documented the methodology and results in topology-v2.ipynb
• Deployed the network configuration in topology-v2.yaml
• Enabled more practical, repeatable experimentation with realistic network 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.