On March 31st, the XRP Ledger (rippled server) version 1.5.0 was released. The rippled 1.5.0 release introduced 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, improved CLI parsing, improved protocol-level handshaking protocol, improved package building, and various other minor bug fixes and improvements.

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

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. 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. You can enable the gRPC API on your server with a new configuration stanza. 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

method to include additional details on the status of the command. Improved tx method response with additional details on ledgers searched. 47501b7f9

method response with additional details on ledgers searched. New validator_info method which returns information pertaining to the current validator’s keys, manifest sequence, and domain. 3578acaf0

method which returns information pertaining to the current validator’s keys, manifest sequence, and domain. New manifest method which looks up manifest information for the specified key (either master or ephemeral). 3578acaf0

method which looks up manifest information for the specified key (either master or ephemeral). 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

1.5.0 Bug Fixes

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

amendment which fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments. tx method now properly fetches all historical tx if they are incorporated into a validated ledger under rules that applied at the time. 11cf27e00

method now properly fetches all historical tx if they are incorporated into a validated ledger under rules that applied at the time. 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 are neither queued nor held. cd9732b47

flag is handled with the method – transactions that are submitted with the flag that result in any TER code besides tesSUCCESS are neither queued nor held. Remove unused Beast code. 172ead822

code. Lag ratchet code fix to use proper ephemeral public keys instead of the long-term master public keys. 6529d3e6f

Xpring course of action

On Wednesday, 2020-04-15, rippled version 1.5.0 will be deployed on the XRP Ledger Testnet, which is also hosted by the Xpring team at Ripple, to give developers an environment for testing their applications with faux XRP that mirrors the latest stable version running on XRP Ledger Mainnet.

Lastly, on Wednesday, 2020-04-15, the Xpring team will be updating its own XRP Ledger Mainnet rippled servers, including clusters and validators, to version 1.5.0. At this time, Xpring also plans to starting voting in favor of the following Amendments, which are proposed fixes to the rippled protocol:

fixQualityUpperBound (introduced in version 1.5.0)

(introduced in version 1.5.0) fixCheckThreading (introduced in version 1.4.0)

(introduced in version 1.4.0) fixPayChanRecipientOwnerDir (introduced in version 1.4.0)

Xpring encourages rippled server operators to review the proposed upgrade to rippled version 1.5.0, learn more about the Amendments above, and upgrade to rippled version 1.5.0 by Wednesday 2020-04-29 in order to ensure service continuity.

At the time of writing, almost a third of the network has upgraded to 1.5.0.

Rippled 1.6.0-b1

Last week, rippled version 1.6.0-b1, the first beta of the 1.6.0 release, was made available. The XRP Ledger Devnet, which is hosted by the Xpring team at Ripple, has been upgraded, giving developers early access to the latest unstable beta version of rippled.

New dUNL validator

On April 8th, a new validator joined the dUNL, taking the number of non-Ripple dUNL validators to 30, as opposed to Ripple’s 6. The new validator is Okonto, a fully licensed digital assets platform registered in Estonia since 2011. Okonto has been running an XRPL validator since August 2019.

A new validator on the dUNL. A big Hi to @okonto https://t.co/CRSuDWvtkb — Alloy Networks (@alloynetworks) April 7, 2020

With the addition of Okonto, non-Ripple validators have now reached 83.3%, making the XRPL as decentralized as ever. The progress the XRPL has done in regards to decentralization in the past 2 years is evident in this graph by minivalist.