Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execution Layer Meeting 189 #1052

Closed
timbeiko opened this issue May 23, 2024 · 14 comments
Closed

Execution Layer Meeting 189 #1052

timbeiko opened this issue May 23, 2024 · 14 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented May 23, 2024

@rakita
Copy link

rakita commented May 24, 2024

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
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Member

gballet commented Jun 4, 2024

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

@yperbasis
Copy link
Member

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
Copy link

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

@timbeiko
Copy link
Collaborator Author

timbeiko commented Jun 5, 2024

@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 😄

@holgerd77
Copy link

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
Copy link

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:

grafik grafik

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
Copy link

MarekM25 commented Jun 6, 2024

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
Copy link
Collaborator

hwwhww commented Jun 6, 2024

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

@timbeiko
Copy link
Collaborator Author

timbeiko commented Jun 6, 2024

Closed in favor of #1066

@timbeiko timbeiko closed this as completed Jun 6, 2024
TeamAvarch added a commit to TeamAvarch/Ethereum-pm that referenced this issue Jun 20, 2024
Please review and Merge Meeting Agenda ethereum#1052
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests