-
Notifications
You must be signed in to change notification settings - Fork 179
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
[Access] Use version beacon to ensure correct version for script exec #5040
Comments
I think this does solve half of the problem, considering going forwards we will proceed with AN allowing to execute script at any height at spork, after HCU scripts ran at lesser block height will have the same problem. I was recently trying to figure out a solution for spork boundaries ( for tinyAN ) which has similar problem with fvm/cadence changes; I think one possible solution is to use webassembly for fvm/cadence combination. If needed version is not the running version, then use webassembly compiled execution engine to run script, otherwise use the native one. |
yea, we hadn't come up with a good solution for that yet
That's interesting. How would that work? We discussed an idea of mini sidecar APIs the just run the local script execution but weren't sold it was the right path forward. |
@peterargue basically I am playing with the idea of having an simple interface for executor. Then binding this executor via webassembly modules. So I will compile simple 2 methods API with in webassembly for flow-go/cadence combination, and for old sporks ( in this case post or pre HCU ) I will execute scripts with that module. |
Problem Definition
Now that Access nodes support local script execution, operators of nodes that use it will also need to upgrade whenever there is a new version of cadences/FVM release. This is typically done using a Height-Coordinated Upgrade (HCU).
Any new version of cadence/FVM may return different results from script execution. How common that will be with actual scripts is unclear when a change is deployed, but ANs must ensure they return accurate results.
At a minimum, operators should manually upgrade their nodes after the HCU to ensure scripts are executed using the latest version. Ideally, they could upgrade at the exact block.
Proposed Solution
Add support in Access nodes to use something similar to the
StopControl
used by execution nodes to pause execution during HCUs. This controller could be integrated into the script execution engine, and block script execution when the current software version is not compatible with the requested block.For example, given an upgrade from
v0.1.0
tov0.1.1
at block1000
:v0.1.0
, if requests come for block9999
, they are executed successfully. If requests are for1000
, they are forwarded/fail.v0.1.1
, if requests come for block9999
, they fail. If requests are for1000
, they are executed successfully.This should be simple to integrate into the existing API endpoints. There are already modes for script execution that support local only and failover the ENs. The controller will need to be integrated into the script executor module, and a sentinel returned when the block is not compatible.
Definition of Done
StopControl
that allows the caller to check if the current node software is compatible with the version at a particular blockTasks
The text was updated successfully, but these errors were encountered: