Agenda
Execution Layer Meeting 198 · Issue #1163 · ethereum/pm · GitHub moderated by @timbeiko
Action Items & summary
Recording
Additional Info
Crypto & Blockchain Research Reports | Galaxy by @Christine_dkim
Execution Layer Meeting 198 · Issue #1163 · ethereum/pm · GitHub moderated by @timbeiko
Crypto & Blockchain Research Reports | Galaxy by @Christine_dkim
pectra-devnet-4 to tentatively launch by Oct 17
We had an extensive discussion about repricing the MSM precompiles with different teams reporting benchmarks, and @chfast sharing his analysis, but no clear consensus reached on the right amounts.
Additionally, there was a proposal by @chfast to remove the MUL precompiles. We also discussed potentially removing subgroup checks, making them optional with input flags, or moving them to separate precompiles to provide a wider range of options to applications.
A breakout room was scheduled for next Monday to better consider these options. We agreed to not include EIP-2537 changes to devnet-4, in order to finalize specs.
devnet-3 had finality issues caused by Geth forking off the of the network. The issue was found, fixed, and deployed during the call, with the network finalizing before we wrapped up To allow the community to test Pectra in a relatively stable environment, we plan to launch a testnet by Devcon! The name is still TBD, with Moodeng being the leading contender. Depending on the complexity of further EIP-2537 changes, they may be excluded from this testnet.
Given many client developers will be attending devcon and we’re unlikely to launch new devnets during that time, we’ll aim to have the testnet live before the conference!
@Nerolation made changes to EIP-7623 which should simplify client implementations. The intrinsic gas cost is no longer deducted before execution. Instead, the EIP now validates that the transaction sender’s balance can cover the floor cost of the transaction. Nethermind has already implemented the changes.
Note: the discussion of EIPs 7782 & 7783 was quite fluid and went back and forth between similar concerns around the EIPs. I recommend watching the livestream for the full nuance here.
This EIP, which came in response to EIP-7782 (see below) proposes a mechanism for clients to dynamically set their gas limit when proposing a block, while still maintaining a cap. The EIP would not require a hard fork, given the gas limit is controlled by block proposers. It would simply change the default behaviour from using a fixed value until changed to a gradually growing value over time, allowing for a smoother raising of the gas limit.
Some concerns were raised around increasing the rate of history/state growth, with pushback about history growth rates being lower post-4844 and state growth not being a pressing issue. There were also concerns about distracting attention/engineering time away from Pectra. Even though this is not a core EIP, and a relatively simple change clients can implement independently, in practice similar individuals are involved across the efforts.
This EIP proposes to reduce the slot time from 12 to 8 seconds. On the call, @benaadams explained his motivation was for this to be an alternative to raising the blob count. By reducing the slot time, we effectively increase the number of blobs/second.
Here, concerns were raised about the impact on bandwidth usage. @Giulio2002 additionally highlighted that even if we could lower the slot time to 8 seconds today, it may impact future efforts such as DVT or SSF, and that impact should be considered as part of the discussion.
There were also concerns raised about this potentially breaking contracts. While this seems very unlikely to be a large issue, it should at least be verified.
@ralexstokes asked for feedback on Pectra changes to the Builder Spec. No major concerns, so leaving the PR as is.
@ryanberckmans had raised concerns about the lack of research on home-staker bandwidth consideration.
While there were no comments about this directly on the call, two bandwidth improvements were highlighted: IDONTWANT and engine_getBlobsV1, with other efforts listed on the original post.
Thanks for these posts @abcoathup ![]()
Is it possible to upload the zoom chat along with the recording in future posts please?
@siladu I would love the chat logs & transcripts to be shared straight after the call.
Formatting chat logs is apparently a manual task, and Eth o’clock (timing for many protocol calls) is when I am asleep in Australia so I haven’t had a chance to try.
For more background see:
Transcripts are eventually shared in GitHub - ethereum/pm: Project Management: Meeting notes and agenda items but these don’t tend to appear quickly…
Thanks for the extra context, I’ve replied on that thread too.
Fellow Australian here, so in the same boat with Eth o’clock ![]()
I would rather have badly formatted chat logs than none at all