EIP-1559 Fees calculations

[P1sar]

Due to the situation of having problem with estimating TX fees for networks with EIP1559 we need to bring up some new algorithm of calculating fees.

Current behavior has its limitations if maxGasPrice set lower than baseFee so that maxPriorityFeePerGas is set to 1 gwei then that leads to long waiting until transaction get mined.

https://github.com/ChainSafe/ChainBridge/blob/main/connections/ethereum/connection.go#L172

I do not see any straight solutions for such situation bcz having any limitation configs will always could lead to such situation. But to make it more predictable there is one proposed solution:

Proposed behavior #1: config all params

Instead of having only maxGasPrice config we probably should have additional config for maxPriorityGasPrice. And so our maxFeePerGas automatically became maxGasPrice + maxPriorityFeePerGas.

If maxGasPrice is not set, then maxFeePerGas = baseFee + maxPriorityFeePerGas

if maxPriorityGasPrice is not set, then maxPriorityFeePerGas is suggested from network

If any of configs is not set (eg 0) then all suggests from network

But then comes question what to do if baseFee > maxGasPrice?

Probably maxFeePerGas = baseFee + maxPriorityGasPrice (if maxPriorityGasPrice set, otherwise 1 Gwei?) or always maxFeePerGas = baseFee + 1Gwei

[GregTheGreek]

If we want to keep the maxGasPrice I think the only solution is if we have a queue implemented, that way we can place those transactions in a queue, wait for network conditions to lower and move on. Otherwise I think it creates very adverse issues for the bridge where it will exit early on a failed transaction.

Also should be noted that in web3.js we recently bumped our default maxPriorityFeePerGas to 2.5 gwei.

[ricardolyn]

Probably maxFeePerGas = baseFee + maxPriorityGasPrice (if maxPriorityGasPrice set, otherwise 1 Gwei?) or always maxFeePerGas = baseFee + 1Gwei

For this case, the former is a better solution than hardcoded of the latter.

If we want to keep the maxGasPrice I think the only solution is if we have a queue implemented, that way we can place those transactions in a queue, wait for network conditions to lower and move on. Otherwise I think it creates very adverse issues for the bridge where it will exit early on a failed transaction.

This is one of the issues we are having with failed transactions. Instead of sending the transaction even if the maxGasFee is above the baseFee, it should instead save it on a queue and wait for better conditions.

This is to avoid having a transaction being sent to the pool which then is not picked up by the miners and the bridge locks as there is a missing nonce. Moreover, a logic should be in place for this case where the transactions are replaced or speeded up (based on some configuration) in the pool so it doesn't get lost.

[peak3d]

I have not dived very deep into the code here, but want to suggest a completely different approach (maybe optional).

Instead executing the TX on the target chain (most critical is ETH currently), an event is emmitted on the (cheaper) src chain which writes out a signed message containing what should be fired on target.

The user (or UI) is then responsible fetching this event, parsing the message and fire it on target chain. The benefit is that the user can decide by himself, how much Gas he is willing to pay (high / low prio).

So my beginners question is: Would relayers be able to create / vote for a secure signed message?

B.t.w. Polygon is bridging to ETH with a 2 step way, too, we have implemented this in UI and our team agrees that this is the most fair way for our users.

[P1sar]

User now is willing to decide how much gas he want to pay when sending Deposit on a origin chain, but our implementation also requires some relayers to vote for this proposal on destination chain, so this is the palce where not 'user' decides what the gasPrice to use.
If I understand right your proposition is that relayers should vote on origin chain (since it cheaper in case of Polygin <> Ethereum transfer) and then after consensus is reached signed message sent by user on the destiantion chain?

And I think its not really realted to the topic of discussuin) So we will appreciate if you start separate topic for this.