This instruction is NOT added to legacy EVM.
Why not?
This is up to debate. I think I did not want to focus on pushing more stuff to the legacy EVM now that we are in a transition to EOF. IMO, there is no way this EIP makes it into a fork before EOF, so I though it would be simpler to only have that in EOF.
better way to specify this than a CREATEDELEGATE opcode might be to allow CREATE , CREATE2 , EOFCREATE /RETURNCONTRACT to return a delegate contract.
That is an interresting idea, but it would not provide a mechanism for upgradeability of the delegate:
CREATE uses a different nonce everytime
CREATE2 would target a different address if the bytecode (of the delegate) changes
in any cases, both CREATE and CREATE2 fail is the target as non empty code
IMO, this proposal loses a lot of its value if upgrades are not possible.
Upgrades could still be possible via SETCODE/RECREATE or any of the other mutable code proposals. I think mutable code is important enough that it should be available to everyone, not only delegators.
That is a very different path that will take a very long time to get accepted (if it ever is).
Delegations already have this reconfiguration by design, which made me thing this proposal would be more easily accepted than a combo “CREATE/CREATE2/EOFCREATE can create delegations” + “SETCODE/RECREATE” that may takes multiple years to be available.
I think we should make explicit the visibility and effectiveness of the deligation in the spec. We also need to think through what the implications of a rapidly changing delegation could be. For example, the code in question could take an address, update the delegation, execute that address, update the delegation again, execute that address again, and then remove that delegation. This would have, in the same transaction without reverts, an address that has three or four possible different codes associated with it, two of which are executed.
We should call this out in security consideraions, namely that end users whose business is forensics and reconciliation, will need to make sure their tooling can handle this scenario.
I propose this note in Specification, after the enumeration of the behavior
Note: The delegation is effective immediately upon the completion of the operation. Calls to the address as soon as the next operation will execute the newly delegated code.
Since this not only creates, but updates existing delegations, I think a better opcode name would be appropriate. I suggest SETDELEGATE or UPDATEDELEGATE as a better option.
Side-note: traditionally we do not have opcodes with an underscore in them.