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
This is essentially a C/P of the issue opened here: AstarNetwork/Astar#1180
It's happening on Astar which is still running on relatively old frontier and polkadot-sdk (pre-sdk) dependencies but I haven't found any recent PRs or commits that would cover the fix.
It has been observed that gas estimation will return incorrect value when provided with certain inputs.
Once transaction is submitted with the estimated value, it will fail with OutOfGas error.
contract is deployed on Astar Network, on address 0xc6bf0C5C78686f1D0E2E54b97D6de6e2cEFAe9fD
at least 1 ASTR should be provided as value with the call
The function of interest is the following one:
/// Minted vNative assets such as vASTR, vGLMR, vMOVRfunction mintVNativeAsset(
addressreceiver,
stringmemoryremark
) externalpayable;
The received address isn't important, but depending on the string remark value, the gas estimate will be correct or incorrect.
It's worth mentioning that remark is only emitted as part of an event, and put inside another subcall's blob (precompile call to XCM transact), and has no effect on logic execution.
When Hello is used as remark value, the gas estimate will be around 167k.
When Hell is used, the gas estimate will be around 180k.
For some reason, adding an 'o' will cause the estimate to drop significantly.
And if call is submitted, as mentioned before, it will fail with OutOfGas error.
The following example can be replicated on any Astar node (current version is astar-80) by using eth.gasEstimate RPC call.
Your case is very similar to one that occurs in the Darwinia network. Fixed patches have been submitted #1239, #1257. Suggest you upgrade your frontier to cover these patches and have a try.
Your case is very similar to one that occurs in the Darwinia network. Fixed patches have been submitted #1239, #1257. Suggest you upgrade your frontier to cover these patches and have a try.
I did find your issues before posting my own, but assumed they probably aren't connected.
My guess regarding my issue, given how I can make it work or fail by simply changing the string argument, is that
decoding of the input data is done incorrectly somewhere, resulting in reduced gas estimate.
Right now we are uplifting to newer versions of polkadot-sdk and frontier so I hope to be able to test it out soon.
Overview
This is essentially a C/P of the issue opened here: AstarNetwork/Astar#1180
It's happening on
Astar
which is still running on relatively oldfrontier
andpolkadot-sdk
(pre-sdk) dependencies but I haven't found any recent PRs or commits that would cover the fix.It has been observed that gas estimation will return incorrect value when provided with certain inputs.
Once transaction is submitted with the estimated value, it will fail with
OutOfGas
error.Details
Astar Network
, on address0xc6bf0C5C78686f1D0E2E54b97D6de6e2cEFAe9fD
The function of interest is the following one:
The received address isn't important, but depending on the
string remark
value, the gas estimate will be correct or incorrect.It's worth mentioning that
remark
is only emitted as part of an event, and put inside another subcall's blob (precompile call to XCM transact), and has no effect on logic execution.When Hello is used as
remark
value, the gas estimate will be around 167k.When Hell is used, the gas estimate will be around 180k.
For some reason, adding an 'o' will cause the estimate to drop significantly.
And if call is submitted, as mentioned before, it will fail with
OutOfGas
error.The following example can be replicated on any Astar node (current version is
astar-80
) by usingeth.gasEstimate
RPC call.One example of the data for the call:
0x62c64fe10000000000000000000000004597c97a43dfbb4a398e2b16aa9ce61f90d801dd0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000548656c6c6f000000000000000000000000000000000000000000000000000000
0x62c64fe10000000000000000000000004597c97a43dfbb4a398e2b16aa9ce61f90d801dd0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000448656c6c00000000000000000000000000000000000000000000000000000000
The text was updated successfully, but these errors were encountered: