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

# PoS Implementers’ Call #87 - 2022-05-19
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]

Agenda: https://github.com/ethereum/pm/issues/527
Livestream: https://youtu.be/-6dZVes6aWc

## Merge updates

Another shadow fork (msf-5) happened immediately before the call. Looking good so far, but too early to know for sure. Equal client split on EL and CL. Also running sync tests with Geth/Nethermind/Besu and all of the consensus clients. The EF security team is running some analysis tools. Will update again before the end of the call!

[Note that the Erigon data in [Ethstats](https://beaconchain.mainnetshadowfork5.ethdevops.io/) is not correct, but others should be.]

### Ropsten TTD

Moving forward on merging Ropsten. A TTD was selected on the ACD call, but we need to revise this. Ropsten is the hardest network to estimate difficulty for. We have new estimates that may be better (or may not be). Need to time the Merge for _after_ Bellatrix update to the beacon client on the accompanying beacon chain.

Either,

1. pick a new value targeting June 8th, risking it happening sooner, or
2. pick a later date (e.g. 15th to guarantee avoiding Bellatrix) and add a bunch of hash rate nearer the time to accelerate and fine-tune the difficulty to hit the 8th.

Ropsten Bellatrix fork is scheduled for June 3rd. Option 2 seems to be winning.

Consensus is not to change TTD now and to take option 2. Tim to look into renting hash power for testnets.

### [Sidebar] MSF5 progress update

Seem to be missing lots of blocks. Maybe due to the previous timeout issue.

### Client releases for Ropsten

Clients all making releases next week. Make sure that you are using the latest spec params - there was a small change to genesis delay etc.

There will be a release candidate for consensus specs and alpha release of engine API in the next days (just adding Ropsten stuff).

Prysm is working on some blog posts for Ropsten. Will there be some more general posts to point to? Tim is working on a post. Will discuss fee recipient things, though clients have different implementations for this.

Recommend that consensus dev teams join the ACD call over the next weeks.

## Other Client updates

**Nimbus**
Release updates: proposer boost, lower CPU usage in sync, compat with Web3Signer, BLS threshold signatures. Staking pools can distribute signing keys in N of M configuration. Reduces insider threat of individuals having access to keys.

Progress with light client protocol. Working on the spec in the Ethereum repo. Planning to implement MEV-boost.

**Lighthouse**
PR to beacon API spec (#216) - not expected to be controversial. But it is a significant change.

Discovery is now IPv6 compatible, but not enabled in production. Implementig episub gossip. Implementing fee recipient method from key manager API.

Michael Sproul has done more work on block print metrics.

**Teku**
Release next week. Improvements and optimisations to REST API framework; can now stream JSON, which reduces memory usage (good for Infura!). Optimisations on BLS batch validation, REST API events memory usage. Implemented Eth1 checksums (e.g. for fee recipient). Working on Builder API (aka MEV-Boost), successfully running this in test, with fallback to local Eth1 node.

**Prysm**
v2.1.2, includes Go 18.2.1, Bug fixes, optimisations. Catching up with spec changes. Saving blinded blocks rather than full blocks to reduce DB size. Builder API impementation ready for testing. Fee recipient implementation. Working on EIP-4844 with Optimism team.

**Lodestar**
Released v0.36. Validator metrics. Proposer boosting. Fixed a security vulnerability. Implementing light client spec. Preparing for an audit and v1.0 release next month.

**Grandine**
Extended Web3Signer support. Working on custom gossip handling that can handle many CPU cores. Reduced memory consumption.

## Research, Spec discussion and AOB

### step deprecation

[See here](https://github.com/ethereum/pm/issues/527#issuecomment-1126033489). Has [been up](https://github.com/ethereum/consensus-specs/pull/2856) for 2 months. Everyone seems ok with this. Any concerns? [Jacek] Note that there is a very similar PR coming for the beacon API also, that doesn't include a `step` parameter.

[Jacek] There is a question about whether execution client should support both "by hash" and "by range" requests. Do we make "by range" optional? It's basically just an optimisation. To be discussed on ACD next week.

Unless any objections surface on the Discord consensus dev channel, will merge the `step` change.

### [Sidebar] MSF5 progress update

Missing blocks is only an explorer issue. The chain is fine!

All clients survived the Merge. An unrelated pre-Merge issue on Besu reduced participation to 97%.

:tada:

### Deposit functionality changes

Reducing follow distance (to one) and effectively eliminating voting on Eth1 chain. Possibly in Shanghai/Capella if code is easy. There may be some other changes to improve elegance, but perhaps not for Shanghai. Note that we need to take care of interactions with optimistic sync.

If anyone wants to look into this, that would help to make progress and get it into Shanghai/Capella.

This wouldn't allow addition of validators at a higher rate, but would improve UX for depositors by giving them some confidence a day earlier that their deposit was successful.

### 0x01 initiated exits

[See here](https://github.com/ethereum/pm/issues/527#issuecomment-1124702172). [Artyom Veremeenko] Is withdrawal credentials initiated exits desirable? Argument that it is, to allow stakers to escape from pools holding their funds hostage.

[Danny] It's definitely weird today that the ultimate owner of the funds can't initiate an exit from a pool. So it's likely a good feature to enable. Likely better post-Shanghai/Capaella due to work involved and complexity.

[Vasiliy Shapovalov] Do we need a generalised Eth1--Eth2 message bus? [Danny] Probably not - credential rotation will probably be handled purely on the consensus side, and don't currently foresee a need for other messages between the layers. Unless the revised deposit mechanism can be rolled into this.

Also need to consider a more robust anti-DoS mechanism than just Eth1 fees. This would likely require the execution side to have some insight into the consensus state.

[Artyom] Depends a lot on being able to do lots of checks in the consensus layer. E.g. the limit on voluntary exits is currently 16; check for wc-initiated exit is much cheaper, so could include many more of them. [Danny] The limit covers two aspects: size of blocks, and computational overhead.

DoS protection could include adding a (small) extra fee on the contract.

[Me] Is there any danger that changing this functionality could break any existing services? General view seems to be not, but we should do some due diligence.

[Artyom] From [Prysm code](https://github.com/prysmaticlabs/prysm/blob/c1197d7881ba2041e06f12b48ad02ab5a91357f1/beacon-chain/powchain/log_processing.go#L103), deposit validity checking. Would the wc-credential initiated exit logic look similar? [Danny] Intuition is that this would be a problem for consensus clients not running with a full execution client, but need to think further.

Making a feature directory withing the consensus spec repo would be a way of making progress with this (absent a more formal EIP-style governanec process for beacon chain).

## Closing

Next shadow fork on Monday 30th or Tuesday 31st? This would test the Ropsten releases directly.

Clients should try to target next Wednesday (25th) latest for releases, to allow time for blog posts, installation etc.

Shadow fork 5 still looking fine!

* * *

# Chat highlights

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

From pari to Everyone 03:04 PM
: https://beaconchain.mainnetshadowfork5.ethdevops.io/

From Marius van der Wijden to Everyone 03:06 PM
: I just checked the new estimates and they are even worse

From danny to Everyone 03:07 PM
: nicehash.com

From Tim Beiko to Everyone 03:08 PM
: https://notes.ethereum.org/@MarioHavel/predicting_ttd
doc explaining how we did predictions

From Micah Zoltu to Everyone 03:09 PM
: 1GH/day is about 0.015 ETH.
To just rent it on the open market.

From Justin Florentine to Everyone 03:11 PM
: merge finalized

From Marek Moraczyński to Everyone 03:11 PM
: hmmm we should check block production on MSF5
only empty blocks?

From pari to Everyone 03:12 PM
: Yup, feels like blocks are produced but we're hitting timeouts
(i assume)
(all clients do async block production now afaik)

From Micah Zoltu to Everyone 03:13 PM
: Hmm, maybe that 0.015 ETH /day is for 1 GH in a day... if we need 1 GH/s then we need 86,400x that much. 😬
Like I said, don't trust me on this!

From Marius van der Wijden to Everyone 03:13 PM
: I see some full blocks

From Marek Moraczyński to Everyone 03:14 PM
: could you send?
link to full block?

From Micah Zoltu to Everyone 03:14 PM
: (I think 0.015 is GH/s per day)

From Marius van der Wijden to Everyone 03:23 PM
: > for (let i = 0; i < 100; i++) { console.log(eth.getBlock(14805454 - i).transactions.length) }
0
0
602
479
...

From Marek Moraczyński to Everyone 03:24 PM
: so beacon explorer issue?

From Marius van der Wijden to Everyone 03:24 PM
: Some blocks are empty but that might just be basefee

From Łukasz Rozmej to Everyone 03:24 PM
: yeah lot of empty blocks, either 0 gas or 30 mln

From Mehdi Zerouali to Everyone 03:24 PM
: https://github.com/ethereum/beacon-APIs/pull/216

From danny to Everyone 03:24 PM
: might also be the same known issue with lodestar and (can’t remember who else) just seen on 40% of blocks now with even split

From Justin Florentine to Everyone 03:24 PM
: can you get the graffiti in that loop?

From Łukasz Rozmej to Everyone 03:25 PM
: I think they might be empty because of EE doesn't gave time to produce the block async
change to async was implemented in Geth for this shadow fork
basefee shouldn't result in this behavior

From Marius van der Wijden to Everyone 03:26 PM
: ExtraData is 0x for all blocks

From pari to Everyone 03:27 PM
: its an explorer issue guys, time="2022-05-19T14:16:35Z" level=warning msg="failed to fetch block(s) for slot 22106: transaction with invalid sender (tx hash: 8513b2dcbb79069d7380e6863456073863386a25ba5e283d693b20ebe48ed3d4): invalid chain id for signer" module=rpc
for soem reason its failling to import transactions and then errors out, so it lists tx as 0

From Marek Moraczyński to Everyone 03:27 PM
: 🙏👌

From pari to Everyone 03:27 PM
: please query your node directly for now

From Tim Beiko to Everyone 03:27 PM
: Wasn't Marius's query from his node?

From pari to Everyone 03:28 PM
: e.g: curl localhost:5052/eth/v2/beacon/blocks/22160 | jq '.data.message' shows a ton of transactions but 0 on the explorer

From Marek Moraczyński to Everyone 03:28 PM
: https://explorer.mainnetshadowfork5.ethdevops.io/blocks

From Marius van der Wijden to Everyone 03:28 PM
: @Tim yeah and my node shows transactions in most blocks

From danny to Everyone 03:31 PM
: https://github.com/ethereum/consensus-specs/pull/2856

From Marek Moraczyński to Everyone 03:32 PM
: yes :) I can confirm network looks fine. It seems that beacon explorer is importing only empty blocks for some reason (exactly as Pari said)

From pari to Everyone 03:33 PM
: We have an equal client split and seems like no client went offline because of an incompatibility! Great milestone 🙂 (caveat, erigon is running only with prysm - but working)
So out of a possible participation rate of 97%, we're at 97%! (the missing ~3% is related to a unhealthy shutdown on besu)

From Arnetheduck to Everyone 03:38 PM
: OK can hopefully add "removed step" to my Twitter bio along little endian

From Tim Beiko to Everyone 03:38 PM
: Very cool!
What's the next one :-) ?

From Marius van der Wijden to Everyone 03:38 PM
: Geth nodes are not updated to the no-async version yet

From pari to Everyone 03:39 PM
: (wasn't the async code pushed to master already?)
ah i see it was merged yesterday
i can update the nodes

From Marius van der Wijden to Everyone 03:42 PM
: Also we optionally wait for 500ms if we don't have a block available on GetPayload before returning the empty block

From Tim Beiko to Everyone 03:43 PM
: A nicer "long term" design also wouldn't need a contract
And it would be neat to do a "supply adjustment" once where we update the deposit contract balance based on withdrawals.
But that seems unlikely for Shanghai

From Marius van der Wijden to Everyone 03:45 PM
: "Supply Adjustment" :D

From Mikhail Kalinin to Everyone 03:48 PM
: I can brain dump ideas that we have discussed into a document and probably do some initial analysis sometimes next couple of weeks

From danny to Everyone 03:48 PM
: great, happy to work with you on it

From Mikhail Kalinin to Everyone 03:49 PM
: 👍

From Yoav to Everyone 04:00 PM
: One issue re EL initiated exits is that a smart contract bug could cause a mass exit. E.g. a bug in the Lido withdrawal contract could cause 30% of the validators to exit. Timed carefully, it could enable coordinated CL attacks.

From stokes to Everyone 04:00 PM
: no BLS in the EVM, can't verify

From Vasiliy Shapovalov to Everyone 04:06 PM
: stakefish's contract is not upgadeable afaik, but it doesn't rely on status quo

From Micah Zoltu to Everyone 04:08 PM
: Looking forward to the Lido "Oops, I killed it" bug. 😆

From danny to Everyone 04:08 PM
: heh

From Artyom Veremeenko to Everyone 04:12 PM
: https://github.com/prysmaticlabs/prysm/blob/c1197d7881ba2041e06f12b48ad02ab5a91357f1/beacon-chain/powchain/log_processing.go#L103

From Yoav to Everyone 04:14 PM
: Right, StakeFish uses proxies but not upgradable. E.g. https://etherscan.io/address/0x576152d5BDc7DBDf3c842B12C03A5151d2Bad90A#code
I forgot about them