Have some questions.

Thanks for the thoughtful questions!

1. Should the addition/removal of these witness servers not happen though a vote mechanism from via the I'LL? has pros and cons, but asking the question.

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).

2. Accounting of what XRP has move to which chain, should be easily done and a trivial look up. Something like the way we can see the escrow total on an account.

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.

3. Would like to see more documentation and explanation around "**disaster case(s)**" there are many, other chain stopped consense what happens here. Other chain was hacked should there be any means to recovery on this chain? Again could see a UNL vote on releasing those "locked" funds as a path forward if the circumstances were right.

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.

4. Witness Server, not a fan of incentive option here, but its an option. However a default of simply using the _GAS fee_ on the opposite side is what i would look to.

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.

5. Another thing that could also be part of the base spec here and a great safety feature. Is a force key rotation on the witness server, eg. it needs to change its key(s) every x days/months.

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).

6. Witness Servers could also possibly fill a role of a basic cross chain API. Just returning the result balance on the mainnet of the balance on a side chain wallet would be fantastic. Meaning i query the main chain for the balance on the side chain. Feel this basic request also should be part of this spec.

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.

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

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.

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.

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.

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.

With regard to the GAS fee and rewards question. My position on rewards and oracles is they should not mix.

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 !

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!

@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.

Thank you for this standards draft!

@Silkjaer Thank you for your insightful comments!

Many existing cross-chain bridges functions using exchange-like deposits (with some variation): Inform the bridge that money will come and where it should be delivered on the other chain (on a website), send an amount to an address with a destination tag (payment), wait for money to be delivered on the other chain (delivery). These designs are unfavorable for many reasons, e.g. error handling, however also very favorable for the ease of use. The XLS38d design has a similar design pattern, however it works with on-chain transactions: XChainCreateClaimID to get a "deposit address and destination tag", XChainCommit to send the money instead of payment. This design makes it impossible to use for users with money in custody (on exchanges) – and even if exchanges were to implement a way to do it, they would expose users to misuse of XChainClaim attacks. Can this be circumvented to be more inclusive? Do you have any statistics on “custody users” vs native users?

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.

Rewards/incentives are introduced for witness servers. Since witness servers has to send attestations, they need to have those costs covered, but could providing incentive to witnesses create a situation where they are not agnostic to the transaction itself?

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 ModifyBridge transaction). Still, as long as the old reward amount was enough to cover fees the witness servers should be motivated to provide attestations.

The design implies that SignerListSet transactions should be used to update the witness server lists on the locking account. So to also change this, the witnesses has to internally coordinate (off-chain) and submit a new SignerListSet. This also means that the locking account can be used as a regular account for witnesses, if they should choose to collude, if there are undetected attack vectors in the witness server design or are attacked or otherwise have their secrets exposed.

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.

It seems the bridge is set up to be as decentralized as possible (up to 32 witnesses, with the SignerList expansion amendment). I believe the first and foremost superpower of decentralization is eliminating the need for trust, but that it has often and mistakenly also been used as an excuse to abdicate responsibility (“I can't control it, so it's not my responsibility”). However the design implies that witness servers has to be able to organise internally off chain, to make changes to the door accounts, adding and removing witnesses etc., so while many witnesses are less likely to collude, they are still very much organised. If they are not very much organised, the bridge is very much vulnerable, as removing and adding witnesses will become increasingly difficult. So by this logic, witnesses can help eliminate the need for trust, but as an organised group, who defacto owns the locking account, they can't abdicate responsibility?

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 read elsewhere that "the burden is on the participants of the issuing chain to evaluate the reliability of witness servers". This has to imply that witnesses (the entities), are somehow public. Otherwise the reliability is solely based on metrics? Users, using the bridge, would also benefit from knowing who witnesses are, to individually assess whether they can trust them not to collude (a signer list could include 32 witnesses controlled by the same entity).

I would expect the identity of the entities running the witness servers to be public, yes.

If witness servers are being paid by unknown entities (rewards) to move money, they are facing all sorts of legal exposure (subject to jurisdiction) as money transmitters?

I'm going to defer the answer to this to others. I'm an engineer, I shouldn't comment on legal questions.

Thank you for the in-depth answers!

You mention error handling as a weakness this and similar designs

I actually meant to say that error handling is a weakness of the existing bridges, and XLS38d is a huge improvement on that 👏

any design is going to require some primitive to move funds - compromise that primitive and it's also "game over"

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.

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.

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 XChainAddAttestation transaction. Could you tell me the difference between the proposed XChainAddAttestation transaction and a normal multi-sig transaction in terms of storage used on the ledger in a FH setting?

@wojake: it sounds like you have a clear understanding of the trade-offs between the two designs.

1. We could have a design where no new ledger objects or transactions are required on the ledger. The witness servers can submit payment transaction themselves using multi-sigs and a transaction's memo fields can be used for additional information like side chain destination accounts. This adds no new complexity to the ledger, but requires witness servers that act as distributed systems that need to come to agreement on certain transaction values - like sequence numbers and fees. Let's call this "dsystem witnesses".

2. We could have a design like the one proposed in this document. There are new transactions and ledger objects, witness server attestations are collected on-ledger, and the witness server can act independently. Let's call this "standalone witnesses".

• Looking at ledger complexity, "dsystem witnesses" is hard to beat as it requires no changes to the ledger at all. It would require two transactions to complete a cross-chain transaction, and importantly would not require an account on the destination chain to own a "claim id".

• Looking at ledger size, "dsystem witnesses" also wins. "standalone witnesses" requires collecting signatures on-ledger with requires storing them while the transaction is in flight and it also requires one transaction per attestation in the current design (although I do have a design for "batch attestations" that mitigates this). Note that the attestations only live on ledger while the cross-chain transaction is in flight, which should be a short amount of time.

• Looking at witness server complexity, "standalone witnesses" is the clear winner here. Submitting a single transaction signed by all the witness servers requires communication among the witness servers and requires coming to agreement on sequence numbers and fees. Agreeing on sequence numbers is mostly straight forward, with the exception that non-cross-chain transactions need to be handled specially, through tickets for example. Fees are trickier than sequence numbers. If fee escalation kicks in, the witness servers need to agree on what the new fees should be. Since this is a distributed system, this would require some consensus mechanism. I don't have a specific solution to propose for the "fee" problem, other than to note, yes, it's a solvable problem, but it also requires making the witness servers relatively complex to do so. Handling errors is also more complex using "dsystem witnesses".

• Looking at usability it's mixed. Using existing transactions for cross-chain transactions can be error prone. However, requiring the user to own a "claim id" also adds complexity. In both cases wallet software can help hide this complexity.

servers falling behind: this may be an issue if the servers (nodes) are either unstable or not powerful enough to perform as expected

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.

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 heart !

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.

If I'm not mistaken, @cjcobb23's suggestion would essentially make the XRPL a layer-0 network? Or am I just using crypto gibberish 😆

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?

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:

1. It's an external program that listens to the other chain and sends information to the mainchain, like the witness servers in this proposal.
2. It's built into the XRPL server and a server pushes this information to the other chain.
3. It's build into the XRPL server and a server pulls this information from the other chain.

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:

1. It's presented as a transaction and lives on the ledger. This is what the current proposal does.
2. It's broadcast through the peer network and lives in a server's database.
3. It's presented as part of a "claim" transaction, and lives in the transaction only.

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:

1. A unique ledger object that is consumed on successful transactions - like claim ids.
2. Enforced transaction ordering - like "account create" does.
3. Explicitly tracking on ledger which proofs have been used. This can use a timeout where a proof must be presented in some limited window to be valid.
4. Explicitly tracking off-ledger which proofs have been used. This can also use a timeout.
5. If proofs are "pushed" to the ledger, the external server that pushes the proofs must do so exactly once (requires trusting this server).

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?

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.

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.

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.

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.

@seelabs

Who informs the mainchain that an asset was moved into trust on the sidechain?

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.

In what form is this information given to the network and where does it live?

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 need a way to prove that something happened on the other chain.

We are on the same page here.

We need a way to prevent proofs from being used more than once.

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.

We need a way to handle transaction failures.

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.

Because there might be multiple? Nothing requires people to use a particular UNL. Today people might trust the UNL published by Acme Corporation and tomorrow they might migrate away from it, sick of Acme's explosive tennis balls.

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.

If there are multiple UNLs, there can be multiple bridges.

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.

In that scenario, the sidechain itself has to trust the bridge, to issue additional native assets?

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.

If anyone could set up a bridge, then anyone can print money on the sidechain.

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.

If one of the chains does not support IBC protocol

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.

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.

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.

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.

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.

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?

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.

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.

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.
I currently fail to understand how the benefits of this amendment outweigh the downsides. I would love to read more about these considerations.

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).

I'll truthfully say my motivation in building this had nothing to do with avoiding regulation

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.

Adding this to the witness server seems natural, but right now the witness servers are completely independent from one another.

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.

I've also though about trying to add a block-list to the ledger itself, but the challenge is the potential size and the static nature (although maybe I could do something clever with a bloom filter).

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.

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?

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 didn't take it as an attack, and I do appreciate you bringing up these points.

This is actually also a thing I have considered for Hooks

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.

What about using ILP synchronizing primitives...

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 Connector, which needs to be run by a single entity (i.e., ILP introduces natural centralization into the mix).

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.

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:

• 99,999,184 BNB and 10 billion BUSD issued on Metis

• 999.8127T SHIB issued on Heco

• 87,579,118 COW and 999,998,434 OOE issued on Polygon

• 636,643,868 STACK and 88,640,563 GM issued on Polygon

• 2,175,053 03 issued on Polygon

• 378,028,371 STACK, 82,854,568 XTM, 11,026,341 SPAY, and 89,383,712 GM issued on Avalanche

• 8,882,911 METIS, 926,160,132 DOV, 978,102,855 SLD

@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.

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.

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.

Another one. CRV/ETH Pool hacked and this could be just the beginning. We can't let this happen to XRPL bridge.

I second this. At a technical level, this is ready to be moved along. Legal concerns should be resolved elsewhere.

I would prefer the xumm team would be more proficient at, which they have not delivered an equivalent/better than the "existing team".

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.

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.

The B2M conversation should also happen on another forum as the concerns are independent of this spec.

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 ?

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 👍

For future readers: see the current version of XLS-38d here.