-
Notifications
You must be signed in to change notification settings - Fork 44
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
base: main
Are you sure you want to change the base?
Conversation
@mbaxter could you take a look and see if you have anything to add or change? |
There was a problem hiding this 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 👍
### 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two ways:
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).op-challenger-runner
continually runs op-program against mainnet blocks
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 | |
There was a problem hiding this comment.
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:
| 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) |
There was a problem hiding this comment.
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
- [ ] 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) |
Adds an FMA for Cannon updates for Go 1.23 and Kona.
Closes ethereum-optimism/release-management#323