As the digital currency revolution continues to gain momentum, the debate between proponents of proof-of-work and newer contract algorithms continues. Beyond rhetoric, the development of the consensus approach is making steady strides that are difficult to find for transactional proof-of-work networks due to design limitations.
As the only blockchain company for businesses whose payment products are in commercial use today, Ripple has found that the digital asset XRP allows its users to raise liquidity quickly and cheaply while offering greater scalability than any other digital asset.
The XRP ledger (XRPL) has a fundamentally different design than blockchains based on proof-of-work such as Bitcoin and Ethereum. The consensus validation system used by XRPL follows an anti-robustness principle that increases reliability. This provides the system with a built-in safety mechanism: if safe forward progress is not clearly possible, XRPL will not make any forward progress.
Despite the existence of this consensus-validated safety brake, XRPL has demonstrated a reliability rate of greater than 99.999% since it began operations more than 58 million ledgers ago. XRPL’s history of closing a ledger roughly every five seconds confirms this consistency.
A quick look back: How public blockchains work
The “secret sauce” of public blockchains like Bitcoin is that every participant can confirm that every transaction complies with all system rules. As a result, the system status is public: transactions are public and everyone knows which transactions are valid and which are not. With such a system, validators do not need to tell anyone which transactions are valid or which transactions are in progress. The validity of each transaction is already available to every participant.
Using Consensus to Beat Double Spending and Accidental Forking
“Consensus”, as applied to the method of validation used by XRPL, refers to the need to address the double spend problem. This problem occurs when there are two (or more) “equally good” ways to make progress. Consensus ensures that dishonest participants cannot mislead honest participants into disagreeing about the system status.
In such a system, the main role of the validators is to enable honest participants to agree on a way forward when there are two or more equally good ways to make progress. This approach prevents attempts to double spending by preventing participants from being tricked by malicious parties into expecting the same funds to be delivered to two different destinations.
Public blockchains do not have central authorities that prescribe system rules. Each participant can choose which rules they want. However, participants who do not agree on system rules cannot interact with each other. This creates complexity and risk when system rules are changed.
Consensus-driven systems can take a different approach: In the case of XRP Ledger, validators help protect against unintentional branching of the ledger by coordinating changes to the system rules. However, you cannot get a server to accept a rule change that it is not specifically configured to accept. To take effect after implementation, changes to the general ledger must be 80% quorate for two consecutive weeks from the validator community.
XRPL’s consensus scheme using validators provides an inexpensive, reliable, decentralized and fast solution to the double spend problem. Thanks to its design, the network can also be updated if the participants agree, without the risk of accidental deviation.
Consensus as a reliable, decentralized and energy-efficient solution
While proof of work has proven to be a technological dead end, given the massive inefficiencies in power usage and transaction costs, other consensus algorithms continue to innovate to achieve better decentralization at lower cost and risk. XRPL’s consensus algorithm is being further developed to improve resilience. In this regard, the recently introduced Negative UNL feature will greatly improve XRPL’s ability to tolerate validator failures while still making reliable progress.
This feature suggests enhancing the liveliness of the XRPL network through features that allow servers to keep track of validators that have gone temporarily offline. With this information, servers can adjust quorum calculations to reflect the offline validators. Since a validator that goes offline for a short period of time is not necessarily a sign of unreliability, Negative UNL helps UNL publishers deal with scenarios where a validator did not go offline long enough to trigger removal from the UNL, and still ensure its offline status to ensure the network can progress.
Ripple and other members of the community will be conducting extensive public testing of the Negative UNL feature on the XRPL Devnet over the next few months. If these public tests meet all applicable security, reliability, stability, and performance requirements, a change to implement the UNL negative quorum checking functionality could be introduced in a future version 2.0.
For more information on building on XRPL, visit the RippleX platform. There you will find developer tools, services, and programs.