FMA for Cannon updates for Go 1.23 and Kona #279
Conversation
|
@mbaxter could you take a look and see if you have anything to add or change? |
pauldowman
changed the title
| ### 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.
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.
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.
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.
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.
There are two ways:
vm-compatis a tool that runs in CI and detects new syscalls referenced in the op-program binary (I added this to the text).op-challenger-runnercontinually runs op-program against mainnet blocks
There was a problem hiding this comment.
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.
Similar comment to the above about how this gets detected in production
There was a problem hiding this comment.
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.
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.
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.
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