You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Found what seems like a bug where we double apply the tx buffer when submitting a tx. We still only apply the buffer once when using the amount to compare for gas payment enforcement, but it does mean we always end up paying 150k gas more than the estimate, which doesn't feel intentional?
imo the relayer's agreement is "i'll require users to pay for a gas amount that is used on the destination" not "i'll require users to pay for a gas amount that is what the destination chains estimate is, even if the estimate is inflated"
Solution
Fix both these issues, copying some suggestions from that thread:
For the double payment, I suggested:
Not 100% sure on the fix, maybe if tx.tx.gas() is Some in fill_tx_gas_params we don't apply the buffer?
Dan's suggestion:
I think our inferred / desired behavior is that we only fill_gas_params before submitting but keep the estimate
so in this function we can add a boolean flag based on which add_gas_overrides is called or not
so an even shorter-term fix is to remove that prematurely added buffer as you suggested, by requiring process_estimate_costs to take in an additional apply_gas_overrides boolean that it passes to process_contract_call
Whatever solution we go with, it should fix both these issues and be easy to understand - it was confusing to track this flow down
The text was updated successfully, but these errors were encountered:
Problem
See discord thread https://discord.com/channels/935678348330434570/1319115367167033399, juicy bits copied:
Problem 1 - double applying a gas buffer for txs
Found what seems like a bug where we double apply the tx buffer when submitting a tx. We still only apply the buffer once when using the amount to compare for gas payment enforcement, but it does mean we always end up paying 150k gas more than the estimate, which doesn't feel intentional?
Looking at this message https://explorer.hyperlane.xyz/message/0x49ab3d0831517ee53c998f59c5732dd1e44f937eb746bb152959e475069e5368
Logs around here https://cloudlogging.app.goo.gl/nYfKhujwm1smLSL26
When preparing:
295432
(while this isn't the true source, that number can be seen in the zks_estimateFee here https://cloudlogging.app.goo.gl/ehvYD149nEwwGXhW8)apply_gas_estimate_buffer
and set the gas limit for the transaction to370432
(https://cloudlogging.app.goo.gl/ee9yJsz72n9tKJmX7)Now when submitting:
370432
when calling mailbox.process (https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/rust/main/agents/relayer/src/msg/pending_message.rs#L371)370432
, giving us445432
due to theapply_gas_estimate_buffer
call in tx.rs fill_tx_gas_params (https://cloudlogging.app.goo.gl/fWrGnyNUHBA589x77, https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/rust/main/chains/hyperlane-ethereum/src/tx.rs#L129)Problem 2 - using post-buffer gas amounts when enforcing IGP gas amounts
We compare an IGP payment's gas amount to the gas limit of a tx after a buffer has been applied.
I notice that we apply the buffer (https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/rust/main/chains/hyperlane-ethereum/src/tx.rs#L36) to the gas estimate in
process_estimate_costs
Call path goes process_estimate_costs -> add_gas_overrides -> fill_tx_gas_params -> apply_gas_estimate_buffer
imo the relayer's agreement is "i'll require users to pay for a gas amount that is used on the destination" not "i'll require users to pay for a gas amount that is what the destination chains estimate is, even if the estimate is inflated"
Solution
For the double payment, I suggested:
Dan's suggestion:
Whatever solution we go with, it should fix both these issues and be easy to understand - it was confusing to track this flow down
The text was updated successfully, but these errors were encountered: