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

[Access] Use version beacon to ensure correct version for script exec #5040

Closed
4 tasks done
peterargue opened this issue Nov 20, 2023 · 3 comments
Closed
4 tasks done

Comments

@peterargue
Copy link
Contributor

peterargue commented Nov 20, 2023

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 to v0.1.1 at block 1000:

  • While running v0.1.0, if requests come for block 9999, they are executed successfully. If requests are for 1000, they are forwarded/fail.
  • While running v0.1.1, if requests come for block 9999, they fail. If requests are for 1000, 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

  • Access nodes run a module similar to StopControl that allows the caller to check if the current node software is compatible with the version at a particular block
  • This controller is integrated into the script execution module, and a sentinel is returned if a query tries to execute at a block that the node is not compatible with.
  • There is new configuration on ANs to specify if/how it should respond to the version beacon events:
    • Crash
    • Stop executing incompatible blocks
    • Do nothing (?? not sure if this should be built in)

Tasks

  1. S-Access
    Guitarheroua
  2. S-Access
    Guitarheroua
  3. S-Access
    Guitarheroua
  4. S-Access
    UlyanaAndrukhiv
@bluesign
Copy link
Contributor

bluesign commented Nov 21, 2023

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.

@peterargue
Copy link
Contributor Author

I think this does solve half of the problem ... after HCU scripts ran at lesser block height will have the same problem.

yea, we hadn't come up with a good solution for that yet

I think one possible solution is to use webassembly

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.

@bluesign
Copy link
Contributor

bluesign commented Nov 23, 2023

@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.

@peterargue peterargue self-assigned this Nov 24, 2023
@peterargue peterargue changed the title [Access] Add stop-control support to ANs for HCUs [Access] Use version beacon to ensure correct version for script exec Nov 27, 2023
@peterargue peterargue removed their assignment Apr 23, 2024
@peterargue peterargue added the Epic label May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants