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.

[JKincorperated]

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

[smartprogrammer93]

Correction, meant DELEGATECALL before AUTHCALL

[etan-status]

Not making it to this call myself, but would like to get the SSZ transition highlighted once more, as described in https://notes.ethereum.org/@vbuterin/purge_2024_03_31#Moving-to-SSZ, https://hackmd.io/@philknows/ryMFFQUpT, and https://hackmd.io/@etan-status/electra-lc:

• EIP-7495: SSZ StableContainer
  • EIP-6493: SSZ Transaction Signature Scheme
    • EIP-6404: SSZ Transactions Root
    • EIP-6466: SSZ Receipts Root
    • EIP-6465: SSZ Withdrawals Root
  • EIP-7688: Forward compatible consensus data structures
• EIP-7658: Light client data backfill

These allow JSON-RPC API servers to include correctness proofs in their responses, eliminating the current requirement to trust them. It is ridiculous that a network as decentralized as Ethereum can only be practically used from wallets, phones, smart contracts and so on by either running a full node (not always feasible), or trusting a centralized entity (some of which are known to have concerning privacy policies when it comes to logging / associating queried wallets with IP addresses etc). With correctness proofs, anyone will be able to serve data without requiring reputation and trust. This then allows a decentralized server infrastructure that is more secure and privacy preserving.

The EIPs also introduce the concept of forward compatibility, which is vital when applications don't share their update cadence with Ethereum. For example, mobile phone OS system services, bridges, decetralized staking pools and so on, they all benefit when their Merkle proof verifiers don't keep breaking when unrelated changes are made to Ethereum. With Electra, the BeaconState is re-indexed (ethereum/consensus-specs#3668 (comment)), already triggering breakage. By pushing these EIPs into Electra, we can avoid future breakage as new features get added and old features get deprecated, at least until the data structures change fundamentally (e.g., SNARK-friendly hashes, far future).

For user adoption, Ethereum should reach a state where it is possible for Apple/Amazon/Google/Cloudflare to run additional full nodes in the cloud that can be trusted for data availability, and for iOS/Android to run a light client as a system service that uses them to stay up to date about relevant events in a battery and privacy preserving way. All these current approaches with messy browser extensions and random apps have to eventually go, they are not securely usable by the masses.

Note that the SSZ EIPs primarily benefit users, application developers, etc, while the effort has to be done by Ethereum core client teams. The effort is non-trivial, but also not a huge hurdle. I did a PoC of the changes discussed in the EIPs myself over at https://eth-light.xyz - the EIPs serve as the basis to unlock all of what's described above, and maybe even benefit environmental concerns in that Bitcoin PoS EIP ;-)

Electra should be the time for it, Geth already has a beacon light client so supports SSZ. Erigon also has it. We only need to add StableContainer to the various SSZ libraries, and change some hashing / serialization for a few data structures. Mostly mechanical changes at this time.

Even though I can't make the call tomorrow, at the very least, I'd appreciate getting some comments on the EIPs Ethereum-Magicians threads.

[wjmelements]

I plan to oppose EIP-7623, which creates free gas, in Meeting 187.

[timbeiko]

Closed in favor of #1029