Supporting EIP-5656 (MCOPY opcode) in the Filecoin EVM runtime

[raulk]

Problem

This EIP was deployed to the Ethereum mainnet in the Dencun upgrade. (NB: It may have been added to the upgrade after we assessed compatibility with the Filecoin EVM, as otherwise we would've identified the divergence just like with #855).

Solidity v0.8.24 added support for MCOPY in Yul and inline assembly (requiring the dev to explicitly use it), and v0.8.25 added support in the code generator. The compiler now utilizes the MCOPY opcode to optimize operations like ABI encode and decode, unlike it happens with TSTORE/TLOAD, which requires explicit inline assembly. More here: https://soliditylang.org/blog/2024/03/14/solidity-0.8.25-release-announcement/

Impact

It is common for smart contract devs to use loose pragma ranges like pragma solidity ^0.8.0;. Often their tooling will install/use the latest stable v0.8 Solidity version published at the time. With time, more and more devs will end up using v0.8.25 — especially since v0.8.26 is GA too.

The IPC Core team recently debugged one such example here: https://filecoinproject.slack.com/archives/C04U4GPK3QR/p1719310936862459.

Workaround

The workaround is to downgrade to Solidity v0.8.24, but forcing devs to rely on outdated compilers is hardly a good solution.

Solution

We should add support for MCOPY to the Filecoin EVM. It should be pretty straightforward.

[raulk]

Pinging @trruckerfling as you're likely to encounter this in the wild.

[Stebalien]

Builtin actors issue: filecoin-project/builtin-actors#1457

[trruckerfling]

figuring out the FVM filoz/filb work allocation here - as EVM upgrades come in we'll face this more - @jennijuju for EVM actor, fair to say mikers pairs with oz on this?

[jennijuju]

@trruckerfling - if Mikers is up for it, we are def open! Let's take this offline!

[jennijuju]

There is a larger convo on whether filecoin should keep up with EVM in general - but this particular one seems well scoped and straight forward; and seems like IPC has a use case for it so I’m 👍🏻

@raulk I’m making a bold assumption that IPC team will drive an FIP and an implementation for this unless there’s major objections from other core devs/community members?

(Next upgrade window is proposed here fyi filecoin-project/core-devs#150 (comment)

[jennijuju]

I don't think it's even a conversation? 🤔

@anorth has raised this before here as well after seeing the original proposal from @Stebalien on this proposal here: the question is

What is our long term strategy for EVM support for Filecoin (noting there are different us involved: FVM team, Filecoin core devs, larger community, etc

I dont think any proposal on the strategy was published before the dedicated FVM team was dismissed (dismissed i meant a dedicated FVM wg was assembled to ship FVM with members from different filecoin teams, including engineering/core dev, BD, dev rel, partner and more), so this is kinda 🤷‍♀️. I can start a separate FIP discussion for the community to discuss on this topic tho! like i said in OP i don't think this strategy decision should block your proposal.

[jennijuju]

Keeping Filecoin/ref-fvm compliant with the EVM is a bit of a side quest for the team,

This is totally fair. However, if the feature is needed for IPC and it's user, would be nice for IPC team and its community to also contribute to FVM (public good) when they can imho.

[trruckerfling]

separate FIP discussion for the community to discuss on this topic

I think this is worth opening up as community discussion! It also helps set the community's expectations of our progress towards true EVM compatibility. We are not there right now and it leads to disappointing DX.

[trruckerfling]

My team wants to help FEVM gain parity with EVM and having consensus on whether it should happen/how its achieved will be super helpful.

[snissn]

I was looking at the EIPs all page - https://eips.ethereum.org/all and there are ~12 overall EIPs with the phrase "instruction" in their title like MCOPY. I think that's relatively little in the life of ethereum and it's worth solving this. I want to dive deeper into ensuring we are proactively aware of what EIPs we will need to support. For instance https://eips.ethereum.org/EIPS/eip-7516 is worth confirming compatibility with

[BigLep]

For visibility, this work is underway:

• FIP: FIP-0094: Add Support for EIP-5656 (MCOPY Opcode) in the FEVM #1047
• builtin-actors: feat(evm): add MCOPY opcode builtin-actors#1572