rework priority fee logic

[christianangelopoulos]

Motivation

updated fee logic calculation to reflect latest changes in Alloy.rs which uses EIP1559_FEE_ESTIMATION_DEFAULT_PRIORITY_FEE of 1 wei instead of 100,000,000 wei (0.1 Gwei).

should save users of hyperlane relayer a substantial amount of gas on L2s where the base gas fee can be thousands of times lower than 0.1 Gwei.

Here is an Example transaction where priority fee was set to 0.1 Gwei

Solution

• Updated EIP1559_FEE_ESTIMATION_DEFAULT_PRIORITY_FEE to 1 wei.
• Added EIP1559_BASE_FEE_MULTIPLIER and changed fn base_fee_surged to use it in order to better reflect recent estimator in Alloy.

[christianangelopoulos]

FYI - test_eip1559_default_estimator was failing previous to these changes. Now that it works, a bunch of other downstream tests are failing, that appear to be unrelated to these changes (when I comment out the test that was failing in the previous commit, I get the same failures)

[aroralanuk]

looking at this

[aroralanuk]

Great catch, a couple of points:

• can remove the if max_priority_fee_per_gas > potential_max_fee branch and just add base to priority fee, bc with the status quo, one edge case is if potential_max_fee == max_priority_fee_per_gas, we end by (x,x) value so effective making base fee 0 which will get stuck
• similar to alloy, can add EIP1559_MIN_PRIORITY_FEE if rewards.is_empty() in case some chains don't accept zero values

[aroralanuk]

Can you remove the commented-out code below?

[christianangelopoulos]

Great point on edge case. Addressed the above:

• removed the if max_priority_fee_per_gas > potential_max_fee branch to reflect the same logic as alloy
• removed commented code

similar to alloy, can add EIP1559_MIN_PRIORITY_FEE if rewards.is_empty() in case some chains don't accept zero values

this is covered by this this part, unless I'm missing something

    let max_priority_fee_per_gas = std::cmp::max(
        estimate_priority_fee(rewards),
        U256::from(EIP1559_FEE_ESTIMATION_DEFAULT_PRIORITY_FEE),
    );