Haskell tends to include IBs in more EBs than does Rust

[bwbush]

Observation

• The Haskell simulation typically references each IB in zero or three EBs.
• The Rust simulation typically references each IB in fewer than three EBs.
• Is the cause of this different worth tracking down?

Evidence

Context

• Tag: leios-2025w11
• Network topo-default-100
• Base configuration: config.default.yaml
• Variation on base configuration:

  ouroboros-leios/analysis/sims/2025w11/run-experiment.sh

  Lines 78 to 80 in f78f1dc

  	STAGE_LENGTHS="20 40 60"
  	IB_RATES="0.1 0.3 1.0 3.0 10.0 30.0"
  	IB_SIZES="32768 65536 98304 131072 163840"

[Saizan]

My guess would be that each generated EB references most IBs, so the difference is probably about minor differences in the implementation of sortition.

@bwbush would it be easy to show data about number of generated EBs per pipeline?

[bwbush]

would it be easy to show data about number of generated EBs per pipeline?

Yes, and I was planning to do checks today that EBs only reference IBs from their own pipeline.

[SupernaviX]

For each node, the rust simulation runs a VRF lottery by

• sampling a random number in 0..total_stake
• checking if the random number is less than stake * success_rate

The default config has an EB generation rate of 1.5, so rust is running this lottery once with a success rate of 1.0 and once with a success rate of 0.5. If either run wins, the node generates a single EB.

[Saizan]

We try to match voter_check in crypto-benchmarks.rs more directly, precomputing the thresholds for the different number of "wins" given a double sampled between 0 and 1.

For EBs then we additionally cap them to max 1 per node.

[bwbush]

Here are the results at tag leios-2025w12, which subjectively seem in closer agreement, but still have deviations.