cannon: Multi VM executor #12072
cannon: Multi VM executor #12072
Conversation
![semgrep-app[bot]](https://avatars.githubusercontent.com/in/60555?s=60&v=4){kind=small}
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #12072 +/- ##
============================================
- Coverage 79.10% 68.14% -10.97%
============================================
Files 41 54 +13
Lines 3437 4119 +682
============================================
+ Hits 2719 2807 +88
- Misses 548 1134 +586
- Partials 170 178 +8
Flags with carried forward coverage won't be shown. Click here to find out more.
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Semgrep found 1 Named return arguments to functions must be appended with an underscore ( |
There was a problem hiding this comment.
LGTM generally. I suspect we should just skip the .git folder access in docker for now since we aren't (yet) supporting old versions and can revisit how best to do that. And it's probably worth following up to work out if we can be more flexible with CLI arg changes but it won't be an issue for now.
Overall I think this is a useful tool in the toolbox and enables the really neat 64bit migration approach you came up with so worth having. I'm not sure it should always be the approach we use for compatibility to be honest and a fork in the STF might be a better approach in simple cases (just like we support multiple hard forks in op-node). At the moment the two approaches are a bit mutually exclusive since we need a separate binary for every state version but we could investigate ways to avoid that in a follow up if we need to.
The thing that makes me nervous about just using a fixed old version for backwards compatibility is if there's some reason we do need to make changes to it like fixing a bug, tweaking a CLI arg etc that doesn't affect the state outcome but is needed for some reason. We could potentially create a fork to do the fix on but it gets messy. I think we can work to improve things over time though if we need to - right now this is a really good way to unblock the GET_FD change and the 64bit migration.
|
Semgrep found 2 Inputs to functions must be prepended with an underscore ( |
|
Merging as soon as CI passes. |
* cannon: Multi VM executor * fix run subcmd arg fwding * fix mt prestate * add list subcmd; multicannon in op-stack-go * remove cannon-latest * safer strconv * lint * include .gitkeep in embed * fix .git copy * add detect.go tests * add nosemgrep * review comments * list filtering * add note to MIPS.sol in version stf ref * use fork-exec * minimal flag parsing * load old cannon binaries from docker images * note * --help flag defaults * remove redundant copy from cannon-builder-0
Multicannon is a cannon wrapper that can be used to load and run Cannon states using a variety of Cannon FPVM implementations. This solves the issue of supporting older versions of the Cannon FPVM STF, without introducing branching logic into the STF. See ethereum-optimism/design-docs#88 for more details on the rationale.
Multicannon mimics the same CLI as regular
cannon, and in a couple subcommands, requires an additional--versionflag to be specified where it cannot autodetect the VM implementation to use. The--versionflag is used to locate the appropriate cannon FPVM program to use.The run subcommand autodetects the appropriate VM implementation to use by inspecting the input state file. The
StateVersionin the state file indicates the Cannon VM implementation to use.Multicannon also supports a new
listsubcommand that displays the embedded cannon VMs and their versions.Annoyances
An embedded cannon binary must exist for every version supported by multicannon. This is wasteful in the case of single-threaded and multi-threaded VMs as a single cannon VM implementation supports both using the
--typeflag.Adding additional Cannon VMs
Easiest way to do this is using the op-stack-go Dockerfile. Whenever the Cannon VM STF is altered, a new
StateVersionmust be created. A Github tag can then be created for the change. This tag can be referenced when building the op-stack-go docker image to build an older version of cannon into thecannon/multicannon/embedsdirectory. When multicannon is built, it becomes aware of all cannon VM binaries found in the embeds directory.