Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback to remote execution in case of cadence arch calls #579

Closed
Tracked by #574
sideninja opened this issue Sep 25, 2024 · 1 comment
Closed
Tracked by #574

Fallback to remote execution in case of cadence arch calls #579

sideninja opened this issue Sep 25, 2024 · 1 comment

Comments

@sideninja
Copy link
Contributor

sideninja commented Sep 25, 2024

An EVM Call (contract view function call) can use the Cadence arch function, the problem is, because we don't have the complete Flow environment setup locally we can not produce the results for those methods. One example is: we have a generate secure revertible random cadence arch function, because EVM GW doesn't have access to the random beacon we can not produce those results locally. So the call will fail.
This problem was solved for transactions in a way that during the transaction execution on EN, the input/output produced by this call is recorded and then added to the EVM transaction executed event, and locally on the EVM GW when we re-execute that transaction we mock the call to the cadence arch because we know the output it should produce. The problem with calls is that we don't execute them on EN by default, so we can't know what the cadence arch should return when we re-execute them locally.

One solution is to make sure all the failed calls have fallback to being executed on EN, so in that case we would still produce the correct result which would be returned to the client, while still offloading the EN with all successful calls.

This could be further improved by detecting the reason the call failed, and if that reason is that it failed to call cadence arch function we would fall back to EN. I think this is not worth optimization at this point unless proven different with metrics. Both failed calls and especially cadence arch calls are a minority of requests.

@j1010001
Copy link
Member

no longer needed, moving to dry-run solution (onflow/flow-go#6539)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants