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

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

Agenda: https://github.com/ethereum/pm/issues/549
Livestream: https://youtu.be/WHOZ_2tlTqk

## Merge

### Ropsten updates

EthStaker team have been doing some sync tests. Should have a full report by ACD next week.

From Pari in chat related to the above:
- Erigon has an intermittent issue that causes sync to fail
- Besu has an (intermittent?) issue that causes sync to fail
- Nimbus cannot sync against Geth, but can against others. Still unclear whether the issue is with Nimbus, Geth, or both
- Nethermind may have a memory leak

### Mainnet Shadow Fork 7

Planned for next week. Configs are in the usual place. Will try to replicate all of the issues found in Ropsten - hopefully all resolved now. Will also do some sync testing.

### Sepolia Genesis and TTD

Sepolia beacon chain will be permissioned. All the genesis validators should have mnemonics from Pari by now. If anyone else wants to participate then contact Pari - you can be onboarded post-genesis via token deposit.

Sepolia supply has been inflated to ~1 million ETH per validator. After withdrawals are enabled we can use this to have more testnet ETH available without a hard fork.

Today is too early to set Sepolia TTD. Recommend setting it Friday next week. Since this is a controlled testnet we don't need too long a lead time. Can we target the Sepolia Merge ~5 days after that (~29th June)? Ropsten Merge was around 5 days from setting TTD.

[Tim B] The Ropsten compatible clients should work on Sepolia (Consensus client will need the Bellatrix fork slot setting manually if so). Can someone do a quick HackMD doc to describe how to set this up? Marius has a TTD override doc that can be repurposed. However, client teams are planning specific Sepolia releases in the next day or two, so may be unnecessary.

### Builder Network Testing

[Alex Stokes] There is an [issue](https://github.com/ethereum/builder-specs/issues/32) around where we test the Builder API (MEV Boost). Is Sepolia a good target? Also, how ready are clients?

Prysm: have been working on Builder API, but progress has been slow. Able to do end to end workflow with the Ropsten relay. 1-2 weeks away from putting it into a release; needs thorough testing.

Teku: implementation is done, and working on Kiln network. Still in testing, but end to end flow is good. Flashbots runs a relay on Kiln.

Lighthouse: expect to be ready before the Sepolia transition.

[dappLion] Can we test using Kurtosis? There are [open source](https://github.com/flashbots/boost-geth-builder) relays and builder implementations that can be used.

[Stephane] recommend client teams test on Sepolia, and 3rd-parties can test on Goerli.

[Alex S] recommended to *not* run MEV Boost through the Merge event itself due to the added complexity. Clients should by default delay for, say, 16 epochs after the Merge. [Dankrad] How about Flashbots just don't serve blocks for 16 epochs? Many people may just disable the delay. [Danny] The local complexity still remains in this case.

[Stephane] Definitely possible for FB to switch off the relay for an hour or so, but that would lead to priority gas auctions (PGA) for MEV extraction on mainnet which is undesirable.

[Paul H] is in favour of disabling MEV Boost during the Merge to reduce complexity. **Action:** Alex Stokes to make a PR to the Builder Spec.

Are client teams looking for help to test MEV Boost during the Sepolia transition? Seems not.

## PoW Gray Glacier hard fork

**Action:** everyone, upgrade your Eth1 clients for the bomb delay! Just waiting for Besu release, expected today. A blog post will be up asap.

## Research Updates

[Mikhail] Deposits processing post-Merge. Walk through [this proposal](https://hackmd.io/@n0ble/HkOfKgH_c).

There are opportunities to make many improvements to deposit processing post-Merge. Exec client will filter out deposit receipts and add them to the block body as deposit transactions. Consensus layer will process these receipts in the following block. Can skip Merkle proof validation. Could still cap `MAX_DEPOSITS`, but might not need to since not doing Merkle proof work.

Also need a handover process from the current method to the new one. Can then deprecate all the current Eth1 data voting logic (yay!).

See [the doc](https://hackmd.io/@n0ble/HkOfKgH_c#Pros) for pro and con.

[dappLion] Could a reorg cause the same validator index to be assigned twice? This could have significant consequences. The validator registry is supposed to be append-only and some optimisations rely on this. [Danny] We could de-queue deposits based on finality to avoid this.

**Action:** please review [the proposal](https://hackmd.io/@n0ble/HkOfKgH_c).

## Spec discussion and AOB

[Saulius] Can anyone recommend tooling to simulate deep reorgs post-Merge? Hive can do this with manually written tests. Kurtosis is planning to add network partitioning functionality, but not yet available.

[Tim B] There is an [EIP-4844 breakout room](https://github.com/ethereum/pm/issues/543) tomorrow.

* * *

# Chat highlights

From pari to Everyone 03:02 PM
: - Erigon has an intermittent issue that causes sync to fail
- Besu has an (intermittent?) issue that causes sync to fail
- Nimbus cannot sync against Geth, but can against others. Still unclear whether the issue is with Nimbus, Geth, or both
- Nethermind may have a memory leak

From thegostep to Everyone 03:05 PM
: we're are looking for validators interested in running mev-boost on sepolia

From danny to Everyone 03:13 PM
: https://github.com/ethereum/builder-specs/issues/32

From stokes to Everyone 03:16 PM
: kiln and ropsten
(relays)
https://github.com/flashbots/boost-geth-builder

From Mikhail Kalinin to Everyone 03:27 PM
: https://hackmd.io/@n0ble/HkOfKgH_c

From Tim Beiko to Everyone 03:36 PM
: Is there a world where we eventually completely remove the deposit contract?

From danny to Everyone 03:37 PM
: you could replace it with a precompile
but i’m not sure the value

From Tim Beiko to Everyone 03:37 PM
: Ideally, not having a contract with a weird balance that doesn't map to much to make supply calculations cleaner

From danny to Everyone 03:37 PM
: eh

From Tim Beiko to Everyone 03:37 PM
: now the deposit contract balance is a subset of the actually PoS ETH supply, post-withdrawals, it becomes a very weird value

From danny to Everyone 03:38 PM
: it just counts all the eth that has ever wanted to go into validation. very great number to track
😅

From stokes to Everyone 03:38 PM
: i thought peter added a proof of concept impl of a supply RPC endpoint?
then we just point ppl there
(to geth)

From Tim Beiko to Everyone 03:39 PM
: @stokes, yeah, I think it might be worth standardizing how supply is calculated and having it implemented across clients
but even that would be wrong, as it doesn't count accrued validator rewards

From Arnetheduck to Everyone 03:39 PM
: we still have the option to not bail out everyone that deposited, by not specifying withdrawals

From Tim Beiko to Everyone 03:40 PM
: yeah, I would not remove the contract before withdrawals (and likely not alongisde them given the increased complexity), but it would be nice to eventually not have it

From Tim Beiko to Everyone 03:46 PM
: https://github.com/ethereum/pm/issues/543