diff --git a/content/concepts/consensus-network/consensus-protections.md b/content/concepts/consensus-network/consensus-protections.md index 45d319e359..98a715bdf6 100644 --- a/content/concepts/consensus-network/consensus-protections.md +++ b/content/concepts/consensus-network/consensus-protections.md @@ -52,11 +52,11 @@ A "51% attack" is an attack on a blockchain system where one party controls more For all participants in the XRP Ledger to agree on what they consider validated, they must start by choosing a set of trusted validators that are fairly similar to the sets chosen by everyone else. In the worst case, less than about 90% overlap could cause some participants to diverge from each other. For that reason, Ripple publishes a signed list of recommended validators, including trustworthy and well-maintained servers run by the company, industry, and community. -By default, XRP Ledger servers are configured to use a validator list site run by Ripple. The site provides a list of recommended validators (also known as a recommended UNL), which Ripple updates periodically. Servers configured this way trust all validators in the latest version of the list, which ensures 100% overlap with others also using the same list. The default configuration includes a public key that verifies the authenticity of the site's contents. In case the site goes down, servers in the XRP Ledger's peer-to-peer network can directly relay the signed updates to the list among themselves. +By default, XRP Ledger servers are configured to use a validator list site run by Ripple. The site provides a list of recommended validators (also known as a recommended _Unique Node List_, or UNL), which Ripple updates periodically. Servers configured this way trust all validators in the latest version of the list, which ensures 100% overlap with others also using the same list. The default configuration includes a public key that verifies the authenticity of the site's contents. In case the site goes down, servers in the XRP Ledger's peer-to-peer network can directly relay the signed updates to the list among themselves. Technically, if you run a server, you can configure your own list site or explicitly choose validators to trust on an individual basis, but Ripple does not recommended doing so. If your chosen set of validators does not have enough overlap with others, your server may diverge from the rest of the network, and you could lose money by taking action based on your server's divergent state. -Research is ongoing to design an improved consensus protocol that allow more heterogeneous validator lists. For more information, see the [Consensus Research](consensus-research.html) page. +Research is ongoing to design an improved consensus protocol that allows more heterogeneous validator lists. For more information, see the [Consensus Research](consensus-research.html) page. ## See Also diff --git a/content/concepts/introduction/intro-to-consensus.md b/content/concepts/introduction/intro-to-consensus.md index 483ea2ff29..89069944f1 100644 --- a/content/concepts/introduction/intro-to-consensus.md +++ b/content/concepts/introduction/intro-to-consensus.md @@ -54,7 +54,7 @@ For a longer exploration of how the XRP Ledger Consensus Protocol responds to va ## See Also - [Consensus Network Concepts](consensus-network.html) for several articles describing the mechanics of the XRP Ledger Consensus Protocol in greater depth. -- [Run `rippled` as a Validator](run-rippled-as-a-validator.html) for instructions running your own validator. +- [Run `rippled` as a Validator](run-rippled-as-a-validator.html) for instructions on running your own validator. - [Decentralization Strategy Update (Ripple Dev Blog)](https://ripple.com/dev-blog/decentralization-strategy-update/) for a description of Ripple's goals and plans for decentralizing the XRP Ledger. @@ -63,6 +63,6 @@ For a longer exploration of how the XRP Ledger Consensus Protocol responds to va ## Footnotes -1. In Bitcoin, the current state is sometimes called the set of "UTXOs" (unspent transaction outputs). Unlike the XRP Ledger, a Bitcoin server must download the entire transaction history to know the full set of UTXOs and process new transactions. Currently (as of 2018), there have been some proposals to modify Bitcoin's consensus mechanism to periodically summarize the latest UTXOs so new servers would not need to do this. Etherium, which also uses a UTXO model, has already implemented a similar approach with summary of the current state, called a _state root_, in each block. +1. In Bitcoin, the current state is sometimes called the set of "UTXOs" (unspent transaction outputs). Unlike the XRP Ledger, a Bitcoin server must download the entire transaction history to know the full set of UTXOs and process new transactions. Currently (as of 2018), there have been some proposals to modify Bitcoin's consensus mechanism to periodically summarize the latest UTXOs so new servers would not need to do this. Etherium, which also uses a UTXO model, has already implemented a similar approach with a summary of the current state, called a _state root_, in each block. 2. A server does not need a direct connection to its trusted validators to hear from them. The XRP Ledger peer-to-peer network uses a _gossip protocol_ where servers identify each other by public keys and relay digitally-signed messages from others.