Execution Layer Meeting 186

[timbeiko]

Meeting Info

• Apr 25, 2024, 14:00-15:30 UTC
• Stream: https://youtube.com/live/iLnBFPH-1Gc
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Pectra EIPs
  • devnet-0 updates
    • EIP-7685 & 6110/7002 changes
  • EIP-3074
    • DELEGATECALL before AUTHCALL
    • AUTH message updates (context)
      • noncemanager
      • remove nonce
      • chainId set to 0
• Pectra Proposals
  • EIP-5003
  • EIP-7623
  • EIP-7636
  • EIP-7212
• ACD/EIPs & L2/RIPs (context)

[rmeissner]

I would like to discuss what is necessary to get EIP-5003 included in Pectra, additional to EIP-3074. To be able to fully facilitate the opportunities given by EIP-3074 for smart accounts and AA it would be extremely beneficial to also have EIP-5003 available. Especially since this will otherwise be delayed for quite a while.

[nerolation]

I would like to have a discussion on including EIP-7623 in Pectra.

There is a discussion thread in the Eth R&D discord:
https://discord.com/channels/595666850260713488/745077610685661265/1228262613239201804

As well as a short summary of the EIP on ethmagicians:
https://ethereum-magicians.org/t/eip-7623-increase-calldata-cost/18647/17

[noam-alchemy]

I would like to discuss at a higher level what is Ethereum's and the EIP process's core charter. Specifically around:

• Ethereum's transition to a rollup centric roadmap and priorities, goals, and non-goals for protocol level changes.
• The decoupling between EIP processes and RIP processes, and on the longer tail, the ability for rollups to innovate protocol level changes without standardization with respect to frameworks and objectives for what needs to be standardized everywhere, what needs to be standardized on rollups, and what doesn't need to be standardized.

[derekchiang]

I would like to discuss this possible improvement to EIP-3074.

[SirSpudlington]

Can we also discuss EIP-7636 as it regards an addition to the ENR.

[ankurdubey521]

I would like to discuss this possible improvement to EIP-3074.

As one of the authors of this suggested improvement, I would also like to propose this as a possible improvement to EIP-3074

[derekchiang]

Actually there are two proposals wrt 3074 that I'd like to discuss:

• Update AUTH message to keccak256(MAGIC || chainId || nonceManagerAddress || nonceManagerNonce || invokerAddress || commit)

• Remove nonce from AUTH message but add an opcode for getting nonce

[smartprogrammer93]

I would like to discuss the inclusion of 7212 secp256r1 precompile.

I would also like to discuss the behavior of 3074 with delegatecall before an authcall.

[timbeiko]

I've updated the agenda will all of the above. Some context:

• We'll start by covering anything relevant to devnet-0
• 3074 makes sense to cover after as changes may or may not be included in the devnet
• We can discuss the various proposals, but more broadly it's worth getting a feel from client teams about their ability to commit to more EIPs while we still have not implemented the ones already included
• If time permits, we can have the L1/L2 conversation, but if all of the above takes up the full call we may have to bump it to another ACD, or perhaps RollCall

[jflo]

Would like to decide if the versions of EIP-6110 and EIP-7002 that will be implemented on pectra-devnet-0 should depend on EIP-7685. I believe they should, but it results in minor rework on the EL side for each.

[timbeiko]

@jflo I believe we had agreed to this on last week's CL call, but yes, that's why I have 7685 first on the agenda. Will explicitly call out the impact on 6110/7002 👍

[shemnon]

Regarding the two EIP-3074 nonce proposals, I want to put my stake in the ground that what I care about is an in-protocol revocation mechanism to revoke an EIP-3074 AUTH signature, with a revocation economy no worse than one action per signature. (i.e. 100 actions to revoke 100 separate signatures is fine, but 100 actions to revoke 1 signature, not fine). Deferring your nonces to another contract weakens the guarantees and moves them out of the ethereum protocols.

[derekchiang]

Regarding the two EIP-3074 nonce proposals, I want to put my stake in the ground that what I care about is an in-protocol revocation mechanism to revoke an EIP-3074 AUTH signature, with a revocation economy no worse than one action per signature. (i.e. 100 actions to revoke 100 separate signatures is fine, but 100 actions to revoke 1 signature, not fine). Deferring your nonces to another contract weakens the guarantees and moves them out of the ethereum protocols.

@shemnon i believe the nonceManager idea will address your concern. A user can always set nonceManager to their own EOA to get the same behavior as the spec specifies today. But it also gives users the flexibility of using a contract as the nonceManager if they want to avoid accidentally revoking AUTH sigs.

Anyways, looking forward to discussing it more tomorrow.

[rmeissner]

I would also love to discuss if it should be possible to allow signing 0 as the chainId for 3074 to allow replayablility across chains. Having an explicit way would be very powerful for cross-chain dynamics (especially in conjunction with 5003)

Edit: This would fall under AUTH message updates