[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]
Agenda: https://github.com/ethereum/pm/issues/738
Livestream: https://youtube.com/live/C5SmmkriuwA?feature=share
Goerli upgrade due next Tuesday. Blog post is out with client releases (except Nimbus). Monday 15:30 UTC community call is planned. Upgrade due at 22:25 UTC Tuesday, Ethstaker livestream starts at 22:00 UTC.
There are no specific plans to flood BLS credential change messages for Goerli - has been done on testnets in the past and don't expect issues.
MEV-Boost community call later today. Builders, relayer operators, please join. [Pari] Have tested relay and circuit breaker on devnet.
One of the main discussion points is getting the blob signing API merged. [Sean] Last BLS call suggested blinded blobs on all workflows, but thinking around this is changing. Could support separate proposal and verification beacon nodes. So there is interest in using unblinded blobs. PR has been updated to reflect this. Single request to sign block and blobs together seems to be the way to go. Limited bandwidth nodes may not be able to participate in blob gossip - a remote blob server could allow them to continue staking. Providing blobs could be a separate API that a beacon node could implement. This might influence the design of the API. [Jacek] We are working on ways to minimise the bandwidth impact of blobs, so not so pessimistic about participating in gossip. Attestations are actually the biggest consumer of bandwidth. The API then should be specialised for the purpose of signing blocks/blobs. A separate API for downloading blobs is an orthogonal issue.
[Danny] We should set our design parameters to allow home validators to participate and not "hack in" external services.
This should be taken to an issue for discussion. Action: Sean to open issue for further discussion. In specs repo rather than API repo.
[Gajinder] Currently we have blinded routes for builder blocks, but unblinded for execution routes. We should add a flag to indicate that we want execution blocks on the blinded route (for more efficiency). [Danny] Seems reasonable.
[Jacek] Related - should the blinded block endpoint provide non-blinded blocks depending on whichever the beacon node happens to have? [Enrico] We (Teku) only cache blinded blocks. How would you handle SSZ encoded data - you don't know a priori if it's blinded or not. [I lost track of the nuance here… listen to the recording at ~23 minutes if you care.] Server can return a flag to indicate blinded or unblinded data. [Sean] Sounds like a more robust design to do this. Happy to make the updates accordingly.
[Etan] SSZ meta document - Action: Please review for discussion next week.
[Jacek] Among other things, we can't currently easily find out whether attestations are to very old blocks (which are wasteful to process). The idea is to include a slot whenever we have a block root. This will allow more nuanced client-side decisions on processing them.
Action: Please review and comment on the PR.
[Guillaume] Walkthrough of the PR. Simple idea - add a field execution_witness
to the execution payload.
Should the ExecutionPayloadHeader
contain the entire witness, or should it be transmitted separately? Don't have the exact size right now, but an array with ~1000 entries. Around 120Kb to 2MB (worst case) in binary format.
Are there use cases in which we'd want the header but not the whole witness or vice-versa? If so, using just the root would be ok. Most of the time if you want the witness you'd also want the whole block.
Intuition is that we don't need the whole witness in the header.
Some question about the exact mechanics of the transition at the fork. Seems like the only feasible option is to start with an empty execution witness.
This spec is built upon Bellatrix at the moment. [Danny] This seems fine - rebasing on Deneb when the time comes might be the way forward.
[Danny] Any gotcha's or only data structures? [Guillaume] Just note that on the kaustinen testnet a field is missing from the SuffixStateDiff
container.
[Etan] Do we need SSZ unions or just optionals? Optionals is in draft in the SSZ spec and makes sense, although in the code it's currently implemented as a union.
[Guillaume] Can we start referring to this as the Electra fork? [Danny] Best to give it a feature name rather than a fork name for now.
[Hsiao-Wei] How ready is this draft? We should make it executable to move it into the features directory. [Guillaume] Need some more client implementations before merging, for example Nethermind is working on this.
Intentionally left blank.
execution_witness
?