Skip to main content

4 posts tagged with "transaction-lifecycle"

View All Tags

Weekly Summary – May 26, 2025

· 3 min read
William Wolff
Architect

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.

Weekly Summary – May 19, 2025

· 2 min read
William Wolff
Architect

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.

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.

Weekly Summary – April 28, 2025

· 2 min read
William Wolff
Architect

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.

Weekly Summary – April 14, 2025

· 3 min read
William Wolff
Architect

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.