From b4c5b69a3408adcbaa00d41c412b2aed83fe0259 Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 13 Dec 2024 09:33:39 -0500 Subject: [PATCH 01/51] Create FOCIL-pm.md Create Folder --- Breakout-Room-Meetings/FOCIL/FOCIL-pm.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 Breakout-Room-Meetings/FOCIL/FOCIL-pm.md diff --git a/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md b/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md new file mode 100644 index 00000000..f9cd52d1 --- /dev/null +++ b/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md @@ -0,0 +1,11 @@ +# [EIP-7805](https://eips.ethereum.org/EIPS/eip-7805): Fork-choice enforced Inclusion Lists (FOCIL) +FOCIL implements a robust mechanism to preserve Ethereum’s censorship resistance properties by guaranteeing timely transaction inclusion. + +## Resources +- [Uncrowdability of FOCIL](https://mirror.xyz/julianma.eth/Gnd8N1IsoHuGHRisp6nCldlt72ZacoXUA-O76qQN3mc) + +## Breakout room meetings + +| # | Date | Agenda | Recording | Notes | +| -- | --| -- | -- | -- | +|1| December 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1210) | [Recording] | [Notes]| From 0b5011d0f9f61077f4bc0b9671a982616b38df78 Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 13 Dec 2024 12:12:52 -0500 Subject: [PATCH 02/51] Create Meeting 01.md Add notes 1 --- Breakout-Room-Meetings/FOCIL/Meeting 01.md | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Breakout-Room-Meetings/FOCIL/Meeting 01.md diff --git a/Breakout-Room-Meetings/FOCIL/Meeting 01.md b/Breakout-Room-Meetings/FOCIL/Meeting 01.md new file mode 100644 index 00000000..efd305d7 --- /dev/null +++ b/Breakout-Room-Meetings/FOCIL/Meeting 01.md @@ -0,0 +1,58 @@ +# FOCIL Breakout Room #01 + +Note: This file is copied from [here](https://github.com/ethereum/pm/issues/1210#issuecomment-2541647674) + +### Meeting Info + +**Agenda**: https://github.com/ethereum/pm/issues/1210 + +**Date & Time**: [Dec 13, 2024, 14:00-15:00 UTC](https://www.timeanddate.com/worldclock/converter.html?iso=20240213T140000&p1=1440&p2=37&p3=136&p4=237&p5=923&p6=204&p7=671&p8=16&p9=41&p10=107&p11=28) + +**Recording**: https://youtu.be/SOt-rNDlsRU + +## Meeting notes: +### Spec Stability + +- CL spec is relatively stable +- EL spec will be formalized with a PR to EELS + +### Spec Questions + +- Fork-Choice slot/block enforcement via proposer-boost reorging. This might/should need to be a separate EIP + +### Inclusions/Exclusions for First Round + +- Blobs will not be included +- Maybe not verify IL's for first round of integration testing + +### Rough Timeline + +- Shoot for first week of January for next meeting +- Hope that by that meeting we can have at least 1 CL and 1 EL ready to test with +- Shoot for attempting to set up a basic Kurtosis/Hive network between the first clients on the next call + +### Spec Test Goals + +- Engage with Testing group to figure out timeline for work on spec tests + +### Active Branches + +- Geth: https://github.com/jihoonsong/go-ethereum/tree/focil +- Lodestar: https://github.com/ChainSafe/lodestar/tree/focil + +### Implementation Notes +Goal should be to keep discussion strictly in Discord and on the website https://meetfocil.eth.limo/. Telegram and Twitter should be avoided to help corral the discussion to a single (or two) places. + +There are two cases in the execution case. When sync'd and before sync. Should the CL be notifying the EL to check the IL's? This will be different cases for when syncing and after sync is complete. A PR will be opened to the spec to dial this in. + +EL will look at specifying that if an IL is passed in then the IL should be checked, if not then the IL's will not need to be verified to check the block. Terrence requested for @Jihoon to open a pr here? https://github.com/ethereum/execution-apis/pulls + +### References Posted During Call + +- https://meetfocil.eth.limo/ +- https://notes.ethereum.org/@jacobkaufmann/Sy7sNHKVye +- https://hackmd.io/@jihoonsong/BJUVIsY4ye +- geth prototype: https://github.com/jihoonsong/go-ethereum/tree/focil +- https://github.com/ChainSafe/lodestar/tree/focil +- https://github.com/ethereum/execution-apis/pulls +- https://hackmd.io/@potuz/BkpzmOgK6 From a2cc30a52d2b9b07edb0864d946e458e9675c1d3 Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 13 Dec 2024 12:15:31 -0500 Subject: [PATCH 03/51] Update FOCIL-pm.md Update README --- Breakout-Room-Meetings/FOCIL/FOCIL-pm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md b/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md index f9cd52d1..84272d85 100644 --- a/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md +++ b/Breakout-Room-Meetings/FOCIL/FOCIL-pm.md @@ -8,4 +8,4 @@ FOCIL implements a robust mechanism to preserve Ethereum’s censorship resistan | # | Date | Agenda | Recording | Notes | | -- | --| -- | -- | -- | -|1| December 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1210) | [Recording] | [Notes]| +|1| December 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1210) | [Recording](https://youtu.be/SOt-rNDlsRU) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/FOCIL/Meeting%2001.md)| From 09d8d35064899b06ab041e6efdabaadf4a64bcca Mon Sep 17 00:00:00 2001 From: fradamt <104826920+fradamt@users.noreply.github.com> Date: Fri, 20 Dec 2024 14:41:38 +0100 Subject: [PATCH 04/51] fix slides link --- .../DevconSEA/R&D-workshop/Single-Slot-Finality.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md b/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md index 0cd76c57..86bf99c9 100644 --- a/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md +++ b/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md @@ -18,7 +18,7 @@ - [More signature aggregation](https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386) - [Path to SSF](https://notes.ethereum.org/@vbuterin/single_slot_finality) -**Slides:** [here](https://docs.google.com/document/d/1pynCM25Lf6tAf-6HZX-Lri28Wgac-K3vGyukn18FAzM/edit?usp=drivesdk) +**Slides:** [here](https://docs.google.com/presentation/d/1-fTMPXtbCgwYJ-K2CW93GGZrzRRrtPnpE8O3Zv81gyA/edit?usp=sharing) ## Agenda ### 15-25 mins: overview of state of research on paths to SSF @@ -123,4 +123,4 @@ Possible goals: * How big is the slashing rule change? Do we need to reimplement stuff from scratch? * Francesco thinks that it’s pretty similar * Are specs and implementations really blocked by the lack of a decision on validator set size management? - * Maybe we would want to do committee-based finality if we were forced to live with a very large validator set. \ No newline at end of file + * Maybe we would want to do committee-based finality if we were forced to live with a very large validator set. From 449091ea1041890f56c00a3d4e404c89e5ad31ae Mon Sep 17 00:00:00 2001 From: fradamt <104826920+fradamt@users.noreply.github.com> Date: Fri, 20 Dec 2024 14:47:04 +0100 Subject: [PATCH 05/51] remove redundant part --- .../R&D-workshop/Single-Slot-Finality.md | 40 ------------------- 1 file changed, 40 deletions(-) diff --git a/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md b/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md index 86bf99c9..368b9752 100644 --- a/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md +++ b/Breakout-Room-Meetings/DevconSEA/R&D-workshop/Single-Slot-Finality.md @@ -84,43 +84,3 @@ Possible goals: * Francesco thinks that it’s pretty similar * Are specs and implementations really blocked by the lack of a decision on validator set size management? * Maybe we would want to do committee-based finality if we were forced to live with a very large validator set. - -# SSF session notes - -[Session doc](https://hackmd.io/@fradamt/devcon-ssf-session) - -## Part 1: Presentation - -[Slides](https://docs.google.com/document/d/1pynCM25Lf6tAf-6HZX-Lri28Wgac-K3vGyukn18FAzM/edit?usp=drivesdk) - -## Part 2: Questions - -* Do we still have accountable safety? - * Yes, minor changes to the slashing conditions but all good. -* Does 3SF give us faster slot times? - * Not inherently, even today we could shave off time from parts of the slot e.g., make aggregation phase 2 seconds. -* Does 3SF affect the mev supply chain? - * Not inherently, similar properties as today when it comes to reorgs/missed slots/timing games. -* What happens if no one consolidates? - * In Orbit, there are incentives to consolidate. -* Expected committee size discussion - * Stable committee size, but what is the distribution of the committee size given the distribution of stake across validators? -* Amount of economic finality based on the stake among committee members -* Question on incentives to consolidate in Orbit - * Explicit incentives or implied ones? - * Two forms: - * Collective incentives: everyone hurts more when people consolidate less - * Individual incentives: if there isn’t high consolidation, you get more rewards if you are consolidate - * Is there a centralisation risk if we give more power to consolidated validators? - * For LMD-GHOST, not really, random sampling - * For finality, more influence of consolidated validators, but the argument for why it’s ok is that today we have 5-10% solo stakers, they are valuable for CR but not so valuable for finality, they are not a blocking minority, they cannot force finality, so their influence on finality today is also small, but it is true that it changes the influence of solo stakers in that section. Also ties with rainbow staking, recognise that their influence is small, and separate them more fully from attestation services. -* Networking complexity of 1-slot SSF - * Each voting phase looks like today’s voting phase, so same same -* Committee size and min balance: can we do 1 ETH validators - * Francesco bearish on 1 ETH, \[redacted\] wants the beacon state in memory, not on disk -* Implementation question: when we process a block, all the fork choice information is available quickly. In the happy case of 3SF, things are still fine, but with the multiple source-target possibilities, do we need to cache things longer? - * It’s high bar to become a source that one cares about, needs to be justified, so not expected to blow up memory -* How big is the slashing rule change? Do we need to reimplement stuff from scratch? - * Francesco thinks that it’s pretty similar -* Are specs and implementations really blocked by the lack of a decision on validator set size management? - * Maybe we would want to do committee-based finality if we were forced to live with a very large validator set. From 71de345e2163da95176a334bdd64101755fe082c Mon Sep 17 00:00:00 2001 From: jamnuel <158302490+jamnuel@users.noreply.github.com> Date: Fri, 20 Dec 2024 12:46:12 -0600 Subject: [PATCH 06/51] Add Meeting #201 Notes --- AllCoreDevs-EL-Meetings/Execution Layer #201 | 446 +++++++++++++++++++ 1 file changed, 446 insertions(+) create mode 100644 AllCoreDevs-EL-Meetings/Execution Layer #201 diff --git a/AllCoreDevs-EL-Meetings/Execution Layer #201 b/AllCoreDevs-EL-Meetings/Execution Layer #201 new file mode 100644 index 00000000..56b3c2e9 --- /dev/null +++ b/AllCoreDevs-EL-Meetings/Execution Layer #201 @@ -0,0 +1,446 @@ +# Execution Layer Meeting #201 +### Meeting Date/Time: Dec 5, 2024, 14:00-15:30 UTC +### Meeting Duration: 1h35m +### [GitHub Agenda](https://github.com/ethereum/pm/issues/1197) +### [Video of the meeting](https://youtube.com/live/Umh7ZKukmtY) + + + + + +### Moderator: Tim +### Notes: June + +| S No | Agenda | Summary | +| -------- | -------- | -------- | +201.1 | **Pectra updates: Mekong & devnet-5 updates** | Mekong testnet is operational ~97% attestation performance; minor issues to address, mostly good on Mekong front and focused on getting all the PRs merged for devnet-5; devnet doc has been updated by testing team to show where the status of tests are. +https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 +201.2 | **Pectra Scoping** | BLS gas pricing discussion of Marek's PR [here](https://github.com/marchhill/bls-precompile-benchmarks/blob/main/proposed-changes.md); Most client teams in production and on call agreed that the proposal works for them to move forward with for now; need confirmation from Besu async; can modify with more fine-grain anaylsis in the future. +201.3 | **Pectra Scoping** | Discussion on [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) inclusion and update with additional security considerations [EIPs#9086](https://github.com/ethereum/EIPs/pull/9086_); 7623 focuses on capping transaction payload sizes to improve network performance and security; client teams all agree it would be a small thing to implement and wouldn't significantly impact timelines; decision to move forward with 7623 on devnet-5 pending confirmation from testing team. +201.4 | **Pectra Scoping** | Discussion on [EIP-7762](https://eips.ethereum.org/EIPS/eip-7762) inclusion; proposes minimum blob price increase; disagreement on whether to include this in Pectra; deferred one week for feedback from rollups and testing. +201.5 | **[EIP-4444 & EIP-7639 rollout](https://hackmd.io/Dobc38YVQ1qmbbyI6LcFqA)** | Discussion and disagreement about best protocol versioning for this implementation and whether or not some clients should be able to provide historical blocks while others don't; concern about protocol fragmentation; Piper to compile notes and create discussion async. +201.6 | **[EIP-4803] (https://eips.ethereum.org/EIPS/eip-4803)** | This EIP is proposed to be enabled from genesis and it limits gas limits on transactions; no objections conceptually but won't be address until after Pectra testing; Alex to create a PR. +201.7 | **[Potential ACD Improvements](https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157/51)** | Agreement to add [Declined for Inclusion] status for EIPs that will not be included in the hard fork; EIPs still open for discussion and available for future hard forks; agreement to include all non-consensus protocol changes in list of hard fork changes to make sure everything is up to date for each hard fork. +201.8 | End of year coordination and holiday meeting schedule | Testing call on Dec 23, Cancel ACDE on Dec 26, Cancel testing call on Dec 30, Replace ACDC by testing call on Jan 2 + +### 201.1 | Pectra updates: Mekong & devnet-5 updates +**Tim**: Welcome everyone to ACDE #201. Couple things on the agenda today, most importantly we can hopefully finish the scope of Pectra and be able to move forward with the specs. After, some conversations around EIP4444 as well as 7639 about dropping history. Then there was an edge case to revist around capping transaction gas amount and then if we have time left, there are a couple ACD process improvements I wanted to cover. + +Pari, Banabus, either of you want to give an update on testnets? + +**Pari**: We have Mekong continuing to run-- we're at 97% attestatino performance. Grandine team has pushed a lot of fixes, mostly okay now. Some problems still with Ethereumjs and Nimbus EL, but mostly good on Mekong front and focused on getting all the PRs merged for devnet-5. +PRs here: +CL - https://github.com/ethereum/consensus-specs/pull/3800 +CL - https://github.com/ethereum/consensus-specs/pull/4023 +EL - https://github.com/ethereum/execution-apis/pull/574 + +Devnet doc has been updated by testing team to show where the status of tests are. +https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 + + +**Tim**: Any other EL PRs that you want to bring people's attention to? + +**Ansgar**: Regarding [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691), there was this open question of what exact update fraction we would go with and we chose the number that is the middle sensitivity between 3-6. We couldn't have 6 blobs less than the target or 3 blobs more than the target, so we picked the middle; now a very full block will have slightly less than 12% increase and a fully empty block will have slightly more than 12% decrease. + +**Toni**: Was just in the process of reviewing the EIP-7691 PR; only one small typo then we can merge. + +**Paritosh**: lightclient brought up [7702 txpool](https://eips.ethereum.org/EIPS/eip-7702) in chat, maybe he wants to discuss? + +**lightclient**: just checking again to see if anyone has looked into it or implemented it? We are in the process of implementing now. + +**Marek**: Nethermind is looking into it, but others can comment on that. + +**Anders**: Yes, we had a discussion on Discord [interop channel]. We had some suggestions but it seems the discusssion stalled. + +**Tim**: As people work on this, share any updates or designs in the discord chat. + + +------------------------------------- +### 201.2 | Pectra Scoping | BLS gas pricing + +**Tim**: Moving on, it's worth chatting about Pectra scope changes. It feels like we're close to finalizing scope, it would be ideal if we could do so on today's call so we have a final set of specs to work with before the holidays. We can come back in January with a clear target to implement. + +On CL, everything seems pretty resolved. + +On EL, some major open questions: first is BLS gas pricing, second is whether to include EIP-7623, lastly is EIP-7762, an adjustment to the blob base fee. + +Let's start with BLS one since it's already included in Pectra and needs to be fixed. Anyone with context on latest BLS pricing discussion? + +**Marek** I took all the numbers and opened a PR, in the [link here](https://github.com/marchhill/bls-precompile-benchmarks/blob/main/proposed-changes.md) we have Nethermind BLS pricing proposal and it would be great if it could be validated by other teams. I think Pawel had a different idea how to price MSM (multi-scalar-multiplication) operations but I don't fully understand, so we need to agree with Pawel about this. + +**Tim**: Have any other teams reviewed or have any strong opinions? + +**Kevaundray**: From the pricings, atleast from what we know from the current numbers, Nethermind for G1MSM would need to go up by 2.5x, Besu and Geth would need to go up by 2x, and evmone would need to go up by 3x. For G2, Nethermind is 1.5, Geth and evmone are 2x. We could go with these pricings but they're more costly than what we would like. + +**Tim**: By 'these pricings,' you mean Marek's current PR? + +**Kevaundray**: We took the worst case of what everyone has already given us in order to cover all of the clients. It's just a more coarse way to do the pricing. + +**Tim**: Do you have a sense of the impact on users for having this more coarse pricing scheme? + +**Kevaundray**: We don't know exactly because it depends on the use cases. My suggestion would be to commit to coarse pricing and we can use other tools to determine a new curve to use. At the moment, we haven't committed to any pricing. I would like to avoid the 3x that is there but it's the only one we've seen imperfectly that covers everyone else. + +**Tim**: So I understand evmone was slow on some of these; that's the one that would be covered by 3x? + +**Kevaundray**: Right, the next lowest would be the Nethermind proposal of 2.5x scaling. + +**Tim**: Is evmone used in production by any clients? + +**Andrew**: Not yet, but we would like to switch Erigon to evmone. At the moment it still uses GoLangEVM which is essentially the same as used in Geth. + +**Tim**: Nethermind uses the same library. I'm trying to understand why evmone is slower and does it make sense to put our worse case on an evm that is not beign used in production today or should we use whatever is already in production? + +**Kevaundray**: To answer the first question, evmone is different and has issues even when using the same library because everyone is basing it off ez-recover, but that's not the same across every library. + +**Radek**: This is not exactly about evmone, but about the blst library, which is used by Nethermind and Reth. This means that the speed is not only the case with evmone but with the library itself. + +**Kevaundray**: Right, so Nethermind uses the same library but it's a 2.5x. This goes down to the issue of ez-recover not being the same across everyone because everyone is scaling based on ez-recover. + +**Tim**: Anyone from Geth or Besu have time to review? Jared says Geth would be good with Nethermind's proposal. My sense is that if Besu is also good with it we should move forward, even if it is slightly underpriced for evmone. + +**Kevaundray**: What do people think about the proposal to commit to 2.5x or 3x and then wait for a gas optimizer tool to possibly give us finer-grain numbers, but we commit to something for the time being? + +**Tim**: Discussion in chat to agree async but before devnet-5. Marek, how much time do you think we need to agree to this? If we could get consensus on your PR as a basecase that we could modify later on, is there a reason to push this back async before we make the decision? + +**Marek**: There is no clear number, we can discuss async, but we should decide before devnet-5. + +**Tim**: It is fine to do it async, but recommend getting to a resolution on testing call Monday. Get us to as final of a pricing scheme as soon as possible. + +**Stokes**: Kev's recommendation is a good way to make progress today. Sounds like this PR gets us directionally closer to what we all like. + +**Tim**: If all of the production clients are fine with this number, we should go ahead and merge. Worth getting a sanity check from Besu, but assuming they can approve async today or tomorrow, we merge. + +**Stokes**: If anyone has a BLS-signature verifier that works with the latest for Pectra, let me know on Discord. Would be nice to have a sense of end-to-end cost for this. + +------------------------------------- +### 201.3 | Pectra Scoping | [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) inclusion and update discussion with additional security considerations [EIPs#9086](https://github.com/ethereum/EIPs/pull/9086_); + +**Tim**: Next up is EIP-7623, Danno you raised some issues on EthMagicians and then Toni opened a PR to address them. Toni, do you want to give a quick recap on those changes? + +**Toni**: We discussed on the consensus layer call last week as well. The main contention we always had with 7623 was not about the mechanism but the scope of Pectra itself. Regarding Danno's suggestions, I included them and incorporated them into the EIP. You can now find a more elaborated backwards compatibility section and security considerations, including the concerns we clarified that William raised about the gas sheltering. I would now propose that we include it and ship it in devnet-5, especially in light of current discussions in the community about potential gas limit increase and agreeing on the blob increase. I think it will be important to make sure we limit EL payload size. + +**Tim**: This PR seems to address Danno's issues. Does anyone think we should *not* include this? + +**Stokes**: I'd like to hear what EL client teams think in terms of implementation complexity? I think it has a lot of merit on the security front, but is it going to add weeks of delay to Pectra? + +**Tim**: Reth, Besu, and Ethereumjs say in chat the impact should be low. Lightclient says it adds complexity to reasoning about tx cost and may introduce some weird gas sheltering schemes. + +Question from Pari: on the testing side, do we have a sense of how big of a lift this is to include? + +**Mario**: No sense as of yet, but I think it is not going to be straightforward. i don't have a clear idea yet. We have made some preparations for this EIP in our repository, but still we need to check and see how long-- probably couple of weeks to implement this. + +**Tim**: How do you feel about the rest of the fork so far? Is the rest of Pectra in a relatively good spot? + +**Mario**: We have PRs for everything for devnet-5. It's looking good, we are probably going to be able to make a release soon. For 7623, I don't think that should be a blocker, but if anything comes up I can signal it. + +**Daniel**: I just wanted to propose that maybe instead of including in devnet-5, we include it in devnet-6 to not block testing of devnet-5. + +**Tim**: It depends on how fast we think devnet-5 will be finalized? If it's in the next week then sure, but if it's going to be a couple weeks then we can include this. I'd rather devnet-5 be the final devnet. + +Does anyone think devnet-5 is ready for launch in the next week or two? + +**Daniel**: We should discuss other EIP to get a good sense of full scope. + +**Tim**: Regardless of devnet-5 or devnet-6, any strong objections to including 7623 so we can finalize the Pectra scope and spec? + +**Barnabus**: The main blocker is 7742 still on the implementation side. If this is a small implementation on the EL side, then we might not even be ready with 7742 before we would be done with this new EIP. + +I haven't heard from any client teams that are 100% done with it on CL or EL. + +**Tim**: Is anyone done? Reth and Besu say they are close, but not done. If teams are mostly done with 7742 and think this is doable, then we can move forward with it. We can discuss devnet-5 or devnet-6 after once we have a better sense. + +**Stokes:** Can we go ahead and include it now and then take it out in a week or two if it ends up being bigger than we think? + +**Paritosh**: Maybe we give the testing some time to look into it? If they say it will take another 3 weeks to have the tests for 7623 then we don't want to block devnet-5 for this one EIP. + +**Mario**: We can have an estimate on Monday's testing call. + + +------------------------------------- +### 201.4 | **Pectra Scoping** | Discussion on [EIP-7762](https://eips.ethereum.org/EIPS/eip-7762) inclusion + +**Tim**: Next on the agenda is EIP-7762, which is the minimum blob price increase. We discussed this as well on last week's call and couldn't quite come to a decision; anyone have thoughts about what to do there? + +**Toni**: We also discussed on last week's Consensus Layer call. We agreed that we don't want to do *all* the changes that are proposed at once on Pectra. There were discussions about picking out minimum blob base fee and only shipping that. I'm indifferent about that one, but I think we should stick to *not* including all the base fee changes in Pectra. + +**Ansgar**: The decision is indeed to not ship the big package.This EIP is only for minimum base fee increase -- a one line change-- and was modified last week to include excess gas reset. You can have a look at the EIP, it is still very smol and the excess gas reset is just one IF statement. One line change is eseentially a 4 line change now. + +Given that it is so tiny, and has a meaningful improvement to UX for rollups who have been signaling that this would be valuable for them, I am in favor of including this. + +**Max**: Maybe one more thing in terms of complexity of test cases. If there are going to be changes to the update rule, I think the additional test cases from including this EIP-- along with the blob increase which will adjust the rate of change-- will be pretty minimal because you'll already have to change the test cases for that. + +**Ansgar**: This is a really good point and one thing that came up in the update fraction change discussion. I think it makes testing slightly simpler even. + +**Tim**: Have any EL teams reviewed this? Ethereumjs seems in favor. + +**Stokes**: Are we talking about just raising the minimum fee or the other things in this PR? + +**Toni**: Only the minimum fees. + +**Ansgar**: The decision is on the current state of the EIP, no open PRs. + +**Stokes**: Okay, yes, this is much simpler. It does add another EIP and overhead of testing. + +**Tim**: The downside of not doing this is that we stay in this awkward world where sometimes the blobs are effectively free and sometimes they get repriced very slowly relative to the market. + +**Max**: The problem is more that they get repriced very slowly recently and when they reprice very slowly, every 20 hours, where we have a 3h period of price discovery and a 3hr period of going back down to less capacity overnight when there's less demand. In that 3hr period we're basically defaulting to first price fee market. + +**Stokes**: And that's a problem because rollups don't want to think about volatile fee markets? + +**Max**: It makes it so that if the rollups are charging for gas they have to do so based on a first-price fee market, which noone understands, versus says your gas on rollup is a function of blob fee on Ethereum today. Makes it much easier for rollups to read and provide gas pricing for their users when it's the number from the controller rather than number from controller + whatever else is happening in first-price fee market + whatever is happening in MEV land for that particular block. + +**Stokes**: I think the strongest counter argument I've heard is what I've seen from lightclient in the chat, that it's just early and presumably we will in price discovery for the blobs and this issue will go away. + +**Max**: We are at price discovery but the demand fluctuates. + +**lightclient**: I don't think we should orient the Ethereum fee market to be US-focused, which is what Max is saying. + +**Tim**: It's more that whenever noone uses blobs or when people decide to use blobs again, we're too slow to adapt. + +**lightclient**: It's still too early in the life of blobs for us to be meddling with the actual price mechanism. Let's revisit it again in the next fork if we're still having problems. + +**Ben Adams**: Aren't we proposing doubling the blobs? That's just going to make it worse. It's not like we're not meddling. + +**Max**: There are already several changes to the controller as well as the blob increase in this fork. We have very strong theoretical reasons why this would increase price discovery with very minimal changes. In total this is, at most, $100,000 a year change to the blob prices, but we think it will make the speed of price discovery much fast. We now see in the data that this is happening very often. + +**lightclient**: We also thought that price discovery was just going to happen once before we implemented blobs, which was wrong. How can we know that this proposal would fix all these problems? + +**Max**: That is not what the proposal claims to do. It claims to be an adjustment, which is low overhead, that we know will improve by some factor. It won't make the blob market perfect, but it will improve it. + +**Ansgar**: I would really strongly recommend adding this EIP. It is a strong change and the situation will get significantly worse from today with this change in throughput. We now maximally can increase the block base fee by 8% per block instead of todays 12%. It takes significantly more time to ramp up...Rollups would prefer us adding this. Testing complexity is basically zero because you already need to run the tests. + +**Paritosh**: Note that each EIP we add will delay Pectra. So the choice is more scaling faster or more EIPs + scaling slower. There is no world in which we can have more EIPs and things faster. + +**Tim**: Even if the changes are small, and we have 12-15 of them in the fork right now, it will delay shipping Pectra. + +**Paritosh**: The question is whether the tradeoff is worth it. + +**Max**: What Ansgar is saying is that the changes are 4 lines. Many of tests are overlapping with what is already taking place because of other rollup EIP. + +**Tim**: What are the risks of not making decision today? + +**Max**: The code itself is a 4-line change, but the tests will need to be rewritten and adjusted. + +**Stokes**: Given that rollups are the user, it would be nice to hear from them directly. + +**Tim**: Ansgar says there is rollcall next week (but we already have signal that they really want this). We can bring this up in the call next week to get feedback and give ourselves time to have a better sense on testing. + +If we finalize today, my sense is that we don't do this. + +**Barnabus**: If we delay one more week, we will not finalize this year. + +**Daniel**: Does this mean the proposal is not included and we would maybe have a devnet-6 for this one EIP? + +**Paritosh**: Devnet numbers are made up, we can add more if we need to. + +**Ansgar**: That seems like the worst option in this case. If we delay to next week, it might not make it to devnet-5 and then we might not want to open a new devnet for it. We are rolling the dice on whether or not to include it. + +**Tim**: We are strained with capacity. We need to evaluate what the impact is before making the decision. + +**Ansgar**: But by delaying it, we change the cost. By next week it might be much larger because it would require a new devnet. + +**Tim**: But I don't think we know today whether this would require a new devnet. + +**Ansgar**: It's fine if the decision is not to include, but we should make the decision today, not delay it to next week. + +[ *disagreement in the chat about whether or not there's consensus around this decision; deferred to next week* ] + + +------------------------------------- +### 201.5 | [EIP-4444 & EIP-7639 rollout](https://hackmd.io/Dobc38YVQ1qmbbyI6LcFqA) | + +**Tim**: Next up, history expiry. Piper you shared a document, do you want to give some context on this? + +**Piper**: We made a decision at the R&D workshop and we have all the execution client teams on board for rolling out what we'll continue to call four 4s with a timeline of dropping a significant part of the history by May 1, 2025. + +Document linked above gives summary of everything going on here. Official EIP number is [7639](https://eips.ethereum.org/EIPS/eip-7639). It specifies a new version of the Eth protocol (Protocol Version 71) for which clients will be allowed to stop responding to certain messages about history. The exact thing we agreed on was dropping block bodies and receipts only for pre-merge data, so that does not include the header chain or any data after merge. Loose estimates suggests this accounts for a couple hundred gigabytes of disc space, this gains us some amount of leeway here on that 4 terabyte hardrive limit. + +The agreement in terms of what consensus was reached was strictly about clients no longer being required to respond to this data over devp2p after that drop date. The exact implementations that clients will be taking with respect to how they handle this data is up for grabs. Every client is able to make their own decisions. We still have clients implementing full syncs, executing all blocks from genesis, they'll be implementing their own plans for how they fetch, retrieve, deal with all that long history data. We have other clients who are going to be implementing Portal Network clients for the Portal Network history network in their clients for surfing things like json rpc. + +That's the high-level overview for this. We met with all the client teams during Devcon, I think everyone knows what they're doing. The time to start working on this is now so that we're ready. Lightclient has pointed out that for this new protocol version we need to warm it up, not have it just turn on May 1st, but client teams should have versions of their clients out before then that allow for both old and new versions to exist at the same time. + +**Andrew**: One comment is that we need to finalize Eth/69 and our side we have some concerns about its compatibility with Polygon. We need some time to prepare and maybe can discuss on next all core devs call. + +My other question is do we actually need a new protocol (Eth/71) to explicitly prohibit answering a historical block request. + +**Piper**: I was going to ask that same question. I don't have a strong opinion about this. Hopefully we could answer that today or async if other client teams want to weigh in. + +**Ahmad**: Given that 3-4 other clients are going to implement 7801, 7801 is going to be Etha subprotocol and everyone can then see premerge history on eth protocol. The reason we want it to be a subprotocol so that eth protocol will not be affected by clients potentially calling clients that do not support 7801. Don't want to give the assumption that all clients are going to support serving historical blocks through 7801. + +**Piper**: Correct, so that sounds like that's a little in favor of not implementing a new Eth subprotocol version. It seems like that could happen independent of whether we have a new eth subprotocol. + +**Ahmad**: No, because when you implement a new eth subprotocol you declare that you support the new subprotocol. If you don't declare it, then no one will ask you for it. + +**Piper**: I'm referring specifically to the new ETh protocol version (Eth/71), not whatever new protocol version 7801 goes on. + +**Adhmad**: Since some clients are going to drop blocks and most nodes are going to drop pre-merge blocks, it wouldn't be fair to anyone to keep saying 'hey I might have the blocks or might not', so we say anyone who is in Eth/70 or 71 will stop serving pre-merge blocks. And if you want to serve pre-merge blocks, you implement the subprotocol. + +**Piper**: Got it, so in your version, anybody who is on Eth/70 may or may not serve the block history and anyone on Eth/71 definitely doesn't serve the block history? + +**Lightclient**: This is just for Eth/71--you *must* not serve pre-merge data on Eth/71 but we can make it clear that you could for earlier versions. + +**Piper**: The endgame here is that we get a sharded Eth pro tocol between the clients that do and don't serve historical blocks; seems like a problems state for things to be in, where there's an option to stay on the old protocol and continuing to serve old blocks. + +**Andrew**: Yeah, I don't like this bifurcation in protocols. Maybe we can make Eth/70 generic enough to allow for clients who don't want to store any historical blocks to explicitly say so. + +**Ahmad**: If you don't put any 1s in your bitmask that means you don't have any history that you don't want to serve; it's easy to implement. If we want to encode the bitmask inside the ENR then that's different. I think I am fine with the handshake. + +I think Geth team is still in favor of having it as a separate protocol regardless of whether we do it in this way, just because they want to keep the network uniform. + +We could change the language to say instead of 'cease serving history' we leave it to the client teams and not have a separate subprotocol (etha) for serving history. + +Lightclient: What is the argument against etha? Isn't it just a string within the handshake. I personally don't care etha versus another version, it's just a string. + +Andrew: From my point of view, etha is fine, what I don't like is Eth/70 for this sharded block proposal and then Eth/71 for actually stimulating must not serve historical blocks because then we have a bifurcation in protocol. + +**Ahmad**: Okay sorry maybe there's a confusion, which is why I asked lightclient to change his version to Eth/70. We are going to not use the 70 version since it's a new subprotocol, it does not conform to the same versioning scheme. + +**Piper**: To round this back up: 7801 goes on a different subprotocol, not part of the Eth protocol. Anyone who is doing 7801 things, it is on a new separate protocol and separate string. The question here is whether there is opposition to doing 4444 without bumping the Eth protocol version and keeping it at 70 with the dropoff date. + +**Lightclient**: We need to bump the version. We don't want to stop serving history on a specific version because then when you connect you won't know if they have the history or not. If you haven't updated your clients and are trying to bootstrap, you're going to try to download but if everyone else updated you won't be able to connect to the network. + +**Piper**: Isn't that the same case though? Isn't the same case true whether we bump the protocol version or not? If you don't update and you connect to the network but everyone else is on the new protocol version and dropped the history, they're no longer serving the data. + +I think we need to do a bit of async discussion on the exact roll out plan for this. It doesn't seem like we have clear consensus here today. I will try to get a write up posted of the two different approaches and see if people want to weigh in on. + +**Tim**: What is the rationale for not having an explicit separation? What do you gain by not having an explicit tell that there's a different version people are running? + +**Piper**: 1. There isn't much of a difference in the actual protocol definition. The actual messages are all the same but the behavior of the request is different. 2. Added complexity and cross-network compatibility. + +**Andrew**: 1. Protocol Eth/69 which we discussed but isn't finalized yet. It has some proposed merge clean ups and we realized it might not play nicely with polygon, so we need to think about it more and discuss again. Basically, Eth/69 is not relevant to 4444s; sequentially it's something that we should finalize if we're talking about Eth/70. + +I also think that we need one single protocol that works for all nodes whether they're storing historical blocks or not. When you need to download historical blocks, it should be explicit with your peers, which blocks your peers have. + +If we do something like 7801 concurrently with a new version of the protocol that actually prohibits historical blocks that creates a bifurcation in the network. My strong preference is to have a single protocol that works for clients that decide to store historical blocks and those who don't. + +**Tim**: Piper, if you want to write something up and post it on the Discord, we can continue this conversation async. + +**lightclient**: If we decide to have this additional provider protocol, it is important that we roll this out with Prague. How do we add that to the Prague hard fork meta? + +**Tim**: In general, we should start adding non-consensus changes to meta hard forks. We have done some things like this in the past, but it does feel important to signal. We can discuss at the end of this call. + + +------------------------------------- +### 201.6 | [EIP-4803] (https://eips.ethereum.org/EIPS/eip-4803) | + +**Tim**: Next up, Axic shared this on the agenda: EIP-4803. A while back we discussed adding bounds to constants in the protocol. We did add a couple, but this one was never confirmed. + +**Alex**: The one we merged back a couple of years ago was 2681 (limiting the account nonce) and there was another larger EIP (1985), which was proposing bounds to pretty much everything. At the time, we agreed to the account nonce limit and to split this 1985 into smaller individual changes; this EIP is one of them. + +This EIP is proposed to be enabled from genesis and it limits gas limits on transactions. No transactions can have a gas limit higher than 2^63-1. The reason is that it allows simplifications in the EVMs, which using 2^63 it can be handled as a signed number and checking whether the out of gas condition is reached is a matter of checking if the gas became negative. + +This can be enabled from genesis because most of the clients, including Go Ethereum, already do this internally. Additionally, it is expensive to create transactions with a limit higher than this because you need the funds available up front. + +Are there any strong reasons against this or should we consider spending more time discussing? + +**Tim**: Why use a different constant for this than 2681? + +**Alex**: The reason we should go with 63 is because then it can be a signed number and the out of gas check is simpler. + +**Tim**: There's a comment from Barnabus around testing and inclusion in the fork. Even if we retroactively add this from genesis, we need some tests for this first. It feels like a bad time to add those tests given everything with Pectra. That aside, assuming we got to this once Pectra is done, is there feedback on design or conceptually? + +**lightclient**: It would be helpful to see if there were examples for using this negative gas value. I kind of understand that it's possible to use this to indicate when out of gas, but if you could link to an example where a client is doing this and what the implication would be. + +**Alex**: evmone was doing this; but the way you could do it, you just subtract the gas and check whether it is a negative value. Internally, CPUs would usually have specific instructions for the negativeness check, so technically it can be cheaper. + +The limit, 63 or 64 is a discussion to be had. Setting that aside, can we atleast agree conceptually that putting this limit is something people agree with or have reasons not to? + +**Tim**: It seems like there are no objections. For next steps, Alex if you are able to open a PR, we have a meta EIP to track these retroactively applied EIPs, so open a PR to that EIP and list this one. +We don't have to merge the PR now, but can revisit post-Pectra testing. + +**Alex**: Sounds good. Re: 7825 (comment from Ben) +7825 proposes to introduce a lower limit, a limit of 30 million. My comment was that the PR I'm proposing can be enabled retroactively whereas 7825 may not be able to be enabled retroactively. The two are related and essentially you could have both at the same time. One is an implementation whereas the other is a limit that we may or may not change over time. + + +------------------------------------- +### 201.7 | [Potential ACD Improvements](https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157/51) | [Declined for Inclusion](https://github.com/ethereum/EIPs/pull/9056) update, Non-consensus changes in Meta EIPs, PFI → CFI → SFI & devnet inclusion + +**Tim**: As we discussed in Bangkok, three ideas came out of the ACD Process Improvements Sessions: + +1. adding 'declined for inclusion' status to meta EIPs for hard forks - +The idea is that we decide to accept things into hard forks but we don't have formal rejections for current fork. It doesn't mean we will never do the EIP, obviously someone can work on any EIP and are free to propose everytime there is a new fork, but we do spend a lot of time discussing EIP inclusion for each fork so having this status would be valuable. + +2. adding non-consensus changes to meta EIPs - +We have meta EIPs for hard forks and it's clear why we need them because there are a set of changes that need to happen at a specific block. One challenge with that is that it means our process often biases toward things that have to activate at a specific block, e.g. spent years talking about 4444s but it doesn't get prioritized because it's not on the same list as everything else. The proposal is that we start including non-consensus changes at hard forks and for something that is not a non-consensus change (like 4444s), the implication is that clients will have this client feature shipped *at the latest* at the hard fork. + +**Stokes**: That makes sense. One thing to note is that we still have the ability to ship non-consensus changes without a hard fork, but this is addressing the false positives. + +**Tim**: Correct. We can ship things before and in practice this would look like compiling a list of previously activated changes to the specs for a hard fork. At this block, all these are active on the core protocol. + +**Pooja**: Just wanted to make sure this is for proposals going to be shipped *before* the hard forks, and not those proposals which are going to be retroactively added. + +**Tim**: Yes, I would keep those separate. The retroactively added EIPs, everyblock from block zero should implement those protocol rules. And we can only add those when it's true that in the entire history those conditions were not broken. Whereas something like dropping history, this was not true of the entire chain history. So it feels more accurate to say, 'as of this hard fork this change is live' even though it's not a consensus change. + +My point is that we would add *all* protocol changes, whether or not their core EIPs, since the hard fork. We can both retroactively do this and we can decide to prioritize proactively. + + +------------------------------------- +### 201.8 | End of year coordination and holiday meeting schedule | +Testing call on Dec 23 +Cancel ACDE on Dec 26 +Cancel testing call on Dec 30 +Replace ACDC by testing call on Jan 2 + +------------------------------------- +### Attendees +* Tim +* Lightclient +* Ognyan Genev +* Ruben +* Tomasz Stanczak +* Daniel Lehrner +* Ben Adams +* Pooja Ranjan +* Anders K +* Guru +* Julian Rachman +* Ben Edgington +* Ameziane Hamlat +* Jihoon +* Danno Ferrin +* Paritosh +* Enrico Del Fante +* Ansgar Dietrichs +* Barnabus +* Kevaundray +* Stokes +* Kolby Moroz Liebl +* Toni Wahrstätter +* Hadrien Croubois +* Dave +* Arik Galansky +* Dragan Rakita +* Spencer +* Frencesco +* Frangio +* Matthew Whitehead +* Piotr +* Terence +* Scorbajio +* Mario Vega +* Mingming Chan +* Gajinder Singh +* Andrei +* Yiannis +* Łukasz Rozmej +* Trent +* Ignacio +* Richard Meissner +* Danceratopz +* Milos +* Guillaume +* Oliver (Reth) +* Karim +* Saulius +* Radek +* Andrew Ashikhmin +* Jared Wasinger +* Max Resnik +* Hsiao-Wei Wang +* Somnath +* Mikhail Kalinin +* Yoav +* Luis Pinto +* Elias Tazartes + + From d69dd62cca40ccd4f5d1a9d294cf1b9776bd20ca Mon Sep 17 00:00:00 2001 From: jamnuel <158302490+jamnuel@users.noreply.github.com> Date: Fri, 20 Dec 2024 12:52:45 -0600 Subject: [PATCH 07/51] Delete AllCoreDevs-EL-Meetings/Execution Layer #201 Need to rename file --- AllCoreDevs-EL-Meetings/Execution Layer #201 | 446 ------------------- 1 file changed, 446 deletions(-) delete mode 100644 AllCoreDevs-EL-Meetings/Execution Layer #201 diff --git a/AllCoreDevs-EL-Meetings/Execution Layer #201 b/AllCoreDevs-EL-Meetings/Execution Layer #201 deleted file mode 100644 index 56b3c2e9..00000000 --- a/AllCoreDevs-EL-Meetings/Execution Layer #201 +++ /dev/null @@ -1,446 +0,0 @@ -# Execution Layer Meeting #201 -### Meeting Date/Time: Dec 5, 2024, 14:00-15:30 UTC -### Meeting Duration: 1h35m -### [GitHub Agenda](https://github.com/ethereum/pm/issues/1197) -### [Video of the meeting](https://youtube.com/live/Umh7ZKukmtY) - - - - - -### Moderator: Tim -### Notes: June - -| S No | Agenda | Summary | -| -------- | -------- | -------- | -201.1 | **Pectra updates: Mekong & devnet-5 updates** | Mekong testnet is operational ~97% attestation performance; minor issues to address, mostly good on Mekong front and focused on getting all the PRs merged for devnet-5; devnet doc has been updated by testing team to show where the status of tests are. -https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 -201.2 | **Pectra Scoping** | BLS gas pricing discussion of Marek's PR [here](https://github.com/marchhill/bls-precompile-benchmarks/blob/main/proposed-changes.md); Most client teams in production and on call agreed that the proposal works for them to move forward with for now; need confirmation from Besu async; can modify with more fine-grain anaylsis in the future. -201.3 | **Pectra Scoping** | Discussion on [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) inclusion and update with additional security considerations [EIPs#9086](https://github.com/ethereum/EIPs/pull/9086_); 7623 focuses on capping transaction payload sizes to improve network performance and security; client teams all agree it would be a small thing to implement and wouldn't significantly impact timelines; decision to move forward with 7623 on devnet-5 pending confirmation from testing team. -201.4 | **Pectra Scoping** | Discussion on [EIP-7762](https://eips.ethereum.org/EIPS/eip-7762) inclusion; proposes minimum blob price increase; disagreement on whether to include this in Pectra; deferred one week for feedback from rollups and testing. -201.5 | **[EIP-4444 & EIP-7639 rollout](https://hackmd.io/Dobc38YVQ1qmbbyI6LcFqA)** | Discussion and disagreement about best protocol versioning for this implementation and whether or not some clients should be able to provide historical blocks while others don't; concern about protocol fragmentation; Piper to compile notes and create discussion async. -201.6 | **[EIP-4803] (https://eips.ethereum.org/EIPS/eip-4803)** | This EIP is proposed to be enabled from genesis and it limits gas limits on transactions; no objections conceptually but won't be address until after Pectra testing; Alex to create a PR. -201.7 | **[Potential ACD Improvements](https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157/51)** | Agreement to add [Declined for Inclusion] status for EIPs that will not be included in the hard fork; EIPs still open for discussion and available for future hard forks; agreement to include all non-consensus protocol changes in list of hard fork changes to make sure everything is up to date for each hard fork. -201.8 | End of year coordination and holiday meeting schedule | Testing call on Dec 23, Cancel ACDE on Dec 26, Cancel testing call on Dec 30, Replace ACDC by testing call on Jan 2 - -### 201.1 | Pectra updates: Mekong & devnet-5 updates -**Tim**: Welcome everyone to ACDE #201. Couple things on the agenda today, most importantly we can hopefully finish the scope of Pectra and be able to move forward with the specs. After, some conversations around EIP4444 as well as 7639 about dropping history. Then there was an edge case to revist around capping transaction gas amount and then if we have time left, there are a couple ACD process improvements I wanted to cover. - -Pari, Banabus, either of you want to give an update on testnets? - -**Pari**: We have Mekong continuing to run-- we're at 97% attestatino performance. Grandine team has pushed a lot of fixes, mostly okay now. Some problems still with Ethereumjs and Nimbus EL, but mostly good on Mekong front and focused on getting all the PRs merged for devnet-5. -PRs here: -CL - https://github.com/ethereum/consensus-specs/pull/3800 -CL - https://github.com/ethereum/consensus-specs/pull/4023 -EL - https://github.com/ethereum/execution-apis/pull/574 - -Devnet doc has been updated by testing team to show where the status of tests are. -https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 - - -**Tim**: Any other EL PRs that you want to bring people's attention to? - -**Ansgar**: Regarding [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691), there was this open question of what exact update fraction we would go with and we chose the number that is the middle sensitivity between 3-6. We couldn't have 6 blobs less than the target or 3 blobs more than the target, so we picked the middle; now a very full block will have slightly less than 12% increase and a fully empty block will have slightly more than 12% decrease. - -**Toni**: Was just in the process of reviewing the EIP-7691 PR; only one small typo then we can merge. - -**Paritosh**: lightclient brought up [7702 txpool](https://eips.ethereum.org/EIPS/eip-7702) in chat, maybe he wants to discuss? - -**lightclient**: just checking again to see if anyone has looked into it or implemented it? We are in the process of implementing now. - -**Marek**: Nethermind is looking into it, but others can comment on that. - -**Anders**: Yes, we had a discussion on Discord [interop channel]. We had some suggestions but it seems the discusssion stalled. - -**Tim**: As people work on this, share any updates or designs in the discord chat. - - -------------------------------------- -### 201.2 | Pectra Scoping | BLS gas pricing - -**Tim**: Moving on, it's worth chatting about Pectra scope changes. It feels like we're close to finalizing scope, it would be ideal if we could do so on today's call so we have a final set of specs to work with before the holidays. We can come back in January with a clear target to implement. - -On CL, everything seems pretty resolved. - -On EL, some major open questions: first is BLS gas pricing, second is whether to include EIP-7623, lastly is EIP-7762, an adjustment to the blob base fee. - -Let's start with BLS one since it's already included in Pectra and needs to be fixed. Anyone with context on latest BLS pricing discussion? - -**Marek** I took all the numbers and opened a PR, in the [link here](https://github.com/marchhill/bls-precompile-benchmarks/blob/main/proposed-changes.md) we have Nethermind BLS pricing proposal and it would be great if it could be validated by other teams. I think Pawel had a different idea how to price MSM (multi-scalar-multiplication) operations but I don't fully understand, so we need to agree with Pawel about this. - -**Tim**: Have any other teams reviewed or have any strong opinions? - -**Kevaundray**: From the pricings, atleast from what we know from the current numbers, Nethermind for G1MSM would need to go up by 2.5x, Besu and Geth would need to go up by 2x, and evmone would need to go up by 3x. For G2, Nethermind is 1.5, Geth and evmone are 2x. We could go with these pricings but they're more costly than what we would like. - -**Tim**: By 'these pricings,' you mean Marek's current PR? - -**Kevaundray**: We took the worst case of what everyone has already given us in order to cover all of the clients. It's just a more coarse way to do the pricing. - -**Tim**: Do you have a sense of the impact on users for having this more coarse pricing scheme? - -**Kevaundray**: We don't know exactly because it depends on the use cases. My suggestion would be to commit to coarse pricing and we can use other tools to determine a new curve to use. At the moment, we haven't committed to any pricing. I would like to avoid the 3x that is there but it's the only one we've seen imperfectly that covers everyone else. - -**Tim**: So I understand evmone was slow on some of these; that's the one that would be covered by 3x? - -**Kevaundray**: Right, the next lowest would be the Nethermind proposal of 2.5x scaling. - -**Tim**: Is evmone used in production by any clients? - -**Andrew**: Not yet, but we would like to switch Erigon to evmone. At the moment it still uses GoLangEVM which is essentially the same as used in Geth. - -**Tim**: Nethermind uses the same library. I'm trying to understand why evmone is slower and does it make sense to put our worse case on an evm that is not beign used in production today or should we use whatever is already in production? - -**Kevaundray**: To answer the first question, evmone is different and has issues even when using the same library because everyone is basing it off ez-recover, but that's not the same across every library. - -**Radek**: This is not exactly about evmone, but about the blst library, which is used by Nethermind and Reth. This means that the speed is not only the case with evmone but with the library itself. - -**Kevaundray**: Right, so Nethermind uses the same library but it's a 2.5x. This goes down to the issue of ez-recover not being the same across everyone because everyone is scaling based on ez-recover. - -**Tim**: Anyone from Geth or Besu have time to review? Jared says Geth would be good with Nethermind's proposal. My sense is that if Besu is also good with it we should move forward, even if it is slightly underpriced for evmone. - -**Kevaundray**: What do people think about the proposal to commit to 2.5x or 3x and then wait for a gas optimizer tool to possibly give us finer-grain numbers, but we commit to something for the time being? - -**Tim**: Discussion in chat to agree async but before devnet-5. Marek, how much time do you think we need to agree to this? If we could get consensus on your PR as a basecase that we could modify later on, is there a reason to push this back async before we make the decision? - -**Marek**: There is no clear number, we can discuss async, but we should decide before devnet-5. - -**Tim**: It is fine to do it async, but recommend getting to a resolution on testing call Monday. Get us to as final of a pricing scheme as soon as possible. - -**Stokes**: Kev's recommendation is a good way to make progress today. Sounds like this PR gets us directionally closer to what we all like. - -**Tim**: If all of the production clients are fine with this number, we should go ahead and merge. Worth getting a sanity check from Besu, but assuming they can approve async today or tomorrow, we merge. - -**Stokes**: If anyone has a BLS-signature verifier that works with the latest for Pectra, let me know on Discord. Would be nice to have a sense of end-to-end cost for this. - -------------------------------------- -### 201.3 | Pectra Scoping | [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) inclusion and update discussion with additional security considerations [EIPs#9086](https://github.com/ethereum/EIPs/pull/9086_); - -**Tim**: Next up is EIP-7623, Danno you raised some issues on EthMagicians and then Toni opened a PR to address them. Toni, do you want to give a quick recap on those changes? - -**Toni**: We discussed on the consensus layer call last week as well. The main contention we always had with 7623 was not about the mechanism but the scope of Pectra itself. Regarding Danno's suggestions, I included them and incorporated them into the EIP. You can now find a more elaborated backwards compatibility section and security considerations, including the concerns we clarified that William raised about the gas sheltering. I would now propose that we include it and ship it in devnet-5, especially in light of current discussions in the community about potential gas limit increase and agreeing on the blob increase. I think it will be important to make sure we limit EL payload size. - -**Tim**: This PR seems to address Danno's issues. Does anyone think we should *not* include this? - -**Stokes**: I'd like to hear what EL client teams think in terms of implementation complexity? I think it has a lot of merit on the security front, but is it going to add weeks of delay to Pectra? - -**Tim**: Reth, Besu, and Ethereumjs say in chat the impact should be low. Lightclient says it adds complexity to reasoning about tx cost and may introduce some weird gas sheltering schemes. - -Question from Pari: on the testing side, do we have a sense of how big of a lift this is to include? - -**Mario**: No sense as of yet, but I think it is not going to be straightforward. i don't have a clear idea yet. We have made some preparations for this EIP in our repository, but still we need to check and see how long-- probably couple of weeks to implement this. - -**Tim**: How do you feel about the rest of the fork so far? Is the rest of Pectra in a relatively good spot? - -**Mario**: We have PRs for everything for devnet-5. It's looking good, we are probably going to be able to make a release soon. For 7623, I don't think that should be a blocker, but if anything comes up I can signal it. - -**Daniel**: I just wanted to propose that maybe instead of including in devnet-5, we include it in devnet-6 to not block testing of devnet-5. - -**Tim**: It depends on how fast we think devnet-5 will be finalized? If it's in the next week then sure, but if it's going to be a couple weeks then we can include this. I'd rather devnet-5 be the final devnet. - -Does anyone think devnet-5 is ready for launch in the next week or two? - -**Daniel**: We should discuss other EIP to get a good sense of full scope. - -**Tim**: Regardless of devnet-5 or devnet-6, any strong objections to including 7623 so we can finalize the Pectra scope and spec? - -**Barnabus**: The main blocker is 7742 still on the implementation side. If this is a small implementation on the EL side, then we might not even be ready with 7742 before we would be done with this new EIP. - -I haven't heard from any client teams that are 100% done with it on CL or EL. - -**Tim**: Is anyone done? Reth and Besu say they are close, but not done. If teams are mostly done with 7742 and think this is doable, then we can move forward with it. We can discuss devnet-5 or devnet-6 after once we have a better sense. - -**Stokes:** Can we go ahead and include it now and then take it out in a week or two if it ends up being bigger than we think? - -**Paritosh**: Maybe we give the testing some time to look into it? If they say it will take another 3 weeks to have the tests for 7623 then we don't want to block devnet-5 for this one EIP. - -**Mario**: We can have an estimate on Monday's testing call. - - -------------------------------------- -### 201.4 | **Pectra Scoping** | Discussion on [EIP-7762](https://eips.ethereum.org/EIPS/eip-7762) inclusion - -**Tim**: Next on the agenda is EIP-7762, which is the minimum blob price increase. We discussed this as well on last week's call and couldn't quite come to a decision; anyone have thoughts about what to do there? - -**Toni**: We also discussed on last week's Consensus Layer call. We agreed that we don't want to do *all* the changes that are proposed at once on Pectra. There were discussions about picking out minimum blob base fee and only shipping that. I'm indifferent about that one, but I think we should stick to *not* including all the base fee changes in Pectra. - -**Ansgar**: The decision is indeed to not ship the big package.This EIP is only for minimum base fee increase -- a one line change-- and was modified last week to include excess gas reset. You can have a look at the EIP, it is still very smol and the excess gas reset is just one IF statement. One line change is eseentially a 4 line change now. - -Given that it is so tiny, and has a meaningful improvement to UX for rollups who have been signaling that this would be valuable for them, I am in favor of including this. - -**Max**: Maybe one more thing in terms of complexity of test cases. If there are going to be changes to the update rule, I think the additional test cases from including this EIP-- along with the blob increase which will adjust the rate of change-- will be pretty minimal because you'll already have to change the test cases for that. - -**Ansgar**: This is a really good point and one thing that came up in the update fraction change discussion. I think it makes testing slightly simpler even. - -**Tim**: Have any EL teams reviewed this? Ethereumjs seems in favor. - -**Stokes**: Are we talking about just raising the minimum fee or the other things in this PR? - -**Toni**: Only the minimum fees. - -**Ansgar**: The decision is on the current state of the EIP, no open PRs. - -**Stokes**: Okay, yes, this is much simpler. It does add another EIP and overhead of testing. - -**Tim**: The downside of not doing this is that we stay in this awkward world where sometimes the blobs are effectively free and sometimes they get repriced very slowly relative to the market. - -**Max**: The problem is more that they get repriced very slowly recently and when they reprice very slowly, every 20 hours, where we have a 3h period of price discovery and a 3hr period of going back down to less capacity overnight when there's less demand. In that 3hr period we're basically defaulting to first price fee market. - -**Stokes**: And that's a problem because rollups don't want to think about volatile fee markets? - -**Max**: It makes it so that if the rollups are charging for gas they have to do so based on a first-price fee market, which noone understands, versus says your gas on rollup is a function of blob fee on Ethereum today. Makes it much easier for rollups to read and provide gas pricing for their users when it's the number from the controller rather than number from controller + whatever else is happening in first-price fee market + whatever is happening in MEV land for that particular block. - -**Stokes**: I think the strongest counter argument I've heard is what I've seen from lightclient in the chat, that it's just early and presumably we will in price discovery for the blobs and this issue will go away. - -**Max**: We are at price discovery but the demand fluctuates. - -**lightclient**: I don't think we should orient the Ethereum fee market to be US-focused, which is what Max is saying. - -**Tim**: It's more that whenever noone uses blobs or when people decide to use blobs again, we're too slow to adapt. - -**lightclient**: It's still too early in the life of blobs for us to be meddling with the actual price mechanism. Let's revisit it again in the next fork if we're still having problems. - -**Ben Adams**: Aren't we proposing doubling the blobs? That's just going to make it worse. It's not like we're not meddling. - -**Max**: There are already several changes to the controller as well as the blob increase in this fork. We have very strong theoretical reasons why this would increase price discovery with very minimal changes. In total this is, at most, $100,000 a year change to the blob prices, but we think it will make the speed of price discovery much fast. We now see in the data that this is happening very often. - -**lightclient**: We also thought that price discovery was just going to happen once before we implemented blobs, which was wrong. How can we know that this proposal would fix all these problems? - -**Max**: That is not what the proposal claims to do. It claims to be an adjustment, which is low overhead, that we know will improve by some factor. It won't make the blob market perfect, but it will improve it. - -**Ansgar**: I would really strongly recommend adding this EIP. It is a strong change and the situation will get significantly worse from today with this change in throughput. We now maximally can increase the block base fee by 8% per block instead of todays 12%. It takes significantly more time to ramp up...Rollups would prefer us adding this. Testing complexity is basically zero because you already need to run the tests. - -**Paritosh**: Note that each EIP we add will delay Pectra. So the choice is more scaling faster or more EIPs + scaling slower. There is no world in which we can have more EIPs and things faster. - -**Tim**: Even if the changes are small, and we have 12-15 of them in the fork right now, it will delay shipping Pectra. - -**Paritosh**: The question is whether the tradeoff is worth it. - -**Max**: What Ansgar is saying is that the changes are 4 lines. Many of tests are overlapping with what is already taking place because of other rollup EIP. - -**Tim**: What are the risks of not making decision today? - -**Max**: The code itself is a 4-line change, but the tests will need to be rewritten and adjusted. - -**Stokes**: Given that rollups are the user, it would be nice to hear from them directly. - -**Tim**: Ansgar says there is rollcall next week (but we already have signal that they really want this). We can bring this up in the call next week to get feedback and give ourselves time to have a better sense on testing. - -If we finalize today, my sense is that we don't do this. - -**Barnabus**: If we delay one more week, we will not finalize this year. - -**Daniel**: Does this mean the proposal is not included and we would maybe have a devnet-6 for this one EIP? - -**Paritosh**: Devnet numbers are made up, we can add more if we need to. - -**Ansgar**: That seems like the worst option in this case. If we delay to next week, it might not make it to devnet-5 and then we might not want to open a new devnet for it. We are rolling the dice on whether or not to include it. - -**Tim**: We are strained with capacity. We need to evaluate what the impact is before making the decision. - -**Ansgar**: But by delaying it, we change the cost. By next week it might be much larger because it would require a new devnet. - -**Tim**: But I don't think we know today whether this would require a new devnet. - -**Ansgar**: It's fine if the decision is not to include, but we should make the decision today, not delay it to next week. - -[ *disagreement in the chat about whether or not there's consensus around this decision; deferred to next week* ] - - -------------------------------------- -### 201.5 | [EIP-4444 & EIP-7639 rollout](https://hackmd.io/Dobc38YVQ1qmbbyI6LcFqA) | - -**Tim**: Next up, history expiry. Piper you shared a document, do you want to give some context on this? - -**Piper**: We made a decision at the R&D workshop and we have all the execution client teams on board for rolling out what we'll continue to call four 4s with a timeline of dropping a significant part of the history by May 1, 2025. - -Document linked above gives summary of everything going on here. Official EIP number is [7639](https://eips.ethereum.org/EIPS/eip-7639). It specifies a new version of the Eth protocol (Protocol Version 71) for which clients will be allowed to stop responding to certain messages about history. The exact thing we agreed on was dropping block bodies and receipts only for pre-merge data, so that does not include the header chain or any data after merge. Loose estimates suggests this accounts for a couple hundred gigabytes of disc space, this gains us some amount of leeway here on that 4 terabyte hardrive limit. - -The agreement in terms of what consensus was reached was strictly about clients no longer being required to respond to this data over devp2p after that drop date. The exact implementations that clients will be taking with respect to how they handle this data is up for grabs. Every client is able to make their own decisions. We still have clients implementing full syncs, executing all blocks from genesis, they'll be implementing their own plans for how they fetch, retrieve, deal with all that long history data. We have other clients who are going to be implementing Portal Network clients for the Portal Network history network in their clients for surfing things like json rpc. - -That's the high-level overview for this. We met with all the client teams during Devcon, I think everyone knows what they're doing. The time to start working on this is now so that we're ready. Lightclient has pointed out that for this new protocol version we need to warm it up, not have it just turn on May 1st, but client teams should have versions of their clients out before then that allow for both old and new versions to exist at the same time. - -**Andrew**: One comment is that we need to finalize Eth/69 and our side we have some concerns about its compatibility with Polygon. We need some time to prepare and maybe can discuss on next all core devs call. - -My other question is do we actually need a new protocol (Eth/71) to explicitly prohibit answering a historical block request. - -**Piper**: I was going to ask that same question. I don't have a strong opinion about this. Hopefully we could answer that today or async if other client teams want to weigh in. - -**Ahmad**: Given that 3-4 other clients are going to implement 7801, 7801 is going to be Etha subprotocol and everyone can then see premerge history on eth protocol. The reason we want it to be a subprotocol so that eth protocol will not be affected by clients potentially calling clients that do not support 7801. Don't want to give the assumption that all clients are going to support serving historical blocks through 7801. - -**Piper**: Correct, so that sounds like that's a little in favor of not implementing a new Eth subprotocol version. It seems like that could happen independent of whether we have a new eth subprotocol. - -**Ahmad**: No, because when you implement a new eth subprotocol you declare that you support the new subprotocol. If you don't declare it, then no one will ask you for it. - -**Piper**: I'm referring specifically to the new ETh protocol version (Eth/71), not whatever new protocol version 7801 goes on. - -**Adhmad**: Since some clients are going to drop blocks and most nodes are going to drop pre-merge blocks, it wouldn't be fair to anyone to keep saying 'hey I might have the blocks or might not', so we say anyone who is in Eth/70 or 71 will stop serving pre-merge blocks. And if you want to serve pre-merge blocks, you implement the subprotocol. - -**Piper**: Got it, so in your version, anybody who is on Eth/70 may or may not serve the block history and anyone on Eth/71 definitely doesn't serve the block history? - -**Lightclient**: This is just for Eth/71--you *must* not serve pre-merge data on Eth/71 but we can make it clear that you could for earlier versions. - -**Piper**: The endgame here is that we get a sharded Eth pro tocol between the clients that do and don't serve historical blocks; seems like a problems state for things to be in, where there's an option to stay on the old protocol and continuing to serve old blocks. - -**Andrew**: Yeah, I don't like this bifurcation in protocols. Maybe we can make Eth/70 generic enough to allow for clients who don't want to store any historical blocks to explicitly say so. - -**Ahmad**: If you don't put any 1s in your bitmask that means you don't have any history that you don't want to serve; it's easy to implement. If we want to encode the bitmask inside the ENR then that's different. I think I am fine with the handshake. - -I think Geth team is still in favor of having it as a separate protocol regardless of whether we do it in this way, just because they want to keep the network uniform. - -We could change the language to say instead of 'cease serving history' we leave it to the client teams and not have a separate subprotocol (etha) for serving history. - -Lightclient: What is the argument against etha? Isn't it just a string within the handshake. I personally don't care etha versus another version, it's just a string. - -Andrew: From my point of view, etha is fine, what I don't like is Eth/70 for this sharded block proposal and then Eth/71 for actually stimulating must not serve historical blocks because then we have a bifurcation in protocol. - -**Ahmad**: Okay sorry maybe there's a confusion, which is why I asked lightclient to change his version to Eth/70. We are going to not use the 70 version since it's a new subprotocol, it does not conform to the same versioning scheme. - -**Piper**: To round this back up: 7801 goes on a different subprotocol, not part of the Eth protocol. Anyone who is doing 7801 things, it is on a new separate protocol and separate string. The question here is whether there is opposition to doing 4444 without bumping the Eth protocol version and keeping it at 70 with the dropoff date. - -**Lightclient**: We need to bump the version. We don't want to stop serving history on a specific version because then when you connect you won't know if they have the history or not. If you haven't updated your clients and are trying to bootstrap, you're going to try to download but if everyone else updated you won't be able to connect to the network. - -**Piper**: Isn't that the same case though? Isn't the same case true whether we bump the protocol version or not? If you don't update and you connect to the network but everyone else is on the new protocol version and dropped the history, they're no longer serving the data. - -I think we need to do a bit of async discussion on the exact roll out plan for this. It doesn't seem like we have clear consensus here today. I will try to get a write up posted of the two different approaches and see if people want to weigh in on. - -**Tim**: What is the rationale for not having an explicit separation? What do you gain by not having an explicit tell that there's a different version people are running? - -**Piper**: 1. There isn't much of a difference in the actual protocol definition. The actual messages are all the same but the behavior of the request is different. 2. Added complexity and cross-network compatibility. - -**Andrew**: 1. Protocol Eth/69 which we discussed but isn't finalized yet. It has some proposed merge clean ups and we realized it might not play nicely with polygon, so we need to think about it more and discuss again. Basically, Eth/69 is not relevant to 4444s; sequentially it's something that we should finalize if we're talking about Eth/70. - -I also think that we need one single protocol that works for all nodes whether they're storing historical blocks or not. When you need to download historical blocks, it should be explicit with your peers, which blocks your peers have. - -If we do something like 7801 concurrently with a new version of the protocol that actually prohibits historical blocks that creates a bifurcation in the network. My strong preference is to have a single protocol that works for clients that decide to store historical blocks and those who don't. - -**Tim**: Piper, if you want to write something up and post it on the Discord, we can continue this conversation async. - -**lightclient**: If we decide to have this additional provider protocol, it is important that we roll this out with Prague. How do we add that to the Prague hard fork meta? - -**Tim**: In general, we should start adding non-consensus changes to meta hard forks. We have done some things like this in the past, but it does feel important to signal. We can discuss at the end of this call. - - -------------------------------------- -### 201.6 | [EIP-4803] (https://eips.ethereum.org/EIPS/eip-4803) | - -**Tim**: Next up, Axic shared this on the agenda: EIP-4803. A while back we discussed adding bounds to constants in the protocol. We did add a couple, but this one was never confirmed. - -**Alex**: The one we merged back a couple of years ago was 2681 (limiting the account nonce) and there was another larger EIP (1985), which was proposing bounds to pretty much everything. At the time, we agreed to the account nonce limit and to split this 1985 into smaller individual changes; this EIP is one of them. - -This EIP is proposed to be enabled from genesis and it limits gas limits on transactions. No transactions can have a gas limit higher than 2^63-1. The reason is that it allows simplifications in the EVMs, which using 2^63 it can be handled as a signed number and checking whether the out of gas condition is reached is a matter of checking if the gas became negative. - -This can be enabled from genesis because most of the clients, including Go Ethereum, already do this internally. Additionally, it is expensive to create transactions with a limit higher than this because you need the funds available up front. - -Are there any strong reasons against this or should we consider spending more time discussing? - -**Tim**: Why use a different constant for this than 2681? - -**Alex**: The reason we should go with 63 is because then it can be a signed number and the out of gas check is simpler. - -**Tim**: There's a comment from Barnabus around testing and inclusion in the fork. Even if we retroactively add this from genesis, we need some tests for this first. It feels like a bad time to add those tests given everything with Pectra. That aside, assuming we got to this once Pectra is done, is there feedback on design or conceptually? - -**lightclient**: It would be helpful to see if there were examples for using this negative gas value. I kind of understand that it's possible to use this to indicate when out of gas, but if you could link to an example where a client is doing this and what the implication would be. - -**Alex**: evmone was doing this; but the way you could do it, you just subtract the gas and check whether it is a negative value. Internally, CPUs would usually have specific instructions for the negativeness check, so technically it can be cheaper. - -The limit, 63 or 64 is a discussion to be had. Setting that aside, can we atleast agree conceptually that putting this limit is something people agree with or have reasons not to? - -**Tim**: It seems like there are no objections. For next steps, Alex if you are able to open a PR, we have a meta EIP to track these retroactively applied EIPs, so open a PR to that EIP and list this one. -We don't have to merge the PR now, but can revisit post-Pectra testing. - -**Alex**: Sounds good. Re: 7825 (comment from Ben) -7825 proposes to introduce a lower limit, a limit of 30 million. My comment was that the PR I'm proposing can be enabled retroactively whereas 7825 may not be able to be enabled retroactively. The two are related and essentially you could have both at the same time. One is an implementation whereas the other is a limit that we may or may not change over time. - - -------------------------------------- -### 201.7 | [Potential ACD Improvements](https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157/51) | [Declined for Inclusion](https://github.com/ethereum/EIPs/pull/9056) update, Non-consensus changes in Meta EIPs, PFI → CFI → SFI & devnet inclusion - -**Tim**: As we discussed in Bangkok, three ideas came out of the ACD Process Improvements Sessions: - -1. adding 'declined for inclusion' status to meta EIPs for hard forks - -The idea is that we decide to accept things into hard forks but we don't have formal rejections for current fork. It doesn't mean we will never do the EIP, obviously someone can work on any EIP and are free to propose everytime there is a new fork, but we do spend a lot of time discussing EIP inclusion for each fork so having this status would be valuable. - -2. adding non-consensus changes to meta EIPs - -We have meta EIPs for hard forks and it's clear why we need them because there are a set of changes that need to happen at a specific block. One challenge with that is that it means our process often biases toward things that have to activate at a specific block, e.g. spent years talking about 4444s but it doesn't get prioritized because it's not on the same list as everything else. The proposal is that we start including non-consensus changes at hard forks and for something that is not a non-consensus change (like 4444s), the implication is that clients will have this client feature shipped *at the latest* at the hard fork. - -**Stokes**: That makes sense. One thing to note is that we still have the ability to ship non-consensus changes without a hard fork, but this is addressing the false positives. - -**Tim**: Correct. We can ship things before and in practice this would look like compiling a list of previously activated changes to the specs for a hard fork. At this block, all these are active on the core protocol. - -**Pooja**: Just wanted to make sure this is for proposals going to be shipped *before* the hard forks, and not those proposals which are going to be retroactively added. - -**Tim**: Yes, I would keep those separate. The retroactively added EIPs, everyblock from block zero should implement those protocol rules. And we can only add those when it's true that in the entire history those conditions were not broken. Whereas something like dropping history, this was not true of the entire chain history. So it feels more accurate to say, 'as of this hard fork this change is live' even though it's not a consensus change. - -My point is that we would add *all* protocol changes, whether or not their core EIPs, since the hard fork. We can both retroactively do this and we can decide to prioritize proactively. - - -------------------------------------- -### 201.8 | End of year coordination and holiday meeting schedule | -Testing call on Dec 23 -Cancel ACDE on Dec 26 -Cancel testing call on Dec 30 -Replace ACDC by testing call on Jan 2 - -------------------------------------- -### Attendees -* Tim -* Lightclient -* Ognyan Genev -* Ruben -* Tomasz Stanczak -* Daniel Lehrner -* Ben Adams -* Pooja Ranjan -* Anders K -* Guru -* Julian Rachman -* Ben Edgington -* Ameziane Hamlat -* Jihoon -* Danno Ferrin -* Paritosh -* Enrico Del Fante -* Ansgar Dietrichs -* Barnabus -* Kevaundray -* Stokes -* Kolby Moroz Liebl -* Toni Wahrstätter -* Hadrien Croubois -* Dave -* Arik Galansky -* Dragan Rakita -* Spencer -* Frencesco -* Frangio -* Matthew Whitehead -* Piotr -* Terence -* Scorbajio -* Mario Vega -* Mingming Chan -* Gajinder Singh -* Andrei -* Yiannis -* Łukasz Rozmej -* Trent -* Ignacio -* Richard Meissner -* Danceratopz -* Milos -* Guillaume -* Oliver (Reth) -* Karim -* Saulius -* Radek -* Andrew Ashikhmin -* Jared Wasinger -* Max Resnik -* Hsiao-Wei Wang -* Somnath -* Mikhail Kalinin -* Yoav -* Luis Pinto -* Elias Tazartes - - From 5cf252dc19ea9d78cf89791199b0546a791ce291 Mon Sep 17 00:00:00 2001 From: jamnuel <158302490+jamnuel@users.noreply.github.com> Date: Fri, 20 Dec 2024 12:54:06 -0600 Subject: [PATCH 08/51] Meeting 201 Meeting 201 Notes --- AllCoreDevs-EL-Meetings/Meeting 201 | 446 ++++++++++++++++++++++++++++ 1 file changed, 446 insertions(+) create mode 100644 AllCoreDevs-EL-Meetings/Meeting 201 diff --git a/AllCoreDevs-EL-Meetings/Meeting 201 b/AllCoreDevs-EL-Meetings/Meeting 201 new file mode 100644 index 00000000..56b3c2e9 --- /dev/null +++ b/AllCoreDevs-EL-Meetings/Meeting 201 @@ -0,0 +1,446 @@ +# Execution Layer Meeting #201 +### Meeting Date/Time: Dec 5, 2024, 14:00-15:30 UTC +### Meeting Duration: 1h35m +### [GitHub Agenda](https://github.com/ethereum/pm/issues/1197) +### [Video of the meeting](https://youtube.com/live/Umh7ZKukmtY) + + + + + +### Moderator: Tim +### Notes: June + +| S No | Agenda | Summary | +| -------- | -------- | -------- | +201.1 | **Pectra updates: Mekong & devnet-5 updates** | Mekong testnet is operational ~97% attestation performance; minor issues to address, mostly good on Mekong front and focused on getting all the PRs merged for devnet-5; devnet doc has been updated by testing team to show where the status of tests are. +https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 +201.2 | **Pectra Scoping** | BLS gas pricing discussion of Marek's PR [here](https://github.com/marchhill/bls-precompile-benchmarks/blob/main/proposed-changes.md); Most client teams in production and on call agreed that the proposal works for them to move forward with for now; need confirmation from Besu async; can modify with more fine-grain anaylsis in the future. +201.3 | **Pectra Scoping** | Discussion on [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) inclusion and update with additional security considerations [EIPs#9086](https://github.com/ethereum/EIPs/pull/9086_); 7623 focuses on capping transaction payload sizes to improve network performance and security; client teams all agree it would be a small thing to implement and wouldn't significantly impact timelines; decision to move forward with 7623 on devnet-5 pending confirmation from testing team. +201.4 | **Pectra Scoping** | Discussion on [EIP-7762](https://eips.ethereum.org/EIPS/eip-7762) inclusion; proposes minimum blob price increase; disagreement on whether to include this in Pectra; deferred one week for feedback from rollups and testing. +201.5 | **[EIP-4444 & EIP-7639 rollout](https://hackmd.io/Dobc38YVQ1qmbbyI6LcFqA)** | Discussion and disagreement about best protocol versioning for this implementation and whether or not some clients should be able to provide historical blocks while others don't; concern about protocol fragmentation; Piper to compile notes and create discussion async. +201.6 | **[EIP-4803] (https://eips.ethereum.org/EIPS/eip-4803)** | This EIP is proposed to be enabled from genesis and it limits gas limits on transactions; no objections conceptually but won't be address until after Pectra testing; Alex to create a PR. +201.7 | **[Potential ACD Improvements](https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157/51)** | Agreement to add [Declined for Inclusion] status for EIPs that will not be included in the hard fork; EIPs still open for discussion and available for future hard forks; agreement to include all non-consensus protocol changes in list of hard fork changes to make sure everything is up to date for each hard fork. +201.8 | End of year coordination and holiday meeting schedule | Testing call on Dec 23, Cancel ACDE on Dec 26, Cancel testing call on Dec 30, Replace ACDC by testing call on Jan 2 + +### 201.1 | Pectra updates: Mekong & devnet-5 updates +**Tim**: Welcome everyone to ACDE #201. Couple things on the agenda today, most importantly we can hopefully finish the scope of Pectra and be able to move forward with the specs. After, some conversations around EIP4444 as well as 7639 about dropping history. Then there was an edge case to revist around capping transaction gas amount and then if we have time left, there are a couple ACD process improvements I wanted to cover. + +Pari, Banabus, either of you want to give an update on testnets? + +**Pari**: We have Mekong continuing to run-- we're at 97% attestatino performance. Grandine team has pushed a lot of fixes, mostly okay now. Some problems still with Ethereumjs and Nimbus EL, but mostly good on Mekong front and focused on getting all the PRs merged for devnet-5. +PRs here: +CL - https://github.com/ethereum/consensus-specs/pull/3800 +CL - https://github.com/ethereum/consensus-specs/pull/4023 +EL - https://github.com/ethereum/execution-apis/pull/574 + +Devnet doc has been updated by testing team to show where the status of tests are. +https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 + + +**Tim**: Any other EL PRs that you want to bring people's attention to? + +**Ansgar**: Regarding [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691), there was this open question of what exact update fraction we would go with and we chose the number that is the middle sensitivity between 3-6. We couldn't have 6 blobs less than the target or 3 blobs more than the target, so we picked the middle; now a very full block will have slightly less than 12% increase and a fully empty block will have slightly more than 12% decrease. + +**Toni**: Was just in the process of reviewing the EIP-7691 PR; only one small typo then we can merge. + +**Paritosh**: lightclient brought up [7702 txpool](https://eips.ethereum.org/EIPS/eip-7702) in chat, maybe he wants to discuss? + +**lightclient**: just checking again to see if anyone has looked into it or implemented it? We are in the process of implementing now. + +**Marek**: Nethermind is looking into it, but others can comment on that. + +**Anders**: Yes, we had a discussion on Discord [interop channel]. We had some suggestions but it seems the discusssion stalled. + +**Tim**: As people work on this, share any updates or designs in the discord chat. + + +------------------------------------- +### 201.2 | Pectra Scoping | BLS gas pricing + +**Tim**: Moving on, it's worth chatting about Pectra scope changes. It feels like we're close to finalizing scope, it would be ideal if we could do so on today's call so we have a final set of specs to work with before the holidays. We can come back in January with a clear target to implement. + +On CL, everything seems pretty resolved. + +On EL, some major open questions: first is BLS gas pricing, second is whether to include EIP-7623, lastly is EIP-7762, an adjustment to the blob base fee. + +Let's start with BLS one since it's already included in Pectra and needs to be fixed. Anyone with context on latest BLS pricing discussion? + +**Marek** I took all the numbers and opened a PR, in the [link here](https://github.com/marchhill/bls-precompile-benchmarks/blob/main/proposed-changes.md) we have Nethermind BLS pricing proposal and it would be great if it could be validated by other teams. I think Pawel had a different idea how to price MSM (multi-scalar-multiplication) operations but I don't fully understand, so we need to agree with Pawel about this. + +**Tim**: Have any other teams reviewed or have any strong opinions? + +**Kevaundray**: From the pricings, atleast from what we know from the current numbers, Nethermind for G1MSM would need to go up by 2.5x, Besu and Geth would need to go up by 2x, and evmone would need to go up by 3x. For G2, Nethermind is 1.5, Geth and evmone are 2x. We could go with these pricings but they're more costly than what we would like. + +**Tim**: By 'these pricings,' you mean Marek's current PR? + +**Kevaundray**: We took the worst case of what everyone has already given us in order to cover all of the clients. It's just a more coarse way to do the pricing. + +**Tim**: Do you have a sense of the impact on users for having this more coarse pricing scheme? + +**Kevaundray**: We don't know exactly because it depends on the use cases. My suggestion would be to commit to coarse pricing and we can use other tools to determine a new curve to use. At the moment, we haven't committed to any pricing. I would like to avoid the 3x that is there but it's the only one we've seen imperfectly that covers everyone else. + +**Tim**: So I understand evmone was slow on some of these; that's the one that would be covered by 3x? + +**Kevaundray**: Right, the next lowest would be the Nethermind proposal of 2.5x scaling. + +**Tim**: Is evmone used in production by any clients? + +**Andrew**: Not yet, but we would like to switch Erigon to evmone. At the moment it still uses GoLangEVM which is essentially the same as used in Geth. + +**Tim**: Nethermind uses the same library. I'm trying to understand why evmone is slower and does it make sense to put our worse case on an evm that is not beign used in production today or should we use whatever is already in production? + +**Kevaundray**: To answer the first question, evmone is different and has issues even when using the same library because everyone is basing it off ez-recover, but that's not the same across every library. + +**Radek**: This is not exactly about evmone, but about the blst library, which is used by Nethermind and Reth. This means that the speed is not only the case with evmone but with the library itself. + +**Kevaundray**: Right, so Nethermind uses the same library but it's a 2.5x. This goes down to the issue of ez-recover not being the same across everyone because everyone is scaling based on ez-recover. + +**Tim**: Anyone from Geth or Besu have time to review? Jared says Geth would be good with Nethermind's proposal. My sense is that if Besu is also good with it we should move forward, even if it is slightly underpriced for evmone. + +**Kevaundray**: What do people think about the proposal to commit to 2.5x or 3x and then wait for a gas optimizer tool to possibly give us finer-grain numbers, but we commit to something for the time being? + +**Tim**: Discussion in chat to agree async but before devnet-5. Marek, how much time do you think we need to agree to this? If we could get consensus on your PR as a basecase that we could modify later on, is there a reason to push this back async before we make the decision? + +**Marek**: There is no clear number, we can discuss async, but we should decide before devnet-5. + +**Tim**: It is fine to do it async, but recommend getting to a resolution on testing call Monday. Get us to as final of a pricing scheme as soon as possible. + +**Stokes**: Kev's recommendation is a good way to make progress today. Sounds like this PR gets us directionally closer to what we all like. + +**Tim**: If all of the production clients are fine with this number, we should go ahead and merge. Worth getting a sanity check from Besu, but assuming they can approve async today or tomorrow, we merge. + +**Stokes**: If anyone has a BLS-signature verifier that works with the latest for Pectra, let me know on Discord. Would be nice to have a sense of end-to-end cost for this. + +------------------------------------- +### 201.3 | Pectra Scoping | [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) inclusion and update discussion with additional security considerations [EIPs#9086](https://github.com/ethereum/EIPs/pull/9086_); + +**Tim**: Next up is EIP-7623, Danno you raised some issues on EthMagicians and then Toni opened a PR to address them. Toni, do you want to give a quick recap on those changes? + +**Toni**: We discussed on the consensus layer call last week as well. The main contention we always had with 7623 was not about the mechanism but the scope of Pectra itself. Regarding Danno's suggestions, I included them and incorporated them into the EIP. You can now find a more elaborated backwards compatibility section and security considerations, including the concerns we clarified that William raised about the gas sheltering. I would now propose that we include it and ship it in devnet-5, especially in light of current discussions in the community about potential gas limit increase and agreeing on the blob increase. I think it will be important to make sure we limit EL payload size. + +**Tim**: This PR seems to address Danno's issues. Does anyone think we should *not* include this? + +**Stokes**: I'd like to hear what EL client teams think in terms of implementation complexity? I think it has a lot of merit on the security front, but is it going to add weeks of delay to Pectra? + +**Tim**: Reth, Besu, and Ethereumjs say in chat the impact should be low. Lightclient says it adds complexity to reasoning about tx cost and may introduce some weird gas sheltering schemes. + +Question from Pari: on the testing side, do we have a sense of how big of a lift this is to include? + +**Mario**: No sense as of yet, but I think it is not going to be straightforward. i don't have a clear idea yet. We have made some preparations for this EIP in our repository, but still we need to check and see how long-- probably couple of weeks to implement this. + +**Tim**: How do you feel about the rest of the fork so far? Is the rest of Pectra in a relatively good spot? + +**Mario**: We have PRs for everything for devnet-5. It's looking good, we are probably going to be able to make a release soon. For 7623, I don't think that should be a blocker, but if anything comes up I can signal it. + +**Daniel**: I just wanted to propose that maybe instead of including in devnet-5, we include it in devnet-6 to not block testing of devnet-5. + +**Tim**: It depends on how fast we think devnet-5 will be finalized? If it's in the next week then sure, but if it's going to be a couple weeks then we can include this. I'd rather devnet-5 be the final devnet. + +Does anyone think devnet-5 is ready for launch in the next week or two? + +**Daniel**: We should discuss other EIP to get a good sense of full scope. + +**Tim**: Regardless of devnet-5 or devnet-6, any strong objections to including 7623 so we can finalize the Pectra scope and spec? + +**Barnabus**: The main blocker is 7742 still on the implementation side. If this is a small implementation on the EL side, then we might not even be ready with 7742 before we would be done with this new EIP. + +I haven't heard from any client teams that are 100% done with it on CL or EL. + +**Tim**: Is anyone done? Reth and Besu say they are close, but not done. If teams are mostly done with 7742 and think this is doable, then we can move forward with it. We can discuss devnet-5 or devnet-6 after once we have a better sense. + +**Stokes:** Can we go ahead and include it now and then take it out in a week or two if it ends up being bigger than we think? + +**Paritosh**: Maybe we give the testing some time to look into it? If they say it will take another 3 weeks to have the tests for 7623 then we don't want to block devnet-5 for this one EIP. + +**Mario**: We can have an estimate on Monday's testing call. + + +------------------------------------- +### 201.4 | **Pectra Scoping** | Discussion on [EIP-7762](https://eips.ethereum.org/EIPS/eip-7762) inclusion + +**Tim**: Next on the agenda is EIP-7762, which is the minimum blob price increase. We discussed this as well on last week's call and couldn't quite come to a decision; anyone have thoughts about what to do there? + +**Toni**: We also discussed on last week's Consensus Layer call. We agreed that we don't want to do *all* the changes that are proposed at once on Pectra. There were discussions about picking out minimum blob base fee and only shipping that. I'm indifferent about that one, but I think we should stick to *not* including all the base fee changes in Pectra. + +**Ansgar**: The decision is indeed to not ship the big package.This EIP is only for minimum base fee increase -- a one line change-- and was modified last week to include excess gas reset. You can have a look at the EIP, it is still very smol and the excess gas reset is just one IF statement. One line change is eseentially a 4 line change now. + +Given that it is so tiny, and has a meaningful improvement to UX for rollups who have been signaling that this would be valuable for them, I am in favor of including this. + +**Max**: Maybe one more thing in terms of complexity of test cases. If there are going to be changes to the update rule, I think the additional test cases from including this EIP-- along with the blob increase which will adjust the rate of change-- will be pretty minimal because you'll already have to change the test cases for that. + +**Ansgar**: This is a really good point and one thing that came up in the update fraction change discussion. I think it makes testing slightly simpler even. + +**Tim**: Have any EL teams reviewed this? Ethereumjs seems in favor. + +**Stokes**: Are we talking about just raising the minimum fee or the other things in this PR? + +**Toni**: Only the minimum fees. + +**Ansgar**: The decision is on the current state of the EIP, no open PRs. + +**Stokes**: Okay, yes, this is much simpler. It does add another EIP and overhead of testing. + +**Tim**: The downside of not doing this is that we stay in this awkward world where sometimes the blobs are effectively free and sometimes they get repriced very slowly relative to the market. + +**Max**: The problem is more that they get repriced very slowly recently and when they reprice very slowly, every 20 hours, where we have a 3h period of price discovery and a 3hr period of going back down to less capacity overnight when there's less demand. In that 3hr period we're basically defaulting to first price fee market. + +**Stokes**: And that's a problem because rollups don't want to think about volatile fee markets? + +**Max**: It makes it so that if the rollups are charging for gas they have to do so based on a first-price fee market, which noone understands, versus says your gas on rollup is a function of blob fee on Ethereum today. Makes it much easier for rollups to read and provide gas pricing for their users when it's the number from the controller rather than number from controller + whatever else is happening in first-price fee market + whatever is happening in MEV land for that particular block. + +**Stokes**: I think the strongest counter argument I've heard is what I've seen from lightclient in the chat, that it's just early and presumably we will in price discovery for the blobs and this issue will go away. + +**Max**: We are at price discovery but the demand fluctuates. + +**lightclient**: I don't think we should orient the Ethereum fee market to be US-focused, which is what Max is saying. + +**Tim**: It's more that whenever noone uses blobs or when people decide to use blobs again, we're too slow to adapt. + +**lightclient**: It's still too early in the life of blobs for us to be meddling with the actual price mechanism. Let's revisit it again in the next fork if we're still having problems. + +**Ben Adams**: Aren't we proposing doubling the blobs? That's just going to make it worse. It's not like we're not meddling. + +**Max**: There are already several changes to the controller as well as the blob increase in this fork. We have very strong theoretical reasons why this would increase price discovery with very minimal changes. In total this is, at most, $100,000 a year change to the blob prices, but we think it will make the speed of price discovery much fast. We now see in the data that this is happening very often. + +**lightclient**: We also thought that price discovery was just going to happen once before we implemented blobs, which was wrong. How can we know that this proposal would fix all these problems? + +**Max**: That is not what the proposal claims to do. It claims to be an adjustment, which is low overhead, that we know will improve by some factor. It won't make the blob market perfect, but it will improve it. + +**Ansgar**: I would really strongly recommend adding this EIP. It is a strong change and the situation will get significantly worse from today with this change in throughput. We now maximally can increase the block base fee by 8% per block instead of todays 12%. It takes significantly more time to ramp up...Rollups would prefer us adding this. Testing complexity is basically zero because you already need to run the tests. + +**Paritosh**: Note that each EIP we add will delay Pectra. So the choice is more scaling faster or more EIPs + scaling slower. There is no world in which we can have more EIPs and things faster. + +**Tim**: Even if the changes are small, and we have 12-15 of them in the fork right now, it will delay shipping Pectra. + +**Paritosh**: The question is whether the tradeoff is worth it. + +**Max**: What Ansgar is saying is that the changes are 4 lines. Many of tests are overlapping with what is already taking place because of other rollup EIP. + +**Tim**: What are the risks of not making decision today? + +**Max**: The code itself is a 4-line change, but the tests will need to be rewritten and adjusted. + +**Stokes**: Given that rollups are the user, it would be nice to hear from them directly. + +**Tim**: Ansgar says there is rollcall next week (but we already have signal that they really want this). We can bring this up in the call next week to get feedback and give ourselves time to have a better sense on testing. + +If we finalize today, my sense is that we don't do this. + +**Barnabus**: If we delay one more week, we will not finalize this year. + +**Daniel**: Does this mean the proposal is not included and we would maybe have a devnet-6 for this one EIP? + +**Paritosh**: Devnet numbers are made up, we can add more if we need to. + +**Ansgar**: That seems like the worst option in this case. If we delay to next week, it might not make it to devnet-5 and then we might not want to open a new devnet for it. We are rolling the dice on whether or not to include it. + +**Tim**: We are strained with capacity. We need to evaluate what the impact is before making the decision. + +**Ansgar**: But by delaying it, we change the cost. By next week it might be much larger because it would require a new devnet. + +**Tim**: But I don't think we know today whether this would require a new devnet. + +**Ansgar**: It's fine if the decision is not to include, but we should make the decision today, not delay it to next week. + +[ *disagreement in the chat about whether or not there's consensus around this decision; deferred to next week* ] + + +------------------------------------- +### 201.5 | [EIP-4444 & EIP-7639 rollout](https://hackmd.io/Dobc38YVQ1qmbbyI6LcFqA) | + +**Tim**: Next up, history expiry. Piper you shared a document, do you want to give some context on this? + +**Piper**: We made a decision at the R&D workshop and we have all the execution client teams on board for rolling out what we'll continue to call four 4s with a timeline of dropping a significant part of the history by May 1, 2025. + +Document linked above gives summary of everything going on here. Official EIP number is [7639](https://eips.ethereum.org/EIPS/eip-7639). It specifies a new version of the Eth protocol (Protocol Version 71) for which clients will be allowed to stop responding to certain messages about history. The exact thing we agreed on was dropping block bodies and receipts only for pre-merge data, so that does not include the header chain or any data after merge. Loose estimates suggests this accounts for a couple hundred gigabytes of disc space, this gains us some amount of leeway here on that 4 terabyte hardrive limit. + +The agreement in terms of what consensus was reached was strictly about clients no longer being required to respond to this data over devp2p after that drop date. The exact implementations that clients will be taking with respect to how they handle this data is up for grabs. Every client is able to make their own decisions. We still have clients implementing full syncs, executing all blocks from genesis, they'll be implementing their own plans for how they fetch, retrieve, deal with all that long history data. We have other clients who are going to be implementing Portal Network clients for the Portal Network history network in their clients for surfing things like json rpc. + +That's the high-level overview for this. We met with all the client teams during Devcon, I think everyone knows what they're doing. The time to start working on this is now so that we're ready. Lightclient has pointed out that for this new protocol version we need to warm it up, not have it just turn on May 1st, but client teams should have versions of their clients out before then that allow for both old and new versions to exist at the same time. + +**Andrew**: One comment is that we need to finalize Eth/69 and our side we have some concerns about its compatibility with Polygon. We need some time to prepare and maybe can discuss on next all core devs call. + +My other question is do we actually need a new protocol (Eth/71) to explicitly prohibit answering a historical block request. + +**Piper**: I was going to ask that same question. I don't have a strong opinion about this. Hopefully we could answer that today or async if other client teams want to weigh in. + +**Ahmad**: Given that 3-4 other clients are going to implement 7801, 7801 is going to be Etha subprotocol and everyone can then see premerge history on eth protocol. The reason we want it to be a subprotocol so that eth protocol will not be affected by clients potentially calling clients that do not support 7801. Don't want to give the assumption that all clients are going to support serving historical blocks through 7801. + +**Piper**: Correct, so that sounds like that's a little in favor of not implementing a new Eth subprotocol version. It seems like that could happen independent of whether we have a new eth subprotocol. + +**Ahmad**: No, because when you implement a new eth subprotocol you declare that you support the new subprotocol. If you don't declare it, then no one will ask you for it. + +**Piper**: I'm referring specifically to the new ETh protocol version (Eth/71), not whatever new protocol version 7801 goes on. + +**Adhmad**: Since some clients are going to drop blocks and most nodes are going to drop pre-merge blocks, it wouldn't be fair to anyone to keep saying 'hey I might have the blocks or might not', so we say anyone who is in Eth/70 or 71 will stop serving pre-merge blocks. And if you want to serve pre-merge blocks, you implement the subprotocol. + +**Piper**: Got it, so in your version, anybody who is on Eth/70 may or may not serve the block history and anyone on Eth/71 definitely doesn't serve the block history? + +**Lightclient**: This is just for Eth/71--you *must* not serve pre-merge data on Eth/71 but we can make it clear that you could for earlier versions. + +**Piper**: The endgame here is that we get a sharded Eth pro tocol between the clients that do and don't serve historical blocks; seems like a problems state for things to be in, where there's an option to stay on the old protocol and continuing to serve old blocks. + +**Andrew**: Yeah, I don't like this bifurcation in protocols. Maybe we can make Eth/70 generic enough to allow for clients who don't want to store any historical blocks to explicitly say so. + +**Ahmad**: If you don't put any 1s in your bitmask that means you don't have any history that you don't want to serve; it's easy to implement. If we want to encode the bitmask inside the ENR then that's different. I think I am fine with the handshake. + +I think Geth team is still in favor of having it as a separate protocol regardless of whether we do it in this way, just because they want to keep the network uniform. + +We could change the language to say instead of 'cease serving history' we leave it to the client teams and not have a separate subprotocol (etha) for serving history. + +Lightclient: What is the argument against etha? Isn't it just a string within the handshake. I personally don't care etha versus another version, it's just a string. + +Andrew: From my point of view, etha is fine, what I don't like is Eth/70 for this sharded block proposal and then Eth/71 for actually stimulating must not serve historical blocks because then we have a bifurcation in protocol. + +**Ahmad**: Okay sorry maybe there's a confusion, which is why I asked lightclient to change his version to Eth/70. We are going to not use the 70 version since it's a new subprotocol, it does not conform to the same versioning scheme. + +**Piper**: To round this back up: 7801 goes on a different subprotocol, not part of the Eth protocol. Anyone who is doing 7801 things, it is on a new separate protocol and separate string. The question here is whether there is opposition to doing 4444 without bumping the Eth protocol version and keeping it at 70 with the dropoff date. + +**Lightclient**: We need to bump the version. We don't want to stop serving history on a specific version because then when you connect you won't know if they have the history or not. If you haven't updated your clients and are trying to bootstrap, you're going to try to download but if everyone else updated you won't be able to connect to the network. + +**Piper**: Isn't that the same case though? Isn't the same case true whether we bump the protocol version or not? If you don't update and you connect to the network but everyone else is on the new protocol version and dropped the history, they're no longer serving the data. + +I think we need to do a bit of async discussion on the exact roll out plan for this. It doesn't seem like we have clear consensus here today. I will try to get a write up posted of the two different approaches and see if people want to weigh in on. + +**Tim**: What is the rationale for not having an explicit separation? What do you gain by not having an explicit tell that there's a different version people are running? + +**Piper**: 1. There isn't much of a difference in the actual protocol definition. The actual messages are all the same but the behavior of the request is different. 2. Added complexity and cross-network compatibility. + +**Andrew**: 1. Protocol Eth/69 which we discussed but isn't finalized yet. It has some proposed merge clean ups and we realized it might not play nicely with polygon, so we need to think about it more and discuss again. Basically, Eth/69 is not relevant to 4444s; sequentially it's something that we should finalize if we're talking about Eth/70. + +I also think that we need one single protocol that works for all nodes whether they're storing historical blocks or not. When you need to download historical blocks, it should be explicit with your peers, which blocks your peers have. + +If we do something like 7801 concurrently with a new version of the protocol that actually prohibits historical blocks that creates a bifurcation in the network. My strong preference is to have a single protocol that works for clients that decide to store historical blocks and those who don't. + +**Tim**: Piper, if you want to write something up and post it on the Discord, we can continue this conversation async. + +**lightclient**: If we decide to have this additional provider protocol, it is important that we roll this out with Prague. How do we add that to the Prague hard fork meta? + +**Tim**: In general, we should start adding non-consensus changes to meta hard forks. We have done some things like this in the past, but it does feel important to signal. We can discuss at the end of this call. + + +------------------------------------- +### 201.6 | [EIP-4803] (https://eips.ethereum.org/EIPS/eip-4803) | + +**Tim**: Next up, Axic shared this on the agenda: EIP-4803. A while back we discussed adding bounds to constants in the protocol. We did add a couple, but this one was never confirmed. + +**Alex**: The one we merged back a couple of years ago was 2681 (limiting the account nonce) and there was another larger EIP (1985), which was proposing bounds to pretty much everything. At the time, we agreed to the account nonce limit and to split this 1985 into smaller individual changes; this EIP is one of them. + +This EIP is proposed to be enabled from genesis and it limits gas limits on transactions. No transactions can have a gas limit higher than 2^63-1. The reason is that it allows simplifications in the EVMs, which using 2^63 it can be handled as a signed number and checking whether the out of gas condition is reached is a matter of checking if the gas became negative. + +This can be enabled from genesis because most of the clients, including Go Ethereum, already do this internally. Additionally, it is expensive to create transactions with a limit higher than this because you need the funds available up front. + +Are there any strong reasons against this or should we consider spending more time discussing? + +**Tim**: Why use a different constant for this than 2681? + +**Alex**: The reason we should go with 63 is because then it can be a signed number and the out of gas check is simpler. + +**Tim**: There's a comment from Barnabus around testing and inclusion in the fork. Even if we retroactively add this from genesis, we need some tests for this first. It feels like a bad time to add those tests given everything with Pectra. That aside, assuming we got to this once Pectra is done, is there feedback on design or conceptually? + +**lightclient**: It would be helpful to see if there were examples for using this negative gas value. I kind of understand that it's possible to use this to indicate when out of gas, but if you could link to an example where a client is doing this and what the implication would be. + +**Alex**: evmone was doing this; but the way you could do it, you just subtract the gas and check whether it is a negative value. Internally, CPUs would usually have specific instructions for the negativeness check, so technically it can be cheaper. + +The limit, 63 or 64 is a discussion to be had. Setting that aside, can we atleast agree conceptually that putting this limit is something people agree with or have reasons not to? + +**Tim**: It seems like there are no objections. For next steps, Alex if you are able to open a PR, we have a meta EIP to track these retroactively applied EIPs, so open a PR to that EIP and list this one. +We don't have to merge the PR now, but can revisit post-Pectra testing. + +**Alex**: Sounds good. Re: 7825 (comment from Ben) +7825 proposes to introduce a lower limit, a limit of 30 million. My comment was that the PR I'm proposing can be enabled retroactively whereas 7825 may not be able to be enabled retroactively. The two are related and essentially you could have both at the same time. One is an implementation whereas the other is a limit that we may or may not change over time. + + +------------------------------------- +### 201.7 | [Potential ACD Improvements](https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157/51) | [Declined for Inclusion](https://github.com/ethereum/EIPs/pull/9056) update, Non-consensus changes in Meta EIPs, PFI → CFI → SFI & devnet inclusion + +**Tim**: As we discussed in Bangkok, three ideas came out of the ACD Process Improvements Sessions: + +1. adding 'declined for inclusion' status to meta EIPs for hard forks - +The idea is that we decide to accept things into hard forks but we don't have formal rejections for current fork. It doesn't mean we will never do the EIP, obviously someone can work on any EIP and are free to propose everytime there is a new fork, but we do spend a lot of time discussing EIP inclusion for each fork so having this status would be valuable. + +2. adding non-consensus changes to meta EIPs - +We have meta EIPs for hard forks and it's clear why we need them because there are a set of changes that need to happen at a specific block. One challenge with that is that it means our process often biases toward things that have to activate at a specific block, e.g. spent years talking about 4444s but it doesn't get prioritized because it's not on the same list as everything else. The proposal is that we start including non-consensus changes at hard forks and for something that is not a non-consensus change (like 4444s), the implication is that clients will have this client feature shipped *at the latest* at the hard fork. + +**Stokes**: That makes sense. One thing to note is that we still have the ability to ship non-consensus changes without a hard fork, but this is addressing the false positives. + +**Tim**: Correct. We can ship things before and in practice this would look like compiling a list of previously activated changes to the specs for a hard fork. At this block, all these are active on the core protocol. + +**Pooja**: Just wanted to make sure this is for proposals going to be shipped *before* the hard forks, and not those proposals which are going to be retroactively added. + +**Tim**: Yes, I would keep those separate. The retroactively added EIPs, everyblock from block zero should implement those protocol rules. And we can only add those when it's true that in the entire history those conditions were not broken. Whereas something like dropping history, this was not true of the entire chain history. So it feels more accurate to say, 'as of this hard fork this change is live' even though it's not a consensus change. + +My point is that we would add *all* protocol changes, whether or not their core EIPs, since the hard fork. We can both retroactively do this and we can decide to prioritize proactively. + + +------------------------------------- +### 201.8 | End of year coordination and holiday meeting schedule | +Testing call on Dec 23 +Cancel ACDE on Dec 26 +Cancel testing call on Dec 30 +Replace ACDC by testing call on Jan 2 + +------------------------------------- +### Attendees +* Tim +* Lightclient +* Ognyan Genev +* Ruben +* Tomasz Stanczak +* Daniel Lehrner +* Ben Adams +* Pooja Ranjan +* Anders K +* Guru +* Julian Rachman +* Ben Edgington +* Ameziane Hamlat +* Jihoon +* Danno Ferrin +* Paritosh +* Enrico Del Fante +* Ansgar Dietrichs +* Barnabus +* Kevaundray +* Stokes +* Kolby Moroz Liebl +* Toni Wahrstätter +* Hadrien Croubois +* Dave +* Arik Galansky +* Dragan Rakita +* Spencer +* Frencesco +* Frangio +* Matthew Whitehead +* Piotr +* Terence +* Scorbajio +* Mario Vega +* Mingming Chan +* Gajinder Singh +* Andrei +* Yiannis +* Łukasz Rozmej +* Trent +* Ignacio +* Richard Meissner +* Danceratopz +* Milos +* Guillaume +* Oliver (Reth) +* Karim +* Saulius +* Radek +* Andrew Ashikhmin +* Jared Wasinger +* Max Resnik +* Hsiao-Wei Wang +* Somnath +* Mikhail Kalinin +* Yoav +* Luis Pinto +* Elias Tazartes + + From 27bc9438c6885d161becd45d53570d97b7dad64c Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 20 Dec 2024 16:54:31 -0500 Subject: [PATCH 09/51] Create Meeting 14.md Add ePBS Notes 14 --- Breakout-Room-Meetings/(e)PBS/Meeting 14.md | 35 +++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Breakout-Room-Meetings/(e)PBS/Meeting 14.md diff --git a/Breakout-Room-Meetings/(e)PBS/Meeting 14.md b/Breakout-Room-Meetings/(e)PBS/Meeting 14.md new file mode 100644 index 00000000..798d1258 --- /dev/null +++ b/Breakout-Room-Meetings/(e)PBS/Meeting 14.md @@ -0,0 +1,35 @@ + +# (e)PBS Breakout Room #14 + +Note: This file is copied from [here](https://hackmd.io/@ttsao/epbs-breakout-14) + +## Meeting Info + +**Agenda**: https://github.com/ethereum/pm/issues/1222 + +**Date & Time**: [Dec 20, 2024, 14:00-15:00 UTC](https://www.timeanddate.com/worldclock/converter.html?iso=20240213T140000&p1=1440&p2=37&p3=136&p4=237&p5=923&p6=204&p7=671&p8=16&p9=41&p10=107&p11=28) + +**Recording**: https://youtu.be/a5k7dg_d42I + +# Notes + +- **Attendance**: Smaller group due to holidays. Representatives from: + - Prysm: Potuz & Terence + - Teku: Stefan + - Nimbus: Kira contributing to Nimbus for ePBS + +- **Fork Choice Simplification**: + - Potuz will open a spec PR for the latest fork choice simplification based on Francesco's "all-in-one" design. + +- **Bug Issue**: + - Current bug: Proposers building on an empty block cannot deterministically retrieve withdrawals from the beacon state. + - Will be problematic if interop begins before a pending spec fix. + +- **Devnet Updates**: + - Teku: Rebasing ePBS on top of Devnet5 spec. + - Prysm: Finishing Devnet5 spec first, then rebasing ePBS. + +- **Interop Target**: 3rd or 4th week of January, approximately two meetings away. + +- **Genesis Transition**: + - No major concerns with starting genesis from Electra and transitioning to ePBS. From 55faa86519f484c0385dd49d2d5b319cf334aa5d Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 20 Dec 2024 16:58:19 -0500 Subject: [PATCH 10/51] Update (e)PBS-pm.md Update README --- Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md | 27 +++++++++++----------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md b/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md index ee8e2a04..a7d9bb3d 100644 --- a/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md +++ b/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md @@ -16,19 +16,20 @@ In EIP-7732 or (e)PBS Breakout Room, client developers discuss specs & implement | # | Date | Agenda | Recording | Notes | | -- | --| -- | -- | -- | -|13| November 22, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1198) | [Recording](https://youtu.be/v80-9dChohM) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2013.md)| -|12| October 25, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1188) | [Recording](https://youtu.be/fs6rNxHQ3f0) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2012.md)| -|11| October 11, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1173) | [Recording](https://youtu.be/Oo8c37ZfV3A) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2011.md)| -|10| September 27, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1157) | [Recording](https://youtu.be/s5Bx_CWf5yg) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2010.md)| -|8| September 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1150) | [Recording](https://youtu.be/2BUsiUnUZYc) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2009.md)| -|8| August 30, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1135) | [Recording](https://youtu.be/BZhYP-JRS7U) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2008.md)| -|7| August 16, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1133) | [Recording](https://youtu.be/fQx_UbaPX-E) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2007.md)| -|6| August 02, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1120) | [Recording](https://www.youtube.com/watch?v=Otxw1uXxFCI) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2006.md)| -|5| July 19, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1095) | [Recording](https://youtu.be/pFJMqk5zkPQ) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2005.md)| -|4| July 05, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1083) | [Recording](https://youtu.be/WC9XsungamU) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2004.md)| -|3| June 21, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording](https://youtu.be/J1e5iUvcTDU) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2003.md) | -|2| June 07, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording](https://youtu.be/w7Wa6oprEhQ) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2002.md) | -|1| Feb 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/953) | [Recording](https://youtu.be/63juNVzd1P4) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2001.md) | +|14| December 20, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1222) | [Recording](https://youtu.be/a5k7dg_d42I) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2014.md)| +|13| November 22, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1198) | [Recording](https://youtu.be/v80-9dChohM) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2013.md)| +|12| October 25, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1188) | [Recording](https://youtu.be/fs6rNxHQ3f0) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2012.md)| +|11| October 11, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1173) | [Recording](https://youtu.be/Oo8c37ZfV3A) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2011.md)| +|10| September 27, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1157) | [Recording](https://youtu.be/s5Bx_CWf5yg) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2010.md)| +|8| September 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1150) | [Recording](https://youtu.be/2BUsiUnUZYc) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2009.md)| +|8| August 30, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1135) | [Recording](https://youtu.be/BZhYP-JRS7U) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2008.md)| +|7| August 16, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1133) | [Recording](https://youtu.be/fQx_UbaPX-E) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2007.md)| +|6| August 02, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1120) | [Recording](https://www.youtube.com/watch?v=Otxw1uXxFCI) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2006.md)| +|5| July 19, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1095) | [Recording](https://youtu.be/pFJMqk5zkPQ) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2005.md)| +|4| July 05, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1083) | [Recording](https://youtu.be/WC9XsungamU) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2004.md)| +|3| June 21, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording](https://youtu.be/J1e5iUvcTDU) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2003.md) | +|2| June 07, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording](https://youtu.be/w7Wa6oprEhQ) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2002.md) | +|1| Feb 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/953) | [Recording](https://youtu.be/63juNVzd1P4) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2001.md) | From de816a044fcc56af102c94e0164d76933f2719da Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 20 Dec 2024 17:08:08 -0500 Subject: [PATCH 11/51] Create Meeting 01.md Create EVMMAX Folder & add Meeting 01 --- Breakout-Room-Meetings/EVMMAX/Meeting 01.md | 40 +++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Breakout-Room-Meetings/EVMMAX/Meeting 01.md diff --git a/Breakout-Room-Meetings/EVMMAX/Meeting 01.md b/Breakout-Room-Meetings/EVMMAX/Meeting 01.md new file mode 100644 index 00000000..7911bf52 --- /dev/null +++ b/Breakout-Room-Meetings/EVMMAX/Meeting 01.md @@ -0,0 +1,40 @@ +# EVMMAX Meeting 01 + +### Meeting Info +- Agenda: ethereum#1204 +- Date & Time: Dec 05 , 12:00 UTC +- Recording: https://youtu.be/2ExBjJ0eySo + +## Notes +### Summary (by @pdobacz) +- clients/implementations represented: Geth, EthJS, Besu, evmone, Cairo ZK-VM +- progress updates: + - geth (EIP-6690 prototype+bls prototype using evmmax-bls12-381 tool) + - evmone (low-level lib) +- Poseidon use case + - no objections to select this as 1st priority use case to cover + - point raised if the bottleneck for the use case isn't calldata cost rather than mod arith cost + - what constants of Poseidon are we interested in? + - depends on the field one's using. + - use case of Poseidon Hash itself + - merkle path verification, need 32 poseidon hashes for every update + - the constants matrix is the same for all of them for a single application + - constants change when you change the field +- choice of assembler - Huff-based like evmmax-bls12-381 vs Yul based +- how to format Montgomery constants - opaque or explicitly in Montgomery form? + - needs measuring +- modular inversion - should this be an opcode? + - complexity of such opcode would be large relative to current spec + - needs measuring + +### Summary (by Kev) +- Besu & EthJS: add modular arithmetic lib +- Chance: Spec out poseidon and add a poseidon impl +- Jared: Help chance integrate into geth codebase +- Investigate whether we need to precompute poseidon constants in montgomery form +- (low priority) Investigate whether opcode inversion is so costly such that it needs to be an opcode and also used in a way that makes batch inversion not viable + +### Links shared in the meeting: +- https://eips.ethereum.org/EIPS/eip-6690 +- https://ethereum-magicians.org/t/rip-7696-generic-double-scalar-multiplication-dsm-for-all-curves/19798 +- https://github.com/chancehudson/moduli-comparison?tab=readme-ov-file#moduli-comparison From d5f798a6bfb996a3f23722a8067bf27d6192a039 Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 20 Dec 2024 17:15:03 -0500 Subject: [PATCH 12/51] Create EVMMAX-pm.md Update Readme for EVMMAX --- Breakout-Room-Meetings/EVMMAX/EVMMAX-pm.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Breakout-Room-Meetings/EVMMAX/EVMMAX-pm.md diff --git a/Breakout-Room-Meetings/EVMMAX/EVMMAX-pm.md b/Breakout-Room-Meetings/EVMMAX/EVMMAX-pm.md new file mode 100644 index 00000000..bed33fd1 --- /dev/null +++ b/Breakout-Room-Meetings/EVMMAX/EVMMAX-pm.md @@ -0,0 +1,14 @@ +# EVM Modular Arithmetic Extensions (EVMMAX) + + +### Resources +- [EVMMAX Breakout - Devcon SEA L1 R&D Workshop](https://notes.ethereum.org/@ipsilon/evmmax-breakout-2024) +- [PSE EVMMAX meeting notes](https://notes.ethereum.org/@ipsilon/rk0GN34fye) + +## Breakout room meetings + +| # | Date | Agenda | Recording | Notes | +| -- | --| -- | -- | -- | +|2| January 02, 2025 | [Agenda](https://github.com/ethereum/pm/issues/1208) | [Recording] | [Notes]| +|1| December 05, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1204) | [Recording](https://youtu.be/2ExBjJ0eySo) | [Notes](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/EVMMAX/Meeting%2001.md)| + From f57b1c88ed12a9be5d981db47461ce34436e3b4f Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 22 Dec 2024 14:11:38 -0500 Subject: [PATCH 13/51] Update Meeting 05.md fixed formatting --- Breakout-Room-Meetings/PeerDAS/Meeting 05.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 05.md b/Breakout-Room-Meetings/PeerDAS/Meeting 05.md index b4afae8b..b56f8eb9 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 05.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 05.md @@ -10,7 +10,9 @@ Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrC ## Meeting info Date: 2024.08.06 + Agenda: https://github.com/ethereum/pm/issues/1114 + YouTube Video: ​​https://www.youtube.com/watch?v=scOJSLiMFy4 ## Notes From 33574736197b11ef36df6a53ca02645f92cf04a5 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 22 Dec 2024 14:14:46 -0500 Subject: [PATCH 14/51] Update Meeting 08.md --- Breakout-Room-Meetings/PeerDAS/Meeting 08.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 08.md b/Breakout-Room-Meetings/PeerDAS/Meeting 08.md index 1beaa3e3..f28ae45f 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 08.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 08.md @@ -10,7 +10,9 @@ Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrC ## Meeting info Date: 2024.09.17 + Agenda: https://github.com/ethereum/pm/issues/1145 + YouTube video: https://youtu.be/UYUJCbDf6po ### Client updates @@ -108,4 +110,4 @@ Jimmy: What’s the must-have features before we can ship PeerDAS https://github.com/KatyaRyazantseva/beacon-metrics/blob/master/metrics.md#peerdas-metrics -https://grafana.observability.ethpandaops.io/public-dashboards/f5ea5e0b0d3a4cbcbb2c6a93a014112c?orgId=1 \ No newline at end of file +https://grafana.observability.ethpandaops.io/public-dashboards/f5ea5e0b0d3a4cbcbb2c6a93a014112c?orgId=1 From d9b65fd3ef8522697eb0ae12614581894f1a3138 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 22 Dec 2024 16:50:11 -0500 Subject: [PATCH 15/51] Create Meeting 55.md --- Breakout-Room-Meetings/EOF/Meeting 55.md | 62 ++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Breakout-Room-Meetings/EOF/Meeting 55.md diff --git a/Breakout-Room-Meetings/EOF/Meeting 55.md b/Breakout-Room-Meetings/EOF/Meeting 55.md new file mode 100644 index 00000000..1f63ff35 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 55.md @@ -0,0 +1,62 @@ +# EOF implementers call 55 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1115#issuecomment-2273805574) + +## Meeting info + +Date: 2024.7.24 + +Agenda: https://github.com/ethereum/pm/issues/1115 + +YouTube video: https://youtu.be/OaNJOoaeNNY + +## Notes + +### Client updates + +Discussed EOF container validation + +some discussion about testing + +### Compiler + +need to finalize solidity PR (depends on an evmone release w/ EOF) + +### Spec + +Contract Detection +- Contracts can either disable safetransferfrom, or call out to another contract with legacy features to get the "isContract" question answered. +- "do nothing" is the most undoable, as we can add ISCONTRACT later. But we cannot do the return code changes. +- do nothing / fix later has momentum + +Tracing changes +- There was discussion of process +- PC is zero to section +- Maybe shorter names for section +- Danno will write up a new EIP as a red herring, rather than modify 3155 +- goEVM lab wants nomemory and nostack options (maybe just top of stack). Make this the default? + +### Testing + +Instead of Kurtosis we can use EEST consume +- Kurtosis's main gain is it's a full client setup +- EOF calls to the system contract would be valuable in Kurtosis. Withdrawals/deposts/other pectra calls +- Not valuable at the moment + +Run every test via consume + +EEST could produce Assertoors + +Testing blindspots +- Need to update the checklist +- Quantify the testing progress for next ACDE +- Make sure all EIPs tests are in the testing checklist + +Devnet +- We want fuzzing ready +- Do we need to be 100% for devnet? + - Client should pass fuzzing + - Clients should pass reference tests at 100% (EESTs and Ethereum/tests and evmone) + - 7702 will be dominating devnet testing +- Reth and Besu can join a devnet today (configuration wise) + - Need updates from Geth, Nethermind, EthJS, Erigon From 1cd796be7fd5ba8ea79e97cfe9fa6c03abe0aca4 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 22 Dec 2024 16:51:55 -0500 Subject: [PATCH 16/51] EOF implementer meetings Meetings 55-63 --- Breakout-Room-Meetings/EOF/Meeting 56.md | 63 ++++++++++++++ Breakout-Room-Meetings/EOF/Meeting 57.md | 58 +++++++++++++ Breakout-Room-Meetings/EOF/Meeting 58.md | 99 ++++++++++++++++++++++ Breakout-Room-Meetings/EOF/Meeting 59.md | 40 +++++++++ Breakout-Room-Meetings/EOF/Meeting 60.md | 100 +++++++++++++++++++++++ Breakout-Room-Meetings/EOF/Meeting 61.md | 86 +++++++++++++++++++ Breakout-Room-Meetings/EOF/Meeting 62.md | 69 ++++++++++++++++ Breakout-Room-Meetings/EOF/Meeting 63.md | 48 +++++++++++ 8 files changed, 563 insertions(+) create mode 100644 Breakout-Room-Meetings/EOF/Meeting 56.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 57.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 58.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 59.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 60.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 61.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 62.md create mode 100644 Breakout-Room-Meetings/EOF/Meeting 63.md diff --git a/Breakout-Room-Meetings/EOF/Meeting 56.md b/Breakout-Room-Meetings/EOF/Meeting 56.md new file mode 100644 index 00000000..34159a51 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 56.md @@ -0,0 +1,63 @@ +--- +title: Meeting 03 + +--- + +# EOF Implimenters call 56 +Note: This file is copied from [here](https://github.com/ethereum/pm/issues/1128#issuecomment-2302428979) +## Meeting info + +**Date**: 2024.08.21 + +**Agenda**: https://github.com/ethereum/pm/issues/1128 + +**YouTube Video**: https://www.youtube.com/watch?v=03Dkfpvw4Pc + +## Notes + +### Client and fuzzing updates + +evmone found a bug that fuzzers couldn't find + +besu had subcontainer container bugs found via evmon's tests a few weeks ago + +Nethermind is re-writing their subcontainer validation to not be recursive + +Reth and Geth were not present. + +### Spec updates + +community strongly wants a EXTCODESIZE/ISCONTRACT solution, Libs may not be happy with legacy "escape hatch" contracts rather than using EIP-165 introspections +- If AA is the reason not to proceed, a clear plan needs to be stated as to how the AA transition is expected to play out. + +Delegate call into legacy call rule +- This may break proxies. (EOF proxies, proxying to a legacy contract) +- A detection of EOF vs legacy contract would be useful. EXTCODEHASH would identify EOF +- No opinion about 7702 proxy detection detection, can go with legacy treatment. + + +### Testing Readiness + +With devnet-4 we need to activate on prague alone +- EEST will migrate to just "Prague" for tests, +- EEST will sunset "CancunEIP7692" and "Prague7692" forks +- Will change once 7702 tests are fully merged into tests +- Suddenly 7702 tests will work with EOF + +New fixtures release 1.0.8 - Contains Both pragueEIP-7692 and Cancun7692 + +EOF Container Fuzzing +- EVMONE and Besu + +EOF Execution fuzzing +- possibly goevmlab, guido vranken's fuzzer. + + +### Testing matrix + +Devs, please update + +Any automation interest? +- Maybe hive/consume? +- Still needs final consume setup in CI +- Consume does not run EOF Validation tests (because engine API is the test interface) \ No newline at end of file diff --git a/Breakout-Room-Meetings/EOF/Meeting 57.md b/Breakout-Room-Meetings/EOF/Meeting 57.md new file mode 100644 index 00000000..7596b961 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 57.md @@ -0,0 +1,58 @@ +--- +title: Untitled + +--- + +# EOF implementers call 57 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1138#issuecomment-2329428927) + +## Meeting info + +Date: 2024.09.04 + +Agenda: https://github.com/ethereum/pm/issues/1138 + +YouTube video: https://youtu.be/7wFucExQb7U + +## Notes + +clients and compilers - no non-test updates + +switch to prague + +mario discussed 7702/EOF testing features in EEST https://github.com/ethereum/execution-spec-tests/blob/eip-7702-devnet-3/tests/prague/eip7702_set_code_tx/test_set_code_txs.py + +Fuzzing - no new updates + +Discussed converting EOF format tests into format tests. + +- Init containers need extra work, either double wrapping or need to declare deployed container format. Issues include appending data +- For automated testing we will move to assuming the container is deployed, and in cases where that isn't going to work we need to notate the tests with expected outputs + +New release of legacy tests - invalid tests have been removed, or fixed, or moved to EEST. No new coverage -- all new coverage comes in EEST. + +### ISCONTRACT + +Legacy solidity will not easily be able to determine if it's EOF or Legacy, so the code may fail compiling to EOF. Old contracts will need new versions or alternates for EOF. + +Most libraries depending on assembly would need to change for EOF anyway (any use of JUMP, CALL*, EXCODE* for example) + +May be best solved in solidity? conditional compilation or new is_contract primitive? existing solidity PR Detect EVM version? existing solidity pr + +Example: OpenZeppelin, Solady, Tycho do deep code interactions and have taken up to a year to implement. + +Need to do outreach to the AA team, as they expressed concern on ACD that this may be problematic. (Piotr to reach out) + + +What is Erigon's status? +- Unknown status. + + +More on nethermind's status + +- 7702 is in a different branch from EOF. 7702 will land in Nethermind master first. +- Will target prague in EOF branch +- Running published EEST fixtures. + +New fixtures will be published this week. Need to fix an EEST bug relating to EXT*CALL opcodes. \ No newline at end of file diff --git a/Breakout-Room-Meetings/EOF/Meeting 58.md b/Breakout-Room-Meetings/EOF/Meeting 58.md new file mode 100644 index 00000000..f1e01aff --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 58.md @@ -0,0 +1,99 @@ +# EOF implementers call 58 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1146#issuecomment-2358853729) + +## Meeting info + +Date: 2024.9.18 + +Agenda: https://github.com/ethereum/pm/issues/1146 + +YouTube video: https://youtu.be/MSuxLswMkXA + +## Notes + + +### Client Discussion + +Discussed Split + +- pt 2 should follow w/in 3-6 months +- mild preference for one merge, but not enough to block +- concern about scope creep and moving actual shipment to 1 year + +### Compiler Updates +None + + +### Specs + +Tracing +- evmone will look into implementing, but may have changes to proposle + +HASCODE/ISCONTRACT +Discussed AA concern in discord + +AA is concerned about the pattern where non-eoa accounts are barred, HASCODE could be used to perpetuate that and +slow AA adoption + +Also, 721 could be solved better with ERC-165 interface + +counter: AA is slowed by lack of smart contract signatures + +counter: Banning EOAs possible w/o HASCODE + +No conclusion yet + +Could pectra split allow it to be added in V1? + +Some preference to be in a follow-on fork, but preference may have been driven by time to gather data + +Split is because of EIP bloat, adding a new EIP would counter the solution + +At least 1 client wants to include it for V1 + +Absence could slow adoption of EOF (Any ERC-721/ERC-1155 or flashloan project for example) + +There is concern that 721 and 1155 are badly designed, and so this pattern won't re-occur. An update of 721 could +provide the same protections and conform to modern practices. + +AA accounts could implement 165, but then they would have to have the 721 callbacks active. + +See note below about EXTDELEGATE and proxies + +EXTCALL return codes + +intent + +- 1 - gas was not burned as part of the violation + - User reverts + - Some failures related to call process +- 2 - all gas consumed as part of the failure + - Out of gas + - RETURNDATA copy oob in legacy + - static call violation + - data stack overflow + +No action today + +Allow EXTDELEGATECALL to legacy + +- This is another use case for HASCODE, to ensure EOF proxies won't delegate to a legacy contract + - This could be solved with a "handshake" method or a trial delegate call + +### Testing + +PRs will be reviewed +7702 testing +- many clients were rejecting incorrectly +- execute mode in EEST can address this problem - uses JSON-RPC only to interact with node + +### Bikeshedding +Can we rename types to stack-io in the spec? types was not terribly clear. +- stack-io +- section-info or section-spec +- code-info +- signature(s) + + +Standing agenda should move testing to the first items \ No newline at end of file diff --git a/Breakout-Room-Meetings/EOF/Meeting 59.md b/Breakout-Room-Meetings/EOF/Meeting 59.md new file mode 100644 index 00000000..2a3168f2 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 59.md @@ -0,0 +1,40 @@ +# EOF implementers call 59 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1162#issuecomment-2388989786) + +## Meeting info + +Date: 2024.10.02 + +Agenda: https://github.com/ethereum/pm/issues/1162 + +YouTube video: https://youtu.be/TjZv8DMZka4 + +## Notes + +Current release tests (EOF on top of prague) are broken +- Besu had a 7702 bug, all non-7702 tests are fine. +- Next release will be released after devnet 4 is released +- PR reviews are mostly caught up +- Testing focus is on devnet 4 for the next week + +Compiler +- Vyper create from blueprint needs a re-work for EOF. +- Create form EXT Contract would have helped. +- Cannot blueprint off of any contract in EOF like you could in legacy +- A factory deployer would be good, delegate call into a contract that EOF creates. As opposed to an initcode only contract + + +Osaka Migration +- Clients need to target Osaka for EOF activation +- Tests need to target Osaka, including moving tests in source tree +- We have 6 more months to reifine the spec +- We can look into HASCODE +- We can reconsider EXT*CALL return code numbers +- cleanup: EOFCREATE stack order +- cleanup: Remove hashing of container in EOFCREATE +-cleanup: Rename RETURNCONTRACT to RETURNCODE + +### Open questions + +Implications of gas introspection: regarding a gas to eth EIP. diff --git a/Breakout-Room-Meetings/EOF/Meeting 60.md b/Breakout-Room-Meetings/EOF/Meeting 60.md new file mode 100644 index 00000000..28ba6d9d --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 60.md @@ -0,0 +1,100 @@ +# EOF implementers call 60 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1167#issuecomment-2417261891) + +## Meeting info + +Date: 2024.10.16 + +Agenda: https://github.com/ethereum/pm/issues/1167 + +YouTube video: https://youtu.be/FLtlemN2W8w + +## Notes + +### Testing + +Pectra-devnet-4 is occuping most of the test teams time + +Will merge new test, EOF WRap tool + +Client need to start activating on osaka + +Osaka fixture are published + +7702 coverage needs delegation testing, should be in fixtures. Will add more as needed + + +### Clients & Compilers + +Nethermind passing Up to v1.1.0 tests + +revm - need to propagate osaka fork and release + +Geth - RSVPed abent + +evmone - no updates - need to add osaka fork + +Besu - oska is published in main, fixed callf bug found checking traces + +### Spec updates + + +EIP-721 - HASCODE / EXTCODESIZE +- Frangio wants to re-enable EXTCODE opcodes to avoid risk, opcodes will happen via legacy contacts if not added, so we may as well add it. +- Marius doesn't want to compromise on removing introspection, 7702 and migration may make EOAs irrelevant +- Separate from 721 the inability to determine if code lis legacy will break proxyies. +- Danno - We can still jumper out to legacy contracts to use EXTCODE* to get the answers we want from HASCODE +- Frangio would want EXTCODE brought in as-is, this still preserves opaqueness for EOF code +- Charles - EOAs can never revert and return data, that is how it is detected. +- ipsilon - agrees with Marius on keeping removing introspection in, but if not an option HASCODE is preferable to EXTCODE* +- Frangio - without this we will never be able to migrate legacy without some facility like EXTCODE +- ben - HASCODE is just checking a code attribute like we already do when executing EOF vs. non-EOF code. These are not deep introspections, doesn't violate the code/memory barrier. Current handling of EXTCODE doesn't violate the introspection for EOF code, and can be circumvented via legacny contract calls. +- frangio - understands ZK motivation, but needs more clarification on how HASCODE/EXTCODE breaks the ZK motivations. +- charles HASCODE does not preculed AA future, just all accoutns will return true + + +### EXT*CALL return codes + +add new return code to clarify when a failure occured + +Pawel - motivation was that solidity wanted to know when a user caused a REVERT, and to behave differently. In process of implementing light errors were joined in with revert (to prevent some info leaks relating to gas introspection? i.e. failures relating to reserved gas returning a 2 could be used to divine gas levels) + +Charles - reverts can be detected with exiting return buffer, + +We should confirm with solidity this is useful. + +Charles - also, this allows for callstack introspection to determine that failure is callstack related., + +danno/pitor - but 63/64ths rule would require billions of gas to reach the callstack limit. + +Current spec is 1 - not all gas consumed 2 - all call gas was consumed. + +### EOFCREATE hashing + +Goal is to reduce number of hashing calls needed, right now there is a double hashing per call. + +Discussions are ongoing on discord. + +Will come back in two weeks. + +Wants to be able to predict addresses from physical code + +Want collision-free addresses + +container path may be the solution instead of simple container offset for current container. + +### Other + +Tracing +- Danno wants PC=0 is start of container +- evmone - starts from pc=0, it's easier for a global pc counter. PC=0 is section 0 byte 0. It's a pointer in evmone, so it's all math in the trace anyway +- dragan - can work either way +- Ben - makes sense +- Pitor - container = 0 allows for impossible PCs to exist. Code section 0 prevents impossible PC indexes from showing up in traces. +- PC=0 at section 0 also helps indicating where a new call starts, apart from depth increasing. +- More consistent with legacy +- evmone - pc=0 at section 0, section 1 offset +- reth pc=0 at section 0, section 1 is zeroed +- nethermind pc=o at section 0, section 1 is zered. +- continuous PC (section1 bytes 0 != 0) is needed for fuzzing. \ No newline at end of file diff --git a/Breakout-Room-Meetings/EOF/Meeting 61.md b/Breakout-Room-Meetings/EOF/Meeting 61.md new file mode 100644 index 00000000..c4e3d126 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 61.md @@ -0,0 +1,86 @@ +# EOF implementers call 61 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1184#issuecomment-2447633714) + +## Meeting info + +Date: 2024.10.30 + +Agenda: https://github.com/ethereum/pm/issues/1184 + +YouTube video: https://youtu.be/kBQoRdBg4Vg + +## Notes + + +### Testing + +### Clients + +Nethermind - + - merged osaka fixes, + - based off of prague / main + + +reth +- has osaka wired in, +- Fixed one bug with precompiles and EXTDELEGAGECALL + +evmone transition to osaka is larger than expected +- Migrated all ethereum/tests state tests over to EEST +- EOF validation tests are not moved over yet +- Some evmone tests are not ported yet - EVMONE v13 tests + +Besu +- osaka ready in main +- prague-3/4 - based on where main besu gets to + + +### Spec Changes + + +EXT*CALL +- discuss after devcon + +EOFCREATE hashing +- multiple initcode contexts are creaed +- Using container address only works for first level, not nested creates +- create transaction - sender has no code so container address won't work +- Not always possible to point to a "physical address" of the container holding the initcode +- Maybe omit address, and still hash subcontainer when it cannot be proved, but computation time is different in two scenarios +- Goal is to reduce extra hashing +- Useful property is to prove code came from a specific code (not just address) +- Is it possible to defeat polymorphic code? +- Should auxdata be included? + +Change max stack height - to be stack needed in addition to inputs +- makes the two fields (inputs / max stack) unrelated, rather than max >= inputs +- rename the field from max_stack_height to... max_stack_increase +- EEST has some auto-calculations we could leverage, client unit tests would incur ~4h work +- Quality of Life fix, can miss if we are shipping Q1, but if we had 6 more months would be worth looking into for devnet-1 + +Re-order EOFCREATE to match EVMCALL +- same QoL level of effort. Can miss, but if we have time worth adding. +- Feels "small" +- Valuable for tooling and developers manually debugging code, to not have to swap elements + +Rename RETURNCONTRACT to RETURNCODE + +Zero client impact, opcode stays the same + +Documentation changes only + +QoL for devnet-1 + +Please comment on EXTCODE* after devcon (//TODO add link) + +EXTDATACOPY and EXTDATASIZE (//TODO add bug link) +- Target memory? SSTORE2 will use return buffer +- When SSTORE2 is used in this context really we are talking about just the read side, not write +- Question now is smart contract read methods equivelantly good. +- How does it handle legacy and delegate contracts? Read like EXTCODECOPY? Zeros? fault? +- Would EXTDATALOAD be needed too? (no EXTCODELOAD...) + +DELEGATECALL to legacy +- If we fail we need to be able to detect legacy contracts safely and easily +- Could we further tweak SELFDESTRUCT to behave differently when a delegate of EOF? \ No newline at end of file diff --git a/Breakout-Room-Meetings/EOF/Meeting 62.md b/Breakout-Room-Meetings/EOF/Meeting 62.md new file mode 100644 index 00000000..5e8cbd28 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 62.md @@ -0,0 +1,69 @@ +# EOF implementers call 62 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1192#issuecomment-2504249197) + +## Meeting info + +Date: 2024.11.27 + +Agenda: https://github.com/ethereum/pm/issues/1192 + +YouTube video: https://youtu.be/yzYUWpa-1QM + +## Notes + +### Testing Update + +How to handle State tests with invalid EOF? +- state tests - reject test if any EOF is invalid +- Block tests - only an issue in genesis? Abort if EOF in genesis is invalid. +- Imported blocks - presume valid as create TXes are how they are added, so invalid EOF should result in an failed transactions. +- Extends to 7702 - 0xEF01 validation? + + +EOFWrap Tests +- ports over legacy tests into EOF if it ports, stopgap for full testing +- feat(tests): port ethereum/tests test cases (tracking issue) execution-spec-tests#972 will ultimately port all old tests + +### Client and Compiler Updates + +No client Updates, mostly focused on petctra + +Solidity working on EOF as an experimental feature +- eof: Support functions (CALLF, RETF, JUMPF) solidity#15550 +- eof: Implement stack height calculation solidity#15555 +- EOF: Implement ext*calls solidity#15559 + +### Spec Updates + +Compiler Metadata Section +- Kaan from Sourcify Team +- Current practice is to just append +- would want a separate metadata section in EOF. + - Unreachable by code (a good thing) + - contains the CBOR data solidity produces +- Current status of appended to data and behind constructor fields makes it hard to find +- Experimental Solidity EOF handling is to put CBOR metadata at the beginning of the data section. +- Would insulate code/data indexes from variable CBOR sizes, such as if experimental flags are logged. +- Next step is an EIP + + +### Brief discussion on header section numbers + +EOFCREATE hash - ipsilon/eof#162 (comment) + +danno wants a "0xef01" hash added + +Solidity has concerns about the genericness, would prefer container index + +Bad salt management could prohibit multiple deployments + +Should hash include auxdata, not just code data? + +possible issues with cross-chain deployment. The more mandatory data makes same address contracts difficult. + +note: some people don't like metadata has in CREATE2, would compiler metadata be excluded from address derivation? + +Are there security implications? Would the "code hash" guarantees be forgotten about? Could compilers compensate? + +Please add comments to the thread. diff --git a/Breakout-Room-Meetings/EOF/Meeting 63.md b/Breakout-Room-Meetings/EOF/Meeting 63.md new file mode 100644 index 00000000..31d1adac --- /dev/null +++ b/Breakout-Room-Meetings/EOF/Meeting 63.md @@ -0,0 +1,48 @@ +# EOF implementers call 63 + +Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1205#issuecomment-2533055543) + +## Meeting info + +Date: 2024.09.17 + +Agenda: https://github.com/ethereum/pm/issues/1205 + +YouTube video: https://youtu.be/2Z5YPfOnb74 + +## Notes + + +### Tracing: + +Updated EIP-7756 + +- PC=0 is always the first byte of the container +- Number and HexNumber are interchangable +- OpCode now defaults to hex +- gas members now default to number + + +reth and evmone will need to adjust to PC=0, geth, besu, and nethermind have already adjusted + +#### Fuzzing: + +branch with WIP fuzzing tool shemnon/eof-fuzz + - Needs a patch to goevmlab to work - Non-osaka EOF changes holiman/goevmlab#179 + +Corpus is the single test set of reference tests + +4 mutators currently (more to come) +- Add PUSH0/POP +- Replace PUSH value with in-test address +- Replace PUSH value with "magic" number (mostly 2^x and friends) +- Replace PUSH with random bytes (biased to shorter strings) + + + +Found 3 bugs so far +- Besu 32/64 bug in EOFCREATE +- Geth DATACOPY overflow +- Nethermind EXT*CALL gas costing issues + +plan is to write more fuzzers to bring it on par with FuzzyVM, but for EOF. \ No newline at end of file From 71c322bc8a12e853383c67f7beeaf63707caf5da Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 22 Dec 2024 17:02:17 -0500 Subject: [PATCH 17/51] Update Meeting 63.md --- Breakout-Room-Meetings/EOF/Meeting 63.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Breakout-Room-Meetings/EOF/Meeting 63.md b/Breakout-Room-Meetings/EOF/Meeting 63.md index 31d1adac..ee987ba8 100644 --- a/Breakout-Room-Meetings/EOF/Meeting 63.md +++ b/Breakout-Room-Meetings/EOF/Meeting 63.md @@ -4,7 +4,7 @@ Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1205 ## Meeting info -Date: 2024.09.17 +Date: 2024.12.17 Agenda: https://github.com/ethereum/pm/issues/1205 @@ -45,4 +45,4 @@ Found 3 bugs so far - Geth DATACOPY overflow - Nethermind EXT*CALL gas costing issues -plan is to write more fuzzers to bring it on par with FuzzyVM, but for EOF. \ No newline at end of file +plan is to write more fuzzers to bring it on par with FuzzyVM, but for EOF. From cb602d38d1c371be9deee0b531f72d387ea53eb8 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 22 Dec 2024 17:14:22 -0500 Subject: [PATCH 18/51] Create EOF-pm.md --- Breakout-Room-Meetings/EOF-pm.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Breakout-Room-Meetings/EOF-pm.md diff --git a/Breakout-Room-Meetings/EOF-pm.md b/Breakout-Room-Meetings/EOF-pm.md new file mode 100644 index 00000000..afade324 --- /dev/null +++ b/Breakout-Room-Meetings/EOF-pm.md @@ -0,0 +1,19 @@ +# EOF + +## Overview + +The Ethereum Object Format (EOF) represents a transformative update to the Ethereum Virtual Machine (EVM) bytecode structure. Designed to enhance the efficiency, security, and modularity of smart contracts, EOF restructures how smart contract bytecode is organized. This upgrade addresses traditional limitations of the bytecode format, aiming to make contracts more manageable and secure. + +| # | Date | Agenda | Recording | Notes | +| -- | --| -- | -- | -- | +|63| December 17, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1205) | [Recording](https://youtu.be/2Z5YPfOnb74) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2063.md)| +|62| November 27, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1192) | [Recording](https://youtu.be/yzYUWpa-1QM) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2062.md)| +|61| October 30, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1184) | [Recording](https://youtu.be/kBQoRdBg4Vg) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2061.md)| +|60| October 16, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1167) | [Recording](https://youtu.be/FLtlemN2W8w) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2060.md)| +|59| October 02, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1162) | [Recording](https://youtu.be/TjZv8DMZka4) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2059.md)| +|58| September 18, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1146) | [Recording](https://youtu.be/MSuxLswMkXA) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2058.md)| +|57| September 04, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1138) | [Recording](https://youtu.be/7wFucExQb7U) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2057.md)| +|56| August 21, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1128) | [Recording](https://www.youtube.com/watch?v=03Dkfpvw4Pc) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2056.md)| +|55| July 24, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1115) | [Recording](https://youtu.be/OaNJOoaeNNY) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2055.md)| + + From d5a7849ecbd7e2e624be70129a9301cdce29c2ef Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:45:27 -0500 Subject: [PATCH 19/51] Update Meeting 12.md --- Breakout-Room-Meetings/PeerDAS/Meeting 12.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 12.md b/Breakout-Room-Meetings/PeerDAS/Meeting 12.md index bb8c54a4..d2908710 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 12.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 12.md @@ -1,8 +1,3 @@ ---- -title: Meeting 12 - ---- - # PeerDAS Breakout Room #12 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) @@ -72,4 +67,4 @@ https://github.com/ethereum/consensus-specs/pull/3832 https://github.com/ethereum/consensus-specs/pull/3871 -https://github.com/ethereum/consensus-specs/pull/3871 \ No newline at end of file +https://github.com/ethereum/consensus-specs/pull/3871 From 6ccd55f1f952454197fb3ab0b0e5c0eeb387955a Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:45:39 -0500 Subject: [PATCH 20/51] Update Meeting 11.md --- Breakout-Room-Meetings/PeerDAS/Meeting 11.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 11.md b/Breakout-Room-Meetings/PeerDAS/Meeting 11.md index 191d900e..5038f5b8 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 11.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 11.md @@ -1,7 +1,3 @@ ---- -title: Meeting 11 - ---- # PeerDAS Breakout Room #11 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) @@ -101,4 +97,4 @@ https://github.com/ethereum/consensus-specs/pull/3993 https://github.com/ethereum/beacon-metrics/pull/14 -https://github.com/KatyaRyazantseva/beacon-metrics/blob/master/metrics.md#gossipsub-metrics \ No newline at end of file +https://github.com/KatyaRyazantseva/beacon-metrics/blob/master/metrics.md#gossipsub-metrics From 49be50de80451943e7eec096ff8202f510ef8229 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:45:50 -0500 Subject: [PATCH 21/51] Update Meeting 09.md --- Breakout-Room-Meetings/PeerDAS/Meeting 09.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 09.md b/Breakout-Room-Meetings/PeerDAS/Meeting 09.md index d1ce9258..ce85189d 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 09.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 09.md @@ -1,7 +1,3 @@ ---- -title: Meeting 09 - ---- # PeerDAS Breakout Room #9 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) @@ -110,4 +106,4 @@ https://github.com/ethereum/execution-apis/pull/559 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7742.md -https://notes.ethereum.org/tJaC6buSSj-YNOKVmAfbCg?view \ No newline at end of file +https://notes.ethereum.org/tJaC6buSSj-YNOKVmAfbCg?view From 3c36e115c481082e662e4a415afb9e178d46d437 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:46:00 -0500 Subject: [PATCH 22/51] Update Meeting 10.md --- Breakout-Room-Meetings/PeerDAS/Meeting 10.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 10.md b/Breakout-Room-Meetings/PeerDAS/Meeting 10.md index ffd6079a..f195301c 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 10.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 10.md @@ -1,7 +1,3 @@ ---- -title: Meeting 10 - ---- # PeerDAS Breakout Room #10 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) @@ -87,4 +83,4 @@ https://grafana.observability.ethpandaops.io/d/fdzvv4w0xe1hcd/peerdas-metrics-sp https://github.com/ethereum/beacon-metrics/pull/13 -https://forms.gle/tt1L2QvSq3JnKPoW7 \ No newline at end of file +https://forms.gle/tt1L2QvSq3JnKPoW7 From ff61c0fbddc7fbc71cceaf68ddfef8f62189f010 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:46:12 -0500 Subject: [PATCH 23/51] Update Meeting 08.md --- Breakout-Room-Meetings/PeerDAS/Meeting 08.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 08.md b/Breakout-Room-Meetings/PeerDAS/Meeting 08.md index f28ae45f..2ed7ef66 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 08.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 08.md @@ -1,8 +1,3 @@ ---- -title: Meeting 08 - ---- - # PeerDAS Breakout Room #8 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) From 42669e16d28d0d476a5d237d057c784201fb1c43 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:46:29 -0500 Subject: [PATCH 24/51] Update Meeting 07.md --- Breakout-Room-Meetings/PeerDAS/Meeting 07.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 07.md b/Breakout-Room-Meetings/PeerDAS/Meeting 07.md index cf983e36..5fa8500d 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 07.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 07.md @@ -1,8 +1,3 @@ ---- -title: Meeting 07 - ---- - # PeerDAS Breakout Room #7 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) @@ -82,4 +77,4 @@ https://github.com/ethereum/consensus-specs/pull/3908 https://github.com/ethereum/consensus-specs/pull/3864 -https://github.com/ethereum/execution-apis/pull/559 \ No newline at end of file +https://github.com/ethereum/execution-apis/pull/559 From 55769b0d2374976099291b0bac01b6d8c16394ce Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:46:51 -0500 Subject: [PATCH 25/51] Update Meeting 06.md --- Breakout-Room-Meetings/PeerDAS/Meeting 06.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 06.md b/Breakout-Room-Meetings/PeerDAS/Meeting 06.md index 9d544b01..d52ab5d7 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 06.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 06.md @@ -1,8 +1,3 @@ ---- -title: Meeting 06 - ---- - # PeerDAS Breakout Room #6 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) @@ -101,4 +96,4 @@ https://github.com/ethereum/consensus-specs/pull/3889 https://github.com/ethereum/consensus-specs/pull/3800 -https://notes.ethereum.org/@ethpandaops/peerdas-devnet-2 \ No newline at end of file +https://notes.ethereum.org/@ethpandaops/peerdas-devnet-2 From 7778415e642c550ae47dfca3aa22beb0dad61156 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:47:07 -0500 Subject: [PATCH 26/51] Update Meeting 05.md --- Breakout-Room-Meetings/PeerDAS/Meeting 05.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 05.md b/Breakout-Room-Meetings/PeerDAS/Meeting 05.md index b56f8eb9..485096b3 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 05.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 05.md @@ -1,7 +1,3 @@ ---- -title: Meeting 05 - ---- # PeerDAS Breakout Room #5 From 57590874e52aec20b46607ed344cab4cde499af8 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:47:19 -0500 Subject: [PATCH 27/51] Update Meeting 04.md --- Breakout-Room-Meetings/PeerDAS/Meeting 04.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 04.md b/Breakout-Room-Meetings/PeerDAS/Meeting 04.md index abdb7ca6..d2fe2a67 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 04.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 04.md @@ -1,8 +1,3 @@ ---- -title: Meeting 04 - ---- - # PeerDAS Breakout Room #4 ## Meeting info @@ -77,4 +72,4 @@ Prysm raised a question regarding validator custody: if node doesn't reply with ## Zoom -https://github.com/ethereum/consensus-specs/pull/3821 \ No newline at end of file +https://github.com/ethereum/consensus-specs/pull/3821 From f130e2a3978cf1bdaa3c0681ede87b9887d21378 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:48:29 -0500 Subject: [PATCH 28/51] Update Meeting 03.md --- Breakout-Room-Meetings/PeerDAS/Meeting 03.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 03.md b/Breakout-Room-Meetings/PeerDAS/Meeting 03.md index 89bbc7a1..8ee385ae 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 03.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 03.md @@ -1,7 +1,4 @@ ---- -title: Meeting 03 ---- # PeerDAS Breakout Room #3 Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq) From debf9320043a1ce208a28afc3e9301d79a62ed39 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Mon, 23 Dec 2024 21:48:40 -0500 Subject: [PATCH 29/51] Update Meeting 02.md --- Breakout-Room-Meetings/PeerDAS/Meeting 02.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/Breakout-Room-Meetings/PeerDAS/Meeting 02.md b/Breakout-Room-Meetings/PeerDAS/Meeting 02.md index fbd345f5..525a96db 100644 --- a/Breakout-Room-Meetings/PeerDAS/Meeting 02.md +++ b/Breakout-Room-Meetings/PeerDAS/Meeting 02.md @@ -1,7 +1,3 @@ ---- -title: Meeting 02 - ---- # PeerDAS Breakout Room #2 From cea68cbeb02afd13795b713bcd26b6ac9752f419 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 24 Dec 2024 18:55:56 -0500 Subject: [PATCH 30/51] Update FutureEOA-AA-pm.md Added 2 new meetings to README file --- Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md b/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md index 5fc20526..c38cc5f5 100644 --- a/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md +++ b/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md @@ -5,6 +5,8 @@ | # | Date | Agenda | Recording | Notes | | -- | --| -- | -- | -- | +|6| July 31, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1118) | [Recording](https://youtu.be/Oct83bBp3Z8) | [Notes] +|5| June 26, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1081) | [Recording](https://youtu.be/_S01TtA3lao) | [Notes] |4| June 05, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1054) | [Recording](https://youtu.be/gsc_yTdHRig) | [Notes] |3| May 29, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1053) | [Recording](https://youtu.be/0vHHhZgrJ58) | [Notes] |2| May 07, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1032) | [Recording](https://youtu.be/GPdbQxmsXR8) | [Notes] | From bcc334f86b219e00c97c9d850821b89a066b9e1a Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 24 Dec 2024 22:10:13 -0500 Subject: [PATCH 31/51] Meetings 3-6 --- .../FutureEOA-AA/Meeting 03.md | 341 +++++++++ .../FutureEOA-AA/Meeting 04.md | 36 + .../FutureEOA-AA/Meeting 05.md | 412 +++++++++++ .../FutureEOA-AA/Meeting 06.md | 683 ++++++++++++++++++ 4 files changed, 1472 insertions(+) create mode 100644 Breakout-Room-Meetings/FutureEOA-AA/Meeting 03.md create mode 100644 Breakout-Room-Meetings/FutureEOA-AA/Meeting 04.md create mode 100644 Breakout-Room-Meetings/FutureEOA-AA/Meeting 05.md create mode 100644 Breakout-Room-Meetings/FutureEOA-AA/Meeting 06.md diff --git a/Breakout-Room-Meetings/FutureEOA-AA/Meeting 03.md b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 03.md new file mode 100644 index 00000000..c5b72409 --- /dev/null +++ b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 03.md @@ -0,0 +1,341 @@ +Future of EOA/AA Breakout Room #3 +-- + +## info +**Date**: May 29 2024, 14:00-15:00 UTC + +**Agenda**: https://github.com/ethereum/pm/issues/1053 + +**Recording**: https://youtu.be/0vHHhZgrJ58 + +**Links shared in chat**: +* notes at the Berlin workshop by Ansgar: https://notes.ethereum.org/@ansgar/aa-meeting-berlin +* proxy pattern idea by Matt Garnett to discuss https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523 + +## Next steps +- next call - 1 week from now, then bi-weekly +- start working on best practices + +By next call we hope to +- explore different specs & changes by Vitalik +- ERC Proxy [Richard & Ansgar] +- getting progress on best practice document [Ansgar] + + +## Agenda + +Tim: Since the last meeting, PR on EIP7702 and the Berlin talk are the two main things. +Hopefully, we can discuss and get next steps. + +Matt: PR is based on different convo in Berlin and at different places. +In Berlin, we talked about some restrictions with wallet devs over there. + +#### Takeaways from Berlin +- will not have a flag to persist the code, because of open question of EOA +- need to do more research on storage allowances + +#### Issues +- storage key collision between..., added 7610 +- Replay protection + +Ansgar: +In Berlin , different dimensions and open questions were discussed. + +- How do you specify the target + - specify the address and not the code +- Decision is that launching something that is already having flag is not right +- other than storage, the other big thing was to start working on a wallet guidence +- how should this be supported by Ledger brought different questions and concerns, thus warrented for a guideline + + + +### Pectra 7702 spec + +#### [Update EIP-7702: refine based on discussions](https://github.com/ethereum/EIPs/pull/8561) + +Ansgar Dietrichs +I really think this PR should be merged instead of being the perpetual catch-all for all changes to the EIP. I keep meeting ppl that only see the main EIP and are unaware of any of these changes. + + +### AA Berlin Workshop Summary +#### Open questions: +##### **Replay Protection** + +Ankur Dubey +Just to confirm, for replay protection has it been decided that both nonce and chain_id will be optional, by setting it to 0? + +Julian Rachman +And then nonce would be set to null + +Daniel Lehrner (Besu) +Yes, just one correction: nonce must be null, not 0 to be optional. Because nonce 0 is a valid value. + + +##### **Storage Restrictions** +Yoav: +@lightclient @Ansgar Dietrichs update re storage. I talked to the solidity team and they started looking into supporting storage layout remapping. Just got off a call with them and they're on it. If we agree on a standard for storage bases, it can be made safe without sstore restrictions. + +Basically resolving this old issue: +https://github.com/ethereum/solidity/issues/597#issuecomment-1537533170 + +- whether to make it safe + +Felix: +- it is usually unsafe to sign conflicting code, the safe side will be to allow only one proxy +- it will allow contract development system to develop the idea of storage system as it is fairly new + + +Konrad +- have a modular account with ref implementation, may send a PR +- Based on the PR it is pretty minimal effort +Pr for context: https://github.com/erc7579/erc7579-implementation/pull/29 + +Richard Meissner +I tend to disagree @Konrad. I.e. with Safe the implementation effort is little, but migrating users is a huge effort. Also auditing this and performing formal verification with external storage increases complexity. + +Ahmad +- specifying a proxy and only allowing single contract + + +Felix +- the difference is that changing destinantion of the proxy +- if want to switch from one to another wallet type, initially you'd point the proxy and when want to point to another wallet +- with authorization approach, you'd be allowed to sign by anyone and run code in the context of account. Will be more risky as it is not an onchain action to designate which code to be run. + +Richard Meissner +It is possible, but definitly way more effort than when we can directly use existing contracts. (Note: I do not see this as a blocker, just a comment on compexity) + +Ansgar Dietrichs +I will say, if we think the “only one authorized implementation at a time, with changes requiring onchain actions” pattern is desirable, we should think about a more fundamental change to 7702 instead of just enshrining a specific proxy as target + +Ahmad: +- it does not make sense to restrict the design + +Richard Meissner +I tend to disagree @Konrad. I.e. with Safe the implementation effort is little, but migrating users is a huge effort. Also auditing this and performing formal verification with external storage increases complexity. + +Richard Meissner +As said it is not a blocker, but we have to consider our existing users. Maintaining multiple contract versions is not really efficient over a longer time + +Konrad +Could this be determined at runtime (ie having a flag that determines whether to use contract storage or external storage)? That way it’d only be one codebase + +Ansgar Dietrichs +I agree with felix to some extent: there is some risk that given pectra might be relatively soon, that we don’t have enough time to fully figure out best practices. in an ideal world then wallets would wait before adopting 7702, but competitive pressures might make this infeasible + +thogard +Could use a diamond storage pattern with address(this).codehash as the storage salt? +But I agree w/ yoav - sequential storage would be a nightmare + +Ahmad: +- I will not prevent SSTORE + +Tim +- So the SSTORE will act like what TSTORE does + +Ahmad +- Yes + +Yoav +- We don't want it to work like TSTORE +- say, setting a threshold for an implementation and the threshold increases. We should not change the semantic + +Richard Meissner +Agree with @Yoav I.e. for a normal Safe you could replay txs as the nonce is in storage that would be reset + +Ansgar +- External storage may be the better way + +Richard: +One point for the external storage pattern was, that keystore related pattern are going in a similar direction + +Ankur +- Allow the user to specify the additional contract storage address +- if the user want to switch to another application, it switch to another storage code + + +Dan Finlay +I thought part of the 7702 motivation was reusing existing code, so making a big difference in the behavior or implementation of these account extensions would seem like it compromises the benefits over 3074. + +Dan Finlay +I’ll note 3074 avoided storage issues. + +Richard Meissner +That is because 3074 acts like an external storage holder, right? + +Dan Finlay +right + +Richard Meissner +But agree that with allowing storage it would provide more benefits + +Dan Finlay +the invoker initiates the message on behalf of the user + +Ansgar Dietrichs +I think it is pretty binary: either there are no changes, or it requires rewrite anyway + +elim +Using existing code as-is would be the dream. But if it requires minimal modifications, imo it's still better than an entirely different architecture as required by 3074. Since the 7702 modified wallets can still be used as-is for native aa. + +Dror +- How much external storage change the implementation to EOA + + +Ansgar Dietrichs +I also strongly disagree with implicit tstore behavior. if behavior is not identical, making it explicit breaking instead of implicit unexpected behavior is much preferable + +Ansgar Dietrichs +storage contract defined in tx would not be forward compatible with later permanent transitions, no? unless we would then store that storage contract location in the verkle node and have this difference of former-EOA contracts forever? + +Ansgar Dietrichs +I don’t think we can make final decisions on storage today. more important to figure out how we can get to making decisions on this over the next month or so + +thogard +One pattern would be to SSTORE / SLOADs point at keccak(actual slot, codehash) for EOAs, but that runs into the same nonce replay issue unless the nonces are stored externally. + +Richard Meissner +the "disadnavtage" with this would be that we have to touch existing opcode behaviour + +Yoav +I held the same opinion until solidity agreed to add namespaced storage + +lightclient +allowing storage isn’t going to block migration + +Yoav +With that, it becomes easier to have a standard that all accounts should use + +Matt: +Even if we have store, we see migration +- same thing discussion +- Solidity is able to suggest storage +- if it is okay at the protocol level, then it is good +- Allowing SSTORE to work as it is supposed to work in a normal contract + + +**Tim**: Let's move forward with Storage and keep discussing. + +Matt +- in 7702 it is possible to delegate to code offchain and is natural. +- It is more likely a situation where user will end up +- One way is to have a proxy contract that is allowed + +Sachin Tomar +If we allow storage in EOA, won’t this result in storage conflict when EOA uses different implementations in different txns? + +Dan Finlay +And risks the bundler including the wrong 7702 account, changing the behavior of the op + +Felix +This is why I suggested to only allow a specific proxy, because then you'd at least be able to perform explicit transitions between the implementations. + +Dan Finlay +Yeah, “just allowing a specific proxy” may not solve storage conflict, but does solve this important issue. + +##### **Proxy Pattern** + + +https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523 + +Matt +- Matt thinks this addresses the issue of Offchain delegation of 7702 + + +elim +Not necessarily the proxy code, but rather the implementation slot right? + +Ansgar Dietrichs +I don’t dislike one proxy contract, but I would be very reluctant to enshrine it in the protocol. better to enforce via wallet whitelisting imo + +Ansgar Dietrichs +also means that every tx is more expensive now, as it always has that additional delegatecall hop + +Dan Finlay +I disagree; a user with srps in two wallets could get in hazardous situations easily here + +Dan +- there can be conflicting 7702 message floating around +- I think this is about ensuring the user about safety + +**SRP means Secret Recovery Phrase** + +Ansgar +- open to the idea, but look more into fundamentally change 7702 + +Matt +- what problem is being addressed? + - (explained at 40 mins) + +Andrew +- extend the account scheme with verkle? + +Gary Schulte +Agreed re:verkle, but presumably we don’t want to wait for Osaka for AA + +Julian Rachman +So would this proxy be a built-in proxy? + +Julian Rachman +Built into the protocol + +vub +**A few random ideas:** +1. Let the code of ADDRESS + 1 represent an EOA's "backup code", and have 7702 just temporarily flip on the backup codes of the listed accounts + +2. Add an EOF version for "this account's 7702-code is at address X" + +Ansgar Dietrichs +can’t do this before eof in pectra is certain + + +Daniel Lehrner (Besu) +An enshrined proxy could cause problems with L2 compatibility. Not all L2s are on the same hard fork as main net + +lightclient +the proxy would not use new ops + +elim +Why does it need to be a proxy? We just need to record on-chain somehow who the account is delegating to. So this can just be an agreed upon storage slot. 7702 auth'ed implementations can just "promise" to verify this slot. +Can bypass the extra delegatecall + + + +Matt +- Merge the PR without the storage restriction +- and we go from there +- the client team will implement +- the wallet team want less permissive system and we will get to know where we land + +Vub - agrees + + +Andrew +- Noun nonce and zero nonce + +#### **Tim: Move forward with the PR to add in Devnet 1** +- will be discussed in ACD meeting + +Ivo @ Ambire +My 2c is that no storage restriction is amazing. Huge flexibility for wallet teams, no need to enshrine a contract, + +And the storage conflicts are a separate issue that always existed. Yes, 7702 makes it easier for it to accidentally happen but this is up to wallet devs to prevent (make implementations that use unique slots) + +Eilas +- Noob question also that i didn’t get an answer for, why is there a keccak in the spec of the new tx type for 7702? +It hinders ZK-EVMs + +Vitalik +- it is broader issue +- can be a part of the broader move + + +Matt agrees with Vitalik. + + +Ahmad +- the wallet developers gather and agree on max flexibility + + +Tim ++1 on ERC proxy, if we could have a draft for next week’s call that’d be great \ No newline at end of file diff --git a/Breakout-Room-Meetings/FutureEOA-AA/Meeting 04.md b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 04.md new file mode 100644 index 00000000..2660320f --- /dev/null +++ b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 04.md @@ -0,0 +1,36 @@ + +Future of EOA/AA Breakout Room #4 +-- + +**Date**: June 05 2024, 14:00-15:00 UTC + +**Agenda**: https://github.com/ethereum/pm/issues/1054 + +**Recording**: https://youtu.be/gsc_yTdHRig + +**Links shared**: +* Working document for [Wallet best practices](https://hackmd.io/@rimeissner/eip7702-best-practices) +* Optional nonce + * https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923/158 +* Signign Address vs Code +https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923/157 + +## Next steps +* discuss this more in All Core Dev and if we want another call. + + + +(Full Notes in WIP) + +**Tim Beiko**: Okay, I guess we probably get started. Had a few things on the agenda for today. basically some spec discussions. Then, following up on what is best practices and the proxy pattern and see how how things go. + +Yeah, let's maybe kick this off with the revocability conversation. So Sudeep, I believe you are the one who posted on the Erigon’s behalf on the magicians. + +## Optional revocability. + +**Tim Beiko**: Do you wanna take maybe a minute to like, walk through your views and concerns. + +**Sudeep | Erigon**: Yeah. So we have been considering, the security handling and concerns, and saying that it's the same as a private key or a seed phrase. I disagree there, because once you delete the wallet from your browser, the seed phrase, or the private key is supposed to be gone, and no more with the wallet provider. But with the signatures, it's a different deal like once you make a 7702 transaction, the authorizations live on the chain. And so let's say, if I don't trust the wallet anymore, and I want to move to a different wallet. Then I should have an option to do something similar to, Sign out of all accounts, or sign out sign out of all devices. There has to be like a mechanism for that. otherwise, there's always a lingering question about Is it safe? There was an authorization that that was there, and it wasn't really revoked. So what what happens there? + + +**Sudeep | Erigon**: Second point is that the people who are opposed to revocability. I don't think they're opposed to revocability as such. But the constraints that it poses on the wallet providers. and I think the nonce solution, nonce revocability is definitely too constraining for the wallet providers to create a proper ux. So I think we should investigate like more solutions. Certainly, Max nonce is one such option. The nonce manager is one such options. I think we can like come together with come together with more solutions on top of this, which have revocability baked in, and also allow the wallet providers enough sort of breathing room to create the UX that they want. diff --git a/Breakout-Room-Meetings/FutureEOA-AA/Meeting 05.md b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 05.md new file mode 100644 index 00000000..982c5d4e --- /dev/null +++ b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 05.md @@ -0,0 +1,412 @@ +Future of EOA/AA Breakout Room #5 +-- + +## Info +**Date**: June 26 2024, 14:00-15:00 UTC + +**Agenda**: https://github.com/ethereum/pm/issues/1081 + +**Recording**: https://youtu.be/_S01TtA3lao + +**Next steps**: +- People are aligned to see [Matt's proposal](https://github.com/ethereum/EIPs/pull/8677) in the next devnet. +- It will be merged in next week or so. +- It is devnet 2 and we will take it from there. will explore more in the next stages. + +## Notes + +**Nicolas** +To discuss that last update to 7702 + +Kevin +- The proposal is basically serving the same purpose of revokability in the same way. +- The new ver is also going in the same direction by trying single implementation at a time. +- Our proposal was mimicing what proxies are doing. +- Except migration being more difficult, I don't see the new proposal to be any different. +- I think we're going into more permanent. + +Julian Rachman +- I am against the permanent approach. I think we talked about this throughout the weeks + +Matt/Sam/Ansgar +Ansgar +- couldn't look into proposed change +- conceptually it is somewhat cleaner, and in principle I like it. +- two different option to activate the delegration target + + - add another field to 7702. give a list without authentication. It will make the tx make it active when needed, not permanenetly. + +Sam +- If we're doing a permanent delegation, why not just make a tx type that deploys code into the EOA + +Richard Meissner +- So the question is if the permanent approach is an acceptable path to approach the revocation topic. +- So far it feels that while now Nethermind is fine with the proposal, other teams that did not have too much of an issue with the revocation, would rather stick to the non-permanent proposal. + +Julian Rachman +- So why dont we just push the current 7702 language then? + +kevin +- That’s also part of the proposal Ledger made, having an access_list like option a transaction to activate or not the behavior + +Richard +- That would still mean only one delegation target at once, right @Ansgar Dietrichs  + +@Arik you advocated to allow multiple delegation targets, right? + +Richard Meissner +basically on chain it is said which delegation target can be used, but it will only be used if you specify it in the transaction. + +Ansgar +- Basically the original version of 7702 will be used, but limited to the address (singular) that is set onchain in the account. + +kvn +- Not that we don’t like the permanent approach, it’s just like it feels like it was the kind of things that people tried to avoid during the discussion for EIP-3074 -> EIP-7702 + + +Matt +- In case of Revokation + - you have given permanent delegation +- the nice thing about 7702 is that autherization is only valide one time while setting the account. + - the a/c is delegated to smartcontract wallet +- now that we can write into the account feels like the best thing to happen. +- Let people slowely migrate to smart contract wallet. + + +Arik +I think you can just add a small flag to decide if the delegation is single transaction or permanent and it should solve everyone’s issue… + +Richard Meissner +should the single tx authorization be reusable? + +Arik +No, if you used it and you want to authorize again you would need to do it on a new nonce… cause it increased + +Ansgar Dietrichs +yes, I think in every variant of this, I would appreciate a one-time use flag, basically “don’t store this as delegation target at all, just use it for this tx” + +Arik +- Ansgar, I am not sure I understood the mechanism fully - can you write it down? + +Ansgar Dietrichs +- right, Richard summarized it well. With the additional asterisk that now by default “turning on” 7702 delegation for an already set target would no longer require any sort of signature by that account at all + +yoav +- Seems like the right trade off to make + +Hoshiyari +- Using this a malicious EOA would act as a genuine contract for eg; a vault until have enough funds to run away. + +I was wondering how the new version can mitigate this actor vector… + +Sudeep | Erigon +- I don’t know if temporary delegation adds anything. Permanent delegation simplifies what 7702 does — which is to set a delegation designation. +Also in temporary delegation wouldn’t you need to have a new authorization (since it’s nonce based) the second time you make a 7702 tx? + +Richard Meissner +- yes, that is basically what arik is asking for. It is basically to bring in features like batching + +Ansgar Dietrichs +- by temporary delegation, do you mean my alternative idea or the proposed one-time use flag Arik just mentioned? + +Richard Meissner +- there no long running authorization is required, it is ok to do a per transaction authorization to batch and sponsor + + +Sam +- Can you self-destruct in the delegate call target? + +Matt thinks +#### Temprorary delegate allocation does not bring us closer tothe smart contract wallet + +Arik thinks other wise +- just having the ability to delegate may increase adoption + + +Sudeep | Erigon +- I don’t know if temporary delegation adds anything. Permanent delegation simplifies what 7702 does — which is to set a delegation designation. +Also in temporary delegation wouldn’t you need to have a new authorization (since it’s nonce based) the second time you make a 7702 tx? + +Ansgar Dietrichs +- right. so in that variant, once the delegation target is set, “turning it on” within a second (or third, or fourth, …) 7702 tx would not require a signature at all. 7702 basically would have 2 lists: one to change 7702 delegation targets, that comes with nonce and sig. and then one for accounts that should have their delegation enabled, without any sigs + +Arik +- I think you can just add a small flag to decide if the delegation is single transaction or permanent and it should solve everyone’s issue… + +Ansgar Dietrichs +- so one problem with this is frontrunning the one-time use tx (e.g. for griefing the user), if you send it via a public mempool. because the sig doesn’t commit to being used within a specific tx + + +- temporary delegation +- longterm deleg +- permanent deleg + + +Ansgar +- The problem we are trying to solve is Frontrunning. +- I am wondering any good ways to mitigate this as it is not with the protocol. +- Matt proposal may have more context and I think could work. Unsure of any other ways to mitigate it. + + +Matt +- using in temp deleg or perm delegation +- if there is a piece of code which has risk then there is no point of having of temporary delegation + + +Richard Meissner (safe) +- what is the most realistic version to push into the h/f +- what is the complexity as we want to ship with devnet 2 +- for me this is the pressing matter that if it is enough to implement +- there are way more qns around revokability at this time +- consideration of security and revokability are good way to go for us +- agree to what ansgar says about timeline + + + +Julian Rachman +- I guess we are using very loose terms here with “permanent”, “temporary”, etc. + +Maybe current “permanent” is better said as “persistent” delegation and “temporary” is better said as “expiring” delegation + +Ansgar Dietrichs +- I would say “one-time” for those that cannot be used more than once. +And then “optional” for those that are stored, but only active in the initial tx and in future txs that explicitly activate it again + +Julian Rachman +- Sure!! Honestly anything away from using “permanent” and “temporary” would be right + +lightclient +- ultimately you can also implement the one-time use with the current proposal + +lightclient +- so there is no need to over complicate 7702 + +Ansgar Dietrichs +- on a more general note, I will say that it really worries me how much the 7702 spec is still in the air, with regard to Pectra timing. + +**For context though**, Pectra size is very very large, so full rollout of the fork will probably take quite some time still. Imo the worst timing risk here is that Pectra ends up split into two parts, and that 7702 won’t be ready for the first part, so will end up having to wait an additional 4 months or so. + +Ahmad +- suggestion - to preserve old 7702 behaviour, we can add a boolean flag +- the nice thing about this is that once it absorbs the nonce, we gain the implemenattion simplicity from the core dev perspective + + +Richard Meissner +@Ahmad Mazen Bitar how do we handle the DoS vector that @Ansgar Dietrichs outlined for this approach? + +Richard Meissner +- in the sense that the authorization can be invalidated by malicious parties + +Ahmad +- this approch of adding flagg may satisfy all three concerns with a better implemenation of EIP + +Arik +- Can someone explain why the persistence version is not attackable by this DOS vector? + +Ansgar +- the prob I see is that if you send one time use tx, and is picked up by a bundler of anyone, the tx doesn't make use + + +Richard Meissner +- because if you frontrun the authorization it is available onchain +and therefore it will still be valid in the tx that was frontrun + +Ivo Georgiev | Ambire +- Unless im missing something, temporary authorizations would be quite limited in terms of UX + +You send one txn to set a delegation, so that you can then benefit from SCA features for one transaction + +Sounds like something that will never be used in the wild + +Richard Meissner +- for batching and sponsoring this should be sufficient, right? + +Ahmad +- it will just validate the tx. + +Ansgar +- it will not activate and will not make use of the one time. + +Ahmad +- got it, will think about it. + +Antony Denyer +- You can basically “unbundle” it? + +kvn +- Also, the more options we have, the more complicated the Wallet UX will be… Explaining this AA behavior in ten different ways for X different AA "brands", and making sign (very powerful) authorizations 10 times, is definitely something that feels very niche to me + +Ansgar +- Pectra is very unprecedented +- 7702 spec should be final very soon otherwise, it will not make it. +- what could happen, that the EIP is split up in two +- if that were to happen, we really need to decide. +- I think we need to make decoision + - what recommendation to ACD on what to ship in the next h/f + - can we ship matt's change. - yes or no + - I persopnally want to make delegation transparent + - we should focus on the spec that we want people to use on the upcoming devnet + + +Ahmad +- EOF tries to look into code & gas introspection + - I'd try to avoid intrspection of code and account +- If we have the knowledge of one time designation will be consumed by the sender account, then we can authorize +- unsure if it will work with paymaster +- also if this is a requirement to allow authorization. + +yoav +- It’s roughly equivalent to SSTORE so we could use the same pricing model (which will change with verkle) + +Ansgar Dietrichs +- on a more general note, I will say that it really worries me how much the 7702 spec is still in the air, with regard to Pectra timing. + +For context though, Pectra size is very very large, so full rollout of the fork will probably take quite some time still. Imo the worst timing risk here is that Pectra ends up split into two parts, and that 7702 won’t be ready for the first part, so will end up having to wait an additional 4 months or so. + +Julian Rachman +- Do you refer to the pre-matt proposal version? + +i wish we could have pre-matt’s proposal version but have come around to be ok with matt’s proposal + +Ivo Georgiev | Ambire +- Unless im missing something, temporary authorizations would be quite limited in terms of UX + +You send one txn to set a delegation, so that you can then benefit from SCA features for one transaction + +Sounds like something that will never be used in the wild + +Ivo Georgiev | Ambire +- Yes but you send one txn which isn’t sponsored or batched to get +one that is? Sounds convoluted since many batches will be no more than 2 calls in the first place +The sponsoring is even more convoluted +I’m talking about temporary one time delegations ofc + +Richard Meissner +- would this then be like a new param in this EIP, the expected tx.origin? + +Arik +- Is it possible to make the “griefing” use case too expensive to be efficient? + +Ansgar Dietrichs +- I don’t think restricting to a specific 7702 tx sender would be the right approach, that way it would be incompatible with 4337 + +Ansgar Dietrichs +- at least with the public 4337 mempool + +Richard Meissner +- could be optional xD (this is more a joke) + +Matt +- The hard thing is we have too many people with different requirements' + +Richard Meissner +- Do we have a summary on what we align on so far? Or at least 2 options that we have to decide between? + +Yoav +- not in favor of temp delegation, if we still want to mitigate the issue raised by Ansgar, it will become possible for 4337 to better use. + +Ansgar +- how will you handle different cases, seems difficult + +Yoav +- agreed +- maybe we don't need a temporary delegation. + +Sam +- Unless you're running initcode, you don't get to revert before your code is deployed + +Richard Meissner +- Just to understand the emulation: it would still have a delegation set and therefore behave different to an EOA when being called (or being the target of the EXT* methods), right? + +kvn +- I don’t think we answered what would be the behavior of delegated accounts without the authorization in the transaction (having another list like access_list basically was mentioned ?) and in the context of transaction type < 3 ? + +Sam +- Wouldn't it be a self-destruct? + +Yoav +- if used during a tx, and says now it is becoming validated, it could work. +- It is hard to think of all the scenarios. + +Matt +- we can’t use the storage +- the protocol should not touch the user space storage + +Kevin +- we kind of changed the opinion on that, but I understand. + + +Ahmad Mazen Bitar +- I dont think client teams will go to change this on devnet1. We already finalized devnet 1 spec + +lightclient +- agreed, this would really be for devnet 2 + +Ansgar Dietrichs +- what is devnet 2 timing? would we have to decide on the spec to use by next acde? + +Nicolas +- let's go for last round of for and against +- dev and researcher thinks this is + +Richard M +- might be helpful to go one more time +- we don't allow temp delegation +- will be dependent on nonce + + +Ansgar +- we seem to mostly align with Matt's proposal as the next step +- we can explore my proposal as conceptually the extension of Matt's idea +- my qn- do we have people on the call who strongly oppose matt's or my proposal as matt's extension? + +Ivo +- I am **opposing temporary delegation** +- there are various AA cases where it works better +- eg. for batching + + +Sam +- If the delegation target is stored in code and you can change your delegation target, then you can mutate your account's code. + +Julian Rachman +- I mean it would be wrong to not say that I do like the flexibility of pre-matt 7702. + +BUT I bias towards matt 7702 because we would be WAY worse off having this fall out in the worst case (knock on wood). The ethos for what 7702 is trying to do is still there and we want the ethos to be something we push into Pectra. + +Richard Meissner +- I also find the idea of Sam interesting to utilize self destruct to reset delegation. + +Ansgar +- with original 7702, it was also the sace +- my extension of this was conceptually more permanent and advantageous + +Richard +- with intrspection, I agree the changes of behaviour. With Proxys we already have a way to look into. +- I like the one time allowing because if it is revert, you have to create a new authorization to reactivate again +- Selfdestruct by itself will be interesting, but unsure if it is going against the isead of deprecating self destruct. + +Arik +- I disagree with the statement regarding the batching use case - but it’s probably not worth the discussion here. 2 signatures that run an atomic 2-action code is not the same as 2 signatures that run two separate pieces of code. + +But again - this is not the main point in this discussion + +Sam +- are we not planning to remove the self destruct even in the same tx + +Ansgar +- as per Vitalik's proposal - yes + +### Next steps +Nicolas +- People are aligned to see Matt's proposal in the next devnet +- it is devnet and we will take it from there. +- will explore more in the next stages. + +Matt +- thanks for the feedback +- will try to merge early next week +- if any different idea is emerged may merge by the next ACD + + + diff --git a/Breakout-Room-Meetings/FutureEOA-AA/Meeting 06.md b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 06.md new file mode 100644 index 00000000..df1c0668 --- /dev/null +++ b/Breakout-Room-Meetings/FutureEOA-AA/Meeting 06.md @@ -0,0 +1,683 @@ +Future of EOA/AA Breakout Room #6 +-- + +## Info +**Date**: July 31 2024, 14:00-15:00 UTC + +**Agenda**: https://github.com/ethereum/pm/issues/1118 + +**Recording**: https://www.youtube.com/watch?v=Oct83bBp3Z8 + +**Summary/Next steps**: +- Migration off the table for EIP-7702. Could be proposed as a separate EIP. +- Not enough support for storage change, should be looked as a separate proposal. +- Keep EIP-7702 as slim as possible to include in Pectra, include the [PR](https://github.com/ethereum/EIPs/pull/8775) in latest specs. + +**Links**: +* [Update EIP-7702: Proxy the storage of a delegation to its unique deleterminstic keys](https://github.com/ethereum/EIPs/pull/8762) +* [[EIP-7702] The Rubber Stamp-ening](https://hackmd.io/@otim/BkUQJ5RdA) +* [`CODERESET` for EIP 7702](https://hackmd.io/@S9AwbucvTS6GYodLz-G1SQ/S102UtTwA) + + +(Notes+zoom chat) + +Nicolas: Initiated the call. +- Going to discuss the latest change requests and hopefully by the end of this call we have some decisions for ACD call. +- Lightclient give us a quick update + +Vitalik: In a state with couple of proposed changes +- it keeps increasing based on ongoing discussion. There is a strong desire to get to a point where we decide on Finality on spec. +- About a week ago, Vitalik suggested breakout to discuss different ideas around. +- And discuss the proposal to replace the current design +- Ideas + - Code reset opcode + - adjusting the storage opcode + - and more +- We can talk about the underline philosophy + +Ankit+1 +- we wrote the document on code reset +- it is at the last mile and making suggested changes +- A workshop posted by wallet connect folks +- Ephimeral vs non-ephimeral +- Shared the screen to share the [doc](https://hackmd.io/@S9AwbucvTS6GYodLz-G1SQ/S102UtTwA) +- Discussing mitigations doesn't feel very strong at this point +- Focusing on suggested changes make more sense + +Ansgar Dietrichs (Jul 31, 2024, 10:05 AM) +to push back on Vitalik a bit, to me it feels like there are simply still remaining open questions, I don’t have high confidence that we are in a good place to pick the final shape of the EIP yet + +Ahmad Bitar (Jul 31, 2024, 10:07 AM) +I disagree, I feel like the EIP in its current shape is actually enough and covers most of the concerns. +It does feel that the remaining concerns can be mitigated by certain patterns or actions + +Ansgar Dietrichs (Jul 31, 2024, 10:08 AM) +I think I said that on the last call, but CODERESET seems like the wrong direction to me. we decided early on in the process that 7702 was not supposed to ship with permanent upgrade capabilities, and this idea would introduce such permanent upgrades through the backdoor + +Ansgar Dietrichs (Jul 31, 2024, 10:09 AM) +although I will admit that the additional capabilities look nice. but it should be its own separate EIP then, not piggybacking off of this one that has a very different focus + +Ansgar: +- looks like interesting feature but I am opposed for it to be in 7702 because the proposed change we considered this initally out of scope. +- it can be good feature to have in the future but no reason to combine this with 7702 + +Ankit+1: I agree, this is a deviation if the EIP isn't intended to acheive the goal. + +Arik: +- the entire idea with 3074 moving on to 7702 is to align a lot of things which were not aligened with EOA, will be addressed. +- As soon as we have those capabilities with 7702, we would be building smarter wallet and contracts to allow the better UX experience be widely adapted. +- want to raise as the question is the ability to build code or save the code for future txs. + + +Vitalik: +- unless in a way Self Destruct already work + +Arik (Jul 31, 2024, 10:12 AM) +What if the CODERESET is added alone, just as a way to make a cheap/1-time delegation? Without making the change that disallows EOA transactions? + +Julian Rachman (Jul 31, 2024, 10:14 AM) +You still have unlocked functionality even if the pk is the master key. I believe safe asked for more concrete reasonings from wallet providers + +Sachin Tomar (Jul 31, 2024, 10:14 AM) +“the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce” +Can this new target be ZERO_ADDRESS to remove the code from an EOA? + +Elias Tazartes (Jul 31, 2024, 10:16 AM) +we are designing an EIP that is scheduled for inclusion, it feels a bit bad no? how much sunk cost can we bear as a governance body + +Arik (Jul 31, 2024, 10:17 AM) +Sorry Derek didn’t see you were earlier 🙏 + +Ivo Georgiev | Ambire (Jul 31, 2024, 10:17 AM) +There’s very little use case for one txn delegation, if not none. + +Gas sponsorships are pointless because you need an eoa txn first, same goes for batching + +So I can’t imagine any useful one transaction delegation use case + + +Darek (Wallet Connect) +- I agree with many people including Arik +- I talked to a bunch of wallets, Trust is a special case but other than that adoption of 7702, ephimeral case for 7702 makes it easier migration path to wallet +- In favor of 7702 in its current form + +Ahmad +- Designation delegation fixed most of the problems, but received comments that some wallet dont like that. +- there is always a spec which is going to be the best for most but won't work for some. +- Code reset is not the way to go because it provided the ability inside EVM and not the wallet +- in the last discossion, ansgar mentioned of DOS vector, may want to touch on that. + + +Arik (Jul 31, 2024, 10:19 AM) +reduced risk = functionality + +Ansgar Dietrichs (Jul 31, 2024, 10:20 AM) +which exact version does ephemeral storage refer to? + +vub (Jul 31, 2024, 10:19 AM) +Do we need a new opcode for CODERESET, or is this a small tweak to the functionality of SELFDESTRUCT? + +Julian Rachman (Jul 31, 2024, 10:20 AM) +a flag be added to the 7702 transaction’s `authorization_list` that would designate it as ephemeral, clearing the code hash at the end of the execution + +Nicolas: +- any strong opinion on this? + +David(Trust Wallet) +- Code reset will be useful +- batch sponsorship will be done by 7702, but many wallets need to handle key mgmt. +- beside institutional functionality, we want to unlock some validation related features. + + +persistnace doesn't has to be in EOA's own storage + +Ahmad Bitar (Jul 31, 2024, 10:22 AM) +7702 is not supposed to be the EIP to fix it all + +Sachin Tomar (Jul 31, 2024, 10:14 AM) +“the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce” +Can this new target be ZERO_ADDRESS to remove the code from an EOA? + +Ronny Panford (Jul 31, 2024, 10:23 AM) +I guess the concern is not allowing the signing key to ultimately reset the account at any time be it by pointing to ZERO_ADDRESS or null bytes. To help create credible smart accounts. Thats why CODERESET only in the contract code, is what I understand, but this opens new gate ways of concern todetermine malicious use of CODERESET. But I agree crafting this solution might be too late for 7702. + +Ankit+1: +- EOA can move contracts away +- A question is to whom we want to delegate what job +- one concern - why making pvt key available to root user +- we need to educate the user +- Even the wallet don't understand the current spec, it will be difficult to expect from the users. +- Educating user the users will be useful +- Over 99% tx on mainnet do not have TVL + + +lightclient (Jul 31, 2024, 10:24 AM) +you were never supposed to get security of smart contract wallets + +derek (Jul 31, 2024, 10:24 AM) +@Derek could you type out here again why some wallets you talked to felt that 7702 in its current form wouldn’t be widely adopted? I didn’t completely catch your point + +Ahmad Bitar (Jul 31, 2024, 10:24 AM) +7702 was not aimed to fix this + +Ahmad Bitar (Jul 31, 2024, 10:24 AM) +7702 was not aimed to fix this + +lightclient (Jul 31, 2024, 10:24 AM) +where have you been the past year? + +Julian Rachman (Jul 31, 2024, 10:24 AM) +Does that really create a new account though? It is just an eoa with smart functionality + +Sudeep | Erigon (Jul 31, 2024, 10:24 AM) +I think the feedback from wallet teams was the opposite some time back — an account should be able to act as both EOA and SCA — so that the apps which EOA interact with continue working; and then SCA based functionalities/dapps can be optionally interacted with (and slowly transitioned to). + +gajinder (Jul 31, 2024, 10:18 AM) +ephemeral storage takes away none of the functionality and reduces complexity + +Ansgar Dietrichs (Jul 31, 2024, 10:25 AM) +ah. then I would just ban storage within 7702 accounts completely, instead of turning it ephemeral. but we discussed this a few months ago - the feeling was that it would be better to have decisions mirror the 4337 situation + +Ansgar Dietrichs (Jul 31, 2024, 10:25 AM) +so rather keep storage enabled, because changing implementations is already a problem that the 4337 ecosystem has to solve. otherwise we end up with 2 separate tech stacks again + +gajinder (Jul 31, 2024, 10:26 AM) +or this PR: https://github.com/ethereum/EIPs/pull/8762 + +Francisco (Jul 31, 2024, 10:26 AM) +7702 is not migration, education should start by avoiding that term + +Ivo Georgiev | Ambire (Jul 31, 2024, 10:26 AM) +Also please let’s not forget the signature complications from the concept of converting EOAs to real smart accounts + +ankitchiplunkar (Jul 31, 2024, 10:27 AM) +https://hackmd.io/-V7ywDDZRDKrXMRRkulOpQ?view + +Matt: +- ENS is at risk +- I took a random token and found that at risk +- I think ENS with billion dollars is at risk and I won't do that to put it on risk + +Aniket+1 +- there are two tokens are at risk + +Jochem (EthJS) (Jul 31, 2024, 10:28 AM) +What is the ENS risk? Someone has a description of this problem? + +Ahmad Bitar (Jul 31, 2024, 10:29 AM) +the idea is that, if the EOA key is leaked somehow, then the assets are still secure if the migration to sca is final +but looking at ENS token for example, you find this to be un true + +lightclient (Jul 31, 2024, 10:29 AM) +ENS doesn’t support 1271 so a EOA pk can spend the funds even if EOA is migrated + +Sudeep | Erigon (Jul 31, 2024, 10:24 AM) +I think the feedback from wallet teams was the opposite some time back — an account should be able to act as both EOA and SCA — so that the apps which EOA interact with continue working; and then SCA based functionalities/dapps can be optionally interacted with (and slowly transitioned to). + +Ahmed Al-Balaghi (Jul 31, 2024, 10:29 AM) +“wallets don’t like eoa retaining root access” is def over exaggerated < why do you think so? + + +Aniket+1: +- shared screen to discuss alternate proposals +- with one proposal if user leak their pvt key + + +Matt +- there sare so many thing wrong with this comparision +- when people migrate to smart contract wallet, they expect Smart contract wallet to secure their fund. +- A true smart contract wallet will be in position to secure them +- It will be difficult to educate every retail users about the security consideration. + + +Julian Rachman (Jul 31, 2024, 10:31 AM) +That is a reallllly binary questioning + +derek (Jul 31, 2024, 10:31 AM) +I don’t think anyone is disputing that by permanently migrating the EOA, the impact of leaking the key gets lower. But that’s not considering all the other factors + +Ansgar Dietrichs (Jul 31, 2024, 10:31 AM) +my personal 7702 wish list: +make it fully ephemeral: store delegation target, but turned off by default. 7702 txs manually enable delegation for a list of addresses +change code read behavior to not return delegation target code +(maybe) add initcode behavior, running at the beginning of a 7702 tx with separate gas limit + +Derek (Jul 31, 2024, 10:31 AM) +SCA based functionalities/dapps + +what exactly is that? `atomic batch transactions` and `dapp sponsored` / `erc20 paid` transactions? + +Ivo Georgiev | Ambire (Jul 31, 2024, 10:32 AM) +There’s more signature risk than just permits IMHO. Just taking any dapp login as an example that doesn’t support 1271 + +there are even dapps which support 1271 but verify ecrecover first or as a fallback 🤷‍♂️ + +Matt +- Let's simplify this for end users. +- the point of 7702 is not to migrate EOA + +Aniket+1: +- our intent was to add some features to enhance the present proposal + +Yoav +- concerned about EOA migration +- I like the change form protocol perspective. +- It has some security considration +- what the change does is alternating the account between EOA or smart wallet. Never both at any point of time. +- we need to decide one of the proposed change and write it to the security consideration + +Darek +- two points + - every one is aligned with the risk of migrating EOA + - it cant be done perfectly. + - there is no EOA migration proposal that address all risks + - people actually want to keep their EOA + - if people have to try out the features of smart contract, there is alternate ways to try + - that depends on the smart contract +- the third point is that we probably we can all agree that the most important thing is to ship this in Pectra +- or a slightly better proposal in the next upgrade. I prefer the Pectra. + +Pedro +- Nicely put. +- From my take, the current solution put account in an ambigous state +- we have the ability to revet back to EOA. + +lightclient (Jul 31, 2024, 10:40 AM) +we should move to the next topics, CODERESET isn’t going to be support by 7702 in pectra and there are other things ppl want to discuss + +Derek (Jul 31, 2024, 10:31 AM) +SCA based functionalities/dapps + +what exactly is that? `atomic batch transactions` and `dapp sponsored` / `erc20 paid` transactions? + +Sudeep | Erigon (Jul 31, 2024, 10:40 AM) +yes + +greg (Jul 31, 2024, 10:37 AM) +Does the current impl of 7702 have sstore + +greg (Jul 31, 2024, 10:42 AM) +Unless we want collisions you technically need it + +Yoav +- there are user's perspective and protocol perspective + +Pedro +- the pvt key should be secondary in this migration + +Ahmad Bitar (Jul 31, 2024, 10:43 AM) +it is a "delegation" and not "migration" + +Agus (Jul 31, 2024, 10:43 AM) +I don't think it's such a UX problem. Smart contract wallets are mostly presented as multisigs, so it can always be displayed as if the wallet has "one more key" that is not revocable + +Julian Rachman (Jul 31, 2024, 10:43 AM) +The vm and wallet interface lines are blurring...... + +greg (Jul 31, 2024, 10:37 AM) +Does the current impl of 7702 have sstore + +Ansgar Dietrichs (Jul 31, 2024, 10:43 AM) +the same is true for changing smart account implementations today. + +Pedro +- In theory it sounds good, but may not be in practical ways. + +Matt +- until we are able to do it in a nice way, we can do it at the protocol level +- there are other problems to be considered, but we need to focus on what it adds + +Darekn (Wallet Connect) +- Billion of dollars at risk - I still have to lose my pvt key for those funds to be at risk + +Matt +- Risk can not be fixed with 7702 +- we are just doing that EOA's can do execution txs. + +pedrogomes (Jul 31, 2024, 10:46 AM) +I would disagree simply because we the current proposal is halfway-migration but we are just renaming it to delegation + +Ansgar Dietrichs (Jul 31, 2024, 10:46 AM) +I am open to reopening the permanent upgrade conversation - but then we have to be okay with 7702 very possibly missing Pectra + +Ahmad Bitar (Jul 31, 2024, 10:47 AM) +i am not. if we want to open the permanent upgrade conversation, it can be in a totally different EIP than this one + +lightclient (Jul 31, 2024, 10:47 AM) +ephemeral setting doesn’t match with 4337 + + +Darek +- one wallet start using and another one doesn't then users may have issues. +- I suggest to keep it simpler for wallets. + +Vitalik: +- it feels to me that chances of getting consensus in time for pectra is Zero +- if we do 7702 (as is), it is still compatible for us to do migration latter +- so I think, for questions we get consesnus around but basically ask questions for full account migration (kick the can down solution) is not do that now, and continue to be open as long as some people care about it. +- May in long term people figure out how to do that. +- Does 7702 as is solve all the problems, if no then see if that can be updated with a new EIP in future? + +Matt +- It make sense +- I am not against EOA migration, but against this with 7702 + +Ahmad Bitar (Jul 31, 2024, 10:51 AM) +always depending on pay masters and bundlers to include my transactions is not something i want to do. I like the ability to use them without being forced to use them + +derek (Jul 31, 2024, 10:48 AM) +Why don’t we tackle permanent EOA migration in a separate EIP? As long as we are aligned that 7702 in its current form is a big value add, and is NOT incompatible with future EOA migration proposals, why don’t we move ahead with it for Pectra and tackle EOA migration in a separate proposal? + +As Ansgar said before, a permanent migration proposal completely changes the *character* of 7702 and should be considered a separate EIP + +derek (Jul 31, 2024, 10:51 AM) +The very reason why no EOA migration proposal has gained any traction, while 7702 did, is because 7702 is not attempting to do EOA migration… so trying to add EOA migration back to 7702 seems like a backwards move to me + +Stephane (Jul 31, 2024, 10:51 AM) +Is that the reason? + +Agus +- we rae discussing many dapps and tokens +- dapps may have to consider this fully in order to prevent vulnaribility +- At some point every single wallet will be smart contract wallet. + +Aniket+1 +- it's a good idea to separate out the migration concerns +- i think things to consider are the side effects +- i know some people will be disappointed that they are waiting on support for the migration + +I can only see power users wanting EOAs + +Ansgar Dietrichs (Jul 31, 2024, 10:53 AM) +side note: I still like the idea of exploring modifying ecrecover to check if there is code in the account associated with the recovered address, and throw if so. not sure if good idea, but worth exploring for full migration + +Ansgar Dietrichs (Jul 31, 2024, 10:55 AM) +for 3074, we even considered a variant where instead of throwing, ecrecover could call into the smart account to have it check the “signature” instead + +Ahmad Bitar (Jul 31, 2024, 10:53 AM) +So, we want to force users to migrate to sca by making sure the EOA experience is bad. I hate this argument 👎 + + + +Greg +- The fundamental thing to remember it took long to discuss 3074 +- we're not going to get everything +- get as slim as lean as we can to hold this to make EOA a little ahead of the curve and in the next year see what i sthe best way to move this forward. + +Agus (Jul 31, 2024, 10:56 AM) +we wouldn't be forcing users to migrate tho, we would be forcing dapp devs to account for smart contract wallets, the other way around + +Ahmad Bitar (Jul 31, 2024, 10:57 AM) +They have to, because they will want to support delegated accounts +delegated accounts will have the exact same features that SCAs will have beside security + +pedrogomes (Jul 31, 2024, 10:58 AM) +Delegated accounts is not a strong enough reason because they can still act as EOAs + +gajinder (Jul 31, 2024, 10:57 AM) ++1 with greg, we should just push for completion of 7702 rather than radically change it + +Eric +- pragmatic usage of 7702 - I'd love to see modification that would make it cheaper + + +lightclient (Jul 31, 2024, 10:58 AM) +**let’s take migration off the table once and for all** + +lightclient (Jul 31, 2024, 10:58 AM) +**should be a separate proposal** + +Greg +- where 7702 sits is not the dream but at least it gets the job done + +Yoav +- in future if we discuss we should have only one thing in +- since we are not using this form of mitigation. It should be mentioned in the Security consideration for the awareness of clients. + +Ansgar +open questions from authors pov +1. Exact ephimeral nature of delegation + - you turn it off default + - to me it feels safer to keep it off (default)in case of attacks +2. Code accesses + - to me seems very dangerous + - never be able to access the code to the delegation target +3. Init code + - In the past it wasn't considered + - it seems reasonable to potentially have init code in + +frangio (Jul 31, 2024, 11:04 AM) +is limiting to one transaction in mempool a problem eg. for UX? + +lightclient (Jul 31, 2024, 11:06 AM) +i don’t see why it would since the user would most likely be using a relayer if they’ve upgraded their account +but even if not, if they are self-relaying their account supports batching so no need for multiple txs pending + +lightclient (Jul 31, 2024, 11:07 AM) +if you run the initcode first, how do you determine how much gas was used to charge that user via a paymaster? + + +Ahmad +- response to Ansgar's 3 points +- I don't see the first as a concern +- for 2nd - I agree with Ansgar +- for 3rd - I know initializing the smart contract in current form is ugly but having init code may complicate it. + +Dror +- Regarding init code - the minimal we should add a very stron security consideration to the EIP. +- you must have a set of signature or you are vulnerable +- it is a call data at the begining and not the init code + + +gajinder (Jul 31, 2024, 11:09 AM) +can we also discuss : https://github.com/ethereum/EIPs/pull/8762 for storage colllision resolution + +Ansgar Dietrichs (Jul 31, 2024, 11:09 AM) +might be some confusion on what I meant with “ephemeral”. + +my question here was basically: +user sets delegation target in tx A. +in tx B, someone calls into their account. does the code run or not? (i.e. does it behave like an EOA or a smart account) + +Ahmad Bitar (Jul 31, 2024, 11:10 AM) +smart account +unless A resets the delegation + +Jochem (EthJS) (Jul 31, 2024, 11:10 AM) +Frontrun could be mitigated by adding ORIGIN to the authority lists: https://github.com/ethereum/EIPs/pull/8763 (but this depends upon the situation) + +lightclient (Jul 31, 2024, 11:10 AM) +this isn’t needed, just use a sig from the account + +Jochem (EthJS) (Jul 31, 2024, 11:11 AM) +So in that case you can ensure that a specific ORIGIN will send your tx and other EOAs cannot "steal" / frontrun your tx by either replacing another code, or setting code before your tx and performing arbitrary code execution (assuming that the delegated contract has no entry guards to check callers) + +Ansgar Dietrichs (Jul 31, 2024, 11:12 AM) +the idea would be that all 4337 bundles would be 7702 txs in the future + +Jochem (EthJS) (Jul 31, 2024, 11:10 AM) +Frontrun could be mitigated by adding ORIGIN to the authority lists: https://github.com/ethereum/EIPs/pull/8763 (but this depends upon the situation) + +gajinder (Jul 31, 2024, 11:14 AM) +this is wallet side providing security post delegation, above Jochem's is user side, both are different + +Ahmad Bitar (Jul 31, 2024, 11:14 AM) +Yeah, i was saying someone can copy the delegation from previous 7702 tx and include in a new one. if the nonce is still valid or the delegation had no nonce, then the problem is not solved. thus, i am not seeing how the ephemeral idea fixes this + +lightclient (Jul 31, 2024, 11:15 AM) +to be clear it isn’t really initcode? +it’s calldata into the account they’re proposing? + +Yoav +- I'd prefer call data +- but init code more consistent + +Matt: what is the flow + +Yoav +- You set the code that allow to work atomatically + +Wallet developers agrees to keep it simple + +Dror +- I understand the complexities to add any such data. + +Matt +- No problem adding security considertaion + +Ansgar Dietrichs (Jul 31, 2024, 11:22 AM) +only a wallet could make the mistake of whitelisting a non-7702 contract + +Ivo Georgiev | Ambire (Jul 31, 2024, 11:22 AM) +We’ve worked around the initialization issue and we don’t use a setup function so that’s what makes things easier for us + +I could be misunderstanding this a bit but still two implementations is not a big sacrifice in our case + +Arik (Jul 31, 2024, 11:22 AM) +It would be useful to be able to use the most proven smart contract wallet in the space… + +frangio (Jul 31, 2024, 11:22 AM) +regarding gas metering for init calldata why wouldn't the user just specify an exact amount of gas and pay for that + +Arik (Jul 31, 2024, 11:22 AM) +But feels like we need Safe on the call for this + +lightclient (Jul 31, 2024, 11:23 AM) +i think ppl want to discuss storage + +Gajinder +- I have put up a [PR](https://github.com/ethereum/EIPs/pull/8762/files) +- it is also compliant to the verkle implementation +- this will solve the problem of conflict +- I think it is worth to include + +Matt +- not with 7702 +- it may restrict some of the changes for EOA and smart contract wallet +- this is not a protocol problem but a implementation problem + +Ansgar Dietrichs (Jul 31, 2024, 11:24 AM) +I don’t love collision avoidance solutions that are specific to 7702, because the long-term future of smart accounts will not be 7702-based + +Yoav (Jul 31, 2024, 11:25 AM) +I agree, we should have the same solution for both account types. + + +Gajinder +- want to hear other opinions + +Ahmad +- since we have whitelist of designations +- Ahmad Bitar (Jul 31, 2024, 11:27 AM) +we can have the user clear the storage from the old wallet using the old wallet interface before migrating to the new one if aconflict could arise + +Matt: +- **not enough support for storage change, should be looked as a separate proposal** + +Vitalik +- the bars for changes in 7702 is difficult to get out from and will be considered as separate EIPs +- it feels like, in general there is no consensus on status quo (have to hear again) +- we are not rubberstamping 7702 as is but pretty close and is progress + + +Eric +- everybody feels that the next iteration will be in next 2 years +- will be nice to have some space in future forks + +We still dont have proper tests. clients forked a lot in devnet-1 because of 7702 transactions + +Matthew Smith (Jul 31, 2024, 11:28 AM) +matt's proposal is extremely well thought out. just a few minor points to clear up. let's ship it + +Ansgar Dietrichs (Jul 31, 2024, 11:29 AM) +I still feel very strongly about code reads. I think the current spec is a clear mistake there, and would really like to see changes + +Ansgar Dietrichs (Jul 31, 2024, 11:30 AM) +all my other proposed changes are more preferences, where I am happy to stick with the current spec instead. + +Ahmad Bitar (Jul 31, 2024, 11:30 AM) +Agree + +Ahmad +- Code read +- in EOF we usually try to avoid any code read, copy exit code, hash exit code, size. Basically it's Code introspection and here it does not make sense to me to allow code introspection into the EOA's delegated account. +- My preference will be to have these specific code return the normal thing that they'd usually return for an EOA and we can simply add that to the EIP? +- what matt and other client implementers think of this? + + +Yoav +- one argument against is there are already contract that make it deliberate to not communicate anything related to account abstraction but to only serve EOAs. + +Ahmad +- so we can keep it for non-EOF + +Yoav +- yes + +Ahmad +- make sense to me + +Ansgar Dietrichs (Jul 31, 2024, 11:32 AM) +there are 4 options imo: +behave like an EOA +return the raw code, i.e. the delegation format +behave EOF-like, return “0xEF” +current spec, return delegation target code + +andrei (Jul 31, 2024, 11:33 AM) +current spec + allow to delegate to EOF only + +Ahmad Bitar (Jul 31, 2024, 11:34 AM) +I actually like that + +lightclient (Jul 31, 2024, 11:34 AM) +i think we should let pectra get a bit farther down the line, but yeah in a few months would be down to also do this + +dror (Jul 31, 2024, 11:34 AM) +re: initcode: +Without initcode, we're not allowed to use existing deployed contract code, and t should be mentioned in the EIP's security consideration + +Specifically, we can't use a contract code that relies on storage initialization, since any "setup" function is not protected by the "authorizer" signature (unless it performs "require address(this)==ecrecover(something)" + +E.g. In the current design, signing an "authority" to use Safe's masterCopy as your account makes this transaction front-runnable, and someone could frontrun with a different setup and take over the account. + +The same goes for any existing contract code, including any ERC4337 modular framework. + +Arik (Jul 31, 2024, 11:36 AM) +I do think it’s something that is unfortunate - there is a lot of value with using “lindy” smart contracts… + +Ansgar Dietrichs (Jul 31, 2024, 11:36 AM) +I think most people already left, we should not discuss this now +(even though I tend to agree with dror on this) + +Ansgar +- I wrote the alternative options in chat + +Yoav +- do you see anyone using this method? + +Ansgar +- it is unpleasent that we have to make these assumptions +- I am talking conseptually it doens't see the right thing to do + + +Yoav +- we should spend some time looking into it + + +Dror +- Observation regarding Initialization code - you can only allow monolithinc account that requires set up + +Matt +- you can modify +- just set up master controller + +Frangio +- Code will be reenabled +- a discussion to be had and make a decision + +Nico +- keep it as small as possible in pectra +- future improvements in separate EIPs. + + From 7dd879f4dd52ba62a604eb87f5bca6093738c6df Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 24 Dec 2024 22:11:26 -0500 Subject: [PATCH 32/51] Update FutureEOA-AA-pm.md Included notes for meetings 3-6 --- Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md b/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md index c38cc5f5..0e71bf60 100644 --- a/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md +++ b/Breakout-Room-Meetings/FutureEOA-AA/FutureEOA-AA-pm.md @@ -5,9 +5,9 @@ | # | Date | Agenda | Recording | Notes | | -- | --| -- | -- | -- | -|6| July 31, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1118) | [Recording](https://youtu.be/Oct83bBp3Z8) | [Notes] -|5| June 26, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1081) | [Recording](https://youtu.be/_S01TtA3lao) | [Notes] -|4| June 05, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1054) | [Recording](https://youtu.be/gsc_yTdHRig) | [Notes] -|3| May 29, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1053) | [Recording](https://youtu.be/0vHHhZgrJ58) | [Notes] +|6| July 31, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1118) | [Recording](https://youtu.be/Oct83bBp3Z8) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/FutureEOA-AA/Meeting%2006.md) +|5| June 26, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1081) | [Recording](https://youtu.be/_S01TtA3lao) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/FutureEOA-AA/Meeting%2005.md) +|4| June 05, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1054) | [Recording](https://youtu.be/gsc_yTdHRig) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/FutureEOA-AA/Meeting%2004.md) +|3| May 29, 2024 |[Agenda](https://github.com/ethereum/pm/issues/1053) | [Recording](https://youtu.be/0vHHhZgrJ58) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/FutureEOA-AA/Meeting%2003.md) |2| May 07, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1032) | [Recording](https://youtu.be/GPdbQxmsXR8) | [Notes] | |1| Feb 28, 2024 | [Agenda](https://github.com/ethereum/pm/issues/962) | [Recording](https://www.youtube.com/watch?v=FfEZdTFAz4E) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/FutureEOA-AA/Meeting%2001.md) | From 6392792574cc341b1b8ab6b04f3c4c840cfda9c5 Mon Sep 17 00:00:00 2001 From: Viktor Pavlik <160131789+Vikt0rPavlik@users.noreply.github.com> Date: Wed, 25 Dec 2024 17:57:52 +0100 Subject: [PATCH 33/51] Update baikal.md --- Network-Upgrade-Archive/London/baikal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Network-Upgrade-Archive/London/baikal.md b/Network-Upgrade-Archive/London/baikal.md index ea879ea9..99b1b222 100644 --- a/Network-Upgrade-Archive/London/baikal.md +++ b/Network-Upgrade-Archive/London/baikal.md @@ -2,7 +2,7 @@ **Disclaimer: This network will soon be shut down in favor of [Calaveras](/network-upgrades/client-integration-testnets/calaveras.md).** -The specification for the Baikal Client Integration Tesnet. Clients who wish to sync need to implement the following features into their client. It is for testing basic infrastructure and will be deprecated. +The specification for the Baikal Client Integration Testnet. Clients who wish to sync need to implement the following features into their client. It is for testing basic infrastructure and will be deprecated. ## Specification From 3ab6ad05bd6e959f5547ebb4baa32f49ae2e7e5a Mon Sep 17 00:00:00 2001 From: Viktor Pavlik <160131789+Vikt0rPavlik@users.noreply.github.com> Date: Wed, 25 Dec 2024 18:06:26 +0100 Subject: [PATCH 34/51] Update call_088.md --- AllCoreDevs-CL-Meetings/call_088.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AllCoreDevs-CL-Meetings/call_088.md b/AllCoreDevs-CL-Meetings/call_088.md index a43c1db6..a07a0dda 100644 --- a/AllCoreDevs-CL-Meetings/call_088.md +++ b/AllCoreDevs-CL-Meetings/call_088.md @@ -38,7 +38,7 @@ **Danny:** [yeah](https://www.youtube.com/watch?v=4oI48BEijVw&t=495) I think probably all in agreement on that okay so when um perry gets back we'll propose a date and a config that'll be approximately in the next couple of weeks and get it up the I think the validator set size is going to be on the order of a couple thousand and permissioned okay any other things on would that be the secant chain terence I think i'm in charge of naming beacon chains -**Ben:** [can](https://www.youtube.com/watch?v=4oI48BEijVw&t=530) I just clarify not on naming um have we decided gurley um prata merge before sepolio or sipolia first because i've heard both recently yeah +**Ben:** [can](https://www.youtube.com/watch?v=4oI48BEijVw&t=530) I just clarify not on naming um have we decided goerli um prata merge before sepolio or sipolia first because i've heard both recently yeah **Tim:** [so](https://www.youtube.com/watch?v=4oI48BEijVw&t=554) the rough feeling that I had was we would do gordy first and the reason there was um we will get more like data out of gordy because it's like a network with more activity there's more people running validators on prater um and I think maybe the the only argument I could see for doing sepolia first if we if we did is like if we do sepolia perhaps like when we're not quite ready when we don't have code that's like quite ready for mainnet but we do want to get another test that run in somehow um and and because it feels like gordy what goes on gordy should probably be like extremely close to what goes on mainnet because it's like what most users will use um and and test on so that's like the only reason I could seem to do support before is if we want another run on a test net with stuff that's maybe not quite ready to find that yet From ab358fc74918d1c857746685c546a5a4054bbf7a Mon Sep 17 00:00:00 2001 From: Viktor Pavlik <160131789+Vikt0rPavlik@users.noreply.github.com> Date: Wed, 25 Dec 2024 18:07:16 +0100 Subject: [PATCH 35/51] Update Meeting 115.md --- AllCoreDevs-EL-Meetings/Meeting 115.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AllCoreDevs-EL-Meetings/Meeting 115.md b/AllCoreDevs-EL-Meetings/Meeting 115.md index a2d07a27..32841b98 100644 --- a/AllCoreDevs-EL-Meetings/Meeting 115.md +++ b/AllCoreDevs-EL-Meetings/Meeting 115.md @@ -534,7 +534,7 @@ okay so that's what you mean that it might have been planned like a launch long- **Martin** -* so ropston and gurley are both multi-client testnets and currently are there any other clients can get that does ranking +* so ropston and goerli are both multi-client testnets and currently are there any other clients can get that does ranking **Tomasz** From 7cf552013816e1eb62451473e5fb39ab88557d46 Mon Sep 17 00:00:00 2001 From: Viktor Pavlik <160131789+Vikt0rPavlik@users.noreply.github.com> Date: Wed, 25 Dec 2024 18:07:54 +0100 Subject: [PATCH 36/51] Update CommunityCall_Meeting_05.md --- Network-Upgrade-Archive/Merge/CommunityCall_Meeting_05.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Network-Upgrade-Archive/Merge/CommunityCall_Meeting_05.md b/Network-Upgrade-Archive/Merge/CommunityCall_Meeting_05.md index 7375d712..3a919e2b 100644 --- a/Network-Upgrade-Archive/Merge/CommunityCall_Meeting_05.md +++ b/Network-Upgrade-Archive/Merge/CommunityCall_Meeting_05.md @@ -82,7 +82,7 @@ **Danny:** currently all clients utilize this engine api uh so the question is um is it requisite that you use the engineering api or are there alternatives so there's the kind of the core specs the core specs tell you the state transition they tell you how to talk on the network and that kind of stuff but they don't really tell you about client architecture the engine api is to facilitate a particular type of client architecture and this client architecture the reason that it exists and the reason that it's so pervasive is that the kind of history of there being these clients that are really good and specialized on transactions and evm execution and and that kind of stuff those are the execution layer clients we have these clients and pieces of software that are very specialized at managing the beacon chain managing proof of stake validators balances bls signatures all that kind of stuff and so it's very natural to unify these pieces of software over an interface and that is the engine api that historically is very natural it also would be very natural to look at all these specs and write one big piece of software and call it a client and so the engine api does not preclude that from happening but there is not currently from my knowledge even a project that's very actively pursuing this i know that nimbus does have a very nascent execution layer client and they're considering doing an integrated build with an optional engine api if you don't want to use um one side of the or the other and you know any any piece of any domain that does have clients on both side of the aisle in the same language people might experiment with that in the future but right now 100 of the production clients are utilizing this engine api thing question about the dos post for proposers yeah so validators leak information they make a lot of messages and um it is very likely possible to reverse engineer where the or you know the origin of those messages with respect to ip and kind of figure out where validators live on nodes and then some of these roles especially the proposal role is known in advance so the concern would be that you could actively dos targeted boss proposers there are a couple of so yes this is possible it's certainly possible um and then there are engineering and kind of like the way nodes are set up mitigations and then there are uh protocol mitigations so in the event that this happened if it happened um home stakers would probably scramble to utilize more advanced setups to help get around this um and i know there's some people working on even better mitigations allowed in clients like i think lighthouse is enabling a kind of a century-node architecture some people are experimenting with how to use openvpn and rotate vpns to allow to help prevent dos and other things like that so more like practical mitigations in the event that this happened uh that would you would certainly see kind of a scramble to get the practical mitigations out there are also other kind of protocol mitigations like single secret leader elections so instead of um that proposer being known in advance the proposer knows in advance but everyone else doesn't know and that proposer then makes a proof when they make their block um this is very under very active development uh but it's hard to say when exactly it would come out to mainnet it's kind of one of those like security features that is always competing with user features so it's like okay do we enhance the security of the protocol or do we get out charting or something like that there's there's kind of always a careful balance between those two types of things additionally there's research into more private networking components so imagine land leveraging certain uh types of network constructions like dandelion plus plus where you um pass messages around secretly before they kind of enter into the network and so it's not clear who the origin the message was -**Trent:** so there's a lot of good research paths along that way but there's also a lot of good practical mitigations um that'll be leveraged in the event of attack we are at time um thank you everybody for joining uh tim you have any like final things that you want to go over i would say if you're so if you're a validator um being on this call is great but if you haven't participated in any test nets and you're currently running validators for the beacon chain you need to participate in gurley don't run your setup on the the main net merge without having participated in a test net merge this is i don't know how to how else i can stress this but you should test your stuff before we go to mainnet um it's coming soon and it will be here sooner than you expect uh if you're not paying attention and trying to trying to test your stuff ahead of time um that was i just wanted to stress that again um if you're a minor part of the mining community please pass this to them i know the merge has been a long time coming it's been a long journey to get here but um it's it's very close if you're a part of a mining community just please be aware of this i think enough of this has trickled out to those communities that it's you know commonly understood to be close but can't hurt to remind people so yeah validators please please test your setups on the existing test nets and the upcoming merge transition and um try to try to dig into the literature that people have made available this stuff that's linked in the in the agenda and you won't regret it and sign up for the um sign up for the google group that's where you're going to get updates follow the ethereum blog emerges soon anything final time oh that sounds great thank you everybody again for joining and for the people that answered questions in the chat and asked questions uh really appreciate it we'll see everyone for the next community call uh maybe in a couple weeks ish we'll see how it goes but again we'll announce it uh ahead of time all right thanks everyone good have a good rest of your day wherever you are +**Trent:** so there's a lot of good research paths along that way but there's also a lot of good practical mitigations um that'll be leveraged in the event of attack we are at time um thank you everybody for joining uh tim you have any like final things that you want to go over i would say if you're so if you're a validator um being on this call is great but if you haven't participated in any test nets and you're currently running validators for the beacon chain you need to participate in goerli don't run your setup on the the main net merge without having participated in a test net merge this is i don't know how to how else i can stress this but you should test your stuff before we go to mainnet um it's coming soon and it will be here sooner than you expect uh if you're not paying attention and trying to trying to test your stuff ahead of time um that was i just wanted to stress that again um if you're a minor part of the mining community please pass this to them i know the merge has been a long time coming it's been a long journey to get here but um it's it's very close if you're a part of a mining community just please be aware of this i think enough of this has trickled out to those communities that it's you know commonly understood to be close but can't hurt to remind people so yeah validators please please test your setups on the existing test nets and the upcoming merge transition and um try to try to dig into the literature that people have made available this stuff that's linked in the in the agenda and you won't regret it and sign up for the um sign up for the google group that's where you're going to get updates follow the ethereum blog emerges soon anything final time oh that sounds great thank you everybody again for joining and for the people that answered questions in the chat and asked questions uh really appreciate it we'll see everyone for the next community call uh maybe in a couple weeks ish we'll see how it goes but again we'll announce it uh ahead of time all right thanks everyone good have a good rest of your day wherever you are From 979808ea57ad3a22b0eba47a718b3c9b73d510ec Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 10:52:39 -0500 Subject: [PATCH 37/51] Verkle meetings 23 & 24 --- Breakout-Room-Meetings/Verkle/Meeting 23.md | 55 +++++++++++++++ Breakout-Room-Meetings/Verkle/Meeting 24.md | 74 +++++++++++++++++++++ 2 files changed, 129 insertions(+) create mode 100644 Breakout-Room-Meetings/Verkle/Meeting 23.md create mode 100644 Breakout-Room-Meetings/Verkle/Meeting 24.md diff --git a/Breakout-Room-Meetings/Verkle/Meeting 23.md b/Breakout-Room-Meetings/Verkle/Meeting 23.md new file mode 100644 index 00000000..383a80ab --- /dev/null +++ b/Breakout-Room-Meetings/Verkle/Meeting 23.md @@ -0,0 +1,55 @@ +# Verkle Call #23 +## Info +Note: This file was copied from here: https://notes.ethereum.org/@rudolf/sic-notes#Call-23-August-26-2024 + +Date: August 26, 2024 + +Recording: https://www.youtube.com/watch?v=VD0P3RkhIjY + +Agenda: https://github.com/ethereum/pm/issues/1121 + +## Notes + +## 1. Team updates + +ignaciohagopian and gballet for go_ethereum: making solid progress on testing and the upcoming testnet. Managed to get the branch with latest gas schedule working with tests. + +jasoriatanishq for nethermindeth: have implemented everything for the testnet. Also working on a few cryptography improvements, and a big refactor to implement the transition. Might be able to implement test transition in next few weeks. + +kt2am1990 for HyperledgerBesu: working on modifying how we save data in the DB, to implement a flat DB based on the stem of the tree. Also working on gas cost implementation and the transition. + +GabRocheleau for EFJavaScript: ready with all the gas cost updates, likewise just waiting for test vectors to confirm. + +Somnath for ErigonEth: getting caught up with the changes up to the most recent testnet. Had an issue when trying to connect to peers on testnet-6, not getting any replies. Will debug with ops. + +techbro_ccoli for the testing team: have released latest fixtures, can be found here. + +## 2. Testing Verkle overview + +Next up, we had a brief presentation from @ignaciohagopian to walk through latest overall progress on the test framework for Verkle. The main branch for the test vectors can be found here in the execution spec tests repo. And to look at existing tests you can find them here in the tests/verkle folder, where all the tests are separated by EIP. Encourage anyone interested to poke around, ask questions, and eventually open up new test cases :) + +Ignacio also gave an overview of the changes that were made in geth to support the test framework, how the CI pipeline works, and a summary of all the test fixtures that exist today. The fixtures can be separated into 3 groups: + +(1) Verkle-genesis, where everything happens in a post-merkle patricia tree (MPT) world, + +(2) overlay-tree, which is running tests with a “frozen” MPT, and doing the block execution in the Verkle tree, + +(3) consuming tests from previous forks, to check pre-Verkle execution isn’t broken + + + +## 3. Testnet readiness check + +Next up, we went through and double checked each team’s readiness for the next testnet. Geth, Nethermind, and EthJS are ready as far as we can tell at this point, while Besu is still finishing up gas cost updates. + +## 4. Binary Tree Exploration + +Last up, Guillaume shared a presentation which summarizes some recent discussions we’ve had, as there’s been a bit of a renewed push by some in the community to explore binary trees as a potential alternative to Verkle. Some of this push has been motivated by recent progress made in ZK proving performance, and a desire to provide something that is even more zk-friendly than Verkle to help accelerate the move towards an eventual fully SNARK-ified L1. + +Highly recommend watching the recording to view Guillaume’s full presentation, but to give a rough TLDR: the main advantage of Verkle (apart from the fact that progress on Verkle is much further along today compared to a binary tree alternative) is that Verkle gives us small proofs (~400kb). And these proofs can enable stateless clients pretty much as soon as we ship Verkle. + +On the other hand, the advantages of binary trees is that hashing performance / commitment computation are much faster in general. And are also more compatible with current ZK proving schemes. The other advantage is around quantum resistance, though of course still much debate around timelines for quantum, and there are several other areas of the protocol that will need to be upgraded as part of any post-quantum push. + +The good news is: in either case, much of the work we’ve already done with Verkle is reusable in a binary tree design: (1) gas cost changes, (2) the single-tree structure, (3) the conversion & preimage distribution, and (4) (potentially) sync. + +What would change with binary trees though include: (1) the proof system, and (2) the cryptography (replacing polynomial commitments/pedersen with hashes) \ No newline at end of file diff --git a/Breakout-Room-Meetings/Verkle/Meeting 24.md b/Breakout-Room-Meetings/Verkle/Meeting 24.md new file mode 100644 index 00000000..3f8c0c66 --- /dev/null +++ b/Breakout-Room-Meetings/Verkle/Meeting 24.md @@ -0,0 +1,74 @@ +# Verkle Call #24 +## Info +Note: This file was copied from here: https://notes.ethereum.org/@rudolf/sic-notes#Call-24-September-9-2024 + +Date: September 9, 2024 + +Recording: www.youtube.com/watch?v=TTqikpo4R7g + +Agenda: https://github.com/ethereum/pm/issues/1149 + +## Notes + +## 1. Team updates + +Gary for @HyperledgerBesu: continuing work on stem-based flat database, and have a working implementation. Will simplify sync for Besu. Also making progress on gas cost changes and witness updates (EIP-4762). And planning on getting back to work on the transition stuff soon. + +@ignaciohagopian and @gballet for @go_ethereum: last week, discussed sync with the Geth team, and would like to figure out how performant it is to compute all of the leaves as they are needed (reading SLOAD + building a snapshot based on those leaves). Interested to understand Besu’s performance in this regard. Also completed a bunch of work on the testing framework. Gas costs are ready to go. Should be ready for new testnet in next few days. + +@GabRocheleau for @EFJavaScript: continued work to prepare for the upcoming testnet. Running the actual tests this week. Also made some upgrades to the WASM cryptography library so can begin creating proofs, and allows for stateful verkle state manager. Previously could only run blocks statelessly. + +@jasoriatanishq for @nethermindeth: mostly been working on getting the Hive test running. Found and fixed a few bugs. One change in the spec around gas costs, and continuing work on the transition. Working on some cryptography improvements as well. + +Somnath for @ErigonEth: integrating the gas cost changes and the witness calculation changes. Noticed some issues with the state management, but hopeful can resolve it in next week. Erigon has already started migrating everything to Erigon 3, but current verkle work is based on Erigon 2. Will try to join devnet-7 soon after it launches. + +@g11tech for @lodestar_eth: rebasing on latest from lodestar, which should provide a more stable base for testnet because of improved performance. + +@techbro_ccoli for the testing team: we have the witness assertions now within the framework when filling tests. Can write a test, and assert that a balance is what you expect. More of a sanity check. Now have similar for witness-specific values. Next step is to optimize how the tests are filled, and improve the transition tool runtime. + +## 2. Devnet Readiness + +There’s a couple updates to the specs that are still open. Quickly reviewed with Guillaume 3 PRs to merge in asap for the testnet: + +https://github.com/ethereum/EIPs/pull/8867 +https://github.com/ethereum/EIPs/pull/8707 +https://github.com/ethereum/EIPs/pull/8697 + +^ Leaving open for comments, but no objections raised during the call on these PRs. + +## 3. Verkle, Binary, & Tree-agnostic development + + +Quick recap of recent conversations we’ve had around the tradeoffs of Binary vs. Verkle: + +This is a topic that has come up often over the past few years, and even going all the way back to 2019/2020 – when @gballet was an author of EIP-3102: an initial proposal to migrate to a binary trie structure. + +More recently, as many teams have made strong progress on the ZK proving side, there’s been renewed discussion around whether a ZK-based solution could be ready in a similar timeframe to Verkle (or soon thereafter), and allow us to skip straight to a fully SNARKed L1. + +In this scenario, a binary trie structure is arguably preferable, in that it’s a friendlier option to current ZK proving systems, despite Verkle’s advantages in other dimensions (such as smaller tree/proof size and slower state growth). While Verkle is closer to “mainnet ready” today, it’s possible the gap closes over the next 1-2 years. + +The challenge and discussion now is mostly centered around how we can optimize forward progress on R&D efforts, solve problems facing users today, while also making sure we properly evaluate other viable/evolving technologies to ensure we land on the best long-term path for the protocol + users. + +TLDR: +it’s safe to say we plan on doing a bit more of at least two things over the next ~3-6 months: + +(1) evaluate binary: invest meaningful bandwidth into exploring / benchmarking a binary tree structure, while collaborating closely with zk teams. Make sure we understand where we are today in terms of performance, hardware requirements (with which hash function etc.), and where things need to be in order to be viable on L1. + +(2) tree-agnostic development: continue building the infrastucture and tooling necessary for statelessness, but lean into a tree-agnostic approach to optimize for reusability. This will give us flexibility to land on the best solution, whether it’s Verkle, Binary, or anything else. In any case, much of what has already been built (e.g. for state migration) will be a valuable and necessary component since it’s unlikely we stick with the current MPT for long. + +If you are excited about making progress on statelessness and scaling the L1, you can join the conversation in our biweekly implementers call 🚀 + +## 4. Deletions in Verkle +Discussion around whether not having deletions in Verkle will bloat the state. There are also downsides to deletions though, as it may make the conversion process a bit more complicated. TBD on final decision, but no strong objections raised to supporting deletions in Verkle. Recommend watching the recording for anyone interested in better understanding the full picture on this topic. + +## 5. Pectra Impact (7702, EOF, etc.) +Ignacio gave an overview of some work he’s done to better understand the potential impact of EOF on Verkle. He created a draft PR with the changes required. Guillaume also shared some thoughts on things we need to be mindful of with 7702. Namely around making sure that when you add something to the witness, you add the contract that the operation is delegated to instead of the account itself (otherwise the witness wil be empty). + +## 6. Verkle Sync +Geth team recently had a discussion on the topic of sync, and came away with a few potential suggestions. + +(1) around witness validation: full nodes can validate witnesses and make sure that no extra data is being passed as a way to prevent bloating of the witness. (e.g. flag a block that has too many leaves as invalid). Note: if we do introduce this rule, then we have to make the witness itself part of the block. + +(2) snapshot per stem, rather than by hash like it currently is. + +(3) how long to save the witness on disk: if we save it for something like a month or so, then it makes it a bit simpler for nodes who have been offline for a short period of time (e.g. 2-3 weeks) to rejoin the network. The tradeoff is it would add around 60GB. \ No newline at end of file From a72d8a4464c2a46da29ee323caa10542800bd6e1 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 10:54:36 -0500 Subject: [PATCH 38/51] Update README.md --- Breakout-Room-Meetings/Verkle/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Breakout-Room-Meetings/Verkle/README.md b/Breakout-Room-Meetings/Verkle/README.md index 0a1891d3..5212d097 100644 --- a/Breakout-Room-Meetings/Verkle/README.md +++ b/Breakout-Room-Meetings/Verkle/README.md @@ -7,6 +7,8 @@ Find more info [here](https://ethereum.org/en/roadmap/verkle-trees/) | # | Meeting | Date | Agenda | Notes | Recording | | -- | --| -- | -- | -- | -- | +24 | Verkle Call 24 | September 9, 2024 | [🔗](https://github.com/ethereum/pm/issues/1149) | [🔗](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/Verkle/Meeting%2024.md) | [📺](http://www.youtube.com/watch?v=TTqikpo4R7g) | +23 | Verkle Call 23 | August 26, 2024 | [🔗](https://github.com/ethereum/pm/issues/1121) | [🔗](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/Verkle/Meeting%2023.md) | [📺](https://www.youtube.com/watch?v=VD0P3RkhIjY) | 22 | Verkle Call 22 | July 29, 2024 | [🔗](https://github.com/ethereum/pm/issues/1119) | [🔗](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/Verkle/Meeting%2022.md) | [📺](https://www.youtube.com/watch?v=W1SLIEQ3a5o&feature=youtu.be) | 21 | Verkle Call 21 | July 15, 2024 | [🔗](https://github.com/ethereum/pm/issues/1092) | [🔗](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/Verkle/Meeting%2021.md) | [📺](https://youtu.be/8YosyUWzmz0) | 20 | Verkle Call 20 | July 1, 2024 | [🔗](https://github.com/ethereum/pm/issues/1089) | [🔗](https://github.com/ethereum/pm/blob/master/Breakout-Room-Meetings/Verkle/Meeting%2020.md) | [📺](https://youtu.be/L873Z5K6XZQ) | From da39fd966e39e6553bab3f645c09d26721dce668 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 11:07:34 -0500 Subject: [PATCH 39/51] Create Meeting 25.md --- .../Stateless/Meeting 25.md | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Breakout-Room-Meetings/Stateless/Meeting 25.md diff --git a/Breakout-Room-Meetings/Stateless/Meeting 25.md b/Breakout-Room-Meetings/Stateless/Meeting 25.md new file mode 100644 index 00000000..cefd29e6 --- /dev/null +++ b/Breakout-Room-Meetings/Stateless/Meeting 25.md @@ -0,0 +1,41 @@ +# Stateless Implementers Call #25 +## Info +Note: This file was copied from here: https://notes.ethereum.org/@rudolf/sic-notes#Call-25-September-23-2024 + +Date: September 23, 2024 + +Recording: https://youtu.be/pfORU9ngjzI + +Agenda: https://github.com/ethereum/pm/issues/1159 + +## Notes + +## 1. Team updates + +ignaciohagopian and gballet for go_ethereum: just about ready for testnet relaunch. Most PRs merged. Also working on benchmarking. Some updates to the test fields, and fixed some tests around witness checks. Can also run the tests in stateless mode soon, where the witness acts as the prestate source of truth. + +jasoriatanishq for nethermindeth: no major updates. Working with Ignacio on tests. Will try to run the tests in stateless mode this week 🔥 + +kt2am1990 and lu-pinto for HyperledgerBesu: last week, working on the flat DB based on stem key. Completed some benchmarking to see impact on SLOAD. Found the perf was quite bad. Working with Kev on some optimizations. Also working on integrating Constantine library into Besu, in order to compare perf. Made some good progress on getting the test fixtures to run. Will get back to finalziing gas costs after. + +## 2. EIP-7702 in Verkle + +We quickly went through a PR from Guillaume to update the stateless gas costs EIP in order to support changes coming in 7702. (Current plan is for 7702 to be included in Pectra, & 7702 containts a new type of tx: authorization_list. Info that is used to update some accounts) + +TLDR is this updates the gas costs EIP so if you call these functions (EXTCODESIZE, EXTCODEHASH etc), then you also need to touch the CODEHASH_LEAF_KEY. Ping Guillaume with any comments/questions. + +## 3. Partial Witness Charging + +Ignacio walked through a few scenarios where a bit more granularity may be needed around gas costs in Verkle. See PR here. + +Scenario 1: if you don’t have enough gas to pay for whatever witness charging you have to do, then you don’t actually need to include that in the witness. (e.g. if you do a jump and don’t have enough available to pay, then you wouldn’t include that cold chunk in the witness) + +Scenario 2: there are several places in execution where you have to include more than one leaf in the witness. In these cases, Geth was previously always including both leaves. Even if you didn’t have enough gas, it was already added to the witness. + +For both scenarios we want to allow for better granularity / partial witness charging. +TLDR: only add things to the witness if you have the available gas for it + +## 4. Testnet-7 Check-in + +Ending things with a quick check on testnet readiness. Pari said DevOps should have time to assist later this week. Recommended doing it locally first in case bugs are found, and then once it works locally switch to a public testnet 🥳 + From 53715a52881b3a02260a8a188ab1007bf74ef7b3 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 11:07:52 -0500 Subject: [PATCH 40/51] Meetings 26 & 28 --- .../Stateless/Meeting 26.md | 39 ++++++++++++ .../Stateless/Meeting 28.md | 60 +++++++++++++++++++ 2 files changed, 99 insertions(+) create mode 100644 Breakout-Room-Meetings/Stateless/Meeting 26.md create mode 100644 Breakout-Room-Meetings/Stateless/Meeting 28.md diff --git a/Breakout-Room-Meetings/Stateless/Meeting 26.md b/Breakout-Room-Meetings/Stateless/Meeting 26.md new file mode 100644 index 00000000..a9ebc74c --- /dev/null +++ b/Breakout-Room-Meetings/Stateless/Meeting 26.md @@ -0,0 +1,39 @@ +# Stateless Implementers Call #26 +## Info +Note: This file was copied from here: https://notes.ethereum.org/@rudolf/sic-notes#Call-26-October-21-2024 + +Date: October 21, 2024 + +Recording: https://youtu.be/MJA1e95cfww + +Agenda: https://github.com/ethereum/pm/issues/1186 + +## Notes + +## 1. Team updates + +ignaciohagopian and gballet for go_ethereum: added around 30 new tests in the execution test spec repo, mostly covering edge cases regarding out of gas execution transactions. (This is relevant for Verkle because if you run out of gas, you might generate a partial witness). Guilluame has been working on speeding up witness generation, as well as the rebase on top of Cancun to get updated metrics. + +jasoriatanishq for nethermindeth: testing and debugging latest hive tests. Also have been progressing on the Nethermind implementation of the transition. + +lu-pinto and kt2am1990 for HyperledgerBesu: Working on gas costs. Currently 2 tests are failing (regarding self-destruct). Also all of the BLOCKHASH tests are failing because the logic for pulling out the BLOCKHASH from the system contract is not yet implemented, but that’s up next. Have also completed some optimizations on the rust-verkle crypto library. And now have a working version of the flatDB based on stem. Next step here is to generate the preimage to be able to run this flatDB with mainnet blocks and compare performance. Lastly, continuing to work on integrating the Constantine crypto library into Besu. + +## 2. Circle STARKs seminar + +Matan joined to share some info on an upcoming SNARK-focused seminar he will be leading, which will be open for anyone currently working on stateless. The seminar will be focused on bridging the gaps for upcoming items on the Verge roadmap, in particular exploring the topics of SNARKing Verkle, Circle STARKs, and STARKed binary hash trees (as a potential alternative to Verkle). No prerequisites or math background required for the course. Idea is accessible to lay audience. The seminar will likely be weekly and run for TBD number of weeks. +Apply to join here! + +## 3. Verkle Metrics + +Guillaume shared an updated document which provides a helpful overview of latest Verkle metrics. This is data collected by replaying ~200k historical blocks (around the time of the Shanghai fork). While they don’t provide a perfect predicition for how things will look in the future, it does help give a solid approximation of what to expect. + + + +## 4. Spec Updates + +Last up on this week’s call, a few quick points related to gas cost spec: + +CREATE gas cost: currently 32,000. But for Verkle, we’ve considered reducing this. +Decision: keep as-is for now. +How much to charge when doing account creation (e.g. when doing a call and the address does not exist yet). And similar question for SELFDESTRUCT +Decision: open a convo with research team for further discussion \ No newline at end of file diff --git a/Breakout-Room-Meetings/Stateless/Meeting 28.md b/Breakout-Room-Meetings/Stateless/Meeting 28.md new file mode 100644 index 00000000..094a38a0 --- /dev/null +++ b/Breakout-Room-Meetings/Stateless/Meeting 28.md @@ -0,0 +1,60 @@ + +# Stateless Implementers Call #28 +## Info +Note: This file was copied from here: https://notes.ethereum.org/@rudolf/sic-notes#Call-28-December-2-2024 + +Date: December 2, 2024 + +Recording: https://www.youtube.com/watch?v=5bxvSLvc9LA + +Agenda: https://github.com/ethereum/pm/issues/1203 + +## Notes + +## 1. Team updates + +@ignaciohagopian and @gballet for @go_ethereum: started working on EIP draft for binary tries. Also working on new execution spec tests from bugs that were found in latest devnet. + +@g11tech for @EFJavaScript: been playing with devnet-7, and resolving some recently found issues. + +@kt2am1990 for @HyperledgerBesu: Working on implementing the blockhash gas cost modification. Also implementing the proof verification. This will unblock some other stuff like Verkle sync (snap sync equivalent), and validating proof coming from the other client. Also working on optimizing stem generation by modifying how we call the Rust Verkle library. + +## 2. Execution spec tests + +Update from Ignacio, sharing v0.0.8. + +After we previously launched devnet-7, we found a consensus bug with Nethermind. Debugged with Tanishq and found an edge case. Created a new test case to cover this. Idea going forward is that every bug we find in any devnet should result in a new execution spec test to cover it. Any new client that joins the next devnet will also be covered by these cases. + +## 3. Preimage distribution and Portal Network + +Piper from Portal Network joined to share some thoughts on preimage distribution with Portal. + +Regarding preimage distribution for the Verkle migration: Piper mentioned that Portal can solve this, but probably isn’t the best solution. Portal is best for clients who want to grab a subset of the data on demand. With the preimage problem for Verkle, all of the clients would need to grab the full set of preimages. But there could be a “file-based approach” that could make sense in this case. + +The file-based approach: S3 buckets being able to generate the file, and potentially having pre coded S3 buckets in clients that are already distributed. Has a predistributed trust model. Distributing big files like this from S3 buckets is a pretty straightforward approach. Alternative to S3 buckets, could use torrents. + +Guillaume mentioned that Lukasz from Nethermind had previously indicated a preference for using an in-protocol p2p approach. But added that it seems clear that the CDN approach is the simplest and should probably go with that. + +Next steps: make a spec on a potential format for the file. + +## 4. State expiry + +Hadrien from OpenZeppelin joined to share some thoughts on state expiry. + +One related question that was discussed in Devcon: do we want to resurrect based on reads or based on writes? + +Hadrien: most of the storage accesses are as you expect related to reading and writing. And so one question is whether a read would extend the lifetime of an extension or not. There are a few slots that are being read, but never written to. For example in the case of ERC-721, when tokens are transferred the slot will often contain a zero because nobody is allowed to take the token. And anytime there is a transfer of that token, in the current implementation it will write another zero to reset, even if old value is a zero, because its cheaper than trying to read. Depending on how state expiry works, there may be different cost model depending on whether there is a zero because it was never written to the state, compared to if a zero gets explicitly written. + +This is where the approach of state expiry shown in EIP-7736 comes in. Han joined to share some updates on this front. + +Han is currently working on implementing 7736, and the changes needed on the Verkle part are done. Still working on the geth part. Once we get all the components complete and integrated can hopefully have a devnet to start testing out the various scenarios. + +## 5. Stateless Transactions EIP + +Gajinder shared some of the latest thinking around changes needed to best support stateless clients. + +One of the challenges is that stateless clients which don’t maintain any execution state would not be able to do any kind of local block building. This proposal is a partial remedy to this problem. + +The basic idea is that with every transaction the transaction submitter will also have to submit an execution witness, and that execution witness will have a state diff + proof of the state diff. The execution witness would also bundle the parent state root, which is what a builder would look at to see whether it can include this tx in the particular block that it’s building. + +Gajinder is currently drafting the EIP. Will have something to share soon. \ No newline at end of file From 5d078d991c8ca767ad80d91f8d75709fd0a9dbb1 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 11:14:20 -0500 Subject: [PATCH 41/51] Create README.md --- Breakout-Room-Meetings/Stateless/README.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Breakout-Room-Meetings/Stateless/README.md diff --git a/Breakout-Room-Meetings/Stateless/README.md b/Breakout-Room-Meetings/Stateless/README.md new file mode 100644 index 00000000..356b498d --- /dev/null +++ b/Breakout-Room-Meetings/Stateless/README.md @@ -0,0 +1,14 @@ +# Stateless Meetings + +## Purpose +Verkle trees (a portmanteau of "Vector commitment" and "Merkle Trees") are a data structure that can be used to upgrade Ethereum nodes so that they can stop storing large amounts of state data without losing the ability to validate blocks. +Find more info [here](https://ethereum.org/en/roadmap/verkle-trees/) + +### Meetings + +| # | Meeting | Date | Agenda | Notes | Recording | +| -- | --| -- | -- | -- | -- | +28 | Statless Call 28 | December 2, 2024 | [🔗](https://github.com/ethereum/pm/issues/1203) | [🔗](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/Stateless/Meeting%2028.md) | [📺](https://www.youtube.com/watch?v=5bxvSLvc9LA) | +27 | Statless Call 27 | November 4, 2024 | [🔗](https://github.com/ethereum/pm/issues/1196) | [🔗] | [📺](https://youtu.be/1PYu4_Ac1Po) | +26 | Statless Call 26 | October 21, 2024 | [🔗](https://github.com/ethereum/pm/issues/1186) | [🔗](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/Stateless/Meeting%2026.md) | [📺](https://youtu.be/MJA1e95cfww) | +25 | Statless Call 25 | September 23, 2024 | [🔗](https://github.com/ethereum/pm/issues/1159) | [🔗](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/Stateless/Meeting%2025.md) | [📺](https://youtu.be/pfORU9ngjzI) | From d66ddd461177746873252265fc25569265431feb Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 11:16:06 -0500 Subject: [PATCH 42/51] Update README.md --- Breakout-Room-Meetings/Stateless/README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Breakout-Room-Meetings/Stateless/README.md b/Breakout-Room-Meetings/Stateless/README.md index 356b498d..56ac4d0d 100644 --- a/Breakout-Room-Meetings/Stateless/README.md +++ b/Breakout-Room-Meetings/Stateless/README.md @@ -1,14 +1,15 @@ # Stateless Meetings ## Purpose -Verkle trees (a portmanteau of "Vector commitment" and "Merkle Trees") are a data structure that can be used to upgrade Ethereum nodes so that they can stop storing large amounts of state data without losing the ability to validate blocks. -Find more info [here](https://ethereum.org/en/roadmap/verkle-trees/) +The ability to run Ethereum nodes on modest hardware is critical for true decentralization. This is because running a node gives users the ability to verify information by performing cryptographic checks independently rather than trusting a third party to feed them data. Running a node allows users to submit transactions directly to the Ethereum peer-to-peer network rather than having to trust an intermediary. Decentralization is not possible if these benefits are only available to users with expensive hardware. Instead, nodes should be able to run with extremely modest processing and memory requirements so that they can run on mobile phones, micro-computers or unnoticeably on a home computer. + +Find more [here]([url](https://ethereum.org/en/roadmap/statelessness/)) ### Meetings | # | Meeting | Date | Agenda | Notes | Recording | | -- | --| -- | -- | -- | -- | 28 | Statless Call 28 | December 2, 2024 | [🔗](https://github.com/ethereum/pm/issues/1203) | [🔗](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/Stateless/Meeting%2028.md) | [📺](https://www.youtube.com/watch?v=5bxvSLvc9LA) | -27 | Statless Call 27 | November 4, 2024 | [🔗](https://github.com/ethereum/pm/issues/1196) | [🔗] | [📺](https://youtu.be/1PYu4_Ac1Po) | +27 | Statless Call 27 | November 4, 2024 | [🔗](https://github.com/ethereum/pm/issues/1196) | N/A | [📺](https://youtu.be/1PYu4_Ac1Po) | 26 | Statless Call 26 | October 21, 2024 | [🔗](https://github.com/ethereum/pm/issues/1186) | [🔗](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/Stateless/Meeting%2026.md) | [📺](https://youtu.be/MJA1e95cfww) | 25 | Statless Call 25 | September 23, 2024 | [🔗](https://github.com/ethereum/pm/issues/1159) | [🔗](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/Stateless/Meeting%2025.md) | [📺](https://youtu.be/pfORU9ngjzI) | From ef016878b3ba192864390f4d4e5cd113c9ea1fd8 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 11:16:36 -0500 Subject: [PATCH 43/51] Update README.md --- Breakout-Room-Meetings/Stateless/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Breakout-Room-Meetings/Stateless/README.md b/Breakout-Room-Meetings/Stateless/README.md index 56ac4d0d..022a98d0 100644 --- a/Breakout-Room-Meetings/Stateless/README.md +++ b/Breakout-Room-Meetings/Stateless/README.md @@ -3,7 +3,7 @@ ## Purpose The ability to run Ethereum nodes on modest hardware is critical for true decentralization. This is because running a node gives users the ability to verify information by performing cryptographic checks independently rather than trusting a third party to feed them data. Running a node allows users to submit transactions directly to the Ethereum peer-to-peer network rather than having to trust an intermediary. Decentralization is not possible if these benefits are only available to users with expensive hardware. Instead, nodes should be able to run with extremely modest processing and memory requirements so that they can run on mobile phones, micro-computers or unnoticeably on a home computer. -Find more [here]([url](https://ethereum.org/en/roadmap/statelessness/)) +Find more [here](https://ethereum.org/en/roadmap/statelessness/) ### Meetings From f2ec0698afb5e15111352fad25c57feba346ac87 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 12:00:12 -0500 Subject: [PATCH 44/51] Update Meeting 56.md --- Breakout-Room-Meetings/EOF/Meeting 56.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/Breakout-Room-Meetings/EOF/Meeting 56.md b/Breakout-Room-Meetings/EOF/Meeting 56.md index 34159a51..03d47b10 100644 --- a/Breakout-Room-Meetings/EOF/Meeting 56.md +++ b/Breakout-Room-Meetings/EOF/Meeting 56.md @@ -1,9 +1,4 @@ ---- -title: Meeting 03 - ---- - -# EOF Implimenters call 56 +# EOF Implementers call 56 Note: This file is copied from [here](https://github.com/ethereum/pm/issues/1128#issuecomment-2302428979) ## Meeting info @@ -60,4 +55,4 @@ Devs, please update Any automation interest? - Maybe hive/consume? - Still needs final consume setup in CI -- Consume does not run EOF Validation tests (because engine API is the test interface) \ No newline at end of file +- Consume does not run EOF Validation tests (because engine API is the test interface) From 59dbd5ac65378c25daac6b8daeca62583a520f38 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 12:00:54 -0500 Subject: [PATCH 45/51] Update Meeting 57.md --- Breakout-Room-Meetings/EOF/Meeting 57.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Breakout-Room-Meetings/EOF/Meeting 57.md b/Breakout-Room-Meetings/EOF/Meeting 57.md index 7596b961..fb1cd0f8 100644 --- a/Breakout-Room-Meetings/EOF/Meeting 57.md +++ b/Breakout-Room-Meetings/EOF/Meeting 57.md @@ -1,8 +1,3 @@ ---- -title: Untitled - ---- - # EOF implementers call 57 Note: this file is copied from [here](https://github.com/ethereum/pm/issues/1138#issuecomment-2329428927) @@ -55,4 +50,4 @@ More on nethermind's status - Will target prague in EOF branch - Running published EEST fixtures. -New fixtures will be published this week. Need to fix an EEST bug relating to EXT*CALL opcodes. \ No newline at end of file +New fixtures will be published this week. Need to fix an EEST bug relating to EXT*CALL opcodes. From d981ba878b8a547787a2349c65817e7d0c0a07b6 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Sun, 29 Dec 2024 12:05:05 -0500 Subject: [PATCH 46/51] Create README.md --- Breakout-Room-Meetings/EOF/README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Breakout-Room-Meetings/EOF/README.md diff --git a/Breakout-Room-Meetings/EOF/README.md b/Breakout-Room-Meetings/EOF/README.md new file mode 100644 index 00000000..5443fec8 --- /dev/null +++ b/Breakout-Room-Meetings/EOF/README.md @@ -0,0 +1,19 @@ +# EOF + +The Ethereum Object Format (EOF) represents a transformative update to the Ethereum Virtual Machine (EVM) bytecode structure. Designed to enhance the efficiency, security, and modularity of smart contracts, EOF restructures how smart contract bytecode is organized. This upgrade addresses traditional limitations of the bytecode format, aiming to make contracts more manageable and secure. + +## Breakout Room Meetings + +| # | Date | Agenda | Recording | Notes | +| -- | --| -- | -- | -- | +| 63 |December 17, 2024| [Agenda](https://github.com/ethereum/pm/issues/1205) | [Recording](https://youtu.be/2Z5YPfOnb74) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2063.md) | +| 62 |November 27, 2023| [Agenda](https://github.com/ethereum/pm/issues/1192) | [Recording](https://youtu.be/yzYUWpa-1QM) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2062.md) | +| 61 |October 30, 2024| [Agenda](https://github.com/ethereum/pm/issues/1184) | [Recording](https://youtu.be/kBQoRdBg4Vg) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2061.md) | +| 60 |October 16, 2024| [Agenda](https://github.com/ethereum/pm/issues/1167) | [Recording](https://youtu.be/FLtlemN2W8w) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2060.md) | +| 59 |October 2, 2024| [Agenda](https://github.com/ethereum/pm/issues/1162) | [Recording](https://youtu.be/TjZv8DMZka4) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2059.md) | +| 58 |September 18, 2023| [Agenda](https://github.com/ethereum/pm/issues/1146) | [Recording](https://youtu.be/MSuxLswMkXA) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2058.md) | +| 57 |September 4, 2024| [Agenda](https://github.com/ethereum/pm/issues/1138) | [Recording](https://youtu.be/7wFucExQb7U) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2057.md) | +| 56 |August 21, 2024| [Agenda](https://github.com/ethereum/pm/issues/1128) | [Recording](https://www.youtube.com/watch?v=03Dkfpvw4Pc) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2056.md) | +| 55 |July 24, 2024| [Agenda](https://github.com/ethereum/pm/issues/1115) | [Recording](https://youtu.be/OaNJOoaeNNY) | [Notes](https://github.com/darkfire-rain/pm/blob/master/Breakout-Room-Meetings/EOF/Meeting%2055.md) | + + From 31733308b33612198f5ed060c26c492bcacd4561 Mon Sep 17 00:00:00 2001 From: Aleneth <145821766+Aleneth@users.noreply.github.com> Date: Mon, 30 Dec 2024 09:06:54 +0530 Subject: [PATCH 47/51] Create call_145.md Agenda: https://github.com/ethereum/pm/issues/1185 --- AllCoreDevs-CL-Meetings/call_145.md | 359 ++++++++++++++++++++++++++++ 1 file changed, 359 insertions(+) create mode 100644 AllCoreDevs-CL-Meetings/call_145.md diff --git a/AllCoreDevs-CL-Meetings/call_145.md b/AllCoreDevs-CL-Meetings/call_145.md new file mode 100644 index 00000000..21acd006 --- /dev/null +++ b/AllCoreDevs-CL-Meetings/call_145.md @@ -0,0 +1,359 @@ +# Consensus Layer Call 145 + +### Meeting Date/Time: Thursday 2024/10/31 at 14:00 UTC +### Meeting Duration: 1 hour +### [GitHub Agenda](https://github.com/ethereum/pm/issues/1185) +### [Audio/Video of the meeting](https://youtu.be/KMLqv60xg9w) +### Moderator: Stokes +### Notes: Alen (Santhosh) + +## Summary +Summary | Description +-|- +145.1 |**Pectra Devnet 4 Updates** EF DevOps Engineer Barnabas Busa said there were no major problems with Pectra Devnet 4. Client teams have implemented various fixes such that all clients are able to propose blocks on the devnet. Busa said that based on Pectra Devnet 4 specifications, his team launched a public Pectra testnet called Mekong earlier in the day on October 31, 2024. His team is working on creating a dedicated blog post and FAQ documented detailing how users can join the public Pectra testnet and try out the new features of the network. Busa said he foresees Mekong running for a few months for the benefit of the broader Ethereum ecosystem and will potentially shut it down before the end of the year. It is a large testnet supported by 110 nodes and approximately 100,000 active validators. Because it is based on Pectra Devnet 4 specifications, the testnet lacks certain features such as EIP 7742 (Uncouple blob count between CL and EL). +145.2 |**Consensus specifications, PR #3900:** This PR introduces a new attestation type for formatting validator and committee indices to simplify how attestations are processed. Developers agreed to move forward with this change and include it in Pectra Devnet 5 specifications. +145.3 |**Consensus specifications, PR #3767:** This PR removes certain time out responses when nodes handle data requests from peers and replaces them with a rate limiting recommendation. This is a backwards compatible change. Developers agreed to move forward with it and include it in Pectra Devnet 5 specifications. +145.4 |**Consensus specifications, PRs TBD:** Stokes said there are a few PRs in the works implementing tweaks to the way execution layer requests are handled on the consensus layer. There were no objections to this comment and Stokes said that developers will move forward with these PRs in Devnet 5 once they are ready. +145.5 |**EIPs, PR #8994:** Lodestar developer Gajinder Singh has recommended updates to the EL headers and gas fee mechanism under EIP 7742 (Uncouple blob count between CL and EL) such that the base fee calculation can respond more accurately to changes in the blob gas target. There are deeper revisions that developers could implement to ensure accuracy in the base fee calculation. However, based on the discussion, developers agreed to opt for the simpler changes suggested by Singh and delay deeper revisions to the base fee calculation to another upgrade. +145.6 |**Consensus specifications, PR #4000** Teku developer Mikhail Kalinin has proposed a PR to add missing checks to validator consolidation requests. Kalinin requested a review of this PR so that it can be finalized for Pectra Devnet 5. +145.7 |**PeerDAS Devnet Updates** PeerDAS Devnet 3 has been shut down after a reported 100,000 slot reorganization. Busa said that it was “unfeasible” for his team to try and recover the network after the incident. He could not share further details about the cause of the reorg. He mentioned that the Prysm team is in the process of investigating the matter. +145.8 |**New EIP: Withdrawal Credential Update** Lucas Saldanha, a Lead Blockchain Protocol Engineer for Consensys, has proposed an EIP to allow validators to update their withdrawal credentials without having to fully exit their validators. Since many new validator operations such as deposits, withdrawals, and consolidations, will be triggerable through a smart contract after Pectra, validator node operators may wish to update their withdrawal credentials such that they are managed through a smart contract. However, there is no way for withdrawals credentials to be updated unless the validator is exited. To avoid the need to cycle validators for the purposes of updating withdrawals credentials, EIP 7800 offers a mechanism for validators to update their withdrawal credentials through a new execution request type, "0x03". Prysm developer “Potuz” and Kalinin expressed their support for the EIP. While it will not be included in Pectra, it may be in EIP for consideration in a future upgrade. + + +**Stokes** +* Okay. We should be live there. And yeah, let's go ahead and get into things. So hey everyone, this is consensus layer. Call 145. I'll drop the agenda here in the chat. And yeah, a number of things for Pectra +* PeerDAS and a couple of other questions. So let's go ahead and get started +* To begin let's look at Pectra Devnet 4 is there any updates there worth going over, any open issues or questions we should discuss at the moment + + +**Barnabas** +* So as of the last week, there has been multiple different client fixes for those clients that were missing slots.in the last weeks. And it seems like everyone is able to now propose blocks. There are still a few, questions that we have open, but everything is, under discussion + +**Stokes** +* Good to hear + +**Stokes** +* I guess a related point, do we want to discuss the, public devnet that we were talking about based off devnet 4 + +**Barnabas** +* Yes. so we were gonna announce this, maybe at the end of the call, but I guess we can already announce it right now. So we have launched a public testnet, which is going to be available for everyone to make deposits and exits and consolidations and everything. We had Genesis just three hours ago, and we have Electra getting triggered on it tomorrow on epoch 256 +* Client teams can decide if they want to include this as a flag in their client. we are writing right now a frequently asked question documentation where we're going to explain how to run a node on this network. But yeah, if any of the clients are up to adding this as a default chain configuration, they are welcome. +* But it's going to run approximately three months or till possibly till, we can fork mainnet We expect it to be shut down by the end of the year. So it's it's not like a must have. It's it's a nice to have + +**Stokes** +* Cool. Yeah. + +**Barnabas** +* Yeah. We have 100,000 validators and, we have approximately 1000 validator per client, so it's about 100, 110 nodes. So it's a pretty it's a fairly big network It's also nice to do some stress tests here And yes, this is based on Pectra for spec. So it doesn't have 7742 requirements yet. And everything that is running on Pectra four should be also working on this, this name testnet. I mean + +**Stokes** +* Cool. And we went with for the name. It looks like + +**Barnabas** +* Yes + +**Barnabas** +* So we decided to use this name because the alternatives had, uh + +**Barnabas** +* Some, some coins already running on it, so we didn't want to be affiliated with that. + +**Stokes** +* And you said there'll be, like, some documentation coming, for, you know, the community to engage with it. + +**Barnabas** +* Yes. we have one that's working in progress right now, so I didn't want to link that, but + +**Barnabas** +* It's coming. Okay. And we have a general URL as usual to find all the links + +**Stokes** +* Cool. Thanks + +**Stokes** +* Great. Then. Yeah, it sounds like we're good on devnet 4 we can move on. Anything else +* Okay, cool great. Yeah. So we can move on, then to Devnet five. Oh, sorry. + +**Barnabas** +* Yeah, there's one more thing. So, we have been working in the background a bit, to introduce the new tool that will be able to submit deposits and consolidation requests. Kind of like what launchpad does. But you can actually, do a bigger deposit now that supports more than 32 . And the consolidation request will also be part of this. So you will be able to test out, how you can consolidate two validators. +* So this is going to help the community To run a test basically even without needing to run a validator + +**Stokes** +* Gotcha Cool. Yeah. It'll be really nice to see it all come together. + +**Barnabas** +* Yeah. This is still a work in progress. So we have something. Maybe by next week + +**Stokes** +* Okay, then onto Devnet five. So there are a number of open items here. And yeah, I think a few of these I think we can get through pretty quickly the first one is essentially just a last call on PR 3900. We had said, a few calls ago that we would target Devnet five for this. And, yeah, there's a little more discussion after that point, but it sounds like at this point that's all been settled. And yeah, I think everyone is generally in agreement to go ahead and merge this. +* So yeah, last call And unless someone opposes I think we'll move ahead with this. we could even merge it after the call today I assume this plus one from Prism is for this PR so yep. In that case, cool and yeah, I guess just like one one caveat there is, to like, limit the scope of implementation changes. We were focusing on this change sort of just at the networking layer so that you didn't have to go through and change a bunch of other stuff in different layers of the client. So just be aware of that. cool. +* Yeah, I've got some plus ones, so we're good on that next up, I did want to bring this, question up. This was refactoring kind of how we do timeouts and like managing peers again, in the past there was support for this. My understanding is that, we don't necessarily need, like, even a hard fork to coordinate this. I mean, I believe it's backwards compatible can someone speak to that point who's a little who's been closer to this PR like, especially if it's backwards compatible, then I think we're good to go ahead and merge it now + +**Pop** +* I think it's backward compatible + +**Stokes** +* Cool. Yeah, that's my understanding right. Okay. So then in that case, I think we go ahead and also just roll this into Devnet five and great we have those. So next up there are a number of well, maybe I'll start here. So my understanding is that there is some demand to refactor the requests coming from the execution layer. a bit further for Devnet five. And there are some PRS that are tracking that and the consensus specs, and we can go ahead and get them, I think in the next release or two pretty easily. But first I just wanted to kind of do a temperature check. +* And this is maybe even more a question for the ELs, because I think some of the changes touched the execution layer a bit more do we have anything to address there? Do we feel like that changes moving forward? Well I know Felix was driving a lot of this. I'm not sure he's here, though + +**James He** +* For the execution requests, I think the big thing is, just documenting all of the edge cases, the PR itself. And this descriptions don't fully document all of the different I think edge cases that we have to deal with, like, if we get, like a type and then we don't get the list or, checking for the max range of the requests, like how many you can include for the decoding or if it's empty, or if it's out of order, those things should be added somehow, especially because there's no spec tests for this + +**Stokes** +* Right. so the consensus specs PR that I saw for this did have these checks, and it was, I think, pretty, pretty well handled. But yeah, it does sound then like things are moving forward. And yeah, I guess no one has any questions or points to raise about that at the Then we'll assume that's moving forward. So next up then 7742. just to remind everyone, this is the EIP to uncouple how we handle the blob counts between the CL and EL and. Right. So this this EIP has been included. +* It'll lay the groundwork for us to more easily make changes to the blob counts in Pectra, which I think there's plenty of demand to do that the question that has come up in the last week or two, is that as written, 7742 is kind of missing a piece, at least potentially missing a piece around changing the base fee calculation. So right now it's essentially a function of the target blob count. And especially if we change the target. That could have implications for the blob base fee and how it responds to these changes once we started getting into this, there's like a number of other questions that came up. +* And I think now we kind of have this question to answer of how invasive do we want to change this? Like, do we sort of aim for sort of a more elegant thing right now, or maybe do something a little more practical that is simpler to move forward and think about this work at a later date. So I guess I can go ahead and grab this update to the EIP I'll put this here in the chat. So there are a couple options here. one of them is to basically just do nothing and not worry about how the target would impact the base fee here. although even moving to, say, four and six would have some implications. The I think next sort of simplest step would be to just go ahead and update 7742 so that the base fee scales with the target. This is what I'd call kind of the quick and dirty solution. +* I think it would work well for Pectra and is like pretty, you know, it's not like a super invasive change. Then from there, there were some questions around revisiting how we again compute the base fee. so it's kind of tolerance to any max or target change. And that has implications for again, sort of like the symmetry of how the base fee scales either coming up or coming down from wherever we're at at the moment. So yeah, I know, let's see. I don't know if Tony's on the call. I think he should be somewhere +* I don't see him. But anyway, so he had a more, sort of elaborated take on this. And yeah, I guess the question for today is just trying to get a sense of like how much we want to do now. I would say the, the EIP, PR that I linked here and what is it, 8994. that one is like, I think a pretty good balance of like, you know, addressing some of these concerns for Pectra without being like too much of a big lift. So that 7742 becomes this, like, very complicated EIP. Gajender + +**Gajinder** +* Yeah. Hello. is the audio okay? + +**Stokes** +* Yeah. That's great + +**Gajinder** +* All right. So yes. So, for, for the symmetry, I mean, it's a very small change to include. And if we actually want the symmetry of gas changes while going up or down, I think we should include it. So the main and it wouldn't really make sense for to any more complicated than it already is. but it will introduce the max, blob count to the header, because then it would be required to make sure that there is symmetry. And, yeah, I think that's it + +**Stokes** +* Right. And so I think what I linked doesn't have the max. Right? I think that's where we landed on that + +**Gajinder** +* Yeah. We basically right now removed the max and only we have target blob count right now. + +**Stokes** +* Right. And then yeah, to get to like a sort of more nice solution, we would also need the max being sent over. So that's a question for CL devs right now. And also EL devs, whoever's here. yeah. Do we feel strongly about adding this field to the header or passing it through the engine API and all the different places it needs to be + +**Stokes** +* Ansgar + +**Ansgar** +* Yeah, and I just wanted to very briefly explain for people. Right. Because this might sound a little complicated, but the idea is very simple, right? If you only communicate the target to the EL, then in the calculation you can you basically just don't know how much more room there is between target and Max. And so you basically look at the target. And if the target is say four, you just say, okay, what's the max for four is basically the, the, the you can have zero blobs one plus two plus 3 or 4 blobs. +* So if you have zero blobs then basically you want to go down by 12% or whatever, the maximum kind of change rate per slot you want to have, and that's fine and all, but if you don't know the max, then you don't know if the if the maximum is eight then then you're good because then on the other side you also have like this maximum of 12% per slot that you can change. But if the maximum says only six, like we had discussed for six, for example, as a potential change, then all of a sudden you only have half of that of responsible responsiveness to the upside. So now you only have 6% of a max increase in base fee per slot. +* And that means that now anytime there's a demand spike, your reactiveness is half as fast. +* Basically, you need twice as many slots to react to a new base fee level that you want to get to than you would otherwise. +* So basically, communicating the max together with the with the target would allow us to have an update rule of some sort. Kind of depends. Can be simple. Can be small. Change today can be bigger change. And but it would basically be able to take that into account. But if you only communicate the target just conceptually, there's no way of knowing how much room you have between target and Max + +**Stokes** +* Right. Yeah. Thanks. And then Oscar, do you have a sense of oh, go ahead. + +**Gajinder** +* I would just want to add in this. Basically, I want to add that, you know, the upside is basically limited because actually the upside for max blobs that can be included is also limited. I mean, it basically reflects that. So if target and Max are basically not symmetric in the sense that this is just reflecting that. And in my eyes, I think this, this is just fine we should be okay with the little bit of asymmetry, but yeah. So I mean, if this is a really desirable quality to have, then definitely we should go for it + +**Gajinder** +* Right? + +**Stokes** +* I mean, I think, you know, the ideal state is that and so it is desirable. But I would kind of bias towards, again, sort of a good enough solution for Pectra. And we can always revisit a deeper change to the fee market and pusaka along + +**Stokes** +* With paradox. So I think we have some room to be flexible here + +**Stokes** +* Right. So okay, I would lean towards moving ahead with this 8994 update here. for 7742 for Pectra and delay a more complicated change to a later fork I suppose we can give people. Well, I don't know. I'd like to go ahead and merge this to keep this moving I think what would help is maybe having either, like, some sort of spec or EIP for the more complex thing, um, to have people sort of have something more concrete to, like, think about. But yeah, I guess. Yeah. Does anyone feel strongly about this or are we happy enough with sort of the, good enough solution for Pectra Yeah okay. Ansgar said he would like the Max and then otherwise. +* Yeah. Okay. +* So then I think we'll directionally move ahead, with 894 and. Yeah. Ansgar, maybe I'll follow up with you to see if, you think we can change something simpler, like in a simple way +* So then what that means is. Yeah, I would hope to then have 7742, sort of the spec finalized in the next week or two and then. Yeah, as soon as we can get implementations, we can start testing this out. Yeah, I guess for Devnet five, maybe some early experiments, even before then. And yeah, can keep this all moving +* There was one more thing for Electra. If there's nothing more to say about that for now, and I just wanted to get an update on the BLS Precompiles. This is more of an EL concern, but we had kind of been discussing there was a question around, effectively the API for the Precompiles, which I think we've kind of resolved. And then now the question was, downstream of that, then doing the gas benchmarking to make everything work well, does anyone here have any updates on that and they may not, but I figured I would ask I don't see anyone on the call who has been closer to this, so okay, that's fine. +* Then we can follow up async so yeah, I think that's all we had today for, Electra. Anything else anyone wants to bring up + +**Mikhail** +* If I may, just a quick, um, thing + +**Stokes** +* Yeah, please. + +**Mikhail** +* I have, Yeah. Thank you. So I have recently submitted a PR, um, which is the PR number 4000, which is sending yeah. It's just basically this PR is about adding a couple of there is a couple of, checks that we do while processing the voluntary exit. And they, for some reason, was not included into consolidation. Processing and consolidation is basically consists of two steps. The first one is to make the other exit. And it makes sense, to preserve the same condition checks +* For consolidation as we do for exit. And we would kind of aligned with that. But for some reason those two have been missed. And this PR just adds them. And yeah, that's the quick announcement. Please take a look. Because basically we want this to be part of Electra + +**Stokes** +* Yeah that makes a lot of sense. So yeah please take a look. I will do the same. And yeah, just from a quick scan. This makes a lot of sense. And this is also something we should do in the next month or two, is just to pass on all these things. Pectra has a lot of features. They all kind of interact in very intricate ways So, yeah, making a second pass on all of this, is super valuable Okay. Yeah. Thanks, Mikhail. So then we can move on to PeerDAS. and any blob questions I guess to kick this off, I will ask if there's any updates on the dev nets. I heard there was something like 100,000 slot reorg on net three, which is impressive + +**Barnabas** +* So we had a massive reorg like, end of last week I think, or beginning of this week. I'm not exactly sure when it happened and we decided to shut down the industry, because it was pretty much unfeasible to recover. At that point. We had only, Prism validating at, at this point, and only, I think one super node So we decided to postpone a relaunch for after, Defcon because everybody wants to focus on rebasing on top of Pectra, and that will take some time And we we would like to discuss whether we can include, pure devs as fully named, future Fork or can we stay or should we stay at a using the EIP 45? Whatever the number is, I think it's 94. + +**Stokes** +* Yeah, yeah. do you have a sense of just on the on the reorg? Do you have a sense of like what caused it? Like did some node eventually release like some data column that triggered this huge fork choice + +**Barnabas** +* Maybe someone from prism can comment on it I think the problem is that the people that are working on this on the prism side, are on holiday right now, so. Okay, I'm not sure if we would have anyone. Yeah. All good. I'm just I'm just curious. That might be the deepest + +**Stokes** +* Okay, cool. Well yeah. So that tees us up to I think the agenda item here, which is moving ahead with this rebase. So I don't have the PR handy, but there is one to essentially. Yeah. Put the PeerDAS EIP + +**Stokes** +* Into Hulu. And yeah, there was a bit of a holding pattern with when implementers were ready to do this. And the timing there I think at this point we should just go ahead and make the merge and, go from there. Anyone feel that we should hold off for some reason + +**Stokes** +* Right. Yeah, I think it's 3.94 here. I looked at the breakout call notes from this week and it said that we had discussed on this call. So my read was that, basically people were ready to do this + +**Barnabas** +* It would be nice to get some input. We got no input on the call. So it would be nice if people have some opinion + +**Stokes** +* Yeah. I mean, the thing is we're going to have to do this eventually. So I think if we can't get an opinion, then we just bias towards where we're ultimately trying to land, which is, going ahead and putting this on top of Electra + +**Barnabas** +* I mean, the question isn't whether we want to have it on top of Electra. The question is whether we want to trigger it as full + +**Stokes** +* What how would like what would. Sure. But what's the alternative? + +**Barnabas** +* The alternative is we keep it as EIP 7594 and we trigger it under that name. And we only include it in full if we are 100% sure that PeerDas is going to make it into full + +**Stokes** +* I mean, that's generally what we've agreed via ACDE. And yeah, I don't see how that would be any different moving forward + +**Barnabas** +* And also if we activate at full, then on the other side that's going to activate Osaka, which will also activate EOF. So it would be good to be able to activate these two features separately in a way so that we don't have EOF + +**Barnabas** +* Problems in peer networks or peer desk problems in EOF networks + +**Stokes** +* Right? I mean, so content on the EL, couldn't we just set basically unset the EOF features so that they aren't responsive to Osaka, even if like there is Osaka fork logic + +**Barnabas** +* Maybe others can comment on that + +**Stokes** +* Ideally, I don't know. I don't know if they're here + +**Stokes** +* Okay. Yeah. I mean to move us forward. Like, again, I would lean towards, moving ahead with all of this, having PeerDas before you have it activate And yeah, this is a good point about EOF and or any like Osaka EIP on the El side So we can definitely discuss this on the next ACD.but yeah, perhaps in the meantime I'll try to get some async information even in the next week and try to move things forward. But I guess what I'm hearing, at least from lack of input, is that there's no opposition to moving ahead on the CL. in this direction Okay then we'll move on to the next agenda item. let's see. +* So I think we had yeah. Lucas, I don't know if he's here, but he has an EIP for changing withdrawal credentials. I don't know if Lucas is on the call but it's here. So, yeah, I think the idea is essentially to have another type of, like, execution change message that would let you change your withdrawal credentials. We've discussed this stuff in the past, and I think generally the sort of consensus has been like, handle this within the execution layer. So, you know, have some withdrawal address that could then point to, you know, a multisig or whatever smart contract where you then have the flexibility to like, manage that policy. +* There but yeah, I guess let me grab the link to this. And I guess the ask for the moment is just to take a look he did say in his comment that basically, he's just looking for feedback and it's very likely to be, something in the future. But if you're interested about this, you could go ahead and put it on your radar + +**Stokes** +* Put it says it'd be nice to have them on the same side Okay + +**Mikhail** +* Just a quick comment on that. So I it this proposal is actually yet another request that we used to introduce Used to have now part of Electra will have the protocol. So it should be pretty straightforward thing I guess. + +**Potuz** +* Yeah it is a really trivial change on the CL side as well. And I suspect on the EL it should be simple + +**Mikhail** +* Yep. Because the complexity will be handled by the yet another system smart contract as long as our request design is kind of good for and yeah, good for extending it. Like for from the EL perspective and yeah + +**Stokes** +* Yeah I gotcha. Yeah that makes sense Cool. Well that was pretty much it on the agenda. Is there anything else, that anyone would like to bring up + +**Stokes** +* Yeah. Yannis + +**Yiannis** +* Hello? It's Yannis from problem. One issue that relates to the blob scaling. part. as you might know, a problem with crawling the, consensus layer network and then using that information where +* We have put together a tool that is probing basically all the different nodes to see what bandwidth availability they have. So that might be we're going to have results soon, but that could be helpful to see, you know, what is the ideal blob increase that should be targeted for the next upgrade or perhaps the one after that if we're too late to have that. Again, I don't we don't have results right now, so I cannot share anything. But, hopefully next week and before the before devcon, we are going to have something so could be some, topic to be discussed there + +**Stokes** +* Great. so you're crawling disk v5 at this link here is to disk V5. And then I'd just be curious, like are you looking at latencies or trying to infer bandwidth or something else + +**Yiannis** +* Sorry. The yeah. The infrastructure bandwidth. Yeah + +**Stokes** +* Okay. Gotcha Cool. Well, yeah. I'll be looking forward to, the results there + +**Yiannis** +* Yeah. I guess there is not going to be a call in two weeks, but, at some point in the devcon week, we could discuss about that Relevant meetings + +**Stokes** +* Sounds good + +**Yiannis** +* Thank you + +**Stokes** +* Anything else + +**Toni** +* Yeah. Very quickly. I missed my turn at translate, but I think you mentioned it already. I just want to put it here in the chat and so that it's, that everyone knows about it. It's basically, I quickly drafted it as an EIP, but I think we we could add it to 7742, but we decided we wanted to keep it as simple as possible. This is fine. It's just a change that would allow us to move away from the from having the target of the blobs always be half of the max. +* So kind of if we want to do, 46 instead of 36, then what we might end up with is some asymmetry when it comes to blob based scaling, because currently the base fee can scale and 12.5% in both directions. +* And I just wanted to yeah, paste that EIP or this draft into the chat so that everyone can see it + +**Stokes** +* Thank you. yeah. We covered this a bit earlier and we kind of decided to move ahead with the simpler thing for Pectra, but I think sort of more, you know complex revisiting of this. And Pusaka is definitely in bounce + +**Toni** +* Yeah. This is this is fine. I'm fine with that + +**Stokes** +* Okay. Well, if there's nothing else we can wrap a bit early. I guess two things to note then. One of them is that. Yes, the call What is it on the 14th. So essentially the next ACDC, we're going to cancel. Everyone will will most of us will be in Devcon, so we'll have plenty of conversations there and otherwise. Yeah. If you're listening, we do have the launch of this, testnet Mekon that is sort of a preview of Petra that's open to the public. And. Yeah, be on the lookout for that. And, yeah, I think that's it. So we can go ahead and wrap up a bit early today. write blog posts for blog post. + +**Barnabas** +* Yep + +**Stokes** +* Yeah. The blog post for Mekong will be coming next week. So + +**Stokes** +* Keep an eye out for that. Otherwise yeah, we'll go ahead and close and yeah, I'll see a lot of you at Devcon. Very excited +Thanks. Bye everyone. Thank you + + + + +---- + + +### Attendees +* Stokes +* Tim +* Arnetheduck +* Marek +* Lance +* Micah +* Paul Hauner +* Ben Edgington +* Loin Dapplion +* Terence +* Enrico Del Fante +* Pooja Ranjan +* Hsiao-Wei Wang +* Saulius Grigaitis +* Roberto B +* Olegjakushkin +* Chris Hager +* Stokes +* Dankrad Feist +* Caspar Schwarz +* Seananderson +* Andrew +* Crypdough.eth +* Zahary +* Matt Nelson +* George Avsetsin +* James HE +* Marius +* Ansgar Dietrichs +* Lightclient +* Stefan Bratanov +* Afri +* Ahmad Bitar +* Lightclient +* Nishant +* Gabi +* Pari +* Jimmy Chen +* Gajinder +* Ruben +* Mikhail +* Zahary +* Daniel Lehrner +* Andrew +* Daniel Lehrner +* Fredrik +* Kasey Kirkham +* Protolambda +* Cayman Nava +* Stefan Bratanov +* Ziad Ghali +* Barnabas Busa +* Potuz +* Trent +* Jesse Pollak + + From 5d20a2fdf3d76acee9a21c2981b93c90dcabc647 Mon Sep 17 00:00:00 2001 From: Aleneth <145821766+Aleneth@users.noreply.github.com> Date: Mon, 30 Dec 2024 09:08:24 +0530 Subject: [PATCH 48/51] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 7df284de..162cc3b5 100644 --- a/README.md +++ b/README.md @@ -248,6 +248,7 @@ The audio files of the Previous Meetings are stored permanently on [Permacast](. № | Date | Notes | Recording | --- | -------------------------------- | -------------- | -------------------- | +145| 31 Oct 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1185) \| [notes](AllCoreDevs-CL-Meetings/Call_145.md) | [video](https://youtu.be/KMLqv60xg9w)| 144| 17 Oct 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1178) \| [notes](AllCoreDevs-CL-Meetings/Call_144.md) | [video](https://youtu.be/p3FRr5umt4U)| 143| 03 Oct 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1158) \| [notes](AllCoreDevs-CL-Meetings/call_143.md) | [video](https://youtu.be/dplciLdQTM0)| 142| 19 Sep 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1154) \| [notes](AllCoreDevs-CL-Meetings/Call_142.md) | [video](https://youtu.be/MRtJSnBU3Gk)| From fec066b4ea5da1cd4965b277a5c81788674472d3 Mon Sep 17 00:00:00 2001 From: Aleneth <145821766+Aleneth@users.noreply.github.com> Date: Mon, 30 Dec 2024 11:46:09 +0530 Subject: [PATCH 49/51] Create Call_146.md Agenda: https://github.com/ethereum/pm/issues/1200 --- AllCoreDevs-CL-Meetings/Call_146.md | 612 ++++++++++++++++++++++++++++ 1 file changed, 612 insertions(+) create mode 100644 AllCoreDevs-CL-Meetings/Call_146.md diff --git a/AllCoreDevs-CL-Meetings/Call_146.md b/AllCoreDevs-CL-Meetings/Call_146.md new file mode 100644 index 00000000..eb747882 --- /dev/null +++ b/AllCoreDevs-CL-Meetings/Call_146.md @@ -0,0 +1,612 @@ +# Consensus Layer Call 146 + +### Meeting Date/Time: Thursday 2024/11/28 at 14:00 UTC +### Meeting Duration: 1.5 hour +### [GitHub Agenda](https://github.com/ethereum/pm/issues/1200) +### [Audio/Video of the meeting](https://youtu.be/HcjuY3WDa9A) +### Moderator: Stokes +### Notes: Alen (Santhosh) + +## Summary +Summary | Description +-|- +146.1 |**Mekong Deposit Processing Bug** Validator deposits on the Mekong testnet triggered major network disruptions earlier in the week on Monday, November 25. The testnet has since recovered and is finalizing again. Several fixes have either been implemented in clients or are in the process of being implemented, said Stokes. +146.2 |**Mekong Deposit Processing Bug** Prysm developer “Potuz” raised the need for more Pectra specification testing in light of the deposit processing bug on Mekong. Consensys Researcher Mikhail Kalinin pushed on this sentiment saying that there are already tests for deposits but client code in some cases is different from specifications and there is a need for more extensive testing that covers client dependencies. Stokes said all types of efforts to bulk up testing for Pectra would be useful. +146.3 |**Devnet-5 Specifications** The first issue is related to EIP 7685, general purpose execution layer requests. It is a corresponding Engine API change to an earlier one already merged and finalized for Devnet 5. The original code change proposes excluding empty items from the “requests_hash” commitment to ensure easier testing and mirror the behavior of other types of EL commitments. Both were proposed by Geth developer Felix Lange. Developers agreed on the call to merge the corresponding Engine API change into Devnet 5 specifications. +146.4 |**Devnet-5 Specifications** The second is an update to EIP 7742, uncouple blob count between CL and EL, to ensure that the gas fee mechanism for blobs correctly scales when the target/max values are updated, even if the target value is not half of the max value like it is currently. EF Researcher Ansgar Dietrichs said that the EIP is “nice to have” but it can be included later in the Fusaka upgrade to avoid delays to Pectra activation. In its place, Dietrichs recommended a minimal “one-line” change to the update fraction in EIP 7742 such that a block without any blobs triggers a reduction in the base fee by less than 21%. In effect, the one-line change would reduce the volatility of negative base fee adjustments. +146.5 |**EIP 7691** The Ethereum Foundation’s PandaOps team conducted a study on the performance of home stakers and solo stakers since the introduction of blobs in the Dencun upgrade. They found that stakers operating on the most resource-constrained devices relative to other types of stakers on the network are performing well and would not be negatively affected by a blob capacity increase to either 4/8 or 6/9 target/max blobs per block. +146.6 |**EIP 7691** Prysm developer “Potuz” was not in favor of an increase to 6/9, while Reth developer “Oliver” was. Wahrstätter pointed out that increasing the target/max such that the target value is not 50% of the max would introduce strange dynamics to blob base fee adjustments, that is the blob base fee would decrease at a faster rate than blob base fee increases. However, developers could address this kink later in the Fusaka upgrade. Dietrichs stressed that rollups care more about increasing the blob capacity than a perfect UX when it comes to blob base fee adjustments. Potuz cautioned against a “radical” change to blob capacity in Pectra and recommended that developers go with 4/8 values. +146.7 |**EIP 7691** In favor of doubling the blob target, Dietrichs wrote in the Zoom chat, “I don’t think anyone argues that a throughput increase is without cost but we have to be willing to make tradeoffs and it’s a very modest ask for very big payoff… We are at real risk of losing L2s to alt-DA providers. That is much more impactful to real-world Ethereum users than any mild extra load for stakers.” +146.8 |**EIP 7623** Related to the discussion on EIP 7691, developers discussed the inclusion of EIP 7623 in Pectra. EIP 7623 proposed an increase to the cost of call data such that the maximum size of Ethereum blocks is reduced. The EIP, proposed by Wahrstätter, is especially important to address a “worst case scenario” in the size of EL payloads given the inclusion of EIP 7691 in Pectra and a potential gas limit increase organized independently by validators. +146.9 |**EIP 7623** Geth developer “Lightclient” was strongly opposed to this code change in Pectra, stressing that even without its inclusion, developers are not ready to implement existing Pectra code changes on mainnet. “I feel like we just had a major testnet failure and should add as few additional things as possible,” wrote Lightclient in the Zoom chat. Stokes agreed that this was the main reason in his view against EIP 7623 inclusion in Pectra. Nethermind developer Ahmad Bitar wrote in the Zoom chat that in his view the EIP should be a “prerequisite” EIP 7691. Dietrichs added, “EIP 7623 is a fix of an active security vulnerability. … This should have been the first EIP in the fork.” +146.10 |**EIP 7623** Others like Nethermind developer Marek Moraczyński and EthereumJS developer Gajinder Singh agreed with Dietrich's comments. Reth developer “Roman” chimed in reiterating that developers should not increase blob throughput without coupling it with a lowering of the maximum block size. Stokes recommended moving forward with EIP 7623 in Pectra. Lightclient opposed the decision again. Stokes recommended tabling the discussion for further input from EL client teams on the next ACD call. +146.11 |**EIP 7251** The final issue related to Devnet 5 specifications that developers discussed was related to EIP 7251, the increase to validators’ maximum effective balance. There is an edge-case scenario where a malicious actor can trigger validator-staked ETH balance consolidations on behalf of another validator. It would require the malicious actor to send the validator their staked ETH in exchange. Albeit expensive, Stokes said it was “a potential attack vector” that Consensys Researcher Mikhail Kalinin has proposed a fix for. Stokes said the fix is a relatively “simple change” and confirmed specs and relevant tests for it would be pushed out post haste for CL teams to start their work on it. +146.12 |**PeerDAS** EF DevOps Engineer Barnabas Busa shared an update on PeerDAS. He said that client teams are waiting on Pectra Devnet 5 specifications before rebasing PeerDAS on top of Pectra. Once the rebase is complete, client teams will move ahead with coordinating a new PeerDAS devnet launch. This is also the status of EOF implementation progress as well, Busa said. +146.13 |**EIP-7805** Thomas Thiery, an Ethereum Foundation Researcher, gave a presentation on EIP 7805, fork-choice enforced inclusion lists (FOCIL). FOCIL essentially enables validators to define a set of transactions that builders must include in their blocks. In doing so, validators can boost the censorship resistance of Ethereum by ensuring that builders do not have full control over transaction inclusion in a block. + +**Stokes** +* We will proceed. Okay. Great everyone. Let's see. This is ACDC 146. It is issue 1200 and the PM repo. I put the link here in the chat. And yeah, there's a number of things here on the agenda today we'll touch on Mekong testnet. The intent is to finalize Pectra for devnet five, and presumably that's the last sort of spec updates we'll need for Pectra itself. otherwise, yeah, there's some other other research things at the end here. So in any case, let's go ahead and dive in because there's quite a bit here. So first, yeah I wanted to talk about Mekong. this was essentially from Devnet four as I believe. And it was a public facing test net. There were a number of deposits, I think Monday or Tuesday that caused some issues. And I think every client, well, at least every CL client had some bug. that being said, the test net is finalizing again, which is very nice. So good work everyone. And in any case, is there anything else we should be discussing here? Any follow ups or contacts clients would like to add are on this bug. Okay, we've got an all good from our side in the chat. Fair enough. Okay, great. So yeah, there are some issues with the deposits and yeah, I think there's a number of different places we can add tasks, just to make sure that there aren't any, regressions. And, yeah, we definitely need more spec test as post calls out here. Mikhail. + +**Mikhail** +* I just wanted to add on the spec test side, we have tests already in the PR, for this specific case and for other potential cases. There is an issue that I've recently opened. so we need tests to cover the epoch processing in a bit different way than it's covered today in the consensus spec tests. So today we use kind of like code coverage metric for like for the epoch, processing tests, which is the code used that is that the spec has. And the problem with the on the Mekong that happened recently was because the spec and the client code are different because clients use caches. So we need to do more extensive testing and find it potentially an ideal situation. We find all these kind of dependencies. When one epoch processing function does the change to the beacon state, and the other function uses this change in its logic. So if anyone wants to. If anyone wants to help with this, with writing these tests, there is an issue. And yeah, I'm happy to to help on that. + +**Stokes** +* Cool. + +**Mikhail** +* Yeah. Yeah. I'll just send a link to this issue. + +**Stokes** +* Another thing to add there is at least I looked at one of the bugs and it wasn't so much a caching issue. It was just like an, you know, an accident, really. And spec tests should catch this kind of thing. one thing to add is the spec tests though, are, you know, I would say primarily more like unit tests. Not so much like Indian integration tests. there are some types of spec tests that start to get towards more end to end things. But that being said, yeah, clients should be careful writing code and, you know, do testing on their end as well and not just rely on the spec test parents. + +**Terence** +* Sort of mutation testing that's happening with the CI/CD. Sorry for the stupid question. I think like a couple of months ago, I went through, basically what I did in Prism is that I started commenting out every single line of the state function, and to see whether the basically the spec will still fail. And then if it doesn't fail, I make a note of it, because that typically means that there is a spec test missing coverage. And then I think I opened like three PRS on the spec test because of that. So I wonder if it's worth doing again from my end? +* Or do we feel like there is sufficient coverage on the spec test today? + +**Mikhail** +* I would say if you if you're willing to do this, please go ahead and, you know, just just do it. But for this particular case, on my own, even if the even if this this spec would have a perfect test coverage And probably it has. In this particular case, it would not mean that. Yeah, that we would reproduce this bug using those tests. + +**Terence** +* Yeah, definitely. Yeah. + +**Stokes** +* Yeah. I think with testing the more the merrier. So everyone should always be thinking about testing from, you know, the more angles, the better. Cool. Well, that being said, we quickly resolved the the bug and I think everyone has shipped fixes or will soon. So nice work. And yeah, anything else on that. Otherwise we'll go to Devnet five spec. + +# Devnet-5 spec [10:30](https://youtu.be/HcjuY3WDa9A?t=630) +**Stokes** +* Okay, cool. So there's a number of things here. let's start with this first one. There was an update to 7685. to change how we handle empty requests with the hashing and the commitment on the EL. So this one. Yeah. So it's a in a bit of a weird spot because I linked the execution APIs PR here. these are the updates for the engine API. There was a corresponding EIP update and then also a CL PR update. The CL specs PR and the EIP have been merged. this has not been merged, but it sounds like just going off of a comment from Felix here on the agenda that there's maybe still some open discussion. my understanding is that we wanted this change and we were going to merge it, and. +* Yeah, I guess we should figure this out now. if we want to walk it back, which I don't really recommend at this point, we need to go and merge some things in other places. So then I guess the question is. Yeah. Does anyone feel strongly against this change at this point? We have support. So. Yeah. And this is my sense. So I think we just go ahead and merge this one in. Okay. + +**Mikhail** +* Yeah. Just Felix wrote that probably we should not, like, have a requirement on a strict order on the engine API and just leave this requirement to the CL side. So the requests are sent in the right order. And this is kind of enforced by CL specs rather than by engine API. This is one of the recent Felix comments. other than that, I had some, you know, some comments about this ordering. Why not doing it on EL, but I don't mind to merge it as is. It's not like super strong, super strong, opinionated that it should not have the order statement in the engine API spec. So if there is a strong, consensus, if there is a strong willing to to merge this as is and there is no opposition from the client teams, then just let's just merge it. + +**Stokes** +* Okay. Yeah. I mean, that sounds like that's where we're at. We're getting support in the chat. And yeah, I think given that we've merged other things that move in lockstep with this one, I think would be a way to merge this. And we can close out this question for Pectra. So let's go ahead and merge it. And that was pretty straightforward. + +# finalize EIP-7742: include? Update EIP-7742: update the required EL headers and the gas fee mechanism EIPs#9047 [13:35](https://youtu.be/HcjuY3WDa9A?t=815) +**Stokes** +* Next up. Okay. So the next I think the big thing here with Devnet five would be 7.742. So let me grab this update And there are a number of 7742 pairs for the feature. They've kind of been ready to go for a while now and let's say maybe like a couple of weeks now ago in the process, as people kind of dug into this, there was a question about changing the fee market, because especially as we go to more flexible target and max values, that's 7742 unlocks. You get to a place where the fee market that sort of was hard coded in 4844 doesn't respond in the best way. So that all being said, there's an update here. It's PR 947. And what we had said from a discussion at Devcon was that we'd have this PR and essentially make a decision today. So there's been some comments on it. +* But yeah, I guess the question here is what's the consensus? do client teams want to include this change or just move ahead with 7742 without it? I'm sorry. + +**Ansgar** +* Yeah. Just wanted to say for for context, that basically this like two different basically like, most of these changes are not very nice to have. They definitely all make the market somewhat nicer. and, and for all compatible like we will have to do this anyway, but we could also do a lot of this in Osaka. And the one thing like if we end up rejecting this kind of bundle of features and that is proposed in the PR, then what we should do is at least have a minimal, change, although I think the better target would actually be the throughput increase EIP itself. So 7691 and which just with just a small adjustment to the update fraction, because if we don't do this, if we basically don't make that one small change, which is literally one line change. And then what would happen is basically after the fork. +* Now any empty block would reduce the base fee by 21%, which I think is a little bit much because basically because because the sensitivity just becomes higher and because now basically we have six blocks under the target in a single block. And and so that would be like a 21% drop, which I think we should adjust that value, which is literally like a one parameter change. So that would be the very minimal change. I think I would recommend at least doing that. The other things are still nice to have, but if clients prefer it, we can do them in Osaka instead. + +**Stokes** +* Yeah, and you're talking about the update fraction. Like we would just change that to reflect the new target. + +**Ansgar** +* Yeah. And there's some ugliness. Like for example by doing that at the time of the fork, the base fee jumps a little bit, which of course this is part of the things that would be cleaned up with this more expensive change. But if we are saying we are going for like the bare bones version here, then we could basically just ignore that. Only change the update fraction. That's a one line change. And and do the nice clean up in in Osaka. + +**Stokes** +* Right. Yeah. So I'm well. Does anyone else have thoughts? I have thoughts on this but. + +**Dustin** +* I yeah just to some extent. So one of the tensions that has come up in these discussions is, is question of, incentive to propagate blobs at all. And so they're obviously expensive and getting more expensive. And there are good for the network as a whole. Yes. But and, and so one of the and it would be, I think maybe we'll say maybe my what I would ideally target and I don't know what other people think about this is actually for the target price, the target market to be a little more to incentivize people to care about. Bob's a little more right now. CLs actually are better off avoiding Bob's mostly, honest validator shenanigans aside. and because they're just not paid enough for it to be worthwhile. And then the trouble is, as soon as you get above the target, it this price ramps up fairly quickly. And so there's not a happy equilibrium really above that either, which would have been otherwise kind of nice. +* So it would be one possibility. I don't know if this is feasible in this particular time frame for for Pectra or if people want this is to explicitly target, a slightly higher like a just enough of a base fee that it is reasonable to for people to actually want to carry Bob's in the same way that people complain when they miss attestations or other things in committee messages, etc. right now nobody complains if they miss Bob, so to speak. But that's a problem with Bob's. And people are being browbeaten into like, you know, you have to have to do Bob's. So yeah, that that's what I'm my thoughts, I guess. + +**Stokes** +* Yeah. I mean, Bob's are a critical part of the protocol, so we should make sure that they're supported. Ansgar has the comment here that you could have, like client side that basically a for inclusion as you build. so yeah, that's an option. And in any case, that was another. Yeah. I mean there was another EIP for raising the floor. that's something we could get into. Tony, you had your hand up. + +**Toni** +* Yeah. first of all, I would agree what Anne said. I think the nice to have EIP can be or they're nice to have. Changes can be postponed until Lusaka. And regarding the question to put them into 7742 or not. I would say we don't put them into there. and keep 7742 and anything that touches the block base fee separate just because I think it's much cleaner that way. And then we can still put like the thing with the block base fee fraction into the ERP that eventually changes the blob to the max. So that could also work. And yeah, I think we have it on the agenda at a later time. Anyway, to talk about the blobs and what Dustin mentioned would basically be something new. We can also think about as a nice to have when we eventually touch the blob base fee. + +**Stokes** +* Yeah, that makes sense. And it does sound like a simple path forward for Pectra, thank God. + +**Dankrad** +* Yeah, I mean, it's two different things, right? We have both the base fee and the tip. And I think there's like confused them a little bit. But what we want Is, like that? Yes. Like, block builders want to include blocks and that's like, that's already possible. Right now you can just set a manual tip at which you include them. It would be nice if like blobs just came with like a little bit of a tip because they do, was like increase the risk of being reworked more significantly and more significantly than other transactions. like I would also be very much for like setting some minimum base fee for blobs and like, I think like it's been really obvious, like, over the last half year, everyone's complaining, oh, rollups don't pay. And like they don't contribute, they are parasitic, which is of course complete bullshit. +* But I think like having a small, just like, base fee would, like, end this, annoying charade where, we will increase blobs a little bit, and then suddenly I will be like, oh, now we're not burning anything again. and like, we'll make it a little bit more kind of a little bit smoother. so I would actually think that it would be a great idea to actually increase the base field a little bit. + +**Stokes** +* Okay. + +**Potuz** +* Yeah, I agree, and I think rollups also agree that that increasing the minimum base fee is something that it's useful. unless we are always on congestion as now. regarding the issue of, like, deep, the markets with deep inclusion, there's a bunch of us that are not really well studied, in my opinion. One of them is the issue. That tip applies the same for blobs that carry execution, that blobs that don't carry execution. And this makes a huge difference for different rollups. That's one thing. The other thing is timing games. even if the builder has the blobs with paint chips. As long as the pool is requesting the headers late enough because they want, they know that they can. And they do this now. then the timing game dynamics changes whether or not you are or not going to include blobs. If you increase the limit to ten blobs, then either pools are going to start requesting earlier and playing less timing games, +* Or they will continue requesting as they do today, and the builder will have to adjust the number of blobs that it includes. so I think these two problems are need to be taken into account and they need to be studied. if we're going to be like counting with tips as to decide on the blob limits or blob targets or blob inclusion event. So I would suggest that we keep it to base fee considerations when we talk about the market until we understand these other sub topics. + +**Stokes** +* Yeah, I think that makes sense. Just around gaining a better understanding of the actual market out there. And a quick interjection. it sounds like maybe from the chat people were confused. So like, right now we're talking about just this one update to 7742 that would touch the market. We are not talking about raising the target or max or anything. We will talk about that in a second. But that's very separate from these basic mechanics where like very zoomed in right now. + +**Gajinder** +* Yep. Just want to add that, I mean this if we don't have any plan to update any target before, I mean, then this PR is basically rendered useless in the sense that it won't add any value. But if we are trying to update the target, then this PR is a bit relevant. Although we can also update target with with some hard coded update fraction like we have done in 4844. But I feel that, this is, this is a good way to go forward. And, maybe we can even have time based target unlocks, with, Osaka. But, yeah, that can happen. That can this PR can be merged with other PRS at that point as well. + +**Stokes** +* Right. So I mean, the question answer now is do we. Yeah. Essentially like how like what what is good enough. We could do a very simple thing. Like there does seem to be quite a bit of demand to raise the target, and max in Petra. And because of that, then we can ask about the fee market. And this current PR is one proposal, another proposal that Ansgar Antonio were just talking about, that is even simpler, is just changing, essentially this update fraction that we have That would do exactly what we want. That's like literally a one line change. You're changing a constant. This one that is under discussion at the moment has some normalization involved. It's a little a little bit more complicated. So the alternative would be to do like they were suggesting, like we just change this update fraction. And then we kind of bundle this with a number of other things because as we're discussing, there are other things around the markets that we could imagine changing. I don't think they're quite, you know, in the endgame state. +* So that would be the idea is to go ahead and do the simple thing that works now and then hold, you know, these more invasive changes off until pusaka. + +**Gajinder** +* Yeah. One thing I want to add, so there are two changes in this. One is normalization, which which as you are saying is a bit more complex. And the second thing is to, to add targets. target blobs per block in el header. So maybe I think we should at least keep that one. + +**Stokes** +* Well, that's already in seven, seven, four, two. + +**Gajinder** +* Okay. All right. Thanks. Yeah. + +**Stokes** +* Okay, so we have, essentially a plus one from Tony to what we just described, basically ignoring this update for now and just bundling it with Pusaka. Then in Petra, this is a topic we will get to soon. around actually changing the blob counts and yeah, just having some some for to for that possibly with updating this update function there. Does anyone feel strongly about doing this more invasive change at the moment or would you rather go the simpler route? + +**Ansgar** +* Sounds good. Yeah. Just just to say basically like I also said it in chat to me, there's three questions. It's the definitely do the simple definitely do the one simple change which is the um update fraction. and then probably it seems like the majority wants to push the bigger change the normalization. And that was working on to to Lusaka, which would then still leave. The one extra decision that we have to make is, the minimum base fee change. That's the one that Max Resnick originally proposed and argued for just now, like five minutes ago on this call. And we can also push that to, for Osaka. It's basically in the middle of those two. It's like small but not a one line change. And also nice to have, but not as important as the other one. So basically we should still, if we want to do the the very small thing and push the very large thing, then we should make the an extra assessment of the the. We also want to increase the minimum base fee in in Petra. Or do we also push that to Vaisakha? + +**Stokes** +* Yeah. Well, does anyone have thoughts? I would say it's like pretty late in the game because my sense is that Max is VIP. Well, I guess that's a question. Like, was Max's VIP ready to go? + +**Ansgar** +* It's almost a one line change. The only reason it's not a one line change is that we would have to basically at the time of the fork, then reset the excess gas to zero. So basically there would also it's like basically it's two lines. It's like in the in the way you now calculate the excess gas. There has to be an if statement. You know, if it's the time of the fork return zero and and and change the one value. So basically like the max gap is like a two or 3 or 4 line change. But my in my understanding is that that is not fully specked out. I think he only specked the one line and not the if statement. + +**Stokes** +* Right? Yeah. So I'm trying to ship Petra, and my concern would be that if we take another cycle to get that ready, Already, then it's just going to delay things even further. So I guess I'd want a sense of like how important raising the base fee would be. Or maybe I'll say minimum fee. yeah. My sense from previous conversations is that there wasn't, like, strong consensus that it was super urgent. + +**Gajinder** +* Although the normalization with 9047 is that it will give a nice treatment to the current excess gas that is out there, and make sure that when the target is updated, that is sort of taken care of in a nice way and there is no irregularity. So that is something that is there in 9047, which could be considered. + +**Stokes** +* Sure. But then that's still a slightly different point to actually raising the minimum fee. There are some comments in the chat that this is a nice to have, but not existential. Do we all agree to that. Anyone disagree? I don't know. Just so strongly about this. Okay. Yeah. Peter. + +**Peter** +* Yeah. No. Um. Just. Sorry, I just joined. this is seven seven, four two. You're talking about. Right? + +**Stokes** +* Well, we're talking about a number of things. So right now we're talking about raising the blob base fee. So right now, the way the protocol works is it's a one way. And there have been proposals to raise it to some higher number. + +**Peter** +* Okay. Yeah. I mean, I feel it isn't existential, but like if we're going to do, a version of seven, seven, four two, we kind of have to because otherwise, because we don't want the consensus layer to have to deal with greater than 60 four's. + +**Stokes** +* Right. So this would be within the domain of the L, and so the CL should be fine there. + +**Peter** +* So I think we're forced to do it eventually because we're talking about if we do, if we do a version of 742, this is a prereq. + +**Stokes** +* No. So the thing that we're talking about now is essentially a number that's only on the L, so the CL never has to deal with it. + +**Peter** +* I guess I'm confusing something else. + +**Stokes** +* So yeah that's okay. No, there's a number of things in play at the moment. okay. So it sounds like from the chat there's support to table this for the min fee. just because. Yeah, I really would like to move things forward here. I think we all would. And if we, you know, again, take more time, then it's just going to delay Pectra on our. Oh, okay. + +**Ansgar** +* Sorry, I just wanted to briefly ask because we want to actually get through freeze. And so if we say we go ahead and I mean, obviously there's still in the next agenda point for, for the actual Bob throughput increase, but assuming we decide to go with a Bob throughput increase, then that it does require this one small adjustment to the update fraction. So the question is what is the timeline there? What is the process there. Do we do that async in a PR who's going to open the PR. There's different alternative options for the for that update fraction. I think it's insignificant enough that we can just say that we will figure that out in the PR and just go with anything that has weak agreement over there. But like how do we basically what's the timeline on that decision? + +**Stokes** +* Yeah. Well, it sounds like we should just get into that now. I think there was a suggestion just to put it into the 69 EIP, which is EIP 691. I think that's perfectly workable. So yeah. Ben. And then we will talk about the blob counts. So, Ben, I don't know. You had your hand up. I don't know if you had. Sorry. + +**Ben** +* I think I think the min fee is related to the blob count. So if you're not touching the blob counts, that's fine. But if you. If the blob counts are changing, then the min fee becomes more important because it will immediately crash the market and go back to one way or one way, which is like a crazy small amount. I mean, the way fraction is used to be able to calculate the fractions of gwei. It's not used as a you know, you wouldn't launch a token on Uniswap. It one way. + +**Stokes** +* You could. + +**Ben** +* Know, but well Uniswap would break because it can't handle there's no decimals. Further. There's no you can't go smaller. You know what I mean? So you either. Yeah. Anyway, I mean, so if you're going from, let's say you need to put the price up. where do you go from one one way or you can't put it up by 10%? You have to put it up by 100% because there's no you know, there's no fraction of a of a way, for example. + +**Stokes** +* Right. Yeah. Francis, do you. Yeah, I guess I do want to move to the blob counts, but. Yeah, yeah. + +**Francis** +* Yeah, that's that's why I'm suggesting, like, because I think a lot of this depends on, like, what kind of target do we want to set, right? + +# Include? eip7251: Do not change creds type on consolidation consensus-specs#4020 [https://youtu.be/HcjuY3WDa9A?t=2103](35:03) +**Stokes** +* Okay. Yeah. So, we will come back to this next agenda item. there is a change to 7251. But since we're already here, let's talk about the blob throughput increase in Pectra. Extra. So to kick things off, I think many of you have seen this EIP already. 7691 which proposes raising the target to six and the max to nine. I'll just grab the link here and maybe to kick us off. Sam wanted to give a quick overview of some work that, he did. Is Sam here? + +**Sam** +* Yeah. I'm here. I think we were going to actually get to present first and sort of combine them. + +**Stokes** +* Okay, sure. Yeah. Yeah. + +**Parithosh** +* I'm just gonna give a bit of context first. so there was concern, at least in the past, to, that we're going to have issues once we increase the blob count in terms of, long range syncing as well as how the network heals. Once there was non finality. So in order to collect some data we did do some devnets over the weekend. You can find a summary over here as well as a deeper blog post on the topic. But the TLDR is that we're not. At least the indication from the devnet is that we're not purely bottlenecked by bandwidth. There are some optimizations that could help sync as well as peer performance, but all of these optimizations are something we're going to need to apply on mainnet. Today, even with the current three six limits, and at least the indication is that, even if we were to increase the block count, we wouldn't necessarily, immediately suffer that we would be able to handle an increase. in order to the question of what we can increase to. I will pass it on to Sam. + +**Sam** +* Yeah, thanks. I'll just share my screen. I hope everyone can see that. yeah, I'm Sam from the panda ops team. I'd just like to quickly go over this post I made yesterday about block arrivals home, stakers and bumping the block count. we as a team recently just started ingesting data from community members who are running nodes at home, and this is what made this analysis possible. so a quick shout out to those community members. so our analysis mostly focused on the case where blocks are being built locally by home stakers and then observed by home Stakers on the other end. home stakers are the most bandwidth constrained participants in the network. and this makes them particularly sensitive to any increase in the block count. so we asked three questions. the first question was how is three target and six Max performing today for these users? And it appears to be pretty good. most bundles are arriving well under this four second deadline. onto the second question. +* Does the arrival time of these blocks and and blobs, scale with the count? And. Yeah, to the surprise of really no one. It does. so under the the third question here, how can we how much more can we actually support our main net? the long story short is that we believe that both for target eight Max and six target nine max are achievable. As far as arrival times are concerned, it's just one piece of the puzzle. yeah. While this analysis made some pretty naive assumptions, I. Yeah, I personally believe these numbers are realistic and safe. we also on the way just forecasted how this would look with EIP 7623, which reduces the maximum compressed block size from 1.8 +* Meg down to 720kB. and yeah, in this scenario, even in the worst case scenario possible, it's still possible to do a count bump. that's pretty much it for this. I'll throw the link in the chat if anyone has any questions, hit me up. + +**Stokes** +* Cool. Thanks. Ahmad. + +**Ahmad** +* Yeah. so one thing that I'd like to mention here is that there is also a push for raising the gas limit for the, L1 gas in general. And, this needs to be taken into account because this raise will probably bump up the block size to around 1.1, even with 7623, 1.1 or 1.2 mix. because like the bump is to around the maximum of 45 million, or something like that. So might be also play an effect here. + +**Oliver (Reth)** +* We think not pumping the block count would be a big mistake in Pectra because we're like essentially waiting for pure times to scale blobs. But that's in Osaka. And there's no, like, clear timeline on Osaka. and it's already pretty apparent that from the presentation that basted a few days ago that they are looking at needing more blobs on top of all the l2's, being announced at the moment that they're also going to launch a mainet. So it would be a huge mistake in our eyes to not do anything at all. We think 69 is preferable, but I see in the chat that maybe 510 is easier to do, and I think we'd be fine with that as well. obviously I'm an EL dev, so from my perspective this seems pretty easy because we have 7742 now, and I don't have like a full view of exactly what changes need to be done on the CL here. So I would like some input on on what CL devs think. + +**Stokes** +* Yeah, thanks. So we do have this EIP for 69. And from what I've seen mostly in the chat over here that there's some concern that 69 is not a perfect double. So yeah I guess I'd like to hear more about that. My understanding is that really the only issues there were that it would make the fee market, you know, have some weird kinks, but it's nothing existential. Toni. + +**Toni** +* Yeah. One of the issues. I wouldn't even say it's a it's a big issue. But if we kind of move away from the target being half of the max, then what we could end up with is the base fee, double base fee scaling, faster in one direction than into another, which is not a big problem, I would say. So six nine should would would basically work as 510 would work. So I don't really see a concern there. Why six nine would be from the base fee perspective, worse than 510. + +**Ahmad** +* I mean, in in the case of empty blobs, you will get the base fee going down a lot, whereas with full blobs you will get the base fee raising less than that. + +**Toni** +* So yeah, this is true. This is this is also one of the points that we talked previously about about those blob base fee improvements. There is one point called making it symmetric again. And by doing that we can also kind of account for that. So we agreed earlier on that we might want to do those optimizations at a later fork. In this case, if we say that this asymmetric block base we update is a big problem, then we should stay somewhere where the target is half of the max. + +**Stokes** +* Oscar. + +**Ansgar** +* Yeah, I put I put some examples in the choices we could have. So indeed with the camp mechanism, the sensitivity of of an empty block and a full block would be different because say for example, for six nine, right. Like if an empty block is six blocks under target and a full block would only be three blocks under target. So we could say be very sensitive to downside, then we would have 21% maximum decrease and 12% maximum increase. But we can also choose the opposite. So like 11% maximum decrease like today. And then it's only a 6% increase or anything in between. Right? Like literally this this update function, we can literally just pick any point of that curve. It will always be more sensitive to the downside than to the upside. And the reason why I strongly would argue for six nine over asymmetric change is that in both cases, only really the roll ups are concerned as consumers to blobs the network doesn't care about like about a slightly more flaky, base fee. Right? Like that's only UX problem for roll ups. +* And from talking to roll ups, it really seemed like they are much, much more concerned with overall throughput than the UX of a slightly more, volatile base fee. So basically they they would much rather have overall more, more room. yeah. And they're not so concerned about the base fee. So of course, I mean, we have other concerns here, right, about average throughput levels and all these things. But in terms of like the base fee, I don't think we would actually act in the interest of the people that we're trying to protect by, by avoiding this asymmetric base fee situation. + +**Stokes** +* Right. Which argues for like six nine over say 510. Because the point here is to raise the target as much as we safely can. I think it was POTUS. I'll just go in the order I have here on zoom. So POTUS. + +**Potuz** +* I want to give a perspective on Sam's result. While it looks as though that increasing to those numbers would be safe when we are in congestion, when actually blocks are needed to be posted regularly, then we would be in a situation where we hit on every slot the maximum if the builders are behaving correctly, and then if you see for 9 or 10 for limits, then you're reaching a point where all of those blocks are being trying to be reordered at least five. Not all, I'm sorry, at least 5% of those, because the line of the 95% is very close to the $0.04 to the four seconds. And this is without counting execution, without counting validation, and without counting for choice on clients. so your blocks are arriving near the deadline, which is four seconds, and we need to steal a test. We need to process, and we need to make a signature out of those. So I would expect that at least 5% of those blocks are going to be being reworked. Besides the validators, like losing the attestation and instability in the network, if we see every single block 9 or 10, my proposal would be to not do something radical this fork move to 48 that we kind of know that we can handle. +* Probably 58 if you want to increase the target. 68 my work. But I wouldn't increase the limit without more measurements. + +**Stokes** +* Okay, Sam, I imagine that you're in response to what Pete is saying. + +**Sam** +* Yeah. so, like, the analysis was done off the beacon, event stream and the client submit those events at different times. it essentially looked at each slot. The latest time for a client to emit the head, the maximum blob sidecar or the block event. So I don't actually know. I guess it's a client specific thing on when those events are are emitted, but it's probably worst case scenario at like every stage of this. And reality is that like we're we're actually way under when we say that like 5% of those blocks will be coming in after four seconds, that's. Yeah, probably like a bit too much, I'd say. I'd say the real world picture is way better than that. We've just left it there to be as safe as possible. and this is also 5% of, of, like, home users, not 5% of the network. I know we care about home users, but yeah, it's just worth bringing it up, I think. + +**Stokes** +* Yeah. Thanks. Thanks, Rob. + +**Dankrad** +* Yeah. So I want to say something about the limit targets. I think like, in terms of predictability and everything. Like right now, at least like most roll ups, like what we're seeing now, people starting to build. Base roll up. But other than that, the timing of when roll ups get their blobs in is, like, not very important to them because they like sequence separately anyway. So I think, the, the only concern about it is really the, the potential economic attacks that that can be done. Like basically I think at six, nine, like one third of the Stakers could potentially just like, set the base fee to the minimum and start extracting value via the tip. So that's like the classical EIP 1559, economic attack in quotation marks. But I just think like that this is at the current Karen stayed just like a very, very unlikely scenario. And, like, we should just, eat that and, like, basically, like, as soon as we can, like, put it back into the, in the normal range and then, like, it's much more important to temporarily have this target increase. + +**Stokes** +* Right. So, yeah, I am hearing a lot of support for six, nine. I think one way forward would be six nine. and then a simple sort of patch would be changing this IP to include the target value that we want or. Sorry. Let me be more specific. I mean, the update fraction that we want to help the few markets. In the meantime, anyone want to argue against what I just said six nine with the fee update? Yeah. Miguel, you had your hand raised. I'm not sure if you want to respond to what I said or something else. + +**Mikel** +* No, it will be something else. Okay. + +**Stokes** +* Well, is it relevant? Because I would like to go ahead and just make the decision now. + +**Mikel** +* I mean, is it slightly related to this problem? We already have a session in Bangkok. When we were discussing the whole bandwidth measurements that we were doing. We've been able to do these measurements from other regions in the the geographical location. I can share the screen and show some graphs if there is time for that. But otherwise, like something that I want to raise is we are going to post this anyways around tomorrow. But the idea is that the all the tendency to say that six nine is fine. It's basically on the idea that you still have bandwidth, peak bandwidth available to download everything. Like what happens if you see that people struggle to to fill that bandwidth, like eventually you just get things worse. And it's like, what I want to say is that it's not linear. and what we see is that from home staker like, pretty much half of the network has less than ten megabytes per second. And increasing the target and the max like that could pretty much become a bottleneck when you're trying to resync stuff. I think that this was also something raised by Paul and Nishant on the discord channel. So yeah, I don't know. I would like to bring a bit more of the concern about having such a big increase. + +**Stokes** +* Right? I mean, that is definitely important data. but it sounds like it's a little bit different than the analysis that I did. so I'm not sure if there's a discrepancy there. Dan can. Tell you what. the hand was raised on zoom. Oh, sorry. Maybe. Yeah. No, it's all good. Ben. + +**Ben** +* And that is an important point. if the if we're running at sort of nine blobs per block. Isn't that a problem if you're also suddenly if you're snap serving, will you start losing stations? Because that's also. + +**Stokes** +* So. Yeah. I mean, there are a couple of things here. So you know, the max, like we wouldn't stay at the max for a sustained period of time. It'd be very expensive to do. and then, you know, I guess another thing to note is that we did do some, like, sneaking experiments to this point, and that was, you know, considered in the suggestion from panda ops around their work for 69. So my understanding is that at least with respect to the work they did, they feel this is safe to do. + +**Potuz** +* I think there's a misunderstanding in the chat regarding timing games, and how builders will react to the the cost of like the probability of reorgs of their Software blocks by including more blocks. It's not so easy that the builders are going to now charge more tip, and then they will include those blocks because they might be more likely to be reworked. But the situation is that the proposer doesn't have a visibility over this. So the proposer that is currently requesting the header late enough makes that decision. So if the pools are requesting late enough, then the builder is forced not to include blocks, even if they will. If they would include blocks with a higher tip, they would not when the request for the header comes already late. So this is not a. This is a matter of like the chicken and egg. And I think people should keep this into account when they are thinking about higher limits. + +**Stokes** +* Sure. But if this happens then you know the blob producer would start paying a higher tip, the builders more incentivized to include them, the proposer they. + +**Potuz** +* Are not because the header comes late. That's the point. The header. All the request for the header comes late and the builder doesn't have a control over this. The pull request from the builder at the time that the pool decides if the pool were to, like, start adjusting their timing games because of this extra tip, that could be something. But the thing is that the pool doesn't have visibility over these numbers. + +**Stokes** +* But the builder would have already made the block with the blobs in it right. + +**Potuz** +* At the time. The builder would change the header the according to change the block according to when the header is being requested. If the header request comes like ten milliseconds before four seconds, the pool builder would include zero blocks because they know there will be reordered. + +**Stokes** +* Okay, so I do think timing games are relevant to consider here. That being said, let's zoom out a bit and circle back to my question. So six nine. And that's the fraction change for eight. Okay. So there's okay Oliver. + +**Oliver (Reth)** +* I just want to quickly ask, um I know like obviously this is very late in the process. We want to freeze picture and all that. what is the potential delay here? And is there anything, my team can help on alleviating the delay? Like, I would imagine it's mostly testing. Correct or incorrect. + +**Stokes** +* I think that would be most of it. And just any analysis, you know, that we can squeeze out of the network basically. Mhm. Okay. Terence. + +**Terence** +* So I'm not aware of any consensus client team that has implemented in a way that you have fought to a different block number that the max and target are different. So we're working on a PR right now. I presume other consensus layer client team are working on PR right now. So after that's done we need testing basically. But yeah, this is something new to us. + +**Stokes** +* Right. Which is what 7742 introduces. So it's not really a surprise but it is new. Okay. So right I mean I guess there are some there's some demand to consider for eight over six nine. I think we've narrowed it down to at least those two. From there I would lean towards moving ahead with six nine again just to provide the most bandwidth that we can. And you know, if we are a month or two down the line and have some reason to think four eight is better, we could always change that. because what we can start doing today is everything around. You know this change. 7742 and any updates? The actual numbers will, you know, ultimately be a configuration change. So it is easy to scale back down. You know, if we really feel like we need to. So do we feel okay moving ahead with this with six nine and the fee update. Okay. I'm just going off the chat their support for this. So let's do that. And I do think it is important to keep doing analysis here. If we find something that is really going to change our minds, we should definitely discuss it as soon as we can. Okay, cool. So I had another note here, which is, you know, let's live in this world where we're doing six, nine. +* Do we want to include seven, six, two, three? I really think at this point we should only be thinking about things for network security, for spectra. So, for example, you know, I would think it would make less sense to talk about raising the base fee for the blobs or, sorry, the fee for the blobs. but this one actually impacts like worst case block numbers. +* So I think it's at least worth discussing. yeah. Tony, you have something to say here? + +# For any given adjustment, do we want to include EIP-7623? [58:01](https://youtu.be/HcjuY3WDa9A?t=3481) +**Toni** +* Yeah. Quickly. About 7623. I think we should, ship it together with the blob increase. And this was, the plan for 7623 for quite some time now. So if you remember, it was, CFI for months now. because we were always unsure if we will ever touch the blob count in spectra, and without touching the blob targets 7623 wouldn't have, had that impact really, because now the actual median throughput will increase with the target increase and 7623 only touches the worst case scenario. So I would argue that with the increased, maximum block blob count. We should also decrease the maximum possible EL payload just in order to make sure that. on the side, EL cannot have like almost 20 blobs in size while we are discussing. Like 1 or 2 more blobs on the CL. + +**Stokes** +* Right. That's a good point. I will surface, this comment in the chat from my client. I think this is probably the main argument against 7623, and Pectra is just that. It adds more things to do, and there's already way too many EIPs. We just had a pretty bad bug on Mekong. So it's not that, you know, it's not that we like are super ready to go. And this is just like a marginal add. It will add complexity to, you know, the whole fork. And yeah, we need to make that decision carefully. I don't know lightclient if you want to add anything. To your comment. + +**Lightclient** +* I mean, I think we need a picture and I'm just worried about adding more stuff when I don't think that we have super high confidence on either the EL or the CL about what we have already committed to shipping in this fork and saying this is an active security vulnerability, but no one is actually taking advantage of it. So I don't really think it's that big of a security vulnerability. Should we fix it at some point? Yes, but I see not a strong reason to fix it in the next fork. + +**Stokes** +* Yeah, there are a lot of emoji reacts to his message though. anyone want to say something else to 7623? + +**Terent** +* Yeah. For other people, doing emoji reacts. maybe 2 or 3 of them should unmute and share that perspective. + +**Roman** +* The point that has been made multiple times, but we cannot safely increase the number of blobs without decreasing the maximum possible size of the block. This is my reasoning for adding the emoji reaction. + +**Ben** +* Then, if we're worried about increasing the gas limit because of 7623 and you know you're compounding it with increasing the blobs if you don't have it in, this is the same issue. + +**Lightclient** +* So why did we agree to ship a blob increase before agreeing to do the thing that apparently is the prerequisite for the blob increase? Like now we're kind of just giving this as a writer because we agreed to do a blob increase, and we're just saying that we should, you know, it's a prerequisite. We have to do it too. + +**Stokes** +* I feel like it's always been sort of in the meta, at least over the last couple of months. So this is just now the time to discuss. + +**Toni** +* Tony. Yeah. No, I just wanted to say the same. So it was always kind of bound to the to a potential blob increase or a gas limit. gas limit increase, which is also still in the room. And yeah, for that we were basically saying now for months that 7.623 will be kind of this measurement against yeah, any DOS attacks that might originate from scaling, scaling everything up? + +**Stokes** +* Okay, so I'm hearing a lot of support for seven, six, two three along with the block increase. So let's go ahead and move forward with that. Anyone opposed? + +**Lightclient** +* Opposed. Guys we're adding three EPs in a call after we just had a three fork test net bug. + +**Toni** +* It's two EIPs, right? It's the blob increase and 7623. It's the. + +**Lightclient** +* Blob increase. 7623. And the fee change. + +**Toni** +* But the fee change is in seven six, nine one because it's basically only. Yeah. + +**Lightclient** +* But there's discussion about putting in its own IP. So yeah, you know we could put these all into one EAP. But these are like three conceptual changes. + +**Stokes** +* Yeah, I mean, I would like to decide today. However, I think there's grounds for making a decision on this on next week's AC, DC because this is primarily an L change. I don't know what would change in the next week, though. Francis. + +**Francis** +* I want to provide a like raw data that I collected, for like 7623. So although the serologic, like, block size limit is 2.8MB. Now, from my kind of like analysis over the last like last month or something, the P9 999 block size is like, well under the like 700 or 500kB. So theoretically this could help, but it could be like in, in the real world, you could not It would be like, okay, it's not that big of a deal, but I think it could be helpful to include that if we are worried about the worst, worst case scenario. + +**Ben** +* Maybe you'll be running for, because the base fee being one way, you'll be running an hour at nine blobs per block before it gets to anything that's even remotely pricey. so then you're opening up plenty of time for somebody to start sticking in vast, sized oversized blocks for no purpose, just for fun. + +**Lightclient** +* Okay, what is the failure case here? If someone does do this. I haven't really heard a compelling argument for what actually happened to the network. Like you don't kill the solo stakers if this happens. So are they offline for ten minutes or are they offline for three hours? Did you kind of keep them offline or like a very low participation? permanently. What's I mean? + +**Ben** +* I mean, you won't pay the gas for the block. That didn't happen. So you can keep putting it back in. You. + +**Lightclient** +* Don't think that there's that much of the network that's going to be negatively affected. This like we're talking about, like the bottom 5 or 10% of validators. + +**Ben** +* From what is it, 13 megabyte blocks with um. The addition of nine blocks, 13MB uncompressed. + +**Lightclient** +* Like, what's the compressed value? The compressed value is like 2.5. + +**Stokes** +* Okay. I would like to make a decision today and there's some chat to that end. I would lean towards including this myself. It sounds like only like client is the one opposed at this moment. Um. Okay. I mean, that being said, I do feel like we probably want to, like, have signed off on this because they're going to be the ones implementing it. So that does really motivate pushing it to next week, I guess. Is anyone opposed to that? The downside is just we have one week less of, you know, a spec freeze. Yeah, I'm saying six nine today and then TBD 7623 next week. And yeah, that's the suggestion. + +**Lightclient** +* Yeah I'm happy with that. + +**Stokes** +* Some thumbs up. Okay. Lots of thumbs up. Cool. Okay, great. So let's do that. And yeah, if you're here and or if you're an El client listening to this, please have a view for ACD next week. Cool. Okay. thanks everyone for that. There's a lot of discussion there, but it's a very important topic. I think that's everything on the blobs we wanted to touch on today. Let's circle back to this item that we skipped over with the sequencing of the agenda. So there was a PR to update how consolidations work under 7215. And yeah, basically, so I think where this is coming from, is that the way that Electra is scoped now, you could essentially trigger a consolidation for any validator, not just the ones that you control. And that's weird. you know, you it would be a very expensive attack, but you could imagine someone you know is wanting to troll some other validator and basically force a consolidation on them. So there is some back and forth on ways to address this. And we got to this. PR 4020. Mikhail, I'm not sure if you want to say anything else. this is from you. in any case, yeah, it looks good to me. I think we should go ahead and move forward with this. +* And, yeah, I would rather go ahead and agree to this today rather than wait another cycle. in the interest of a spec freeze. Yeah. So maybe, just maybe just add one more comment. From what Francesco said, it would cost you your stake. So it is a very expensive attack, but it could be done right. + +**Mikhail** +* You still can do consolidation. So. But what this is about. Yeah Sorry. + +**Lightclient** +* Sorry. Go ahead. + +**Mikhail** +* Yeah. There was a concern that it could cause some. So basically, this PR prevents, the target to be switched to compounding. So if it's compounding, the anyone can do consolidation to the target. And the concern was about that anyone can switch any validator to compounding credentials. And that can have some legal implications in some jurisdictions. So that's that's one of the reasons. The other one is the we have just this, in this place, the There is the way to switch to compounding upon request and in protocol, we have this automatic switch to compounding on consolidation two, which is a bit of a quirk in the design. So we're just removing that as well. And yeah that's about it. And also yeah there is the the UX trade off. So if you want to consolidate your validator you will have to first switch to compounding target and then do consolidation. This is going to be two different requests. And but that's not a big problem because if you have like say ten validators to to consolidate you should just do the switch once and yeah, then send those to ten messages or ten requests for consolidations. +* If you are a soul taker and you have just two validators, you want to consolidate them, then it will result in two messages instead of just one as per existing logic. So it's not a big UX reduction. And also to a bit alleviate this UX thing. I think we should increase the max consolidation requests to to two instead of one. So we can basically switch to compound and then do consolidation in one block. + +**Stokes** +* Yeah, I think that makes sense. And I guess one other point here is like this does actually simplify, like the whole state transition, just thinking about validator lifecycle states and how you transit between them. so I really like that. There was the here. + +**Lightclient** +* Is the compounding. Just get set today by whenever you have something as the destination of a consolidation, it becomes compounding. And the problem is that you can set any target without authorization from the target. + +**Mikhail** +* Yes. One of the concerns come from that. + +**Lightclient** +* So now you're separating the compounding from consolidation. + +**Mikhail** +* Right. So you cannot do you will have to to authorize the compounding switch first before doing consolidation. + +**Stokes** +* Yeah. And I'll just waste Francesca's comment here. It is a very simple change. And I think it does simplify things quite a bit, which is nice. + +**Lightclient** +* How do you authorize it ahead of time? + +**Stokes** +* How do you. Oh, sorry. What was that. + +**Lightclient** +* Like? Today we authorize consolidations by looking at the like, using the message sender, comparing it to the ETH one credential. Is it going to be like that again or is it different. + +**Stokes** +* No it's the same. Okay. + +**Lightclient** +* Sounds good to me. Yeah. + +**Stokes** +* Yeah. This just restricts what you can do basically. Okay. So I think the people who have looked at this before this moment are in favor. And it sounds like there's. Yeah, some support on the call as we talk through it. anyone want to avoid this? Not move ahead. Otherwise, I think we go ahead and do it for Pectra. Okay, great. Let's see. Yeah. So it does need testing. But yeah this is something that we can get to the next release. And yeah. Mikhail I can help you get this tidied up ASAP so we can keep things moving. Cool. + +**Mikhail** +* Yeah. Also requires the update to the consolidation smart contract to bump the max value from 1 to 2. But it's trivial change. + +**Stokes** +* Right? Okay. Yeah, we should track that. It is worth noting that it's okay if that doesn't change in the smart contract. It would be nice if we do it. It's not the end of the world. Cool. So let's see. I think that was everything for the next Devnet spec and should have picture in a pretty good spot. okay, we don't have a lot of time left, so we'll just keep going. Okay. I guess. Were there any very quick updates with PeerDas or anything? Any Devnet there? My sense is that they've kind of been waiting for, Pectra to settle down. + +**Barnabas** +* Exactly. So the idea is, that process is going to launch once factor five is, stable, and then everyone can revisit their code. I think most of the CL are already working on a S3 based on top of Pectra, so we didn't want to complicate things by launching some very old spec. + +**Stokes** +* Yeah. + +**Barnabas** +* Yeah. The same. True for update, by the way. + +**Stokes** +* Okay, great. + +**Barnabas** +* They both expect to arrive once Pectra five is stable. + +**Stokes** +* Okay. Sounds good. Thank you. + +**Barnabas** +* And for Pectra devnet five, then we can probably calculate with A69 change already, right? + +**Stokes** +* Yes. Yeah. So Devnet five would be essentially the final Pectra spec. + +**Wei-Wang** +* Can we confirm the scope of the Pectra Devnet 5? Definitely. Right now we talk about many. Sounds like. + +**Stokes** +* It sounds like 7623 is still up in the air for next week. I did want to leave some time for the other agenda items, but yeah, I guess. Are there any specific questions right now? Shall we? + +**Wei-Wang** +* Do we have for the CL update? Do we need to wait for this discussion before we got the release? + +**Stokes** +* Not for 7623. That's a good point. So let's see. Right. So from this list here on this issue, 7691, which is the throughput increase that would need an update for the target or. Sorry I keep calling it out. The update fraction. Let's see. Do one of the authors want to go ahead and handle that change? Mike Perry. Tony, Sam, Andrew, some of you are here on this call. Okay. We at least got a thumbs up from Tony. So, yeah, if we could do that, like. I mean, today's a holiday for some of us, but yeah, if we could do this, like, in the next day or two, that would be great. Okay, Oscar says he's writing one right now. Perfect. cool. So. Otherwise, yeah. This list, looks pretty good. Shall we? This issue 4026. I can follow up with you after, and we can double check everything if that sounds good. Cool. Okay. +* So I think that was everything on Pectra and or PeerDas to discuss at the moment. again, very nice work everyone. I'm getting to this point. +* Been a big one. but yeah. So now let's keep moving to the agenda. next up, we had a request to discuss another EIP 7805, which is fossil, and this is a solution for resistance. Uh. Let's see, so I spoke. Are you on the call? + +# EIP-7805: FOCIL [https://youtu.be/HcjuY3WDa9A?t=4718](1:18:38) +**Thomas** +* Yeah, yeah. I'm here. Hey. + +**Stokes** +* Yeah. yeah. Take it away. + +**Thomas** +* Hi. Thanks. I'll share my screen. + +**Stokes** +* It only shows, like, the upper corner of your screen for some reason. + +**Thomas** +* Oh. Hold on. + +**Stokes** +* I'm not sure why. + +**Thomas** +* Does this work now? + +**Stokes** +* It's better. Yeah. I think this is everything. + +**Thomas** +* Yeah. Okay. I'll just start. yeah. thanks for letting me present this. I'm Toma. I'm a researcher in the robust incentives group at the EFF. And, yeah, today, I want to talk to you guys about IP 785805, which is on for choice inclusion lists and shortest fossil. So, yeah, I don't want to take too much time. So I'll dive right in and just give a quick, context. But yeah, proposal builders operation was kind of quite successful Awful at keeping the validator set relatively unsophisticated and decentralized, I think. But builders have become like super, super centralized. On the other hand, probably more than we expected. And so today we rely on like literally two very sophisticated and centralized entities to build more than 90% of all blocks. And this is obviously like super bad for censorship resistance properties, because now those two entities can basically arbitrarily decide what transactions get included or excluded from almost all blocks. +* And so, for example, like a couple of months ago, you have like a major builder that just decided to stop censoring some transactions and for some reasons that are actually still kind of unknown, at least to me. +* And we got like this huge drop in censorship out of kind of nowhere. And so, yeah, it's directionally good in this case, but it also just kind of shows how fragile A CR is on Ethereum right now. And so you guys, know about this, but one good way to drastically improve the censorship resistance properties is just to use inclusion lists. And just to say it again, the very basic idea is super simple. It's to let the decentralized set of validators define a set of transactions that must be included in building blocks for them to be considered valid by testers. +* And yeah, there was like a lot of research done in the past couple of years, on inclusion lists, obviously, since there was even like EIP 7547 that was considered for inclusion, but it was then rejected because of some issues regarding its compatibility with account abstraction and equivocation. but there was also some, like really cool and relevant research on block code construction by multiple parties is or the concept of view merge for, for choice. And so we took kind of inspiration from these different research threads and came up with fossil, which is actually like a very simple mechanism. And that allows multiple validators to propose inclusion lists, plural and co-construct a template roadblock made of transactions that have to be included in builders blocks. And so we kind of think of it as like a very important step forward, because fossil, what actually allows to give some power back to the validator set and allows them to like, reclaim some control over block production and reintroduce some kind of neutrality at the protocol level. +* Another important aspect worth mentioning is that fossil can also kind of be seen as a way to boost the signal provided by the solar stakers. So today, if you assume like there are like 6% of total stakers, we have to wait quite a long time, like a 1770 slot on average, I think, before a block gets proposed by a solo taker. And we can often, like, rely heavily on solo takers to ensure, like the censorship resistance properties of the network are like that. Censorable transactions are eventually included and with fossil like still assuming around like 6% solo stakers there will be like a 63% chance of at least one solo taker being in a committee if we had like 16, committee members per slot. +* And so, yeah, here's how it basically works. There are like three main steps that I'll just briefly describe. The first step is about building and broadcast broadcasting IELTS. So each slot you have 16 validators that are randomly selected to become Ill committee members. And each of them will just like monitor the public mempool and include transactions that are pending there in their IELTS up to eight kilobytes, which is about 40 transactions per day per URL. If you take the median transaction size and then they broadcast their IELTS on the global topic over the P2P network, and what validators and testers have to do is just like monitor the P2P network and store store URLs that are broadcast until the view freeze deadline, which is at nine seconds into the slot. And basically at this point they keep forwarding IELTS, but like stop storing new ones. And in the second step it's about what the like the builder actually including IELTS and IL transactions in its block in its payload. +* So yeah, the builder will do just like the validators and will collect and store is, but it actually has additional time after the view freeze deadline to ensure there is enough time for him to see all the available ills that were broadcast by committee members. And so about like, like around 11 seconds into the slot. So two more seconds after the red line. The builder just basically takes the union of transactions across all its stored aisles, and he includes them in the the payload before the full block is, is then like just proposed to the rest of the network by the proposer. And the step three is how it's enforced. So a tester will do exactly the same. They will take the union of transactions from the stored, but in their case until the view freeze deadline. +* And then they will check whether all these transactions were actually included in the block's execution payload that was proposed. And this is kind of where the fork choice and forced comes from, because the tester will only vote for the block if it satisfies all conditions according to their view. And yeah, I'll go quickly. But I want to highlight like like Fossil Core properties. I guess the first one is that IELTS and the payload are actually built in parallel, and they only kind of need to be merged together towards the end of the slot. So that's quite nice because it provides some almost real time censorship resistance. Having multiple proposals made for makes also like a really robust to commitment attacks, but it also actually allows us to get like a super nice one out of an honest assumption. So we only need one committee member to build its ill honestly. And just like include transactions from the mempool without censoring for the mechanism to work. and then we have the conditional property. +* That just means the builder must include all all transactions. But until the block is full and the builder is also not constrained on where transactions, of the order of transactions in each block. And so these two last properties are actually quite important to just prevent IELTS from being crowded out by MeV transactions. Like, imagine if there was some dedicated block space, or like if all transactions had to be included at the top or end of the block, then we probably have seen something like ILP boost emerge. But in the fossil case, like transactions have like no ordering guarantees and they must be created before the builder actually has the last look and builds the full payload. They're also broadcast publicly. +* So there is really no point in trying to include like valuable or MeV transactions via fossil. yeah. And all our all these are I'll just mention them quickly because it also addresses like some issues that were present in like the previous proposals. There is no 3D problem because in our case I'll stay on the P2P network and they never go on chain. we've thought about, like, handling scenarios in which transactions can be invalidated. We made sure it's compatible with other APIs, those that are considered for inclusion, and others like account abstraction APIs and PDAs and apps. we we handle equivocation. I always say that with it's quite robust against against commitment attacks. So bribing and extortion because we do have multiple validators, and multiple community members, and against following attacks. +* And yeah, it's also like critical because like, if you want to move towards like a apps or a tester proposal separation, it's, it's actually critical to have a mechanism like fossil to ensure there is validators that are unsophisticated and decentralized, involved in like building these roadblocks, before moving towards a world in which we might want to sell off execution rights to sophisticated parties. and yeah, finally, I just want to say that fossil can be seen, like, as a core mechanism to enforce chain neutrality and improve censorship resistance quite drastically. But it's also, like quite well suited for extensions in the future. So so far we've thought the most about extending fossil for blockchain transactions because like that's very obvious. But we are also actively researching how, for example, to properly reward committee members if we wanted to do so, because in the current version, we rely on altruistic behavior or how to secretly select, committee members so they can contribute to the mechanism with without actually revealing their identity, which also might be very useful. +* And all of these are like super exciting research direction that can extend fossil to give even better censorship resistance guarantees in the future. so thanks everyone for listening. and thanks to all the authors of fossil, and we just released today a censorship resistance website using ENS and IPFs for resources that are related to fossil. So it's called fossil dot f dot. So check it out. Thanks. + +**Stokes** +* Cool. Thank you. yeah. I mean, it's really exciting to see and especially, like, the history of research that got us to this place. I guess one question I have that might be relevant for people here is if you thought about implementation at all, I don't know if you've thought about prototypes or anything like that to accompany the EIP. + +**Thomas** +* Yeah. We like, opened the EIP a few weeks ago. And now that that's all an author has starting working on a Geth implementation that although that's quite recent, Terence is also planning to work on a Prism implementation, but that's all like that's a great problem because like anyone who's willing to work with us on this, who are like pretty active and we are looking for other people to help us, on the implementation side. + +**Stokes** +* Cool, awesome. yeah. We will not get into future forks today, but, this is something definitely everyone should have on their radar. we only have a few minutes. There was a question here. How does fossil work? Any caveats? + +**Thomas** +* No. so we discussed, about, like, the potential compatibility with the PBS. and it is about like, timing things. Right? So we allow for enough time for deadlines and view frees and like everything to to like not to to eat too much time for each of the proposal to go together. But it seemed like it was actually like quite compatible and that we can make it work. so we had like a lot of back and forth discussions in the inclusion lists channel on the R&D, ETH, R&D, discord. So if you want to check it out you can and happy to like yeah, work on this even more once like I don't know maybe we have also more clarity on what gets included or not. + +**Stokes** +* Cool. Okay. Well we are actually at time now and yeah, I think we'll go ahead and wrap up. I guess I'll ask, are there any closing comments? Very briefly. Otherwise that will be that. + +**Tim** +* Quick. Yeah. We didn't have time to get to it and it's fine, but I had some acid process stuff on the agenda. If people can review those before next week's call and leave any comments, I think that'd be great. yeah, just posted the link in the chat. Cool. + +**Stokes** +* Thanks, Tim. great. Okay then. nice call everyone. I think we made a lot of good progress on packaging, and I'll see you next time. + +**Potuz** +* Bye bye. + + + +---- + + +### Attendees +* Stokes +* Tim +* Arnetheduck +* Marek +* Lance +* Micah +* Paul Hauner +* Ben Edgington +* Loin Dapplion +* Terence +* Enrico Del Fante +* Pooja Ranjan +* Hsiao-Wei Wang +* Saulius Grigaitis +* Roberto B +* Olegjakushkin +* Chris Hager +* Stokes +* Dankrad Feist +* Caspar Schwarz +* Seananderson +* Andrew +* Crypdough.eth +* Zahary +* Matt Nelson +* George Avsetsin +* James HE +* Marius +* Ansgar Dietrichs +* Lightclient +* Stefan Bratanov +* Afri +* Ahmad Bitar +* Lightclient +* Nishant +* Gabi +* Pari +* Jimmy Chen +* Gajinder +* Ruben +* Mikhail +* Zahary +* Daniel Lehrner +* Andrew +* Daniel Lehrner +* Fredrik +* Kasey Kirkham +* Protolambda +* Cayman Nava +* Stefan Bratanov +* Ziad Ghali +* Barnabas Busa +* Potuz +* Trent +* Jesse Pollak + + + + + From 98ac35b4fd0745fe0be2fc188e2d944e0a7c83ea Mon Sep 17 00:00:00 2001 From: Aleneth <145821766+Aleneth@users.noreply.github.com> Date: Mon, 30 Dec 2024 11:47:46 +0530 Subject: [PATCH 50/51] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 7df284de..810a9255 100644 --- a/README.md +++ b/README.md @@ -248,6 +248,8 @@ The audio files of the Previous Meetings are stored permanently on [Permacast](. № | Date | Notes | Recording | --- | -------------------------------- | -------------- | -------------------- | +146| 28 Nov 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1200) \| [notes](AllCoreDevs-CL-Meetings/Call_146.md) | [video](https://youtu.be/HcjuY3WDa9A)| +145| 31 Oct 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1185) \| [notes](AllCoreDevs-CL-Meetings/Call_145.md) | [video](https://youtu.be/KMLqv60xg9w)| 144| 17 Oct 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1178) \| [notes](AllCoreDevs-CL-Meetings/Call_144.md) | [video](https://youtu.be/p3FRr5umt4U)| 143| 03 Oct 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1158) \| [notes](AllCoreDevs-CL-Meetings/call_143.md) | [video](https://youtu.be/dplciLdQTM0)| 142| 19 Sep 2024, 14:00 UTC |[agenda](https://github.com/ethereum/pm/issues/1154) \| [notes](AllCoreDevs-CL-Meetings/Call_142.md) | [video](https://youtu.be/MRtJSnBU3Gk)| From 5032472c469e9ff273e2adee5d2d83d2314b3cb6 Mon Sep 17 00:00:00 2001 From: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com> Date: Fri, 3 Jan 2025 16:22:26 -0500 Subject: [PATCH 51/51] Update pectra-pm.md --- Pectra/pectra-pm.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Pectra/pectra-pm.md b/Pectra/pectra-pm.md index 9a564140..63340736 100644 --- a/Pectra/pectra-pm.md +++ b/Pectra/pectra-pm.md @@ -1,3 +1,9 @@ # Pectra Devnets -Latest devnet: [devnet-0](https://notes.ethereum.org/@ethpandaops/pectra-devnet-0) +### Latest devnet: +- [devnet-5](https://notes.ethereum.org/@ethpandaops/pectra-devnet-5) +- [devnet-4](https://notes.ethereum.org/@ethpandaops/pectra-devnet-4) +- [devnet-3](https://notes.ethereum.org/@ethpandaops/pectra-devnet-3) +- [devnet-2](https://notes.ethereum.org/@ethpandaops/pectra-devnet-2) +- [devnet-1](https://notes.ethereum.org/@ethpandaops/pectra-devnet-1) +- [devnet-0](https://notes.ethereum.org/@ethpandaops/pectra-devnet-0)