mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
Migrate dev-blog to Redocly (#2346)
* Step 1 to migrate the blog - Add blog pages from the dev-blog repo * Add blog-specific sidebar (& update contents) * Add new dev reflections blog post from 01-23-2024 * Blog migration: fix markdoc errors and broken links * Remove community pages from the sidebar --------- Co-authored-by: mDuo13 <mduo13@gmail.com>
This commit is contained in:
Amarantha Kulkarni
committed by
mDuo13
mDuo13
parent
33cd1f54a5
commit
b4489f8649
@@ -0,0 +1,45 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2020-03-10
|
||||
labels:
|
||||
- Developer Reflections
|
||||
---
|
||||
# Community Spotlight: Developing Wallet Protect
|
||||
|
||||
GateHub started in 2013 with an idea: _What if there was a wallet that could hold any type of asset, have an integrated exchange built-in and provide the ability to send and receive assets across any payment network instantly?_
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
Bitcoin dominated the market at the time, and as an early pioneer, Bitstamp’s exchange was one of the first exchanges to list XRP and become an XRPL gateway. Enej Pungerčar, who at the time worked at Bitstamp as a web designer and developer, was able to see the benefits of a blockchain that would be able to support other types of assets, unlike Bitcoin. Inspired by the challenge, he began building a front-end wallet prototype to ease the burden of transferring funds and to better the user experience.
|
||||
|
||||
He decided to use the XRP Ledger because it was instant and allowed users to send multiple currencies across the network. But, while he could access and transfer funds on the XRP Ledger (XRPL), Pungerčar still needed a Bitstamp account to send money to the wallet itself. He needed more support in order to develop a more robust solution.
|
||||
|
||||
## Building on the XRP Ledger
|
||||
|
||||
In 2014, he presented his idea at Ripple in San Francisco. It was the first time anyone attempted to build something on the front-end of the XRP Ledger and he received overwhelming support from both Ripple’s leadership and developer teams. Shortly thereafter, Pungerčar along with Anžej Simičak and George Frost, formally started [GateHub](https://gatehub.net/?utm_source=ripplex&utm_medium=affiliate&utm_campaign=wallet_protect) and launched the first version of the wallet in 2015.
|
||||
|
||||
Since then, GateHub has been focused on improving its user experience. On the one side is the wallet. Built for the masses, it is a robust platform but user friendly enough to allow those who haven’t necessarily interacted with the XRP Ledger to jump right in with both feet. Then on the other side is growing GateHub into a gateway, building it out as a platform that would not only attract customers, but also increase the adoption of the XRP Ledger and provide a turn key solution for financial institutions and corporations to act as a gateway without worrying about all the complicated infrastructure requirements. GateHub is the largest wallet provider on the XRP Ledger. Ultimately, it aims to become one of the world’s leading overall wallet providers and the best ‘gateway as a service’ platform.
|
||||
|
||||
The primary reasons they chose to build GateHub on XRPL is the benefits of scalability, speed and low cost. Compared to other blockchains, settlements on XRPL take an average of 3-5 seconds, versus an hour or more. Plus, using the XRPL gives GateHub freedom to build out new tools to better serve their customers.
|
||||
|
||||
> 
|
||||
|
||||
## Wallet Protect: A New Service for XRPL Wallets
|
||||
|
||||
Security concerns are permeating the crypto market. Since 2011, over $7.6 billion of crypto funds have been stolen due to scams and user’s general unfamiliarity with the market. On top of that, when exchanges are forced to shut down, there is no way for users to recover their funds. This is a problem GateHub is looking to solve.
|
||||
|
||||
[Wallet Protect](https://gatehub.net/blog/wallet-protect-faq/?utm_source=ripplex&utm_medium=affiliate&utm_campaign=wallet_protect) is a world-first for the XRP Ledger. It provides users with the ability to secure their wallets with multi-signature and up to $100,000 of theft cover through a partnership with [Coincover](http://coincover.com/). Coincover offers a range of cryptocurrency protection products including fund recovery and deposit protection guarantee.
|
||||
|
||||
Additionally, the custody of funds always stays with the customer, meaning whether GateHub exists or not, users will always be able to get their funds back. Thanks to its use of [xrplorer](https://xrplorer.com/) and [Chainalisys](https://www.chainalysis.com/), GateHub flags suspicious account addresses to help mitigate unnecessary security problems in the first place.
|
||||
|
||||
Wallet Protect is built into GateHub and it’s easy for users to [sign-up](https://signin.gatehub.net/signup?utm_source=ripplex&utm_medium=affiliate&utm_campaign=wallet_protect). A special 25% discount has been extended for readers of this blog. For the month of March, $10,000 of theft cover can be purchased for $2.25 per month or upgraded to $100,000 of theft cover for $18 per month.
|
||||
|
||||
<figure class="kg-card kg-embed-card"><iframe src="https://player.vimeo.com/video/522005166?app_id=122963" width="640" height="360" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen></iframe></figure>
|
||||
|
||||
## What’s Next for GateHub
|
||||
|
||||
As GateHub continues to improve its platform and grow, Pungerčar and his team, that is more than 40 people strong, are committed to helping people navigate the world of cryptocurrency more efficiently. By building a network of regulated gateways using the XRP Ledger, it will soon be possible for customers to draw upon any assets or values.
|
||||
|
||||
GateHub, however, doesn’t want to do it alone. The team wants to encourage other developers and merchants to build their own solutions and wallet applications. The sooner more companies and developers adopt the technology, the sooner its value will be recognized on a global scale.
|
||||
|
||||
Are you a developer interested in building on the XRP Ledger? Learn more [here](https://xrpl.org/docs.html).
|
||||
82
content/blog/2021/five-upcoming-amendments.md
Normal file
82
content/blog/2021/five-upcoming-amendments.md
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-11-10
|
||||
labels:
|
||||
- Amendments
|
||||
---
|
||||
# Five Amendments Expected Soon
|
||||
|
||||
Several amendments to the XRP Ledger protocol are expected to become enabled on the XRP Ledger Mainnet soon. Three of these amendments fix bugs in the XRP Ledger protocol, one (NegativeUNL) improves the ability of the network to make forward progress during periods of instability, and the last one (TicketBatch) adds the ability to prepare and send transactions in a more flexible order. The details are as follows (all dates are in UTC):
|
||||
|
||||
- fixSTAmountCanonicalize (min version: [1.7.0](https://xrpl.org/blog/2021/rippled-1.7.0.html)) expected **2021-11-11**.
|
||||
- FlowSortStrands (min version: [1.7.0](https://xrpl.org/blog/2021/rippled-1.7.0.html)) expected **2021-11-11**.
|
||||
- fixRmSmallIncreasedQOffers (min version: [v1.7.2](https://xrpl.org/blog/2021/rippled-1.7.2.html)) expected **2021-11-18**.
|
||||
- TicketBatch (min version: [v1.7.2](https://xrpl.org/blog/2021/rippled-1.7.2.html)) expected **2021-11-18**.
|
||||
- NegativeUNL (min version: [v1.7.3](https://xrpl.org/blog/2021/rippled-1.7.3.html)) expected **2021-11-21**.
|
||||
|
||||
Each amendment will become enabled if it maintains support from at least 80% of trusted validators until its expected time. Operators of `rippled` servers **must** upgrade to the minimum version or higher by the time these amendments become enabled.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Action Required
|
||||
|
||||
If you operate an XRP Ledger (`rippled`) server, you should upgrade to **version 1.7.3** (or higher) as soon as possible, for service continuity.
|
||||
|
||||
**Note:** Version 1.8.0 is currently in the release candidate stage, and also supports these amendments. However, the amendments may go live before version 1.8.0 reaches full release, so you should not wait to upgrade.
|
||||
|
||||
No action is needed for applications and integrations with the XRP Ledger. You may want to review how [Tickets](https://xrpl.org/tickets.html) work to see if you want to use them in your software, or enable your users to use them.
|
||||
|
||||
## Impact of Not Upgrading
|
||||
|
||||
If you operate a `rippled` server but don’t upgrade to the minimum version by the time the amendments are expected to become enabled, then your server will become amendment blocked, meaning that your server:
|
||||
|
||||
* Cannot determine the validity of a ledger
|
||||
* Cannot submit or process transactions
|
||||
* Does not participate in the consensus process
|
||||
* Does not vote on future amendments
|
||||
* Could rely on potentially invalid data
|
||||
|
||||
If some amendments do not become enabled, then your server will not be amendment blocked as long as it meets the minimum version for any amendments that did become enabled. However, version 1.7.3 is strongly recommended because it includes important fixes for server stability and supports all four amendments.
|
||||
|
||||
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
|
||||
|
||||
## Amendment Summaries
|
||||
|
||||
### fixSTAmountCanonicalize
|
||||
|
||||
This amendment fixes an edge case in [deserializing](https://xrpl.org/serialization.html) Amount-type fields. Without this amendment, in some rare cases the operation could result in otherwise valid serialized amounts overflowing during deserialization. With this amendment, the XRP Ledger detects error conditions more quickly and eliminates the problematic corner cases.
|
||||
|
||||
|
||||
### FlowSortStrands
|
||||
|
||||
This amendment improves the payment engine's calculations for finding the most cost-efficient way to execute a cross-currency transaction.
|
||||
|
||||
Without this change, the engine simulates a payment through each possible path to calculate the quality (ratio of input to output) of each path. With this change, the engine calculates the theoretical quality of each path without simulating a full payment. With this amendment, the payment engine executes some cross-currency payments much faster, is able to find the most cost-efficient path in more cases, and can enable some payments to succeed in certain conditions where the old payment engine would fail to find enough liquidity.
|
||||
|
||||
|
||||
### fixRmSmallIncreasedQOffers
|
||||
|
||||
This amendment fixes an issue where certain Offers, when almost completely consumed, have a much lower exchange rate than when they were first placed. This occurs when the remaining amounts of one or both assets are so small that they cannot be rounded to a similar ratio as when the Offer was placed.
|
||||
|
||||
Without this amendment, an Offer in this state blocks Offers with better rates deeper in the order book and causes some payments and Offers to fail when they could have succeeded.
|
||||
|
||||
With this amendment, payments and trades can remove these types of Offers the same way that transactions normally remove fully consumed or unfunded Offers.
|
||||
|
||||
|
||||
### NegativeUNL
|
||||
|
||||
This amendment implements a ["Negative UNL" system](https://xrpl.org/negative-unl.html), where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the ability of the network to make progress during periods of network instability.
|
||||
|
||||
|
||||
### TicketBatch
|
||||
|
||||
This amendment adds [Tickets](https://xrpl.org/tickets.html) as a way of sending transactions out of the typical sequence number order. (Standards Draft: [XLS-13d](https://github.com/XRPLF/XRPL-Standards/issues/16).) If you have an XRP Ledger account, you can create one or more Tickets, then use those Tickets to send transactions that can execute in any order. This allows for usage patterns such as preparing multiple multi-signed transactions in parallel when the process of collecting signatures can take a long time.
|
||||
|
||||
|
||||
## Learn, ask questions, and discuss
|
||||
|
||||
To learn more about how the XRP Ledger's amendments system coordinates protocol upgrades, see the [Amendments article](https://xrpl.org/amendments.html).
|
||||
|
||||
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
|
||||
|
||||
For more platforms with XRP Ledger content and more ways to get involved, see the [XRPL Community Page](https://xrpl.org/contribute.html).
|
||||
44
content/blog/2021/introducing-xrpl-js.md
Normal file
44
content/blog/2021/introducing-xrpl-js.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-10-20
|
||||
labels:
|
||||
- xrpl.js Release Notes
|
||||
---
|
||||
# Introducing xrpl.js
|
||||
_by Team RippleX_
|
||||
|
||||
[RippleX](https://ripple.com/ripplex/) and the [XRP Ledger Foundation (XRPLF)](https://xrplf.org/) are excited to announce xrpl.js **version 2.0.0**, a JavaScript/TypeScript library for interacting with the XRP Ledger (XRPL). Formerly known as ripple-lib, the library was renamed to better represent its role in the XRPL ecosystem and overhauled to take advantage of modern JavaScript features.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Background
|
||||
|
||||
JavaScript is one of the most widely-used programming languages, and as such has a massive community of active developers. Maintaining a JavaScript SDK enables these developers to seamlessly interact with the XRP Ledger, both in the browser and in Node.js. In addition, the JavaScript libraries (xrpl.js, ripple-binary-codec, ripple-keypairs, and ripple-address-codec) power many [apps](https://github.com/XRPLF/xrpl.js/blob/develop/APPLICATIONS.md) in the XRPL ecosystem, as well as [packages](https://www.npmjs.com/browse/depended/ripple-lib) from companies such as BitGo and Ledger.
|
||||
|
||||
## Changes
|
||||
|
||||
With this release of xrpl.js, the JavaScript, [Java](https://github.com/XRPLF/xrpl4j), and [Python](https://github.com/XRPLF/xrpl-py/) libraries provided by the XRPLF now have parallel structures and systems. This enables developers to easily work with their preferred programming language depending on their specific needs, without having to learn an entirely new interface.
|
||||
|
||||
xrpl.js will continue to support all ripple-lib features, such as:
|
||||
|
||||
- Serializing, signing, and submitting transactions to the XRPL
|
||||
- Retrieving information from the XRPL
|
||||
- Helpful utility functions (such as converting between [drops](https://xrpl.org/xrp.html#xrp-properties) and XRP)
|
||||
- Support for Node.js, web browsers, and React
|
||||
|
||||
It also introduces a number of new features, including:
|
||||
|
||||
- TypeScript types for all transaction types and WebSocket requests
|
||||
- A Wallet class to make it easier to work with key pairs
|
||||
- Protections against the [partial payment attack vector](https://xrpl.org/partial-payments.html#partial-payments-exploit)
|
||||
- An additional submit implementation that returns the transaction's final outcome after validation.
|
||||
|
||||
In version 2.0, the library is now much more aligned with the core XRP Ledger interface. This means XRPL developers—whether new or experienced—can refer to multiple sources of documentation instead of needing to rely solely on the library-specific documentation. There are also a number of general architecture improvements, such as simplifying code, making user interfaces more intuitive (especially in relation to the core ledger), and revamping the testing structure. For a detailed list of changes, visit the [changelog](https://github.com/XRPLF/xrpl.js/blob/develop/HISTORY.md).
|
||||
|
||||
## Start Building
|
||||
|
||||
To get started using xrpl.js, see [this tutorial on xrpl.org](https://xrpl.org/get-started-using-javascript.html), or check out the [project repo](https://github.com/XRPLF/xrpl.js) or [reference documentation](https://js.xrpl.org/).
|
||||
|
||||
If you already have a project that uses ripple-lib, migrate today! We have a [migration guide for moving your code from ripple-lib v1.10 to xrpl.js v2.0](https://xrpl.org/xrpljs2-migration-guide.html).
|
||||
|
||||
We hope you enjoy building the Internet of Value, and feel welcome to reach out to the XRP Ledger developer community if you have any questions!
|
||||
36
content/blog/2021/introducing-xrpl-py-for-pythonistas.md
Normal file
36
content/blog/2021/introducing-xrpl-py-for-pythonistas.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-04-06
|
||||
labels:
|
||||
- xrpl-py Release Notes
|
||||
---
|
||||
# Introducing xrpl-py for Pythonistas
|
||||
_by Team RippleX_
|
||||
|
||||
Today, [RippleX](https://ripple.com/) and the [XRP Ledger Foundation (XRPLF)](https://xrplf.org/) are excited to announce the launch of [`xrpl-py`](https://github.com/XRPLF/xrpl-py), a pure Python implementation for interacting with the XRP Ledger. The `xrpl-py` library simplifies the hardest parts of XRP Ledger interaction—like serialization and transaction signing—by providing native Python methods and models for [XRP Ledger transactions](https://xrpl.org/transaction-formats.html) and [core server API](https://xrpl.org/api-conventions.html) ([rippled](https://github.com/ripple/rippled)) objects.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
Python is one of the most popular programming languages in the world. This library opens up a significant amount of XRP Ledger functionality to Python developers, whether they are just learning to code or have been working in the language for years. Data scientists and engineers working on machine learning will find it far easier to work with and build on top of the XRP Ledger by using this library as part of their Python-based toolkit.
|
||||
|
||||
Previously, the only actively maintained libraries were for [JavaScript](https://github.com/ripple/ripple-lib) or [Java](https://github.com/XRPLF/xrpl4j). To do any extensive work with the XRP Ledger, Python developers had to either switch to a less familiar language or rely on libraries whose shelf life was unclear. All of this is now available natively, as an easy-to-use library that is friendly to crypto newbies.
|
||||
|
||||
The `xrpl-py` library offers a range of features including:
|
||||
|
||||
* Serializing, signing, and submitting transactions
|
||||
* [Cryptographic key generation](https://github.com/XRPLF/xrpl-py#manage-keys-and-wallets)
|
||||
* [Converting between X-Addresses and classic addresses](https://github.com/XRPLF/xrpl-py#encode-addresses)
|
||||
* Retrieving account information, including balances
|
||||
* [Model objects for all transaction types](https://xrpl-py.readthedocs.io/en/latest/source/xrpl.models.transactions.html) and all core server [requests](https://xrpl-py.readthedocs.io/en/latest/source/xrpl.models.requests.html)
|
||||
|
||||
We think of `xrpl-py` v1.0.0 as the first step in a longer journey. We built `xrpl-py` as part of our larger goal to facilitate development on the XRP Ledger by decreasing the learning curve, creating more inclusive tools and expanding the choice of programming languages.
|
||||
|
||||
The feature set for the first available version is limited but it implements the most common use cases of XRP Ledger development. We're working on adding new features to `xrpl-py` and aim to include everything else the XRP Ledger offers within the library soon. We plan on using this framework to create even more libraries for the XRP Ledger in other languages in the near future.
|
||||
|
||||
Since we designed `xrpl-py` to be usable for a wide range of developer levels, you can find the functionality that matches your skill level. For beginners, the library offers several higher-level functions that abstract away a lot of details and provide useful developer interfaces. More experienced developers can access the lower-level methods and functions to build more complex projects. Overall, `xrpl-py` closely mirrors the underlying [core server API](https://xrpl.org/rippled-api.html) so even developers who have built directly on the core server in the past should find the structure of the project familiar.
|
||||
|
||||
While the team at RippleX built the first release of `xrpl-py`, we did this while taking input from the community. We feel that libraries like `xrpl-py` work best when they are owned, used, and supported by a large and thriving community of excited developers. To that end, we contributed the code to the XRPLF, who are hosting the source code under their [GitHub organization](https://github.com/XRPLF), which features a growing number of libraries and other developer tools.
|
||||
|
||||
To get started, see [this tutorial](https://xrpl.org/get-started-using-python.html) on xrpl.org, check out the [README in the project repo](https://github.com/XRPLF/xrpl-py#xrpl-py), or go right to the [reference documentation](https://xrpl-py.readthedocs.io/).
|
||||
|
||||
For more discussion about developing on the XRP Ledger, catch the [RippleXDev stream](https://www.twitch.tv/ripplexdev) on Twitch!
|
||||
27
content/blog/2021/introducing-xrpl4j.md
Normal file
27
content/blog/2021/introducing-xrpl4j.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-05-20
|
||||
labels:
|
||||
- xrpl4j Release Notes
|
||||
---
|
||||
# Introducing xrpl4j
|
||||
|
||||
RippleX and the XRP Ledger Foundation (XRPLF) are pleased to announce the release of`xrpl4j`, a pure Java library for interacting with the XRP Ledger (XRPL). [`xrpl4j`](https://github.com/XRPLF/xrpl4j) provides convenient tooling for developers to take full advantage of all the XRP Ledger has to offer, including wallet derivation, address encoding, transaction serialization and signing and native Java objects modeling core primitives of the rippled API.
|
||||
|
||||
Though `xrpl4j` was initially built as a tool for internal Ripple projects, we have since open-sourced the code on Github under the XRP Ledger Foundation organization. We’ve also released [two major versions](https://search.maven.org/search?q=org.xrpl) to Maven Central. This library exposes a large portion of the functionality of the XRP Ledger and can be used in any JVM environment, opening the door for Android and server-side Java developers alike to start developing XRP Ledger apps. Whether you are a novice XRP Ledger developer or a seasoned vet, the `xrpl4j` API offers an easy and idiomatic toolkit for your next app.
|
||||
|
||||
Prior to the release of `xrpl4j`, Java developers interested in building on top of the XRP Ledger either had to write large amounts of complicated code themselves or develop their apps using [JavaScript](https://github.com/ripple/ripple-lib) or [Python](https://github.com/XRPLF/xrpl-py). Now, they can enjoy the features of those libraries in an easy-to-use, fully native Java library.
|
||||
|
||||
The `xrpl4j` library offers a range of features including:
|
||||
|
||||
* Cryptographic key and account generation
|
||||
* Transaction serialization, secure signing and submission
|
||||
* Model objects for all [transaction types](https://xrpl.org/transaction-formats.html) and the most commonly used [Ledger objects](https://xrpl.org/ledger-data-formats.html) and [server API](https://xrpl.org/public-rippled-methods.html) requests and responses
|
||||
|
||||
The feature set of the library includes almost everything that the XRP Ledger supports. However, by design, `xrpl4j` does not provide abstractions on top of the core rippled API. This design equips developers with the most flexibility in how they use the XRP Ledger, and has the added benefit of being familiar to developers who have built directly on the rippled API. Additionally, newer XRPL developers only have to learn one API instead of needing to learn the core rippled server API along with a new library interface.
|
||||
|
||||
While the team at RippleX has built a majority of `xrpl4j` thus far, we did this with input from the developer community. We feel that libraries like `xrpl4j` work best when they are owned, used and supported by a large and thriving community. To that end, we contributed the code to the XRPLF, who is hosting the source code under their [GitHub organization](https://github.com/XRPLF), which features a growing number of libraries and other developer tools supporting the XRP Ledger community.
|
||||
|
||||
To get started with `xrpl4j`, follow [this tutorial](https://xrpl.org/get-started-using-java.html) on xrpl.org, check out the [README in the project repo](https://github.com/XRPLF/xrpl4j/blob/main/README.md) or go right to the [reference documentation](https://javadoc.io/doc/org.xrpl/xrpl4j-parent/2.0.0/index.html).
|
||||
|
||||
For more discussions about building on top of the XRP Ledger and to see `xrpl4j` in action, tune into the [RippleXDev](https://www.twitch.tv/ripplexdev) Twitch stream on May 25 at 11am PT.
|
||||
@@ -0,0 +1,139 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-03-16
|
||||
labels:
|
||||
- Development
|
||||
---
|
||||
# Message Routing Optimizations, Pt. 1: Proposal & Validation Relaying
|
||||
|
||||
_by Gregory Tsipenyuk and Nikolaos D. Bougalis of Ripple_
|
||||
|
||||
Like all peer-to-peer networks, the XRP Ledger needs a strategy to ensure that messages are propagated across the network. Of course, some types of messages are more important or more time-sensitive than others, so the XRP Ledger uses different strategies for relaying different types of messages.
|
||||
|
||||
This blog post discusses the message propagation strategy used for “proposal” and “validation” messages, which are part of the [consensus protocol](https://xrpl.org/consensus.html), and the improvements that the RippleX team researched and is contributing.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Current System
|
||||
|
||||
Currently, the XRP Ledger uses [flooding](https://en.wikipedia.org/wiki/Flooding_%28computer_networking%29) to propagate proposal and validation messages; in other words, when a server receives a proposal or validation message, that server passes it on to all of its peers except the one it got the message from initially. A proposal message contains a set of candidate transactions and a proposed close time for the next ledger, while a validation message contains information about the ledger built by applying a set of proposals.
|
||||
|
||||
Flooding protocols are generally reliable in propagating messages throughout the network since they naturally utilize every path. However, they can also be inefficient, especially in densely connected networks, where they can increase bandwidth usage dramatically and impose additional work on the servers that must process those messages..
|
||||
|
||||
For example, in the graph below, if _A_ sends a message to _B_ and _C_, the flood algorithm might result in both _B_ and _C_ sending the message to each other. Unfortunate timing may even make it possible for one of them to even send the message back to _A_, which originated it (Figure 1).
|
||||
|
||||
> 
|
||||
>
|
||||
> _Figure 1. Redundant message propagation from node A to node B_
|
||||
|
||||
While this example is a hypothetical scenario, we felt that the impact of redundant message propagation on the XRP Ledger network could be substantial, so we collected and analyzed data in an attempt to better understand the scope of the problem.
|
||||
|
||||
## Initial Research and Approach
|
||||
|
||||
We crawled the XRP Ledger main network with [Peer Crawler](https://xrpl.org/peer-crawler.html) and collected the number of peers for each reachable node: we discovered a total of 759 reachable nodes and 9,926 links between the nodes. About 73% of the nodes have more than 10 peers, 10% have more than 50 peers, and 6% have more than 200 peers. The highest number of peers we detected was 238.
|
||||
|
||||
We also used the [get_counts](https://xrpl.org/get_counts.html) API method on a Ripple-operated node connected to the XRP Ledger mainnet, to determine the frequency of various message types. We discovered that, during the sampling period, proposal and validation messages accounted for 72% of the 42 million messages.
|
||||
|
||||
These percentages are not unexpected and confirmed the theory that the propagation of proposal and validation messages has a significant impact on the bandwidth usage of individual nodes and the network as a whole, and that message duplication likely has a measurable impact on the performance of the network as a whole.
|
||||
|
||||
We are proposing to mitigate the load on the network by optimizing the relaying strategy for proposal and validation messages by limiting transmission of duplicates, resulting in a net reduction of the number of messages relayed.
|
||||
|
||||
|
||||
## How It Works
|
||||
|
||||
The proposal, previously [outlined on xrpchat.com](https://www.xrpchat.com/topic/33075-suggestion-reduce-relaying/), accomplishes this by allowing a server to select a subset of its peers to function as the source of proposal and validation messages from a specific validator and suppressing the messages from the rest of its peers by sending a “squelch” message to them.
|
||||
|
||||
This process should work well because, generally, the flooding protocol utilizes all paths throughout the network equally, and since some paths will be “shortest” or “fastest” in the sense that they consistently deliver the message from a particular validator faster than others we can identify the peers with the lowest latency and select them as a preferred source of the proposal and validation messages.
|
||||
|
||||
The node uses the number of messages received from each peer to make a short list of peers who've sent a good number of messages. Then it randomly chooses some of those peers to be its preferred source of validation and proposal messages. To everyone else, the node sends a "squelch" message, telling them not to relay certain messages to it for a while.
|
||||
|
||||
More specifically, the “squelch” message tells a peer to suppress messages originating from a certain validator (identified by a public key) for a given amount of time. After the duration expires, the peer starts relaying messages downstream (Figure 2).
|
||||
|
||||
When the node gets a message from a new peer, or receives a message from a peer whose squelch duration has passed, that node restarts the peer selection process. Similarly, if a selected peer disconnects, then the node sends an “un-squelch” message to all squelched peers requesting that they resume relaying messages, then restarts its peer selection process.
|
||||
|
||||
This mechanism allows to adjust the peer’s selection process to changes in the network topology. Note that a node maintains a record of the squelch duration for each squelched peer and doesn’t start the selection process if a message from a squelched peer is received too soon.
|
||||
|
||||
This process is further demonstrated on a sequence diagram in Figure 2(A). Node _G_ propagates validation and proposal messages from a validator to nodes _B_ through _F_ (blue arrows) via some route (1).
|
||||
|
||||
> 
|
||||
>
|
||||
> _Figure 2. Relay Reduction concept sequence diagram and graph visualization._
|
||||
|
||||
Nodes _B_ through _F_ are peers of node _A_ and relay the messages to node _A_ (green arrows). Consequently, node _A_ receives each message 5 times. As node _A_ receives the messages from its peers, it determines that messages from nodes _C_, _D_, and _E_ arrive sooner than from the rest of the peers.
|
||||
|
||||
Node _A_ selects these peers as the source of the messages from the validator and sends a “squelch” message to nodes _B_ and _F_ (red arrows). Node _G_ keeps on relaying the messages to nodes _B_ through _F_ but only nodes _C_, _D_, and _E_ relay the messages to node _A_ (2).
|
||||
|
||||
At some point, nodes _B_ and _F_ un-squelch and start relaying the messages to node _A_. Node _A_ determines this time that nodes _B_, _C_, and _E_ should be the source of the messages from the validator and sends squelch messages to nodes _D_ and _F_ (3).
|
||||
|
||||
This is further visualized as a graph on Figure 2 (B, C) where graphs (B) and (C) correspond to sequence (1) and (2) respectively. We can see that the relay reduction algorithm reduces the number of down-links to A by 2. As demonstrated in the Results section below, the reduction in links, when scaled up to the main network, is significant.
|
||||
|
||||
However, as can be seen from Figure 2(C), node _A_ still receives 3 redundant messages. In an ideal network topology a broadcast tree is formed in such a way that each node receives a unique message only once. This topology can be represented as a subgraph or a [spanning tree](https://en.wikipedia.org/wiki/Spanning_tree), which has every node (vertex) covered with a minimum possible number of links (edges).
|
||||
|
||||
> 
|
||||
>
|
||||
> _Figure 3. Pros and cons of a spanning tree broadcast._
|
||||
|
||||
Consider a message propagation in a network represented by a directed graph in figure 3(A). A simulated message propagation via Breadth First Search (BFS) from a vertex _A_ through the graph forms the following paths: 1) _A→C_, _A→E_, _A→F_; 2) _C→D_, _C→E_; 3) _E→B_; 4) _F→B_, _F→D_; 5) _D→B_. All together there are 9 edges in the graph and as can be seen, vertices _B_, _D_, and _E_ have multiple incoming edges; i.e. receive the message from _A_ redundantly 3, 2, and 2 times respectively. If we form a spanning tree by selecting one random incoming edge in each node then it forms a graph in Figure 3(B). This graph has 5 edges; i.e. a number of redundant messages is reduced by 45%.
|
||||
|
||||
This topology is optimal in an ideal network with no failures. But in a real crypto network where links and nodes can experience arbitrary byzantine failure, this topology loses resilience and reliability. Indeed, if a link _C→E_ fails then nodes _E_ and _B_ are not going to receive the message as shown in Figure 3(C). If on the other hand we select two random incoming edges in each node then node _E_ can receive the message via link _A→E_ as shown in figure 3(D). Other failures are still possible in this hypothetical network since nodes _C_ and _F_ have only one incoming edge; i.e. there is no redundancy.
|
||||
|
||||
There are some strategies where an optimal broadcast tree can be constructed with the flooding used for fast recovery in case of failures as described in the [Epidemic Broadcast Tree](https://core.ac.uk/download/pdf/32330596.pdf) research paper. We are collaborating with University of Luxembourg researchers to investigate how other overlay optimization strategies can be applied.
|
||||
|
||||
### Validating This Proposal
|
||||
|
||||
To prove the validity of this proposal, we modeled the XRPL network as a [directed graph](https://en.wikipedia.org/wiki/Directed_graph) and demonstrated that the graph remains connected when “squelched” edges are removed and that there is a substantial reduction in relayed messages.
|
||||
|
||||
A network node is represented by a vertex and a connection between two nodes in the network is represented by two directed edges connecting the nodes in the opposite direction. The directed edges model the message propagation within the network.
|
||||
|
||||
To model the peer squelching, for each vertex in the graph we randomly select 5 neighbors, and for the rest of the neighbors, remove the incoming edges. The resulting graph is a snapshot of a message propagation path from a node to all other nodes.
|
||||
|
||||
Note that the resulting paths are not the optimal paths since the source upstream vertices are selected at random. It is expected that on a live network the paths would be better optimized since the peers are selected using latency as the selection criterion.
|
||||
|
||||
We took 100,000 snapshots of the graph constructed this way. For each snapshot we recorded:
|
||||
|
||||
* if the graph is weakly connected;
|
||||
* a number of nodes in the largest strongly connected component;
|
||||
* if remaining nodes have an incoming edge from the component; and
|
||||
* a number of undirected edges.
|
||||
|
||||
## Results
|
||||
|
||||
The graph remains weakly connected in every snapshot. On average there are 465 nodes in the largest strongly connected component, all remaining nodes have an incoming edge from the component, and on average there are 3,477 edges in the component.
|
||||
|
||||
There are two important findings in the results. First that the remaining nodes have an incoming edge from the component. If a node is the originator of a message, a validator in the XRPL network, then it ignores the squelch request and relays the message to all its peers.
|
||||
|
||||
Consequently, if a remaining node is a message’s originator, then the message will be propagated to the strongly connected component, and from the strongly connected component, it can be propagated to any of the remaining nodes. If a node in the strongly connected component is a message’s originator, then the message can be propagated to all remaining nodes. Therefore, a message originating at any node within the graph can be propagated to any node.
|
||||
|
||||
Second, while the reduced graph retains its ability to propagate a message throughout the network, it has 2.8 times less edges, which may result in significantly less redundant messages propagated throughout the network.
|
||||
|
||||
Note that a snapshot represents an optimally reduced graph in that it has all non-source vertices squelched at the same time. In the real network, the vertices/nodes are squelched and un-squelched at a random time resulting in a higher average number of edges.
|
||||
|
||||
We can model this by introducing a timeline to the graph where each vertex selects 5 neighbors at random and squelches the rest for a random duration. When a neighbor is squelched, the incoming edge is removed. When a neighbor is un-squelched, the respective incoming edge is added back.
|
||||
|
||||
Each change in the number of edges is recorded in the timeline. We simulated 120 minutes of this process. The result is shown on Figure 4.
|
||||
|
||||
The network starts in a normal mode with 9,926 links. After about 5 minutes all vertices squelch their redundant neighbors, resulting in a significant reduction of links. As neighbors start to randomly squelch and un-squelch, a number of links averages at 4,210 with standard deviation 157. The reduction in links in this case is 2.4-fold.
|
||||
|
||||
> 
|
||||
>
|
||||
> _Figure 4. Model of a number of links over time._
|
||||
|
||||
Validating the Results To collect information, we instantiated a testnet with 40 nodes, 10 of which were configured as validators; each node had 20 peers. We conducted several one-hour runs of this network, both with and without the “reduce relay” feature. The results are shown in Table 1.
|
||||
|
||||
The reduction in a number of messages and size is about 2.76 fold, which is within the estimated range of reduction 2.4-2.8 fold. Bandwidth savings in this case is about 528K/sec.
|
||||
|
||||
| Metric | Relay Reduction disabled | Relay Reduction enabled | Reduction |
|
||||
|:-------------|:-------------------------|:------------------------|:----------|
|
||||
| Count | 15,628,604 | 5,653,278 | 276% |
|
||||
| Size (bytes) | 2,979,290,492 | 1,077,290,776 | 276% |
|
||||
|
||||
The expected bandwidth savings across the entire XRP Ledger main network from applying the relay reduction feature can be estimated using data from the model and information collected from the main network, and works out to approximately ~1MB/sec per validator.
|
||||
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
Modeling and testing of the relay reduction feature demonstrate that it is effective at reducing the amount of proposal and validation messages can be reduced roughly by 2.5 times without affecting message propagation.
|
||||
|
||||
These results are incredibly exciting and will help make the protocol more efficient. We hope to see other node operators test the relay reduction enhancement, and validate the results.
|
||||
|
||||
In the meantime, we will continue research improvements in message routing, focusing especially on the routing of transaction messages. Unlike proposals and validations, which only originate from nodes configured as validators, transactions can originate at any node and that necessitates a different approach. We hope to outline the thinking and provide more details on this topic in an upcoming blog post.
|
||||
41
content/blog/2021/reserves-lowered.md
Normal file
41
content/blog/2021/reserves-lowered.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-09-21
|
||||
labels:
|
||||
- Advisories
|
||||
---
|
||||
# Lower Reserves Are Now In Effect
|
||||
|
||||
Over the course of the past year, several members of the XRP Ledger community have advocated for lowering the reserve requirements in the network to compensate for the sustained increase in the price of XRP. On 2021-09-19, [the new reserve values went into effect](https://livenet.xrpl.org/transactions/5922A0BA30621C60B2B6DDBC3FF6B5BB509EB3685C4C3D56696A9FE4FE6D48A3/raw) after gaining support from a majority of validators. The new reserve amounts are **10 XRP** base for an account plus **2 XRP** per object owned in the ledger, down from 20 XRP base and 5 XRP per object owned.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Impacts
|
||||
|
||||
Some XRP that was previously reserved is now available for use. Since the base reserve requirement has decreased from 20 to 10, accounts with a balance of at least 20 XRP now have access to the difference of 10 XRP, plus a decrease of 3 XRP per item owned (from 5 each to 2 each). For example, if your account owns 4 objects in the ledger, your reserve requirement decreased from 40 XRP (20 + 4×5) to 18 XRP (10 + 4×2).
|
||||
|
||||
It is now possible to fund new accounts by sending a payment of as little as 10 XRP; previously, at least 20 XRP was required.
|
||||
|
||||
The [special transaction cost](https://xrpl.org/transaction-cost.html) to [delete an account](https://xrpl.org/accounts.html#deletion-of-accounts) is based on the owner reserve, so deleting an account now requires burning only 2 XRP instead of 5 XRP.
|
||||
|
||||
|
||||
## Action Recommended
|
||||
|
||||
Most XRP Ledger users and integrations do not need to take action to benefit from the reduced reserve. However, if you have software with a hard-coded reserve of 20 XRP, you should consider adjusting it to use the new values, or better yet, occasionally query the reserve information from the API:
|
||||
|
||||
To look up XRP reserves, see the [server_info method](https://xrpl.org/server_info.html)'s response. In particular, the `validated_ledger.reserve_base_xrp` field shows the base account reserve and the `validated_ledger.reserve_inc_xrp` shows the owner reserve (per item). You can also use the [server_state method](https://xrpl.org/server_state.html) to get the values in drops of XRP.
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
The XRP Ledger has [reserve requirements](https://xrpl.org/reserves.html) to disincentivize spamming the ledger with data, which must be replicated throughout the network and maintained by all servers in the system. The _base reserve_ (now 10 XRP) sets the minimum XRP that must be sent to create a new account, and the _owner reserve_ (now 2 XRP per item) increases an account's reserve for each additional object the account owns in the ledger's [state data](https://xrpl.org/ledger-data-formats.html), such as Offers, trust lines and Escrows.
|
||||
|
||||
The [Fee Voting](https://xrpl.org/fee-voting.html) process lets validators in the decentralized XRP Ledger network collectively adjust the reserve requirements. One reason to adjust reserve requirements is to compensate for long-term changes in the value of XRP. Fee voting can adjust reserves in either direction, but as XRP Ledger expert David Schwartz notes, [increases in the reserve are more painful for users than decreases](https://twitter.com/JoelKatz/status/1380980093858631682), so validator operators should avoid lowering the reserve if doing so is likely to require an increase later.
|
||||
|
||||
The previous time the reserves changed was in [December 2013](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/), when 20 XRP was worth much less in fiat currency than it is today. The new 10 XRP reserve brings the fiat-currency cost of creating a new XRP Ledger account closer to the historical average.
|
||||
|
||||
## XRP Ledger Foundation Statement
|
||||
|
||||
The XRP Ledger Foundation posted this statement about the change to Twitter:
|
||||
|
||||
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">We are very happy to see that the reserves have been voted down to 10/2 by validators. The foundation firmly believes in increasing accessibility to the XRP Ledger and hope this trend will continue in the same direction.</p>— XRP Ledger Foundation (Official) (@XRPLF) <a href="https://twitter.com/XRPLF/status/1439655907051274241?ref_src=twsrc%5Etfw">September 19, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
|
||||
69
content/blog/2021/ripple-lib-drops-lodash-browsers.md
Normal file
69
content/blog/2021/ripple-lib-drops-lodash-browsers.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-08-26
|
||||
labels:
|
||||
- xrpl.js Release Notes
|
||||
---
|
||||
# ripple-lib Drops Lodash Requirement in Browsers
|
||||
|
||||
[Version 1.10.0](https://github.com/ripple/ripple-lib/releases/tag/1.10.0) of ripple-lib, the JavaScript/TypeScript library for the XRP Ledger, no longer requires a separate Lodash script to run in web browsers. This change comes alongside other continued improvements in the library, improving the experience of developing applications on the XRP Ledger.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Update Your Script Tags
|
||||
|
||||
Starting with 1.10.0, ripple-lib incorporates Lodash into the browser-ready JavaScript build, so you can import just the library and get a working environment. Previously, you needed a separate script tag to import the Lodash dependency in web browsers.
|
||||
|
||||
**Before:**
|
||||
|
||||
```html
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js"></script>
|
||||
<script src="https://unpkg.com/ripple-lib@1.9.8/build/ripple-latest-min.js"></script>
|
||||
```
|
||||
|
||||
**After:**
|
||||
|
||||
```html
|
||||
<script src="https://unpkg.com/ripple-lib@1.10.0/build/ripple-latest-min.js"></script>
|
||||
```
|
||||
|
||||
**Tip:** You can safely update ripple-lib to 1.10.0 even if you haven't removed the Lodash script tag. The extra script tag is now an unnecessary extra download for most cases, but it doesn't cause errors if it's still there.
|
||||
|
||||
## Same Process on Node.js
|
||||
|
||||
There is no change to how dependencies are managed when using ripple-lib in Node.js.
|
||||
|
||||
## Other Changes
|
||||
|
||||
As always, version 1.10.0 includes various minor improvements to fix bugs and improve documentation. There's also a new API method to call the [Testnet (or Devnet) faucet](https://xrpl.org/xrp-testnet-faucet.html) to get a new account pre-funded with test XRP. This method automatically selects the appropriate faucet based on which network you're already connected to. (It raises an error if you're connected to the Mainnet!)
|
||||
|
||||
Example usage:
|
||||
|
||||
```js
|
||||
const ripple = require('ripple-lib') // Node.js only. Use a <script> tag in browsers
|
||||
async function main() {
|
||||
const api = new ripple.RippleAPI({server: 'wss://s.altnet.rippletest.net:51233'})
|
||||
await api.connect()
|
||||
const data = await api.generateFaucetWallet()
|
||||
console.log(data)
|
||||
// {
|
||||
// account: {
|
||||
// xAddress: 'TVH9dJMaXuuTzxgWCqn9PvKdu65Uxij1mS1spgTJ2QkshXg',
|
||||
// secret: 's████████████████████████████',
|
||||
// classicAddress: 'rGyvpAdjkg7EwJdNY8K2GvvEzeNJ8hfHZU',
|
||||
// address: 'rGyvpAdjkg7EwJdNY8K2GvvEzeNJ8hfHZU'
|
||||
// },
|
||||
// amount: 1000,
|
||||
// balance: 1000
|
||||
// }
|
||||
|
||||
api.disconnect()
|
||||
}
|
||||
main()
|
||||
```
|
||||
|
||||
## Looking Forward: xrpl.js
|
||||
|
||||
The developers of ripple-lib are targeting version 2.0 as a major update containing breaking changes. One of the changes will be renaming the library to **xrpl.js**. The name ripple-lib dates back to [the beginning](https://xrpl.org/history.html), and it's long overdue to rename the library in keeping with the evolution of the XRP Ledger as a network and a community.
|
||||
|
||||
There is no set schedule for this update, but it's likely to release sometime in Q3 of this year. Stay tuned for more updates on the changes to make xrpl.js version 2.0 a better and more consistent experience for developers, or [follow the development process](https://github.com/ripple/ripple-lib/pulls?q=is%3Apr+label%3A%22ripple-lib+2.0+%28xrpl.js%29%22) and add your voice to the community.
|
||||
207
content/blog/2021/rippled-1.7.0.md
Normal file
207
content/blog/2021/rippled-1.7.0.md
Normal file
@@ -0,0 +1,207 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-02-24
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
---
|
||||
# Introducing XRP Ledger version 1.7.0
|
||||
|
||||
Ripple has released version 1.7.0 of `rippled`, the reference server implementation of the XRP Ledger protocol. This release [significantly improves memory usage](https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/), introduces a protocol amendment to allow out-of-order transaction execution with Tickets, and brings several other features and improvements.
|
||||
|
||||
## Upgrading (SPECIAL ACTION REQUIRED)
|
||||
|
||||
If you use the precompiled binaries of `rippled` that Ripple publishes for supported platforms, please note that Ripple has renewed the GPG key used to sign these packages. If you are upgrading from a previous install, you must download and trust the renewed key. **Automatic upgrades will not work** until you have re-trusted the key.
|
||||
|
||||
### Red Hat Enterprise Linux / CentOS
|
||||
|
||||
_(These instructions have been updated.)_ First, re-add the repository to get the updated key.
|
||||
|
||||
```
|
||||
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
|
||||
[ripple-stable]
|
||||
name=XRP Ledger Packages
|
||||
enabled=1
|
||||
gpgcheck=0
|
||||
repo_gpgcheck=1
|
||||
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable
|
||||
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
|
||||
REPOFILE
|
||||
```
|
||||
|
||||
Then perform a [manual upgrade](https://xrpl.org/update-rippled-manually-on-centos-rhel.html). When prompted, confirm that the key's fingerprint matches the following example, then press `y` to accept the updated key:
|
||||
|
||||
```sh
|
||||
$ sudo yum install rippled
|
||||
Loaded plugins: fastestmirror
|
||||
Loading mirror speeds from cached hostfile
|
||||
* base: mirror.web-ster.com
|
||||
* epel: mirrors.syringanetworks.net
|
||||
* extras: ftp.osuosl.org
|
||||
* updates: mirrors.vcea.wsu.edu
|
||||
ripple-nightly/signature
|
||||
| 650 B 00:00:00
|
||||
Retrieving key from https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
|
||||
Importing GPG key 0xCCAFD9A2:
|
||||
Userid : "TechOps Team at Ripple <techops+rippled@ripple.com>"
|
||||
Fingerprint: c001 0ec2 05b3 5a33 10dc 90de 395f 97ff ccaf d9a2
|
||||
From : https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
|
||||
Is this ok [y/N]: y
|
||||
```
|
||||
|
||||
### Ubuntu / Debian
|
||||
|
||||
Download and trust the updated public key, then perform a [manual upgrade](https://xrpl.org/update-rippled-manually-on-ubuntu.html) as follows:
|
||||
|
||||
```bash
|
||||
$ wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
|
||||
sudo apt-key add -
|
||||
$ sudo apt -y update
|
||||
$ sudo apt -y install rippled
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
On supported platforms, see the [instructions on updating rippled](https://xrpl.org/install-rippled.html).
|
||||
|
||||
| Package | SHA-256 |
|
||||
|:--------|:--------|
|
||||
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.7.0-1.el7.x86_64.rpm) | `da32137d460c6c2ce5b7035d82b637f71138fa92564f7ab1fdf04d1e59be8f2a` |
|
||||
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.7.0-1_amd64.deb) | `1920881caab4fac02a4a99a67bb4f2746b89f7b99f2c28e83832039a2dd5d8a5` |
|
||||
|
||||
For other platforms, please [build from source](https://github.com/ripple/rippled/tree/master/Builds). The most recent commit in the git log should be the change setting the version:
|
||||
|
||||
```text
|
||||
commit c0a0b79d2d483b318ce1d82e526bd53df83a4a2c
|
||||
Author: manojsdoshi <mdoshi@ripple.com>
|
||||
Date: Tue Feb 23 12:51:11 2021 -0800
|
||||
|
||||
Set version to 1.7.0
|
||||
```
|
||||
|
||||
## Change Log
|
||||
|
||||
### New and Improved Features
|
||||
|
||||
- **Rework deferred node logic and async fetch behavior:** This change significantly improves ledger sync and fetch times while reducing memory consumption. (More information on the [RippleX blog](https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/))
|
||||
|
||||
- **New Ticket feature:** Tickets are a mechanism to prepare and send certain transactions outside of the normal sequence order. This version reworks and completes the implementation for Tickets after more than 6 years of development. This feature is now open for voting as the newly-introduced `TicketBatch` amendment, which replaces the previously-proposed `Tickets` amendment. The specification for this change can be found at: [xrp-community/standards-drafts#16](https://github.com/xrp-community/standards-drafts/issues/16)
|
||||
|
||||
- **Add Reporting Mode:** The server can be compiled to operate in a new mode that serves API requests for validated ledger data without connecting directly to the peer-to-peer network. (The server needs a gRPC connection to another server that is on the peer-to-peer network.) Reporting Mode servers can share access to ledger data via Apache Cassandra and PostgreSQL to more efficiently serve API requests while peer-to-peer servers specialize in broadcasting and processing transactions. ([#3609](https://github.com/ripple/rippled/pull/3609))
|
||||
|
||||
- **Optimize relaying of validation and proposal messages:** Servers typically receive multiple copies of any given message from directly connected peers; in particular, consensus proposal and validation messages are often relayed with extremely high redundancy. For servers with several peers, this can cause redundant work. This commit introduces experimental code that attempts to optimize the relaying of proposals and validations by allowing servers to instruct their peers to "squelch" delivery of selected proposals and validations. This change is considered experimental at this time and is disabled by default because the functioning of the consensus network depends on messages propagating with high reliability through the constantly-changing peer-to-peer network. Server operators who wish to test the optimized code can enable it in their server config file. ([#3412](https://github.com/ripple/rippled/pull/3412))
|
||||
|
||||
- **Report server domain to other servers:** Server operators now have the option to configure a domain name to be associated with their servers. The value is communicated to other servers and is also reported via the `server_info` API. The value is meant for third-party applications and tools to group servers together. For example, a tool that visualizes the network's topology can show how many servers are operated by different stakeholders. An operator can claim any domain, so tools should use the [xrp-ledger.toml file](https://xrpl.org/xrp-ledger-toml.html) to confirm that the domain also claims ownership of the servers. ([#3597](https://github.com/ripple/rippled/pull/3597))
|
||||
|
||||
- **Improve handling of peers that aren't synced:** When evaluating the fitness and usefulness of an outbound peer, the code would incorrectly calculate the amount of time that the peer spent in a non-useful state. This release fixes the calculation, and server operators can now configure the timeout values in the `[overlay]` stanza of the config file. ([#3603](https://github.com/ripple/rippled/pull/3603))
|
||||
|
||||
- **Persist API-configured voting settings:** Previously, the amendments that a server would vote in support of or against could be configured both via the configuration file and via the ["feature" API method](https://xrpl.org/feature.html). Changes made in the configuration file were only loaded at server startup; changes made via the command line take effect immediately but were not persisted across restarts. Starting with this release, changes made via the API are saved to the `wallet.db` database file so that they persist even if the server is restarted. ([#3617](https://github.com/ripple/rippled/pull/3617))
|
||||
|
||||
Amendment voting in the config file is deprecated. The first time the server starts with v1.7.0 or higher, it reads any amendment voting settings in the config file and saves the settings to the database; on later restarts the server prints a warning message and ignores the `[amendments]` and `[veto_amendments]` stanzas of the config file.
|
||||
|
||||
Going forward, use the [feature method](https://xrpl.org/feature.html) to view and configure amendment votes. If you want to use the config file to configure amendment votes, add a line to the `[rpc_startup]` stanza such as the following:
|
||||
|
||||
[rpc_startup]
|
||||
{ "command": "feature", "feature": "FlowSortStrands", "vetoed": true }
|
||||
|
||||
- **Support UNLs with future effective dates:** Updates the format for the recommended validator list file format, allowing publishers to pre-publish the next recommended UNL while the current one is still valid. The server is still backwards compatible with the previous format, but the new format removes some uncertainty during the transition from one list to the next. Also, starting with this release, the server locks down and reports an error if it has no valid validator list. You can clear the error by loading a validator list from a file or by configuring a different UNL and restarting; the error also goes away on its own if the server is able to obtain a trusted validator list from the network (for example, after an network outage resolves itself). ([#3619](https://github.com/ripple/rippled/pull/3619))
|
||||
|
||||
- **Improve manifest relaying:** Servers now propagate change messages for validators' ephemeral public keys ("manifests") on a best-effort basis, to make manifests more available throughout the peer-to-peer network. Previously, the server would only relay manifests from validators it trusts locally, which made it difficult to detect and track validators that are not broadly trusted. ([#3722](https://github.com/ripple/rippled/pull/3722))
|
||||
|
||||
- **Implement ledger forward replay feature:** The server can now sync up to the network by "playing forward" transactions from a previously saved ledger until it catches up to the network. Compared with the default behavior of fetching the latest state and working backwards, forward replay can save time and bandwidth by reconstructing previous ledgers' state data rather than downloading the pre-calculated results from the network. As an added bonus, forward replay confirms that the rest of the network followed the same transaction processing rules as the local server when processing the intervening ledgers. This feature is considered experimental this time and can be enabled with an option in the config file. ([#3659](https://github.com/ripple/rippled/pull/3659))
|
||||
|
||||
- **Make the transaction job queue limit adjustable:** The server uses a job queue to manage tasks, with limits on how many jobs of a particular type can be queued. The previously hard-coded limit associated with transactions is now configurable. Server operators can increase the number of transactions their server is able to queue, which may be useful if your server has a large memory capacity or you expect an influx of transactions. ([#3556](https://github.com/ripple/rippled/issues/3556))
|
||||
|
||||
- **Add public_key to the Validator List method response:** The [Validator List method](https://xrpl.org/validator-list.html) can be used to request a recommended validator list from a `rippled` instance. The response now includes the public key of the requested list. ([#3392](https://github.com/ripple/rippled/issues/3392))
|
||||
|
||||
- **Server operators can now configure maximum inbound and outbound peers separately:** The new `peers_in_max` and `peers_out_max` config options allow server operators to independently control the maximum number of inbound and outbound peers the server allows. ([#3616](https://github.com/ripple/rippled/pull/3616))
|
||||
|
||||
- **Improvements to shard downloading:** Previously the `download_shard` command could only load shards over HTTPS. Compressed shards can now also be downloaded over plain HTTP. The server fully checks the data for integrity and consistency, so the encryption is not strictly necessary. When initiating multiple shard downloads, the server now returns an error if there is not enough space to store all the shards currently being downloaded. ([#3578](https://github.com/ripple/rippled/pull/3578), [#3604](https://github.com/ripple/rippled/pull/3604))
|
||||
|
||||
- **The `manifest` command is now public:** The manifest API method returns public information about a given validator. The required permissions have been changed so it is now part of the public API. ([#3612](https://github.com/ripple/rippled/pull/3612))
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- **Implement sticky DNS resolution for validator list retrieval:** When attempting to load a validator list from a configured site, attempt to reuse the last IP that was successfully used if that IP is still present in the DNS response. ([#3494](https://github.com/ripple/rippled/issues/3494))
|
||||
|
||||
- **Improve handling of RPC ledger_index argument:** You can now provide the `ledger_index` as a numeric string. This allows you to copy and use the numeric string `ledger_index` value returned by certain RPC commands. Previously you could only send native JSON numbers or shortcut strings such as "validated" in the `ledger_index` field. ([#3533](https://github.com/ripple/rippled/issues/3533))
|
||||
|
||||
- **Fix improper promotion of bool on return** ([6968da1](https://github.com/ripple/rippled/commit/6968da1))
|
||||
|
||||
- **Fix ledger sequence on copynode** ([#3643](https://github.com/ripple/rippled/pull/3643))
|
||||
|
||||
- **Fix parsing of node public keys in `manifest` CLI:** The previous code attempts to validate the provided node public key using a function that assumes that the encoded public key is for an account. This causes the parsing to fail. The caller can now specify the type of the public key being checked. ([#3317](https://github.com/ripple/rippled/issues/3317))
|
||||
|
||||
- **Fix idle peer timer:** Fixes a bug where a function to remove idle peers was called every second instead of every 4 seconds. ([#3754](https://github.com/ripple/rippled/issues/3754))
|
||||
|
||||
- **Add database counters:** Fix bug where `DatabaseRotateImp::getBackend` and `::sync` utilized the writable backend without a lock. `::getBackend` was replaced with `::getCounters`. ([#3755](https://github.com/ripple/rippled/pull/3755))
|
||||
|
||||
- **Improve online_delete configuration and DB tuning** ([#3321](https://github.com/ripple/rippled/issues/3321))
|
||||
|
||||
- **Improve handling of burst writes in NuDB database** ([#3662](https://github.com/ripple/rippled/pull/3662))
|
||||
|
||||
- **Fix excessive logging after disabling history shards.** Previously if you configured the server with a shard store, then disabled it, the server output excessive warning messages about the shard limit being exceeded. ([#3620](https://github.com/ripple/rippled/pull/3620))
|
||||
|
||||
- **Fixed some issues with negotiating link compression.** ([#3705](https://github.com/ripple/rippled/pull/3705))
|
||||
|
||||
- **Fixed a potential thread deadlock with history sharding.** ([#3683](https://github.com/ripple/rippled/pull/3683))
|
||||
|
||||
- **Various fixes to typos and comments, refactoring, and build system improvements**
|
||||
|
||||
### Amendments introduced in 1.7
|
||||
|
||||
**fixSTAmountCanonicalize:** Fix a rare bug in deserializing currency amounts.
|
||||
**FlowSortStrands:** Improve efficiency of cross-currency payment execution.
|
||||
**TicketBatch:** Add Tickets feature for executing transactions outside of the typical sequence order.
|
||||
For more information on these and other protocol amendments, please see [Known Amendments](https://xrpl.org/known-amendments.html).
|
||||
|
||||
|
||||
## Contributions
|
||||
|
||||
### GitHub
|
||||
|
||||
The public git 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:
|
||||
|
||||
|
||||
- CJ Cobb <ccobb@ripple.com>
|
||||
- Carl Hua <carlhua@gmail.com>
|
||||
- Crypto Brad Garlinghouse <cryptobradgarlinghouse@protonmail.com>
|
||||
- Danil Nemirovsky <danil.nemirovsky@gmail.com>
|
||||
- Devon White <dwhite@ripple.com>
|
||||
- Edward Hennis <ed@ripple.com>
|
||||
- Elliot Lee <github.public@intelliot.com>
|
||||
- Gregory Tsipenyuk <gtsipenyuk@ripple.com>
|
||||
- Howard Hinnant <howard.hinnant@gmail.com>
|
||||
- Ikko Ashimine <eltociear@gmail.com>
|
||||
- David 'JoelKatz' Schwartz <DavidJoelSchwartz@GMail.com>
|
||||
- John Freeman <jfreeman08@gmail.com>
|
||||
- John Northrup <jnorthrup@ripple.com>
|
||||
- Mark Travis <mtravis@ripple.com>
|
||||
- Miguel Portilla <miguelportilla@pobros.com>
|
||||
- Nathan Nichols <natenichols@cox.net>
|
||||
- Nik Bougalis <nikb@bougalis.net>
|
||||
- Peng Wang <pwang200@gmail.com>
|
||||
- Richard Holland <richard.holland@starstone.co.nz>
|
||||
- Scott Schurr <scott@ripple.com>
|
||||
- Wietse Wind <w.wind@ipublications.net>
|
||||
- cdy20 <dcherukhin@ripple.com>
|
||||
- Rome Reginelli <rome@ripple.com>
|
||||
- Manoj Doshi <mdoshi@ripple.com>
|
||||
- Scott Determan <scott.determan@yahoo.com>
|
||||
|
||||
#### Lifetime Contributors
|
||||
|
||||
The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.7.0:
|
||||
|
||||
Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Carl Hua, Casey Bodley, Christian Ramseier, CJ Cobb, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Gábor Lipták, Gregory Tsipenyuk, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jeroen Meulemeester, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Kirill Fomichev, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Alvila, Markus Teufelberger, Mayur Bhandary, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, p2peer, Patrick Dehne, Peng Wang, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, ShangyanLi, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA.
|
||||
|
||||
For a real-time view of all 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.
|
||||
94
content/blog/2021/rippled-1.7.2.md
Normal file
94
content/blog/2021/rippled-1.7.2.md
Normal file
@@ -0,0 +1,94 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-05-24
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
---
|
||||
# Introducing XRP Ledger version 1.7.2
|
||||
|
||||
Version 1.7.2 of `rippled`, the reference server implementation of the XRP Ledger protocol, is now available. This release protects against the security issue [CVE-2021-3499 affecting OpenSSL](https://www.openssl.org/news/secadv/20210325.txt), 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.
|
||||
|
||||
This release supersedes version 1.7.1 and adds fixes for more issues that were discovered during the release cycle.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## 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](https://xrpl.org/amendments.html), 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](https://xrpl.org/known-amendments.html) so you can make informed decisions about [how your validator votes](https://xrpl.org/configure-amendment-voting.html). If you take no action, your validator begins voting in favor of any new amendments as soon as it has been upgraded.
|
||||
|
||||
|
||||
## Install / Upgrade
|
||||
|
||||
On supported platforms, see the [instructions on installing or updating `rippled`](https://xrpl.org/install-rippled.html).
|
||||
|
||||
| Package | SHA-256 |
|
||||
|:--------|:--------|
|
||||
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.7.2-1.el7.x86_64.rpm) | `fbdc7a442b1cbcb04cacda40fc3eb0b6178329b5bf9ba3084b4728a0ed2d9b26` |
|
||||
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.7.2-1_amd64.deb) | `71767ee966b3520796d03ffbdc14ddeeb44876097b897df0ff71b2da3e69e633` |
|
||||
|
||||
For other platforms, please [build from source](https://github.com/ripple/rippled/tree/master/Builds). The most recent commit in the git log should be the change setting the version:
|
||||
|
||||
```text
|
||||
commit 34ee4ca0cb59037e840f7d454114701b534f0afa
|
||||
Author: manojsdoshi <mdoshi@ripple.com>
|
||||
Date: Fri May 7 15:03:49 2021 -0700
|
||||
|
||||
Set version to 1.7.2
|
||||
```
|
||||
|
||||
## Change Log
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
Version 1.7.2 has the following 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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/3843/commits/79e69da3647019840dca49622621c3d88bc3883f))
|
||||
|
||||
- **Support HTTP health check in reporting mode:** Enables the [Health Check special method](https://xrpl.org/health-check.html) when running the server in the new [Reporting Mode][] introduced in 1.7.0. ([9c8cadd](https://github.com/ripple/rippled/pull/3843/commits/9c8caddc5a197bdd642556f8beb14f06d53cdfd3))
|
||||
|
||||
- **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](https://github.com/ripple/rippled/pull/3843/commits/8579eb0c191005022dcb20641444ab471e277f67))
|
||||
|
||||
- **Add `load_factor` in reporting mode:** Adds a `load_factor` value to the [server info method response](https://xrpl.org/server_info.html) 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](https://github.com/ripple/rippled/pull/3843/commits/430802c1cf6d4179f2249a30bfab9eff8e1fa748))
|
||||
|
||||
- **Properly encode metadata from tx RPC command:** Fixes a problem where transaction metadata in the [tx API method response](https://xrpl.org/tx.html) would be in JSON format even when binary was requested. ([7311629](https://github.com/ripple/rippled/pull/3843/commits/73116297aa94c4acbfc74c2593d1aa2323b4cc52))
|
||||
|
||||
- **Updates to Windows builds:** When building on Windows, use `vcpkg` 2021 by default and add compatibility with MSVC 2019. ([36fe196](https://github.com/ripple/rippled/pull/3843/commits/36fe1966c3cd37f668693b5d9910fab59c3f8b1f), [30fd458](https://github.com/ripple/rippled/pull/3843/commits/30fd45890b1d3d5f372a2091d1397b1e8e29d2ca))
|
||||
|
||||
|
||||
[Reporting Mode]: https://xrpl.org/rippled-server-modes.html#reporting-mode
|
||||
|
||||
## Contributions
|
||||
|
||||
### GitHub
|
||||
|
||||
The public git 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:
|
||||
|
||||
- CJ Cobb <ccobb@ripple.com>
|
||||
- Edward Hennis <ed@ripple.com>
|
||||
- Manoj Doshi <mdoshi@ripple.com>
|
||||
- Mark Travis <mtravis@ripple.com>
|
||||
- Nik Bougalis <nikb@bougalis.net>
|
||||
- Scott Determan <scott.determan@yahoo.com>
|
||||
|
||||
#### Lifetime Contributors
|
||||
|
||||
The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.7.2:
|
||||
|
||||
Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Carl Hua, Casey Bodley, Christian Ramseier, CJ Cobb, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Gábor Lipták, Gregory Tsipenyuk, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jeroen Meulemeester, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Kirill Fomichev, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Alvila, Markus Teufelberger, Mayur Bhandary, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, p2peer, Patrick Dehne, Peng Wang, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, ShangyanLi, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA.
|
||||
|
||||
For a real-time view of all 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.
|
||||
45
content/blog/2021/rippled-1.7.3.md
Normal file
45
content/blog/2021/rippled-1.7.3.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-08-27
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
---
|
||||
# Introducing XRP Ledger version 1.7.3
|
||||
|
||||
Version 1.7.3 of `rippled`, the reference server implementation of the XRP Ledger protocol, is now available. This release addresses an out-of-bounds 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 internal data structures. By [community demand](https://github.com/ripple/rippled/issues/3898), this version also introduces the NegativeUNL amendment, which corresponds to the feature which was introduced in [the 1.6.0 release](https://xrpl.org/blog/2020/rippled-1.6.0.html).
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## 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.
|
||||
|
||||
Additionally, this release introduces a new amendment to the XRP Ledger protocol: [NegativeUNL](https://xrpl.org/negative-unl.html). This amendment is now **open for voting** according to the XRP Ledger's [amendment process](https://xrpl.org/amendments.html), which enables protocol changes following two weeks of >80% support from trusted validators. If the NegativeUNL amendment activates, servers running previous versions of `rippled` will become [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked).
|
||||
|
||||
If you operate an XRP Ledger validator, please [learn more about this amendment](https://xrpl.org/known-amendments.html) so you can make informed decisions about [how your validator votes](https://xrpl.org/configure-amendment-voting.html). If you take no action, your validator begins voting in favor of any new amendments as soon as it has been upgraded.
|
||||
|
||||
## Install / Upgrade
|
||||
|
||||
On supported platforms, see the [instructions on installing or updating `rippled`](https://xrpl.org/install-rippled.html).
|
||||
|
||||
| Package | SHA-256 |
|
||||
|:--------|:--------|
|
||||
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.7.3-1.el7.x86_64.rpm) | `d994543be11edeb9c1256cd7e35c6bd7f5b53f23f97b8bdf380302b24269d47e` |
|
||||
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.7.3-1_amd64.deb) | `5d13b32ac00796a50266030de5de40e85c310c762a88e72d435e5c8c2e30becb` |
|
||||
|
||||
For other platforms, please [build from source](https://github.com/ripple/rippled/tree/master/Builds). The most recent commit in the git log should be the change setting the version:
|
||||
|
||||
```text
|
||||
commit 96bbabbd2ece106779bb544aa0e4ce174e99fdf6
|
||||
Author: Nik Bougalis <nikb@bougalis.net>
|
||||
Date: Wed Aug 4 10:52:58 2021 -0700
|
||||
|
||||
Set version to 1.7.3
|
||||
```
|
||||
|
||||
|
||||
## Changelog
|
||||
|
||||
- Improve SLE (Serialized Ledger Entry) 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: Adds an amendment to enable the Negative UNL feature introduced in version 1.6.0.
|
||||
83
content/blog/2021/rippled-1.8.1.md
Normal file
83
content/blog/2021/rippled-1.8.1.md
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-12-02
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
---
|
||||
# Introducing XRP Ledger version 1.8.1
|
||||
|
||||
Version 1.8.1 of `rippled`, the reference server implementation of the XRP Ledger protocol, is now available. This release contains several improvements and optimizations to improve stability and performance under load, along with other features and fixes including deterministic history shards, default amendment votes, and the CheckCashMakesTrustLine amendment.
|
||||
|
||||
This release supersedes version 1.8.0. Version 1.8.1 makes additional changes to database tuning parameters to optimize start-up and syncing time. It is **highly recommended that operators upgrade to 1.8.1 as soon as possible** because the optimizations in this release should help alleviate some of the [pressure on the network from increased usage](https://dev.to/ripplexdev/update-on-the-xrpl-5f3e).
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Action Recommended
|
||||
|
||||
This release introduces a new amendment to the XRP Ledger protocol: CheckCashMakesTrustLine. This amendment is now **open for voting** according to the XRP Ledger's [amendment process](https://xrpl.org/amendments.html), 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.8.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.
|
||||
|
||||
Additionally, version 1.8.1 is highly recommended because the performance optimizations should improve the speed and stability of the server when the network is under high load. Increased network traffic and ledger size in recent months have made it difficult for machines with lower hardware specs to stay synced with the XRP Ledger Mainnet. The optimizations in 1.8.1 mitigate some of the effects of these trends.
|
||||
|
||||
If you issue currency in the XRP Ledger, you can use this new behavior to simplify the process of issuing tokens after the amendment becomes enabled. See the [CheckCashMakesTrustLine description](https://xrpl.org/known-amendments.html#checkcashmakestrustline) for details.
|
||||
|
||||
|
||||
## Install / Upgrade
|
||||
|
||||
On supported platforms, see the [instructions on installing or updating `rippled`](https://xrpl.org/install-rippled.html).
|
||||
|
||||
| Package | SHA-256 |
|
||||
|:--------|:--------|
|
||||
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.8.1-1.el7.x86_64.rpm) | `be092bcb02f8118121f6303ede4f109601f797cd02a1ddaf237604fd54e0237b` |
|
||||
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.8.1-1_amd64.deb) | `b95772f59cfcd0fb2318ad908ab00421bcbd46c430c12371c0fc9d6003ed06b3` |
|
||||
|
||||
For other platforms, please [build from source](https://github.com/ripple/rippled/tree/master/Builds). The most recent commit in the git log should be the change setting the version:
|
||||
|
||||
```text
|
||||
commit fbedfb25aefc609aff2c6090b19c419c224a8ab2
|
||||
Author: manojsdoshi <mdoshi@ripple.com>
|
||||
Date: Wed Nov 24 10:32:25 2021 -0800
|
||||
|
||||
Set version to 1.8.1
|
||||
```
|
||||
|
||||
### Automatic Updates After This Version
|
||||
|
||||
Starting _after_ this version, new `rippled` packages _do not_ automatically restart the server after performing an [automatic upgrade](https://xrpl.org/update-rippled-automatically-on-linux.html). The server continues to run the old version even after upgrading, until it is restarted. The server automatically switches to the new server after a reboot or if you manually restart the service, for example:
|
||||
|
||||
```sh
|
||||
sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
This change is intended to decrease the chances that multiple important servers (including validators, hubs, and public API servers) go offline to restart and re-sync at the same time. However, automatic upgrades _to_ version 1.8.1 still restart the server automatically (after a randomized delay).
|
||||
|
||||
|
||||
## Changelog
|
||||
|
||||
### 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](https://github.com/ripple/rippled/issues/2688), [#3726](https://github.com/ripple/rippled/pull/3726), [#3875](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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. ([#3820](https://github.com/ripple/rippled/pull/3820))
|
||||
- **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. ([#3618](https://github.com/ripple/rippled/pull/3618))
|
||||
- **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. ([#3778](https://github.com/ripple/rippled/pull/3778))
|
||||
- **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](https://github.com/ripple/rippled/pull/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. ([19018e8](https://github.com/ripple/rippled/commit/19018e895905adfe70030f6c03e7ec8d03f81aef))
|
||||
- **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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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.
|
||||
41
content/blog/2021/rippled-1.8.2.md
Normal file
41
content/blog/2021/rippled-1.8.2.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-12-20
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
---
|
||||
# Introducing XRP Ledger version 1.8.2
|
||||
|
||||
Version 1.8.2 of `rippled`, the reference server implementation of the XRP Ledger protocol, is now available. 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.
|
||||
|
||||
Due to the holidays, version 1.8.2 is being made available as a "soft release" in the `unstable` package channel so that operators who are interested can upgrade. Automatic updates will not update to this release until it is pushed to the `stable` branch at a later date.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## 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 [commit `62127d7`](https://github.com/ripple/rippled/commit/62127d725d801641bfaa61dee7d88c95e48820c5). 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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/4031))
|
||||
|
||||
- **Improve full & compressed inner node deserialization**: Remove a redundant copy operation from low-level SHAMap deserialization. ([#4004](https://github.com/ripple/rippled/pull/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](https://github.com/ripple/rippled/pull/4028))
|
||||
|
||||
- **Improve handling of HTTP X-Forwarded-For and Forwarded headers**: Fixes the way the server handles IPv6 addresses in these HTTP headers. ([#4009](https://github.com/ripple/rippled/pull/4009), [#4030](https://github.com/ripple/rippled/pull/4030))
|
||||
|
||||
- **Other minor improvements to logging and Reporting Mode.**
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-02-24
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
---
|
||||
# Road to XRP Ledger 1.7: Improving Efficiency and Security
|
||||
|
||||
Today, [version 1.7.0](https://xrpl.org/blog/2021/rippled-1.7.0.html) of the reference implementation of the software behind the XRP Ledger (XRPL) was released with key contributions from RippleX aimed at improving the Ledger’s decentralization, security and efficiency.
|
||||
|
||||
In this post, RippleX breaks down some of the changes and highlights in the release.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Release Highlights: Improvements for Validators, Server Operators
|
||||
|
||||
As a part of our commitment to the XRP Ledger, RippleX continued to work on improving the use of available system resources and making the software work efficiently on various server configurations. Building on previously contributed improvements, a new set of changes has [slashed memory usage by 50%](https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/). Part of these memory savings came directly from Ripple CTO [David Schwartz](https://twitter.com/JoelKatz), who implemented a change that eliminates a layer of caching to further improve memory and execution time.
|
||||
|
||||
Other optimizations include: improved validation and proposal routing, which benefit operators of single servers and large clusters alike, and validator manifests, which are now propagated widely and more efficiently over the peer network—giving greater visibility into the overall ecosystem of operators.
|
||||
|
||||
Also being introduced today is **forward ledger replay**—a pivotal improvement to XRPL that enhances security and reduces the amount of bandwidth needed by allowing servers to more easily retain synchronization with the rest of the network. This is an experimental feature that can be enabled via options.
|
||||
|
||||
Proposed and agreed upon by XRPL server operators, the features in this latest release of the code demonstrates a shared commitment to improving the XRP Ledger’s performance, innovation and decentralization.
|
||||
|
||||
|
||||
## Looking Ahead
|
||||
|
||||
Today’s release is another step in the continuous evolution of the XRPL. Feature updates, such as those being introduced today, are reviewed and voted on by the XRPL’s network operators and help improve its capabilities.
|
||||
|
||||
[The XRP Ledger Foundation](https://xrplf.org/)—whose goal is to accelerate the development and adoption of XRPL by engaging developers—will also play an active role in maintaining XRPL’s infrastructure and default [Unique Node List (UNL)](https://xrpl.org/faq.html#validators-and-unique-node-lists) in the future.
|
||||
|
||||
“Enhancements, such as today’s improvements to memory usage, are key to growth and innovation on the Ledger,” says Bharath Chari of the XRP Ledger Foundation. “We look forward to supporting the wider ecosystem, including the superb code development by the RippleX team. Testament to this will be our focus on producing an evolving list of validators and enhancing the core code and infrastructure behind the XRP Ledger."
|
||||
|
||||
RippleX is one contributor to this growing XRPL community. As such, we look forward to continuing our commitment to developing best-in-class functionalities, tools and open protocols that help developers to build trust and utility on the XRP Ledger.
|
||||
|
||||
For details on feature updates in XRPL 1.7.0, visit XRPL.org(https://xrpl.org/) .
|
||||
28
content/blog/2021/sidechain-engineering-preview.md
Normal file
28
content/blog/2021/sidechain-engineering-preview.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-09-30
|
||||
labels:
|
||||
- Development
|
||||
---
|
||||
# RippleX Releases Engineering Preview of Proposed Federated Sidechains System
|
||||
|
||||
Earlier this year, Ripple [shared](https://ripple.com/insights/a-vision-for-federated-sidechains-xrp-ledger/) a vision for Federated Sidechains that can complement the XRP Ledger (XRPL) Mainnet. Federated Sidechains support the developer community by unlocking new capabilities related to smart contracts and DeFi, interoperability, NFTs and more.
|
||||
|
||||
Today, an engineering preview of Federated Sidechains that can be used with the XRPL is available for developers to experiment with. Developers are welcome to view and comment on the [technical design](https://github.com/ripple/rippled/blob/sidechain/docs/sidechain/design.md), as well as leverage this technology to [start](https://github.com/ripple/rippled/blob/sidechain/docs/sidechain/GettingStarted.md) exploring its potential.
|
||||
|
||||
At a high level, each sidechain acts as its own blockchain, while federation enables value in the form of XRP and other tokens to move efficiently from the sidechain to the Mainnet. Federated Sidechains operate without compromising the impressive speed, efficiency, and throughput of the public XRPL Mainnet.
|
||||
|
||||
Federated Sidechains create exciting new opportunities for developers. They expand the scope for developers to customize the core, proven XRPL technology to the needs of a specific use case or project. Examples of the kinds of customization enabled include:
|
||||
|
||||
* Innovative design characteristics that can be tuned to specific use cases like tokenization, DeFi, or payments
|
||||
* Flexibility to make permissioned or nearly permissionless, centralized or largely decentralized ledgers whose assets can be traded on the Mainnet DEX
|
||||
* Choice in validators and flexibility of system rules (e.g. optional transaction fees and reserve requirements)
|
||||
* Opportunity to temporarily manage a sidechain and shut it down after it has served its purpose
|
||||
|
||||
Note that successful new sidechain features may even eventually be ported to the XRPL Mainnet.
|
||||
|
||||
Federated Sidechains give developers an opportunity to launch new features and innovative applications built on foundational XRP Ledger technology, like a smart sidechain with [Hooks](https://hooks-testnet.xrpl-labs.com/) enabled. Developers can also create private or public sidechains, with public sidechains available for the community to leverage for various use cases.
|
||||
|
||||
Ripple itself will be looking to leverage the flexibility and customizability that Federated Sidechains afford in its own [CBDC efforts](https://ripple.com/insights/ripple-pilots-a-private-ledger-for-central-banks-launching-cbdcs/), making it possible for private CBDC ledgers to easily and seamlessly interconnect.
|
||||
|
||||
Interested developers are encouraged to [apply](https://xrplgrants.org/) to the XRPL Grants Program with your ideas on implementing and launching sidechains for creative use cases and applications.
|
||||
60
content/blog/2021/three-amendments-expected.md
Normal file
60
content/blog/2021/three-amendments-expected.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-03-30
|
||||
labels:
|
||||
- Amendments
|
||||
---
|
||||
# Three Amendments Expected on 2021-04-08
|
||||
|
||||
Two bug-fixing amendments to the XRP Ledger protocol and one amendment that improves robustness of consensus, all introduced in [`rippled` v1.6.0](https://github.com/ripple/rippled/releases/tag/1.6.0), have gained support from a majority of trusted validators: [fix1781](https://livenet.xrpl.org/transactions/777AF3E5F557972734AE43C71E092782DDEC6F730A729BE3A74C2007F4EACC55), [fixAmendmentMajorityCalc](https://livenet.xrpl.org/transactions/29D7B3317C5662086791A0C21FB0FB9261DC7A6537D8E4117D925029EEF57BB3), and [HardenedValidations](https://livenet.xrpl.org/transactions/DCB78BB19FD379918A52F68C4B4BA98C5A8F98A15153876AC3458B4613A7CB9E). Currently, they are expected to become enabled on 2021-04-08. Any of these amendments that continue to have the continuous support of at least 80% of trusted validators will become enabled on the scheduled date.
|
||||
|
||||
Server operators should be sure to upgrade `rippled` before this date.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## Action Required
|
||||
|
||||
- If you operate a `rippled` server, you must upgrade to version 1.6.0 or higher by 2021-04-08, for service continuity. [Version 1.7.0](https://xrpl.org/blog/2021/rippled-1.7.0.html) is recommended.
|
||||
|
||||
- If you have code that submits XRP Ledger payments, make sure your code correctly handles the [`temBAD_PATH_LOOP` error code](https://xrpl.org/tem-codes.html). As a `tem` code, this error only occurs on transaction submission and does not appear in validated ledger data.
|
||||
|
||||
## Impact of Not Upgrading
|
||||
|
||||
If you operate a `rippled` server but don’t upgrade to version 1.6.0 (or higher) by 2021-04-08, when the amendments are expected to become enabled, then your server will become amendment blocked, meaning that your server:
|
||||
|
||||
* Cannot determine the validity of a ledger
|
||||
* Cannot submit or process transactions
|
||||
* Does not participate in the consensus process
|
||||
* Does not vote on future amendments
|
||||
* Could rely on potentially invalid data
|
||||
|
||||
If none of the amendments becomes enabled, then your server will not become amendment blocked and should continue to operate.
|
||||
|
||||
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
|
||||
|
||||
|
||||
## fix1781 Summary
|
||||
|
||||
Fixes a bug where certain XRP endpoints were not checked when detecting circular paths.
|
||||
|
||||
Without this amendment, it is possible to have a [payment path](https://xrpl.org/paths.html) where the input to the path is XRP, and an intermediate path step also outputs XRP. This is a "loop" payment, and the payment engine typically disallows such paths because they can have different results when executed forward compared to backwards.
|
||||
|
||||
With this amendment, those payments fail with the [`temBAD_PATH_LOOP` result code](https://xrpl.org/tem-codes.html) instead.
|
||||
|
||||
## fixAmendmentMajorityCalc Summary
|
||||
|
||||
Fixes a bug that could cause an amendment to achieve a majority and later activate with support of slightly less than 80% of trusted validators due to rounding semantics.
|
||||
|
||||
Without this amendment, the minimum threshold for amendment activation is any value that rounds to 204/256 of trusted validators, which depends on the number of trusted validators at the time. For example, an amendment could activate with exactly 28 out of 36 validators (approximately 77.8%). With this amendment, the actual minimum number of validators needed is never less than 80% of trusted validators.
|
||||
|
||||
## HardenedValidations Summary
|
||||
|
||||
Allows validators to include a new optional field in their validations to attest to the hash of
|
||||
the latest ledger that the validator considers to be fully validated. The consensus process can use this information to increase the robustness of consensus.
|
||||
|
||||
|
||||
## Learn, ask questions, and discuss
|
||||
|
||||
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
|
||||
|
||||
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-06-05
|
||||
labels:
|
||||
- Features
|
||||
---
|
||||
# XRPL Grants: Funding the Next Phase of Open, Decentralized Innovation
|
||||
|
||||
XRPL Grants is helping enable developers to leverage the XRP Ledger’s (XRPL) open-source technology to further innovate in the Internet of Value. If you’re a developer and would like to build a project on the XRPL, keep reading to find out more info and how to apply.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
## A Community-Centric Initiative
|
||||
|
||||
As interest in crypto continues to skyrocket, 2021 has presented new opportunities for entrepreneurs and developers to build exciting, real-world use cases. As this blockchain ecosystem grows, more and more projects are being built on the XRP Ledger—a scalable, sustainable and reliable public blockchain rife with opportunities for innovation.
|
||||
|
||||
On the heels of this growing spotlight on crypto innovation, the new [XRP Ledger Grants Program](https://xrplgrants.org/) aims to support the independent, open-source development ecosystem around the XRPL.
|
||||
|
||||
Here are just a few examples of the exciting work being built on the XRP Ledger today:
|
||||
|
||||
|
||||
* [Travala](https://www.travala.com/) is a blockchain-based travel booking platform used by thousands of customers worldwide and accepts cryptocurrencies as payment
|
||||
* [Uphold](https://uphold.com/en/debit-card) offers a debit card that enables consumers to pay in cryptocurrencies and fiat.
|
||||
* [Forte](https://www.forte.io/) provides tools for game developers to integrate blockchain technology and crypto into new and existing games.
|
||||
* [Audiotarky](https://www.audiotarky.com/) is a streaming platform where artists and labels are paid directly using crypto for downloads.
|
||||
* [Wirex](https://wirexapp.com/en/card) offers a travel card for customers to exchange and spend cryptocurrencies.
|
||||
* [Puma Browser](https://www.pumabrowser.com/) is a private, mobile Web3 browser that makes it easy to support micropayments and pay creators using cryptocurrencies.
|
||||
* [XRPLORER](https://xrplorer.com/) offers services and tools that help prevent and combat fraudulent activity on the XRPL as well as custom APIs and analytics that supplement the XRPL APIs.
|
||||
* [Coil](https://coil.com/) provides web monetization as an alternative to traditional paid advertising. It uses the Interledger Protocol (ILP) to stream micropayments as users consume content. The XRP Ledger's payment channels provide an ideal system for settling these micropayments at high speed and low cost.
|
||||
* [XRPL Labs](https://xrpl-labs.com/) is dedicated to building software on the XRP Ledger, from cold storage to apps for signing transactions.
|
||||
|
||||
## About the Program
|
||||
|
||||
XRPL Grants funds both select core technology and end-user applications including, but not limited to:
|
||||
|
||||
|
||||
* Non-Fungible Tokens (NFTs)
|
||||
* Core infrastructure
|
||||
* Developer tooling
|
||||
* Developer UX
|
||||
* Security
|
||||
* Software
|
||||
* Hardware
|
||||
* Firmware
|
||||
* Design projects
|
||||
|
||||
The first round of applications is currently open until June 9 and will consider any project that builds on the XRP Ledger, involves some technical development and has an open-source component.
|
||||
|
||||
The review panel is composed of [committee members](https://xrplgrants.org/about) Ali Mohammadloo from XRPL Labs, Matt Hamilton and Elliot Lee from RippleX.
|
||||
|
||||
The focus area for the first round relates to the development of NFTs on the XRP Ledger such as:
|
||||
|
||||
* An XRPL-based NFT Marketplace
|
||||
* An XRPL-based NFT Issuance platform (minting)
|
||||
* Wallet support for XRPL-based NFTs
|
||||
* Tools and services for XRPL-based NFTs
|
||||
|
||||
## Why NFTs?
|
||||
|
||||
The XRP Ledger is ideally suited to deliver a superior user experience for NFTs and tokenization more broadly. When combined with a robust suite of tools and resources, the innate performance advantages of the XRPL and its native digital asset [XRP](https://xrpl.org/xrp-overview.html) enable developers a seamless experience for NFTs, without the environmental implications inherent in other blockchains.
|
||||
|
||||
The developer community around the XRP Ledger is already hard at work proposing features and providing tools and documentation to make XRPL the go-to chain for NFTs. XRPL Labs(https://xrpl-labs.com/), for example, proposed a [standard](https://github.com/XRPLF/XRPL-Standards/discussions/30) for using existing functionality to issue NFTs on the XRP Ledger and started working on an embedded xApp in XRP wallet XUMM for minting NFTs on the XRPL.
|
||||
|
||||
Inspired by XRPL Labs’ standard, the RippleX team also [proposed](https://github.com/XRPLF/XRPL-Standards/discussions/46) additional functionality that would provide enhanced NFT support on the XRP Ledger.
|
||||
|
||||
## The Application and Selection Process
|
||||
|
||||
Step 1: Create an initial prototype and submit your application
|
||||
|
||||
Step 2: Finalists are chosen for interviews
|
||||
|
||||
Step 3: Accepted projects are notified
|
||||
|
||||
Step 4: Grantees receive funding and are matched with mentors
|
||||
|
||||
Step 5: After 3-4 months, final interviews are conducted
|
||||
|
||||
## About The XRP Ledger
|
||||
|
||||
The XRP Ledger is open-source and permissionless, delivering powerful utility to developers on a public blockchain. Its built-in decentralized exchange (DEX)(https://xrpl.org/decentralized-exchange.html#main-page-header) and custom token functionality—[Issued Currencies](https://xrpl.org/issued-currencies-overview.html)—supports the seamless exchange of tokens, with more than 5,400 currencies issued and traded on the XRP Ledger to date.
|
||||
|
||||
Additionally, the XRP Ledger is the first major [carbon-neutral blockchain](https://xrpl.org/impact.html) and inherently energy efficient, alleviating high costs that developers experience when building on proof-of-work blockchains. Development and forward progress of the XRPL is maintained by the growing developer community around XRP for which RippleX is just one participant.
|
||||
|
||||
## Get Started Today
|
||||
|
||||
This new initiative is an incredible opportunity to grow that community to new heights.
|
||||
|
||||
Ready to get started? [Apply for a grant](https://xrplgrants.org/) before the first round closes on June 9.
|
||||
170
content/blog/2021/xrpl-node-configurator.md
Normal file
170
content/blog/2021/xrpl-node-configurator.md
Normal file
@@ -0,0 +1,170 @@
|
||||
---
|
||||
category: 2021
|
||||
date: 2021-04-14
|
||||
labels:
|
||||
- Development
|
||||
---
|
||||
# XRP Ledger Node Configurator
|
||||
_by Javier Romero of Ripple_
|
||||
|
||||
The XRP Ledger is open to anyone: all you need is a computer. For many people, using one of the many available client applications, user interfaces or portals is sufficient. But if you want to go beyond [exploring the ledger](https://livenet.xrpl.org/) or sending a payment, you need to run a server to participate as a node in the peer-to-peer network that manages the Ledger.
|
||||
|
||||
While the [docs](https://xrpl.org/manage-the-rippled-server.html) on xrpl.org make it fairly easy for anyone to spin up an XRP Ledger node, some nuanced configuration options can complicate the setup process. To help simplify this process, we've built the [XRPL Node Configurator](https://xrplf.github.io/xrpl-node-configurator/#/), a tool that walks you through setting up a node based on your use case.
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
Before you set up an XRPL node, you need to know why you're setting up a server. Not everyone has the exact same needs. You might want to [set up rippled on your Mac](https://xrpl.org/build-run-rippled-macos.html) or [on your server](https://xrpl.org/build-run-rippled-ubuntu.html) to play around and familiarize yourself with the software, you may only need the server to run RPC commands or APIs locally or to test your application code, or you might want to help the network by [running a Validator](https://xrpl.org/run-rippled-as-a-validator.html).
|
||||
|
||||
Here are some questions you need to answer when configuring a node:
|
||||
|
||||
* Do you need full transaction history, none, or just some of it?
|
||||
* What ports and protocols do you need?
|
||||
* What database do you want to use?
|
||||
* What Node Size should you choose?
|
||||
* Are you following best practices for your use case? For example, if you're running a validator, you should not reveal your IP address or allow public WebSocket connections.
|
||||
* Are you running your node on Mainnet, Testnet, or just for your testing?
|
||||
|
||||
Choosing suitable configuration settings means you can meet your requirements. But each decision also has potential tradeoffs that could impact performance and security.
|
||||
|
||||
|
||||
## XRP Ledger Node Configurator to the Rescue
|
||||
|
||||
The XRP Ledger Node Configurator is a tool that, through a set of steps, will guide you to produce the required files to run a node.
|
||||
|
||||
While this tool doesn’t aim to cover all the possible configuration decisions you could be making, it helps to configure your node quickly and follow best practices.
|
||||
|
||||
It also provides contextual information about each decision and links to the official docs in some cases, as well as provides recommendations based on your decisions.
|
||||
|
||||
For example:
|
||||
|
||||
* If you are going to run a Validator server: you should probably use RocksDB, do not broadcast your address, and should not store more than about 300,000 ledgers (approximately two weeks' worth of historical data) in the ledger store.
|
||||
* If you want to run on Mainnet, you should probably choose a `Huge` node size.
|
||||
|
||||
|
||||
## Server Decisions
|
||||
|
||||
It’s essential to understand what the primary purpose of your node is and to choose configuration settings accordingly. Let’s review the use cases for the following server decisions below:
|
||||
|
||||
|
||||
### Dedicated Validator
|
||||
|
||||
You want to help keep the XRP Ledger network online and humming along smoothly. You might have different machines you use for other purposes, or you might actually send or receive XRPL transactions sparingly enough that you don’t run a machine for that purpose.
|
||||
|
||||
Maybe you don’t even use the XRPL much directly, but you’re associated with another entity that does. For example, a charity organization might run a validator while governments and companies it assists use the XRPL for transactions.
|
||||
|
||||
Most likely, you run this as a private peer even though it might be clustered with several other servers you also operate, such as a hub server and API servers.
|
||||
|
||||
|
||||
### All-Purpose Server
|
||||
|
||||
You are using the XRPL, but you’re a small enough entity that you don’t want to maintain a whole farm of servers for all the things you do, so you have one high-quality server that does a little bit of everything you need.
|
||||
|
||||
This machine acts as a validator, provides admin APIs to authorized users to send and monitor for transactions as they arrive, keeps a moderate amount of ledger history to facilitate day-to-day use, and maybe even signs transactions that you send.
|
||||
|
||||
|
||||
### Dedicated API Server
|
||||
|
||||
You use the XRP Ledger APIs extensively for your work, so you have one or even multiple machines dedicated to this purpose.
|
||||
|
||||
Maybe you’re tracking analytics, sending transactions at high volume, or providing a public server as a means of increasing your social capital. If you’re a medium-sized business, you might run one of these as a hot backup to your all-purpose server so that critical business functions can continue through a hardware failure or a partial outage.
|
||||
|
||||
This machine stores a moderate to high amount of history but has little to no unique persistent settings so additional exact clones can be spun up and down on short notice or even automatically. It doesn’t run as a validator because each validator must be unique and these servers are meant to be numerous and interchangeable.
|
||||
|
||||
It may or may not serve a public API to the open internet, and if you run several servers, they may be clustered with one another.
|
||||
|
||||
|
||||
### Full History Server
|
||||
|
||||
You need to have all the history since the genesis block because you will be making use of that data. This server maintains special hardware specs that make it capable of storing the entire history of the XRP Ledger.
|
||||
|
||||
This also means it’s not cheap and replacements cannot be easily brought online because [full history](https://xrpl.org/ledger-history.html#full-history) is too large to quickly acquire/copy into a new instance.
|
||||
|
||||
|
||||
### Hub Server
|
||||
|
||||
You want to contribute to the overall success of the XRP Ledger and you happen to have the resources to do that by improving the connectivity within the network. Your hub server has the resources, especially network bandwidth, to connect to many peers at the same time.
|
||||
|
||||
This server does not do much other than relay messages throughout the network and follow along with consensus, but some servers specialized for this role are very helpful to the overall health of the network.
|
||||
|
||||
Hub servers that are especially reliable may be hard-coded into the rippled source code as connection points where new servers can go to bootstrap their connectivity with the rest of the network.
|
||||
|
||||
|
||||
### Development Machine
|
||||
|
||||
You are experimenting with XRP Ledger software, either developing rippled itself or some kind of integration or app on top of it. You don’t need your server to have production-quality stability and you are likely to start it up or shut it down frequently.
|
||||
|
||||
Retaining some history is nice so that you can look up transactions you sent or received a little while ago, but you don’t need to keep a large amount of history, and it’s not that bad if you wipe it and start from scratch. You might hop around between different network chains (e.g. Devnet, Testnet, etc.) or run experimental code.
|
||||
|
||||
You need an admin API, and you might experiment with any other features of the code, but you likely don’t have a cluster. It’s likely you may want to run with a higher level of logging than any other use case.
|
||||
|
||||
|
||||
## Other Server Settings
|
||||
|
||||
In this step, you will also decide what protocols (Peer, WebSockets, JSON-RPC, gRPC…) you need to run, on which ports, and what kind of access they will allow.
|
||||
|
||||
|
||||
### Protocol Settings
|
||||
|
||||
You know so far what your server is for and how you want to configure it but here you will make decisions at the protocol level:
|
||||
|
||||
* What Node size you want/need to run?
|
||||
* How much ledger history you need?
|
||||
* What Network do you want to run it on?
|
||||
* What Validators do you want to trust?
|
||||
|
||||
|
||||
### Storage
|
||||
|
||||
Choosing storage settings wisely is important to avoid future problems. Depending on what you run your server on, you might use RocksDB or NuDB, and you might need an SSD unit.
|
||||
|
||||
Another important decision to make is how much data do we want to purge automatically (or manually) if any.
|
||||
|
||||
|
||||
### SSL
|
||||
|
||||
When running an XRP Ledger node, our server will be making client connections as well as receiving connections as a server. SSL settings are important to make sure we support secure outgoing and incoming connections.
|
||||
|
||||
|
||||
### Other Settings
|
||||
|
||||
The tool also allows you to configure other settings like:
|
||||
|
||||
* Broadcasting your address
|
||||
* Providing signing support
|
||||
* Determining the level of logs you want to have
|
||||
* Configuring the outgoing and incoming connections number
|
||||
|
||||
|
||||
## Output
|
||||
|
||||
Once you are ready to go, click on ‘Generate’, and the tool will produce a zip file with all the files needed to run our server, and in cases where further configuration is required (like keys generation), instructions will be provided on how to do it:
|
||||
|
||||
|
||||
### Configuration Files
|
||||
|
||||
`rippled.cfg`: main configuration file for your XRP node.
|
||||
|
||||
`validators.txt`: Validators configuration.
|
||||
|
||||
|
||||
### Other files
|
||||
|
||||
`instructions.txt`: Follow up instructions to finish your node configuration.
|
||||
|
||||
`cfg.json`: JSON Export of the configuration. This is useful if later on, you want to load it in the tool to make amendments.
|
||||
|
||||
|
||||
## It’s Open Source and Multi-language
|
||||
|
||||
The tool is built using [Vue.js](https://vuejs.org) and [Tailwind CSS](https://tailwindcss.com), it is Open Source and multi-language with initial support for English and Spanish.
|
||||
|
||||
It supports being run locally or from a web server.
|
||||
|
||||
Although it is the very first version, we encourage the community to participate and work on fixing bugs, adding new features, languages...
|
||||
|
||||
|
||||
## Use It Today
|
||||
|
||||
Repo: <https://github.com/XRPLF/xrpl-node-configurator>
|
||||
|
||||
Github Pages: <https://xrplf.github.io/xrpl-node-configurator>
|
||||
Reference in New Issue
Block a user