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

Merge branch 'ledger_close_times'

Browse Source
This commit is contained in:
mDuo13
2021-05-19 15:29:23 -07:00
parent 97eaa6345a 0c37492624
commit 577ea9300e
2 changed files with 11 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -32,8 +32,7 @@ In the case of transactions, the identifying hash is based on the signed transac
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 |
@@ -46,6 +45,14 @@ For an open ledger, servers apply transactions in the order those transactions a
Thus, an open ledger is only ever used as a temporary workspace, which is a major reason why transactions' [tentative results may vary from their final results](finality-of-results.html).
## Ledger Close Times
The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing.
Since new ledger versions usually close about every 3 to 5 seconds, these rules result in a loose pattern where ledgers' close times end in :00, :01, :02, :10, :11, :20, :21, and so on. Times ending in 2 are less common and times ending in 3 are very rare, but both occur randomly when more ledgers randomly happen to close within a 10-second window.
Generally speaking, the ledger cannot make any time-based measurements that are more precise than the close time resolution. For example, to check if an object has passed an expiration date, the rule is to compare it to the close time of the parent ledger. (The close time of a ledger is not yet known when executing transactions to go into that ledger.) This means that, for example, an [Escrow](escrow.html) could successfully finish at a real-world time that is up to about 10 seconds later than the time-based expiration specified in the Escrow object.
## See Also

4
content/references/protocol-reference/ledger-data/ledger-header.md
View File

@@ -6,7 +6,7 @@ blurb: A unique header that describes the contents of a ledger version.
# Ledger Header
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
Every [ledger version](ledger-data-formats.html) has a unique header that describes the contents. You can look up a ledger's header information with the [ledger method][]. The contents of the ledger header are as follows:
Every [ledger version](ledgers.html) has a unique header that describes the contents. You can look up a ledger's header information with the [ledger method][]. The contents of the ledger header are as follows:
| Field | JSON Type | [Internal Type][] | Description |
|:-----------------------------|:----------|:------------------|:--------------|
@@ -29,7 +29,7 @@ Every [ledger version](ledger-data-formats.html) has a unique header that descri
## Close Flags
The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different close times for the ledger, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger version contains a `close_time` value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.)
The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different [close times for the ledger](ledgers.html#ledger-close-times), but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, official `close_time` value of the ledger is 1 second after that of the parent ledger.
The `closeFlags` field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.