Ethereum Core Devs Meeting 134 Agenda

[timbeiko]

Meeting Info

• March 18, 2022, 14:00 UTC
  • Note: Daylight Savings time will start in Americas before the call, but the call is "fixed" at 14:00 UTC - double check your local time!
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/Lbsjw-lzMIw
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

• Merge Updates
  • Kiln 🔥🧱 Updates
• Shanghai Planning #450
  • Beacon Chain Withdrawals for Shanghai #495
  • EIP-4844 updates
• Core EIPs & executable specs (link)

[ralexstokes]

i'd like to continue discussing how we want to implement validator withdrawals for inclusion in Shanghai.

i've put together a "meta-spec" with links to the latest thinking on changes at the consensus, execution layers and their interface; along with some explanatory prose walking through the overall flow:

https://notes.ethereum.org/@ralexstokes/Skp1mPSb9

in particular, there are two EIPs for execution client devs showcasing two different approaches to representing withdrawals at the execution layer and it would be great to reach consensus on one route during the call

[protolambda]

Agenda item suggestion: EIP-4844 Blob transactions

Progress summary:

• New meta-spec, lists all different resources / prototypes / etc.
• Consensus specs PR ready
• Execution-APIs PR ready
• Benchmarks (bench code done, machines / BLS libs being compared now). Including VerifyBlobs to batch-verify multiple blobs at once (much more efficient)
• Super new: EIP-4844 implementer notes, inlcuding benchmarking and optimization information.
• Ongoing prototype testing (and work-in-progress interop work with Prysm)

Meta: EIP process with consensus/execution-layers. @timbeiko has a draft proposal for this type of EIP? (also relevant to withdrawals EIP)

Bonus: Vitalik wrote a post about trusted setups, good information for the KZG trusted setup.

[gcolvin]

I'm not able to comment at https://notes.ethereum.org/@timbeiko/executable-eips, (account closed, it says) so I'll do it here.

First, a nit. It says the current process starts with:

Pre-Draft: Open PR in EIPs Github repository, no requirements

But I think that pre-drafts take place elsewhere: blog posts, HackMds, personal GitHub repos and the like. I don't want PRs cluttering the EIP repo until there is a champion and a draft for a solid EIP.

A bigger problem. The proposal is to start here instead:

Pre-Draft: Open PR in EIPs Github repository, Open PR in Executable Specs Repository, no requirements.

Which we means we have the clutter of pre-proposals in two repos. Worse, the rest of the proposed process seems to involve maintaining PRs in sync against two repos. I think that is just too difficult. Instead, I think there needs to be a hand-off point -- such as the Draft staying in the EIP repo until it goes to Final.

Which gets to the substance of my problem:

Make the following changes to the template:

Specification

Replace with link(s) to PRs or Commits in:
https://github.com/ethereum/execution-specs/
https://github.com/ethereum/consensus-specs/

This seems to mean that the authors and the reviewers of Core EIPs will need be competent programmers in the language of the Execution Specs. In which case I might need to stop writing and reviewing Core EIPs.

From my own experience... The C++ Standard itself was written in a fairly precise mix of formal notation, maths, and technical English. In the end only the lead Editor was trusted to get it right. Ordinary humans -- even compiler authors -- weren't worthy. Proposals to change the Standard were not generally presented in that dialect. They were typically a mix of C++ and more ordinary technical English -- the kind ordinary experts can read and write. New features were typically implemented in at least one compiler or library as well. The "standardese" for accepted proposals basically got reverse-engineered by the Editor from these sources.

So I'd prefer to see the current EIP process remain close to as it is, with the translation to Execution Specs happening further down the road. As I understand it the Execution Specs are an executable client, so will (like the other clients) have the Final EIPs implemented and running on the testnets well before we go live. Once they are live this executable spec -- being in consensus on the network -- is ground truth, and the EIP subject to errata if it differs.

[gcolvin]

A second objection to demanding that EIPs use a particular specification language is that the best language for a proposal will vary. It might be mathematical or graphical notation specific to its domain. It might be more abstract and declarative than executable. It might even be English. The proposal itself shouldn't need to say how best to implement itself in a particular language.

Please don't take any of this as an objection to an executable specification. Rather, I think the beauty is that the executable specification emerges directly out of the "literate programming" effort of maintaining the client that instantiates that spec.

[timbeiko]

I'm not able to comment at https://notes.ethereum.org/@timbeiko/executable-eips, (account closed, it says) so I'll do it here.

Good point, most people won't be able to comment on it. I've opened an EthMagicians thread, and pasted your thoughts: https://ethereum-magicians.org/t/core-eips-in-an-executable-spec-world/8640

[timbeiko]

Closed in favor of #500