Better bridge asset transfer user fees

[acatangiu]

Background

The current general idea of how assets are transferred over the bridge is described below. Let's say it is for the bridge between Statemint (Polkadot parachain) and Statemine (Kusama parachain):

1. we assume that this pallet (please note it isn't yet completed) will be deployed at Statemint and Statemine;
2. a user wants to transfer their assets e.g. from Statemint to Statemine and they call the transfer_asset_via_bridge() function of the pallet. Part of this call is taking fees - so user pays fees on the source parachain (not at bridge hubs). Right now the plan is that it'll be the constant, which eventually may be updated by governance or something like that. We need to figure out how to calculate this constant fee;
3. the message is sent to the sibling bridge hub (XCMP queue) and it is pushed to the bridge queue;
4. relayer delivers it to the other-side-bridge-hub and the message is redirected to the target parachain (XCMP queue);
5. costs (and rewards) of relayer transactions are disconnected from user fee paid at 2); the relayer rewards are registered in the pallet-bridge-relayers on both sides bridge hubs, so they can claim it anytime.

So we assume that Statemint will have a sovereign account at the Kusama Bridge Hub and Statemine will have a sovereign account at the Polkadot Bridge Hub. These accounts are used to pay registered rewards to relayers. Accounts eventually need be topped up by Statemint/Statemine bridge maintainers.

Issue/Task

This issue focuses on the fee in point 2) above.

A concern was raised that a constant fee is likely not enough, as it would allow an attacker to enqueue thousands of messages and thus create a considerable delay in message delivery. This could be abused for intentional DoS by temporarily stalling a bridge lane/delaying messages in order to slow down automatic arbitration systems and gain an unfair advantage.

Dynamic fees

One idea is to implement some form of dynamic fees similar to what is implemented in paritytech/polkadot#6843 for DMP. That way sending messages gets (exponentially) more expensive if the queue size (number of messages and/or cumulative size of all messages in queue) exceeds a threshold. This will effectively limit the queue length and therefore the delay an attacker can cause by spamming the system. When having a dynamic fee system, it is also possible to adjust fees so that the sovereign account used for relayer rewards gets sufficiently funded (may require using the dex pallet to exchange between DOT and KSM so that the rewards on the other side can be paid).

From technical point of view, we have our own challenges regarding this exponential approach. We have 3 queueus in the bridge (Statemine <XCMP queue> BHK <bridge queue> BHP <XCMP queue> Statemint). So we don't have access to "number of queued messages" at the source parachain.
We may say that the whole bridge throughput is, say 10 messages per block and then we can exponentially increase cost if we see that the number of outbound messages overflows this limit.

Constant fees

We may also decide that a constant fee is enough for the first iteration of the bridge where being able to transfer assets between Statemint and Statemine is all we target.
In this case we would have to document and warn users that the bridge should not be used for low-latency arbitrage purposes.

How to calculate fee

In either case, we need to find the base value of this fee paid by users at Statemint/Statemine when doing asset transfers between them.

@joepetrowski ^

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/bridge-hub-questions/2693/2

[joepetrowski]

Sorry for the late response. Yeah this is a tricky one. I agree dynamic fees will ultimately be necessary. Looking at the three queues, I think we could handle it for DOT/KSM being transferred over the bridge, but it will be more difficult with other messages.

In the case Statemine to mint:

• Statemine <queue> BHK: Of course this part is trivial.
• BHK <queue> BHP: Two options:
  • The user attaches a "max fee" to the message, and if the queue is too busy then it will just stay in the queue. This is basically an Ethereum tx pool.
  • The BH forwards to Statemint what the fee was, and Statemint either teleports it back to BH to pay relayers (or more efficiently, saves it in an account that it teleports every day or so).
  • Or combine both, with a user setting a max fee and then Statemint handling all the fees on reception.
• BHP <queue> Statemint: Here, if we are dealing with DOT (or any asset once we have the asset conversion pallet online), Statemint can just deduct the fees for this queue on the Statemint side. BHP might need to send some info to Statemint telling it how much to charge, and it trusts Statemint to handle this.