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

Fixes per @intelliot's review

Browse Source
This commit is contained in:
mDuo13
2018-08-21 14:25:19 -07:00
parent a2d7baff7d
commit 5ef7538e2a
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -65,6 +65,6 @@ For a longer exploration of how the XRP Ledger Consensus Protocol responds to va
1. <a id="footnote-1"></a> Due to a mishap early in the XRP Ledger's history, [ledgers 1 through 32569 were lost](https://forum.ripple.com/viewtopic.php?f=2&t=3613). (This loss represents approximately the first week of ledger history.) Thus, ledger #32570 is the earliest ledger available anywhere. Because the XRP Ledger's state is recorded in every ledger version, the ledger can continue without the missing history. New test networks still start with ledger index 1.
2. <a id="footnote-2"></a> 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 id="footnote-2"></a> 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. 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. Ethereum, 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.
3. <a id="footnote-3"></a> 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.