[SPIKE] EVM bytecode compatibility across SF networks

[d10r]

The solidity compiler has a configurable EVM version target, see
https://docs.soliditylang.org/en/v0.8.21/using-the-compiler.html#input-description

This defaults to what's deployed on Ethereum.
We don't currently have a process in place for ensuring that the bytecode we create is compatible with all EVM networks it's deployed to.

Task:
Investigate if there's any risks here / what they are / how to mitigate

[d10r]

example for an added opcode: https://eips.ethereum.org/EIPS/eip-3855

[d10r]

We indeed need to be extra careful with the switch to Solidity v0.8.20+, see OpenZeppelin/openzeppelin-contracts#4489 (comment)

Recommendation: explicitly set evm target to "paris" (prevent switch to the new default target "shanghai" which enables the new PUSH0 opcode not universally supported).

[hellwolf]

As of solidity v0.8.19, the default evm_version is paris, see https://docs.soliditylang.org/en/v0.8.19/using-the-compiler.html.

After solidity v0.8.19, the default evm_version is at least shanghai, see https://docs.soliditylang.org/en/v0.8.21/using-the-compiler.html

The shanghai evm version include a breaking evm upgrade that is "push0" op code. The concern is that not all EVM chains would keep up with this change at the same rate, and superfluid protocol has a implicit assumption that all networks are compatible to the extent what superfluid protocol is built against.

This assumption is now in jeopardy because of the inclusion of push0 op code, and the options we have are:

1. multi evm-target releases, where pre-shanghai and post-shanghai are two release targets.
2. configure solc to use paris evm target explicitly, in foundry see this
   • a related scenario is that, we still uses hardhat/truffle to test the contracts, we should also set them to paris target explicitly.

P.S.:

A oneliner for detecting PUSH0:

find out/default -name '*.json' | grep -v build-info | while read i;do echo $i;cast disassemble $(cat "$i" | jq -r .deployedBytecode.object) | grep PUSH0;done

So far we haven't managed to produce a single contract that contans the PUSH0 yet.