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

# PoS Implementers’ Call #66 - 2021-06-17
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]

Agenda: https://github.com/ethereum/eth2.0-pm/issues/222
Livestream: Recorded locally for upload due to problems with streaming - to be uploaded later.

## Client updates

**Teku**
Updated to alpha 7 Altair release. Up and running in a devnet that other teams can try syncing with. A few fixes to the API to improve Kubernetes support. Lot of fixes for discovery, and a few tweaks to gossip - arising from learnings from Altair devnets.

**Prysm**
Up to alpha 7. Working on sync committee vaidator endpoints. On track to start local fork transition testnet. After that will jump into multiclient devnet.

Planning to release Eth2 API support in next release.

**Nimbus**
Also on alpha 7. Continuing to optimise Nimbus. Have significantly improved public key handling by not compressing the keys. Working on validator client - managed to interop with Lighthouse node. Adding more endpoints to get up to Eth2 API spec.

**Lodestar**
On alpha 6 for Altair. Fixing performance and stability issues. Looking good locally. Other optimisations: delete pending attesation cache since not DoS resistant; stopped updating fork choice head on every call.

API client is now in a separate package, and light client prototype has its own package. The light client talks to a beacon node via the REST API, with additions for updates and proofs.

**Lighthouse**
Alpha 7 is merged. Following the latest Teku devnet. Basically working. Finishing sync committee caching implementation. Will merge Altair to primary soon.

Big improvements in memory usage in last release. Focus now on Altair.

## Altair

Appreciation to Adrian Sutton for putting up the Teku devnets. Intro to Parithosh from the EF who will be helping to stand up future testnets.

### Engineering progress
As above.

### Planning
Iterate short-lived devnets over the next couple of weeks.

When would be reasonable to be able to fork an existing testnet, such as Pyrmont? ~4 weeks from now seems realistic. Propose that in our July 1st meeting, set a fork block for one of the testnets. Early August time horizon for mainnet fork.

Need to ensure that testnet users have advance notice and that they upgrade in time.

Fuzzing [Mehdi]: is each team ready to receive crash reports for Altair resulting from Altair (confidentially)? Generally, yes.

[Terence] Are teams thinking of doing an audit for the Altair work? [Danny] Note that Eth1 mainnet clients don't tend to do this for forks, and rely on comprehensive testing. Auditors are extremely backlogged, so likely unrealistic.

[Jacek] Has the spec been audited? No. The Phase 0 spec, was, but not the changes. Far more issues were found outside the audit process than within it.

### Sync committee gossip losses

On the devnets, Teku found that many sync committee signatures were getting lost. This is because the nodes were producing signatures before receiving blocks - a race condition arising from the current spec.

Adrian has run an experiment delaying producing signatures to 4s into a slot. Better, but not 100% (probably due to there not being an aggregator assigned).

Three ideas:
1. Always wait until 4 second mark before publishing the sync committee signature.
2. Introduce a short-lived cache, for ~1 slot
3. Add a random delay after receiving a block before publishing a signature

Danny recommends the second of these. [PaulH] Is it possible to build a DoS-resistant cache? It's not always possible to verify the signatures before putting signatures into the cache (later discussion suggests that this is actually possible). The delay is also a reasonable approach and can obviate the need for a cache.

The network is less forgiving of missing a sync committee signature than missing an attestation. Could we allow a two-slot inclusion distance instead of one?

We don't yet know how this would behave on realistically sized networks. It could look quite different.

Danny would prefer to solve this within the P2P spec, rather than by adding delay on the state-transition side.

What would be the problem with approach 1? Sending as early as possible gives a greater chance of being aggregated. Also reduces the spike in message sending on the network.

## Research Updates

**Protolambda**
Sharding update: there is an updated sharding spec with a new state format that makes Merkle proofs easier. Thinking of changing the way shard proposers are tasked with duties. The current approach has caching complexity. Might introduce a separation between block builders and block proposers and a market on the sharding level similar to Vitalik's recent [post on MEV](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725). It will also reduce the amount of data being gossipped. Discussion about firewalling MEV - encourage every validator to participate on an even footing; Flashbots democratises MEV.

PR incoming, for future discussion.

**Leo**
Planning to publish work on client performance and network crawler at a conference. Working on a new network crawler that can power a dashboard. Continuing to work on common metrics standard; just choosing good namings right now.