Over the past nine years, the XRP community has been committed to advancing innovation and moving forward the XRP Ledger (XRPL) to dramatically increase decentralization, performance, and feature set.
Among the most requested features that we have heard from the developers and contributors of the XRP Ledger are the capabilities of smart contracts resulting from the explosive growth of Decentralized Finance (DeFi). In fact, the number of DeFi developers has grown by 110% since 2019, and this number is expected to grow beyond 2021. However, at Ripple we have long advocated features that would threaten the highly efficient XRP Ledger focus on payments .
Today, we’re suggesting a strategy that offers the best of both worlds: united side chains for the XRP ledger. This will enable developers to implement new features, such as native smart contracts that interact seamlessly with XRP and the XRP Ledger, while also allowing the XRP Ledger to maintain its existing “weak and active” feature set.
Unified Sidechains allow for experimentation and customization, so developers can enjoy the power of XRPL on a sidechain that acts as its own blockchain. For example, imagine the possibility of branching out into new functionality by shrinking the features of XRPL to a specific subset of a particular use case — or even creating a private parallel network for the authorized blockchain. Unified Sidechains can make this a reality.
How it works
In order to understand the vision of unified Sidechains, it is first important to define the federation: a piece of software that communicates with at least two instances of the XRPL software. The federation program means anyone who wants to run a side chain into the XRP Ledger. On one side, the union is connected to the XRP Ledger Mainnet. On the other hand, it connects to one or more side chains. The union will be run by parties that run validators on at least one side chain.
The vision is that each side chain will act as its own blockchain. They will have their own ledger and transactions just as the XRP Ledger does. What makes them side chains is the union system that allows XRP and issued tokens to move from one chain to another.
Consolidated Sidechains can use XRP as the underlying asset. In this case, people can use the union system to transfer XRP from XRPL to the sidechain. Then, the XRP moving can be used on the side chain just as it is on the main chain. Anyone can transfer XRP from any two chains to the other.
Alternatively, the sidechain can use its own parent assets, so that people with accounts in both ledgers can transfer XRP to and from the issuer asset in the sidechain.
The consolidated assets imported into XRPL itself will be traded on XRPL’s Decentralized Integrated Exchange (DEX). The XRP that has been imported into the liquidity side chain will be used in the integrated DEX as well.
This strategy requires three things:
Create a new program, or “union”.
Making two trivial changes to the operation of the live XRP Ledger network.
Adding new features to the XRPL server software to allow it to run in a side chain. However, these features will not be enabled in XRPL itself. (The current recommendation is to fork XRPL so that new versions of the side-chain program can be released without making new versions of XRPL and to reduce the risk of damage to XRPL.)
Each side chain will have a “trust” account on the XRPL mainnet. This account can hold assets on XRPL on behalf of sidechain users. The computation will use a multi-signature key or a threshold key with the signers being the validators in the side chain. Each side-chain validation operator records a signing key that signs transactions on the XRPL; Thus, sidechain validators can collectively create transactions to manage the sidechain’s Mainnet account.
XRP Ledger Mainnet has one original asset, XRP, and an unlimited number of tokens that can represent anything else but not have the same status as XRP. It wouldn’t make sense for each sidechain to start with a whole new pool of 100 billion XRP, so instead the sidechains have two options for their parent asset: either you have a new parent of the sidechain, or you set aside some of the real XRP in order to use it on side chain. If the sidechain uses XRP as a parent asset, then the chain account on the mainnet holds the total amount of the sidechain of XRP as “collateral” for its use in the sidechain. If the sidechain generates a different parent asset, then that asset can be issued on the XRPL Mainnet by the mainnet side account.
The sidechain can hold other assets and tokens issued locally on the XRPL Mainnet; Just like with XRP, the sidechain Mainnet account holds the total amount used in the sidechain. Ownership of this asset within the sidechain can change as a result of transactions and events in the sidechain that the main XRPL network never needs to see. When an asset – XRP or otherwise – needs to move “from” the sidechain, the sidechain’s Mainnet account sends that amount of XRP to the intended recipient on the Mainnet. This could also be another sidechain, allowing assets to cross from one sidechain via the Mainnet to any other sidechain. Conversely, to send money “to” a sidechain, you must send the money to the sidechain’s Mainnet account.
The person creating a new side chain must choose a set of initial validators and ask them to negotiate the appropriate minimum or multi-signature keys. They will then create and setup the sidechain’s XRPL Mainnet account so that only the collective signature strength of sidechain validators can control that account. If the sidechain validators change, the Mainnet account must change its keys to match the new list of trusted validators. (Note: The XRP Ledger’s original multi-signature lists are limited to 8 keys or less, but Threshold Keys can support as many signers as necessary to include each of the side validators.)
With this software, anyone can choose to run a side chain to the XRP Ledger. For developers, it opens up new use cases such as native DeFi capabilities and smart contracts. Developers can also create and release blockchain features that are “baked” into this side chain; In the future, successful features can even be ported to XRPL Mainnet.
Developers who run a side chain also have the freedom to decide how their chains work. They will choose their own validators for their side chain and can change the rules of the system as they need (in collaboration with the side validators). For example, the sidechain can operate without transaction fees or reserve requirements, it can operate without its own version of the decentralized exchange XRP Ledger, or it can add new transaction types and functions to store large pieces of data in the ledger. The possibilities are limitless: strict side chain permission can be obtained, (almost) permissionless, centralized, or (mostly) decentralized. You can even run a side chain temporarily but allow it to manage the real value and safely close it after it has served its purpose.
Unified Sidechains for developers immediate benefits include:
Horizontal scaling: A side chain can have its own fee system, its own reserve system, and its own transaction capacity. Someone who wants to build a system with thousands of users who can hold XRP has a better choice than being a custodian or putting all the accounts on XRPL directly.
Low Risk: The XRP Ledger does not need to be changed at all. Even the changes that might be beneficial are minimal.
Low Effort: Anyone who needs or wants to experiment with blockchain can start with a complete system that is ready to use out of the box, based on robust, stable and sustainable XRP Ledger technology.
Long roadmap: New features can be added over a long period of time based on feedback on what people find interesting. This will be a constant stream of new features and capabilities.
Changes in the XRP Ledger
Success in this vision requires making some changes to the XRPL software that will not be used on XRPL itself in order to support sidechain features. The primary change to the software will be to support the Unique Node List (UNL) stored in the ledger. Pseudo-transactions will be needed to change the UNL. UNL ‘hint’ has to be supported to avoid the chicken and egg problem of needing UNL to get ledger and ledger to get UNL.
It is also necessary to provide support for coordinating the generation of threshold keys and/or multi-signature keys and the signature of XRPL transactions provided by the union. It is possible that some API improvements will be needed to handle spurious transactions made by federation or federated communication through peer network.
The main XRP Ledger network can also use a flag to indicate whether an issued asset is allowed to federate. Some issuers of assets, for example, may insist that all holders of their assets be directly represented on the main chain for regulatory purposes while others can allow their assets to trade freely on the side chains. (It is always possible to allocate some of your own resources to others, with or without a side chain to automate the process, but legal responsibilities for doing so can vary based on jurisdiction and circumstances.)
Sidechains will have a special entry in their ledgers that tracks the last side transaction executed on the main chain and the last main chain transaction executed on the side chain.
When challengers see a new transaction on the side chain that affects the main chain, they coordinate sending that transaction to the main chain. When challengers see a new transaction on the main chain that affects the side chain, they coordinate sending that transaction to the main chain.
Making these changes is probably the largest part of this effort because even though they are not enabled on XRPL, there are still risks associated with changing the software. For example, some existing code may need to be moved or modified which runs the risk of inadvertently changing behavior.
The strategy described is a starting point for gathering feedback from the XRP Ledger community. We invite developers and community contributors to head over to the Dev To community page to review and provide feedback. Let’s build a roadmap of innovative and new use cases together.