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

More 'ledger index' standardization

Browse Source
This commit is contained in:
mDuo13
2019-11-26 16:35:40 -08:00
parent db5da68093
commit 100b2cc47d
12 changed files with 103 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -25,11 +25,11 @@ _Figure 1: XRP Ledger Elements_
The XRP Ledger has a new ledger version every several seconds. When the network agrees on the contents of a ledger version, that ledger version is _validated_, and its contents can never change. The validated ledger versions that preceded it form the ledger history. Even the most recent validated ledger is part of history, as it represents the state of the network as of a short time ago. In the present, the network is evaluating transactions which may be applied and finalized in the next ledger version. While this evaluation is happening, the network has candidate ledger versions that are not yet validated. The XRP Ledger has a new ledger version every several seconds. When the network agrees on the contents of a ledger version, that ledger version is _validated_, and its contents can never change. The validated ledger versions that preceded it form the ledger history. Even the most recent validated ledger is part of history, as it represents the state of the network as of a short time ago. In the present, the network is evaluating transactions which may be applied and finalized in the next ledger version. While this evaluation is happening, the network has candidate ledger versions that are not yet validated.
[![Figure 2: XRP Ledger Sequence and History](img/ledger-history.png)](img/ledger-history.png) [![Figure 2: XRP Ledger History](img/ledger-history.png)](img/ledger-history.png)
_Figure 2: XRP Ledger Sequence and History_ _Figure 2: XRP Ledger History_
A ledger version has two identifiers. One identifier is its _ledger index_, also called a _sequence number_. Ledger versions are numbered incrementally. For example, if the current ledger version has ledger index of 100, the previous has ledger index 99 and the next has ledger index 101. The other identifier is a _ledger hash_, which is a digital fingerprint of the ledger's contents. A ledger version has two identifiers. One identifier is its _ledger index_. Ledger versions are numbered incrementally. For example, if the current ledger version has ledger index of 100, the previous has ledger index 99 and the next has ledger index 101. The other identifier is a _ledger hash_, which is a digital fingerprint of the ledger's contents.
As servers propose transactions to apply to the ledger, they may create several candidate ledger versions with slightly different contents. These candidate ledger versions have the same ledger index but different ledger hashes. Of the many candidates, only one can become validated. All the other candidate ledger versions are discarded. Thus, there is exactly one validated ledger hash for each ledger index in history. As servers propose transactions to apply to the ledger, they may create several candidate ledger versions with slightly different contents. These candidate ledger versions have the same ledger index but different ledger hashes. Of the many candidates, only one can become validated. All the other candidate ledger versions are discarded. Thus, there is exactly one validated ledger hash for each ledger index in history.
@@ -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_ _Figure 4: Participants in the XRP Ledger Protocol_
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>. 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 history. <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. 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.

20
content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md
View File

@@ -382,7 +382,7 @@ Each field of the `cluster` object is the public key of that `rippled` server's
| `Field` | Type | Description | | `Field` | Type | Description |
|:--------|:-------|:----------------------------------------------------------| |:--------|:-------|:----------------------------------------------------------|
| `tag` | String | The display name for this cluster member as defined in the config file. | | `tag` | String | The display name for this cluster member as defined in the config file. |
| `fee` | Number | (May be omitted) The load multiplier this cluster member is applying to the [transaction cost](transaction-cost.html) | | `fee` | Number | _(May be omitted)_ The load multiplier this cluster member is applying to the [transaction cost](transaction-cost.html) |
| `age` | Number | The number of seconds since the last cluster report from this cluster member. | | `age` | Number | The number of seconds since the last cluster report from this cluster member. |
Each member of the `peers` array is a peer object with the following fields: Each member of the `peers` array is a peer object with the following fields:
@@ -390,19 +390,19 @@ Each member of the `peers` array is a peer object with the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:-------------------|:--------|:----------------------------------------------| |:-------------------|:--------|:----------------------------------------------|
| `address` | String | The IP address and port where this peer is connected | | `address` | String | The IP address and port where this peer is connected |
| `cluster` | Boolean | (May be omitted) If `true`, the current server and the peer server are part of the same `rippled` cluster. | | `cluster` | Boolean | _(May be omitted)_ If `true`, the current server and the peer server are part of the same `rippled` cluster. |
| `name` | String | (May be omitted) If the peer is part of the same cluster, this is the display name for that server as defined in the config file. | | `name` | String | _(May be omitted)_ If the peer is part of the same cluster, this is the display name for that server as defined in the config file. |
| `complete_ledgers` | String | Range expression indicating the [ledger indexes][ledger index] of the ledger versions the peer `rippled` server has available | | `complete_ledgers` | String | Range expression indicating the [ledger indexes][ledger index] of the ledger versions the peer `rippled` server has available |
| `inbound` | Boolean | (May be omitted) If `true`, the peer is connecting to the local server. | | `inbound` | Boolean | _(May be omitted)_ If `true`, the peer is connecting to the local server. |
| `latency` | Number | The network latency to the peer (in milliseconds) | | `latency` | Number | The network latency to the peer (in milliseconds) |
| `ledger` | String | The hash of the peer's most recently closed ledger | | `ledger` | String | The identifying [hash][Hash] of the peer's most recently closed ledger |
| `load` | Number | A measure of the amount of load the peer server is putting on the local server. Larger numbers indicate more load. (The units by which load is measured are not formally defined.) | | `load` | Number | A measure of the amount of load the peer server is putting on the local server. Larger numbers indicate more load. (The units by which load is measured are not formally defined.) |
| `protocol` | String | (May be omitted) The protocol version that the peer is using, if not the same as the local server. | | `protocol` | String | _(May be omitted)_ The protocol version that the peer is using, if not the same as the local server. |
| `public_key` | String | (May be omitted) A public key that can be used to verify the integrity of the peer's messages. This is not the same key that is used for validations, but it follows the same format. | | `public_key` | String | _(May be omitted)_ A public key that can be used to verify the integrity of the peer's messages. This is not the same key that is used for validations, but it follows the same format. |
| `sanity` | String | (May be omitted) Whether this peer is following the same rules and ledger sequence as the current server. A value of `insane` probably indicates that the peer is part of a parallel network. The value `unknown` indicates that the current server is unsure whether the peer is compatible. <!-- STYLE_OVERRIDE: insane --> | | `sanity` | String | _(May be omitted)_ Whether this peer is following the same rules and ledger history as the current server. A value of `insane` probably indicates that the peer is part of a [parallel network](parallel-networks.html). The value `unknown` indicates that the current server is unsure whether the peer is compatible. <!-- STYLE_OVERRIDE: insane --> |
| `status` | String | (May be omitted) The most recent status message from the peer. Could be `connecting`, `connected`, `monitoring`, `validating`, or `shutting`. | | `status` | String | _(May be omitted)_ The most recent status message from the peer. Could be `connecting`, `connected`, `monitoring`, `validating`, or `shutting`. |
| `uptime` | Number | The number of seconds that your `rippled` server has been continuously connected to this peer. [New in: rippled 0.30.1][] | | `uptime` | Number | The number of seconds that your `rippled` server has been continuously connected to this peer. [New in: rippled 0.30.1][] |
| `version` | string | (May be omitted) The `rippled` version number of the peer server | | `version` | string | _(May be omitted)_ The `rippled` version number of the peer server |
### Possible Errors ### Possible Errors

8
content/references/rippled-api/ledger-data-formats/ledger-header.md
View File

@@ -8,10 +8,10 @@ Every ledger version has a unique header that describes the contents. You can lo
| `ledger_index` | String | UInt32 | The [ledger index][Ledger Index] of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number. | | `ledger_index` | String | UInt32 | The [ledger index][Ledger Index] of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number. |
| `ledger_hash` | String | Hash256 | The [SHA-512Half][] of this ledger version. This serves as a unique identifier for this ledger and all its contents. | | `ledger_hash` | String | Hash256 | The [SHA-512Half][] of this ledger version. This serves as a unique identifier for this ledger and all its contents. |
| `account_hash` | String | Hash256 | The [SHA-512Half][] of this ledger's state tree information. | | `account_hash` | String | Hash256 | The [SHA-512Half][] of this ledger's state tree information. |
| `close_time` | Number | UInt32 | The approximate time this ledger closed, as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00. This value is rounded based on the `close_time_resolution`, so later ledgers can have the same value. | | `close_time` | Number | UInt32 | The approximate time this ledger version closed, as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00. This value is rounded based on the `close_time_resolution`. |
| `closed` | Boolean | bool | If true, this ledger version is no longer accepting new transactions. (However, unless this ledger version is validated, it might be replaced by a different ledger version with a different set of transactions.) | | `closed` | Boolean | Boolean | If `true`, this ledger version is no longer accepting new transactions. (However, unless this ledger version is validated, it might be replaced by a different ledger version with a different set of transactions.) |
| `parent_hash` | String | Hash256 | The `ledger_hash` value of the previous ledger that was used to build this one. If there are different versions of the previous ledger index, this indicates from which one the ledger was derived. | | `parent_hash` | String | Hash256 | The `ledger_hash` value of the previous ledger version that is the direct predecessor of this one. If there are different versions of the previous ledger index, this indicates from which one the ledger was derived. |
| `total_coins` | String | UInt64 | The total number of [drops of XRP][XRP, in drops] owned by accounts in the ledger. This omits XRP that has been destroyed by transaction fees. The actual amount of XRP in circulation is lower because some accounts are "black holes" whose keys are not known by anyone. | | `total_coins` | String | UInt64 | The total number of [drops of XRP][] owned by accounts in the ledger. This omits XRP that has been destroyed by transaction fees. The actual amount of XRP in circulation is lower because some accounts are "black holes" whose keys are not known by anyone. |
| `transaction_hash` | String | Hash256 | The [SHA-512Half][] of the transactions included in this ledger. | | `transaction_hash` | String | Hash256 | The [SHA-512Half][] of the transactions included in this ledger. |
| `close_time_resolution` | Number | Uint8 | An integer in the range \[2,120\] indicating the maximum number of seconds by which the `close_time` could be rounded. | | `close_time_resolution` | Number | Uint8 | An integer in the range \[2,120\] indicating the maximum number of seconds by which the `close_time` could be rounded. |
| [`closeFlags`](#close-flags) | (Omitted) | UInt8 | A bit-map of flags relating to the closing of this ledger. | | [`closeFlags`](#close-flags) | (Omitted) | UInt8 | A bit-map of flags relating to the closing of this ledger. |

18
content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md
View File

@@ -1,7 +1,7 @@
# account_offers # account_offers
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountOffers.cpp "Source") [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountOffers.cpp "Source")
The `account_offers` method retrieves a list of offers made by a given account that are outstanding as of a particular ledger version. The `account_offers` method retrieves a list of [offers](offers.html) made by a given [account](accounts.html) that are outstanding as of a particular [ledger version](ledgers.html).
## Request Format ## Request Format
@@ -155,14 +155,14 @@ An example of a successful response:
The response follows the [standard format][], with a successful result containing the following fields: The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:-----------------------|:-------------------------------------------|:-------| |:-----------------------|:--------------------------|:------------------------|
| `account` | String | Unique [Address][] identifying the account that made the offers | | `account` | String | Unique [Address][] identifying the account that made the offers |
| `offers` | Array | Array of objects, where each object represents an offer made by this account that is outstanding as of the requested ledger version. If the number of offers is large, only returns up to `limit` at a time. | | `offers` | Array | Array of objects, where each object represents an offer made by this account that is outstanding as of the requested ledger version. If the number of offers is large, only returns up to `limit` at a time. |
| `ledger_current_index` | Integer | (Omitted if `ledger_hash` or `ledger_index` provided) Sequence number of the ledger version used when retrieving this data. [New in: rippled 0.26.4-sp1][] | | `ledger_current_index` | Number - [Ledger Index][] | _(Omitted if `ledger_hash` or `ledger_index` provided)_ The ledger index of the current in-progress ledger version, which was used when retrieving this data. [New in: rippled 0.26.4-sp1][] |
| `ledger_index` | Integer | (Omitted if `ledger_current_index` provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. [New in: rippled 0.26.4-sp1][] | | `ledger_index` | Number - [Ledger Index][] | _(Omitted if `ledger_current_index` provided instead)_ The ledger index of the ledger version that was used when retrieving this data, as requested. [New in: rippled 0.26.4-sp1][] |
| `ledger_hash` | String | _(May be omitted)_ Hex hash, provided in the request, of the ledger version that was used when retrieving this data. [New in: rippled 0.26.4-sp1][] | | `ledger_hash` | String - [Hash][] | _(May be omitted)_ The identifying hash of the ledger version that was used when retrieving this data. [New in: rippled 0.26.4-sp1][] |
| `marker` | [Marker][] | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. [New in: rippled 0.26.4][] | | `marker` | [Marker][] | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. [New in: rippled 0.26.4][] |
Each offer object contains the following fields: Each offer object contains the following fields:

18
content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md
View File

@@ -199,15 +199,15 @@ An example of a successful response:
The response follows the [standard format][], with a successful result containing the following fields: The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:-----------------------|:-------|:-------------------------------------------| |:-----------------------|:--------------------------|:------------------------|
| `account` | String | Unique [Address][] identifying the account that issued the balances. | | `account` | String - [Address][] | The address of the account that issued the balances. |
| `obligations` | Object | (Omitted if empty) Total amounts issued to addresses not excluded, as a map of currencies to the total value issued. | | `obligations` | Object | (Omitted if empty) Total amounts issued to addresses not excluded, as a map of currencies to the total value issued. |
| `balances` | Object | (Omitted if empty) Amounts issued to the `hotwallet` addresses from the request. The keys are addresses and the values are arrays of currency amounts they hold. | | `balances` | Object | _(Omitted if empty)_ Amounts issued to the `hotwallet` addresses from the request. The keys are addresses and the values are arrays of currency amounts they hold. |
| `assets` | Object | (Omitted if empty) Total amounts held that are issued by others. In the recommended configuration, the [issuing address](issuing-and-operational-addresses.html) should have none. | | `assets` | Object | _(Omitted if empty)_ Total amounts held that are issued by others. In the recommended configuration, the [issuing address](issuing-and-operational-addresses.html) should have none. |
| `ledger_hash` | String | (May be omitted) The identifying hash of the ledger that was used to generate this response. | | `ledger_hash` | String - [Hash][] | _(May be omitted)_ The identifying hash of the ledger version that was used to generate this response. |
| `ledger_index` | Number | _(May be omitted)_ The ledger index of the ledger version that was used to generate this response. | | `ledger_index` | Number - [Ledger Index][] | _(May be omitted)_ The ledger index of the ledger version that was used to generate this response. |
| `ledger_current_index` | Number | (May be omitted) The sequence number of the current in-progress ledger version that was used to generate this response. | | `ledger_current_index` | Number - [Ledger Index][] | _(Omitted if `ledger_current_index` is provided)_ The [ledger index][] of the current in-progress ledger version, which was used to retrieve this information. |
## Possible Errors ## Possible Errors

14
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md
View File

@@ -155,13 +155,13 @@ An example of a successful response:
The response follows the [standard format][], with a successful result containing the following fields: The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:-----------------------|:-------------------------------------------|:------------------------------------------| |:-----------------------|:--------------------------|:------------------------|
| `ledger_current_index` | Integer | (Omitted if ledger version provided) Sequence number of the ledger version used when retrieving this data. | | `ledger_current_index` | Number - [Ledger Index][] | _(Omitted if `ledger_current_index` is provided)_ The [ledger index][] of the current in-progress ledger version, which was used to retrieve this information. |
| `ledger_index` | Integer | (Omitted if ledger\_current\_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. | | `ledger_index` | Number - [Ledger Index][] | _(Omitted if `ledger_current_index` provided)_ The ledger index of the ledger version that was used when retrieving this data, as requested. |
| `ledger_hash` | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. | | `ledger_hash` | String - [Hash][] | _(May be omitted)_ The identifying hash of the ledger version that was used when retrieving this data, as requested. |
| `marker` | [Marker][] | (May be omitted) Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. | | `marker` | [Marker][] | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. |
| `offers` | Array | Array of offer objects, each of which has the fields of an [Offer object](offer.html) | | `offers` | Array | Array of offer objects, each of which has the fields of an [Offer object](offer.html) |
In addition to the standard Offer fields, the following fields may be included in members of the `offers` array: In addition to the standard Offer fields, the following fields may be included in members of the `offers` array:

18
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/deposit_authorized.md
View File

@@ -117,15 +117,15 @@ Loading: "/etc/rippled.cfg"
The response follows the [standard format][], with a successful result containing the following fields: The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:-----------------------|:---------------------|:-----------------------------| |:-----------------------|:--------------------------|:------------------------|
| `deposit_authorized` | Boolean | Whether the specified source account is authorized to send payments directly to the destination account. If `true`, either the destination account does not require [Deposit Authorization](depositauth.html) or the source account is preauthorized. | | `deposit_authorized` | Boolean | Whether the specified source account is authorized to send payments directly to the destination account. If `true`, either the destination account does not require [Deposit Authorization](depositauth.html) or the source account is preauthorized. |
| `destination_account` | String - [Address][] | The destination account specified in the request. | | `destination_account` | String - [Address][] | The destination account specified in the request. |
| `ledger_hash` | String | _(May be omitted)_ The identifying hash of the ledger that was used to generate this response. | | `ledger_hash` | String | _(May be omitted)_ The identifying hash of the ledger that was used to generate this response. |
| `ledger_index` | Number | _(May be omitted)_ The [ledger index][] of the ledger version that was used to generate this response. | | `ledger_index` | Number - [Ledger Index][] | _(May be omitted)_ The ledger index of the ledger version that was used to generate this response. |
| `ledger_current_index` | Number | _(May be omitted)_ The sequence number of the current in-progress ledger version that was used to generate this response. | | `ledger_current_index` | Number - [Ledger Index][] | _(May be omitted)_ The ledger index of the current in-progress ledger version, which was used to generate this response. |
| `source_account` | String - [Address][] | The source account specified in the request. | | `source_account` | String - [Address][] | The source account specified in the request. |
| `validated` | Boolean | _(May be omitted)_ If `true`, the information comes from a validated ledger version. | | `validated` | Boolean | _(May be omitted)_ If `true`, the information comes from a validated ledger version. |
**Note:** A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](trust-lines-and-issuing.html) for the specified currency, or there may not be sufficient liquidity to deliver a payment. **Note:** A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](trust-lines-and-issuing.html) for the specified currency, or there may not be sufficient liquidity to deliver a payment.

48
content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md
View File

@@ -151,18 +151,18 @@ The `ledger` stream only sends `ledgerClosed` messages when [the consensus proce
The fields from a ledger stream message are as follows: The fields from a ledger stream message are as follows:
| `Field` | Type | Description | | `Field` | Type | Description |
|:--------------------|:-----------------|:------------------------------------| |:--------------------|:--------------------------|:---------------------------|
| `type` | String | `ledgerClosed` indicates this is from the ledger stream | | `type` | String | `ledgerClosed` indicates this is from the ledger stream |
| `fee_base` | Unsigned Integer | Cost of the 'reference transaction' in drops of XRP. (See [Transaction Cost](transaction-cost.html) If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new transaction cost applies to all transactions after this ledger. | | `fee_base` | Number | The [reference transaction cost](transaction-cost.html#reference-transaction-cost) as of this ledger version, in [drops of XRP][]. If this ledger version includes a [SetFee pseudo-transaction](setfee.html) the new transaction cost applies starting with the following ledger version. |
| `fee_ref` | Unsigned Integer | Cost of the 'reference transaction' in 'fee units'. | | `fee_ref` | Number | The [reference transaction cost](transaction-cost.html#reference-transaction-cost) in "fee units". |
| `ledger_hash` | String | Unique hash of the ledger that was closed, as hex | | `ledger_hash` | String - [Hash][] | The identifying hash of the ledger version that was closed. |
| `ledger_index` | Unsigned Integer | Sequence number of the ledger that was closed | | `ledger_index` | Number - [Ledger Index][] | The ledger index of the ledger that was closed. |
| `ledger_time` | Unsigned Integer | The time this ledger was closed, in [seconds since the Ripple Epoch][] | | `ledger_time` | Number | The time this ledger was closed, in [seconds since the Ripple Epoch][] |
| `reserve_base` | Unsigned Integer | The minimum reserve, in drops of XRP, that is required for an account. If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new base reserve applies after this ledger. | | `reserve_base` | Number | The minimum [reserve](reserves.html), in [drops of XRP][], that is required for an account. If this ledger version includes a [SetFee pseudo-transaction](setfee.html) the new base reserve applies starting with the following ledger version. |
| `reserve_inc` | Unsigned Integer | The increase in account reserve that is added for each item the account owns, such as offers or trust lines. If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new owner reserve applies after this ledger. | | `reserve_inc` | Number | The [owner reserve](reserves.html#owner-reserves) for each object an account owns in the ledger, in [drops of XRP][]. If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new owner reserve applies after this ledger. |
| `txn_count` | Unsigned Integer | Number of new transactions included in this ledger | | `txn_count` | Number | Number of new transactions included in this ledger version. |
| `validated_ledgers` | String | (May be omitted) Range of ledgers that the server has available. This may be discontiguous. This field is not returned if the server is not connected to the network, or if it is connected but has not yet obtained a ledger from the network. | | `validated_ledgers` | String | _(May be omitted)_ Range of ledgers that the server has available. This may be discontiguous. This field is not returned if the server is not connected to the network, or if it is connected but has not yet obtained a ledger from the network. |
## Validations Stream ## Validations Stream
@@ -338,18 +338,18 @@ The `accounts_proposed` subscription works the same way, except it also includes
Transaction stream messages have the following fields: Transaction stream messages have the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:------------------------|:-----------------|:--------------------------------| |:------------------------|:--------------------------|:-----------------------|
| `type` | String | `transaction` indicates this is the notification of a transaction, which could come from several possible streams. | | `type` | String | `transaction` indicates this is the notification of a transaction, which could come from several possible streams. |
| `engine_result` | String | String [Transaction result code](transaction-results.html) | | `engine_result` | String | String [Transaction result code](transaction-results.html) |
| `engine_result_code` | Number | Numeric [transaction response code](transaction-results.html), if applicable. | | `engine_result_code` | Number | Numeric [transaction response code](transaction-results.html), if applicable. |
| `engine_result_message` | String | Human-readable explanation for the transaction response | | `engine_result_message` | String | Human-readable explanation for the transaction response |
| `ledger_current_index` | Unsigned Integer | (Omitted for validated transactions) Sequence number of the current ledger version for which this transaction is currently proposed | | `ledger_current_index` | Number - [Ledger Index][] | _(Unvalidated transactions only)_ The ledger index of the current in-progress [ledger version](ledgers.html) for which this transaction is currently proposed. |
| `ledger_hash` | String | (Omitted for unvalidated transactions) Unique hash of the ledger version that includes this transaction, as hex | | `ledger_hash` | String - [Hash][] | _(Validated transactions only)_ The identifying hash of the ledger version that includes this transaction |
| `ledger_index` | Unsigned Integer | (Omitted for unvalidated transactions) Sequence number of the ledger version that includes this transaction | | `ledger_index` | Number - [Ledger Index][] | _(Validated transactions only)_ The ledger index of the ledger version that includes this transaction. |
| `meta` | Object | (Omitted for unvalidated transactions) Various metadata about the transaction, including which ledger entries it affected | | `meta` | Object | _(Validated transactions only)_ The [transaction metadata](transaction-metadata.html), which shows the exact outcome of the transaction in detail. |
| `transaction` | Object | The [definition of the transaction](transaction-formats.html) in JSON format | | `transaction` | Object | The [definition of the transaction](transaction-formats.html) in JSON format |
| `validated` | Boolean | If true, this transaction is included in a validated ledger. Responses from the `transaction` stream should always be validated. | | `validated` | Boolean | If `true`, this transaction is included in a validated ledger and its outcome is final. Responses from the `transaction` stream should always be validated. |
## Peer Status Stream ## Peer Status Stream

12
content/references/rippled-api/public-rippled-methods/transaction-methods/transaction_entry.md
View File

@@ -195,12 +195,12 @@ An example of a successful response:
The response follows the [standard format][], with a successful result containing the following fields: The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description | | `Field` | Type | Description |
|:---------------|:-----------------|:-----------------------------------------| |:---------------|:--------------------------|:--------------------------------|
| `ledger_index` | Unsigned Integer | Sequence number of the ledger version the transaction was found in; this is the same as the one from the request. | | `ledger_index` | Number - [Ledger Index][] | The ledger index of the ledger version the transaction was found in; this is the same as the one from the request. |
| `ledger_hash` | String | (May be omitted) Unique hash of the ledger version the transaction was found in; this is the same as the one from the request. | | `ledger_hash` | String - [Hash][] | _(May be omitted)_ The identifying hash of the ledger version the transaction was found in; this is the same as the one from the request. |
| `metadata` | Object | Various metadata about the transaction. | | `metadata` | Object | The [transaction metadata](transaction-metadata.html), which shows the exact results of the transaction in detail. |
| `tx_json` | Object | JSON representation of the [Transaction object](transaction-formats.html) | | `tx_json` | Object | JSON representation of the [Transaction object](transaction-formats.html) |
There are a couple possible reasons the server may fail to find the transaction: There are a couple possible reasons the server may fail to find the transaction:

30
content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md
View File

@@ -44,35 +44,35 @@ To connect your `rippled` server to the XRP Testnet or Devnet, set the following
# #
# [validator_list_keys] # [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
2b. Changes to connect to the devnet 2b. Changes to connect to the devnet
a. Comment out the following sections as follows: a. Comment out the following sections as follows:
# [validator_list_sites] # [validator_list_sites]
# https://vl.altnet.rippletest.net # https://vl.altnet.rippletest.net
# [validator_list_keys] # [validator_list_keys]
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 # ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
# [validator_list_sites] # [validator_list_sites]
# https://vl.ripple.com # https://vl.ripple.com
# #
# [validator_list_keys] # [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
b. Add the following trusted validators to the validator.txt file: b. Add the following trusted validators to the validator.txt file:
# Hard-coded List of Devnet Validators # Hard-coded List of Devnet Validators
[validators] [validators]
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
3. Restart `rippled`. 3. Restart `rippled`.
@@ -86,7 +86,7 @@ To connect your `rippled` server to the XRP Testnet or Devnet, set the following
$ ./rippled --rpc_ip 34.83.125.324:51234 server_info | grep seq $ ./rippled --rpc_ip 34.83.125.324:51234 server_info | grep seq
The following command checks your local `rippled`'s latest validated ledger sequence: The following command checks your local `rippled`'s latest validated ledger index:
$ ./rippled server_info | grep seq $ ./rippled server_info | grep seq

2
content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.md
View File

@@ -29,7 +29,7 @@ If none of the above apply, please report the issue to Ripple as a security-sens
## Already validated sequence at or past ## Already validated sequence at or past
Log messages such as the following indicate that a server received validations for different ledger sequences out of order. Log messages such as the following indicate that a server received validations for different ledger indexes out of order.
```text ```text
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1 2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1

10
content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
View File

@@ -44,9 +44,9 @@ The XRP Ledger provides several APIs for submitting transactions, including [`ri
APIs may return provisional results based on the result of applying candidate transactions to the current, in-progress ledger. Applications must not confuse these with the final, *immutable*, results of a transaction. Immutable results are found only in validated ledgers. Applications may need to query the status of a transaction repeatedly, until the ledger containing the transaction results is validated. APIs may return provisional results based on the result of applying candidate transactions to the current, in-progress ledger. Applications must not confuse these with the final, *immutable*, results of a transaction. Immutable results are found only in validated ledgers. Applications may need to query the status of a transaction repeatedly, until the ledger containing the transaction results is validated.
While applying transactions, `rippled` servers use the *last validated ledger*, a snapshot of the ledger state based on transactions the entire network has validated. The process of consensus and validation apply a set of new transactions to the last validated ledger in canonical order, resulting in a new validated ledger. This new validated ledger instance and the ones that preceded it form the ledger history. While applying transactions, `rippled` servers use the *last validated ledger*, a snapshot of the ledger state based on transactions the entire network has validated. The process of consensus and validation apply a set of new transactions to the last validated ledger in canonical order, resulting in a new validated ledger. This new validated ledger version and the ones that preceded it form the ledger history.
Each validated ledger instance has a sequence number, which is one greater than the sequence number of the preceding instance. Each ledger also has an identifying hash value, which is uniquely determined from its contents. There may be many different versions of in-progress ledgers, which have the same sequence number but different hash values. Only one version can ever be validated. Each validated ledger version has a ledger index, which is 1 greater than the ledger index of the previous ledger version. Each ledger also has an identifying hash value, which is uniquely determined from its contents. There may be many different versions of in-progress ledgers, which have the same ledger index but different hash values. Only one version can ever be validated.
Each validated ledger has a canonical order in which transactions apply. This order is deterministic based on the final transaction set of the ledger. In contrast, each `rippled` server's in-progress ledger is calculated incrementally, as transactions are received. The order in which transactions execute provisionally is usually not the same as the order in which transactions execute to build a new validated ledger. This is one reason why the provisional outcome of a transaction may be different than the final result. For example, a payment may achieve a different final exchange rate depending on whether it executes before or after another payment that would consume the same offer. Each validated ledger has a canonical order in which transactions apply. This order is deterministic based on the final transaction set of the ledger. In contrast, each `rippled` server's in-progress ledger is calculated incrementally, as transactions are received. The order in which transactions execute provisionally is usually not the same as the order in which transactions execute to build a new validated ledger. This is one reason why the provisional outcome of a transaction may be different than the final result. For example, a payment may achieve a different final exchange rate depending on whether it executes before or after another payment that would consume the same offer.
@@ -54,7 +54,7 @@ Each validated ledger has a canonical order in which transactions apply. This or
### LastLedgerSequence ### LastLedgerSequence
`LastLedgerSequence` is an optional [parameter of all transactions](transaction-common-fields.html). This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger instance. The XRP Ledger never includes a transaction in a ledger instance whose sequence number is higher than the transaction's `LastLedgerSequence` parameter. `LastLedgerSequence` is an optional [parameter of all transactions](transaction-common-fields.html). This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger version. The XRP Ledger never includes a transaction in a ledger version whose ledger index is higher than the transaction's `LastLedgerSequence` parameter.
Use the `LastLedgerSequence` parameter to prevent undesirable cases where a transaction is not confirmed promptly but could be included in a future ledger. You should specify the `LastLedgerSequence` parameter on every transaction. Automated processes should use a value of 4 greater than the last validated ledger index to make sure that a transaction is validated or rejected in a predictable and prompt way. Use the `LastLedgerSequence` parameter to prevent undesirable cases where a transaction is not confirmed promptly but could be included in a future ledger. You should specify the `LastLedgerSequence` parameter on every transaction. Automated processes should use a value of 4 greater than the last validated ledger index to make sure that a transaction is validated or rejected in a predictable and prompt way.
@@ -327,7 +327,7 @@ Request:
Notice the application specifies the account sequence `"Sequence": 4`, learned from an earlier call to `account_info`, to avoid `tefPAST_SEQ` errors. Notice the application specifies the account sequence `"Sequence": 4`, learned from an earlier call to `account_info`, to avoid `tefPAST_SEQ` errors.
Notice also the `LastLedgerSequence` based on the last validated ledger our application learned from `server_state`. The recommendation for backend applications is to use *(last validated ledger sequence + 4)*. Alternately, use a value of *(current ledger + 3)*. If `LastLedgerSequence` is miscalculated and less than the last validated ledger, the transaction fails with `tefMAX_LEDGER` error. Notice also the `LastLedgerSequence` based on the last validated ledger our application learned from `server_state`. The recommendation for backend applications is to use *(last validated ledger index + 4)*. Alternately, use a value of *(current ledger + 3)*. If `LastLedgerSequence` is miscalculated and less than the last validated ledger, the transaction fails with `tefMAX_LEDGER` error.
Response: Response:
@@ -466,7 +466,7 @@ Response:
This example response shows `"validated": true`, indicating the transaction has been included in a validated ledger, so the result of the transaction is immutable. Further, the metadata includes `"TransactionResult": "tesSUCCESS"`, indicating the transaction was applied to the ledger. This example response shows `"validated": true`, indicating the transaction has been included in a validated ledger, so the result of the transaction is immutable. Further, the metadata includes `"TransactionResult": "tesSUCCESS"`, indicating the transaction was applied to the ledger.
If the response does not include `"validated": true`, the result is provisional and subject to change. To retrieve a final result, applications must invoke the `tx` method again, allowing enough time for the network to validate more ledger instances. It may be necessary to wait for the ledger specified in `LastLedgerSequence` to be validated, although if the transaction is included in an earlier validated ledger the result becomes immutable at that time. If the response does not include `"validated": true`, the result is provisional and subject to change. To retrieve a final result, applications must invoke the `tx` method again, allowing enough time for the network to validate more ledger versions. It may be necessary to wait for the ledger specified in `LastLedgerSequence` to be validated, although if the transaction is included in an earlier validated ledger the result becomes immutable at that time.
#### Verify Missing Transaction #### Verify Missing Transaction