ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 15:15: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

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]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
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]
# https://vl.altnet.rippletest.net
# [validator_list_keys]
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
b. Add the following trusted validators to the validator.txt file:
# Hard-coded List of Devnet Validators
[validators]
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
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
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

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
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
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.
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.
@@ -54,7 +54,7 @@ Each validated ledger has a canonical order in which transactions apply. This or
### 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.
@@ -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 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:
@@ -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.
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