DEV Community: Elliot Lee

Empowering Developers: rippled 2.0 Presents Exciting Upgrades

Elliot Lee — Wed, 10 Jan 2024 20:08:00 +0000

The XRP Ledger developers are pleased to announce the release of rippled 2.0. This update introduces two new feature amendments: XLS-38 Cross-Chain Bridge and XLS-40 Decentralized Identity. Additionally, there are two fix amendments, as well as numerous other improvements.

Why is this being released now?

With the holiday season behind us and an exciting year ahead, validator and node operators have more time to learn about the 2.0 release and new amendments as they update their software and reconsider votes.

New Feature Amendments

XLS-38 Cross-Chain Bridge

The Cross-Chain Bridge would enable XRP and fungible tokens issued on the XRPL to move efficiently between XRPL Mainnet and XRPL Sidechains, as well as XRPL Mainnet and the upcoming EVM sidechain.
The Cross-Chain Bridge is secured by independent witness servers that attest to any transactions moving between chains.
Learn more technical details in the XLS-38 spec on GitHub.

XLS-40 Decentralized Identity

Decentralized Identity (DID) is a technology that enables users to control their online identity in a self-sovereign way. The XLS-40 DID implementation will use the World Wide Web Consortium (W3C) standard to enable verifiable, self-sovereign digital identity and will be compatible with any distributed ledger or network.
DID on the XRPL satisfies the following principles: Decentralized, Persistent and Portable, Cryptographically Verifiable, Universally Resolvable and Interoperable.
XLS-40 is a lightweight amendment and adds a new ledger object. Associated transactions can create, update, and delete this object.
Learn more about XLS-40 in the official documentation and spec on GitHub.

API Updates

Introduces API v2.
Cleans up the API with the removal of deprecated fields and methods, renaming fields which were frequently misinterpreted, and improving consistency in responses.
The new server_definitions command returns SDK-compatible binary format definitions, making it easier for client libraries to adopt support for the latest features over time.

Core Ledger Updates

fixDisallowIncomingV1: Fixes an issue that occurs with authorized trustlines and the “lsfDisallowIncomingTrustline” flag.
fixFillOrKill - Fixes an issue that occurs with a combination of flags under circumstances where an exchange rate on an offer differs from the orderbook rate.

The XRPL Amendment Voting Process

To bring new features to the XRPL Mainnet, XLS specs that involve breaking changes to the core protocol must undergo the amendment process, in which the validator community votes on the feature.
In blockchain protocols, a breaking change occurs when structures that were invalid under the old rules become valid under the new rules. For example, XLS-38 introduces new transactors and ledger objects. After the amendment activates, transactions and ledger objects that were previously invalid will now be valid. All nodes must update their software in order to work together after the change.
Every server on the network independently tallies the votes of the validators it is configured to listen to, as part of the consensus process.
For an amendment to pass:
- At least 80% of validators must approve the amendment by setting their vote to “yes” or "accept".
- This threshold must be maintained for at least 2 weeks.
If both conditions are met, the amendment will activate and the feature defined in the XLS spec will become live on Mainnet. This process happens independently for each amendment.
All members of the validator community are encouraged to review the code and documentation to make an informed decision.

Casting a Ballot

To vote in favor of a particular amendment, the command to execute is:

/opt/ripple/bin/rippled feature NAME accept

To vote against a particular amendment, the command to execute is:

/opt/ripple/bin/rippled feature NAME reject

Replace /opt/ripple/bin/ with the path to your rippled binary, and NAME with the name of the amendment.

The names of the amendments introduced in 2.0.0 are DID, XChainBridge, fixDisallowIncomingV1, and fixFillOrKill.

Analysis of the XRPL Amendments Introduced in March 2023

Elliot Lee — Fri, 26 May 2023 21:49:43 +0000

Decentralized blockchains such as the XRP Ledger (XRPL) rely on the collective decision-making of their participants in order to coordinate changes to the protocol. Amendments are the primary mechanism for initiating changes to the XRPL, which track changes to transaction processing. This includes new features, enhancements to existing functionality, and bug fixes. Validator operators vote on these amendments. If more than 80% of support is maintained for two consecutive weeks, the amendment activates, enabling the associated behavior.

The XRP Ledger software (rippled) generally defaults to voting against new amendments in order to reduce the odds that older servers become "amendment blocked" (context). It’s expected that some amendments may default to “yes" in a future release of the software—after the code to understand them has been included in a stable rippled release for some time. For example, an important fix might be given a default "yes" vote. In most cases, bug fix amendments are expected to move from default "no" to default "yes" after being in stable release for about two release cycles.

Overview of Amendment Blocking

Amendment blocking is a safety feature that protects the XRPL. When an amendment is enabled, servers running earlier versions of the rippled software are designed to detect that they don’t have the source code required to understand the amendment. Therefore, they can’t reliably process transactions correctly, according to the current protocol rules. Instead of potentially misinterpreting transactions or ledgers, these servers automatically become amendment blocked, effectively ceasing to function. They don’t submit or process transactions, and they don’t participate in consensus.

The voting configuration of a server doesn’t influence whether or not it becomes amendment blocked. Servers always follow the amendments enabled by the rest of the network, and amendment blocking occurs solely based on the absence of the code required to understand the rule changes.Connecting your server to a parallel network with different amendments enabled can also lead to amendment blocking. For example, the RippleX-operated Devnet test network often has experimental amendments enabled. Even if you are running the latest production release, your server may not have the code for those experimental amendments. When relevant, details about experimental amendments on Devnet will be posted to the XRP Ledger Blog.

To unblock an amendment blocked server, update to a newer version of the rippled software. On the Mainnet production network, the latest stable version always understands the enabled amendments on the network.

How Ripple Votes

Validator operators should independently assess the impact of amendments and exercise judgment to make informed voting decisions. A balanced approach considers the network's stability, robustness, and usefulness. Ripple takes this approach and recommends it to other stakeholders. It is beneficial for the network's overall robustness and security to minimize the number of amendment blocked nodes. Additionally, updating the software is a burden and should not be taken lightly. Every update brings both improvements and risks, as new bugs could be introduced and unexpected emergent behavior could occur.

Participants take time to review release notes and code changes, and nodes on the network tend to be updated to newer versions of rippled over time. There is a diverse community of independent node operators, and not all of them apply updates on a frequent basis. It makes sense to offer a reasonable amount of time between the introduction of an amendment and its activation to allow the network as a whole to upgrade and mitigate nodes becoming amendment blocked. This is why Ripple has intentionally chosen not to vote in favor of a new amendment until some time has passed since its introduction in a stable release.

Ripple does not control the XRP Ledger Mainnet and runs only 1 of the 30+ validators on the most commonly-used UNL. At the protocol level, Ripple's amendment votes have the same amount of influence as the votes of any other validator. Each node operator chooses the UNL they wish to use, which may include configuring their own UNL.

As always, we encourage ongoing engagement and dialogue. You can reach the software maintainers by opening an issue on GitHub.

In this post, we provide an analysis of the six amendments that were introduced in rippled version 1.10, released in March 2023. Each amendment brings its own set of changes and implications.

featureImmediateOfferKilled

featureImmediateOfferKilled changes the response code of an OfferCreate transaction with the tfImmediateOrCancel flag, changing it from tecSUCCESS to tecKILLED when no funds are moved. (Full details)

This change improves the clarity of the transaction status by providing a more intuitive result code. The tradeoff is that applications and services that rely on the previous response code may need to be updated. In our assessment, the improved clarity outweighs the potential need for minor adjustments in applications. Ripple has voted in favor of the featureImmediateOfferKilled amendment.

featureDisallowIncoming

featureDisallowIncoming allows an account to block incoming checks, payment channels, NFToken offers, and trust lines. (Full details)

This feature provides users with increased control by allowing accounts to block incoming transactions. For users who do not wish to use certain features, disallowing them is a good way to improve the user experience by preventing spam. It may also help to reduce ledger bloat, as users can block certain unwanted ledger objects from being created. On the other hand, users who have blocked certain ledger objects will not have access to use cases that depend on those objects. In our assessment, the added control outweighs the potential limitations on certain use cases. Ripple has voted in favor of the featureDisallowIncoming amendment.

featureXRPFees

This amendment simplifies transaction cost calculations by using XRP directly, instead of calculating indirectly in "fee units". All instances of "fee units" are updated in the protocol and ledger data to be drops of XRP. (Full details)

This refactor streamlines transaction cost calculations and simplifies fee-related calculations. On the other hand, it may require adjustments in applications that rely on the previous fee unit calculations. In our assessment, the streamlined calculations and improved maintainability of the implementation outweighs the potential need for adjustments in applications. Furthermore, we are not aware of any specific applications that will need to be updated. Ripple has voted in favor of the featureXRPFees amendment.

fixUniversalNumber

This amendment simplifies and unifies the code for decimal floating-point math, resulting in slightly improved accuracy. (Full details)

This refactor provides slightly better accuracy in decimal floating-point math calculations. However, it may cause edge case discrepancies in places where precise calculations are used, such as ranking of offers, or processing of payments that use several different paths. In our assessment, the improved maintainability of the code justifies the potential edge case discrepancies. Ripple has voted in favor of the fixUniversalNumber amendment.

fixNonFungibleTokensV1_2

This amendment includes multiple fixes related to NFTokens. It allows NFTs with more than 500 offers to be burned (#4346). It fixes a few NFToken offer acceptance issues (#4380). It prevents brokered sales of NFTokens to owners (#4403). And for NFT offers that have a destination set, only that destination will be able to settle through brokerage (#4399). (Full details)

While these fixes are not extremely urgent, they are important quality-of-life improvements for NFToken users, marketplaces, and businesses. They enhance the overall reliability and usability of NFToken features. Ripple has voted in favor of the fixNonFungibleTokensV1_2 amendment.

fixTrustLinesToSelf

This amendment removes two trust lines that are not between two different accounts. Although trust lines must be between two different accounts, the two trust lines removed by this amendment exist due to a previous bug. (Full details)

Removing the two trust lines is not expected to have any meaningful impact on the ledger. Ripple has voted in favor of the fixTrustLinesToSelf amendment.

Conclusion

After carefully evaluating the pros and cons of each amendment, we provide our decisions as outlined above. We encourage active participation and evaluation by every validator operator in making decisions on how, and when, to vote on each amendment.

As in the past, this post intends to shed light on Ripple’s voting decisions. We believe that the amendment process is important and plays a crucial role in guiding the XRP Ledger’s continued evolution. Because of that, validator operators should be active and engaged participants in the amendment process. Please evaluate proposed amendments using criteria that you believe to be important.

Casting a Ballot

To vote in favor of a particular amendment, the command to execute is:

/opt/ripple/bin/rippled feature NAME accept

To vote against a particular amendment, the command to execute is:

/opt/ripple/bin/rippled feature NAME reject

Replace /opt/ripple/bin/ with the path to your rippled binary, and NAME with the name of the amendment.

Note: This post has been syndicated to the Ripple Engineering blog

Help Build the Future of the XRPL with Bounties

Elliot Lee — Fri, 02 Sep 2022 20:11:05 +0000

Introducing XRPL Bounties—a new program that awards software developers for completing specific ideas and projects that benefit the XRP Ledger (XRPL) community and advance the Internet of Value.

Unlike the XRPL Grants program, which funds developers to build out their existing project or app idea, Bounties start with an idea and award developers who fulfill the specific requirements needed to bring those ideas to life. Doing so directly supports and encourages the growing XRPL dev community to contribute new use cases and capabilities for the XRPL.

Building on the XRP Ledger

Bounties pave the path to success for qualified software developers who want to build something useful for the community, but aren’t quite sure what.

With XRPL Bounties, developers can choose their next project and bring it to life by learning through building. These ideas can come from anyone—in the XRPL community or beyond—and receive input from XRPL experts and engineers before developers are approved and funded to execute them. Use cases include gaming, e-commerce, real estate and more—the possibilities are limitless!

FAQ

What are Bounties?
Bounties are awards for developing software, tools or integrations that enable and improve specific use cases for the XRP Ledger.

Unlike Ripple’s Bug Bounty program, which encourages hackers to responsibly report infosec issues instead of exploiting them, XRPL Bounties are defined in advance with specific acceptance criteria.

Who can apply?
XRPL Bounties is open to any software developer or team from most places worldwide. While experience building on the XRP Ledger is great, you do not need explicit XRPL experience to build a bounty.

However, applicants should be over 18 and have coding experience and specialized skills (depending on the bounty).

How are XRPL Bounties funded?
Based on the project value and priority, software developers will be awarded anywhere from $500 - $100,000 USD per milestone completed.

How do Bounties differ from the XRPL Grants program?
XRPL Grants awards software developers who are already working on an idea. XRPL Bounties start with the ideas (or problems) and pay developers who fulfill the requirements to complete the idea with pre-defined funding.

How can I submit my idea?
Anyone can identify and introduce an idea (or problem) by starting a discussion on GitHub. From there, technical specifications and milestones are identified and approved via a GitHub PR (pull request).

Then what?
Once the PR is live on GitHub, the XRPL Bounties team will review the proposal for value-add and technical feasibility. Each bounty needs at least three approvals on GitHub, and budget needs to be approved and set aside for completing the bounty. Bounties will then remain open for 1-6 months for developers to fulfill. Only after the work is complete can devs receive payment—it’s that simple!

What if I don't meet the above criteria? Can I still get funded?
Don’t worry if you don’t meet the criteria for XRPL Bounties; there are still many other ways to get funding for your XRPL project or idea. Simply head to the developer funding page for the latest and greatest!

Furthermore, funding is not required to build on the XRP Ledger—a free and open-source public blockchain network. Learn more about the XRP Ledger at XRPL.org.

Questions? Let us know in the comments section below or visit http://xrplbounties.org/proposals!

Announcing the XRPL Grants Wave 2 Awards

Elliot Lee — Tue, 22 Feb 2022 18:52:47 +0000

The XRPL Grants Program funds software development projects that leverage the open-source XRP Ledger. After a successful inaugural wave, XRPL Grants opened the call for applications for Wave 2 in Fall 2021. In this second wave, more than 30 teams from across five continents have been awarded nearly $4 million in total funding. Awardees also get the opportunity to receive technical mentorship from a Ripple engineer to support project integration with the XRP Ledger (XRPL).

More than 100 applications were submitted in Wave 2. Every project was carefully reviewed by the judging committee, with experts and professors from organizations including Stronghold, Australian National University, University of Nicosia, Ryerson University, Northeastern University, and TU Delft. We were impressed by the quality and creativity of the applicants and projects.

Wave 2 of the XRPL Grants program focused on Federated Sidechains. In December, RippleX introduced an engineering preview, making it possible for developers to connect a sidechain to the XRP Ledger Mainnet or a test network. Awarded projects showcase the vast use cases for sidechains, including but not limited to:

NFT minting
Charitable giving
Sports club memberships
Restaurant/retail orders
Data security

Additional awardees encompass a range of exciting applications: tackling economic inequality, ocean conservation, artistic collaboration, equitable compensation for artists, and more. There are also a few metaverse projects that allow users to play games, attend concerts, and more.

In addition to projects related to the current focus area, XRPL Grants welcomes applications for any project that builds on the XRPL and involves some technical development. The applicant pool continued to impress, with teams in more than 25 countries across a wide range of topics and areas of expertise.

🎉 Full List - XRPL Grants Awardees 🎉

Applications for Wave 3 of the XRPL Grants program will open in March 2022. All information, including the focus area for Wave 3, will be posted on XRPLGrants.org.

Share questions or comments in the thread below, and join the XRPL Developers Discord for more updates.

Update on the XRPL

Elliot Lee — Thu, 02 Dec 2021 02:13:53 +0000

By: Elliot Lee and Nik Bougalis, RippleX Engineering

Over the past several weeks, the XRP Ledger (XRPL) has experienced instability, a transient halt in consensus on November 3 and, over the last several hours, unusually high fees resulting in a large queue of transactions. The XRPL Foundation summarized many of these issues in a recent communication.

Essentially, the number of trust lines, tokens, and transactions on the network has increased dramatically (and the size of the ledger’s state has grown), so there is a corresponding need to scale to this growth that the community is now addressing.

Despite these challenges, the XRP Ledger is continuing to make forward progress because of the hard work of a number of dedicated ecosystem participants, such as the XRPL Foundation. In parallel, many in the XRPL community, including Ripple, are working to more thoroughly understand the issues and propose the best path forward.

Actions Toward a Solution

Since 2013, Ripple, along with others in the community, has contributed improvements to various components of the XRP Ledger and related technology—including on components such as rippled and xrpl.js.

The team has submitted proposed enhancements to the performance of the codebase that, after approval by the broader community, have already been adopted—including a set of changes that dramatically reduced the memory usage for servers. These fixes, which appeared in the 1.7.0 release, are already helping the network to cope with the increased load.

Prior to the recent instability, engineers were already working on several proposed changes that should help improve the scalability and performance of the XRP Ledger, but the events of the past few weeks have caused us to redouble our efforts. In the weeks ahead, our team will continue to work hard to identify performance bottlenecks and propose targeted improvements to fix issues.

Some of the things that we are going to propose include:

Making it easier to run rippled in Reporting Mode – a special mode that’s tailored to handling RPC and WebSocket client requests outside of the main rippled process and which can scale horizontally, making it possible to service more clients, more efficiently.
Working on “Project Clio,” which was presented at Apex, and is being designed to efficiently service RPC and WebSocket client requests.
Building profile-guided improvements that help eliminate lock contention, avoid resource starvation, and enhance I/O performance, all of which should make servers perform better at higher loads.
Proposing several protocol-level improvements, including changes to the binary representation of some objects like trustlines, which should result in significant additional memory savings, reduced overhead, lower bandwidth usage, faster sync times for servers, and less memory pressure for servers.

Call to Action

The XRP Ledger is an open-source, shared resource and no one party is responsible for it. Several participants in the community have already stepped up, with many going above and beyond. We at Ripple are also focusing engineering efforts on understanding and solving the issues, but as with everything on the ledger, it requires community effort and so we call on everyone in the XRPL community to contribute to the solution.

Numerous exchanges and other participants use the XRP Ledger. We also call on them to operate infrastructure in support of the network with the same care and diligence that they use in operating their other production environments.

We believe that the issues related to the rapid growth of the XRP Ledger are transient and, with the help of the broader community, will be solved, so that the Ledger will continue to get stronger as it grows.

ripple-keypairs: XRP Ledger Key Generation and Signing

Elliot Lee — Tue, 19 Oct 2021 06:24:28 +0000

This was originally posted to the RippleX blog on March 31, 2021.

Public key cryptography is one of the fundamental technologies that enables the XRP Ledger and other blockchain systems to operate.

It uses a pair of keys: a public key and a private key. Anyone can create a new account and have authority to sign transactions from that account. In order to generate these keys, you can use a software library like ripple-keypairs.

Many of the applications that integrate with the XRP Ledger depend on the stability and security of ripple-keypairs in order to create and use XRP Ledger accounts.

Each account has an address, which is derived from the account's master public key. It might also have a regular key, which is a secondary way to authorize transactions from an account.

An account can also have a signing list to allow for multi-signing, which requires a transaction to have multiple signatures before it is considered valid.

We help to maintain and enhance the libraries underpinning the XRP Ledger in order to ensure superior security, safety and ease-of-use for every app that uses XRP.

High-quality apps deserve high-quality supporting libraries, and that's why we're excited to announce that ripple-keypairs v1.0 is now available.

With this release, the ripple-keypairs library has been refactored into TypeScript, bringing it up-to-date with modern JavaScript. It also has 100% unit test coverage, ensuring that every line in the library has been thoughtfully considered and tested. Similarly, we have released a Java version of this library, which is called xrpl4j-keypairs.

Here are the library's main use cases:

Generate new XRPL accounts (wallets)
Generate a regular key to use with your account
Generate keys to use for multi-signing
Sign messages (create signatures)
Verify messages (verify signatures)
Generate a validator manifest public key

ripple-keypairs is fully open source and licensed under the ISC license, is available as an npm package and is easy to use in browser-based apps using a compiler like TypeScript, Browserify, Babel, or Parcel.

It is also an integrated component of ripple-lib (RippleAPI) and the RippleX Dev Kit, so if you're developing on the XRP Ledger, you are probably already using ripple-keypairs!

More Resources:

We continue to work with the open source XRP Community on the development of ripple-keypairs and the entire suite of XRPL libraries. We'd love to hear your feedback. You can reach out to us through GitHub issues.

Happy developing!

Other Information

Bug Bounties and Responsible Disclosures

As a responsible participant in the XRP Ledger ecosystem, Ripple is sponsoring a bug-bounty program to help encourage third-party reviews of the codebase. We urge developers and researchers to responsibly disclose any issues that they may find.

For more on Ripple’s Bug Bounty program, please visit https://ripple.com/bug-bounty/.

Announcing the First Wave of XRPL Grants

Elliot Lee — Thu, 23 Sep 2021 22:52:34 +0000

We’re excited to announce the inaugural awardees of XRPL Grants, presented by RippleX with XRPL Labs as a technical advisor. The XRPL Grants Program provides funding to independent developers building a variety of self-selected projects that leverage the XRP Ledger’s open-source technology and further accelerate the Internet of Value. The program welcomes applications from any project that builds on the XRP Ledger (XRPL) and involves some technical development.

For the first wave of the XRPL Grants Program, we invited applicants to apply with any open-source project built on the XRPL and particularly encouraged projects focused on the development of non-fungible tokens (NFTs).

In this wave, more than 100 grant proposals were submitted, and from this incredible batch of applicants, over 20 grantees have been awarded nearly $2 million in total value. Among the grantees are individual developers and teams from more than 10 countries around the world. We're also proud to award three grants to applicants from within Ripple’s University Blockchain Research Initiative.

Inaugural grantee projects tackle a wide range of problems and opportunities, including:

The development of NFTs for multiple industries (retail, art, music, sports, digital advertising and carbon capture)
Learning tools and platforms to build on and interact with the XRPL
Data visualization tools
Payment and security solutions

You can learn more about the Wave 1 grantees on the XRPL Grantees page, at XRPL-related events—including Apex: The XRPL Developer Summit—and on the RippleXDev Twitch channel.

The XRP Ledger is an open platform, and it is not necessary to apply for a grant in order to build on the XRPL. However, information regarding the application window for the next round of grants will be posted on XRPLGrants.org.

🎉 XRPL Grants - Wave 1 Awardees 🎉

Let us know if you have any questions or thoughts in the comments right here!