## 6 Conclusions  
This work complements the analysis presented in [27] where a minimum bound on the percentage of UNL overlapping is suggested. More specifically, we report results from our empirical experimentation with different percentages of UNL overlaps in conjunction with varying numbers of malicious nodes, measuring their respective effect in terms of network performance. The main experimental finding suggests that, when a low percentage (0-20%) of malicious nodes is present, the centralization degree of the network--as implemented by the UNL's percent overlap--can be significantly relaxed ensuring convergence times being shorter than 1000 ms. A strong UNL overlap,  
Figure 2: Network Health Indicator (NHI) vs. percentage of malicious nodes for various UNL overlaps.  
for example 90-99%, is needed only when the percentage of malicious nodes exceeds a critical threshold, which equals to 20%. This threshold can be considered as an empirical boundary between two broad operational regions. When the percentage of malicious nodes is less than 20%, the convergence time is upper-bounded at 1000 ms--this holds for all (10-99%) UNL overlaps applied in this work. If the 20% is exceeded, a \"burst\" effect occurs making the consensus less robust, in terms of time, as the percentage of UNL overlap decreases. The above observations clearly indicate the opportunity for engineering an adaptive scheme for dynamically (i.e., as the networks operates) determining an optimal (or nearly-optimal) UNL overlap. The optimization problem deals with the identification of the lowest possible UNL overlap (thus enhancing the decentralization degree of the network) while constraining the consensus time under a desirable threshold. This is fully aligned with one of the main points reported in [37] according to which the enhancement of the network decentralization is of greater importance compared to the protocol efficiency. For this purpose, an additional computational element is required, namely a malicious nodes estimator (or, ideally, identifier/tracker). In this framework, one may configure networks that combine the high reliability of private networks (e.g., Ripple) with the decentralized spirit of open blockchains (e.g., Bitcoin).  
Conceptualization, K.C., E.I.; Data curation, K.C., E.I., and A.I.; Formal analysis, K.C., E.I., A.I., and M.T.; Investigation, K.C., E.I., and A.I.; Methodology, K.C., E.I., A.I., and M.T.; Supervision, K.C. and E.I.; Validation, K.C. and E.I.; Writing--original draft, K.C., E.I., and A.I.; and Writing--review and editing, K.C., E.I., and M.T. All authors have read and agreed to the published version of the manuscript. This research was funded by the Ripple's Impact Fund, an advised fund of Silicon Valley Community Foundation (Grant id: 2018-188546). We thank [PERSON], Executive Director at the Institute For the Future (IFF), for his assistance with the methodology section of the paper and for the valuable comments that greatly improved the manuscript. We thank also [PERSON], Senior Software Engineer at Ripple Labs Inc., for the valuable suggestions. The authors declare no conflict of interest. The following abbreviations are used in this manuscript:  
RPCA Ripple Consensus Algorithm  
BFT Byzantine Fault Tolerance  
Practical Byzantine Fault Tolerance  
NHI Network Health Indicator  
PoW Proof-of-Work  
XRP Refers to the three-letter code of the native digital currency used by the Ripple protocol