Metrics

Each trilemma axis is measured through several metrics. Some apply to any blockchain system, others only to a specific consensus protocol. Where configurations with a differing number of validation nodes (VNs) are compared, an $n$-based normalization is required so the values stay comparable.

Decentralization

Block Proposal Randomness (H)

Indicates how randomly the validation nodes that may propose a new block are selected — that is, how fairly the chances are distributed among the validation nodes. It uses Shannon entropy (in bits).

$H = - \sum_{i=1}^{n} p_i \cdot \log_2{(p_i)}, \quad p_i = \frac{b_i}{\sum_{j=1}^{n}b_j}$

• $n$: number of VNs
• $b_i$: number of blocks that VN $i$ was allowed to propose
• $p_i$: probability, derived from $b_i$, that a block is proposed by VN $i$

Let $k = |\{ i \in VN : p_i > 0 \}|$ be the number of VNs with at least one block proposal, and let $VN$ denote the set of all VNs. Then $H \leq \log_2{(k)}$, and $\max \{ \log_2{(n)} \} \iff \forall i \in VN : p_i \neq 0$.

For comparing configurations with a differing number of VNs (differing $n$), an $n$-based normalization is required:

$H_{norm} = \frac{H}{\log_2{(n)}}, \quad H \in [ 0, \log_2{(n)} ], \quad H_{norm} \in [0, 1]$

$H_{norm} = 1$ holds when $\forall i \in VN \; \forall j \in VN : i \neq j \implies p_i = p_j$.

Geographical Diversity (GD)

The degree to which validation nodes in a blockchain system are located in different places.

If a large number of validation nodes are geographically close together, natural disasters or political influences such as bans can affect those nodes and therefore the blockchain as a whole.

$GD = \frac{(GD_{excl} - GD_{target}) - GD_{equal}}{GD_{excl} - GD_{equal}}$

• $GD_{excl}$: the dispersion measure when all validation nodes operate in a single location
• $GD_{equal}$: the dispersion measure when all validation nodes are distributed equally across all available locations
• $GD_{target}$: the measure for the observed distribution

These quantities are derived from an auxiliary dispersion term $GD_{aux}$:

$GD_{aux} = \left( 2 - \frac{ \log_{(|N|+1)}(|N_t|) - \log_{(|N_t| + 1)}(|N_t|) }{ \log_2{(|N_t|)} - \log_{(|N_t + 1|)}(|N_t|) } \right) \cdot \sqrt{\frac{ \sum_{i = 1}^{|N_t|} (|n_i| - \mu)^2 }{|N_t|}}, \quad \mu = \frac{n}{|N_t|}$

• $n$: number of VNs
• $|N|$: number of all locations
• $|N_t|$: number of occupied locations
• $|n_i|$: number of VNs in location $i$

A higher $GD$ implies an even cross-location dispersion of VNs and increases the degree of decentralization.

Hashing Power Distribution (PoW only)

Indicates the extent to which hashing power is distributed among all validating nodes that propose the next block. It uses the Nakamoto coefficient (NC):

$NC = \min \left\{ k \in [1, \ \dots \ , n]: \sum_{i = 1}^{k}p_i \geq threshold \right\}$

• $p_i$: share of hashing power held by VN $i$

A high $NC$ implies a higher degree of decentralization.

Token Concentration (PoS only)

Indicates the distribution of tokens held as stake among the validation nodes.

A node’s stake usually influences, roughly proportionally, the probability that it may validate a new block. If the stake is split such that, say, three nodes account for 60 % of it, those three nodes have decisive influence over the validation of new blocks and affect both the ability of other nodes to participate and the security of the blockchain.

This is measured with the Herfindahl–Hirschman Index (HHI):

$HHI = \sum_{i = 1}^{n} \left( \frac{t_i}{t_{total}} \right)^2$

• $t_i$: the stake of VN $i$
• $t_{total}$: the total stake, $t_{total} = \sum_{i=1}t_i$

For comparing configurations with a differing number of VNs (differing $n$), an $n$-based normalization is required:

$HHI_{norm} = \frac{HHI - \frac{1}{n}}{1 - \frac{1}{n}} \in [0, 1]$

$HHI_{norm} = 0$ indicates an equal stake distribution, and $HHI = 0$ a monopolistic one.

Wealth Distribution (PoS only)

Indicates the inequality of the total tokens held by (validation) nodes.

Note

Often the tokens of all actors in a blockchain that can hold tokens are taken into account. However, the paper “On the Trade-Off between Degree of Decentralization and Scalability in Proof-of-Stake-based Blockchain Systems” explicitly mentions validation nodes only.

This uses the Gini coefficient:

$Gini = \frac{ \sum_{i=1}^{n} \sum_{j=1}^{n} |t_i - t_j| }{ 2n \cdot \sum_{i=1}^{n}t_i }$

• $n$: number of VNs
• $t_i$: number of tokens held by VN $i$

For comparing configurations with a differing number of VNs (differing $n$), an $n$-based normalization is required:

$Gini_{norm} = Gini \cdot \frac{n}{n-1} \in [0, 1]$

Security

Cost of Attack (CoA)

Describes the cost, in fiat currency, of gaining control over a blockchain system through an attack.

A high CoA is intended to make attacking a blockchain system economically unattractive.

$CoA = t_h \times c \times \sum_{i=1}^{n}s_i$

• $t_h$: the minimum share of network resources required to gain control over consensus
• $c$: monetary cost per unit of resource
• $s_i$: the number of resources controlled by VN $i$

Fault Tolerance (FT)

Describes the degree to which a blockchain system continues to operate consistently and correctly despite random or byzantine faults.

$FT = \{ \Delta ThroughputDiff, \Delta ConfLatDiff \}$

$ThroughputDiff$ denotes the drop in the maximum achievable throughput under failure:

$ThroughputDiff = |Throughput_N - Throughput_F|$

$ConfLatDiff$ denotes the increase in confirmation latency under failure:

$ConfLatDiff = |ConfLat_N - ConfLat_F|$

• $N$: value during normal operation of the blockchain
• $F$: value with faults occurring during operation

Reliability (R)

Denotes the ability of a blockchain system to provide correct services continuously.

Reliability reflects the probability that the system keeps functioning correctly without interruption.

We assume exponentially distributed failure times with a constant hazard rate $\lambda$:

$R(t) = \text{Pr}[T > t] = e^{-\lambda \cdot t}, \quad \lambda = \frac{1}{MTBF}$

There is also the variant in which $R(t)$ is expressed via the mean time between failures (MTBF):

$R(t) = e^{-t / MTBF}, \quad MTBF = \frac{\text{TotalOperationalTime}}{\text{NumberOfFailures}}$

Stale Block Rate (SBR)

Indicates the proportion of blocks that were propagated in a blockchain system but not finalized into the main chain within a given period.

$SBR = \frac{NumberOfStaleBlocks}{NumberOfConfirmedBlocks}$

Scalability

Transaction Throughput (TPS)

The rate of first inclusions of transactions over an observation window.

$TPS = \frac{\text{NumOfConfTr}}{t_1 - t_0}$

• $\text{NumOfConfTr}$: number of independent transactions
• $t_0$: start of the observation window
• $t_1$: end of the observation window

Transaction Finalization Latency (TFL)

The time span from submitting a transaction to its first inclusion in the blockchain.

$TFL = t_\text{incl} - t_\text{prop}$

• $t_\text{prop}$: timestamp when the transaction was issued
• $t_\text{incl}$: timestamp when the first block containing the transaction was validated

Confirmation Latency (CL)

The time span from proposing new blocks to their confirmation.

$CL_\text{emp}$ gives the estimated confirmation latency:

$CL_\text{emp} = BConfTime - BPropTime$

• $BPropTime$: the point in time when the block was proposed
• $BConfTime$: the point in time when the block was confirmed

$CL_\text{conf}$ computes the confirmation latency taking into account the number of safety confirmations $b' \in \mathbb{N}$ and the average block creation interval:

$CL_\text{conf} = b' \times BCI$

Some blockchain systems (such as Ethereum) first justify a block and confirm it in the following epoch. For such procedures, $CL_\text{epoch}$ describes the confirmation latency:

$CL_\text{epoch} = e_f \times TTJ, \quad TTJ = e_l \times slot\_time$

• $e_f$: number of epochs until finalization
• $e_l$: number of slots per epoch
• $slot\_time$: duration of one slot

Availability

Describes the degree to which a blockchain system is operational and delivers consistent, timely responses.

It is often measured as the ratio between confirmed and total transactions.

$Availability = \frac{NumOfConfTr}{NumOfTr}$

• $NumOfConfTr$: number of confirmed transactions
• $NumOfTr$: total number of transactions