Please forgive me for banging on about the same thing again and again. But the current definition of “the currently executing code that does not belong to the executing account” is not well defined for making an allow/fail decision for SETCODE.
Consider the following scenarios:
- Contract A performs a delegatecall to itself, followed by a SETCODE operation.
- Contract A performs a delegatecall to Contract B, which has the same code as Contract A, and then calls SETCODE.
In the second scenario, where Contract A delegatecalls to Contract B with identical code, it becomes challenging for the contract itself to distinguish between the two cases. The executing contract is unaware of the source of the code it is currently running.
One could argue that SETCODE in the second scenario should be allowed as well since the code being executed is the same.
Additionally, as previously mentioned, one could argue that after the first SETCODE operation, the remaining execution is not running the code belonging to the executing account. This distinction can be easily verified by comparing CODECOPY to EXTCODECOPY.
To address these concerns, I suggest to redefine the decision criteria in terms of how the message call was entered:
When in a STATICCALL context:
SETCODE should be disallowed (FORBID).
When in a non-STATICCALL context:
SETCODE should be allowed if the current message call was entered via a CALL operation or if it is the first call from an externally owned account (EOA) to an existing contract (excluding the initial contract creation call).
SETCODE should be disallowed (FORBID) in all other cases, covering variations of DELEGATECALL, CALLCODE, CREATE, CREATE2, and non-STATICCALL contexts other than CALL or first call from EOA to an existing contract.
By redefining the decision criteria in this manner, the specification becomes easier to understand and helps address numerous corner cases. It ensures that SETCODE behavior aligns with the context of the message call, resulting in a more coherent and predictable execution model.