Execution Layer Meeting 189

[timbeiko]

Meeting Info

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

Agenda

• Pectra EL scope
  • Besu views
  • EthJS views
  • Nethermind views
  • Reth views
  • EthPandaOps views
  • EOF inclusion views
• Pectra EIP discussion
  • Future of EOA/AA Breakout Room #4 #1054 recap
  • EIP-7702 revocability issues
  • engine: Return and accept EL triggered requests as a sidecar execution-apis#551
  • EL consolidation spec
    • Update EIP-7251: Add EL triggered consolidations EIPs#8625
    • engine: Add EL triggered consolidations execution-apis#554
  • engine: align WithdrawalRequestV1 with EIP-7002 and consensus spec execution-apis#549
  • Extend V1 vs introduce V2 for engine_getPayloadBodies* requests engine: Extend payload bodies with deposit and withdrawal requests execution-apis#545 (comment)
• Deactivating EIP-158 in Pectra/Osaka
• EIP-4444 & Portal
• ACD, Network Upgrades & EthMag Improvements
• Testing/Devops comms channels
• PeerDAS Breakout Room #1 #1059
• ePBS breakout room #2 #1060

[rakita]

I am gathering the views of clients and stakeholders regarding EOF inclusion in Prague, so I would like to start the meeting by reading this post, as it should make the discussion more clearer: https://discord.com/channels/595666850260713488/745077610685661265/1243235232082301009

If people want this post updated in any way to better express their current stance, please reach out or make a comment in the Discord thread.

[pipermerriam]

I'd be interested in a few minutes to get an update from EL teams on what they see as next steps for 4444s and whether anyone has any questions or feedback on portal history network protocol specifications.

If EL teams want to move forward with 4444 using Portal.... we would like to propose a plan for getting 4444's implemented and live in clients before the end of the year. Our most recent client to join the network was Shisui. They took 6 months to go from the forked implementation of the DiscV5 protocol to passing our full suite of interop tests for the history network. They did this almost entirely from reading the code of the existing implementations, reading the specs, working on the hive tests and asking us very few questions. We think that any EL team that is able to get started in the July/August timeline should be able to have something mostly or entirely complete by Devcon. We also think there is likely significant benefit from multiple EL teams working on this concurrently in terms of delivering 4444s to EL clients in a short timeline. The existing portal client developers would be available through this process to support these new implementations, answer questions and help troubleshoot.

[timbeiko]

As mentioned on Discord, I'd like to spend some time on the call discussing potential improvements to ACD, Network Upgrades and EthMagicians. The full list of proposals is here. For ACDE specifically, the most important ones to get consensus on are these three:

• ACD Proposal 1: EIP Review Requests
• NUP Proposal 1: PFI, CFI, SFI
• NUP Proposal 3.1: Client Team EIP Editors by Default

[marioevz]

Testing and Devops teams would like to discuss the current channels we have to broadcast testing-related announcements, discussion and information: https://notes.ethereum.org/@danceratopz/testing-channels

[gballet]

We would like to discuss deactivating eip 158 in pectra/osaka to mitigate some bad interactions between eip 7702 and eip 6800

[yperbasis]

Erigon would like to discuss the topic of EIP-7702 revocability. Reposting from Eth Magicians:

I’m still not comfortable about optional revocability.

1. The argument that has been pushed so far is that the signature has same kind of security concerns/handling as a private key or seed phrase. I disagree. Once a tx is made with non-revocable signature, it’s public.
   This is different from private key because if I delete a metamask wallet from my browser, the private key is wiped out. It never leaves my computer (I trust metamask to follow this). This doesn’t happen with signature because this is public, and deleting metamask doesn’t quite provide the same effects.
2. There is a significant change in the level of trust placed on wallet providers here. Of course, smart wallets are more complex than EOAs (and so there’s already an increase in trust), but I still want to able to delete/leave a smart wallet without having lingering doubts about future signature exploitation. e.g. I realize that a wallet provider I was using is not really safe anymore, and I want to do a “invoke all previous authorizations”-style operation – something analogous to what happens when (in web2) I change password or “sign out from all devices.”
3. There is a shift of trust (regarding security) from Ethereum protocol to wallet providers, which is uncomfortable. Making revocability optional complicates the UX, and some wallet providers might just decide to make all signatures non-revocable in order to “simplify the UX” and not expose the revocable signature option at all.

[rmeissner]

@yperbasis would recommend to join #1054 to discuss this.

[timbeiko]

@rakita ty for compiling this 🙏 ! @pipermerriam @marioevz @gballet I've added all your points to the agenda. @yperbasis +1 on @rmeissner's comment re: attending the breakout to discuss the topic in depth 😄

[mkalinin]

It would be great to quickly go over the following Pectra items:

• engine: Return and accept EL triggered requests as a sidecar execution-apis#551
• EL consolidation spec
  • Update EIP-7251: Add EL triggered consolidations EIPs#8625
  • engine: Add EL triggered consolidations execution-apis#554
• engine: align WithdrawalRequestV1 with EIP-7002 and consensus spec execution-apis#549
• Extend V1 vs introduce V2 for engine_getPayloadBodies* requests engine: Extend payload bodies with deposit and withdrawal requests execution-apis#545 (comment)

[holgerd77]

Following the latest trend we (EthereumJS) have also written down some arguments and a proposal for a Pectra-and-beyond fork timeline:
https://notes.ethereum.org/C2xqg0pKRW2TL7WfFqka_Q?view

I will likely not be able to join the call, we will likely have two people from the team joining though ( @g11tech and/or @jochem-brouwer).

[holgerd77]

Just reading up on the ACD, Network Upgrades & EthMag Improvements from Tim (thanks for this!) (also, realizing that we just already violated the 24h announcement rule for async takes 😂, sorry for that).

Will just post here my comments (not team aligned) I made within our internal chat:

Just a general note that I perceive this topic as so vast that this might deserve a breakout room on it's own to discuss. Guess we'll see if we get through though (again, can't join myself likely though).

[MarekM25]

Nethermind's view about fork scoping 👇

---

We considered many options, and two of them seem to be the most reasonable:

1. Three-fork solution:
   a) Fork 1: PectraCore
   b) Fork 2: EOF + PeerDAS + potentially ePBS
   c) Fork 3: Verkle
2. Two-fork solution (with GigaFork):
   a) Fork 1: GigaFork (PectraCore + EOF + PeerDAS + potentially ePBS)
   b) Fork 2: Verkle

• We would like to ship EOF before Verkle.
• We would like to see two extra small EIPs, EIP-7212 and EIP-7623, included in either 1a/1b or 2a.
• Ultimately, it is up to the CL teams to decide if it is feasible to ship PeerDAS and ePBS.
• We commit to keeping our focus on Verkle and EIP-4444.
• While we think SSZ is important, we believe it is better to ship it after Verkle to maintain our focus on Pectra/EOF/Verkle/4444.
• We believe the main complexity of EOF lies in proper cross-client testing, not in the implementation.

It seems that more team members favor the three-fork solution, but the two-fork solution is acceptable as well. Some team members feel strongly about the three-fork solution to avoid delaying Pectra. If we decide to go with the three-fork solution, it will be important to agree on the scope of Fork 1 and Fork 2, avoid changes, and ideally ship them in a manner similar to Berlin and London (with only a few months between the forks). The main advantage of the three-fork solution is that we will be able to ensure that EOF/PeerDAS and ePBS are properly tested without blocking other improvements. The main disadvantage, of course, is the extra coordination efforts.

It would be great to assess with all teams (CL/EL/testing) what delay would be introduced for Pectra if we decide to go with the GigaFork. If there is strong commitment from all teams that the delay will be small, the GigaFork seems to be a viable solution. On our side, we don't think that EOF implementation will be a blocker, but we do believe that proper testing of all edge cases and covering all possible scenarios might take time and shouldn't be rushed.

By PectraCore I mean the following EIPs: EIP-6110, EIP-7002, EIP-7685, EIP-7702, EIP-2537, EIP-2935, EIP-7541 + CL EIPs (up to CL teams to decide about them, for example, EIP-7549).

[hwwhww]

@timbeiko
We'd like to remind people of the PeerDAS breakout next week: #1059 🙏

[timbeiko]

Closed in favor of #1066