## 4 Experimental Setup  
In this section, the experimental setup is described, which consists of two scenarios. The purpose of both scenarios is to help us gain deeper understanding of the performance of the underlying consensus mechanisms with respect to the security of the network in terms of malicious nodes. Regarding the latter, the underlying hypothesis is that a subset of the network nodes is malicious i.e., the respective nodes propagate falsified messages to the entire network. Specifically, the experimental parameters are as follows:  
1. percentage of malicious nodes in the network;
2. percentage of UNL overlap; and
3. performance-related metrics.  
For both scenarios, the first two experimental parameters are identical. The first parameter aims to simulate the conditions under which varying numbers of malicious nodes participate in the network. These numbers are relative to the total number of network nodes. Specifically, 0-35% malicious nodes were used in the experiments conducted in the present work. This particular range (0-35%) followed the analysis reported in [11; 27]. The second experimental parameter was used for incorporating various degrees of decentralization regarding the underlying consensus. In particular, the percentage of UNL overlap can be considered being inversely proportional to the decentralization degree of the consensus process. For example, a network configuration that utilizes 10% UNL overlap is more decentralized compared to the case of 90% UNL overlap. In the next paragraphs, a number of scenario-specific parameters are briefly described.  
**Scenario 1: Convergence Time.** The experiments conducted in this scenario were based on the simulator implementation that is publicly available via the following link: [[https://github.com/ripple/simulator](https://github.com/ripple/simulator)]([https://github.com/ripple/simulator](https://github.com/ripple/simulator)). This is described in [11]. The convergence time (i.e., the time required for reaching consensus between the network nodes) was used as a performance metric. The performance of the consensus mechanism (and, in general, the network as a whole) is inversely proportional to the convergence time.  
**Scenario 2: Network Health Indicator.** In this scenario, a more recent version of the simulator was applied, which is also publicly available at: [[https://github.com/ripple/rippled/tree/develop/src/test/csf](https://github.com/ripple/rippled/tree/develop/src/test/csf)]([https://github.com/ripple/rippled/tree/develop/src/test/csf](https://github.com/ripple/rippled/tree/develop/src/test/csf)). This simulator is described in [27]. This newer implementation enabled the computation of a new performance metric, which is more insightful compared to the convergence time used in the first scenario. Specifically, we define the Network Health Indicator (\(NHI\)) as follows:  
\[NHI=\frac{L_{C}-L_{V}}{L_{C}},\text{for}L_{C}>0\text{and}L_{V}>0, \tag{1}\]  
where \(L_{C}\) and \(L_{V}\) denote the number of candidate ledgers and the number of fully validated ledgers, respectively. By definition, \(L_{C}\geq L_{V}\), i.e., some candidate ledgers may not be validated. According to the above definition, there are two extreme cases. The worst case takes place when none of the candidate ledgers is validated (i.e., \(L_{V}=0\)) resulting in \(NHI=1\). The best case happens when \(L_{C}=L_{V}\), which yields \(NHI=0\). Thus, the performance is inversely proportional to \(NHI\).