ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-01 09:05:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Negative UNL: edits per review

Browse Source
This commit is contained in:
mDuo13
2024-06-25 11:48:08 -07:00
parent 44621acd8f
commit 9ec5ad9b84
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/concepts/consensus-protocol/negative-unl.md
View File

@@ -16,11 +16,11 @@ The Negative UNL has no impact on how the network processes transactions or what
## Background
Each server in the XRP Ledger protocol has its own UNL (Unique Node List), a list of validators it trusts not to collude, and each server independently decides when a ledger version is validated based on the consensus when enough of its trusted validators agree on a new ledger version. The standard quorum requirement is at least 80% of trusted validators must agree. By default, servers are configured to download two lists, one UNL published by the XRP Ledger Foundation and one UNL published by Ripple, and to use the union of those two lists as their UNL. (In other words, by default a server listens to the votes of any validator that is on at least one of those lists.)
Each server in the XRP Ledger protocol independently decides a ledger version is validated when a quorum of its trusted validators agree. A server's trusted validators are defined by that server's UNL (Unique Node List), a list of validators it trusts not to collude. By default, servers are configured to trust any validator on at least one of two lists, one UNL published by the XRP Ledger Foundation and one UNL published by Ripple.
If more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, the network stops validating new ledgers because it cannot reach a quorum. This is a design choice to ensure that no transactions' outcomes can be changed after they are declared final. During such a situation, the remaining servers would still be online and could provide past and tentative transaction data, but could not confirm the final, immutable outcome of new transactions.
The standard quorum requirement is 80% of trusted validators. If more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, servers stop validating new ledgers because they cannot reach a quorum. This is a design choice to ensure that no transactions' outcomes can be changed after they are declared final. During such a situation, the remaining servers would still be online and could provide past and tentative transaction data, but could not confirm the final, immutable outcome of new transactions.
However, this means that the network could stop making forward progress if a few widely-trusted validators went offline. As of 2024-06-07, there are a total of 35 validators on the default UNLs, so the network would stop making forward progress if 8 or more of them were offline. Furthermore, if one or two validators are out for an extended period of time, the network has less room for disagreement between the remaining validators, which can make it take longer to achieve a consensus.
However, this means that the network could stop making forward progress if a few widely trusted validators went offline. As of 2024-06-25, there are a total of 35 validators on the default UNLs, so the network would stop making forward progress if 8 or more of them were offline. Furthermore, if one or two validators are out for an extended period of time, the network has less room for disagreement between the remaining validators, which can make it take longer to achieve a consensus.
## Summary