Last year, David Schwartz unveiled a vision for federated sidechains: an innovation intended for developers to customize the XRP Ledger (XRPL) to the needs of their use case, or build and experiment with new features that, if successful, could be proposed to the mainnet.
For the last few months, federated sidechains have been available in a preview mode for developers to experiment with the transfer of tokens including the XRP Ledger’s native XRP from the "main" XRPL to a "sidechain." After testing and reviewing community feedback from the preview, Ripple engineers are excited to unveil the next iteration of XRPL sidechains with a new design.
Understanding the New XRP Ledger Sidechains
The original design for XRPL sidechains introduced an innovation called a “federator”—a piece of software that connects to at least two instances of the XRPL software. On one side, the federator connects to XRP Ledger Mainnet and to one (or more) sidechains on the other side.
The federator software allows anyone to run a sidechain to the XRP Ledger while having the freedom to decide how their chains work.
While the core concept remains the same, the new design for XRP Ledger sidechains does away with the federator and instead leverages a “witness.”
Why? Witness servers introduce more simplicity for developers wanting to get started with sidechains. Moving from a system in which servers depend on a shared global state between servers (a federator) to one where servers act independently (a witness) makes testing and debugging easier while making sidechains more robust in production. The new design also addresses several pain points, such as fee escalation and transaction throughput.
Any bridging solution between blockchains—such as the XRPL and its sidechains—should support the following primitives:
- Putting assets into trust on the mainchain
- Issuing wrapped assets on the sidechain
- Returning or destroying wrapped assets on the sidechain
- Proving to a sidechain that assets were put into trust on the mainchain
- Proving to a mainchain that assets were returned or destroyed on the sidechain
- Preventing assets from being wrapped multiple times, and preventing transaction replay
While both designs support these primitives, the new design results in a simpler implementation. It also solves for a number of errors that previously hindered efficiency.
| Federator | Witness | |
|---|---|---|
| In the situation of fee escalation, servers would have to decide on what fee to use | → | Transactions are not submitted by the servers, so users can specify a fee like any other transaction |
| Out-of band transactions resulted in the need to use tickets | → | This is no longer an issue |
| Failed transactions resulted in refunds | → | Users can re-send the claim to an account |
| Fees paid by door resulted in awkward accounting for locked assets | → | Fees are paid by a user account |
| Door accounts acted as a bottleneck, limiting transactions on a single account | → | Transactions are submitted by non-door accounts |
| Previously, federators relied on a codebase that was a fork of rippled | → | Witnesses use a separate (and much simpler) codebase, so a few additional transactions are added to rippled |
| Testing and bug fixes were complex, due to all federators needing to stay in sync | → | Transactions can be tested and debugged in isolation since the witness server is much simpler |
While witness servers solve for the issues identified above, there is still some testing and exploration needed to address things like creating accounts and the need for wallets, which is often complex.
Cross-Chain Transfers
The XRPL mainchain and sidechain operate as parallel networks with independent nodes and validators. With the new design, the witness watches transactions and attests that assets have moved into specially designated accounts.
Doing so allows the ability to carry out a cross-chain transfer in which:
- The user claims a cross-chain claim ID on the destination chain.
- The user submits a cross-chain transfer transaction on the source chain, attaching the claimed cross-chain claim ID and including a reward amount for the witness servers. This locks or burns the asset on the source chain.
- The witness server signs an attestation saying that the funds were locked/burned on the source chain. This is then submitted as a transaction on the destination chain.
- When there is a quorum of witness attestations, the funds can be claimed on the destination chain. If a destination account is included in the initial transfer, then the funds automatically transfer when quorum is reached. Otherwise, the user can submit a claim transaction for the transferred value on the destination chain.
Simply put, a witness watches transactions and attests that assets have moved into specially designated accounts. This is due to its use of a cross-chain claim ID, which makes it so that the ledger doesn’t need to keep track of all hashes that it has seen to prevent replay attacks and the fact that signatures are broadcast on the ledger instead of users needing to query the witness server.
Sidechains Roadmap
Looking ahead, we’re working on an Ethereum Virtual Machine (EVM) sidechain to allow even more developers easy access to XRPL’s feature set and bring existing Solidity-based smart contracts written for EVM-compatible chains to the XRPL. The first step in bringing this to life will be a devnet release, and we’re excited to update on our progress in the coming weeks.
As a direct response to the demand for smart contract-like functionality on the XRP Ledger, the team at XRPL Labs has introduced Hooks with plans to deploy the functionality to an XRPL sidechain. Doing so will allow for programmability on top of XRPL as well as smart contact capabilities that are fast, low-cost and eliminate the need for Solidity or contract-to-contract calling.
We will keep the community apprised of new updates as we continue to progress our roadmap for XRPL sidechains.
Unlocking New Use Cases for the XRPL
Sidechains ultimately allow for experimentation and specialization with new features on the XRPL. For example, developers could implement new features such as smart contracts via a sidechain to unlock native DeFi (and even more tokenization) capabilities on the XRP Ledger. Moreover, sidechains let developers use XRP in their own blockchain environment—effectively and without having to build value for a new token.
Sidechains also act as an environment for imagining new XRPL functionality while ensuring its existing feature set isn’t compromised. This is because sidechains have their own validators and can have their own set of custom transactions. Because sidechains act as their own blockchain, developers can pick and choose XRPL features that best fit their particular use case. Devs could even create a private, parallel network for a permissioned blockchain if they wanted—all the while enjoying the inherent benefits of the main XRPL like low costs and fast transactions.
With the re-release of sidechains, we invite developers and contributors to the XRPL community to comment and ask questions below. To learn more about sidechains, visit GitHub.
Top comments (4)
I was wondering, what happens when all validators keys from the sidechain would get lost for whatever reason?
See what would happen with the XRPL, in case all validators in the UNL fail or are lost, then the others will simply select new validators for the UNL, and the network starts running its course again.
However, what will happen with such an event on a side-chain? Then all the funds from that side-chain are locked in the multi-sig account for-ever... I also wonder how difficult it will become to manage changes on a side-chain UNL in general and how decentralized that actually will be ... Because not every nodes' decision on which validator on the UNL can be added to the multi-sig on the main-chain just like that ...
Will there be support for vyper on the EVM chain?
vyper compiles down to byte code just like solidity. If they support the evm, these languages will both work.
With the sidechains being able to do many many more transactions than the main-net, doesn’t this create a bottleneck? Are there plans to upgrade tps on the main xrpl to handle more tps?