Skip to content

Releases: XRPLF/rippled

rippled (XRP Ledger server) Version 1.9.3

26 Aug 19:52
47dec46
Compare
Choose a tag to compare

Version 1.9.3 of rippled, the reference server implementation of the XRP Ledger protocol is now available. This release corrects minor technical flaws with the code that loads configured amendment votes after a startup and the copy constructor of PublicKey.

Install / Upgrade

On supported platforms, see the instructions on installing or updating rippled.

Changelog

Contributions

This releases contains the following bug fixes:

  • Change by-value to by-reference to persist vote: A minor technical flaw, caused by use of a copy instead of a reference, resulted in operator-configured "yes" votes to not be properly loaded after a restart. (#4256)
  • Properly handle self-assignment of PublicKey: The PublicKey copy assignment operator mishandled the case where a PublicKey would be assigned to itself, and could result in undefined behavior.

GitHub

The public source code repository for rippled is hosted on GitHub at https://github.com/XRPLF/rippled.

We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.

Credits

The following people contributed directly to this release:

rippled (XRP Ledger server) Version 1.9.2

26 Jul 20:19
e5275b8
Compare
Choose a tag to compare

Version 1.9.2 of rippled, the reference server implementation of the XRP Ledger protocol, is now available. This release includes several fixes and improvements, including a second new fix amendment to correct a bug in Non-Fungible Tokens (NFTs) code, a new API method for order book changes, less noisy logging, and other small fixes.

Action Required

This release introduces a two new amendments to the XRP Ledger protocol. The first, fixNFTokenNegOffer, fixes a bug in code associated with the NonFungibleTokensV1 amendment, originally introduced in version 1.9.0. The second, NonFungibleTokensV1_1, is a "roll-up" amendment that enables the NonFungibleTokensV1 feature plus the two fix amendments associated with it, fixNFTokenDirV1 and fixNFTokenNegOffer.

If you want to enable NFT code on the XRP Ledger Mainnet, you can vote in favor of only the NonFungibleTokensV1_1 amendment to support enabling the feature and fixes together, without risk that the unfixed NFT code may become enabled first.

These amendments are now open for voting according to the XRP Ledger's amendment process, which enables protocol changes following two weeks of >80% support from trusted validators.

If you operate an XRP Ledger server, then you should upgrade to version 1.9.2 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.

For more information about NFTs on the XRP Ledger, see NFT Conceptual Overview.

Install / Upgrade

On supported platforms, see the instructions on installing or updating rippled.

Changelog

This release contains the following features and improvements.

  • Introduce fixNFTokenNegOffer amendment. This amendment fixes a bug in the Non-Fungible Tokens (NFTs) functionality provided by the NonFungibleTokensV1 amendment (not currently enabled on Mainnet). The bug allowed users to place offers to buy tokens for negative amounts of money when using Brokered Mode. Anyone who accepted such an offer would transfer the token and pay money. This amendment explicitly disallows offers to buy or sell NFTs for negative amounts of money, and returns an appropriate error code. This also corrects the error code returned when placing offers to buy or sell NFTs for negative amounts in Direct Mode. (8266d9d)
  • Introduce NonFungibleTokensV1_1 amendment. This amendment encompasses three NFT-related amendments: the original NonFungibleTokensV1 amendment (from version 1.9.0), the fixNFTokenDirV1 amendment (from version 1.9.1), and the new fixNFTokenNegOffer amendment from this release. This amendment contains no changes other than enabling those three amendments together; this allows validators to vote in favor of only enabling the feature and fixes at the same time. (59326bb)
  • Handle invalid port numbers. If the user specifies a URL with an invalid port number, the server would silently attempt to use port 0 instead. Now it raises an error instead. This affects admin API methods and config file parameters for downloading history shards and specifying validator list sites. (#4213)
  • Reduce log noisiness. Decreased the severity of benign log messages in several places: "addPathsForType" messages during regular operation, expected errors during unit tests, and missing optional documentation components when compiling from source. (#4178, #4166, #4180)
  • Fix race condition in history shard implementation and support clang's ThreadSafetyAnalysis tool. Added build settings so that developers can use this feature of the clang compiler to analyze the code for correctness, and fix an error found by this tool, which was the source of rare crashes in unit tests. (#4188)
  • Prevent crash when rotating a database with missing data. When rotating databases, a missing entry could cause the server to crash. While there should never be a missing database entry, this change keeps the server running by aborting database rotation. (#4182)
  • Fix bitwise comparison in OfferCreate. Fixed an expression that incorrectly used a bitwise comparison for two boolean values rather than a true boolean comparison. The outcome of the two comparisons is equivalent, so this is not a transaction processing change, but the bitwise comparison relied on compilers to implicitly fix the expression. (#4183)
  • Disable cluster timer when not in a cluster. Disabled a timer that was unused on servers not running in clustered mode. The functionality of clustered servers is unchanged. (#4173)
  • Limit how often to process peer discovery messages. In the peer-to-peer network, servers periodically share IP addresses of their peers with each other to facilitate peer discovery. It is not necessary to process these types of messages too often; previously, the code tracked whether it needed to process new messages of this type but always processed them anyway. With this change, the server no longer processes peer discovery messages if it has done so recently. (#4202)
  • Improve STVector256 deserialization. Optimized the processing of this data type in protocol messages. This data type is used in several types of ledger entry that are important for bookkeeping, including directory pages that track other ledger types, amendments tracking, and the ledger hashes history. (#4204)
  • Fix and refactor spinlock code. The spinlock code, which protects the SHAMapInnerNode child lists, had a mistake that allowed the same child to be repeatedly locked under some circumstances. Fixed this bug and improved the spinlock code to make it easier to use correctly and easier to verify that the code works correctly. (#4201)
  • Improve comments and contributor documentation. Various minor documentation changes including some to reflect the fact that the source code repository is now owned by the XRP Ledger Foundation. (#4214, #4179, #4222)
  • Introduces a new API book_changes to provide information in a format that is useful for building charts that highlight DEX activity at a per-ledger level. (#4212)

Contributions

GitHub

The public source code repository for rippled is hosted on GitHub at https://github.com/ripple/rippled.

We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.

Credits

The following people contributed directly to this release:

For a real-time view of all lifetime contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: https://github.com/ripple/rippled/graphs/contributors.

rippled (XRP Ledger server) Version 1.9.1

23 May 21:58
e32bc67
Compare
Choose a tag to compare

Version 1.9.1 of rippled, the reference server implementation of the XRP Ledger protocol, is now available. This release includes several important fixes, including a fix for a syncing issue from 1.9.0, a new fix amendment to correct a bug in the new Non-Fungible Tokens (NFTs) code, and a new amendment to allow multi-signing by up to 32 signers.

Action Required

This release introduces two new amendments to the XRP Ledger protocol. These amendments are now open for voting according to the XRP Ledger's amendment process, which enables protocol changes following two weeks of >80% support from trusted validators.

If you operate an XRP Ledger server, then you should upgrade to version 1.9.1 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.

The fixNFTokenDirV1 amendment fixes a bug in code associated with the NonFungibleTokensV1 amendment, so the fixNFTokenDirV1 amendment should be enabled first. All validator operators are encouraged to configure amendment voting to oppose the NonFungibleTokensV1 amendment until after the fixNFTokenDirV1 amendment has become enabled. For more information about NFTs on the XRP Ledger, see NFT Conceptual Overview.

The ExpandedSignerList amendment extends the ledger's built-in multi-signing functionality so that each list can contain up to 32 entries instead of the current limit of 8. Additionally, this amendment allows each signer to have an arbitrary 256-bit data field associated with it. This data can be used to identify the signer or provide other metadata that is useful for organizations, smart contracts, or other purposes.

Install / Upgrade

On supported platforms, see the instructions on installing or updating rippled.

Changelog

This release contains the following features and improvements.

New Features and Amendments

  • Introduce fixNFTokenDirV1 Amendment - This amendment fixes an off-by-one error that occurred in some corner cases when determining which NFTokenPage an NFToken object belongs on. It also adjusts the constraints of NFTokenPage invariant checks, so that certain error cases fail with a suitable error code such as tecNO_SUITABLE_TOKEN_PAGE instead of failing with a tecINVARIANT_FAILED error code. (#4155)

  • Introduce ExpandedSignerList Amendment - This amendment expands the maximum signer list size to 32 entries and allows each signer to have an optional 256-bit WalletLocator field containing arbitrary data. (#4097)

  • Pause online deletion rather than canceling it if the server fails health check - The server stops performing online deletion of old ledger history if the server fails its internal health check during this time. Online deletion can now resume after the server recovers, rather than having to start over. (#4139)

Bug Fixes and Performance Improvements

  • Fix performance issues introduced in 1.9.0 - Readjusts some parameters of the ledger acquisition engine to revert some changes introduced in 1.9.0 that had adverse effects on some systems, including causing some systems to fail to sync to the network. (#4152)

  • Improve Memory Efficiency of Path Finding - Finding paths for cross-currency payments is a resource-intensive operation. While that remains true, this fix improves memory usage of pathfinding by discarding trust line results that cannot be used before those results are fully loaded or cached. (#4111)

  • Fix incorrect CMake behavior on Windows when platform is unspecified or x64 - Fixes handling of platform selection when using the cmake-gui tool to build on Windows. The generator expects Win64 but the GUI only provides x64 as an option, which raises an error. This fix only raises an error if the platform is Win32 instead, allowing the generation of solution files to succeed. (#4150)

  • Fix test failures with newer MSVC compilers on Windows - Fixes some cases where the API handler code used string pointer comparisons, which may not work correctly with some versions of the MSVC compiler. (#4149)

  • Update minimum Boost version to 1.71.0 - This release is compatible with Boost library versions 1.71.0 through 1.77.0. The build configuration and documentation have been updated to reflect this. (#4134)

  • Fix unit test failures for DatabaseDownloader - Increases a timeout in the DatabaseDownloader code and adjusts unit tests so that the code does not return spurious failures, and more data is logged if it does fail. (#4021)

  • Refactor relational database interface - Improves code comments, naming, and organization of the module that interfaces with relational databases (such as the SQLite database used for tracking transaction history). (#3965)

Contributions

GitHub

The public source code repository for rippled is hosted on GitHub at https://github.com/ripple/rippled.

We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.

Credits

The following people contributed directly to this release:

For a real-time view of all lifetime contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: https://github.com/ripple/rippled/graphs/contributors.

We welcome external contributions and are excited to see the broader XRP Ledger community continue to grow and thrive.

rippled (XRP Ledger server) Version 1.9.0

07 Apr 17:32
7c66747
Compare
Choose a tag to compare

Version 1.9.0

This is the 1.9.0 release of rippled, the reference implementation of the XRP Ledger protocol. This release brings several features and improvements.

New and Improved Features

  • Introduce NFT support (XLS-20): This release introduces support for non-fungible tokens, currently available to the developer community for broader review and testing. Developers can create applications that allow users to mint, transfer, and ultimately burn (if desired) NFTs on the XRP Ledger. You can try out the new NFT transactions using the nft-devnet. Note that some fields and error codes from earlier releases of the supporting code have been refactored for this release, shown in the Code Refactoring section, below. (70779f)

  • Simplify the Job Queue: This is a refactor aimed at cleaning up and simplifying the existing job queue. Currently, all jobs are canceled at the same time and in the same way, so this commit removes the unnecessary per-job cancellation token. (#3656)

  • Optimize trust line caching: The existing trust line caching code was suboptimal in that it stored redundant information, pinned SLEs into memory, and required multiple memory allocations per cached object. This commit eliminates redundant data, reduces the size of cached objects and unpinning SLEs from memory, and uses value types to avoid the need for std::shared_ptr. As a result of these changes, the effective size of a cached object includes the overhead of the memory allocator, and the std::shared_ptr should be reduced by at least 64 bytes. This is significant, as there can easily be tens of millions of these objects. (4d5459)

  • Incremental improvements to pathfinding memory usage: This commit aborts background pathfinding when closed or disconnected, exits the pathfinding job thread if there are no requests left, does not create the path find a job if there are no requests, and refactors to remove the circular dependency between InfoSub and PathRequest. (#4111)

  • Improve deterministic transaction sorting in TxQ: This commit ensures that transactions with the same fee level are sorted by TxID XORed with the parent ledger hash, the TxQ is re-sorted after every ledger, and attempts to future-proof the TxQ tie-breaking test. (#4077)

  • Improve stop signaling for Application: (34ca45)

  • Eliminate SHAMapInnerNode lock contention: The SHAMapInnerNode class had a global mutex to protect the array of node children. Profiling suggested that around 4% of all attempts to lock the global would block. This commit removes that global mutex, and replaces it with a new per-node 16-way spinlock (implemented so as not to affect the size of an inner node object), effectively eliminating the lock contention. (1b9387)

  • Improve ledger-fetching logic: When fetching ledgers, the existing code would isolate the peer that sent the most useful responses, and issue follow-up queries only to that peer. This commit increases the query aggressiveness, and changes the mechanism used to select which peers to issue follow-up queries to so as to more evenly spread the load among those peers that provided useful responses. (48803a)

  • Simplify and improve order book tracking: The order book tracking code would use std::shared_ptr to track the lifetime of objects. This commit changes the logic to eliminate the overhead of std::shared_ptr by using value types, resulting in significant memory savings. (b9903b)

  • Negative cache support for node store: This commit allows the cache to service requests for nodes that were previously looked up but not found, reducing the need to perform I/O in several common scenarios. (3eb8aa)

  • Improve asynchronous database handlers: This commit optimizes the way asynchronous node store operations are processed, both by reducing the number of times locks are held and by minimizing the number of memory allocations and data copying. (6faaa9)

  • Cleanup AcceptedLedger and AcceptedLedgerTx: This commit modernizes the AcceptedLedger and AcceptedLedgerTx classes, reduces their memory footprint, and reduces unnecessary dynamic memory allocations. (8f5868)

Code Refactoring

This release includes name changes in the NFToken API for SFields, RPC return labels, and error codes for clarity and consistency. To refactor your code, migrate the names of these items to the new names as listed below.

SField name changes:

  • TokenTaxon -> NFTokenTaxon
  • MintedTokens -> MintedNFTokens
  • BurnedTokens -> BurnedNFTokens
  • TokenID -> NFTokenID
  • TokenOffers -> NFTokenOffers
  • BrokerFee -> NFTokenBrokerFee
  • Minter -> NFTokenMinter
  • NonFungibleToken -> NFToken
  • NonFungibleTokens -> NFTokens
  • BuyOffer -> NFTokenBuyOffer
  • SellOffer -> NFTokenSellOffer
  • OfferNode -> NFTokenOfferNode

RPC return labels

  • tokenid -> nft_id
  • index -> nft_offer_index

Error codes

  • temBAD_TRANSFER_FEE -> temBAD_NFTOKEN_TRANSFER_FEE
  • tefTOKEN_IS_NOT_TRANSFERABLE -> tefNFTOKEN_IS_NOT_TRANSFERABLE
  • tecNO_SUITABLE_PAGE -> tecNO_SUITABLE_NFTOKEN_PAGE
  • tecBUY_SELL_MISMATCH -> tecNFTOKEN_BUY_SELL_MISMATCH
  • tecOFFER_TYPE_MISMATCH -> tecNFTOKEN_OFFER_TYPE_MISMATCH
  • tecCANT_ACCEPT_OWN_OFFER -> tecCANT_ACCEPT_OWN_NFTOKEN_OFFER

Bug Fixes

  • Fix deletion of orphan node store directories: Orphaned node store directories should only be deleted if the proper node store directories are confirmed to exist. 06e87e

rippled (XRP Ledger server) Version 1.8.5

08 Feb 03:25
72377e7
Compare
Choose a tag to compare

Version 1.8.5

This is the 1.8.5 release of rippled, the reference implementation of the XRP Ledger protocol. This release includes fixes and updates for stability and security, and improvements to build scripts. There are no user-facing API or protocol changes in this release.

Bug Fixes

This release contains the following bug fixes and under-the-hood improvements:

  • Correct TaggedPointer move constructor: Fixes a bug in unused code for the TaggedPointer class. The old code would fail if a caller explicitly tried to remove a child that is not actually part of the node. (61389a8)

  • Ensure protocol buffer prerequisites are present: The build scripts and packages now properly handle Protobuf packages and various packages. Prior to this change, building on Ubuntu 21.10 Impish Indri would fail unless the libprotoc-dev package was installed. (b7e0306)

  • Improve handling of endpoints during peer discovery. This hardens and improves handling of incoming messages on the peer protocol. (289bc0a)

  • Run tests on updated linux distros: Test builds now run on Rocky Linux 8, Fedora 34 and 35, Ubuntu 18, 20, and 22, and Debian 9, 10, and 11. (a9ee802)

  • Avoid dereferencing empty optional in ReportingETL: Fixes a bug in Reporting Mode that could dereference an empty optional value when throwing an error. (5b085a7)

  • Correctly add GIT_COMMIT_HASH into version string: When building the server from a non-tagged release, the build files now add the commit ID in a way that follows the semantic-versioning standard, and correctly handle the case where the commit hash ID cannot be retrieved. (d23d37f)

  • Update RocksDB to version 6.27.3: Updates the version of RocksDB included in the server from 6.7.3 (which was released on 2020-03-18) to 6.27.3 (released 2021-12-10). (c5dc00a)

rippled (XRP Ledger server) Version 1.8.4

31 Jan 20:48
d49b486
Compare
Choose a tag to compare

Version 1.8.4

This is the 1.8.4 release of rippled, the reference implementation of the XRP Ledger protocol.

This release corrects a technical flaw introduced with 1.8.3 that may result in failures if the newly-introduced 'fast loading' is enabled. The release also adjusts default parameters used to configure the pathfinding engine to reduce resource usage.

Bug Fixes

  • Adjust mutex scope in walkMapParallel: This commit corrects a technical flaw introduced with commit 7c12f01 that would result in undefined behavior if the server operator configured their server to use the 'fast loading' mechanism introduced with 1.8.3.

  • Adjust pathfinding configuration defaults: This commit adjusts the default configuration of the pathfinding engine, to account for the size of the XRP Ledger mainnet. Unless explicitly overriden, the changes mean that pathfinding operations will return fewer, shallower paths than previous releases.

Version 1.8.3

This is the 1.8.3 release of rippled, the reference implementation of the XRP Ledger protocol.

This release implements changes that improve the syncing performance of peers on the network, adds countermeasures to several routines involving LZ4 to defend against CVE-2021-3520, corrects a minor technical flaw that would result in the server not using a cache for nodestore operations, and adjusts tunable values to optimize disk I/O.

Summary of Issues

Recently, servers in the XRP Ledger network have been taking an increasingly long time to sync back to the network after restartiningg. This is one of several releases which will be made to improve on this issue.

Bug Fixes

  • Parallel ledger loader & I/O performance improvements: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, rippled needs to be using storage with high IOPS and operators need to explicitly enable this behavior by adding the following to their config file, under the [node_db] stanza:

    [node_db]
    ...
    fast_load=1

Note that when 'fast loading' is enabled the server will not open RPC and WebSocket interfaces until after the initial load is completed. Because of this, it may appear unresponsive or down.

  • Detect CVE-2021-3520 when decompressing using LZ4: This commit adds code to detect LZ4 payloads that may result in out-of-bounds memory accesses.

  • Provide sensible default values for nodestore cache:: The nodestore includes a built-in cache to reduce the disk I/O load but, by default, this cache was not initialized unless it was explicitly configured by the server operator. This commit introduces sensible defaults based on the server's configured node size.

  • Adjust the number of concurrent ledger data jobs: Processing a large amount of data at once can effectively bottleneck a server's I/O subsystem. This commits helps optimize I/O performance by controlling how many jobs can concurrently process ledger data.

  • Two small SHAMapSync improvements: This commit makes minor changes to optimize the way memory is used and control the amount of background I/O performed when attempting to fetch missing SHAMap nodes.

rippled (XRP Ledger server) Version 1.8.2

21 Dec 00:03
89766c5
Compare
Choose a tag to compare

Version 1.8.2

Ripple has released version 1.8.2 of rippled, the reference server implementation of the XRP Ledger protocol. This release addresses the full transaction queues and elevated transaction fees issue observed on the XRP ledger, and also provides some optimizations and small fixes to improve the server's performance overall.

Summary of Issues

Recently, servers in the XRP Ledger network have had full transaction queues and transactions paying low fees have mostly not been able to be confirmed through the queue. After investigation, it was discovered that a large influx of transactions to the network caused it to raise the transaction costs to be proposed in the next ledger block, and defer transactions paying lower costs to later ledgers. The first part worked as designed, but deferred transactions were not being confirmed as the ledger had capacity to process them.

The root cause was that there were very many low-cost transactions that different servers in the network received in a different order due to incidental differences in timing or network topology, which caused validators to propose different sets of low-cost transactions from the queue. Since none of these transactions had support from a majority of validators, they were removed from the proposed transaction set. Normally, any transactions removed from a proposed transaction set are supposed to be retried in the next ledger, but servers attempted to put these deferred transactions into their transaction queues first, which had filled up. As a result, the deferred transactions were discarded, and the network was only able to confirm transactions that paid high costs.

Bug Fixes

  • Address elevated transaction fees: This change addresses the full queue problems in two ways. First, it puts deferred transactions directly into the open ledger, rather than transaction queue. This reverts a subset of the changes from ximinez@62127d7. A transaction that is in the open ledger but doesn't get validated should stay in the open ledger so that it can be proposed again right away. Second, it changes the order in which transactions are pulled from the transaction queue to increase the overlap in servers' initial transaction consensus proposals. Like the old rules, transactions paying higher fee levels are selected first. Unlike the old rules, transactions paying the same fee level are ordered by transaction ID / hash ascending. (Previously, transactions paying the same fee level were unsorted, resulting in each server having a different order.)

  • Add ignore_default option to account_lines API: This flag, if present, suppresses the output of incoming trust lines in the default state. This is primarily motivated by observing that users often have many unwanted incoming trust lines in a default state, which are not useful in the vast majority of cases. Being able to suppress those when doing account_lines saves bandwidth and resources. (#3980)

  • Make I/O and prefetch worker threads configurable: This commit adds the ability to specify io_workers and prefetch_workers in the config file which can be used to specify the number of threads for processing raw inbound and outbound IO and configure the number of threads for performing node store prefetching. (#3994)

  • Enforce account RPC limits by objects traversed: This changes the way the account_objects API method counts and limits the number of objects it returns. Instead of limiting results by the number of objects found, it counts by the number of objects traversed. Additionally, the default and maximum limits for non-admin connections have been decreased. This reduces the amount of work that one API call can do so that public API servers can share load more effectively. (#4032)

  • Fix a crash on shutdown: The NuDB backend class could throw an error in its destructor, resulting in a crash while the server was shutting down gracefully. This crash was harmless but resulted in false alarms and noise when tracking down other possible crashes. (#4017)

  • Improve reporting of job queue in admin server_info: The server_info command, when run with admin permissions, provides information about jobs in the server's job queue. This commit provides more descriptive names and more granular categories for many jobs that were previously all identified as "clientCommand". (#4031)

  • Improve full & compressed inner node deserialization: Remove a redundant copy operation from low-level SHAMap deserialization. (#4004)

  • Reporting mode: only forward to P2P nodes that are synced: Previously, reporting mode servers forwarded to any of their configured P2P nodes at random. This commit improves the selection so that it only chooses from P2P nodes that are fully synced with the network. (#4028)

  • Improve handling of HTTP X-Forwarded-For and Forwarded headers: Fixes the way the server handles IPv6 addresses in these HTTP headers. (#4009, #4030)

  • Other minor improvements to logging and Reporting Mode.

rippled (XRP Ledger server) Version 1.8.1

25 Nov 00:32
fbedfb2
Compare
Choose a tag to compare

Version 1.8.0

Ripple has released version 1.8.0 of rippled, the reference server implementation of the XRP Ledger protocol. This release brings several features and improvements.

New and Improved Features

  • Improve History Sharding: Shards of ledger history are now assembled in a deterministic way so that any server can make a binary-identical shard for a given range of ledgers. This makes it possible to retrieve a shard from multiple sources in parallel, then verify its integrity by comparing checksums with peers' checksums for the same shard. Additionally, there's a new admin RPC command to import ledger history from the shard store, and the crawl_shards command has been expanded with more info. (#2688, #3726, #3875)
  • New CheckCashMakesTrustLine Amendment: If enabled, this amendment will change the CheckCash transaction type so that cashing a check for an issued token automatically creates a trust line to hold the token, similar to how purchasing a token in the decentralized exchange creates a trust line to hold the token. This change provides a way for issuers to send tokens to a user before that user has set up a trust line, but without forcing anyone to hold tokens they don't want. (#3823)
  • Automatically determine the node size: The server now selects an appropriate [node_size] configuration value by default if it is not explicitly specified. This parameter tunes various settings to the specs of the hardware that the server is running on, especially the amount of RAM and the number of CPU threads available in the system. Previously the server always chose the smallest value by default.
  • Improve transaction relaying logic: Previously, the server relayed every transaction to all its peers (except the one that it received the transaction from). To reduce redundant messages, the server now relays transactions to a subset of peers using a randomized algorithm. Peers can determine whether there are transactions they have not seen and can request them from a peer that has them. It is expected that this feature will further reduce the bandwidth needed to operate a server.
  • Improve the Byzantine validator detector: This expands the detection capabilities of the Byzantine validation detector. Previously, the server only monitored validators on its own UNL. Now, the server monitors for Byzantine behavior in all validations it sees.
  • Experimental tx stream with history for sidechains: Adds an experimental subscription stream for sidechain federators to track messages on the main chain in canonical order. This stream is expected to change or be replaced in future versions as work on sidechains matures.
  • Support Debian 11 Bullseye: This is the first release that is compatible with Debian Linux version 11.x, "Bullseye." The .deb packages now use absolute paths only, for compatibility with Bullseye's stricter package requirements. (#3909)
  • Improve Cache Performance: The server uses a new storage structure for several in-memory caches for greatly improved overall performance. The process of purging old data from these caches, called "sweeping", was time-consuming and blocked other important activities necessary for maintaining ledger state and participating in consensus. The new structure divides the caches into smaller partitions that can be swept in parallel.
  • Amendment default votes: Introduces variable default votes per amendment. Previously the server always voted "yes" on any new amendment unless an admin explicitly configured a voting preference for that amendment. Now the server's default vote can be "yes" or "no" in the source code. This should allow a safer, more gradual roll-out of new amendments, as new releases can be configured to understand a new amendment but not vote for it by default. (#3877)
  • More fields in the validations stream: The validations subscription stream in the API now reports additional fields that were added to validation messages by the HardenedValidations amendment. These fields make it easier to detect misconfigurations such as multiple servers sharing a validation key pair. (#3865)
  • Reporting mode supports validations and manifests streams: In the API it is now possible to connect to these streams when connected to a servers running in reporting. Previously, attempting to subscribe to these streams on a reporting server failed with the error reportingUnsupported. (#3905)

Bug Fixes

  • Clarify the safety of NetClock::time_point arithmetic: * NetClock::rep is uint32_t and can be error-prone when used with subtraction. * Fixes #3656
  • Fix out-of-bounds reserve, and some minor optimizations
  • Fix nested locks in ValidatorSite
  • Fix clang warnings about copies vs references
  • Fix reporting mode build issue
  • Fix potential deadlock in Validator sites
  • Use libsecp256k1 instead of OpenSSL for key derivation: The deterministic key derivation code was still using calls to OpenSSL. This replaces the OpenSSL-based routines with new libsecp256k1-based implementations
  • Improve NodeStore to ShardStore imports: This runs the import process in a background thread while preventing online_delete from removing ledgers pending import
  • Simplify SHAMapItem construction: The existing class offered several constructors which were mostly unnecessary. This eliminates all existing constructors and introduces a single new one, taking a Slice. The internal buffer is switched from std::vector to Buffer to save a minimum of 8 bytes (plus the buffer slack that is inherent in std::vector) per SHAMapItem instance.
  • Redesign stoppable objects: Stoppable is no longer an abstract base class, but a pattern, modeled after the well-understood std::thread. The immediate benefits are less code, less synchronization, less runtime work, and (subjectively) more readable code. The end goal is to adhere to RAII in our object design, and this is one necessary step on that path.

rippled (XRP Ledger server) Version 1.7.3

27 Aug 21:29
96bbabb
Compare
Choose a tag to compare

Version 1.7.3

This is the 1.7.3 release of rippled, the reference implementation of the XRP Ledger protocol. This release addresses an OOB memory read identified by Guido Vranken, as well as an unrelated issue identified by the Ripple C++ team that could result in incorrect use of SLEs. Additionally, this version also introduces the NegativeUNL amendment, which corresponds to the feature which was introduced with the 1.6.0 release.

Action Required

If you operate an XRP Ledger server, then you should upgrade to version 1.7.3 at your earliest convenience to mitigate the issues addressed in this hotfix. If a sufficient majority of servers on the network upgrade, the NegativeUNL amendment may gain a majority, at which point a two week activation countdown will begin. If the NegativeUNL amendment activates, servers running versions of rippled prior to 1.7.3 will become amendment blocked.

Bug Fixes

Improve SLE usage in check cashing: Fixes a situation which could result in the incorrect use of SLEs.
Address OOB in base58 decoder: Corrects a technical flaw that could allow an out-of-bounds memory read in the Base58 decoder.
Add NegativeUNL as a supported amendment: Introduces an amendment for the Negative UNL feature introduced in rippled 1.6.0.

rippled (XRP Ledger server) Version 1.7.2

24 May 22:45
34ee4ca
Compare
Choose a tag to compare

This the 1.7.2 release of rippled, the reference server implementation of the XRP Ledger protocol. This release protects against the security issue CVE-2021-3499 affecting OpenSSL, adds an amendment to fix an issue with small offers not being properly removed from order books in some cases, and includes various other minor fixes. Version 1.7.2 supersedes version 1.7.1 and adds fixes for more issues that were discovered during the release cycle.

Action Required

This release introduces a new amendment to the XRP Ledger protocol: fixRmSmallIncreasedQOffers. This amendment is now open for voting according to the XRP Ledger's amendment process, which enables protocol changes following two weeks of >80% support from trusted validators. If you operate an XRP Ledger server, then you should upgrade to version 1.7.2 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network. If you operate an XRP Ledger validator, please learn more about this amendment so you can make informed decisions about how your validator votes. If you take no action, your validator begins voting in favor of any new amendments as soon as it has been upgraded.

Bug Fixes

fixRmSmallIncreasedQOffers Amendment: This amendment fixes an issue where certain small offers can be left at the tip of an order book without being consumed or removed when appropriate and causes some payments and Offers to fail when they should have succeeded (#3827).
Adjust OpenSSL defaults and mitigate CVE-2021-3499: Prior to this fix, servers compiled against a vulnerable version of OpenSSL could have a crash triggered by a malicious network connection. This fix disables renegotiation support in OpenSSL so that the rippled server is not vulnerable to this bug regardless of the OpenSSL version used to compile the server. This also removes support for deprecated TLS versions 1.0 and 1.1 and ciphers that are not part of TLS 1.2 (#79e69da).
Support HTTP health check-in reporting mode: Enables the Health Check special method when running the server in the new Reporting Mode introduced in 1.7.0 (9c8cadd).
Maintain compatibility for forwarded RPC responses: Fixes a case in API responses from servers in Reporting Mode, where requests that were forwarded to a P2P-mode server would have the result field nested inside another result field (8579eb0).
Add load_factor in reporting mode: Adds a load_factor value to the server info method response when running the server in Reporting Mode so that the response is compatible with the format returned by servers in P2P mode (the default) (430802c).
Properly encode metadata from tx RPC command: Fixes a problem where transaction metadata in the tx API method response would be in JSON format even when the binary was requested (7311629).
Updates to Windows builds: When building on Windows, use vcpkg 2021 by default and add compatibility with MSVC 2019 (36fe196), (30fd458).