Title: EIP_7819__Create_delegate
Category: EIPs

Author: Amxx
Date: 2024-11-19T12:38:32.647Z

Discussion topic for EIP-7819
Update Log
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
External Reviews
None as of 2024-11-18.
Outstanding Issues
2024-11-19: Which magic value to use? (0xef0100 vs 0xef0101)
2024-11-20: Include opcode into legacy EVM (in addition to EOF)?

Author: wjmelements
Date: 2024-11-20T04:27:20.235Z

This instruction is NOT added to legacy EVM.

Why not?

Author: wjmelements
Date: 2024-11-20T20:21:37.399Z

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.

Author: Amxx
Date: 2024-11-20T20:36:01.733Z

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.

Author: wjmelements
Date: 2024-11-20T20:48:48.402Z

Amxx:

IMO you lose a lot of the value of the proposal 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.

Author: Amxx
Date: 2024-11-20T20:52:36.097Z

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.

Author: shemnon
Date: 2025-03-12T20:57:49.766Z

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.

Author: Amxx
Date: 2025-03-17T20:20:55.908Z

An account executing differnt logic within the same transaction is already possible with “tranditional” upgradeable contracts.
Still adding that to the EIP document

Author: axic
Date: 2025-04-10T15:19:13.131Z

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.