---
tags: eth2devs
description: Notes from the regular proof of stake [Eth2] implementers call
image: https://benjaminion.xyz/f/favicon-96x96.png
---

# Consensus Implementers’ Call #104 - 2023-03-09
[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

## Capella

Goerli upgrade due next Tuesday. [Blog post](https://blog.ethereum.org/2023/03/08/goerli-shapella-announcement) is out with client releases (except Nimbus). Monday 15:30 UTC [community call](https://github.com/ethereum/pm/issues/741) 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](https://collective.flashbots.net/t/mev-boost-community-call-1-9-mar-2023/1367) later today. Builders, relayer operators, please join. [Pari] Have tested relay and circuit breaker on devnet.

## Deneb

### Blob signing API

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.

### SSZ Meta doc

[Etan] [SSZ meta document](https://hackmd.io/y1MCA5Q-R4eMVyOBHiRH7Q) - **Action:** Please review for discussion next week.

### Parent slots in attestations

[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](https://github.com/ethereum/consensus-specs/pull/3249).

## Research, Spec, etc.

### The Verge spec draft

[TheVerge: spec draft](https://github.com/ethereum/consensus-specs/pull/3230)

[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.

## Spec discussion and AOB

Intentionally left blank.

* * *

# Chat highlights

Tim Beiko 14:04
: https://blog.ethereum.org/2023/03/08/goerli-shapella-announcement
https://github.com/ethereum/pm/issues/741

Potuz 14:06
: it's trading at 16 bucks a pop, will be flooding the fork and try to sell it quickly :P

Tim Beiko to Everyone 14:06
: *20c

Potuz to Everyone 14:06
: ohh already so much down :(

Chris Hager to Everyone 14:06
: community call 2h from now

Etan (Nimbus) to Everyone 14:07
: https://github.com/ethereum/consensus-specs/pull/3284
small light client fix for fork transition

Chris Hager to Everyone 14:07
: https://collective.flashbots.net/t/mev-boost-community-call-1-9-mar-2023/1367

MariusVanDerWijden 14:16
: Why does the beacon node need the blobs for block production? The blob transactions are on the el, no?

terence 14:16
: Blobs are gossip’ed and stored on the consensus client

MariusVanDerWijden 14:17
: Yes, but I would call that block verification, not block production

Etan (Nimbus) to Everyone 14:17
: also for extra safety it may want to validate the KZGs against the blob before signing the beaconblock

Potuz 14:17
: you need to verify the block before signing

terence 14:18
: Right, especially you get that a builder

Etan (Nimbus) 14:19
: isn't that portion blinded?

terence 14:20
: Could be, not sure if it’s fully spec’ed out

Etan (Nimbus) 14:27
: https://hackmd.io/y1MCA5Q-R4eMVyOBHiRH7Q

MariusVanDerWijden 14:30
: Should we continue the discussion on removing AL and Create from Blob txs?

Ben 14:31
: https://github.com/ethereum/consensus-specs/pull/3249

Hsiao-Wei Wang 14:33
: https://github.com/ethereum/consensus-specs/pull/3230

Etan (Nimbus) 14:35
: does light client need `execution_witness`?

Etan (Nimbus) 14:38
: please SSZ root, in both EL and CL

MariusVanDerWijden 14:39
: We could produce a merkle proof :P

Etan (Nimbus) 14:41
: withdrawals / blobs missing at top btw
and title needs to be consistent with class name (IPA vs Ipa) or it will fail lint
eip 6475 for optional discussion btw (in case we don't need full union)

Tim Beiko to Everyone 14:46
: +1 on feature name

Mikhail Kalinin 14:47
: combined with full danksharding

Tim Beiko 14:47
: Write an EIP :-) !

Tim Beiko to Everyone 14:48
: I’m not joking about the EIP, though: would be neat to have a “main” Verkle EIP, which links to the changes in the CL + EL, given how big it is
Can use the EIP number as the feature name, like 4844