Skip to main content

2 posts tagged with "workshop"

View All Tags

Weekly Summary – April 7, 2025

· 3 min read
William Wolff
Architect

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.

Weekly Summary – March 31, 2025

· 3 min read
William Wolff
Architect

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.

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