Skip to content

FMA for Cannon updates for Go 1.23 and Kona #279

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

pauldowman
Copy link
Contributor

Adds an FMA for Cannon updates for Go 1.23 and Kona.

Closes ethereum-optimism/release-management#323

@pauldowman
Copy link
Contributor Author

@mbaxter could you take a look and see if you have anything to add or change?

Copy link
Contributor

@mbaxter mbaxter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the feature toggles section might need to be adjusted a bit to reflect the latest code, but generally looks good to me 👍

@pauldowman pauldowman changed the title Begin FMA for Cannon updates for Go 1.23 and Kona FMA for Cannon updates for Go 1.23 and Kona May 21, 2025
@pauldowman pauldowman marked this pull request as ready for review May 21, 2025 23:24
@pauldowman pauldowman requested a review from mds1 May 21, 2025 23:24
Comment on lines +81 to +89
### FM3: New dclo/dclz instructions are incorrectly implemented

- **Description:** There are two new instructions, there could be a bug in the implementation. They aren't used by op-program, but would be used if we ever deployed Kona on Cannon.
- **Risk Assessment:** low
- **Mitigations:**
1. These instructions aren't emitted by the Go compiler, so behavior should not affect the VM when running op-program
2. If we ever do deploy Kona on Cannon we will do more testing, including running it on mainnet data for weeks in VM Runner.
- **Detection:** The program would crash if it used those instructions and they were incorrectly implemented.
- **Recovery Path(s)**: It would require fixing the bug and upgrading the contract.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there other onchain changes we'd need to ship kona to prod? i.e why we are shipping these to production if we aren't going to use them in production, is this to help roll out kona incrementally in some way?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe these are the only changes needed. They're included here because it gives us the option to use Kona with Cannon if needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does it mean to use Kona with Cannon, does that require a governance proposal and new prestate? What does "if needed" mean, i.e. is this part of our runbooks somewhere?

(I thought Kona was intended to be used with Asterisc, so this is a generic question as to why we are shipping these instructions, since I'm not up to speed with what the kona/asterisc plan is)


### FM4: Incomplete Go 1.23 support (missing syscalls)

- **Description:** It's possible that the Go 1.23 compiler uses additional syscalls that we haven't noticed and they aren't implemented.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we typically notice the new syscalls that we need to implement? It sounds like this is empirically based on running the challenger, as opposed to e.g. go release notes giving us this info?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two ways:

  1. vm-compat is a tool that runs in CI and detects new syscalls referenced in the op-program binary (I added this to the text).
  2. op-challenger-runner continually runs op-program against mainnet blocks

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's interesting that both ways are empirical, and there's no concrete docs we can reference to get a full list. That means pretty much every Go bump will have this failure mode?

- **Mitigations:**
1. We have comprehensive differential testing on all VM instructions, which should catch any potential refactoring-related bugs
2. This is a trivial refactoring
- **Detection:** We rely on our tests.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar comment to the above about how this gets detected in production

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no generalized automatic way to catch a bug, but this refactoring was pretty trivial and has been audited.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a more broad framing: for a lot of these, given that we typically don't run op-program in prod, do proofs failure modes typically surface in production in the same way you described in #279 (comment), i.e. the VM runner would catch it?

| Created at | 2025-05-02 |
| Initial Reviewers | Meredith Baxter |
| Need Approval From | Matt Solomon |
| Status | Implementing Actions |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we have no actions we can do this:

Suggested change
| Status | Implementing Actions |
| Status | Final |


Below is what needs to be done before launch to reduce the chances of the above failure modes occurring, and to ensure they can be detected and recovered from:

- [ ] Resolve all comments on this document and incorporate them into the document itself (Assignee: document author)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and similarly to above, this

Suggested change
- [ ] Resolve all comments on this document and incorporate them into the document itself (Assignee: document author)
- [x] Resolve all comments on this document and incorporate them into the document itself (Assignee: document author)

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

Successfully merging this pull request may close these issues.

[U16] FMA for Cannon updates to support Go 1.23 and Kona
3 participants