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
{{ message }}
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.
In our project we are using the alpha version of Ganache to create forks and then call eth_call through Ganache's request method. We have noticed two strange behaviours:
Calling eth_call this way is dramatically slower than calling it directly (118s vs 0.7s)
The returned data is not right
We wrote the following code so you can replicate it and see the behaviour in action. We are running it with:
Thanks for the issue! I've confirmed that this is still a bug against the develop branch.
Interestingly, ganache doesn't forward eth_call's to blocks before the fork to the original node, but instead executes everything locally. This means we have to fetch any state that the transaction interacts with at runtime.
A couple of reasons for doing this
we currently apply ganache's hardfork rules, not historical rules to eth_call. This will change for "known chains" once fix: make forking chainId aware #1537 is merged.
We plan on allowing users to alter historical state, which requires we run the transaction locally.
remote nodes usually have an upper bound for how long an eth_call call is permitted to run. Ganache doesn't currently limit the execution time.
But I agree with you... waiting 200x longer than you should is annoying just for handling these little edge cases! So I think we should solve them by:
setting a "dirtyState" flag and only running locally if historical state has been altered.
try the eth_call via the remote node first (or simultaneously), and fall back to local only if it fails due to timeout reasons.
As for the actual bug here... I'm not sure what is causing the difference in results, as the hardfork rules should match in this case. I'll likely need to diff a transaction trace between ganache and a geth to find where we go wrong.
Thanks again for opening the issue. Hopefully we can get to the bottom of it soon!
I believe the problem here is that Ganache is using the wrong block baseFee when executing the eth_call's message. Ganache calculates the next blocks's base fee, instead of just using the specified block's base fee. This is a bug and will be fixed in a future release.
In our project we are using the alpha version of Ganache to create forks and then call
eth_call
through Ganache'srequest
method. We have noticed two strange behaviours:We wrote the following code so you can replicate it and see the behaviour in action. We are running it with:
Code to replicate the behaviour:
The text was updated successfully, but these errors were encountered: