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

# PoS Implementers’ Call #90 - 2022-06-30
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]

Agenda: https://github.com/ethereum/pm/issues/555
Livestream: https://youtu.be/Fid8hTxkRHM

## Merge

[Mikhail] Teku--Erigon issue on MSF7. The two went into deadlock waiting for each other due to an Erigon bug and small issue in Teku. Recommend modifying spec to say that the consensus client "should" rather than "may" retry a call that times out.

**Action**: Mikhail to submit PR to the spec for discussion.

[Terence] Prysm does not do this either, but easy to update. [Enrico] Teku has now been patched to retry FCU calls that time out. This resolves the issue with Erigon.

[Mikhail] Second topic. Analysing latest valid hash and its importance. How do consensus clients behave after restart while in optimistic mode? See post in #Interop channel:

> What happens with beacon blocks which payload has `NOT_VALIDATED` status (according to Optimistic Sync spec) after CL client is restarted? Is `NOT_VALIDATED` status persisted anyhow, or may be the opposite, beacon blocks with `NOT_VALIDATED` payloads aren't persisted and CL client tries to pull them from the wire if that need be (upon receiving an attestation or a descendant block)?

There could be data availability issues in an edge case, if consensus client does not resend invalid payloads. But Danny thinks this is probably not the case.

[PaulH] Lighthouse does not replay any blocks on restart.

**Action**: Mikhail to write something more about his concerns for discussion.

### Mainnet Shadow Fork 8

Nodes are syncing; expect TTD to be reached around Tuesday.

Note that MSF7 is about to be deprecated.

### Sepolia

TTD has been decided. There has been some extra mining on the chain, so Merge may come early, but everything is ready in any case.

## Gray Glacier

Everything went fine. The bad chain has only one block, equating to less than 0.2% of hash rate. No reports of any issues from infrastructure providers.

## MEV-Boost

### adding signature to getHeader

[MetaChris - Chris Hager] Background [here](https://github.com/ethereum/pm/issues/555#issuecomment-1170353602) and [here](https://github.com/flashbots/mev-boost/issues/112).

Validators do not currently authenticate to relays which upsets the block auction dynamics: this makes it an open auction. If it were a sealed-bid auction that would be a superior solution. Downside is that validators would need to sign to autheniticate themselves to the relay before receiving the bids.

[Danny] Nodes could pre-register by other means to identify themselves. [Chris] There is no whitelist planned.

[Stephane] Relays and proposers could still be bribed for the information. General point: we should consider the design space that opens up if validators become equipped with an authentication signing method. Also consider how this fits with a future PBS design: would that require bids to be public. Tl;dr - could we decouple from changing consensus clients by adding a generic validator authentication method? (I.e. an arbitrary message signing scheme.) [PaulH] The hard part is integrating this into block production workflow.

[Terence] Concerns about validator privacy. If there were only one relay they could get the IP addresses of all validators. In fact, this is already the case in the current design.

[Micah] Making it sealed-bid (i.e. obscuring information) seems to be not ideal - if only relays can see the bids, this gives them privileged information and creates an unfair dynamic. Builders will become relays to gain the information and the advantage. [Danny] This could disincentivise trusting new relays. Does the introduction of sealed bids drastically change the trust assumptions we are putting on relays anyway? [Dankrad] No, not really. [Chris] The relay and validators would have additional negotiating power - they could request bribes for information.

[Danny] Possible design. There is a register validator API. We could register a separate key at that point for signing non-consensus messages for authentication purposes.

[Micah] Is the issue with escalating auctions simply the spam generated by the bids. Could we introduce a minimum bid increment (e.g. 5%) to control this? Yes - this could work for well-behaved relays. We can't control misbehaving relays. [Dankrad] A validator will likely choose relays that offer smaller increments so as to get optimal bids regardless of the overhead - a race for the bottom.

[Stephane] Private links from large validators to block builders may also spring up.

**Action**: Discuss further on the [issue](https://github.com/flashbots/mev-boost/issues/112), and `#block-construction` channel on the R&D discord.

Note that the builder and relay are available on Sepolia for testing.

[Enrico] Regarding the discussion about waiting for some epochs post-Merge before activating MEV-Boost - can we test this on Sepolia? [Chris] Will configure Sepolia relay to return 205 error for 16 epochs after the Merge.

## Afri's comments

See [here](https://github.com/ethereum/pm/issues/555#issuecomment-1170959155).

Pulling chain configurations from GitHub. Afri suggests not dynamically pulling them in builds. This has led to an issue concerning a renamed repo. [Dustin] Nobody should be _blindly_ pulling them. As far as we know people are checking commit hashes etc., and certainly ought to be (i.e. don't just pull from `master`). Git will verify the commit, so use that rather than `curl`. There may be a centralisation risk, but there's not really a security risk here. We already rely on GitHub for so much that this is a triviality in the big picture.

[Jacek] Standardising a format for all the network info would be useful, and allow for broader dissemination of files. For example, there exist two formats for bootnodes and multiple for Eth1 genesis. [Marius] Clients have differing requirements due to varied "adjacent to Ethereum mainnet" use cases, so this is difficult to achieve.

Checkpoint sync from Infura - see [Danny's comments](https://github.com/ethereum/pm/issues/555#issuecomment-1171238941). As long as we handle state root distribution better then Infura or whatever is not really an issue. Not much appetite on the consensus client side for adding state distribution via p2p.

[Jacek] Era files update: community members are serving era files. Multiple Nimbus beacon nodes can share p2p block storage between themselves via era files. Still planning to write an EIP!

* * *

# Chat highlights

From danny to Everyone 03:02 PM
: https://github.com/ethereum/pm/issues/555

From Chris Hager to Everyone 03:19 PM
: https://github.com/flashbots/mev-boost/issues/112

From thegostep to Everyone 03:19 PM
: or the validators
you can still bribe the relays or the proposer for the information

From danny to Everyone 03:22 PM
: i was confused what the signature was being put on. the proposer signs the request. not the builder signing the response. got it

From Chris Hager to Everyone 03:23 PM
: yes, the sealed-bid auction could happen if the proposers add a signature to the getHeader request, allowing relays only providing bids to the actual proposer for a slot

From MariusVanDerWijden to Everyone 03:24 PM
: This has nothing to do with the EL clients right?

From stokes to Everyone 03:24 PM
: not directly

From Chris Hager to Everyone 03:28 PM
: good point

From Enrico Del Fante to Everyone 03:28 PM
: +1

From thegostep to Everyone 03:29 PM
: I think relays have privileged information regardless
the difference is slot proposer having privileged information about the bids for their own slot

From Paul Hauner to Everyone 03:31 PM
: Adding a signature over the getHeader sounds like an achievable thing from an engineering perspective. It’s means adding a new HTTP round-trip during block production and a new method to the standard beaconAPI.

From stokes to Everyone 03:32 PM
: can't we just staple a signature onto the `produceBlindedBlock` method?
vals just know ahead of time to always send the signature

From Paul Hauner to Everyone 03:32 PM
: Oh yeah, probably. I am a bit rusty on builder API.

From thegostep to Everyone 03:32 PM
: consider if there is an incentive for builder to sidestep relays that use public bids, in favor of relays that use private bids

From stokes to Everyone 03:33 PM
: if we want a "generic signing endpoint" then thats different

From Enrico Del Fante to Everyone 03:34 PM
: if we sign only slot we can bake it into the block production request
signing the slot should be enough, per my understanding
and we could sign in advance, potentially sending them along with registration

From thegostep to Everyone 03:42 PM
: public bids means more incentive for builders to bypass relays

From elopio to Everyone 03:43 PM
: +1

From Chris Hager to Everyone 03:44 PM
: https://github.com/flashbots/mev-boost/issues/112

From Micah Zoltu to Everyone 03:46 PM
: Wen PBS. 😬

From elopio to Everyone 03:46 PM
: next sunday

From Micah Zoltu to Everyone 03:46 PM
: 🎉

From MariusVanDerWijden to Everyone 03:55 PM
: We need to retrieve ~ 50 GB of state on eth1 (just saying its possible)

From pari to Everyone 03:56 PM
: 3 eth1 genesis formats
only geth/erigon share a format

From Paul Hauner to Everyone 04:02 PM
: Adopting era files is something we’re interested in. Lots of other things to do, but generally interested and open to it.

From Me to Everyone 04:02 PM
: +1