diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md index db9450c5e4..e345fc5777 100644 --- a/content/concepts/consensus-network/consensus.md +++ b/content/concepts/consensus-network/consensus.md @@ -88,6 +88,9 @@ Validation can be broken up into roughly two parts: - Calculating the resulting ledger version from an agreed-upon transaction set. - Comparing results and declaring the ledger version validated if enough trusted validators agree. +Each server in the network performs validation separately and locally; the consensus process can proceed to tentatively confirm transactions even if no ledger is validated from a given round. + + #### Calculate and Share Validations When the consensus process completes, each server independently computes a new ledger from the agreed-upon set of transactions. Each server calculates the results by following the same rules, which can be summarized as follows: @@ -126,7 +129,7 @@ Servers in the network recognize a ledger instance as validated when a supermajo In cases where a server is in the minority, having computed a ledger that differs from its peers, the server disregards the ledger it computed 8. It recomputes the correct ledger, or retrieves the correct ledger as needed. -If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the servers repeat the consensus process. As time passes since consensus began, it becomes increasingly likely that a majority of the servers have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](transaction-cost.html) and the time to wait for consensus in response to these conditions. +If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the servers repeat the consensus process for a new ledger version. As time passes since consensus began, it becomes increasingly likely that a majority of the servers have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](transaction-cost.html) and the time to wait for consensus in response to these conditions. Once they reach supermajority agreement on validations, the servers work with the new validated ledger, ledger index N+1. The consensus and validation process repeats 9, considering candidate transactions that were not included in the last round along with new transactions submitted in the meantime. diff --git a/content/concepts/consensus-network/negative-unl.md b/content/concepts/consensus-network/negative-unl.md index 4e893eae39..301bf617aa 100644 --- a/content/concepts/consensus-network/negative-unl.md +++ b/content/concepts/consensus-network/negative-unl.md @@ -18,15 +18,10 @@ The Negative UNL has no impact on how the network processes transactions or what 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 default configuration uses a recommended UNL, signed by Ripple, consisting of validators Ripple considers to be sufficiently unique, reliable, and independent.) The standard quorum requirement is at least 80% of trusted validators must agree. -Therefore, if more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, the network stops making forward progress 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. +Therefore, 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. However, this means that the network could stop making forward progress if a few widely-trusted validators went offline. As of 2020-10-06, there are 34 validators in Ripple's recommended UNL, so the network would stop making forward progress if 7 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. -## Enabling the Negative UNL for Testing - -Negative UNL functionality is currently available for testing on [Devnet](parallel-networks.html). You can test the Negative UNL feature by adding or modifying a `[features]` stanza in your `rippled.cfg` file, as described in [Connect Your rippled to a Parallel Network](connect-your-rippled-to-the-xrp-test-net.html). - - ## Summary It is not reasonable to expect a diverse set of validators to maintain 100% uptime: many things can cause a validator to become temporarily unavailable, such as: hardware maintenance, software upgrades, internet connectivity problems, targeted attacks, human error, hardware failures, and outside circumstances like natural disasters. @@ -37,11 +32,17 @@ When a validator that is on the Negative UNL comes back online and sends consist In cases where validators go offline one or two at a time, the remaining validators can use the Negative UNL to gradually adjust their effective UNLs, so that the network only ever needs 80% of the _online_ validators to achieve a quorum. To prevent the network from fragmenting, the quorum has a hard minimum of 60% of _total_ validators. -The Negative UNL does not help against situations where greater than 20% of trusted validators suddenly go offline all at once. In that case, the remaining validators would not be able to reach the consensus necessary to adjust the Negative UNL. +If more than 20% of validators suddenly go offline all at once, the remaining servers cannot achieve the quorum necessary to validate a new ledger, so no new ledgers could be validated. However, those servers can still make tentative forward progress through successive consensus rounds. Over time, the remaining validators would continue to apply changes to the Negative UNL to the tentative ledgers and adjust their effective UNLs; eventually, if the situation persists, the network could resume fully validating ledgers by using the adjusted Negative UNL from the tentative ledger versions. Negative UNL has no effect on [stand-alone mode](rippled-server-modes.html) since the server does not use consensus in stand-alone mode. +## Enabling the Negative UNL for Testing + +Negative UNL functionality is currently available for testing on [Devnet](parallel-networks.html). You can test the Negative UNL feature by adding or modifying a `[features]` stanza in your `rippled.cfg` file, as described in [Connect Your rippled to a Parallel Network](connect-your-rippled-to-the-xrp-test-net.html). + + + ## How It Works The Negative UNL is closely tied to the [consensus process](consensus.html) and is designed with safeguards to maintain the continuity and reliability of the network in adverse situations. When all trusted validators are operating normally, the Negative UNL is unused and has no effect. When some validators appear to be offline or out of sync, the Negative UNL rules take effect. @@ -67,6 +68,8 @@ If a validator's reliability is **less than 50%**, it is a candidate to be added Each server, including validators, independently calculates reliability scores for all of its trusted validators. Different servers may reach different conclusions about a validator's reliability, either because that validator's votes reached one server and not the other, or because they happened to disagree about specific ledgers more or less often. To add or remove a validator from the Negative UNL, a consensus of trusted validators must agree that a particular validator is above or below the reliability threshold. +**Tip:** Validators track their own reliability, but do not propose adding themselves to the Negative UNL. A validator's measure of its own reliability cannot take into account how successfully its validation votes propagate through the network, so it is less dependable than measurements from outside servers. + ### Modifying the Negative UNL @@ -115,10 +118,12 @@ This mechanism has several useful properties: ### Filtering Validations -During the consensus process, validators in the parent ledger's Negative UNL are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum accordingly. (The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.) If a disabled validator sends validation votes, servers track those votes for purposes of calculating the disabled validator's reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus. +During [the validation step of the consensus process](consensus.html#validation), validators in the parent ledger's Negative UNL are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum accordingly. (The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.) If a disabled validator sends validation votes, servers track those votes for purposes of calculating the disabled validator's reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus. **Note:** The Negative UNL adjusts the _total_ trusted validators that the quorum is calculated from, not the quorum directly. The quorum is a percentage but the number of votes is a whole number, so in some cases, reducing the total trusted validators may not change the number of votes required to reach a quorum. For example, if there are 15 total validators, 80% is 12 validators exactly. If you reduce the total to 14 validators, 80% is 11.2 validators, which means that it still requires 12 validators to reach a quorum. +The Negative UNL has no impact on the other parts of the consensus process, such as choosing which transactions to include in the proposed transaction set. Those steps always rely on configured UNL, and the thresholds are based on how many trusted validators are actively participating in the consensus round. Therefore, even a validator that is in the Negative UNL can participate in the consensus process. + ### Example The following example demonstrates how the Negative UNL affects the consensus process: diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/negativeunl.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/negativeunl.md index 432ac085f4..9cd33a5635 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/negativeunl.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/negativeunl.md @@ -46,7 +46,7 @@ A `NegativeUNL` object has the following fields: ## DisabledValidator Objects -Each DisabledValidator Object represents one disabled validator. In JSON, a DisabledValidator object has one field, `DisabledValidator`, which in turn contains another object with the following fields: +Each `DisabledValidator` object represents one disabled validator. In JSON, a `DisabledValidator` object has one field, `DisabledValidator`, which in turn contains another object with the following fields: | Name | JSON Type | [Internal Type][] | Description | |:----------------------|:----------|:------------------|:---------------------|