ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

UNL: Apply suggestions from review

Browse Source 
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
This commit is contained in:
Rome Reginelli
2024-07-12 13:41:11 -07:00
committed by GitHub
parent 68b2184fef
commit b442bbb964
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/concepts/consensus-protocol/unl.md
View File

@@ -2,11 +2,11 @@
A _unique node list_ (UNL) is a server's list of validators that it trusts not to collude. Every XRP Ledger server is configured with a UNL, which determines which validation votes it listens to and which votes it throws out during the consensus process. By design, each entry in a UNL should represent an independent entity, which could be a business, a university, another type of organization, or even just an individual hobbyist; by having each entry be a separate entity, no one has more than a minimum share of the responsibility for keeping the network running normally.
Validators are intended to be impartial, and to process every transaction as soon as is possible within the constraints of the technology. Validators must not block or censor some transactions for arbitrary reasons, because that hinders the network from reaching consensus. More importantly, validators should be online and operational as much as possible. However, the XRP Ledger is designed to allow for imperfections, both in the network and in the validators themselves. Even if some validators are offline, misconfigured, buggy, or outright malicious, the network should still be able to make progress if the majority of them are operating normally, and the network will never confirm transactions that contradict the rules or past history of the network unless a supermajority (>80%) agree. Keeping these things in mind, the validators on a UNL should be chosen to minimize the chances that many validators will fail in the same way at the same time, or collude for malicious reasons.
Validators are intended to be impartial, and to process every transaction as soon as is possible within the constraints of the technology. Validators must not block or censor some transactions for arbitrary reasons, because that hinders the network from reaching consensus. More importantly, validators should be online and operational as much as possible. However, the XRP Ledger is designed to allow for imperfections, both in the network and in the validators themselves. Even if some validators are offline, misconfigured, buggy, or outright malicious, the network should still be able to make progress if the majority of them are operating normally, and the network will never confirm transactions that contradict the rules or past history of the network unless a supermajority (>80%) agree. Keeping these things in mind, the validators on a UNL are chosen to minimize the chances that many validators will fail in the same way at the same time, or collude for malicious reasons.
## UNL Overlap
Each server operator has full control over which validators are in their UNL. However, if two servers operate with totally different UNLs, they are likely to reach different conclusions about when ledgers (and the transactions in them) are validated. This could lead to a _fork_ in the network; when a fork happens, parties on different sides are unable to mutually agree on what has happened and can't transact with one another. To avoid forking, servers in the XRP Ledger should be configured with UNLs that have some amount of overlap with one another.
Each server operator has full control over which validators are in their UNL. However, if two servers operate with totally different UNLs, they are likely to reach different conclusions about when ledgers (and the transactions in them) are validated. This could lead to a _fork_ in the network; when a fork happens, parties on different sides are unable to mutually agree on what has happened and can't transact with one another. To avoid forking, servers in the XRP Ledger need to be configured with UNLs that have a high degree of overlap with one another.
Initially, it was believed that 60% overlap between two servers' UNLs was enough to prevent those servers from forking apart. However, [further research](./consensus-research.md) showed that in the worst case scenario, 90% overlap was required to prevent a fork. This significantly limits how much flexibility server operators have in customizing their UNL: the less overlap with the UNLs that others are using, the higher the chances of forking.