On February 22nd, Mayukha Vadari tweeted about a new XRPL Standards Proposal that outlines a Cross-Chain Bridge connecting the XRP Ledger and Sidechains. The esteemed software engineer at RippleX has published a comprehensive Github page that delves into the details of the proposed Cross-Chain Bridge.
Cross-chain bridges are software applications that enable transactions to occur between various blockchains. If someone wants to transfer a cryptocurrency, or another digital asset between blockchain networks, cross-chain bridges are an essential part of the process.
The Github proposal attentively notes: “A bridge does not exchange assets between two ledgers. Instead, it locks assets on one ledger (the “locking chain”) and represents those assets with wrapped assets on another chain (the “issuing chain”). A good model to remember is a box with an infinite supply of wrapped assets. Putting an asset from the locking chain into the box will release a wrapped asset onto the issuing chain. Putting a wrapped asset from the issuing chain back into the box will release one of the existing locking chain assets back onto the locking chain. There is no way to get assets into or out of the box.”
The design proposes 1 new server type called “witness servers”, 3 new ledger objects, and 8 new transactions.
So-called “Door accounts” will be vital in bridging transactions between chains. Door accounts represent the account on the locking chain used to put assets into trust, or the account on the issuing chain used to issue wrapped assets.
The introduction of a new type of server called witness servers will help provide proof that an event happened on either the locking chain or the issuing chain. The primary function of these lightweight servers is to listen to transactions on one side of the bridge and submit attestations on the other side, affirming that a transaction on the source chain occurred.
A witness server may offer attestations for a single chain, and the door account on the locking chain could potentially have a different list of signers than the door account on the issuing chain. An attestation is a message signed by a witness server attesting to a particular event on the other chain. This is used because chains don’t talk to each other directly. The current implementation of the witness server assumes that it is providing attestations for both chains. However, Mayukha Vadari notes that allowing witness servers to only know about one of the chains is desirable.
It is interesting to note that signing an attestation will take place on-chain, requiring a transaction and paying a fee by the signer. This highlights the need for rewarding a witness server to provide signatures.
Let’s say that Alice has some funds in her account that she wants from her account to another account on a different chain. In this case, the locking chain (or source chain in this example) represents where her funds are currently, and the issuing chain (destination chain) represents where she wants to move her funds.
To initiate the Bridge transaction, Alice creates a “claim ID” on the destination chain, which creates a new Ledger object that specifies the source account (where her funds are currently) on the source chain.
Then, Alice submits a transaction on the source chain, attaching the “claim ID” she previously created on the destination chain. Alice also includes a reward amount for the witness servers as compensation for them providing attestations on her transactions.
Individual witness servers then sign an attestation saying that Alice’s funds are indeed locked/burned on the source chain, and when a quorum of witness attestations is reached, her funds can be claimed on the destination chain.
Cross-chain bridges are a vital component in enabling interoperability between different blockchain networks. However, they also present unique security challenges that must be addressed to protect users’ funds.
Over the past years, several hacks and attacks have exploited vulnerabilities in cross-chain bridges. These hacks have resulted in the loss of hundreds of millions of dollars in user funds and have highlighted the need for more robust security measures.
The XLS-38d proposal mentions an assumption of trust between the witness servers, and if a quorum of them colludes, they can steal funds from the door account. In the case of an IOU-IOU bridge, this presents significantly more security risks as issuers create the bridge themselves. They also choose the quorum of witness servers that provide attestations. As mentioned, these witness servers can collude and steal funds from the door account, which can be spun up relatively quickly. This will present opportunities for malicious actors in the somewhat lawless sphere that crypto still is.
For more information, visit the proposal on GitHub here.
In conclusion, the XLS-38D Cross-Chain Bridge Standard Proposal is an innovative solution to enable transactions between the XRPL and Sidechains. The proposal outlines in detail how and which new Ledger objects will be used and how witness servers will be used to provide attestations to ensure the security of users’ funds. However, it is essential to note that cross-chain bridges still pose unique security challenges that must be addressed to protect users’ funds fully. As the blockchain industry continues to evolve, developing more robust security measures to prevent hacks and attacks on cross-chain bridges will be crucial.
Related Articles
