search

ethereum-optimism / design-docs

MIT License
27 stars 20 forks source link

Add cannon upgrade design doc #64

Closed ajsutton closed 2 months ago

ajsutton commented 3 months ago

Description

Draft of a doc to determine a roll out plan for cannon MT and cannon 64-bit.

Inphi commented 3 months ago

Good doc. I'll add that we don't have to be fancy with regards to backwards-compatibility. Create a snapshot of cannon-32 today and keep it in a separate directory and Go module, cannon32, stored in the monorepo. Then continue multithreaded and 64-bit development in cannon. We retain the benefits of running both VMs in our tests. And If need be, introduce a shim program that uses either VM. Fixes to current cannon (cannon32) can be done upstream without having to backport anything.

Inphi commented 3 months ago

And I'm onboard with implementing 64-bit and MT Cannon as a single feature.

ajsutton commented 3 months ago

I spiked out supporting both versions in a single cannon version and it works out pretty well: https://github.com/ethereum-optimism/optimism/pull/11467 though the diff looks pretty intimidating. We're essentially duplicating the mipsevm package to have mipsevm32 and mipsevm64 - the diff would be a lot smaller if we left the legacy version as just mipsevm. I also removed the multithreaded impl from the 32 bit version and removed the single threaded version from the 64bit VM.

It's a little complicated to start from everything upgraded to 64bit and try and undo the single threaded upgrade - we could do it in smaller steps if we started from the current develop, introduce the abstractions and pull out code that can be shared, then split mipsevm into mipsevm32 and mipsevm64 and then apply the 64bit upgrade to mipsevm64. Will be much more reviewable that way.

ajsutton commented 2 months ago

Going to close this - cannon now detects multithreaded or single threaded based on the prestate and we think rolling out 64bit with backwards compatibility will be doable. I'm not sure this design doc actually reflects all the discussion that wound up happening elsewhere (GitHub is not a great venue for async discussion really) so won't merge it. The plan only affects the proofs team anyway so doesn't need wider buy-in.