2024-11-18: initial draft Add EIP: Create delegate by Amxx · Pull Request #9042 · ethereum/EIPs · GitHub
2024-11-21: EIP merged and available here
None as of 2024-11-18.
2024-11-19: Which magic value to use? (0xef0100 vs 0xef0101)
2024-11-20: Include opcode into legacy EVM (in addition to EOF)?
This instruction is NOT added to legacy EVM.
Why not?
A better way to specify this than a CREATEDELEGATE opcode might be to allow CREATE, CREATE2, EOFCREATE/RETURNCONTRACT to return a delegate contract.
I don’t think every kind of special contract should have its own opcode.
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
CREATEDELEGATEopcode might be to allowCREATE,CREATE2,EOFCREATE/RETURNCONTRACTto 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 everytimeCREATE2 would target a different address if the bytecode (of the delegate) changesCREATE and CREATE2 fail is the target as non empty codeIMO, 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.
An account executing differnt logic within the same transaction is already possible with “tranditional” upgradeable contracts.
Still adding that to the EIP document
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.