Ripple Dev Blog - Recent Posts
Ripple has released version 1.2.4 of rippled, the reference implementation of the core XRP Ledger protocol.
Version 1.2.4 improves the verification and routing of shard crawl requests and imposes a 20 second timeout onto the component that checks for an updated validator list to prevent it from becoming blocked for an indefinite amount of time.
By Nik Bougalis, Engineering Manager
The primary mission of the C++ team at Ripple is to contribute to
rippled, the reference implementation of the protocol that underpins the XRP Ledger. The codebase—which is now over 6 years old—has contributions from over 100 developers from all over the world.
As a team, our primary focus is on ensuring that the codebase is solid, that the code is robust and that it is well-suited to be the core of the next-generation of financial infrastructure, one which allows value to not only move as fast and as efficiently as information does today, but to move securely as well.
In an earlier blog post, I noted that our existing software development and quality assurance process—honed over several years—places heavy emphasis on correctness and security. I highlighted our use of automated tests and specialized tooling (such as static analyzers) but I also alluded to the human element as well: our rigorous and public code reviews and regular security audits of the codebase by specialists. I’d like to take the opportunity to discuss those practices in greater detail.
The MultiSignReserve amendment to the XRP Ledger, introduced in
rippled v1.2.0, has gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-04-17. As long as the MultiSignReserve amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date.
The Data API, an open API that provides data to XRP Charts and third-party tools, suffered gaps in data ingestion on 2019-03-23. As a result, several metrics on XRP Charts, including the number of ledgers closed per day, were overcounted. During this time, the XRP Ledger did not experience any outages. However, the Data API's ingestion service was unable to process ledgers with transactions containing the
tecKILLED transaction response code.
tecKILLED is a new response code added to the XRP Ledger by amendment fix1578 on 2019-03-23. This necessitated changes to the ripple-binary-codec library used by the ingestion service, but those changes were only partially deployed to the ingestion service. We have since reprocessed and corrected the metrics that were affected by this problem.
Here at Ripple, we've been eagerly following and contributing to the progress of Interledger, a neutral standard for connecting all money systems into an Internet-like network of networks. Since finalizing the core protocol suite in late 2017, contributors from a variety of companies and backgrounds have been working hard on growing the ecosystem with implementations and infrastructure. Progress has been rapid and wild, so we thought we'd help make sense of it by checking in to see where Interledger stands today.
Ripple has released version 1.2.3 of rippled, the reference implementation of the core XRP Ledger protocol.
Version 1.2.3 corrects a technical flaw that could, in rare circumstances, cause the server to dereference a null pointer, which could result in the server process being terminated by the operating system.
The fix1578 amendment to the XRP Ledger, introduced in
rippled v1.2.0, has gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-03-23.
The fixTakerDryOfferRemoval amendment to the XRP Ledger has also gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-04-02.
As long as the amendments continue to have the support of at least 80% of trusted validators continuously, they will become enabled on the expected dates.