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
Some parts of the feemarket PostHandle() function (like this and this one) are not executed during transaction simulation, which causes the gas estimation to be wrong, since the gas spent there is not taken into account.
This has the following consequence: user runs transaction simulation in a wallet and receives some estimation of gas needed to execute the tx (let's say 80k gas units). It then uses gas adjustment multiplier (usually 1.3 by default) to set the gas limit on the tx, which would be 104k gas units in this case. When the wallet sends tx, it would fail during deliverTx() since it requires more gas than the specified gas limit (let's say the actual gas needed was 115k). Users have an option to increase the gas limit, but since the estimate given in the beginning is wrong, they need to guess what amount of gas would make their tx enter the block. If they specify very high gas limit, they would have to pay for gas that would not be actually spent.
The same problem exists with IBC relayers, which would need to use high gas multiplier in their configuration, and therefore pay much higher fees for creating light clients, connections, relaying packets, etc.
Here is an error thrown by the Hermes when trying to create a light client between two feemarket-enabled chains (using gas multiplier 1.5):
ChainError("deliver_tx for 3780236541E37FEE56167162A089CCBBDA6FE75F83333A5FE988B1783DD32ABF reports error: code=Err(11), log=\"out of gas in location: Has; gasWanted: 131004, gasUsed: 131890: out of gas\"")
The text was updated successfully, but these errors were encountered:
Some parts of the feemarket PostHandle() function (like this and this one) are not executed during transaction simulation, which causes the gas estimation to be wrong, since the gas spent there is not taken into account.
This has the following consequence: user runs transaction simulation in a wallet and receives some estimation of gas needed to execute the tx (let's say 80k gas units). It then uses gas adjustment multiplier (usually 1.3 by default) to set the gas limit on the tx, which would be 104k gas units in this case. When the wallet sends tx, it would fail during
deliverTx()
since it requires more gas than the specified gas limit (let's say the actual gas needed was 115k). Users have an option to increase the gas limit, but since the estimate given in the beginning is wrong, they need to guess what amount of gas would make their tx enter the block. If they specify very high gas limit, they would have to pay for gas that would not be actually spent.The same problem exists with IBC relayers, which would need to use high gas multiplier in their configuration, and therefore pay much higher fees for creating light clients, connections, relaying packets, etc.
Here is an error thrown by the Hermes when trying to create a light client between two feemarket-enabled chains (using gas multiplier 1.5):
ChainError("deliver_tx for 3780236541E37FEE56167162A089CCBBDA6FE75F83333A5FE988B1783DD32ABF reports error: code=Err(11), log=\"out of gas in location: Has; gasWanted: 131004, gasUsed: 131890: out of gas\"")
The text was updated successfully, but these errors were encountered: