Skip to content

rippled (XRP Ledger server) Version 1.5.0
Compare
Choose a tag to compare
@carlhua carlhua released this 31 Mar 21:24
1.5.0
f00f263
This commit was signed with the committer’s verified signature.
carlhua Carl
GPG key ID: 262602F26220A79A
Learn about vigilant mode.

The rippled 1.5.0 release introduces several improvements and new features, including support for gRPC API, API versioning, UNL propagation via the peer network, new RPC methods validator_info and manifest, augmented submit method, improved tx method response, improved command line parsing, improved handshake protocol, improved package building and various other minor bug fixes and improvements.

This release also introduces two new amendments: fixQualityUpperBound and RequireFullyCanonicalSig.

Several improvements to the sharding system are currently being evaluated for inclusion into the upcoming 1.6 release of rippled. These changes are incompatible with shards generated by previous versions of the code.
Additionally, an issue with the existing sharding engine can result in a server running versions 1.4 or 1.5 of the software to experience a deadlock and automatically restart when running with the sharding feature enabled.
At this time, the developers recommend running with sharding disabled, pending the improvements scheduled to be introduced with 1.6. For more information on how to disable sharding, please visit https://xrpl.org/configure-history-sharding.html

New and Updated Features

  • The RequireFullyCanonicalSig amendment which changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid. This protects against transaction malleability on all transactions, instead of just transactions with the tfFullyCanonicalSig flag enabled. Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. With this amendment, no single-signed transactions are malleable. (Multi-signed transactions may still be malleable if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. For more information. ec137044a
  • Native gRPC API support. Currently, this API provides a subset of the full rippled API. You can enable the gRPC API on your server with a new configuration stanza. 7d867b806
  • API Versioning which allows for future breaking change of RPC methods to co-exist with existing versions. 2aa11fa41
  • Nodes now receive and broadcast UNLs over the peer network under various conditions. 2c71802e3
  • Augmented submit method to include additional details on the status of the command. 79e9085dd
  • Improved tx method response with additional details on ledgers searched. 47501b7f9
  • New validator_info method which returns information pertaining to the current validator's keys, manifest sequence, and domain. 3578acaf0
  • New manifest method which looks up manifest information for the specified key (either master or ephemeral). 3578acaf0
  • Introduce handshake protocol for compression negotiation (compression is not implemented at this point) and other minor improvements. f6916bfd4
  • Remove various old conditionals introduced by amendments. (51ed7db00, 6e4945c56)
  • Add getRippledInfo info gathering script to rippled Linux packages. acf4b7889

Bug Fixes and Improvements

  • The fixQualityUpperBound amendment which fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments. 9d3626fec
  • tx method now properly fetches all historical tx if they are incorporated into a validated ledger under rules that applied at the time. 11cf27e00
  • Fix to how fail_hard flag is handled with the submit method - transactions that are submitted with the fail_hard flag that result in any TER code besides tesSUCCESS is neither queued nor held. cd9732b47
  • Remove unused Beast code. 172ead822
  • Lag ratchet code fix to use proper ephemeral public keys instead of the long-term master public keys.6529d3e6f
Assets 2
Loading