XRP Ledger (rippled server) version 1.6.0 has been released, introducing several new features including changes to the XRP Ledger’s consensus mechanism to make it even more robust in adverse conditions, as well as numerous bug fixes and optimizations.
About the update
Warren Paul Anderson (Ripple’s Head of Developer Relations), briefly summarized this huge update in a blog post.
“Version 1.6.0 includes a proposed change to harden validations, which will require an Amendment, and subsequent 80% quorum approval among the community of validators on Ripple’s recommended UNL for two-consecutive weeks. The change allows servers to detect accidental misconfiguration of validators, as well as potentially Byzantine behavior by malicious validators.
With the proposed hardened validations change, servers can now log a message to notify operators if they detect a single validator issuing validations for multiple, incompatible ledger versions, or validations from multiple servers sharing a key. As part of this update, validators report the version of rippled they are using, as well as the hash of the last ledger they consider to be fully validated, in validation messages.
Beginning with version 1.6.0, server operators can enable support for compressing peer-to-peer messages. This can save bandwidth at a cost of higher CPU usage. This support is disabled by default and should prove useful for servers with a large number of peers.
Version 1.6.0 also comes with a new Health Check Method to perform a simple HTTP request to get a summary of the health of the server: Healthy, Warning, or Critical.
Another known “fix” Amendment is being introduced in version 1.6.0, which fixes the 14 day timer to enable an Amendment to start at the correct quorum size due to rounding semantics.
The latest beta version includes a proposed change to the XRP Ledger consensus mechanism with an initial implementation of a Negative UNL, which can improve the liveness of the network during periods of network instability, by allowing servers to track which validators are temporarily offline and to adjust quorum calculations to match.
Ripple expects to run extensive public testing for the Negative UNL functionality on the XRP Ledger Devnet in the coming months. If public testing satisfies all requirements across security, reliability, stability, and performance, then the amendment could be included on an Amendment for quorum review in an upcoming version 2.0 release.
This release further demonstrates Ripple’s continued commitment to developing open protocols, such as the XRP Ledger.”
New and Improved Features
- Initial implementation of Negative UNL functionality: This change can improve the liveness of the network during periods of network instability, by allowing servers to track which validators are temporarily offline and to adjust quorum calculations to match. This change requires an amendment, but the amendment is not in the 1.6.0 release. Ripple expects to run extensive public testing for Negative UNL functionality on the Devnet in the coming weeks. If public testing satisfies all requirements across security, reliability, stability, and performance, then the amendment could be included in a version 2.0 release. [#3380]
- Validation Hardening: This change allows servers to detect accidental misconfiguration of validators, as well as potentially Byzantine behavior by malicious validators. Servers can now log a message to notify operators if they detect a single validator issuing validations for multiple, incompatible ledger versions, or validations from multiple servers sharing a key. As part of this update, validators report the version of
rippledthey are using, as well as the hash of the last ledger they consider to be fully validated, in validation messages. [#3291]
- Software Upgrade Monitoring & Notification: After the
HardenedValidationsamendment is enabled and the validators begin reporting the versions of
rippledthey are running, a server can check how many of the validators on its UNL run a newer version of the software than itself. If more than 60% of a server’s validators are running a newer version, the server writes a message to notify the operator to consider upgrading their software. [#3447]
- Link Compression: Beginning with 1.6.0, server operators can enable support for compressing peer-to-peer messages. This can save bandwidth at a cost of higher CPU usage, which should prove useful for servers with a large number of peers. This support is disabled by default and can be enabled in your server’s config file. [#3287]
- Unconditionalize Amendments that were enabled in 2017: This change removes legacy code which the network has not used since 2017. This change limits the ability to replay ledgers that rely on the pre-2017 behavior. [#3292]
- New Health Check Method: Perform a simple HTTP request to get a summary of the health of the server: Healthy, Warning, or Critical. [#3365]
- Start work on API version 2. Version 2 of the API will be part of a future release. The first breaking change will be to consolidate several closely related error messages that can occur when the server is not synced into a single “notSynced” error message. [#3269]
- Improved shard concurrency: Improvements to the shard engine have helped reduce the lock scope on all public functions, increasing the concurrency of the code. [#3251]
- Default Port: In the config file, the
[ips]stanzas now use the IANA-assigned port for the XRP Ledger protocol (2459) when no port is specified. The
connectAPI method also uses the same port by default. [#2861].
- Improve proposal and validation relaying. The peer-to-peer protocol always relays trusted proposals and validations (as part of the consensus process), but only relays untrusted proposals and validations in certain circumstances. This update adds configuration options so server operators can fine-tune how their server handles untrusted proposals and validations, and changes the default behavior to prioritize untrusted validations higher than untrusted proposals. [#3391]
- Various Build and CI Improvements including updates to RocksDB 6.7.3 [#3356], NuDB 2.0.3 [#3437], adjusting CMake settings so that rippled can be built as a submodule [#3449], and adding Travis CI settings for Ubuntu Bionic Beaver [#3319].
- Better documentation in the config file for online deletion and database tuning. [#3429]
- Fix the 14 day timer to enable amendment to start at the correct quorum size [#3396]
- Improve online delete backend lock which addresses a possibility in the online delete process where one or more backend shared pointer references may become invalid during rotation. [#3342]
- Address an issue that can occur during the loading of validator tokens, where a deliberately malformed token could cause the server to crash during startup. [#3326]
- Add delivered amount to GetAccountTransactionHistory. The delivered_amount field was not being populated when calling GetAccountTransactionHistory. In contrast, the delivered_amount field was being populated when calling GetTransaction. This change populates delivered_amount in the response to GetAccountTransactionHistory, and adds a unit test to make sure the results delivered by GetTransaction and GetAccountTransactionHistory match each other. [#3370]
- Fix build issues for GCC 10 [#3393]
- Fix historical ledger acquisition – this fixes an issue where historical ledgers were acquired only since the last online deletion interval instead of the configured value to allow deletion.[#3369]
- Fix build issue with Docker #3416]
- Add Shard family. The App Family utilizes a single shared Tree Node and Full Below cache for all history shards. This can create a problem when acquiring a shard that shares an account state node that was recently cached from another shard operation. The new Shard Family class solves this issue by managing separate Tree Node and Full Below caches for each shard. #3448]
- Amendment table clean up which fixes a calculation issue with majority. #3428]
- Add the
ledger_cleanercommand to rippled command line help [#3305]
- Various typo and comments fixes.
Rippled server operators are encouraged to explore the proposed Amendments highlighted in rippled version 1.6.0, and upgrade to rippled version 1.6.0 by Wednesday 2020-09-02, which is the earliest date that the Amendments could reach network quorum by the community of validators, in order to ensure service continuity.
XRP Ledger Testnet, which Ripple hosts for developer’s to test the latest stable version, will be upgraded to rippled version 1.6 on Wednesday, 2020/08/19.
For instructions on updating XRP Ledger on supported platforms, see here:
For other platforms, compile version 1.6.0 from source.
The first log entry should be the change setting the version:
commit 01bd5a2646cda78ee09d2067c287c8f89872736d Author: manojsdoshi <[email protected]> Date: Tue Aug 18 15:32:50 2020 -0700 Set version to 1.6.0
At the time of writing, 122 nodes out of 900 are already running the new version.