search

filecoin-project / ref-fvm

Reference implementation of the Filecoin Virtual Machine
https://fvm.filecoin.io/
Other
379 stars 134 forks source link

FEVM: Contract upgrades & SELFDESTRUCT #1174

Closed Stebalien closed 1 year ago

Stebalien commented 1 year ago

In the EVM, users can loop CREATE2 and SELFDESTRUCT to repeatedly re-deploy contracts at specific addresses. This is currently used to:

  1. Perform some nasty gas-saving hacks.
  2. Perform in-place upgrades without proxies.
  3. Strange things where contracts only exist ephemerally.

We have a few options:

  1. Allow for this. We can do this entirely in userspace by:
    1. Making SELFDESTRUCT replace the code with "empty" code, but not actually delete the actor.
    2. Having the EAM deploy over empty EVM contracts. Well, really, allowing the EAM to call the EVM's "constructor iff there's no code deployed.
  2. Allow for this in the system itself. HAHAHAHAHAHA. No. Deletion is final. This is a really important security property. Once code has been deployed to an address, that actor is in charge. Otherwise, the actor that deployed the code can change things later.
  3. Add userspace upgrades #654 back into the scope to partially support this flow. However, we'd likely have to implement this via a precompile... which is sketch.
  4. Don't support this entirely. Unfortunately, this does remove a nice "self-upgrade" workflow.

:sob:

Stebalien commented 1 year ago

(found by @wadeAlexC)

raulk commented 1 year ago

Perform in-place upgrades without proxies.

This is how this pattern gets used in practice: https://ethereum-blockchain-developer.com/110-upgrade-smart-contracts/12-metamorphosis-create2/

raulk commented 1 year ago

Perform some nasty gas-saving hacks.

I am quite confident discarding this motivation on our end, as the mechanics at play there are Ethereum (blockchain) specific and not EVM (runtime) specific. We excised Ethereum gas logic, so I don't see a reason we should be driven by Ethereum gas tricks anyway.

Perform in-place upgrades without proxies.

FEVM's goal is not to match 1:1 exactly every single dark corner of the Ethereum chain. But rather to allow devs to port their smart contracts with none to little adjustment (to then leverage Filecoin storage features). The key questions here are:

  1. How frequently used is this feature in existing Ethereum smart contracts, generally?
  2. How frequently used is this feature in Ethereum smart contracts that devs will want to port as-is? (e.g. usually building blocks and nuts and bolts, like tokens, AMM/DEXes, DAOs, etc.)
  3. How feasible is it to modify those contracts to use another technique to achieve the same outcome? What is the tradeoff? (in this case, traditional proxies)

I think (3) is the key here -- there is already another way to achive the same outcome, so I'd be happy marking this as "not supported" (advising that actor upgrades are in the feature roadmap for FVM anyway) and advising to adopt the proxy pattern instead. It will be less gas optimized, but fair tradeoff IMO.

Strange things where contracts only exist ephemerally.

Any clue what the motivations here are? (no need to research if we don't know off the cuff)

Side question: how would supporting this dark corner be different to offering a precompile to mutate the EVM bytecode of the caller?

wadealexc commented 1 year ago

Answering your questions --

  1. How frequently used is this feature in existing Ethereum smart contracts, generally?

Very infrequently. I haven't personally encountered this pattern, and I've reviewed a lot of Eth contracts! That said, EVM devs are aware of its existence and there are some folks who use it in larger prod systems (as opposed to personal use). I asked around and got a few answers:

  1. How frequently used is this feature in Ethereum smart contracts that devs will want to port as-is? (e.g. usually building blocks and nuts and bolts, like tokens, AMM/DEXes, DAOs, etc.)

I can't think of any examples. I would say likely never.

  1. How feasible is it to modify those contracts to use another technique to achieve the same outcome? What is the tradeoff? (in this case, traditional proxies)

If these projects want to redeploy, there are almost certainly other patterns that should work for them - maybe with the exception of Revest Finance? I don't think this question is too important to worry about.

Strange things where contracts only exist ephemerally.

Any clue what the motivations here are? (no need to research if we don't know off the cuff)

If I had to guess, the use case is for MEV searcher bots that want:

MEV searchers are all about gas though, which I think we've stated isn't as much of a concern. I don't know of any ephemeral contracts that have seen wide use outside of this (with the exception of Revest Finance, I guess!).

Side question: how would supporting this dark corner be different to offering a precompile to mutate the EVM bytecode of the caller?

The difference is just in EVM compatibility - the proxy pattern is already sufficient for the above concept, and I don't think anything here warrants a precompile.

wadealexc commented 1 year ago

Additional note -- seems popular sentiment is that EIP-4758 is likely to be accepted during the "Purge" stage of Ethereum development, and that this pattern will be deprecated / won't function. The idea behind 4758 is to replace SELFDESTRUCT with a different opcode, SENDALL, which sends the entire balance of the receiver to some beneficiary, without executing code.

The behavior of SENDALL is why a lot of people like using SELFDESTRUCT - because you can send funds without executing code.

EIP discussion is ongoing here: https://ethereum-magicians.org/t/eip-4758-deactivate-selfdestruct/8710

wadealexc commented 1 year ago

Okay, and finally -- something to consider here is EVM feature parity for "feature parity's sake."

If someone wants to build Layer 2 systems on top of the FEVM, they may use optimistic execution verification patterns of the same sort that are being widely talked about / implemented in Eth land today.

For each deviation from EVM parity, additional tweaks need to be made to these systems to allow deployment onto the FEVM. It may be worth being as compatible as possible to allow these projects to redeploy easily onto Filecoin.

Stebalien commented 1 year ago

Closing in favor of #1221