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

Consensus/TxQ text cleanup

Browse Source
This commit is contained in:
mDuo13
2018-10-02 14:48:30 -07:00
parent 1177df2e9e
commit 66f7374eb2
2 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
content/concepts/consensus-network/consensus.md
View File

@@ -15,7 +15,7 @@ The peer-to-peer XRP Ledger network provides a worldwide, shared ledger, which g
- balances of XRP and [issued currencies](issued-currencies.html)
- offers in the distributed exchange
- network settings, such as [transaction costs](transaction-cost.html) and [reserve](reserves.html) amounts
- a time stamp
- a timestamp
For a full, technical description of which data is included in a ledger version, see the [Ledger Format Reference](ledger-data-formats.html).
@@ -61,7 +61,7 @@ The peer-to-peer XRP Ledger network consists of many independent XRP Ledger serv
_Figure 4: Participants in the XRP Ledger Protocol_
The servers that receive, relay and process transactions may be either tracking servers or validators. Tracking servers’ primary functions include distributing transactions from clients and responding to queries about the ledger. Validating servers perform the same functions as tracking servers and additionally contribute to advancing the ledger sequence <a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>.
The servers that receive, relay and process transactions may be either tracking servers or validators. The major functions of tracking servers include distributing transactions from clients and responding to queries about the ledger. Validating servers perform the same functions as tracking servers and also contribute to advancing the ledger sequence <a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>.
While accepting transactions submitted by client applications, each tracking server uses the last validated ledger as a starting point. The accepted transactions are candidates. The servers relay their candidate transactions to their peers, allowing the candidate transactions to propagate throughout the network. Ideally, each candidate transaction would be known to all servers, allowing each to consider the same set of transactions to apply to the last validated ledger. As transactions take time to propagate however, the servers do not work with the same set of candidate transactions at all times. To account for this, the XRP Ledger uses a process called consensus to ensure that the same transactions are processed and validated ledgers are consistent across the peer-to-peer XRP Ledger network.
@@ -73,7 +73,7 @@ During consensus, each server evaluates proposals from a specific set of servers
[![Figure 5: Validators Propose and Revise Transaction Sets](img/consensus-rounds.png)](img/consensus-rounds.png)
_Figure 5: Validators Propose and Revise Transaction Sets — At the start of consensus, validators may have different sets of transactions. In later rounds, servers modify their proposals to match what their trusted validators proposed. This process determines which transactions the should apply to the ledger version currently being discussed, and which they should postpone for later ledger versions._
_Figure 5: Validators Propose and Revise Transaction Sets — At the start of consensus, validators may have different sets of transactions. In later rounds, servers modify their proposals to match what their trusted validators proposed. This process determines which transactions they should apply to the ledger version currently being discussed, and which they should postpone for later ledger versions._
Candidate transactions that are not included in the agreed-upon proposal remain candidate transactions. They may be considered again in for the next ledger version. Typically, a transaction which is omitted from one ledger version is included in the next ledger version.
@@ -121,7 +121,7 @@ Validators each relay their results in the form of a signed message containing t
[![Figure 8: Ledger is Validated When Supermajority of Peers Calculate the Same Result Result](img/consensus-declare-validation.png)](img/consensus-declare-validation.png)
_Figure 8: Ledger is Validated When Supermajority of Peers Calculate the Same Result — Servers compare their calculated ledger with the hashes received from chosen validators. If not in agreement, the server must re-calculate or retrieve the correct ledger._
_Figure 8: Ledger is Validated When Supermajority of Peers Calculate the Same Result — Each server compares its calculated ledger with the hashes received from its chosen validators. If not in agreement, the server must recalculate or retrieve the correct ledger._
Servers in the network recognize a ledger instance as validated when a supermajority of the peers have signed and broadcast the same validation hash <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>. Going forward, transactions are applied to this updated and now validated ledger with sequence number N+1.

10
content/concepts/consensus-network/transaction-queue.md
View File

@@ -18,7 +18,7 @@ The transaction queue plays an important role in selecting the transactions that
5. **Building the Next Proposal** - Each validator prepares its proposal for the next ledger version, starting with queued transactions.
6. **Adding to the Queue** - If the next proposed ledger is already full, incoming transactions are queued for a later ledger version.
6. **Adding to the Queue** - If the next proposed ledger is already full, incoming transactions are queued for a later ledger version. (Transactions that pay the [open ledger cost](transaction-cost.html#open-ledger-cost) can still get into the next proposed ledger even if it's "full", but the open ledger cost grows exponentially with each transaction added this way.)
After this step, the process repeats from the beginning.
@@ -32,19 +32,19 @@ The `rippled` server uses a variety of heuristics to estimate which transactions
* Transactions with an `AccountTxnID` field cannot be queued.
* A single sending address can have at most 10 transactions queued at the same time. In order for a transaction to be queued, the sender must have enough XRP to pay all the XRP costs of all the sender's queued transactions including both the `Fee` fields and the sum of the XRP that each transaction could send. [New in: rippled 0.32.0][]
* If a transaction affects how the sending address authorizes transactions, no other transactions from the same address can be queued behind it. [New in: rippled 0.32.0][]
* If the transaction includes a `LastLedgerSequence` field, the value of that field must be at least **the current ledger index + 2**.
* If a transaction includes a `LastLedgerSequence` field, the value of that field must be at least **the current ledger index + 2**.
### Fee Averaging
[New in: rippled 0.33.0][]
If a sending address has one or more transactions queued, that sender can "push" the existing queued transactions into the open ledger by submitting a new transaction with a high enough transaction cost to pay for all of them. Specifically, the new transaction must increase the total transaction cost of the queued transactions from the same sending address, including the new transaction, to cover the [open ledger cost](transaction-cost.html#open-ledger-cost) of each transaction as it gets added to the ledger. The total must include the increased open ledger cost for each new transaction. The transactions must still follow the other [queuing restrictions](#queuing-restrictions) and the sending address must have enough XRP to pay the transaction costs of all the queued transactions.
If a sending address has one or more transactions queued, that sender can "push" the existing queued transactions into the open ledger by submitting a new transaction with a high enough transaction cost to pay for all of them. Specifically, the new transaction must pay a high enough transaction cost to cover the [open ledger cost](transaction-cost.html#open-ledger-cost) of itself and each other transaction from the same sender before it in the queue. (Keep in mind that the open ledger cost increases exponentially each time a transaction pays it.) The transactions must still follow the other [queuing restrictions](#queuing-restrictions) and the sending address must have enough XRP to pay the transaction costs of all the queued transactions.
This feature helps you work around a particular situation. If you submitted one or more transactions with a low cost, which got queued, you cannot send new transactions from the same address unless you do one of the following:
This feature helps you work around a particular situation. If you submitted one or more transactions with a low cost that were queued, you cannot send new transactions from the same address unless you do one of the following:
* Wait for the queued transactions to be included in a validated ledger, _or_
* Wait for the queued transactions to be permanently invalidated if the transactions have the [`LastLedgerSequence` field](reliable-transaction-submission.html#lastledgersequence) set, _or_
* [Cancel the queued transactions](cancel-or-skip-a-transaction.html) by submitting a new transaction with the same sequence number.
* [Cancel the queued transactions](cancel-or-skip-a-transaction.html) by submitting a new transaction with the same sequence number and a higher transaction cost.
If none of the above occur, transactions can stay in the queue for a theoretically unlimited amount of time, while other senders can "cut in line" by submitting transactions with higher transaction costs. Since signed transactions are immutable, you cannot increase the transaction cost of the queued transactions to increase their priority. If you do not want to invalidate the previously submitted transactions, fee averaging provides a workaround. If you increase the transaction cost of your new transaction to compensate, you can ensure the queued transactions are included in an open ledger right away.