Today, RippleX is rolling out a community page on DEV aimed at engaging the growing XRP Ledger Community.
Our inaugural post was written by David Schwartz, CTO at Ripple and one of the original architects of the XRP Ledger, and introduces his vision for Federated Sidechains.
Developers around the world are invited to share ideas, provide feedback, ask questions and join the discussion. Together, we look forward to building trust and utility for the XRP Ledger.
Over the last nine years, the XRP community has been committed to advancing the innovation and forward progress of the XRP Ledger (XRPL) to dramatically increase its decentralization, performance, and feature set.
Among the most-requested features we have heard from developers and contributors to the XRP Ledger is smart contract capabilities brought about by the exponential growth in decentralized finance (DeFi). In fact, the number of DeFi developers has grown 110% since 2019, and that number is projected to grow well beyond 2021. However, we at Ripple have long advocated against features that would compromise the XRP Ledger's highly efficient focus on payments.
Today, we are proposing a strategy that enables the best of both worlds: Federated Sidechains for the XRP Ledger. This will enable developers to implement new features, such as native smart contracts that interoperate seamlessly with XRP and the XRP Ledger, while also allowing the XRP Ledger to maintain its existing, "lean and efficient" feature set.
Federated Sidechains allow for experimentation and specialization, so developers can enjoy the power of the XRPL on a sidechain that acts as its own blockchain. For example, imagine the potential to branch out into new functionality by slimming down the XRPL's features to a specific subset for a particular use case—or even creating a private, parallel network for a permissioned blockchain. Federated Sidechains could very well make this a reality.
How It Works
In order to understand the vision for Federated Sidechains, it is first important to define a federator: a piece of software that connects to at least two instances of the XRPL software. The federator software means anyone who wanted to could run a sidechain to the XRP Ledger. On one side, the federator is connected to XRP Ledger Mainnet. On the other side, it connects to one or more sidechains. The federator would be run only by parties who operate validators on at least one sidechain.
The vision is that each sidechain would function as its own blockchain. They’d have their own ledger and transactions just as the XRP Ledger does. What makes them sidechains is the federation system which allows XRP and issued tokens to move from one chain to another.
Federated Sidechains could use XRP as their primary asset. In that case, people could use the federation system to move XRP from XRPL to the sidechain. Then, the moved XRP could be used on the sidechain just as it is on the main chain. Anyone could move XRP from either chain to the other.
Alternatively, sidechains could use their own native asset, so people with accounts on both ledgers could move XRP to and from the issued asset on the sidechain.
Functionality:
Federated assets imported onto XRPL itself would trade on the XRPL’s integrated decentralized exchange (DEX). XRP imported onto sidechains would be used for liquidity on their integrated DEX as well.
This strategy requires three things:
- Building a new piece of software, or the “federator.”
- 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 operate in a sidechain. However, these features would not be enabled on XRPL itself. (The current recommendation is to fork the XRPL software so that new versions of the sidechain software could come out without having to make new versions of the XRPL software and to reduce the risk of harming XRPL.)
Each sidechain would have a "trust" account on the XRPL Mainnet. This account can hold assets on the XRPL on behalf of users of the sidechain. The account would use a multisign or threshold key with the signers being the validators of the sidechain. Each sidechain validator operator registers a signing key that signs transactions on XRPL; thus, the validators of the sidechain can collectively create transactions to manage the sidechain's Mainnet account.
The XRP Ledger Mainnet has one native asset, XRP, and an unlimited number of issued tokens that can represent anything else but don't have the same status as XRP. It wouldn't make sense for each sidechain to start with a whole new set of 100 billion XRP, so instead, sidechains have two options for their native asset: either have a new native asset for the sidechain, or set aside some real XRP for use on the sidechain. If the sidechain uses XRP as its native asset, then the chain’s account on the Mainnet holds the sidechain's total amount of XRP "in trust" for use in the sidechain. If the sidechain creates a different native asset, that asset can be issued on XRPL Mainnet by the sidechain's Mainnet account.
The sidechain can hold other assets and tokens issued natively on the XRPL Mainnet; just like with XRP, the sidechain's Mainnet account holds the total amount in use on the sidechain. The ownership of that asset within the sidechain can change as a result of transactions and events in the sidechain that the XRPL Mainnet never needs to see. Whenever an asset—XRP or otherwise—needs to move "out of" the sidechain, the sidechain's Mainnet account sends that amount of XRP to its intended recipient on the Mainnet. This could even be another sidechain's account, allowing assets to cross from one sidechain through the Mainnet to any other sidechain. Conversely, to send funds "into" a sidechain, you would send funds to that sidechain's Mainnet account.
Someone who establishes a new sidechain should pick a set of initial validators and have them negotiate appropriate threshold or multi-signing keys. They would then create the sidechain’s XRPL Mainnet account and set it up so that only the sidechain validators' collective signing power can control that account. If the sidechain's validators change, then the Mainnet account should change its keys to match the new list of trusted validators. (Note: The XRP Ledger's native multi-signing lists are limited to 8 keys or fewer, but threshold keys can support as many signers as necessary for each of the sidechain's validators to be included).
Advantages
With this software, anyone can choose to run a sidechain to the XRP Ledger. For developers, it unlocks new use cases like native DeFi capabilities and smart contracts. Developers can also build and launch blockchain features that are “baked” into these sidechains; in the future, successful features could even be ported to the XRPL Mainnet.
The developers managing a sidechain also have the freedom to decide how their chains work. They would choose their own validators for their sidechain and could change the system’s rules as they need (with the cooperation of their sidechain's validators). For example, a sidechain could operate without transaction fees or reserve requirements, it could operate without its own copy of the XRP Ledger's decentralized exchange, or it could add new transaction types and functionality for storing large chunks of data on-ledger. The possibilities are limitless: a sidechain can be strictly permissioned or (nearly) permissionless, centralized or (mostly) decentralized. You could even run a sidechain temporarily while letting it manage real value and gracefully shut it down after it has served its purpose.
Immediate advantages of Federated Sidechains for developers include:
Horizontal scaling: Sidechains can have their own fee system, their own reserve system, and their own transaction capacity. Someone who wants to create a system with thousands of users that can hold XRP has a better option than being the custodian or putting all the accounts on XRPL directly.
Low risk: The XRP Ledger doesn't need to change at all. Even the changes that would be helpful are quite minimal.
Low effort: Anyone who needs or wants to experiment with a blockchain can get started with a complete system ready out of the box, based on powerful, 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 would be a continuous stream of new features and capabilities.
Changes to the XRP Ledger
Succeeding in this vision requires a few changes to the XRPL software that wouldn’t be used on XRPL itself in order to support the sidechain features. The primary change to the software would be to support the unique node list (UNL) being stored in the ledger. Pseudo-transactions to change the UNL would be needed. A “hint” UNL would need to be supported to avoid the chicken and egg problem of needing the UNL to get the ledger and the ledger to get the UNL.
Support for the coordination of creating threshold and/or multisign keys and signing XRPL transactions introduced by the federator is also necessary. Some API enhancements would likely be needed to handle pseudo-transactions introduced by the federator or federator-federator communication through the peer network.
The XRP Ledger mainnet could also use a flag to indicate whether an issued asset was permitted to federate or not. Some asset issuers, for example, might insist that all holders of their assets be directly represented on the main chain for regulatory purposes while others could allow their assets to freely trade on sidechains. (It's always possible to privately allocate some of your own resources to others, with or without a sidechain to automate the process, but the legal responsibilities of doing so can vary based on jurisdiction and circumstances.)
Sidechains would have a special entry in their ledgers that tracks the last sidechain transaction that has been executed on the main chain and the last main chain transaction that has been executed on the sidechain.
When federators see a new transaction on the sidechain that affects the main chain, they coordinate the submission of that transaction to the main chain. When federators see a new transaction on the main chain that affects the sidechain, they coordinate the submission of that transaction to the main chain.
Making these changes is probably the biggest part of this effort because even though they won’t be enabled on XRPL, there is still risk associated with changing the software. For example, some existing code may need to be moved or adjusted which carries the risk of inadvertently changing behavior.
The outlined strategy is a starting point to gather feedback from the XRP Ledger community. We invite developers and contributors to the community to comment below. Let’s build a roadmap for innovative, new use cases together.
Latest comments (23)
[Note: I also posted something similar to this on the "0020 XLS-20d Non-Fungible Token Support (native)" Github discussion. I'm trying to explore different options for my idea - which I really want running on the XRPL.]
I'm curious about federated side chains, because I'm currently working on a science/business idea using something like 'fractional NFTs'.
I realise this may sound somewhat confusing, as NFTs are by their nature 'indivisible', but I think it's at least conceptually possible if we flip the concept upside-down.
Essentially, I'm referring to minting NFTs for elements of a piece (e.g. pixels of an image) and then grouping them together as a set of NFTs. This could allow for fractional ownership and trading of especially valuable NFTs. This could be quite valuable as it wouldn't exclude anyone based on their financial resources (in the same way fractional shares open up the stock market to a wider range of people).
Could a specialised side chain be capable of issuing copious amounts of NFTs that could then be linked to represent a group of NFTs (tied to a particular object)? So basically a number of 'supra-NFTs' with nested 'sub-NFTs'.
I asked about this on the 0020 XLS-20d Github discussion... but I fear the amount of NFTs my project idea would need to issue will get out of hand very quickly because of the the reserve requirement. i.e. minting 'sub-NFTs' for a 1080x1920 image (2 073 600 pixels) would require 64 800 NFToken pages and 324 000 XRP (at reserve=5 XRP).
Is a specialised side chain a possible way to solve this?
I'm probably being a little unreasonable... but I just really want 'fractional NFTs'... haha
Please bear in mind, I am also a total noob. I have zero experience in blockchain technology and only some experience in scripting for data analysis in R and python.
Thanks a lot
Cheers!
Hopefully one day someone will create a side chain that tokenized movie funding, to help fund indie movies. It would really help the entertainment industry and its struggling talent work on amazing projects. Imagine being able to read a script and invest in it and it rackes in hundreds of millions and also has royalties you’re also entitled to. Kinda sounds like a security but I’m sure there’s a way to structure it so it’s not.
That wouldn't ned a side chain. You could just use the main XRP Ledger to do that. Sounds like a very interesting idea. I know that Coil were looking at similar and I think funded a feature length film as part of Grant for the Web.
There’s so much opportunity in films and series that I really think decentralization would help really good ideas be executed and not have a fast and the furious 17. Hopefully aslo help the vfx industry get compensated better by having them be eligible to tokens because they worked on the projects.
This is interesting. I'll be following.
Hi Ben! Thanks :) And great work on dev.to and Forem! I'm very much a fan on what you have been creating!
So, I could isolate an instance on the XRPL on my home network, tie a main wallet to the interface to the public XRPL. I could then issue no fee wallets internally that represent various aspects of my budget. (Mortgage, food, medical, clothing, etc)
In the (hopefully) near future when I can seamlessly interchange XRP for XUSD(US Fed XRP based CBDC), I can pay with my XUMM app that is tied to my external wallet with memos that are automatically filed in the correct budget line items as my internal implementation of XRPL is notified of external purchases.
I know, kind of a mundane implementation, but it is a free engine for home budgeting, and who has their budget history on a blockchain?
This could come in handy come tax time.... Itemize medical expenses, child care, etc...
Just a thought.
Just need to have something read the memos and file the purchases to the correct internal wallets, or manually sort things that are not clearly defined...
It would certainly be possible. Although I'd probably say running your own sidechain might be overkill for just yourself!
Just spit balling at the moment. This opens a lot of potential. I thought a little more about it, and really, any organization could create an internal currency and maintain records on their own ledger, using a common external wallet for outside transactions.
Correct. Which is pretty much what any centralised exchange (Coinbase, Kraken, etc) do. Just in this case "their own ledger" would be an instance of the XRP Ledger code running privately.
Brilliant! I hope they have adequate quality control management because I've experienced some bad side effects from 'trivial' code changes in the past. But then again, David's sense of something being trivial is probably the equivalent to my professors when they skip through some lecture slides that still require some elbow-grease to decipher.
Wow! This is amazing. It seems like this will empower the advancement of CBDC's being able to either issue their token on the XRPL or on their own clone of the XRPL and seamlessly interact with the Mainnet.
I thought it was a bad idea to issue NFTs and Hooks on the Ledger. This solves both those issues. Just clone rippled and build the solution there.
Exactly, this enables a bank to run a "private" network of rippled instances to issue their CBDC on and then connect that to the main public XRPL.
related: ripple.com/insights/ripple-pilots-...
I have a quick question. Does it mean Ripple is building interoperability in its own ecosystem? Is it possible that this sidechain will connect XRPL with another blockchain?
Wow, I appreciate you Matt. Thanks for the explanation.
Thanks Matt and David for the great work, We are building an e-commerce site for an unbanked market. Could we use the side chain to create our own tokens and have our own smart contracts and still be able to exchange our native tokens with xrp?
Yes, you could do that.
Is there any shared security from XRPL main net or does each sidechain have its own security assumptions depending on its validator set?
Each sidechain is completely independant and has its own security assumptions based on its own validator set.
Thx and understood. Is a shared trust model something RippleX considered or is researching? Advantage is that security isn't starting from scratch.
Look forward to this, opens the doors to new developments in general.
Do we know when demo/code will be posted, some boiler plate for testing?
"soon". I'm hoping to get David and one of the other Ripple engineers that has been working on it on the Twitch stream.