ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 23:25:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clean up unused / removed pages & images

Browse Source 
- Delete folders for new pages that are handled by templates w/ no
  markdown source
- Fully remove "Use Cases", leaving redirects for deleted pages.
    - Move certain pages to new areas & remove Use Case markup
- Add "Contribute Code to the XRP Ledger" draft page
- Fix image paths in some Japanese-translated pages
This commit is contained in:
mDuo13
2020-09-17 22:17:06 -07:00
parent fee9d79a18
commit b1339f84c6
37 changed files with 200 additions and 833 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/concepts/introduction/intro-to-consensus.md
View File

@@ -39,7 +39,7 @@ The main job of the XRP Ledger Consensus Protocol is to agree on a set of transa
## Trust-Based Validation
The core principle behind the XRP Ledger's consensus mechanism is that a little trust goes a long way. Each participant in the network chooses a set of _validators_, servers [specifically configured to participate actively in consensus](run-a-rippled-validator.html), run by different parties who are expected to behave honestly most of the time. More importantly, the set of chosen validators should not be likely to collude with one another to break the rules in the exact same way. This list is sometimes called a _Unique Node List_, or UNL.
The core principle behind the XRP Ledger's consensus mechanism is that a little trust goes a long way. Each participant in the network chooses a set of _validators_, servers [specifically configured to participate actively in consensus](run-rippled-as-a-validator.html), run by different parties who are expected to behave honestly most of the time. More importantly, the set of chosen validators should not be likely to collude with one another to break the rules in the exact same way. This list is sometimes called a _Unique Node List_, or UNL.
As the network progresses, each server listens to its trusted validators[³](#footnote-3); as long as a large enough percentage of them agree that a set of transactions should occur and that a given ledger is the result, the server declares a consensus. If they don't agree, validators modify their proposals to more closely match the other validators they trust, repeating the process in several rounds until they reach a consensus.