Testing environment to mimic main-net Mithril verification behaviour

[iquerejeta]

Why

Having such a testing environment would provide us with a benchmark environment mimicking the usage of Mithril in main-net without the need of having it running there. This would allow us to measure, realistically, how much a client will take to bootstrap a node using Mithril on main-net. The goal of such a benchmark is not to discover possible regressions, but rather imitate a main-net run using an identical environment (identical to the client, not the signers/aggregator). This environment would give us concrete numbers of the size of Mithril certificates/chain that we could only estimate in its absence.

How

The idea is to mimic main-net behaviour in a closed environment without the need of having a high percentage of SPOs produce Mithril signatures. To have realistic numbers, we need the following:

1. Node snapshot
2. Realistic stake distribution
3. Realistic parameters
4. Realistic (fake) signers
5. Sufficiently long chain of certificates

Node snapshot and stake distribution

These are the easiest goals of all. We can directly get the snapshot from a full node running on main-net. This will represent precisely what would need to be downloaded by Mithril clients running on main-net. Similarly, for the stake distribution, we can use the current stake distribution, which will result in a realistic number of individual signatures in the Mithril certificate.

Realistic parameters

To provide with an upper bound, the most reasonable decision for the Mithril parameters are those providing a higher level of security, in particular:

StmParameters {
    m: 2422,
    k: 20973,
    phi_f: 0.2,
}

However, the testing environment can be sufficiently flexible for us to test different sets of parameters

Realistic (fake) signers

To benchmark a realistic node bootstrap, we do not need to have realistic signers. To that end we would generate all signatures in the test script, without the need of running actual signers, nor handling the communication layer. We would assign them a stake corresponding to a real SPO, so their 'chances' of winning several indices of the lottery is similar to what we would get in main-net. Then, the corresponding signatures would be aggregated into a single Mithril certificate, making the latter equivalent to a 'main-net' Mithril certificate.

Sufficiently long chain of certificates

Again, this value can be parametrisable, but we can initially aim to create a certificate chain mimicking one year of Mithril. The longer Mithril runs for, the longer the chain of certificates is. However, the size of certificates (and the time spend verifying them) is negligible wrt to downloading the snapshot and recovering the node from it.

Making it transparent for the client

The goal of this environment is that a mithril-client will have the exact same interaction as it would with main-net. That is the reason we want to make it private initially, to guarantee it is only used for testing. The catch of how we can manage to mimic main-net without having SPOs participating, is that we will 'fake' the Genesis Certificate. 'Faking', here simply means that we will use a different key, which the clients will consider valid.

The overview of series of events to create such an environment would be:

1. Get the snapshot of the node, compress it, and compute its hash snp
2. Get the current stake distribution of Cardano. Let k be the number of currently registered SPOs in Cardano, with stake stake_i
3. Spin k new signers, each with stake stake_i, for i \in [1, k]
4. Run a central aggregator (as it is now in the testing environment), and register all signers. This will provide the avk. For sake of simplicity, we can use the same avk throughout the whole chain[^1]
5. Every signer tries to produce N signatures for msg = (avk, snp). N is the number of mithril certificates in one year. If we have one necessary certificate per epoch, one epoch lasts 5 days, then N = 365 / 5 = 73

Having the above, a client can bootstrap a full main-net node using Mithril following the exact same steps as it would do in the real system.

[^1]: While this does not represent reality, as the avk should be dynamic, it does gives us a reasonable stake distribution to base our benchmarks on.

[abailly-iohk]

I am not too sure about the Why? Could you elaborate on what would be the output of this benchmark? What do we want to measure? Would this be run on, say. every merge on master to keep historical data? Is the goal to track performance improvements/degradations? What would we know from running this benchmark we don't or cannot know running smaller scoped tests?