PoS Implementers’ Call #71 - 2021-08-26

[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]

Agenda: https://github.com/ethereum/eth2.0-pm/issues/233
Livestream: https://youtu.be/DZiy3RhUgNY

Altair

New release

v1.1.0 Beta 3 is out, and test vectors are being uploaded. Has greatly increased test coverage. Also some Merge and Sharding updates.

Pyrmont testing status

Coordinated testing on Pyrmont Altair is ongoing. Non-finality for 720 epochs, now turning validators back on, and planning to do more weird things.

Prysm ran into an issue of not being able to sync under non-finality. Now patched.

Pre-Merge, we will likely create large testnets against each Eth1 testnet.

Prater in one week

Config for Altair on Prater is up. Look out for client releases for that in the next few days. Upgrade is on 2 September.

Pari is contacting client teams to discuss increasing the number of validators on Prater, since it is now smaller than mainnet.

Planning

All being well, set mainnet Altair upgrade date once Prater is done. Need to allow plenty of time for stakers to update their clients ahead of the date. What does Eth1 typically do, and how does it go? Rough consensus around targeting 30th September. This should allow time for releases, comms, updates, etc. But this date is not yet committed; discuss further after the Prater upgrade.

[Adrian] Ideally, clients should have release versions for Prater, not putting Altair on a fork/RC as some did for Pyrmont.

Client updates

Nimbus
Altair upgrades, especially performance improvements. REST API updates for Altair.

Grandine
Continuing to work on managing forks via separate runtimes. Passing Altair tests, but still a lot of work to do to make it all hang together.

Lodestar
Released in-browser light client prototype. Reduced hashing cache by half through an optimisation to the bytes type. Looking to allocate some team members to implementing the Merge.

Prysm
Mostly reviewing and merging Altair changes. Last Friday's minor incident with orphaned blocks uncovered some deficiencies in how Prysm handles the situation.

Also working on Eth2 API and prep for the Prysm v2 release.

Teku
Release coming tomorrow, 21.8.2, with Altair upgrade epoch baked in for Prater. Lots of nice optimisations to reduce CPU and memory usage. Improvements to running Teku validators against load balanced beacon nodes (such as Infura). Changes to remote signer API to add Altair support.

Lighthouse
v1.5.0 released. Seems to be going well, but some reports of lower attestation effectiveness - may be a network issue rather than Lighthouse, investigating. v1.5.1 coming Monday, including Altair fork on Prater. Remote signer compatibility with Teku/Web3Signer should be good to go.

Merge discussion

Just had a call to discuss the engine API, will continue on the next All Core Devs call.

The Merge process and terminal total difficulty calculation has been analysed. Key take-away: we may wish to use a more precise value for the seconds per Eth1 block parameter to make the predicted Merge time more accurate (i.e. within a 20 hour window). Could be affected by approaching an ice-age.

Getting to work on Merge prototypes soon will be good.

Research Updates

None.

Spec discussion and AOB

[PaulH] Issue 2569, "Set disabled values as null in yaml config" - is anyone against this? Probably needs some more justification in the issue to be able to decide.

[Leo] When clients are updated, the PeerID often seems to change. Is there a reason for this? It makes it difficult to track the evolution of new versions appearing on the network. [Jacek] Nimbus changes PeerID at every restart for privacy reasons. There is no reason to keep it the same. Have considered doing this for every connection. Also note that when the peer table is full, Nimbus does not accept any incoming peer requests, so crawlers cannot see it. This helps to avoid DoS. Lighthouse persists PeerID (as does Teku, I believe).

[Leo] Doesn't updating the PeerID frequently damage peer-scoring? [Jacek] This works both ways.

[Danny] It's not always in a client's best interests to make life easy for crawlers. Just need to work around it.

[Saulius] Is it optional or mandatory to rotate PeerIDs? [Jacek] Best to let users choose. For example a boot node should not rotate ID, or where a trust relationship exists between two nodes. On the other hand is privacy of nodes. Rotating helps to prevent validator IDs being linked to a specific beacon node (but not foolproof).

[Leo] Reminder about metrics standardisation effort that is underway. Please implement the standard metrics in releases soon!

---

Chat highlights

From danny to Everyone: 03:07 PM

https://github.com/ethereum/eth2.0-pm/issues/233
https://github.com/eth2-clients/eth2-networks/issues/59

From terence(prysmaticlabs) to Everyone: 03:08 PM

https://github.com/prysmaticlabs/prysm/issues/9450

From danny to Everyone: 03:22 PM

https://medium.com/chainsafe-systems/lodestar-releases-light-client-prototype-40f300361c65

From Mikhail Kalinin to Everyone: 03:27 PM

https://ethresear.ch/t/using-total-difficulty-threshold-for-hardfork-anchor-what-could-go-wrong/10357

From Micah Zoltu to Everyone: 03:31 PM

Ice Age doesn't need to be immediately after the merge. It just needs to happen sometime after the merge to achieve its original goal.
So we can give ourselves lots of breathing room on that front.

From Mikhail Kalinin to Everyone: 03:32 PM

right, it will need to be set in some advance to give us a room for setting the exact merge fork epoch

From Alex Stokes to Everyone: 03:33 PM

https://github.com/ethereum/consensus-specs/issues/2569