Remove the restriction on the "from" field when calling from a contract or identical address

[eshon]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

v1.31.1

Repro Steps

The following eth_call (via RPC) does not work on Calibration testnet but works on Eth Sepolia.
However it works on Calibration testnet when the "from" field is removed.

{ "jsonrpc": "2.0", "method":"eth_call", "params": [ {"data":"0x20c13b0b00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000002072444027d75a9dc204da4c533f689b7e7eb7a094c707324433dad0ae1f58ada700000000000000000000000000000000000000000000000000000000000001249f79f31d96faf6a4ff833f4e62575d75e1fdd684cd2ed907e62af2573338d3a971436d64a07d1f6d252c8e861e45389e53a3bdbec47fd966430ac1e9f47723ce1cff8ba3b2fc7bada8c74fbcd9be109d379adde0f43b8a363c80851f1126db3f8c167fd0feaa382dfba2fff958e2c0cb49bc740accc35e6776d780ecdbf7f5667c1c000000000000000000000000a4c605603D3703c3672033bC06870aaF88EB2c4300000000000000000000000000000000000000000000000000000000000000c3000000000000000000000000000000000000000000000000000000000000000041f9a1ef8a4c256aede4289d711fcbbc1eb555a53f44d176cd9fbc8272afa647c407dc4cd07302600746ee8079a73eff573aa7571877a0b88ca09dc015141c9c332000000000000000000000000000000000000000000000000000000000", "from":"0x3C36F670d288eA51E810B4b236f569D675D19165", "to":"0x3C36F670d288eA51E810B4b236f569D675D19165"}, "latest" ], "id": 1 }

However when the "from" field is removed in the original call, there is no error and it executes successfully.

(This was discovered by @snissn in this Slack thread.)

• Is this because the "from" is a contract?
• Is this because the "from" and "to" are identical?

Context

This is a call from Safe Core SDK Protocol-kit which is widely used across other EVMs.

• The Safe protocol-kit adds this "from" part automatically for signature checks.
• It is currently needed by EVM teams integrating with Safe.filecoin.io who need to validate signatures using the Protocol Kit.
• This works successfully on other EVMs integrated with Safe

👉 Given this fact, we should consider removing the current "from" field restrictions in place on eth_call.

Describe the Bug

The error on Calibration testnet is:

"error": { "code": 11, "message": "message execution failed (exit=[SysErrSenderInvalid(1)], revert reason=[pre-validation failed: Send not from valid sender\n (RetCode=1)], vm error=[ERROR: revert reason is not cbor encoded bytes])", "data": "0x"},

However when the "from" field is removed in the original call, there is no error and it executes successfully.

Logging Information

RPC was used, no logs

[rvagg]

I've been wondering whether this is related to #12441, it just seems odd to me that removing from makes it pass so more investigation required.

[BigLep]

Thanks for reporting @eshon. To make sure I'm tracking the impact, is it fair to say that: many EVM development groups use Safe (presumably for contract ownership and governance) and that they usually programmatically interact with Safe via the Safe Core SDK Protocol-kit. Until this issue is fixed, we're preventing these groups from using their standard workflows to do contract development/management on Filecoin.

[eshon]

Yes I think that's fair to say @BigLep