unexpected eth_call behavior in pending opt

[huahuayu]

hi, since eth_call have a pending opt for query based on the pending stats, I do a test as below.

I send a tx which can change some stat variables, and I check the stat variable before and after sending it,

I expected to get different results, but the results are identical.

[rjl493456442]

Can you extend the sleep interval a bit longer? Perhaps the node hasn't included your transaction into the pending state. Or perhaps your transaction isn't executable?

[huahuayu]

hi @rjl493456442 I write some code to demonstrate the problem https://github.com/huahuayu/ethcall

I'd rather say it's gas estimation problem, eth_call with pending opt is working fine, but gas estimation is not.

[huahuayu]

for a workaround, if only I can do eth_call for not just view function but transactions, so I can use it to replace gasEstimation for some cases.

[rjl493456442]

I think you have to wait the first transaction to be mined first. You can use accounts/abi/bind.WaitMined for waiting.

[huahuayu]

I want to predict the tx success or not before it gets mined, as the EstimateGas comment says, it is based on the current pending state to do the estimation, since TransactionByHash returns isPending = true, so it's included to the mempool, why the estimation is not accurate?

    // EstimateGas tries to estimate the gas needed to execute a specific
    // transaction based on the current pending state of the backend blockchain.
    // There is no guarantee that this is the true gas limit requirement as other
    // transactions may be added or removed by miners, but it should provide a basis
    // for setting a reasonable default.

[rjl493456442]

The result returned by the TransactionByHash can't indicate your transaction is included in the pending block. It only shows that the transaction is sitting in the txpool. So I would recommend to use wait the first transaction(the one to send ether to contract) to be mined, or you can subscribe the pending transaction for notification.

[rjl493456442]

// NewPendingTransactionFilter creates a filter that fetches pending transaction hashes
// as transactions enter the pending state.
//
// It is part of the filter package because this filter can be used through the
// `eth_getFilterChanges` polling method that is also used for log filters.
//
// https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter

[rjl493456442]

Btw, I guess I do understand your requirement for estimating/predicting a batch of transactions before sending them out. We do have a PR for it but it's not decided whether the feature is wanted or not. https://github.com/ethereum/go-ethereum/pull/21268

[huahuayu]

So I would recommend to use wait the first transaction(the one to send ether to contract) to be mined.

I only care about pending tx, and btw I test in ropsten network with 10Gwei the tx should be in the pending block right?

can't indicate your transaction is included in the pending block

so how can I manually make it's in pending block, at least in my client.

or you can subscribe the pending transaction for notification

Do you mean the txhash NewPendingTransactionFilter is all in pending block rather than pending stats

[huahuayu]

Did you run https://github.com/huahuayu/ethcall ? The inconsistency is that eth_call with pending opt has perceived the stat variable change, but gasEstimation doesn't?

[rjl493456442]

I tried your code and nothing wrong to me. It's on the goerli testnet.

test contract deployed:  0xd0413F5E44F06Abeb927e28572bc753Bd483D8Fb
sleep for 20 seconds to make sure test contract deployed
sendEth tx 0x3be4f40143814c2bc565cfd3380c533fa10d097d875de3a3595abe07f0bca3e0 balanceBefore 0, balanceAfter 1
txHash: 0x3be4f40143814c2bc565cfd3380c533fa10d097d875de3a3595abe07f0bca3e0 isPending true
eth_call result: balance after  1
sendEthBack tx 0xb5abc85140fae47d610e2e9f34a3e485006e07c10a2b1af44db1361f0c24e358 balanceBefore 1, balanceAfter 0
sendEthBackSimulation success! 3761053

[huahuayu]

Could you please just go run main.go it's in ropsten network. I don't know why there's a difference.

[huahuayu]

Btw, I guess I do understand your requirement for estimating/predicting a batch of transactions before sending them out. We do have a PR for it but it's not decided whether the feature is wanted or not. #21268

this is helpful

[rjl493456442]

@huahuayu I guess it's the nondeterministic error. I can't reproduce it. But I still recommend you to try some different approaches to have some strong correctness guarantee if you are making your own client. I will close it now if you think #21268 is helpful. But feel free to reopen it.