eth_estimateGas fails on empty address

[kuegi]

Summary

eth_estimateGas returns Custom error: gas required exceeds allowance 0 if the address has no DFI on it. But it should return the estimated gas.

[sieniven]

This is the correct behaviour. Estimate gas RPC aligns with geth, and you will see the exact same behaviour on Ethereum. If the from address has no DFI, and it is trying to make a transaction, the RPC will propagate this error since you cant make transactions without any DFI. If you would like to create a state override setting to test a specfic context, please pass the state override set with the address-to-state mapping in the optional parameter in the eth_estimateGas RPC.

[kuegi]

thx. @sieniven it might be according to geth. but reality for exchanges is different it seems.
doing the call for any ethereum rpc on https://ethereumnodes.com/ with the address that is also empty on ETH, it always returns the estimated gas.
So this difference makes it harder for anyone to reuse existing eth tools.

[sieniven]

@kuegi that is not true. Please verify again on your end that you are directly interacting with an ethereum node. With any ethereum node, the default behaviour returns an invalid response: "error": { "code": -32000, "message": "insufficient funds for transfer" }. Often times these public endpoints, for example Alchemy, may provide an additional layer on top of nodes which differ from node behaviours. We choose to align ourselves as much as we can to geth, and implement behaviours that make sense in our context.

In addition, as mentioned above, please note that our node supports the addition state override set customization in our eth calls RPC. In this specific context, it does not make sense to return a default gas transfer used in this RPC when the address is zero. That would actually make the RPC faulty and unreliable. Please pass the state override if you would like to set a defined context on your RPC call.

[LXHLeaner]

@sieniven Account DFI amount is not enough will also report an error?

[kuegi]

@kuegi that is not true. Please verify again on your end that you are directly interacting with an ethereum node. With any ethereum node, the default behaviour returns an invalid response: "error": { "code": -32000, "message": "insufficient funds for transfer" }. Often times these public endpoints, for example Alchemy, may provide an additional layer on top of nodes which differ from node behaviours. We choose to align ourselves as much as we can to geth, and implement behaviours that make sense in our context.

In addition, as mentioned above, please note that our node supports the addition state override set customization in our eth calls RPC. In this specific context, it does not make sense to return a default gas transfer used in this RPC when the address is zero. That would actually make the RPC faulty and unreliable. Please pass the state override if you would like to set a defined context on your RPC call.

thx for the reply. In the end, the issue is that we make it really hard for externals right now to integrate DMC as it behaves different. If its not an issue on the node itself, its an issue on the blockscouts?

What can we do, to make it easier for exchanges to integrate DMC?

If I do the same call on any public eth rpc that I find, I get a valid result. So its a bit hard to believe that this should not be the standard.

[sieniven]

@LXHLeaner Yup. https://www.quicknode.com/docs/ethereum/eth_estimateGas - you can check out the optional state override parameter that our node supports.

[sieniven]

@kuegi

If I do the same call on any public eth rpc that I find, I get a valid result. So its a bit hard to believe that this should not be the standard.

https://ethereum-sepolia.publicnode.com public RPC endpoint behaviour aligns exactly the same as our node.

What can we do, to make it easier for exchanges to integrate DMC?

We have been making multiple PRs and fixes to fix all endpoints to align ourselves as much as we can with geth. geth is the most largest client with the most widespread user base. Actually the node has been making active steps to stability and full integration (PRs #2633, #2736, #2784, #2788, etc), more to come. Would be really helpful if the community could continue pointing out any integration issues with external web3 applications :)

[kuegi]

@kuegi

If I do the same call on any public eth rpc that I find, I get a valid result. So its a bit hard to believe that this should not be the standard.

https://ethereum-sepolia.publicnode.com public RPC endpoint behaviour aligns exactly the same as our node.

Does this call return something else on your side? If I call it, it returns a valid gas estimate:

curl  https://ethereum-sepolia.publicnode.com \
-H 'Content-Type: application/json' \
--data '{
    "jsonrpc":"2.0","method":"eth_estimateGas",
    "params":[
        {
            "from":"0x4790b73359B393a10D4201371563795001f17977",
            "to":"0x347D48fB3907B71089945Aee7cafEe75d5F30EBc",
            "data":"0xa9059cbb000000000000000000000000dac0ebb0b5ed7ffd9441509acb40f06a529500000000000000000000000000000000000000000000000107ad8f556c6c0000"
        }],
        "id":1
}' 

returns {"jsonrpc":"2.0","id":1,"result":"0x5512"}

Would be really helpful if the community could continue pointing out any integration issues with external web3 applications :)

Thats what I am trying to do here.

[sieniven]

@kuegi Thanks for providing the context. This is much more useful, and this is indeed a bug when calling eth_estimateGas with a populated data field in the call context. Will be re-opening this issue.

[Stonygan]

https://ethereum-sepolia.publicnode.com public RPC endpoint behaviour aligns exactly the same as our node.

I run a public BSC Node without some additional layers and Version: instance=Geth/v1.3.8-c6aeee20-20240123/linux-amd64/go1.21.6
Have the same behavior, Request works and result is the estimate Gas as expected, only Defichainnode returns an incorrect result.

[LXHLeaner]

@sieniven @Stonygan @ldenman @kuegi When will this Defichainnode problem be solved?

[sieniven]

This issue will be resolved once the PR #2808 is merged.