mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
1.8.0 is dead, long live 1.8.1
This commit is contained in:
mDuo13
@@ -40,7 +40,7 @@
|
||||
"1.6.0",
|
||||
"1.7.0",
|
||||
"1.7.2",
|
||||
"1.8.0",
|
||||
"1.8.1",
|
||||
] %}
|
||||
|
||||
{% for v in rippled_versions %}
|
||||
|
||||
@@ -57,7 +57,7 @@ Theoretically, a `tfLostMajority` EnableAmendment pseudo-transaction could be in
|
||||
|
||||
## Amendment Voting
|
||||
|
||||
Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. Operators of `rippled` validators [configure their servers](configure-amendment-voting.html) to vote in favor or against each inactive amendment. Server operators can change their votes at any time. If the operator does not choose a setting for a particular amendment, the server uses a default vote which is defined in the source code. The default can change in new software releases. For example, version 2.0 of the server might understand a new amendment but vote against it by default; then version 2.1 of the server might vote in favor of the same amendment by default. [Updated in: rippled 1.8.0][]
|
||||
Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. Operators of `rippled` validators [configure their servers](configure-amendment-voting.html) to vote in favor or against each inactive amendment. Server operators can change their votes at any time. If the operator does not choose a setting for a particular amendment, the server uses a default vote which is defined in the source code. The default can change in new software releases. For example, version 2.0 of the server might understand a new amendment but vote against it by default; then version 2.1 of the server might vote in favor of the same amendment by default. [Updated in: rippled 1.8.1][]
|
||||
|
||||
To become enabled, an amendment must be supported by at least 80% of trusted validators continuously for two weeks. If support for an amendment goes below 80% of trusted validators, the amendment is temporarily rejected. The two week period starts over if the amendment regains support of at least 80% of trusted validators. (This can occur if validators vote differently, or if there is a change in which validators are trusted.) An amendment can gain and lose a majority any number of times before it becomes permanently enabled.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ The server selects and downloads additional shards until it reaches the maximum
|
||||
|
||||
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce "proof trees" or "ledger deltas" which shows how each ledger in the blockchain's history was the result of applying transactions to the previous state. Since servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
|
||||
|
||||
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce binary-identical data regardless of what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) [New in: rippled 1.8.0][]
|
||||
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce binary-identical data regardless of what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) [New in: rippled 1.8.1][]
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -127,10 +127,10 @@ Each member of the `peers` array of the response is an object that describes one
|
||||
| `Field` | Type | Description |
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `complete_shards` | String | The range of complete history shards this peer has available. This may be disjointed. For example, `1-2,5,7-9` indicates that shards 1, 2, 5, 7, 8, and 9 are available. |
|
||||
| `incomplete_shards` | String | _(May be omitted)_ A comma-separated list of history shards this peer has partially downloaded, and percent completion for each. For example, `1:50,2:25` indicates that shard 1 is 50% downloaded and shard 2 is 25% downloaded. [New in: rippled 1.8.0][] |
|
||||
| `incomplete_shards` | String | _(May be omitted)_ A comma-separated list of history shards this peer has partially downloaded, and percent completion for each. For example, `1:50,2:25` indicates that shard 1 is 50% downloaded and shard 2 is 25% downloaded. [New in: rippled 1.8.1][] |
|
||||
| `public_key` | String | _(Omitted unless the request specified `"public_key": true`)_ The public key this peer uses for peer-to-peer communications, in the XRP Ledger's [base58 format](base58-encodings.html). |
|
||||
|
||||
The `ip` field is no longer provided. [Removed in: rippled 1.8.0][]
|
||||
The `ip` field is no longer provided. [Removed in: rippled 1.8.1][]
|
||||
|
||||
|
||||
### Possible Errors
|
||||
|
||||
@@ -89,7 +89,7 @@ The `streams` parameter provides access to the following default streams of info
|
||||
- `server` - Sends a message whenever the status of the `rippled` server (for example, network connectivity) changes
|
||||
- `validations` - Sends a message whenever the server receives a validation message, regardless of if the server trusts the validator. (An individual `rippled` declares a ledger validated when the server receives validation messages from at least a quorum of trusted validators.)
|
||||
|
||||
**Note:** The following streams are not available from servers in [Reporting Mode][]: `server`, `peer_status`, `consensus`. Reporting Mode servers return the error `reportingUnsupported` if you request one of these streams. [Updated in: rippled 1.8.0][]
|
||||
**Note:** The following streams are not available from servers in [Reporting Mode][]: `server`, `peer_status`, `consensus`. Reporting Mode servers return the error `reportingUnsupported` if you request one of these streams. [Updated in: rippled 1.8.1][]
|
||||
|
||||
Each member of the `books` array, if provided, is an object with the following fields:
|
||||
|
||||
@@ -217,7 +217,7 @@ The fields from a validations stream message are as follows:
|
||||
| `type` | String | The value `validationReceived` indicates this is from the validations stream. |
|
||||
| `amendments` | Array of Strings | _(May be omitted)_ The [amendments](amendments.html) this server wants to be added to the protocol. [New in: rippled 0.32.0][] |
|
||||
| `base_fee` | Integer | _(May be omitted)_ The unscaled transaction cost (`reference_fee` value) this server wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `cookie` | String - Number | _(May be omitted)_ An arbitrary value chosen by the server at startup. If the same validation key pair signs validations with different cookies concurrently, that usually indicates that multiple servers are incorrectly configured to use the same validation key pair. [New in: rippled 1.8.0][] |
|
||||
| `cookie` | String - Number | _(May be omitted)_ An arbitrary value chosen by the server at startup. If the same validation key pair signs validations with different cookies concurrently, that usually indicates that multiple servers are incorrectly configured to use the same validation key pair. [New in: rippled 1.8.1][] |
|
||||
| `flags` | Number | Bit-mask of flags added to this validation message. The flag `0x80000000` indicates that the validation signature is fully-canonical. The flag `0x00000001` indicates that this is a full validation; otherwise it's a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
|
||||
| `full` | Boolean | If `true`, this is a full validation. Otherwise, this is a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
|
||||
| `ledger_hash` | String | The identifying hash of the proposed ledger is being validated. |
|
||||
@@ -226,10 +226,10 @@ The fields from a validations stream message are as follows:
|
||||
| `master_key` | String | _(May be omitted)_ The validator's master public key, if the validator is using a validator token, in the XRP Ledger's [base58][] format. (See also: [Enable Validation on your `rippled` Server](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).) [New in: rippled 1.4.0][] |
|
||||
| `reserve_base` | Integer | _(May be omitted)_ The minimum reserve requirement (`account_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `reserve_inc` | Integer | _(May be omitted)_ The increment in the reserve requirement (`owner_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `server_version` | String - Number | _(May be omitted)_ An 64-bit integer that encodes the version number of the validating server. For example, `"1745990410175512576"`. Only provided once every 256 ledgers. [New in: rippled 1.8.0][] |
|
||||
| `server_version` | String - Number | _(May be omitted)_ An 64-bit integer that encodes the version number of the validating server. For example, `"1745990410175512576"`. Only provided once every 256 ledgers. [New in: rippled 1.8.1][] |
|
||||
| `signature` | String | The signature that the validator used to sign its vote for this ledger. |
|
||||
| `signing_time` | Number | When this validation vote was signed, in [seconds since the Ripple Epoch][]. [New in: rippled 0.32.0][] |
|
||||
| `validated_hash` | String | The unique hash of the proposed ledger this validation applies to. [New in: rippled 1.8.0][] |
|
||||
| `validated_hash` | String | The unique hash of the proposed ledger this validation applies to. [New in: rippled 1.8.1][] |
|
||||
| `validation_public_key` | String | The public key from the key-pair that the validator used to sign the message, in the XRP Ledger's [base58][] format. This identifies the validator sending the message and can also be used to verify the `signature`. If the validator is using a token, this is an ephemeral public key. |
|
||||
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Linuxでは、`rippled`が1回限りの`cron`構成を使用して最新バー
|
||||
|
||||
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
|
||||
|
||||
このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトは`rippled`サービスを再起動しません。手動再起動しますまで、以前のバージョンを実行し続けます。[新規: rippled 1.8.0][]
|
||||
このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトは`rippled`サービスを再起動しません。手動再起動しますまで、以前のバージョンを実行し続けます。[新規: rippled 1.8.1][]
|
||||
|
||||
3. 新しいリリースが公開された後、`rippled`サービスを手動再起動する。
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ To set up automatic updates, complete the following steps:
|
||||
|
||||
sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
|
||||
|
||||
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To avoid network instability from too many servers updating at the same time, this script does not automatically restart the server, so it continues to run the old version until it restarts. [Updated in: rippled 1.8.0][]
|
||||
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To avoid network instability from too many servers updating at the same time, this script does not automatically restart the server, so it continues to run the old version until it restarts. [Updated in: rippled 1.8.1][]
|
||||
|
||||
3. **Whenever a new release comes out,** you must manually restart the `rippled` service to switch to the updated software.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user