XRP Ledger Sidechains, Redesigned


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 sidechain that assets were returned or destroyed on the mainchain
  • 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:

  1. The user claims a cross-chain claim ID on the destination chain.
  2. 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.
  3. 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.
  4. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

How I made a discord bot to generate artistic images and a poetic text about it

Next Post

Node.js ‘__dirname’ vrs ‘process.cwd()’

Related Posts