Creating a contract via `eth_call` should return the return value of the init code

[raulk]

This is a mischievious edge case that has gone unnoticed (AFAIK) for a few years, yet it was uncovered while investigating a report from Recall folks.

Original report

Running this script to deploy Safe on an IPC subnet fails due to an eth_call returning an empty return value. This is the error thrown by the script.

Luckily, our reporter was able to isolate and reproduce the issue with a single request:

$ curl -s https://... \                               
  --header "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [
      {
        "data": "0x604580600e600039806000f350fe7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3"
      },
      "latest"
    ],
    "id": 1
  }'
{"jsonrpc":"2.0","result":"0x","id":1}

Whereas running this request against Sepolia returns the following:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3"
}

The script in question is verifying the chain's behaviour by simulating the deployment of a minimal CREATE2 factory contract via eth_call, and expecting the node to return the effectively deployed bytecode after evaluating the supplied initcode. It then goes on to perform a hash assertion on that value, which fails.

What's going on?

When a contract is deployed, the bytecode sent as data in the deployment transaction is interpreted as the "initcode". Whatever value is RETURNed from the initcode becomes the effectively deployed bytecode on-chain.

In Ethereum:

• When executed in the context of a transaction, the node elides the return value from the transaction receipt (probably for efficiency reasons).
• When executed in the context of a call, the node does not override the default behaviour and simply propagates the return value from the EVM in the response.

In Filecoin:

• The EAM (Ethereum Address Manager) doesn't return the deployed bytecode to the client.
• In our design, the EAM creates the EVM actor via the InitActor, which in turn creates the actor in the state tree and invokes its constructor supplying the initcode. The EVM constructor evaluates the initcode and stores the bytecode in its own state, i.e. all our deployment logic sits in actors and is well encapsulated, whereas in Ethereum the client is responsible for updating the state tree. Hence the client must have access to the return value.

Easy solution

The affected behaviour is not consensus-critical. The mismatch could be patched in the Eth JSON-RPC server by querying the saved bytecode after a contract deployment call for first-order contract creations. For indirect creations, there's nothing to worry about (CREATE* opcodes don't return the bytecode anyway).

I guess the hard part is querying the "intermediate" state tree from the Eth JSON-RPC server implementation in Lotus. But there's several ways to overcome that implementation detail.

[Stebalien]

This is related to #11635. The only tricky part there was handling contracts that self-destruct and re-create themselves in the same transaction where they're constructed.

But this looks like a strict-subset: all we care about is eth_call where the "to" address is empty. This should be pretty straight-forward.

[raulk]

Yeah I think this can be patched independently of the other issue. And if the latter ends up resolved, we could migrate to that solution if needed, with no impact to clients.

[raulk]

(Dropped a comment there.)

[ameeetgaikwad]

if this is a good first issue, would like to pick it up

[rvagg]

not a good first issue unfortunately @ameeetgaikwad, it's a bit too involved in fishing around in temporary state, which we currently don't have good access to where it's needed so there's a lot of plumbing work needed too

[ameeetgaikwad]

alright!

not a good first issue unfortunately @ameeetgaikwad, it's a bit too involved in fishing around in temporary state, which we currently don't have good access to where it's needed so there's a lot of plumbing work needed too

[stbrody]

Note this is a blocker for the Recall team - we need this fixed in order to get the Safe contracts deployed on our chain for multi-sig support.

Is there any estimate of when we think this could get fixed and deployed by?

[rvagg]

Re timing: unfortunately this is probably going to rely on me to get this done but I'm stretched for time at the moment. I have a backlog this week and then I'm on a break for a couple of weeks, bumping right up to FDS. Unless it happens to easily fall out of existing work then it may not get seen to for at least a month.

Here's how I see what probably needs to be done here, or at least some of the related work:

• fvm recently got a superpower to flush_all_blocks @ feat: add flush_all_blocks option to also write intermediate blocks ref-fvm#2101 that lets us capture intermediate blocks during execution for debugging purposes
  • fvm@4.7.1 still needs to be pushed up through filecoin-ffi and to here for this to become usable
  • I've been working on a debugging feature that uses this @ feat(exec): dump intermediate cache blocks from FVM exec in StateReplay #12822 so I'm actively trying to get this landed and usable
• We're currently discussing what StateCall / StateReplay / StateCompute look like in the new /v2 APIs and we have users who need something available, but we're also trying to reduce the duplication and introduce a single call that's a bit more flexible, which would do things like "capture all intermediate blocks". Unfortunately there's a bunch of breakage to /v1 APIs to do what we want, so I'd like to just throw those 3 out and replace them with one that takes a nice options struct that gives us room to move to do what we need.
• But ^ completion of that is not strictly necessary to make progress here, we just need the internal bit done so we can actually make the call and capture intermediate state and state roots and pass them back up to the Ethereum code.
• From what I understand from the excellent description above by @raulk, this is the critical piece of code where we need to inject some new logic:

  lotus/node/impl/eth/gas.go

  Lines 255 to 256 in a8999cb

  	if msg.To == builtintypes.EthereumAddressManagerActorAddr {
  	return ethtypes.EthBytes{}, nil

  - at that point we make an assumption that it's a CREATE (assumption should hold here). Once we have intermediate blocks we can load the in-memory blockstore and fish around with the message execution's state root to get the saved bytecode and return that.

I got https://opt-sepolia.g.alchemy.com/v2/demo to respond as was suggested above, so 👌 .

Do we know what 0x604580600e600039806000f350fe7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3 decompiles to? Or does it not matter?

I can get it down to 0x604580600e600039806000f3 and still get a non-empty response.

[brunocalza]

hey @rvagg thanks for looking into this. I'm the one that raised the issue to @raulk

Do we know what 0x604580600e600039806000f350fe7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3 decompiles to? Or does it not matter?

I assume that the bytecode is from the safe singleton factory contract I was trying to deploy. Although I don't think that should matter. Part of the process of deploying involves simulating the contract creation. That was when I ran into this issue. Simulating the contract creation is kind of critical for deploying the contract.