op-program: Use cannon release for reprod builds

[Inphi]

Introducing new cannon state versions breaks the reproducible-prestate build. This is because the locally-built multicannon program is not aware of older state versions. We need to be able to continue cannon development without breaking the reproducible-prestate workflow.

To fix this, the reproducible-prestate build is updated to use a cannon release that supports all state versions. The cannon/v1.4.0 docker image is used for this purpose. This makes local development a bit inconvenient as users have to login to GCP in order to build the prestates.

[Inphi]

cc @sbvegan. What you think about the gcp login requirement with this change?

[sbvegan]

@Inphi generally when we provide guidance on verifying prestates, we tell permissionless fault proof chain operators to run the make reproducible-prestate command. To be able to independently verify they're getting the same output. The next level of verification that we're looking to show external operators is the check-prestate script.

If folks are still able to do that for more official releases and release candidates, I think this is fine. Otherwise, we'd need to figure out a way permissionless chain operators can independently verify they're using the correct absolute prestates.

[ajsutton]

I don't think I understand this change properly. The version of cannon used here is from the same commit as the op-program that was just built. So the version of cannon at that commit has to support the state version you're trying to create or we don't really have a reproducible build (it depends on something not in the git repo).

Is there an example of where this is actually breaking?

[Inphi]

I don't think I understand this change properly. The version of cannon used here is from the same commit as the op-program that was just built. So the version of cannon at that commit has to support the state version you're trying to create or we don't really have a reproducible build (it depends on something not in the git repo).

@ajsutton The trouble with using the same commit as the op-program is that we may need a new op-program prestate release before the cannon STF is feature-complete, audited and ready to be proposed to governance.
Consider the go1.23 work as an example. If a maintenance upgrade to the op-program is required, that becomes blocked by an audit and governance approval of the go1.23 VM changes. In this scenario we'd have the following events:

1. Prep cannon for go1.23 compatibility
2. Update mt64 cannon state version to 4
3. op-program maintenance upgrade is required
4. (At some point in the future) mt64-4 is feature-complete and audited; proposed to gov
5. Create op-program rc for a maintenance upgrade
6. Propose new op-program rc to governance

And it could take a while for steps 3 and 4 to be end.

A more likely example is any new chains, or config updates, to the superchain-registry would require a new op-program rc. An older op-program rc wouldn't have the new configs, but the latest op-program rc may be tied to an unreleased cannon state version / stf.

[mbaxter]

Do we need 2 different versions of make reproducible-prestate - one that targets develop and one that targets the latest release? For example, the publish-cannon-prestates CI task publishes prestates from develop that we use in the vm-runner. Seems like those should target the latest version in develop.

And I think the e2e tests use the reproducible-prestate. Should those be running on the latest version or the latest release?

[Inphi]

Do we need 2 different versions of make reproducible-prestate - one that targets develop and one that targets the latest release? For example, the publish-cannon-prestates CI task publishes prestates from develop that we use in the vm-runner. Seems like those should target the latest version in develop.

And I think the e2e tests use the reproducible-prestate. Should those be running on the latest version or the latest release?

I believe so. For now I'm going with a single prestate build that uses the most recent governance-approved state version. I'll figure out how to integrate latest cannon later.

[ajsutton]

This really feels like we're doing feature toggling wrong. The latest develop should always be releasable so if it can't build the prestates we need we've merged something bad and lost that always releasable invariant. It seems to me that we need to work out how to build cannon STF changes and the new state version in a way that develop supports both the current and next versions, then when the next version is fully approved we drop the older one from develop and support for it gets pulled into cannon from an older release.

On the go side, that's quite easy to do - we just have a field somewhere that tracks what state version we loaded from and anything that changes is wrapped in an if stateVersion == 0 { doV0() } else { doV1() } kind of thing. Solidity is a bit more challenging but we must keep the solidity in develop releasable as well or we can't cut a new contracts release safely. So it will need to do something similar or have an immutable variable set on deployment that acts as the feature toggle.

However we approach it, we need to keep develop releasable - we can work around generating a prestate like this, but we can't block contracts releases by having unshippable changes in the solidity side merged into develop. That needs to be properly feature toggled.

[Inphi]

Closing this in favor of using feature toggles to build prestate versions.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 0.00%. Comparing base (03f8875) to head (72ec996).
Report is 26 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop   #15377       +/-   ##
============================================
- Coverage    46.45%        0   -46.46%     
============================================
  Files         1227        0     -1227     
  Lines       103054        0   -103054     
============================================
- Hits         47876        0    -47876     
+ Misses       51803        0    -51803     
+ Partials      3375        0     -3375     

Flag	Coverage Δ
cannon-go-tests-32	?
cannon-go-tests-64	?
contracts-bedrock-tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

see 1227 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.