Rewrite MIPS.sol in Huff

[0xClandestine]

Is your feature request related to a problem? Please describe.
Yes, the main concern in this issue is gas usage. MIPS.sol could benefit from a rewrite in Huff, as well as formal foundry testing. It is crucial to optimize the fault proving process as much as possible given it lives on L1.

Describe the solution you'd like.
I would like to request a rewrite of MIPS.sol using the Huff language.

Additional context
I imagine the implementation would look something like the HyVM by Nested.fi.

PS I'd be glad to create a PR for the rewrite! 🫡

[protolambda]

Gas-usage is not the primary usage concern here, as the step-function only has to be efficient enough to be covered by bonds, and correctness of code is critical.

I still welcome a Huff version proposal, and have heard arguments from @clabby to use Huff as well, but for now Cannon is using Solidity. Correctness is very important here. Maybe there are ways the Huff version can make it easier to audit / formally verify? Happy to hear if you have any tooling recommendations (in addition to foundry ofc).

Also note that we're in the process of migrating Cannon into the Optimism monorepo: ethereum-optimism/optimism#6050 So please open up any PRs on top of that branch instead of this repository.

And while the smart-contracts have full coverage through custom Go testing, we're definitely interested in foundry test contributions (perhaps through FFI, or a build step, to generate VM states using the Go code).

[clabby]

^ I'd obviously be all for it in theory, but @protolambda raises good points. Correctness is critical here, and not only is Huff harder to make correct / audit / maintain, the compiler is less battle tested, not audited itself, etc. This is probably the #1 reason why I'm less for it in the beginning.

In the longer term, for something like the VM, Huff would make more sense due to all of the code being low-level anyways. i.e., we can break up all of the different syscall / opcode handlers into separate macros for easy auditability + zero gas penalties, use jump tables for the super nested conditionals, and more. The big advantage to writing it in Huff as mentioned above would be to reduce branching / make it more easy to formally specify - that'd be a big win in security with an added side benefit of gas efficiency.

This is theoretically the most important smart contract code we'll have, but due to the incentive compatibility of the game, it should rarely run. Because of this, correctness trumps all else in terms of priorities.

[0xClandestine]

@protolambda @clabby, First of all, thanks for your responses!

I agree that ensuring correctness is crucial, especially considering the infrequent execution of the contract. Given the absence of a formal audit for Huff, one viable option could be a pure Yul rewrite, which could still bring significant value. Another possibility is to consolidate everything within a Solidity Fallback function, providing a comparable level of low-level control.

In the short term, it makes sense to proceed with the current implementation, considering its battle-tested nature. However, in the long run, implementing Huff could prove advantageous, as highlighted by @clabby. At the very least, I believe it would be worthwhile to proceed with the rewrite to establish a baseline and assess the potential benefits it may offer.

Will make a PR in the monorepo once I get some time.

[clabby]

Will make a PR in the monorepo once I get some time.

Sounds good - if you want to pursue this, would be glad to help / support where I can. I think that for production use, a pure Yul rewrite would be more likely to be considered in the short->medium term, but Huff gives a lot of advantages that Yul does not (aside from some of the aforementioned downsides on the security side of things).