Discussion: Bridging assets via external bridges to different parachains via XCM

Tech Talk
1

Problem:
Bridging assets from e.g. Ethereum via an “External” bridge, e.g. Wormhole, to non-EVM parachains currently requires an XCM “hop”.

For example, to move DAI from Ethereum to Hydra, you currently do:
Ethereum -- Wormhole --> Acala -- XCM --> Hydra

The UX is currently not ideal and there are questions / challenges around:

  • Paying XCM fees
  • Paying fees on the “hop” parachain, e.g. Acala in the example above
  • Wallet UX (goal is to avoid the user coming online multiple times)
  • …

There are a few teams currently working/thinking about custom solutions and talking to bridge providers, incl. work on Substrate-native integrations with external bridges. It seems Snowbridge and the Kusama<>Polkadot bridge are supposed to launch on a dedicated bridge hub, and will hence use a similar “XCM multi-hop” model to move assets to parachains.

Goal
The goal of this post/thread is for teams currently working on this “How get external assets to parachains via XCM hops” problem to share thoughts, current issues and possible solutions - and to connect with the respective teams at Parity.

The ultimate goal is to work towards a “standard” process that can be used across the ecosystem to help accelerate integrations with new bridges/parachains and avoid a dozen of custom solutions being built.

10 Likes
2

What about building a second cross-chain communication possibility.
The relay chain tracks all para-heads and the relay head is provided to the para-chain runtimes via the parachain-system pallet.

Basically, do what snowfork is doing between ethereum and polkadot, but just between parachains. Any protocol whose processed messages can be proven via a storage-proof (snowfork commits them via an digest-item) can be build on top of that.

3

I want to highlight some UX related difficulties. Without address those, we may end up with UX that requires users to have multiple tokens for tx fee on different chains and need to sign multiple tx for a multi hop cross chain transfer.

Transaction fee: The source chain hop chain will need to charge some token for tx fee. Ideally user only need to pay tx fee once on the source chain with one token. This means the hop chain will need to accept non-native token as tx fee.

Multiple transactions: Without optimization, user will need to sign & send a transaction on the hop chain to send the token to dest chain. This means user will need to have an account on the hop chain to sign & send transaction.

Dependencies: The more chain involved, the more dependency the transfer depends on. We need to ensure the compatibly across upgrades. This includes runtime and UI.

4

These conclusions are not true. The way we imagine this happening on the Bridge Hub (the “hop chain”) is that no user would ever transact on it; all interactions would be XCM instructions. Of course, XCM execution fees will be in DOT/KSM (on Polkadot, Kusama).

The chains that interact with it (Acala, Statemint, etc.) will need to keep some DOT in their sovereign account on the bridge hub. These can be topped up from each chain’s treasury occasionally.

Of course, you still need to account for the fee, and don’t want to give users unlimited free execution over the bridge. But your runtime should have an idea of the execution costs on the bridge, and charge for it accordingly. I.e., a fee that uses the bridge would have:

  • Normal fee for transacting on the source chain (Acala, Statemint, etc.)
  • Additional fee for the BuyExecution instruction on the Bridge Hub. This could even go into a small pot on the source chain that gets transferred to the Bridge Hub sovereign account every n blocks.

The source chain can charge fees in whatever it wants, as long as it has a way to price and convert that fee to the DOT/KSM fee it will pay on the Bridge Hub and maintain its sovereign account. (Related: Why not just Statemint needs an AMM but (likely) every parachain and we should do our best to agree on a shared interface)

On a more general note, I think parachain developers need to consider their chains qua sovereign entities that can have and manage their own assets/information and express their own voice within the greater network. A parachain is not just an interface that users pass through but need to own every downstream asset/transact on every other chain – XCM, origins, and autonomous runtime hooks allow chains to abstract this away from users.

4 Likes
5

Does BridgeHub aim to become a transactionless chain? i.e. no user transaction. Only XCM & operational transactions.

Also how will it work when the source chain is Ethereum? e.g. Transfer ERC20 token from Ethereum to Acala via Snowfork on BridgeHub.

6

Yes. In that case, Snowbridge accepts inbound messages from its Relayers (the Snowbridge docs give a good overview). Maybe @Vincent can comment more about who can be a Relayer? I suppose it is not “transactionless” if Relayers are transacting with message blobs from Ethereum, but we wouldn’t expect application users to transact on the Bridge Hub.

But the message blob should include some info about where in Polkadot it wants to go, e.g. to Acala or to Statemint. The Bridge Hub would be able to express MultiLocations like { parents: 2, interior: X2(GlobalConsensus(Ethereum), ERC20(0x1234))}, which the destination chain should know how to map to an asset identifier locally.

I know for the Polkadot<>Kusama bridge, @acatangiu or @bkontur on end-to-end cases (e.g. Statemine to Statemint over BH), so perhaps they could chime in with more details about the message/transaction handling.

7

I can’t find docs on how fee works with relayers and will love to learn more about it. Does relayer have to pay DOT on BridgeHub to relay a message?

For Polkadot <> Kusama bridge I am also want to learn how fee works as well. To transfer token from Statemint to Statemine, does user need to have KSM for pay execution on Kusama BridgeHub?

8

Equilibrium team in cooperation with Moonbeam and Multichain have developed a solution for cross-chain transfers without user additional transactions on Moonbeam by using xTokens system contract. This enables user-friendly asset transfers between EVM networks like Ethereum, Polygon, etc, and Polkadot ecosystem Parachains.

Deposits are a one-click user action, while withdrawals require Moonbeam - Ethereum interaction and are a 2-click user action, with Moonbeam’s functionality to call EVM via XCM this will later be merged to one-click action as well.

We have registered mintable XC-20 xcWBTC.multi, xcETH.multi, and xcUSDC.multi tokens on Moonbeam. And now we are deploying bridge contracts on Ethereum and Moonbeam.

Passed proposal on Moonbeam: Polkassembly

2 Likes
9

Hi, Vincent from Snowfork here. Thanks for bringing this up @alexei, its quite relevant, as we’re currently reworking our relaying fabric to be compatible with BridgeHub, and to be similar to the Polkadot<->Kusama bridge.

Our old relaying and fees/reward design at Incentivized Channel - Snowbridge can be considered obsolete.

We are currently sketching out a new design at Channels V2. It describes my understanding of how the Polkadot<->Kusama will handle fees/rewards, and the same for Snowbridge.

Several notes to add context to Channels V2. To ensure a trustless and decentralized architecture:

  1. We’ve deliberately chosen not to use on-chain oracles to determine exchange rates between DOT/KSM and DOT/ETH.
  2. When exporting a message to another chain (like Ethereum), BridgeHub does not perform any dynamic fee estimation. That would involve BridgeHub being updated with Ethereum gas prices from some kind of oracle, which would likely not be trustless. So initially fee amounts would be set by governance.
  3. Parachain teams are responsible for topping up their sovereign accounts on the destination chain, so that offchain message relayers can be fairly compensated.

These issues are certainly not ideal, but we view them as an acceptable tradeoff to ensure a secure design, at least for our initial rollout.

Designing a trustless and incentivized message relay is hard! And our priorities need to be initially focused on light client security and adapting our bridge to use XCMv3 as the low-level messaging protocol.

I think for a future fee/reward model, we do have a few tricks up our sleeve. For example, to improve (2), our ethereum light client can securely and trustlessly provide the latest Ethereum baseFeePerGas value (EIP-1559) to BridgeHub, which would go a long way into providing better fee estimates.

3 Likes
10

This is very helpful information - and also what I would perceive as ideal UX scenario.

User interacts with bridge interface, specifying “I want to move DAI from Ethereum on Acala”.
Signs all the transactions at once, waits, and receives DAI on the Acala account.

The user does not need to worry about different fee-currencies used along the way and does not need to come online in-between to manually execute intermediate steps/transactions.

Maybe the user needs Aca to pay for gas to use DAI on Acala going forward - this can be solved e.g. by small faucets and “bring-your-own-fees” as Acala and Hydra are already doing.

11

Yeah, ideally the user would only sign one transaction - the origin chain should take the full fee (knowing what it will need downstream) and then any chain downstream should manage their sovereign account on chains they interact with.

12

Yeah. That will require custom logic, either as a service (this is what we are trying to figure out / build right now to work with existing EVM bridges) or on parachain level.

13

just want to pop in and touch on Darwinia’s light client-based solution, designed to use simple endpoints and abstract away intermediate routes along the way. their cross-chain bridge relayer network is permissionless, and uses an incentivized fee market model to ensure all fees are payable only in the token of the source chain… no other assets are required. (ie: buy ETH and have it delivered to your wallet straight from Acala parachain, without needing to own DOT, RING, or ETH.)

Darwinia devs should pop in and add more technical details to this discussion when they are back at their desks.

2 Likes
14

Yeah, to confirm, with Snowbridge, users will certainly not need to relay their own messages or interact with BridgeHub in any way. To transfer assets across the bridge to a final destination they will only need to sign a single transaction.

1 Like
15

For the cross-chain fee problems, our solution here in Darwinia, is not to resolve it by a governance mechanism or oracle system. The cost structure for the fees are from different chains and the market and liquidation provider could change quickly, the gov solution is not agile enough to keep up with the changes of market and cost.

Our general solution is to handle it to relayer market system, the relayer is sensitive to the cost structure of the transactions fees, and the price ratio of different tokens.

In this way, the users in source chain only need to pay the message fees using the native token from source chain, the fee market will handle the other stuffs, including pricing based on auction, fee settlement.

From an architectural point of view, this can also keep it simple, and the design of the fee market system can be continuously improved.

For more details, please refer our initial design documents and reference implementation, it is already used in production.

4 Likes
16

Here is a presentation from Bear:

An article from Darwinia medium:

3 Likes
17

Yeah, I agree that the current UX could be better for the reasons you’ve stated above. Also, parachain teams need liquidity now, and so a solution that can be built with the current implementation seems like a good path moving forward today.

As @Overseven mentioned, Equilibrium/Multichain worked together (we helped :slight_smile: ) on creating a proposal to create Mintable XC-20s to bring WBTC, ETH, and USDC to Equilibrium, with the first hop being from Ethereum to Moonbeam via Multichain, and the second from Moonbeam to Equilibrium via XCM.

We are happy on collaborating with other GMP providers (bridges) on creating a similar solution for their implementation on Moonbeam to bring liquidity to other parachains.

While depending on the bridge architecture, this can be a one-click or two-click user action, and Moonbeam is excellent as an intermediary when bridging assets from Ethereum or other chains that use ECDSA-based accounts because there is no need to bind an EVM account to a Substrate account.

Also, we are currently exploring ideas to enable ERC-20s to be directly sent via XCM, without needing them to be wrapped as an XC-20, which would drastically improve UX as well. Lastly, a network of decentralized relayers like Biconomy could help (or, depending on the GMP, the GMP network itself) in the intermediary hop.

With this model, and depending on how the target parachain is configured, the XCM fee can be charged in the wrapped asset, meaning that if you sent 1 ETH from Ethereum to Interlay, you could charge 0.XYZ ETH on Interlay to execute the XCM there. Consequently, the user bringing liquidity into the ecosystem does not have to have the notion of GLMR, DOT, INT, to bring their liquidity.

1 Like
18

Thank you @alex for bringing this up. I’m so excited because this is what SubBridge (built by Phala) is doing, by building a muti-bridge router, to transfer assets between any Polkadot parachian and external EVM chains. It is already online and running for nearly one year: https://subbridge.io/

The fundamental principle of SubBridge is we don’t want other parachain to change any single line of their runtime code to use SubBridge, in other words, if the parachain has opened an HRMP channel with Phala, it can transfer their asset through XCM to external EVM chains directly, and verse versa. And we made it, parachains only need to change the dest MultiLocation when they construct the transaction arguments on the client. Here are some examples:

Suppose we have a user that wants to transfer an asset from Karura to Khala he needs to specify the dest with:

{"parents": 1, "interior": {"X2": [{"Parachain": 2004}, {"AccountId32": {...account_key_on_khala}}]}}

Now if he wants to transfer to Ethereum, he only needs to change it to:

{"parents": 1, "interior": {"X4": [{"Parachain": 2004}, {"GeneralKey": "cb"}, {"GeneralIndex": 0} {"GeneralKey": {...account_address_on_ethereum}}]}}

SubBridge routing protocol can recognize it and forward messages from the XCM protocol to the EVM bridge that connects with Phala.

Like this image shown below, SubBridge connects serval bridges, we already connect ChainBridge with XCM protocol and will complete the integration with SygmaBridge (by ChainSafe) and WanBridge in the coming two months. Especially SygmaBridge, we are developing the sygma-substrate-pallet with the Sygma team, and it is almost done, the pallets can be used by any substrate chain in the future (fully support XCM protocol from the beginning).

img
img974×287 12.6 KB

Our wiki has more details on how SubBridge work, check it here. And also, earlier last year, we talked to communities at the Substrate seminar, here is the slide link.

6 Likes
19

image
image1200×675 48.6 KB

SubBridge has supported lots of parachains which you can find in this image.

3 Likes
20

I also offer to look at subbridge.
It is Phala/Khala Networks solution for bridging assets.
Just check it out please.