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.

[Saizan]

Any IBs not endorsed appear to be from pipelines without an EB. So that part seems to work as expected.

According to the sortition spec, if we weren't forcing at most 1 EB per node, we should expect the number of EBs to be Poisson distributed with \lambda equal to eb-generation-probability. For 1.5 we would have the following PMF

What we are actually doing each pipeline is to take the sum of 100 samples of a poisson distribution with \lambda 1.5e-2, but each sample capped at 1. Anyhow, within 150 slots we are doing this only about 5 times, so things seem quite within variance.
(Note that the distribution of IBs in EBs is not quite the same: it's skewed by variance in IB generation and by the pipelines that have gone through Propose stage but not yet Endorse, inflating the count for 0 EBs above 1 EBs).

Finally it can look suspicious that all the runs have the same gap. However, because they all have the same stage length and rb-generation-probability, we are actually doing the same number of PRNG samplings and in the same order, so consistency is expected (what changes is only how many IBs you are granted for the same sampled value). One would really need to do runs with different seeds to see more variation.

Rather than more runs we can directly do the sampling described above. Doing 10000 iterations gives this distribution, which should be what we expect to see in the long run with eb-gen-probability=1.5

[Saizan]

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.

The distribution for the above looks pretty close to Haskell's