EIP-7819: Create delegate

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)?

2 Likes

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 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.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like