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

Tx finality: edits per reviews

Browse Source
This commit is contained in:
mDuo13
2019-04-16 17:51:38 -07:00
parent 4262e4663f
commit a71c50ee2d
2 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
content/concepts/payment-system-basics/ledgers.md
View File

@@ -25,9 +25,9 @@ In the case of transactions, the identifying hash is based on the signed transac
## Open, Closed, and Validated Ledgers
The `rippled` server makes a distinction between ledger versions that are _open_, _closed_, and _validated_. A server has one open ledger, a history of immutable, validated ledgers, and any number of closed but unvalidated ledgers. The following table summarizes the difference:
The `rippled` server makes a distinction between ledger versions that are _open_, _closed_, and _validated_. A server has one open ledger, any number of closed but unvalidated ledgers, and an immutable history of validated ledgers. The following table summarizes the difference:
| Ledger Type | Open | Closed | Validated |
| Ledger Type: | Open | Closed | Validated |
|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
| **Purpose:** | Temporary workspace | Proposed next state | Confirmed previous state |
| **Number used:** | 1 | Any number, but usually 0 or 1 | One per ledger index, growing over time |

2
content/concepts/payment-system-basics/transaction-basics/finality-of-results.md
View File

@@ -22,7 +22,7 @@ When you initially submit a transaction, the `rippled` server tentatively applie
- The transaction may be delayed until a later ledger version, or may never be included in a validated ledger. For the most part, the XRP Ledger follows a principle that all valid transactions should be processed as soon as possible. However, there are exceptions, including:
- If a proposed transaction has not been relayed a majority of validators by the time a [consensus round](consensus.html) begins, it may be postponed until the next ledger version, to give the remaining validators time to fetch the transaction and confirm that it is valid.
- If a proposed transaction has not been relayed to a majority of validators by the time a [consensus round](consensus.html) begins, it may be postponed until the next ledger version, to give the remaining validators time to fetch the transaction and confirm that it is valid.
- If an address sends two different transactions using the same sequence number, at most one of those transactions can become validated. If those transactions are relayed through the network in different paths, a tentatively-successful transaction that some servers saw first may end up failing because the other, conflicting transaction reached a majority of servers first.