mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
inc'd feedback
This commit is contained in:
@@ -30,7 +30,7 @@ This combines qualities of physical and centralized digital money. Prior to the
|
||||
|
||||
The XRP Ledger's system of trusted validators uses a small amount of human interaction to achieve better distribution of authority than other decentralized systems. Fully-automated systems for reaching consensus from an unknown set of participants are vulnerable to concentrations of voting power. For example, Bitcoin mining is disproportionately concentrated in places with cheap electricity. As Ripple curates a list of distinct validators operated by different entities in different jurisdictions, the XRP Ledger can become more resistant to censorship and outside pressures than proof-of-work mining. For more information on Ripple's plan to decentralize the recommended set of validators, see the [Decentralization Strategy Update](https://ripple.com/dev-blog/decentralization-strategy-update/).
|
||||
|
||||
For more information about the XRP Ledger's ability to detect censorship, see [Transaction Censorship Detection](transaction-censorship-detection.html). ***TODO: appropriate here?***
|
||||
For more information about the XRP Ledger's ability to detect censorship, see [Transaction Censorship Detection](transaction-censorship-detection.html).
|
||||
|
||||
|
||||
## Fast, Efficient Consensus Algorithm
|
||||
|
||||
@@ -1,17 +1,14 @@
|
||||
# Transaction Censorship Detection
|
||||
|
||||
The XRP Ledger is designed to be [censorship resistant](xrp-ledger-overview.html#censorship-resistant-transaction-processing). Any attempt to censor transactions requires coordinated action by a majority of the XRP Ledger network's validators.
|
||||
[New in: rippled 1.2.0][]
|
||||
|
||||
XRP Ledger provides an automated transaction censorship detector that is available on all `rippled` servers, enabling all participants to see if censorship is affecting the network.
|
||||
The XRP Ledger is designed to be [censorship resistant](xrp-ledger-overview.html#censorship-resistant-transaction-processing). In support of this design, the XRP Ledger provides an automated transaction censorship detector that is available on all `rippled` servers, enabling all participants to see if censorship is affecting the network.
|
||||
|
||||
While a `rippled` server is in sync with the network, the detector tracks all transactions that, in the view of the `rippled` server, should have been accepted in the last round of [consensus](intro-to-consensus.html) and included in the last validated ledger. The detector issues log messages of increasing severity for transactions that have not been included in a validated ledger after several rounds of consensus.
|
||||
|
||||
A `rippled` server is considered to be in sync if it meets the following criteria: ***TODO: Is this info useful or overkill?***
|
||||
|
||||
- It has a `server_state` of `full` or `proposing`.
|
||||
- It has the network's last fully validated ledger.
|
||||
- It has good connectivity.
|
||||
- It is tracking the current consensus round.
|
||||
|
||||
## How It Works
|
||||
|
||||
At a high-level, here’s how the transaction censorship detector works:
|
||||
|
||||
@@ -23,7 +20,7 @@ At a high-level, here’s how the transaction censorship detector works:
|
||||
|
||||
For as long as the transaction remains in the tracker, the detector continues to issue a warning message in the log every 15 ledgers, for up to five warning messages. After the fifth warning message, the detector issues a final [error message](#example-error-message) in the log and then stops issuing warning and error messages.
|
||||
|
||||
If you see these messages in your `rippled` server log, you may want to investigate, off-ledger, why other `rippled` servers are failing to include the transaction.
|
||||
If you see these messages in your `rippled` server log, first verify that the messages are not [false positives](#potential-false-positives). If they are not false positives, you may want to investigate, off-ledger, why other `rippled` servers are failing to include the transaction.
|
||||
|
||||
|
||||
|
||||
@@ -31,7 +28,7 @@ At a high-level, here’s how the transaction censorship detector works:
|
||||
|
||||
This is an example warning message issued by the transaction censorship detector after transaction E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 remained in the tracker for 15 ledgers, from ledger 18851530 to ledger 18851545.
|
||||
|
||||
Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
|
||||
|
||||
|
||||
@@ -39,4 +36,21 @@ This is an example warning message issued by the transaction censorship detector
|
||||
|
||||
This is an example error message issued by the transaction censorship detector after transaction E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 remained in the tracker for 75 ledgers (5 sets of 15 ledgers), from ledger 18851530 to ledger 18851605.
|
||||
|
||||
Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
|
||||
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
|
||||
|
||||
|
||||
|
||||
## Potential False Positives
|
||||
|
||||
The transaction censorship detector may issue false positives in certain scenarios. In this case, a false positive means that the detector has flagged a transaction that has remained in the tracker for 15 ledgers or more, but for innocent reasons.
|
||||
|
||||
Here are some scenarios that could cause the detector to issue false positive messages:
|
||||
|
||||
- Your `rippled` server is running a build with code that is different from the rest of the network. This may cause your `rippled` server to apply transactions differently, resulting in false positives. While this type of false positive is unlikely, in general, it is crucial that you run the correct version of `rippled`.
|
||||
|
||||
- Your `rippled` server is out of sync with the network and has not yet realized it.
|
||||
|
||||
- Your `rippled` server is being impacted by a class of bug that causes `rippled` servers to inconsistently relay transactions to other `rippled` servers in the network.
|
||||
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -154,6 +154,10 @@ This is not strictly a problem, but if you want to acquire ledger history faster
|
||||
s2.ripple.com 51235
|
||||
```
|
||||
|
||||
## Potential Censorship
|
||||
|
||||
The transaction censorship detector issues log messages when it detects potential transaction censorship. For more information about the detector and these log messages, see [Transaction Censorship Detection](transaction-censorship-detection.html).
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
Reference in New Issue
Block a user