How the Pareto calculation works

1. The core idea

Each simulation run becomes a point within a cube defined by three axes — decentralization (degree of decentralization, DoD), security, and scalability.

A run $X$ is Pareto-optimal if there is no other run $Y$ that dominates $X$, i.e. that is at least as good across all three axes and strictly better on at least one of them.

Since, according to the blockchain trilemma, it is impossible to maximize all three goals simultaneously, trade-offs must be made. Consequently, there is usually no single best solution, but rather several equally valid compromises — and these are precisely what we are looking for. The group of those Pareto-optimal runs is called the Pareto front.

2. How it is done

Imagine a cube whose edges range from $0$ to $1$: $[0,1]^3$.

• Right (axis $x$) = greater decentralization
• Back (axis $y$) = greater security
• Top (axis $z$) = greater scalability

A run with the values $(x, y, z) = (0.9, 0.2, 0.5)$ is therefore highly decentralized, not very secure, and moderately scalable. For every axis, the following applies uniformly: higher = better.

The task is simple: How do we get from the many raw numbers of a simulation to these three clean values between $0$ and $1$? These are the next four steps.

Step 1 – Collect the raw values

Each run provides many individual measurements (metrics), e.g.:

Metric	Meaning	Belongs to axis	Good is …
ShannonEntropy	Dispersion of block production	Decentralization	high
GiniCoefficient	Inequality of distribution	Decentralization	low
Reliability	Reliability	Security	high
TransactionThroughput	Transactions per minute	Scalability	high

(The complete mapping is located in TrilemmaMetricRegistry in .core.analysis.)

We simply read out these numbers for each run.

Step 2 – Normalize the values

The problem: The metrics have completely different units and orders of magnitude. TransactionThroughput might be $300$, whereas the GiniCoefficient ranges between $0$ and $1$. You cannot combine them directly — the large number would completely dominate the others.

The solution: We convert each metric to a common scale from $0$ to $1$. This is known as min-max normalization. For a given value $v$ of a metric, we look at the minimum value ($\min$) and the maximum value ($\max$) of that metric across all runs in the group and calculate:

$$n = \frac{v - \min}{\max - \min}$$

• The worst run for a metric thus receives $n = 0$.
• The best receives $n = 1$.
• All others fall in between.

Aligning direction: For some metrics, a lower value is better (e.g., GiniCoefficient). To ensure that “higher = better” applies across the board, we simply invert such values:

$$n_{\text{inverted}} = 1 - n$$

Example

Gini values for the runs are $0.2$, $0.4$, and $0.6$. For $v = 0.2$, $n = \frac{0.2 - 0.2}{0.6 - 0.2} = 0$. Since lower is better, we invert the value: $1 - 0 = 1$. Thus, the run with the lowest Gini receives the best score, $1$. That works.

Step 3 – Aggregate by axis (mean value)

An axis (e.g., decentralization) is often derived from multiple metrics. We simply calculate the average of the normalized values for that axis. Which metrics take part can be chosen per analysis — see choosing which metrics count.

If an axis has $k$ metrics with the normalized values $n_1, n_2, \dots, n_k$, the axis score is:

$$\text{Score}_{\text{axis}} = \frac{n_1 + n_2 + \dots + n_k}{k}$$

Each run thus has exactly three numbers: its point $(x, y, z)$ within the cube.

Step 4 – Dominance and the Pareto front

Now we compare the points with each other.

Dominance. A run $A$ dominates a run $B$ if $A$ is at least as good on all three axes and strictly better on at least one. Formally, with the points $A = (a_1, a_2, a_3)$ and $B = (b_1, b_2, b_3)$:

$$A \text{ dominates } B \quad\Longleftrightarrow\quad \big(\forall i:\ a_i \ge b_i\big)\ \ \text{and}\ \ \big(\exists j:\ a_j > b_j\big)$$

In words: $A$ is nowhere worse and strictly better in at least one respect. In this case, $B$ is clearly inferior — after all, there is an alternative that is better in every regard.

Pareto-optimal. A run is Pareto-optimal if no other run dominates it. The set of all Pareto-optimal runs is called the Pareto front. This front typically comprises multiple runs — representing the various “best compromises,” all of which are equally valid.

3. A fully worked-out example

Four runs, four raw metrics:

Run	ShannonEntropy	GiniCoefficient	Reliability	Throughput
A	4	0.2	0.9	100
B	2	0.6	0.5	300
C	3	0.4	0.7	200
D	2	0.6	0.5	100

Normalization (Step 2)

Min/max per metric across all four runs: Shannon $[2, 4]$, Gini $[0.2, 0.6]$, Reliability $[0.5, 0.9]$, Throughput $[100, 300]$.

Run	Shannon (high=good)	Gini (low=good → inverted)	Reliability	Throughput
A	$\frac{4-2}{2}=1.0$	$1-\frac{0.2-0.2}{0.4}=1.0$	$\frac{0.9-0.5}{0.4}=1.0$	$\frac{100-100}{200}=0.0$
B	$\frac{2-2}{2}=0.0$	$1-\frac{0.6-0.2}{0.4}=0.0$	$\frac{0.5-0.5}{0.4}=0.0$	$\frac{300-100}{200}=1.0$
C	$0.5$	$0.5$	$0.5$	$0.5$
D	$0.0$	$0.0$	$0.0$	$0.0$

Average per axis (Step 3)

Decentralization = Mean of Shannon and Gini. Security = Reliability. Scalability = Throughput. This yields the points in the cube:

Run	Decentralization	Security	Scalability	Point $(x,y,z)$
A	$\frac{1.0+1.0}{2}=1.0$	$1.0$	$0.0$	$(1.0,\ 1.0,\ 0.0)$
B	$\frac{0.0+0.0}{2}=0.0$	$0.0$	$1.0$	$(0.0,\ 0.0,\ 1.0)$
C	$\frac{0.5+0.5}{2}=0.5$	$0.5$	$0.5$	$(0.5,\ 0.5,\ 0.5)$
D	$\frac{0.0+0.0}{2}=0.0$	$0.0$	$0.0$	$(0.0,\ 0.0,\ 0.0)$

Check for dominance (Step 4)

• D $=(0,0,0)$: C is $\ge$ everywhere and strictly better on every axis → C dominates D. (A and B also dominate D.) → D is not Pareto optimal.
• A $=(1,1,0)$: No other option is at least as good across the board. B has lower $x,y$; C has lower $x,y$. → A is Pareto optimal.
• B $=(0,0,1)$: B is the only one with $z=1$; no other option matches this while keeping the other values the same. → B is Pareto optimal.
• C $=(0.5, 0.5, 0.5)$: While A has higher $x,y$, it has lower $z$ ($0 < 0.5$), so it is not $\ge$ everywhere. The same applies to B. → C is Pareto optimal.

Result – the Pareto frontier: $\{A, B, C\}$. Only D is excluded because there is an alternative (C) that is better in every respect.

It is interesting to note: A, B, and C represent three distinct trade-offs (A prioritizes decentralization and security, B prioritizes scalability, and C is balanced) — and all three are valid “winners.” This is precisely the point of the trilemma.

4. Choosing which metrics count

By default every registered metric contributes to its axis. A research question rarely needs all of them, though — so the analysis accepts a selection: one list of metric names per axis, and only those are aggregated in Step 3.

The metric registry is the single source of truth for what exists. It maps every raw simulator metric to its axis and its direction (higher or lower is better), and the front end builds its selection UI from that list rather than hardcoding names:

List<MetricContribution> available = bench.availableParetoMetrics();

List<ParetoPoint> points = bench.paretoAnalysis(runs, new ParetoSelection(
        List.of("ShannonEntropy", "GiniCoefficient"),   // decentralization
        List.of("AvailabilitySecurity"),                // security
        List.of("TransactionThroughput")));             // scalability

Three properties are worth knowing:

Selections are validated, not silently ignored. An unknown metric name, a metric listed under the wrong axis, or the same metric twice (which would double its weight in the mean) is rejected with an IllegalArgumentException. A typo fails loudly instead of quietly changing the front.

An empty list ignores that axis. Every run then scores a constant $0.0$ on it, so all points come to lie on that face of the cube. Because the value is identical for all runs, it has no influence on dominance — the analysis effectively becomes two-dimensional while the view stays a cube. This is distinct from the neutral $0.5$ described below, which means “metric selected but not present in this run’s data”.

The analysis is stateless. Nothing is cached between calls, so several analyses with different selections over the same group are simply several calls, and they can be shown side by side. Calling the analysis without a selection keeps the previous behaviour and considers every registered metric.

5. Three nuances

Constant metric → neutral value of $0.5$. If all runs have the same value for a given metric, then $\max - \min = 0$, and the formula would involve division by zero. In this case, the metric provides no basis for differentiation, so we assign it the neutral value of $0.5$. Since this applies to all runs equally, it does not alter the ranking (dominance). An axis for which a run has no metric value at all is assigned this same value.

Everything is group-relative. The values ranging from $0$ to $1$ are derived from comparisons within a group (the $\min$ and $\max$ are drawn from that specific group). Thus, a point $(0.8, \dots)$ signifies “good compared to the other runs in this group” — not “good on an absolute scale.” Consequently, values across different groups are not directly comparable.

Minute computational inaccuracies. Computers introduce slight inaccuracies when calculating with floating-point numbers. To prevent $0.5000001$ from being incorrectly deemed “better” than $0.5$, we perform comparisons using a tiny tolerance of $\varepsilon = 10^{-9}$.