0038 XLS-38d: Cross-Chain Bridge (side chains) #92
Replies: 13 comments 74 replies
-
|
Love to see movement still on this initiative well done to all involved! Have some questions.
|
Beta Was this translation helpful? Give feedback.
-
Thanks for the thoughtful questions!
What happens now is the multi-signer's list on the door account are the witness server's signing keys. This is essentially the list of witness servers. Changing the witness servers requires changing this list. The multi-signer's list can be changed by submitting a transaction signed by a quorum of existing witness servers. This makes sense to me. The entities currently controlling the bridge get to decide on changes to the bridge. I'm not sure what entities you are allowing to vote through the UNL. Are you proposing the the entities on the UNL itself are allowed to vote on changes to a bridge. I don't think that will work well. If you're proposing that the current owners of the bridge vote via the UNL in some way, I think we already have a mechanism to let the owner vote (a multi-signed transaction). Although that does require off-ledger coordination that an on-ledger vote wouldn't require. I think that's OK at least for now. We can add a way for on-ledger voting to change the list later if needed. (I don't have a design, but it could look like the current "add attestation" transaction, but for changing the multi-signer's list).
I thought about doing that. I had a balance field on the bridge object that tracked locked or issued funds. I decided that the account balance was a good enough proxy for this (tho not exact). We can discuss adding this back if people think it's important.
The multi-signer's list controls the door account, and if a quorum of witness server operators decide to release funds in an emergency, they can do so. Noted about needing more docs around this.
In a normal cross-chain transaction, the "reward" is paid on the opposite side of the "commit" transaction. I'm not sure what you mean by using a "gas fee" instead.
I think this runs the risk of accidentally either locking funds forever (if an expired key couldn't be used for any reason) or halting the bridge (if expired keys could only be used to change keys).
It's important to me that the witness servers are private. It greatly reduces the attack surface (it's hard to DOS a witness server if you don't know it's IP address, for example). I think there may be room for public witness servers in the future, and there may be some interesting use-cases for those. But for now I'd like to assume that witness servers are private. |
Beta Was this translation helpful? Give feedback.
-
|
With regards to the last point the current submission nodes could pass that query on where by still masking the identification of the witness node. The clients still only query at the submission nodes. My question around some form of UNL vote essentially allows for external on/off switch if something does wrong and it is seen to be damaging the ecosystem/ledger. This was there is a onledger back up to halt the bridge. With regard to the GAS fee and rewards question. My position on rewards and oracles is they should not mix. But I do recognize a transaction fee needs to be paid some chains this fee is called GAS. If I'm moving funds from XRPL to another chain with a high gas fee I need to account for that. To make sure the funds on the other side are delivered. I'm hoping that no middle man is going to be sitting here and simply reaping a reward running one of these. Thanks you for your detailed reply, @seelabs |
Beta Was this translation helpful? Give feedback.
-
The submission nodes don't know about the witness servers either. The witness servers listen to the transactions on the chain, and they submit transactions to the chain, but the chain doesn't know the IP address of the witness server, so submission nodes can't forward the query.
Ah, I see. In that case it sounds like amendments already fill a similar role (tho not exactly what you have in mind). If there's a serious issue with this design that's damaging to the ecosystem/ledger an amendment could be introduced that addresses the issue and the UNL votes on if it should be adopted or not. One nice thing about the current design is anyone can make a sidechain. The UNL doesn't need to know about it and you don't need to ask permission to do it. Asking servers on the network to vote on allowing specific sidechains (as opposed to voting on general sidechain functionality) moves us away from that world. Given one motivation of sidechains is to allow experimentation, moving towards a more permissioned world moves us away from that experimentation, I think. > I'm hoping that no middle man is going to be sitting here and simply reaping a reward running one of these. Higher rewards would discourage cross chain transactions. So they may be better off with smaller fees and larger volume. Larger rewards would also make the sidechain less healthy, which they likely are motivated to keep healthy. Thanks again for your thoughtful clarifications @lathanbritz ! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @seelabs, what are the use cases to making witness servers public? I can't think of a thing that's a good tradeoff since making them public would expose them to DOS attacks. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@wojake Thanks for the comment! I agree with you about exposing the witness servers to DOS attacks. However, there are benefits to making them public: we can add a claim transaction where the attestations are submitted with the claim - this should increase throughput as well as simplifying a sidechain that uses this because it wouldn't need to support the complicated "add attestation" commands. Also, with public servers it may be feasible for a witness server to monitor an entire chain for all sidechain "commit" transactions and attest to them through and API instead of submitting the transactions itself. Maybe the server could charge a subscription fee to use the API as well. But please note the "public facing witness servers" is just a thought in the back of my mind. I don't have a design and I haven't thought through the issues. I'm a long way to perusing these thoughts. In the submitted proposal the witness servers are definitely meant to be private. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this standards draft! Following from the sidelines, the design and terminology has changed a lot over the last year – so in advance sorry if some of my questions and observations are mixed up and refer to previous and now abandoned design choices.
|
Beta Was this translation helpful? Give feedback.
-
@Silkjaer Thank you for your insightful comments!
That's a great comment, thank you. One quibble before I talk about the meat of your comment. You mention error handling as a weakness this and similar designs. I actually like the error handling mechanism of the claim id mechanism. If there is an error transferring funds, the claim id is not consumed and the claim id owner may redirect the payment. That makes handling things like deposit auth, dest tag required, and other ways of making payments fail easier to deal with. You correctly point out that someone who can't check out a claim id can't use a regular cross-chain transaction. The reason for this is my desire to keep the witness servers as simple as possible. The other designs I considered required witness servers that acted as a distributed system rather than individual servers. In those more complex designs, the "claim id" is not needed, but implementing and debugging the system was much more complex. I would like to start with this simple design, where the witness servers act individually, and after this simple version is launched, explore adding complexity to the witness servers and removing complexity from the protocol (i.e. look at getting rid of the "claim id"). But you're correct, that decision limits us to "native users". I appreciate the comment. I very much welcome the opportunity to show the trade-offs that were made. One minor note: the design does have a transaction that could be used for "custody users": the "Account Create" interface. However, that interface has limitations where I wouldn't encourage that use - error handling in particular.
Every transaction provides the same reward, so there should be no incentive to favor one transaction over another. The only time when the rewards won't be the same is when the reward amount is change (through a
Yes, the design is very explicit that if a quorum of entities on the signer's list collude, it's game over. I don't think it matters if the funds are stolen through a regular payment transaction or fraudulent attestations. I will defend this by saying any design is going to require some primitive to move funds - compromise that primitive and it's also "game over". I did think about other ways to prove funds were put into trust (and the design can be expanded to include these other proofs in the future), but a quorum of signatures seems like a good primitive to start with.
Since the witness servers control the movement of funds, I think it makes sense that if anyone should be able to change the bridge it should be the witness server. However, the current design does not allow the witness servers to "vote" for changes on-chain, and this would require off-chain coordination if these changes were to be made. I think providing a way to vote for changes on-chain is an interesting extension of the design. However, while I think it's a good suggestion, I also don't think it's critical to launch with that. I'm trying to launch with the minimum required feature set.
I would expect the identity of the entities running the witness servers to be public, yes.
I'm going to defer the answer to this to others. I'm an engineer, I shouldn't comment on legal questions. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the in-depth answers!
I actually meant to say that error handling is a weakness of the existing bridges, and XLS38d is a huge improvement on that 👏
If a L2 bridge is somehow compromised, people will blame the bridge. If native functionality is used and an incident happens, people will blame the technology. My main issue probably boils down to: since witnesses still has to coordinate off-chain, they have to behave as a sort of entity (centralized), but is acting as it is not an entity (decentralized). A bridge can't both be centralized and decentralized at the same time – at very best it's somewhere in the gray, in between. The benefits of the amendment has to outweigh the drawbacks of having a centralized entity run a bridge for a sidechain, which would not require changes to the core at all. That entity could also be run by a consortium of witnesses, with signerlists etc. The amount of trust would be the same. This can't be discussed, without also discussing some of the legal aspects. Decentralization has been an excuse to skip e.g. due diligence and AML/KYC, because no entity is single-handedly responsible and the technology isn't licensable. In this design, it is questionable whether the bridge falls within those criteria. (The same applies for many existing bridges). Some people will probably sniff this comment out and attack the similarities between the witness design and the XRPL itself with its UNL(s) – claiming i call the XRPL centralized. So just to be a bit ahead of that, there are big differences to a, what Stefan Thomas refers to as Proof of Association. Witnesses is a set list of signers, whilst the UNL suggests new node operators who to trust. Any node operator can decide who they trust themselves. So I guess I say that I think the design has to go down the complexity path right away – witness servers should also be distributed, with some consensus mechanism that makes it actually decentralized, beyond a doubt. OR a bridge might as well be run by a properly licensed entity. |
Beta Was this translation helpful? Give feedback.
-
|
I planned on writing a pretty long comment and I'm halfway finished but I didn't want to write under the assumption that there are benefits to using a normal transaction with a multi-sig list on it, coordinated by the bridge's own layer-2 network (Appendix B) than using the proposed There are noted complex issues with using a separate distributed system as a service (L2) to coordinate and distribute signatures and I'm personally faced with that, mainly:
It would be nice if you could also share on how you mitigated these issues or how you planned on mitigating them if we were to go for the L2 designed ❤️ ! |
Beta Was this translation helpful? Give feedback.
-
@wojake: it sounds like you have a clear understanding of the trade-offs between the two designs.
One solution is to detect when the servers fall too far behind and disable cross-chain transactions until they catch up. For example, but use "deposit auth" on the door accounts.
In the proposed design, fees escalation is an easy problem. Individual servers can set the fee on their own, and raise the fee if desired without communicating with the other servers. As long as the fee is smaller than the reward, it makes sense to raise the fee. For servers falling behind no special action is taken. The witness servers are very simple, it unlikely they will not be able to keep up with cross chain transactions. More likely is a scenario where enough witness servers go off-line. If this happens I think it's best to take no action. However, one thing we could potentially do is when the witness servers detect too many attestations have been added to the ledger without being cleared, they could pause adding their own attestations. As a side note, when deciding between a trade-off between putting complexity on-ledger or on an external program, I lean toward putting the complexity in the external program. However, in this case the witness servers would be so much more complex than the added ledger complexity that I think the simple witness servers is the correct direction. |
Beta Was this translation helpful? Give feedback.
-
|
Why not go with the light client approach for bridging between XRPL chains? Any XRPL chain can directly verify (on chain) whether a transaction was validated on another chain simply by knowing the other chain's UNL. If chain A knows chain B's UNL, chain A can be fed a ledger header from chain B, as well as sufficient validations for said header from validators on chain B's UNL. Then, for any cross chain transfer from chain B, all that's needed is the SHAMap proof path for the transaction, proving the transaction is in the ledger. You can store the UNL on ledger as a ledger object to make this process simple for other chains. If we did this, there would be no need to trust witness servers or any entity besides the two chains involved in bridging. As it stands right now, the witness servers are an attack vector. If the witness servers collude, or if their private keys are compromised (as has happened in many multi million dollar bridge hacks in the past few years), millions of dollars of funds will be lost. The light client approach eliminates this common attack vector, and is thus a far more secure bridge. The reason all bridges are not light clients is because it is hard to build a light client for most chains. But for XRPL chains, it is incredibly easy, because of the way XRPL consensus works. Given this, it just seems like a bad design decision to go with a design that allows for the hack we've seen so often in the bridge space. Even from an infrastructure standpoint, the light client approach is easier. All that's needed is a relayer to pass transactions between the two chains, which is not trusted and only provides liveness, and could really be run by anyone, or even done by the wallet itself. This approach would also be useful when XRPL (hopefully) starts bridging to other chains. Any remote chain can verify a transaction was validated by an XRPL chain using the same approach described here. |
Beta Was this translation helpful? Give feedback.
-
|
If I'm not mistaken, @cjcobb23's suggestion would essentially make the XRPL a layer-0 network? Or am I just using crypto gibberish 😆 |
Beta Was this translation helpful? Give feedback.
-
|
The light approach reminds me of the xPop demonstration at Apex: https://www.youtube.com/watch?v=URSo8e3NbS8 A drawback is that it would limit bridges to compatible chains only? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @cjcobb23. I understand your comment isn't a proposal - I don't expect it to be, but can you help clarify some things for me, even at a high level? There are a couple of primitives we need. Let look at it from the perspective of the XRPL mainnet. Let's call this the "mainchain" the we'll call the other chain the "sidechain". Let's only worry about the "mainchain". Who informs the mainchain that an asset was moved into trust on the sidechain?In the current proposal, there are "witness servers" that are tasked with sending this information. In this light-client approach, who does this? I can think of a couple possibilities:
I think you are proposing (2), but I'm not sure. Can you clarify? In what form is this information given to the network and where does it live?In the current proposal, there's an "Add Attestation" transaction that provides the information and the information lives on the ledger. There are other ways of providing the information (requiring attestations in a "claim" transaction, for example). In that case, the attestations don't live on the ledger, since it can be in the transaction. In this light-client approach, how is the information provided and where does it live? I can think of a couple possibilities:
I think you are proposing (2), but I'm not sure. Can you clarify? We need a way to prove that something happened on the other chain.In the current proposal, witness servers are trusted and they sign attestations that some event occurred. I think you are proposing using proof trees instead, where the proof tree root is signed by some subset of validators, and the list of validators is signed by some list of entities. I think this is clearer, but if I'm misunderstanding, please let me know. As an aside, I think using proof trees is a good way to provide proofs that something happened on the other chain. It does require trusting the signer's of a validators list, but this seems like a reasonable trust model. I wouldn't want to trust a single signature, no matter who it was, but a list signed by a couple of entities would be OK. I was a little worried about the size of proof trees, and there were some thought that would reduce their size in rippled. At any rate, adding "proof trees" as a new attestation type in a future version of sidechains should fit into the current design reasonably well. To be clear, I know you are proposing more than just "use proof" trees, I'm just commenting on "could we use proof trees as an attestation type" and I think we could. We need a way to prevent proofs from being used more than once.If an asset if put into trust, the wrapped version of that asset should be issued exactly once on the other chain. The current design uses "claim ids" to prevent replay of "claim" transactions, and it uses transaction ordering to prevent replay of "account create" transactions. In this light-client approach, what prevents transaction replay. I can think of a couple possibilities:
I'm not sure what you are proposing. Can you clarify? We need a way to handle transaction failures.For example, if the destination has "deposit auth" set, a cross transfer transaction can fail. In the current design, "claim ids" are used to handle this error (the claim id won't be consumed and the asset can be directed to another account). I'm assuming a light-client version would have some automated refund mechanism? That works, but it does complicate the protocol. If you've thought about error handling, can you clarify what you're thinking? |
Beta Was this translation helpful? Give feedback.
-
This is something that had been discussed before. It assumes that there exists a UNL, which may not be the case. Even if there is, there are corner cases around the UNL expiring or changing. Not dismissing this idea, but there's complexity and security considerations there that require serious thought.
It's unclear to me if that really results in a "far more secure bridge." In fact, the same attack vector continues to exists under your proposal: instead of the witness servers, the validators can mount the same attack. |
Beta Was this translation helpful? Give feedback.
-
This is done by an off chain relayer. The relayer retrieves proof from chain A that an asset was moved into trust on chain A, and sends that proof to chain B. The relayer is not trusted though. Anyone can run a relayer, or the wallet itself can act as the relayer. The relayer does not have an identity or add any sort of signatures to the message that's relayed.
The proof could just be supplied as part of the transaction. If the proof is provided fully as one transaction, I don't think anything needs to live in the state.
We are on the same page here.
I don't have a strong opinion on how this should be done. I think solution 1, 2 or 3 that you proposed would work fine here. I was thinking of explicitly tracking which proofs have been used, and enforcing a timeout so the old proofs can be cleaned up eventually. You wouldn't need to store the full proof itself, but rather just some identifier, such as a hash.
I have not thought explicitly about error handling. I'd imagine the claim ID solution could work. Or you could actually record the failures in the ledger of the destination chain, and then relay proof of that failure back to the source chain to release the funds back to the original sender. |
Beta Was this translation helpful? Give feedback.
-
When would there ever not be a UNL? As to the UNL expiring or changing, the light client can handle that in the same way that rippled handles UNLs expiring or changing.
The validators could mount the same attack, but this is unlikely and I would argue violates the trust assumption we already have for the ledger. We trust that more than 80% of the mainnet validators will not collude in a malicious way. The attack I'm actually concerned with though is not collusion but a separate entity compromising the private keys of the witness servers. This is the bridge attack we've seen in practice several times already. In the light client approach, an attacker would need to compromise the private keys of the validators, which I think is much less likely, and would enable them to mount all sorts of attacks beyond just attacking the sidechain bridge. Furthermore, I would argue that both of these attacks (validator collusion or validator key compromise) would work with the existing bridge architecture anyways. If the validators collude to validate malicious transactions and change the state of the ledger, they can probably fool the witness servers (as well as centralized exchanges). All in all, I think the validators colluding or their keys being compromised is an all bets are off scenario, in which case the whole security assumption of the network is violated. So the light client approach is basically just not adding additional security assumptions (such as the witness servers not colluding or not getting their keys compromised). |
Beta Was this translation helpful? Give feedback.
-
That is fine. If there are multiple UNLs, there can be multiple bridges. If you want to use Acme's UNL on mainnet, you can also use a side chain bridge that honors Acme's UNL. And if you then want to migrate away from it, you also start using a different bridge. This won't be necessary in practice though, because there are only a few UNLs that people listen to, and they are almost exactly the same set of validators. Which is necessary to avoid forking. Also, this same argument would apply to the witness servers. The witness servers need to listen to a UNL (or multiple). Whatever UNLs they are listening to define the bridge. It's basically the same thing. |
Beta Was this translation helpful? Give feedback.
-
How would that practically work in a setup as envisioned by Ripple, where the sidechain also use a native asset called XRP? In that scenario, the sidechain itself has to trust the bridge, to issue additional native assets? If anyone could set up a bridge, then anyone can print money on the sidechain. This spec doesn't exclusively detail that use case though. |
Beta Was this translation helpful? Give feedback.
-
The sidechain can trust a bridge to issue additional native assets by verifying and validating the proofs of correctness and validity provided by the bridge. When a sidechain receives a message from another blockchain through the IBC protocol, it checks the cryptographic proofs contained in the message to ensure that they are valid and were generated by the sender blockchain. This includes verifying the signatures of the validators who processed the transaction on the sender blockchain and confirming that the transaction was included in a valid block. If the cryptographic proofs are valid, the sidechain can trust that the transaction was executed correctly on the sender blockchain and can proceed to execute the corresponding action on the sidechain, such as issuing additional native assets. Additionally, the bridge can provide collateral in the form of staked tokens or other assets to guarantee its obligations, and the sidechain can perform periodic audits of the bridge to ensure its continued trustworthiness.
To prevent just anyone from creating a bridge and issuing tokens on the sidechain, the Inter-Blockchain Communication (IBC) protocol includes several mechanisms that ensure the authenticity and validity of the bridge. Firstly, the IBC protocol requires that the bridge is registered on both the sending and receiving blockchains, and that it satisfies certain requirements to become an eligible bridge. For example, the bridge may need to hold a minimum amount of stake in the sending blockchain, demonstrate a track record of successful operation, and meet certain technical requirements. Secondly, the IBC protocol includes a mechanism called Proof-of-Relay (PoR), which requires that the bridge prove that it has actually relayed the transaction from the sending blockchain to the receiving blockchain. This is done by including a cryptographic proof of the relay in the IBC packet that is sent between the blockchains. The PoR mechanism ensures that the bridge is actively participating in the IBC process and is not simply issuing tokens on the sidechain without proper authorization. Finally, the sidechain itself can implement additional verification and validation mechanisms to ensure that only authorized bridges are allowed to issue tokens. For example, the sidechain can require that the bridge holds a specific type of token on the sidechain in order to issue new tokens, or it can require that the bridge provides a collateral deposit that is forfeited in the case of any fraudulent activity.
An adapter would be required to convert the data and assets from the format used by the non-IBC compatible chain to the format used by the IBC-compatible chain. The adapter would act as a bridge between the two chains, allowing them to communicate using the proposed IBC protocol. The adapter could be developed as a standalone application or integrated into an existing blockchain node. The adapter would need to be designed to handle the specific requirements of the non-IBC compatible chain, including the validation of transactions and the conversion of data and assets. |
Beta Was this translation helpful? Give feedback.
-
In practice, there would just be one bridge, so I think this is a non-issue. You are right though, there would have to be one canonical bridge that the sidechain uses for native assets, and assets from other bridges cannot be used as the native asset. I would say that the whole idea of "I can choose whatever UNL I want" doesn't really work for side chains and bridging, irrespective of bridge technology. If you choose a different UNL on main chain that actually forks away from the UNL that the bridge is using, then you won't be able to use the bridge. If the UNL validators on mainnet become malicious, everyone on mainnet can just decide to use a different UNL. But the transactions that were validated maliciously may have already moved across the bridge (whether the bridge is light client or witness servers, doesn't really matter), and the side chain has no real recourse except to also fork (even though it's own validator set is not malicious). You are free to use whatever UNL you want, but it should be validating the same transactions as everyone else's UNL, else you are going to be off on your own fork. Which means we can just use one bridge with a single UNL that tracks the network state. |
Beta Was this translation helpful? Give feedback.
-
|
Upon first glance, Bob Way, mentioned using synchronizing primitives much like ILP to implement complex smart contract logic and to enable cross-ledger communication without the need for foreign asset "wrapping". ILP synchronizing primitives is to enable multiple parties to read and write to a shared data object in a coordinated and secure manner. This shared data object could be a ledger state, a smart contract, or any other type of data that needs to be shared between multiple parties. The synchronizing primitive ensures that all parties have a consistent view of the data object, even if they are reading or writing to it concurrently. There are several types of synchronizing primitives that can be used in ILP, including: 1. Locks: Locks are used to ensure that only one party can read or write to a shared data object at a time. When a party wants to access the data object, it must first acquire a lock, which prevents other parties from accessing the data until the lock is released. 2. Semaphores: Semaphores are used to coordinate access to a shared data object among multiple parties. A semaphore has a fixed number of "tokens" that can be used to access the data object. When a party wants to access the data, it must first acquire a token from the semaphore. Once a party is done accessing the data, it releases the token back to the semaphore, allowing other parties to access the data. 3. Atomic counters: Atomic counters are used to track the number of times a shared data object has been accessed or modified. An atomic counter ensures that multiple parties can access and modify the counter without interfering with each other, and that the counter value is always consistent across all parties. ILP synchronizing primitives can be used for smart contract logic by enabling multiple parties to read and write to a shared smart contract in a coordinated and secure manner. For example, a smart contract on one ledger could use a semaphore to coordinate access to a shared data object on another ledger. When a party wants to access the shared data, it would acquire a token from the semaphore, ensuring that only a fixed number of parties can access the data at any given time. Once a party is done accessing the data, it would release the token back to the semaphore, allowing other parties to access the data. The escrow feature of ILP could also work providing an extra layer of security for cross-chain transactions, even if the two chains involved do not inherently trust each other. It allows for the safe transfer of assets across different ledgers, with the intermediary connector acting as a trusted third party to ensure that the assets are not released until the transaction is complete and both parties have fulfilled their obligations ILP most universal and can be used to transfer any type of asset, regardless of the underlying technology or blockchain network. However, it requires the use of connectors and payment channels, which can introduce additional complexity and potential points of failure. But it enable seamless asset transfers between different ledgers, without requiring the use of intermediary tokens or specific shared protocols. On the other hand, IBC is a protocol specifically designed for interconnecting different blockchain networks. IBC allows for the transfer of assets and data between blockchains that support the protocol, enabling interoperability and collaboration between different blockchain networks. But IBC relies on a shared set of protocols and standards to ensure compatibility and consistency between the different chains. Both ILP or IBC seems like a superior option to accomplish a cross-chain bridge, with less clunky architecture and fewer points of failure and security risk. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this open draft! Witnesses have to somehow coordinate off-chain. A consumer of such a bridge may see them as a kind of "centralized group" instead of a single centralized entity. The trust needed seems similar to me. I would like to read about specific aspects where the benefits of this proposal outweigh a bridge provided by a single centralized entity without this amendment. Right now, it's hard for me to see how this amendment outweighs the downsides. |
Beta Was this translation helpful? Give feedback.
-
|
Witnesses only need to coordinate off-chain for modifying the bridge (changing the set of witnesses or the reward amount). They do not need to coordinate off-chain for cross-chain transfers. |
Beta Was this translation helpful? Give feedback.
-
|
How do they coordinate whatever needs to be done off chain if they aren’t brought together in the first place? Or know each other as a group. Is Ripple going to coordinate this? And/or run a witness? |
Beta Was this translation helpful? Give feedback.
-
|
A bridge's attestors would know each other as a group but Ripple would have no involvement in the bridge, unless they decide to get involved in a certain bridge. |
Beta Was this translation helpful? Give feedback.
-
|
This question wasn’t specific to any particular bridge. But in general, given the ambiguous nature of whether a witness requires a license depending on jurisdiction. |
Beta Was this translation helpful? Give feedback.
-
|
The needed off-chain coordination seems relevant to me from a consumer point of view of such a bridge. They must somehow decide off-chain who is added/removed from the witnesses list. Regarding necessary trust from a customer this 'centralized' group in control isn't that different from a single entity in my current understanding of this amendment. A single entity providing a bridge could also be run by a consortium like Silkjaer already indicated earlier. As an engineer I have a limited significance talking about regulation issues. According to my recent talks with the regulator in my jurisdiction (central Europe) I highly assume I (or specifically 'the group') would need some kind of license to participate. Mainly, because I would be part of a group accepting/controlling money from 3rd parties making me a financial intermediary (technological neutrality approach). |
Beta Was this translation helpful? Give feedback.
-
|
Hi folks: per the new XLS Contributing process, it is my opinion that we have reached a "well-refined standard." As such, I propose that we move this discussion to a file (via #109) and work on final changes using additional PRs, for better change-tracking. Please comment here if you would like to object to moving this spec/discussion forward in the process into a DRAFT spec. (Note that per the Contributing guidelines, moving a spec into the DRAFT state does not mean any kind of endorsement, nor does it mean that this specification will become adopted. It is solely meant as a mechanism to enable better change tracking using PRs.) |
Beta Was this translation helpful? Give feedback.
-
I realize how this could have seemed like an attack – I am sorry! My point is that ultimately by bridges being trustless, decentralized and open, it circumvents checks that are usually required by regulators – intentionally or not. And if it does that, anyone running such a service will eventually face scrutiny, and the trustlessness and decentralization would be challenged.
I think that as "the witness selection is totally abstracted away from the protocol itself", so could a AML/KYC example. But the witnesses would have to have means to hold (hold back attestations), refund (reject) and eventually maybe even "claw back". Then how AML/KYC is handled is also abstracted away from the protocol itself – but possible. So a) one could easily spin up a sidechain with a bridge, out of the box, if they are confident it's completely legal, or b) they can use the amendment with additional off-chain organization. The latter would question the need for an amendment though.
This is actually also a thing I have considered for Hooks and personal wallet protection. But for this, I don't think a block list in itself would satisfy any regulator. |
Beta Was this translation helpful? Give feedback.
-
|
What about using ILP synchronizing primitives, as Bob Way had mentioned before? What if it was required that each witness server to be held in a Trust with at least 3 Trustees? That way the decentralized is decentralized. All you are trying to do is introduce checks and balances into the decentralization so that these rogue scenarios are as unlikely as possible. I think requiring some sort of governance could accomplish this. Maybe @JoelKatz has some comment on the architecture? |
Beta Was this translation helpful? Give feedback.
-
I didn't take it as an attack, and I do appreciate you bringing up these points.
This is an aside, but as long you brought up hooks and we're talking about motivations... Given the "smart transactor" design of the ledger, adding a new transactor needs to pass some high bars. It can't just be a good idea on it's own, it needs to fit into a coherent whole with the rest of the ledger or we'll end up with a "big ball of mud" of unrelated features. This is especially concerning as different groups add features. Who decides if a well-implemented feature belongs on the ledger? (The answer is validators, I know, but it's still a real problem). But the bar can't be too high or we won't adopt to the fast moving world we live in. That's why I'm really excited about hooks. Hooks is a huge step forward in solving that dilemma. I can add really interesting features without the "big ball of mud" problem. But it's also a motivation for sidechains. I love the idea that people can spin up sidechains and use an existing token with value on that sidechain and either try out new ideas or implement feature that may be good in isolation but may not be a good fit for the ledger itself. I know other people have other valid motivations for this feature, I'm not discounting those, I though it was interesting to point out a common motivation for both hooks and sidechains. |
Beta Was this translation helpful? Give feedback.
-
Can you be more specific about what you had in mind? It's true that ILP could be applied towards the problem of "cross-chain" bridging, but all of the formally specified ILP versions (i.e., ILPv1 and ILPv4) require a |
Beta Was this translation helpful? Give feedback.
-
|
I can't speak for Bob Way and how he might see it working, but here are some possibilities. One possible approach is to leverage decentralized technologies and consensus mechanisms to achieve cross-chain bridging without a central authority. Here are a few ideas on how ILP concepts could be applied in a decentralized manner: Decentralized Connectors: Instead of relying on a single centralized Connector, multiple decentralized Connectors can be deployed across different nodes in a network. These Connectors would act as intermediaries between different ledgers and facilitate the routing of payments. By utilizing consensus mechanisms like distributed ledger technology (DLT), such as blockchain, these Connectors can work collectively to achieve cross-chain bridging. Smart Contracts: Smart contracts, which are self-executing contracts with predefined rules and conditions, can be utilized to automate the process of cross-chain bridging. By deploying smart contracts on different blockchains or ledgers, you can define the conditions and rules for transferring value between them. These smart contracts can interact with the respective blockchain networks to validate and execute transactions, ensuring atomicity and security. Smart contracts can also utilized to enforce specific conditions within the escrow function. For example, the release of funds can be contingent upon the successful completion of predefined ILP-based conditions, such as the verification of a transaction on another blockchain or the confirmation of specific events or data. The smart contract can programmatically validate these conditions and execute the transfer once the conditions are met, ensuring the secure and reliable execution of the cross-chain bridging transaction. Decentralized Oracles: Oracles act as bridges between blockchains and external data sources. They can be utilized to provide real-time information about the state of different ledgers involved in cross-chain bridging. Decentralized oracles can fetch and validate data from multiple sources, ensuring the accuracy and reliability of the information. This information can then be used to trigger and execute cross-chain transactions based on predefined ILP rules. Interoperability Standards: ILP concepts can be incorporated into interoperability standards that are designed to facilitate cross-chain communication and value transfer. These standards can define common protocols, data formats, and APIs that enable different ledgers to interact with each other in a decentralized manner. By adhering to these standards, different blockchain networks can communicate and transfer value without the need for a centralized authority. Multi-signature Escrow: Multi-signature (multisig) technology can be leveraged to create an escrow mechanism involving multiple parties. In this setup, multiple participants, such as the sender, receiver, and a neutral third party, hold a private key each. The funds or assets are locked in a multisig address, requiring a predefined number of signatures to release the funds. This escrow arrangement ensures that all involved parties must agree and validate the transaction before the assets are transferred, providing an added layer of security and trust in cross-chain bridging. Further by incorporating semaphores, the decentralized approaches mentioned earlier can achieve better coordination, resource management, and synchronization in the cross-chain bridging process. Semaphores help maintain order and prevent issues that may arise from concurrent access to shared resources, ensuring the integrity and reliability of the ILP-based system. |
Beta Was this translation helpful? Give feedback.
-
|
A recent case that needs to be discussed is the The hackers utilized a multi-sig bridge powered by Orbit to launder the funds to other chains to avoid regulations & AML efforts put in place. With the bridge, the hackers swapped the stolen $XRP to $KLAY, then swapped to $ETH, then moved to Avalanche and then moved them to Bitcoin.
This brings up an additional case to discuss about the regulatory aspect of bringing native implementation of layer-2 bridges and its practicality. My personal concerns:
|
Beta Was this translation helpful? Give feedback.
-
|
The biggest hack in crypto just occurred this week @ an astounding 34,000,000,000 USD. Bridge: https://www.poly.network/#/ The breakdown of assets minted by the hacker on different chains is as follows:
|
Beta Was this translation helpful? Give feedback.
-
|
@seelabs @WietseWind The morning of July 2, hackers found a vulnerability in the smart contract of the Poly Network cross-chain bridge and minted a large number of tokens. THIS is why getting this architecture right is so critical. Done haphazardly and you could blow up the entire thing. |
Beta Was this translation helpful? Give feedback.
-
|
The architecture of this bridge is remarkably similar to most other bridges in production. There is nothing unique about this bridge really. As long as the set of witness servers are sufficiently large, and they implement good security mechanisms around their private keys (as is standard in crypto), this bridge architecture is fine. We can also in the future develop a light client bridge. There is no need for one bridge to rule them all. Light client bridges get hacked as well btw (binance bridge hack, ibc had a bug, etc). When the light client bridge comes online, we could even have an aggregate bridge, where both bridges have to validate a transfer for it to go through. This would be the most secure. But let's not get hung up here going back and forth forever, shooting ourselves in the foot by never launching a bridge at all. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, but there needs to be no single points of failure. If a hack occurs, there needs to be fail-safes to stop the bleeding, fast. Here are some ideas that come to mind. The AI angle would be a XRPL competitive advantage and could be closed source enabling XRPL to have the safest bridge out there and with a first mover advantage, the largest data set years ahead of the competition. (Like Tesla). AI Anomaly Detection: AI algorithms can analyze transaction data sets to identify patterns and detect anomalies or suspicious activities. By training machine learning models on historical transaction data, the AI system can learn the normal behavior of the bridge and flag any unusual or potentially fraudulent transactions. This can help identify hacking attempts or security breaches at an early stage. AI Fraud Detection: AI models can be trained to identify patterns and indicators of fraudulent activities in transaction data sets. By analyzing various data points, such as transaction amounts, timestamps, and the behavior of involved addresses or accounts, AI algorithms can identify suspicious patterns indicative of fraud. This can help prevent fraudulent transactions from being processed through the cross-chain bridge. AI Predictive Analytics: AI algorithms can leverage transaction data sets to make predictions and anticipate potential security threats. By analyzing historical transaction patterns, the AI system can identify trends and patterns that may indicate future vulnerabilities or risks. This enables proactive security measures to be implemented, reducing the likelihood of successful hacking attempts. Abnormal Activity Detection: Volume triggers can be set to monitor the transaction volume or activity on the bridge. By analyzing historical patterns and expected transaction volumes, abnormal spikes or deviations can be detected. These triggers can serve as an early warning system for potential hacks or security breaches. Transaction Thresholds: Volume triggers can be configured to activate when the transaction volume exceeds a certain threshold. For example, if the transaction volume suddenly increases beyond a predefined limit, the bridge can automatically trigger additional security measures or temporarily halt transactions for further investigation. Transaction Rate Monitoring: Frequency triggers can monitor the rate of transactions or specific types of activities on the bridge. By analyzing the historical transaction rates, any sudden spikes or abnormal frequency can be identified, potentially indicating a hack or unauthorized activity. Threshold-Based Actions: Frequency triggers can be set up to initiate specific actions when the transaction rate exceeds a predefined threshold. For example, if the rate of transactions surpasses a certain limit within a given time period, the bridge can automatically activate additional security measures, such as increasing confirmation requirements or implementing manual approval processes. Witness Server Redundancy: With multiple witness servers, if one server goes offline or becomes compromised, the other witness servers can continue to operate and validate transactions. This redundancy ensures that the bridge remains functional even if some witness servers are unavailable. Consensus Mechanisms: Multiple witness servers can employ consensus mechanisms to collectively agree on the validity of transactions or operations. Consensus protocols like Byzantine fault tolerance or practical Byzantine fault tolerance can be used to ensure agreement among the witness servers, making it difficult for a single malicious server to manipulate the process. Fault Detection and Recovery: Having multiple witness servers increases the ability to detect and recover from faults or attacks. Monitoring systems can identify inconsistencies or suspicious behavior across the witness servers, triggering alerts or initiating recovery processes to mitigate the impact of a potential hack. Distributed Trust: By distributing the responsibility of validation across multiple witness servers, you reduce the need to trust a single entity or server. This helps to prevent collusion or compromise by a single server and strengthens the overall security of the cross-chain bridge. Threshold Signatures: Multiple witness servers can employ threshold signature schemes, where a signature requires a predefined number of witness servers to collectively authorize a transaction. This ensures that no single server has complete control over the signing process, reducing the risk of misuse or compromise. Auditing and Transparency: The presence of multiple witness servers enhances transparency and accountability. Each server can be audited independently, increasing the likelihood of detecting any malicious behavior or vulnerabilities. The transparency provided by multiple witness servers can also foster trust within the community and attract more users to the cross-chain bridge. Emergency Shutdown: In extreme cases, volume triggers can be set to initiate an emergency shutdown of the cross-chain bridge when an unusually high volume of transactions is detected. This mechanism can help prevent further unauthorized activity while allowing the bridge operators or community to assess and address the security issue. |
Beta Was this translation helpful? Give feedback.
-
|
Another one. CRV/ETH Pool hacked and this could be just the beginning. We can't let this happen to XRPL bridge.
|
Beta Was this translation helpful? Give feedback.
-
|
Proposed implementation: XRPLF/rippled#4292 |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to propose that we move this spec to the next step in our development process. I understand there are still legal concerns, and I don't want to minimize these. Since many people and groups help develop the ledger, making decisions is challenging. We try to have a good development process that helps us make good decisions. Our current process with phases for discussion, draft spec, and candidate spec are reasonable and help us make good technical decisions. I'm not sure what the best process is to resolve legal concerns. Still, I think we're in a good place technically I think it's reasonable to move from the discussion phase to a draft spec phase even with the outstanding legal concerns. I'd like to close this discussion on Tuesday, July 4th and open a pull request for a draft standard. I appreciate all of the great feedback everyone has provided. Thank you everyone. |
Beta Was this translation helpful? Give feedback.
-
|
I second this. At a technical level, this is ready to be moved along. Legal concerns should be resolved elsewhere. |
Beta Was this translation helpful? Give feedback.
-
|
I to would prefer this move forward, both as a technical solutions provide forward progress. I would prefer a competing solution to a single option offered to the the market. My only impetus, is simple "get to dev" instances are available at every step, something I would prefer the xumm team would be more proficient at, which they have not delivered an equivalent/better than the "existing team". I would call for further review on the xumm solution (pending their public release) vs a speedy vote to public opinion. I have no technical issue the approach, but do not agree on need to "burn to mint". This could be achieved via multiple other options. +1 to this moving forward and a -1 to xumm to find a equilibrium. |
Beta Was this translation helpful? Give feedback.
-
We're not trying to present a competing solution, we came up with "a solution", an alternative one, we're comfortable with. We have looked at this from most likely an even broader scope than many: we didn't only look at it from a technological standpoint, but also from a compliance and risk based standpoint. The world we operate in isn't purely tech anymore: the tech needs to be reasonably usable in the global regulatory landscape. I think you may have missed the point of us coming up with B2M: the compliance argument. Anything bridge related comes with the regulatory uncertainty or even (depending on jurisdiction) requirements like money transmission services licenses, doubt about bridge operator status, custody rules, and then there's the bridge hack risk (code or config related). B2M is user facing, client side burn, client side proof, client side proof-offering for re-issue, so all compliance related risks, challenges and uncertainties are worked around. Something we feel is worth a lot. We didn't just come up with this and rolled with it. We've been discussing and pivoting for months. Taking the tech, compliance and legal angle into account. |
Beta Was this translation helpful? Give feedback.
-
|
The concern is simply the 'burning' of XRP. I understand why the route chosen has been done so. I like many parts of it, the one way bridge is still concerning a complete solution should be on the table. The ability to complete the loop in your solution needs to be in a XLS (is what I was referring to with my comments). We are still waiting to see the technical solution to the 2nd part of the bridge, which could I assume be done 2 ways. Either using a blackhole that then the ledger can "re-fetch" those locked units or reissue new XRP. The second option then "forces" the XRPL to become a 'uncapped' supply as if something goes wrong in that code the upper supply bound could theoretically then be breached as well. At the moment the two solutions B2M and 38-d have risks at opposite ends. A regulatory risk on the bridge here and B2M has the risk of depleting the available unites on the ledger (we have no idea, how much could be burnt). The other thing I have not seen anyone cover is then linking these two side chains together. |
Beta Was this translation helpful? Give feedback.
-
|
The B2M conversation should also happen on another forum as the concerns are independent of this spec. |
Beta Was this translation helpful? Give feedback.
-
|
If XRPL Labs chooses to move forward with a B2M proposal, I hope they will write and share a new proposed spec so that we can learn and review all the technical details. Looks like the next available number will be XLS-44 ? |
Beta Was this translation helpful? Give feedback.
-
|
Of course we will: like we did for many years we'll share, open source, etc. We have already shared that we would & promised in multiple places 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Burn to Mint isn’t mutually exclusive with XLS38. These are decentralised public blockchains anyone can use. More than one bridge mechanism is possible. As @WietseWind has pointed out, our solution is based on legal constraints. If you are lucky enough to live and work somewhere where you can run a custodial two way bridge with legal immunity and without a money services business license + AML/KYC reporting then please, by all means do. For us this is simply legally impossible. |
Beta Was this translation helpful? Give feedback.
-
|
I am now closing this discussion as I have opened a PR for the draft spec: #118 If you have any additional comments please post them in the PR or open your own PR with proposed changes. |
Beta Was this translation helpful? Give feedback.
-
|
For future readers: see the current version of XLS-38d here. |
Beta Was this translation helpful? Give feedback.
-
Latest version: XLS-38 Cross-Chain Bridge
The initial version follows:
Cross-Chain Bridge
Abstract
A bridge connects two blockchains: a locking chain and an issuing chain (also called a mainchain and a sidechain). Both are independent ledgers, with their own validators and potentially their own custom transactions. Importantly, there is a way to move assets from the locking chain to the issuing chain and a way to return those assets from the issuing chain back to the locking chain: the bridge. This key operation is called a cross-chain transfer. In this proposal, a cross-chain transfer is not a single transaction. It happens on two chains, requires multiple transactions, and involves an additional server type called a "witness".
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 keep in mind 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 other way to get assets into or out of the box. Note that there is no way for the box to "run out of" wrapped assets - it has an infinite supply.
1. Introduction
1.1. Terminology
1.2. The Witness Server
A witness server is an independent server that helps provide proof that an event happened on either the locking chain or the issuing chain. It listens to transactions on one side of the bridge and submits attestations on the other side. This helps affirm that a transaction on the source chain occurred. The witness server is acting as an oracle, providing information to help prove that the assets were moved to the door account on the source chain (to be locked or burned). This then allows the recipient of those assets to claim the equivalent funds on the destination chain.
Since submitting a signature requires submitting a transaction and paying a fee, supporting rewards for signatures is an important requirement. The reward could be higher than the fee, providing an incentive for running a witness server.
1.3. Design Overview
This design proposes: 1 new server type, 3 new ledger objects, and 8 new transactions.
The new server type is:
The new ledger objects are:
BridgeXChainOwnedClaimIDXChainOwnedCreateAccountClaimIDThe new transactions are:
XChainCreateBridgeXChainModifyBridgeXChainCreateClaimIDXChainCommitXChainAddClaimAttestationXChainClaimXChainAccountCreateCommitXChainAddAccountCreateAttestation1.3.1. A Cross-Chain Transfer
1.3.1.1. Primitives
A cross-chain transfer moves assets from the locking chain to the issuing chain, or returns those assets from the issuing chain back to the locking chain. These transfers need some primitives:
Put assets into trust (lock assets) on the locking chain.
Issue or mint wrapped assets on the issuing chain.
Return or burn the wrapped assets on the issuing chain.
On the issuing chain, prove that assets were put into trust on the locking chain.
On the locking chain, prove that assets were returned or burned on the issuing chain.
A way to prevent the same assets from being wrapped multiple times (prevent transaction replay). The proofs that certain events happened on the different chains are public and can therefore theoretically be submitted multiple times. This must be valid only once to wrap or unlock assets.
1.3.1.2. Process
In this scenario, a user is trying to transfer funds from their account on the source chain to their account on the destination chain.
XChainCreateClaimIDtransaction. This creates aXChainOwnedClaimIDledger object. The ledger object must specify the source account on the source chain.XChainCommittransaction on the source chain, attaching the claimed cross-chain claim ID and including a reward amount (SignatureReward) for the witness servers. This locks or burns the asset on the source chain, depending on whether the source chain is a locking or issuing chain. This transaction must be submitted from the same account that was specified when creating the claim ID.XChainAddClaimAttestationtransaction on the destination chain.XChainClaimtransaction for the transferred value on the destination chain.1.3.2. Setting Up a Cross-Chain Bridge
XChainCreateBridgetransactions sent by the door accounts, which creates aBridgeledger object on each chain. Each chain has a door account that controls that end of the bridge on-chain. On one chain, currency is locked and unlocked (the locking chain). On the other chain, currency is minted and burned, or issued and reclaimed (the issuing chain).Bridgeledger object can be modified via theXChainModifyBridgetransaction.SignerListSettransaction) using the witness servers’ signing keys, so that they control the funds that the bridge controls.AccountSettransaction), so that the witness servers as a collective have total control of the bridge.1.3.3. Account Creation
Account creation must happen via a different means. This is because the cross-chain transfer process requires an existing account on the destination chain, so if the user does not have an account on the destination chain, they have no way to transfer funds.
XChainAccountCreateCommittransaction on the source chain. This locks or burns the asset on the source chain, depending on whether the source chain is a locking or issuing chain.XChainAddAccountCreateAttestationtransactions. Since there is noXChainOwnedClaimIDobject on the destination chain to keep track of the attestations, the ledger instead creates aXChainOwnedCreateAccountClaimIDobject upon receiving the first attestation.2. Changes to the XRPL
2.1. On-Ledger Objects
We propose three new objects:
A
Bridgeis a new object that describes a single cross-chain bridge.A
XChainOwnedClaimIDis a new object that describes a single cross-chain claim ID.A
XChainOwnedCreateAccountClaimIDis a new object that describes an account to be created on the issuing chain.2.1.1. The
BridgeobjectThe
Bridgeobject represents one end of a cross-chain bridge and holds data associated with the cross-chain bridge. Bridges are created using theXChainCreateBridgetransaction.The ledger object is owned by the door account and defines the bridge parameters. It is created with a
XChainCreateBridgetransaction, and modified with aXChainModifyBridgetransaction (only the
MinAccountCreateAmountandSignaturesRewardmay be changed). It cannot be deleted. A door account may not own more than oneBridgeobject.Note: The signatures used to attest to chain events are on the
XChainOwnedClaimIDandXChainOwnedAccountCreateClaimIDledger objects, not on this ledger object.2.1.1.1. Fields
A
Bridgeobject has the following fields:LedgerIndexstringHASH256XChainBridgeXChainBridgeXCHAIN_BRIDGESignatureRewardCurrency AmountAMOUNTMinAccountCreateAmountCurrency AmountAMOUNTXChainAccountCreateCountnumberUINT64XChainAccountClaimCountnumberUINT64XChainClaimIDnumberUINT642.1.1.1.1.
LedgerIndexThe ledger index is a hash of a unique prefix for a bridge object, and the fields in
XChainBridge.2.1.1.1.2.
XChainBridgeThe bridge that this object correlates to - namely, the door accounts and the currencies.
This is the identity of the bridge and cannot be changed, as if it were to change, the object would be representing a different bridge.
It is used everywhere where a
XChainBridgefield exists. This is easier for users instead of expecting them to use the ledger object ID.LockingChainDoorstringACCOUNTLockingChainIssueIssueISSUEIssuingChainDoorstringACCOUNTIssuingChainIssueIssueISSUELockingChainDoorThe door account on the locking chain.
LockingChainIssueThe asset that is locked and unlocked on the locking chain.
IssuingChainDoorThe door account on the issuing chain. For a XRP-XRP bridge, this must be the genesis account (the account that is created when the network is first started, which contains all of the XRP).
IssuingChainIssueThe asset that is minted and burned on the issuing chain. For an IOU-IOU bridge, the issuer of the asset must be the door account on the issuing chain, to avoid supply issues.
2.1.1.1.3.
SignatureRewardThe total amount, in XRP, to be rewarded for providing a signature for a cross-chain transfer or for signing for the cross-chain reward. This will be split among the signers.
2.1.1.1.4.
MinAccountCreateAmountThe minimum amount, in XRP, required for a
XChainAccountCreateCommittransaction. If this is not present, theXChainAccountCreateCommittransaction will fail. This field can only be present on XRP-XRP bridges.2.1.1.1.5.
XChainAccountCreateCountA counter used to order the execution of account create transactions. It is incremented every time a successful
XChainAccountCreateCommittransaction is run for the source chain.2.1.1.1.6.
XChainAccountClaimCountA counter used to order the execution of account create transactions. It is incremented every time a
XChainAccountCreateCommittransaction is "claimed" on the destination chain. When the "claim" transaction is run on the destination chain, theXChainAccountClaimCountmust match the value that theXChainAccountCreateCounthad at the time theXChainAccountClaimCountwas run on the source chain. This orders the claims so that they run in the same order that theXChainAccountCreateCommittransactions ran on the source chain, to prevent transaction replay.2.1.1.1.7.
XChainClaimIDThe value of the next
XChainClaimIDto be created.2.1.2. The
XChainOwnedClaimIDobjectThe
XChainOwnedClaimIDledger object represents a unique ID for each cross-chain transfer. It must be acquired on the destination chain before submitting aXChainCommiton the source chain. Its purpose is to prevent transaction replay attacks and is also used as a place to collect attestations from witness servers.A
XChainCreateClaimIDtransaction is used to create a newXChainOwnedClaimID. The ledger object is destroyed when the funds are successfully claimed on the destination chain.2.1.2.1. Fields
A
XChainOwnedClaimIDobject may have the following fields:LedgerIndexstringHASH256XChainBridgeXChainBridgeXCHAIN_BRIDGEOtherChainSourcestringACCOUNTSignatureRewardCurrency AmountAMOUNTXChainClaimAttestationsarrayARRAYXChainClaimIDstringUINT642.1.2.1.1.
LedgerIndexThe ledger index is a hash of a unique prefix for
XChainOwnedClaimIDs, the actualXChainClaimIDvalue, and the fields inXChainBridge.2.1.2.1.2.
XChainBridgeWhich bridge the
XChainClaimIDcorrelates to.2.1.2.1.3.
OtherChainSourceThe account that must send the corresponding
XChainCommiton the source chain. The destination may be specified in theXChainCommittransaction, which means that if theOtherChainSourceisn't specified, another account can try to specify a different destination and steal the funds. This also allows tracking only a single set of signatures, since we know which account will send theXChainCommittransaction.2.1.2.1.4.
SignatureRewardThe total amount to pay the witness servers for their signatures. It must be at least the value of
SignatureRewardin theBridgeledger object.2.1.2.1.5.
XChainClaimAttestationsAttestations collected from the witness servers. This includes the parameters needed to recreate the message that was signed, including the amount, which chain (locking or issuing), optional destination, and reward account for that signature.
See the
XChainAddClaimAttestationsection for more details on what this looks like.2.1.2.1.6.
XChainClaimIDThe unique sequence number for a cross-chain transfer.
2.1.3. The
XChainOwnedCreateAccountClaimIDobjectThe
XChainOwnedCreateAccountClaimIDledger object is used to collect attestations for creating an account via a cross-chain transfer. It is created when aXChainAddAccountCreateAttestationtransaction adds a signature attesting to aXChainAccountCreateCommittransaction and theXChainAccountCreateCountis greater than or equal to the currentXChainAccountClaimCounton theBridgeledger object. It is destroyed when all the attestations have been received and the funds have transferred to the new account.2.1.3.1. Fields
A
XChainOwnedCreateAccountClaimIDobject may have the following fields:LedgerIndexstringHASH256XChainBridgeXChainBridgeXCHAIN_BRIDGEXChainAccountCreateCountnumberUINT64XChainCreateAccountAttestationsarrayARRAY2.1.3.1.1.
LedgerIndexThe ledger index is a hash of a unique prefix for
XChainOwnedCreateAccountClaimIDs, theXChainAccountCreateCount, and the fields inXChainBridge.2.1.3.1.2.
XChainBridgeDoor accounts and assets.
2.1.3.1.3.
XChainAccountCreateCountAn integer that determines the order that accounts created through cross-chain transfers must be performed. Smaller numbers must execute before larger numbers.
2.1.3.1.4.
XChainCreateAccountAttestationsAttestations collected from the witness servers. This includes the parameters needed to recreate the message that was signed, including the amount, destination, signature reward amount, and reward account for that signature. With the exception of the reward account, all signatures must sign the message created with common parameters.
See the
XChainAddAccountCreateAttestationsection for more details on what this looks like.2.2. Transactions Controlling The Bridge
2.2.1. The
XChainCreateBridgetransactionThe
XChainCreateBridgetransaction creates a newBridgeledger object. This tells one chain (whichever chain the transaction is submitted on) the details of the bridge.The transaction must be submitted by the door account. It must also be submitted on both chains that form the bridge in order to be a valid bridge. A door account may own at most one bridge object.
2.2.1.1. Fields
The
XChainCreateBridgetransaction contains the following fields:XChainBridgeXChainBridgeXCHAIN_BRIDGESignatureRewardCurrency AmountAMOUNTMinAccountCreateAmountCurrency AmountAMOUNT2.2.1.1.1.
XChainBridgeWhich bridge (door accounts and issues) to create.
2.2.1.1.2.
SignatureRewardThe signature reward split between the witnesses for submitting attestations.
2.2.1.1.3.
MinAccountCreateAmountThe minimum amount, in XRP, required for a
XChainAccountCreateCommittransaction. If this is not present, theXChainAccountCreateCommittransaction will fail. This field can only be present on XRP-XRP bridges.2.2.2. The
XChainModifyBridgetransactionThe
XChainModifyBridgetransaction allows bridge managers to modify the parameters of the bridge. They can only change theSignatureRewardand theMinAccountCreateAmount. This is because changing the door accounts or assets would essentially be creating a new bridge as opposed to modifying an existing one.Note that this is a regular transaction that is sent by the
door account and requires the entities that control the witness servers to coordinate and provide the signatures for this transaction. This coordination happens outside the ledger.
Note that the signer list for the bridge is not modified through this transaction. The signer list is on the door account itself and is changed in the same way signer lists are changed on accounts (via a
SignerListSettransaction).2.2.2.1. Fields
The
XChainModifyBridgetransaction contains the following fields:XChainBridgeXChainBridgeXCHAIN_BRIDGESignatureRewardCurrency AmountAMOUNTMinAccountCreateAmountCurrency AmountAMOUNTFlagsnumberUINT322.2.2.1.1.
XChainBridgeWhich bridge (door accounts and issues) to modify.
2.2.2.1.2.
SignatureRewardThe signature reward split between the witnesses for submitting attestations.
2.2.2.1.3.
MinAccountCreateAmountThe minimum amount, in XRP, required for a
XChainAccountCreateCommittransaction. If this is not present, theXChainAccountCreateCommittransaction will fail. This field can only be present on XRP-XRP bridges.2.2.2.1.4.
FlagsSpecifies the flags for this transaction. In addition to the universal transaction flags that are applicable to all transactions (e.g.,
tfFullyCanonicalSig), the following transaction-specific flags are defined:tfClearAccountCreateAmount0x00010000MinAccountCreateAmountof the bridge.2.3. Transactions for Cross-Chain Transfers
2.3.1. The
XChainCreateClaimIDtransactionThe
XChainCreateClaimIDtransaction is the first step in a cross-chain transfer. The claim ID must be created on the destination chain before theXChainCommittransaction (which must reference this number) can be sent on the source chain. The account that will send theXChainCommiton the source chain must be specified in this transaction (see note on theOtherChainSourcefield in theXChainOwnedClaimIDledger object forjustification). The actual claim ID must be retrieved from a validated ledger.
2.3.1.1. Fields
The
XChainCreateClaimIDtransaction contains the following fields:XChainBridgeXChainBridgeXCHAIN_BRIDGESignatureRewardCurrency AmountAMOUNTOtherChainSourcestringACCOUNT2.3.1.1.1.
XChainBridgeWhich bridge to create the
XChainOwnedClaimIDfor.2.3.1.1.2.
SignatureRewardThe amount, in XRP, to be used to reward the witness servers for providing signatures. This must match the amount on the
Bridgeledger object.This could be optional, but it is required so the sender can be made positively aware that these funds will be deducted from their account.
2.3.1.1.3.
OtherChainSourceThe account that must send the
XChainCommittransaction on the source chain.Since the destination may be specified in the
XChainCommittransaction, if theOtherChainSourcewasn't specified, another account could try to specify a different destination and steal the funds.This also allows us to limit the number of attestations that would be considered valid, since we know which account will send the
XChainCommittransaction.2.3.2. The
XChainCommittransactionThe
XChainCommittransaction is the second step in a cross-chain transfer. It puts assets into trust on the locking chain so that they may be wrapped on the issuing chain, or burns wrapped assets on the issuing chain so that they may be returned on the locking chain.2.3.2.1. Fields
The
XChainCommittransaction contains the following fields:XChainBridgeXChainBridgeXCHAIN_BRIDGEXChainClaimIDstringUINT64AmountCurrency AmountAMOUNTOtherChainDestinationstringACCOUNT2.3.2.1.1.
XChainBridgeWhich bridge to use to transfer funds.
2.3.2.1.2.
XChainClaimIDThe unique integer ID for a cross-chain transfer.
This must be acquired on the destination chain (via a
XChainCreateClaimIDtransaction) and checked from a validated ledger before submitting this transaction.If an incorrect sequence number is specified, the funds will be lost.
2.3.2.1.3.
AmountThe asset to commit, and the quantity.
This must match the door account's
LockingChainIssue(if on the locking chain) or the door account'sIssuingChainIssue(if on the issuing chain).2.3.2.1.4.
OtherChainDestinationThe destination account on the destination chain.
If this is not specified, the account that submitted the
XChainCreateClaimIDtransaction on the destination chain will need to submit aXChainClaimtransaction to claim the funds.2.3.3. The
XChainAddClaimAttestationtransactionThe
XChainAddClaimAttestationtransaction provides an attestation from a witness server attesting to aXChainCommittransaction on the other chain.The signature must be from one of the keys on the door's signer list at the time the signature was provided. However, if the signature list changes between the time the signature was submitted and the quorum is reached, the new signature set is used and some of the currently collected signatures may be removed. Note that the reward is only sent to accounts that have keys on the current list.
Note: Any account can submit signatures. This is important to support witness servers that work on the "subscription" model (see the
Witness Serversection for more details).Note: A quorum of signers need to agree on the
SignatureReward, the same way they need to agree on the other data. A single witness server cannot provide an incorrect value for this in an attempt to collect a larger reward.2.3.3.1. Fields
The
XChainAddClaimAttestationtransaction contains the following fields:AmountCurrency AmountAMOUNTAttestationRewardAccountstringACCOUNTAttestationSignerAccountstringACCOUNTDestinationstringACCOUNTOtherChainSourcestringACCOUNTPublicKeystringBLOBSignaturestringBLOBWasLockingChainSendnumberUINT8XChainBridgeXChainBridgeXCHAIN_BRIDGEXChainClaimIDstringUINT642.3.3.1.1.
AmountThe amount committed via the
XChainCommittransaction on the source chain.2.3.3.1.2.
AttestationRewardAccountThe account that should receive this signer's share of the
SignatureReward.2.3.3.1.3.
AttestationSignerAccountThe account on the door account's signer list that is signing the transaction. Normally, the public key would be equivalent to the master key of the account. However, there is also the option of creating the account on the chain and setting a regular key, and using that key to sign attestations on behalf of the signer account.
2.3.3.1.4.
DestinationThe destination account for the funds on the destination chain (taken from the
XChainCommittransaction).2.3.3.1.5.
OtherChainSourceThe account on the source chain that submitted the
XChainCommittransaction that triggered the event associated with the attestation.2.3.3.1.6.
PublicKeyThe public key used to verify the attestation signature.
2.3.3.1.7.
SignatureThe signature attesting to the event on the other chain.
2.3.3.1.8.
WasLockingChainSendA boolean representing the chain where the event occurred.
2.3.3.1.9.
XChainBridgeThe bridge associated with the attestations.
2.3.3.1.10.
XChainClaimIDThe
XChainClaimIDassociated with the transfer, which was included in theXChainCommittransaction.2.3.3.2. Implementation Details
To add an attestation to a
XChainOwnedClaimID, that ledger object must already exist.2.3.4. The
XChainClaimtransactionThe
XChainClaimtransaction allows the user to claim funds on the destination chain from aXChainCommittransaction.This is normally not needed, but may be used to handle transaction failures or if the destination account was not specified in the
XChainCommittransaction. It may only be used after a quorum of signatures have been sent from the witness servers.If the transaction succeeds in moving funds, the referenced
XChainOwnedClaimIDledger object will be destroyed. This prevents transaction replay. If the transaction fails, theXChainOwnedClaimIDwill not be destroyed and the transaction may be re-run with different parameters.2.3.4.1. Fields
The
XChainClaimtransaction contains the following fields:XChainBridgeXChainBridgeXCHAIN_BRIDGEXChainClaimIDstringUINT64DestinationstringACCOUNTDestinationTagintUINT32AmountCurrency AmountAMOUNT2.3.4.1.1.
XChainBridgeThe bridge associated with this transfer.
2.3.4.1.2.
XChainClaimIDThe unique integer ID for a cross-chain transfer that was referenced in the relevant
XChainCommittransaction.2.3.4.1.3.
DestinationThe destination account on the destination chain. It must exist or the transaction will fail. However, if the transaction fails in this case, the sequence number and collected signatures will not be destroyed and the transaction may be rerun with a different destination address.
2.3.4.1.4.
DestinationTagAn integer destination tag.
2.3.4.1.5.
AmountThe amount to claim on the destination chain.
This must match the amount attested to on the attestations associated with this
XChainClaimID.2.4. Transactions for Account Creation
Since the cross-chain transfer process requires an existing account on the destination chain, if the user does not have an account on the destination chain, they have no way to transfer funds. With a sidechain, there are no user accounts when the chain is first created. Therefore, account creation requires a special mechanism and special transactions.
2.4.1. The
XChainAccountCreateCommittransactionThe
XChainAccountCreateCommittransaction is a special transaction used for creating accounts through a cross-chain transfer.A normal cross-chain transfer requires a
XChainClaimID(which requires an existing account on the destination chain). One purpose of theXChainClaimIDis to prevent transaction replay. For this transaction, we use a different mechanism: the accounts must be claimed on the destination chain in the same order that theXChainAccountCreateCommittransactions occurred on the source chain.This transaction can only be used for XRP-XRP bridges.
IMPORTANT: This transaction should only be enabled if the witness attestations will be reliably delivered to the destination chain. If the signatures are not delivered, then account creation will be blocked until the one waiting on attestations receives its attestations. This could be used maliciously. To disable this transaction on XRP-XRP bridges, the bridge's
MinAccountCreateAmountshould not be present.Note: If this account already exists, the XRP is transferred to the existing account. However, note that unlike the
XChainCommittransaction, there is no error handling mechanism. If the claim transaction fails, there is no mechanism for refunds (except manually, via the witness signing keys on the door accounts' signer list). The funds are essentially permanently lost. This transaction should therefore only be used for account creation.2.4.1.1. Fields
The
XChainAccountCreateCommittransaction contains the following fields:XChainBridgeXChainBridgeXCHAIN_BRIDGESignatureRewardCurrency AmountAMOUNTDestinationstringACCOUNTAmountCurrency AmountAMOUNT2.4.1.1.1.
XChainBridgeThe bridge to use to transfer funds.
2.4.1.1.2.
SignatureRewardThe amount, in XRP, to be used to reward the witness servers for providing signatures.
This must match the amount on the
Bridgeledger object.This could be optional, but it is required so the sender can be made positively aware that these funds will be deducted from their account.
2.4.1.1.3.
AmountThe amount, in XRP, to use for account creation. This must be greater than or equal to the
MinAccountCreateAmountspecified in theBridgeledger object.2.4.1.1.4.
DestinationThe destination account on the destination chain.
2.4.2. The
XChainAddAccountCreateAttestationtransactionThe
XChainAddAccountCreateAttestationtransaction provides an attestation from a witness server attesting to aXChainAccountCreateCommittransaction on the other chain.The signature must be from one of the keys on the door's signer list at the time the signature was provided. However, if the signature list changes between the time the signature was submitted and the quorum is reached, the new signature set is used and some of the currently collected signatures may be removed. Note that the reward is only sent to accounts that have keys on the current list.
Note: Any account can submit signatures. This is important to support witness servers that work on the "subscription" model (see the
Witness Serversection for more details).Note: A quorum of signers need to agree on the
SignatureReward, the same way they need to agree on the other data. A single witness server cannot provide an incorrect value for this in an attempt to collect a larger reward.2.4.2.1. Fields
The
XChainAddAccountCreateAttestationtransaction contains the following fields:AmountCurrency AmountAMOUNTAttestationRewardAccountstringACCOUNTAttestationSignerAccountstringACCOUNTDestinationstringACCOUNTOtherChainSourcestringACCOUNTPublicKeystringBLOBSignaturestringBLOBSignatureRewardCurrency AmountAMOUNTWasLockingChainSendnumberUINT8XChainAccountCreateCountstringUINT64XChainBridgeXChainBridgeXCHAIN_BRIDGE2.4.2.1.1.
AmountThe amount committed via the
XChainAccountCreateCommittransaction on the source chain.2.4.2.1.2.
AttestationRewardAccountThe account that should receive this signer's share of the
SignatureReward.2.4.2.1.3.
AttestationSignerAccountThe account on the door account's signer list that is signing the transaction. Normally, the public key would be equivalent to the master key of the account. However, there is also the option of creating the account on the chain and setting a regular key, and using that key to sign attestations on behalf of the signer account.
2.4.2.1.4.
DestinationThe destination account for the funds on the destination chain.
2.4.2.1.5.
OtherChainSourceThe account on the source chain that submitted the
XChainAccountCreateCommittransaction that triggered the event associated with the attestation.2.4.2.1.6.
PublicKeyThe public key used to verify the signature.
2.4.2.1.7.
SignatureThe signature attesting to the event on the other chain.
2.4.2.1.8.
SignatureRewardThe signature reward paid in the
XChainAccountCreateCommittransaction.2.4.2.1.9.
WasLockingChainSendA boolean representing the chain where the event occurred.
2.4.2.1.10.
XChainAccountCreateCountThe counter that represents the order that the claims must be processed in.
2.4.2.1.11.
XChainBridgeThe bridge associated with the attestation.
2.4.2.2. Implementation Details
Since
XChainOwnedCreateAccountClaimIDis ordered, it's possible for this object to collect a quorum of signatures but not be able to execute yet. As a result, the witness servers are designed to always deliver attestations in order. Therefore, in practice, this object should not be able to collect a quorum of attestations without being able to execute yet.However, if this situation should occur (e.g. via a buggy witness server), then the object will not execute yet and another attestation will need to be sent to the object in order to execute it. In this case, it is okay to send an attestation that is already on the object.
3. The Witness Server
A witness server helps provide proof that some event happened on either the locking chain or the issuing chain. It does not validate transactions and does not need to coordinate with other witness servers. Instead, it listens to transactions from the chains. When it detects an event of interest on the source chain, it creates an attestation (a signed message) and uses the
XChainAddClaimAttestationorXChainAddAccountCreateAttestationtransactions to submit their attestation for the event to the destination chain. When a quorum of signatures are collected on the destination chain, the funds are released.Since submitting a signature requires submitting a transaction and paying a fee, supporting rewards for signatures is an important requirement. The reward could be higher than the fee, providing an incentive for running a witness server.
It is possible for a witness server to provide attestations for one chain only - and it is possible for the door account on the locking chain to have a different signer's list than the door account on the issuing chain. The initial implementation of the witness server assumes it is providing attestation for both chains, however it is desirable to allow witness servers that only know about one of the chains.
The current design envisions two models for how witness servers are used:
The servers are completely private. They submit transactions to the chains themselves and collect the rewards themselves. Allowing the servers to be private has the advantage of greatly reducing the attack surface on these servers. They won't have to deal with adversarial input to their RPC commands, and since their ip address will be unknown, it will be hard to mount an DOS attack.
The witness server monitors events on a chain, but does not submit their signatures themselves. Instead, another party will pay the witness server for their signature (for example, through a subscription fee), and the witness server allows that party to collect the signer's reward. The account that receives the signature reward is part of the message that the witness server signs.
Note: since submitting a signature requires submitting a transaction and paying a fee, supporting rewards for signatures is an important requirement. Of course, the reward can be higher than the fee, providing an incentive to run a witness server.
3.1. The Server Code
The witness server code is currently available here. However, the official repo will likely move to the XRPLF Github org if this proposal is accepted.
3.2. Witness Configuration
The witness configuration is stored in a file called
witness.json.3.2.1. Fields
LockingChainobjectIssuingChainobjectRPCEndpointobjectLogFilestringLogLevelstringDBDirstringSigningKeySeedstringSigningKeyTypestringXChainBridgeXChainBridge3.2.1.1.
LockingChainThe parameters for interacting with the locking chain.
EndpointobjectTxnSubmitobjectRewardAccountstring3.2.1.1.1.
EndpointThe websocket endpoint of a
ripplednode synced with the locking chain.The fields are as follows:
IPstringPortstringIPThe IP address of the
ripplednode.Note: This does not accept URLs right now.
PortThe port used for the websocket endpoint.
3.2.1.1.2.
TxnSubmitThe parameters for transaction submission on the locking chain.
ShouldSubmitbooleanSigningKeySeedstringSigningKeyTypestringSubmittingAccountstringShouldSubmitA boolean indicating whether or not the witness server should submit transactions on the locking chain.
For the subscription model, the witness server should not submit transactions.
SigningKeySeedThe seed that the witness server should use to sign its transactions on the locking chain. This is required if
ShouldSubmitistrue.SigningKeyTypeThe algorithm used to encode the
SigningKeySeed. The options aresecp256k1anded25519. This is required ifShouldSubmitistrue.SubmittingAccountThe account from which the
XChainAddClaimAttestationandXChainAddAccountCreateAttestationtransactions should be sent. This is required ifShouldSubmitistrue.3.2.1.1.1.
RewardAccountThe account that should receive the witness's share of the
SignatureRewardon the locking chain.3.2.1.2.
IssuingChainThe parameters for interacting with the issuing chain. This is identical to the
LockingChainsection.3.2.1.3.
RPCEndpointThe endpoint for RPC requests to the witness server.
IPstringPortstring3.2.1.3.1.
IPThe IP address for the endpoint.
3.2.1.3.2.
PortThe port for the endpoint.
3.2.1.4.
LogFileThe location of the log file.
3.2.1.5.
LogLevelThe level of logs to store in the log file. The options are
["All", "Trace", "Debug", "Info", "Warning", "Error", "Fatal", "Disabled","None"].3.2.1.6.
DBDirThe location of the directory where the databases are stored.
3.2.1.7.
SigningKeySeedThe seed that the witness server should use to sign its attestations.
3.2.1.8.
SigningKeyTypeThe algorithm used to encode the
SigningKeySeed. The options aresecp256k1anded25519.3.2.1.9.
XChainBridgeThe bridge that the witness server is monitoring. This is identical to the
XChainBridgeparams in every transaction and ledger object.3.3. Running a Witness Server
After downloading and building the code, run:
Further details are available in the README of the repo.
3.3.1. Server Specs
The witness server is pretty lightweight, so it likely doesn't need very high specs. However, this has not been tested.
3.3.2. Best Practices
In a production environment, a witness server should use different keys for each of signing attestations, signing locking chain transactions, and signing issuing chain transactions. This adds security and helps avoid transaction replay attack issues.
4. How to Build a Bridge
4.1. Setting Up a New Sidechain (AKA Building a XRP-XRP Bridge)
Setting up a new issuing chain with a XRP-XRP bridge is somewhat complex, because there are no accounts on the issuing chain, even for witnesses. As a result, witnesses cannot directly submit
XChainAddClaimAttestationorXChainAddAccountCreateAttestationtransactions.Once the new network is set up and active (in other words, the validators are running and are successfully closing ledgers):
XChainCreateBridgetransaction on the locking chain from the door account.SignerListSetfor ease of setup.MinAccountCreateAmountvalue should be at minimum the account reserve on the issuing chain.SignerListSettransaction on the locking chain from the door account, with the witnesses' signing keys as the signers.AccountSettransaction.XChainCreateBridgetransaction on the issuing chain from the door account. This door account already exists, since it must be the genesis account.XChainAccountCreateCommittransactions from account(s) that have enough funds, to create each of the witnesses' submission accounts on the issuing chain.XChainAccountCreateCommittransactions in step 6. These attestations should be signed by the genesis seed, since that is currently what controls the genesis account.XChainAddAccountCreateAttestationtransaction for each of the attestations from step 7 on the issuing chain, with the genesis account.SignerListSettransaction on the issuing chain from the door account, with the witnesses' signing keys as the signers.AccountSettransaction.The bridge is now set up and can be used normally.
4.2. Building an IOU-IOU Bridge
Any two networks that have an IOU-IOU bridge between them should already have a XRP-XRP bridge between them, as a sidechain will need XRP for account reserves and transaction fees (while this could be changed, in that case the
XChainBridgeamendment code could also be modified). This makes it simpler to set up an IOU-IOU bridge.To set up an IOU-IOU bridge:
XChainCreateBridgetransaction on the locking chain from the door account.SignerListSetfor ease of setup.MinAccountCreateAmountvalue should not be included.SignerListSettransaction on the locking chain from the door account, with the witnesses' signing keys as the signers.AccountSettransaction.XChainCreateBridgetransaction on the issuing chain from the door account.SignerListSettransaction on the issuing chain from the door account, with the witnesses' signing keys as the signers.AccountSettransaction.The bridge is now set up and can be used normally.
5. Security
5.1. Trust Assumptions
The witness servers are trusted, and if a quorum of them collude they can steal funds from the door account.
5.1.1. Use of the Signer List
The public keys that the witness servers use must match the public keys on that door's signer's list. But this isn't the only way to implement this. A bridge ledger object could contain a signer list that's independent from the door account. The reasons for using the door account's signers list are:
The bridge signers list can be used to move funds from the account. Putting this list on the door account emphasizes this trust model.
It allows for emergency action. If something goes very, very wrong, funds could still be moved if the entities on the signer list sign a regular
Paymenttransaction.It's a more natural way to modify bridge parameters.
5.2. Transaction Replay Attacks
Normally, account sequence numbers prevent transaction replay on the XRP Ledger. However, this bridge design allows funds to move from an account via transactions not sent by that account (namely, the attestations submitted by the witness servers). All the information to replay these transactions are publicly available. This section describes how the different transactions prevent certain attacks - including transaction replay attacks.
To successfully run a
XChainClaimtransaction, the account sending the transaction must own theXChainOwnedClaimIDledger object referenced in the witness server's attestation. Since this ledger object is destroyed when the funds are successfully moved, the transaction cannot be replayed.To successfully create an account with the
XChainAccountCreateCommittransaction, the ordering number must match the current order number on the bridge ledger object. After the transaction runs, the order number on the bridge ledger object is incremented. Since this number is incremented, the transaction can not be replayed since the order number in the transaction will never match again.Since the
XChainCommitcan contain an optional destination account on the destination chain, and the funds will move when the destination chain collects enough signatures, one attack would be for an account to watch for aXChainCommitto be sent and then send their ownXChainCommitfor a smaller amount. This attack doesn't steal funds, but it does result in the original sender losing their funds. To prevent this, when aXChainOwnedClaimIDis created on the destination chain, the account that will send theXChainCommiton the source chain must be specified. Only the attestations from this transaction will be accepted on theXChainOwnedClaimID.5.3. Error Handling
5.3.1. Error Handling for Cross-Chain Transfers
Error handling for cross-chain transfers is straightforward. The
XChainOwnedClaimIDis only destroyed when a claim succeeds. If it fails for any reason (for example, if the destination account doesn't exist or has deposit auth set), then an explicitXChainClaimtransaction may be submitted to redirect the funds.5.3.2. Error Handling for Cross-Chain Account Creates
If a cross-chain account create fails, the recovery of funds must happen outside the rules of the bridge system. The only way to recover them would be if the witness servers created a
Paymenttransaction themselves. This is unlikely to happen and should not be relied upon. TheMinAccountCreateAmounton theBridgeobject is meant to prevent these transactions from failing due to having too little XRP.5.3.3. Error Handling for Signature Reward Delivery
If the signature reward cannot be delivered to the specified account, that portion of the signature reward is kept by the account that owns the
XChainOwnedClaimID.Appendix
Appendix A: Alternate Account Create Design: Undeletable Accounts
In a normal cross-chain transfer, the claim ID is used to prevent transaction replay. However, the account create design does not use claim IDs. Instead, it requires that accounts be created in the same order as the "commit" transactions.
There is another way to prevent transaction replay - check if the account to be created already exists. If it does, reject the transaction. The only problem with this is that accounts on the XRP ledger are deletable, and an easy attack would be to delete the account and replay the transaction.
To prevent this, a design was considered where accounts created through cross-chain "account create" transactions would be undeletable. This has the nice property that the attestations no longer need to be added in order. However, it also introduces a new property on
AccountRoots that interacts with existing functionality.In the end, this proposal chose to pursue the "execution ordering" strategy. However, the undeletable account strategy is a viable solution with a different set of tradeoffs.
Appendix B: Alternate Designs
One alternate design that was implemented involved a set of servers similar to the witness servers called "federators". These servers communicated among themselves, collected signatures needed to submit transactions on behalf of the door accounts directly, and submitted those transactions.
This design is attractive from a usability point of view. There is no "cross-chain sequence number" that needs to be obtained on the destination chain, and creating accounts using cross-chain transfers is straightforward.
The main disadvantage of this design is the complexity in the federators. In order to submit a transaction, the federators need to agree on a transaction's sequence number and fees. This requires the federators to stay in "sync" with each other and requires that these federators be much more complex than the "witness" servers proposed in this design.
In addition, handling fee escalation, failed transactions, and servers falling behind was much more complex.
Finally, because all the transactions were submitted from the same account (the door account), this presented a challenge for transaction throughput as the XRP ledger limits the number of transactions an account can submit in a single ledger.
Beta Was this translation helpful? Give feedback.
All reactions