--- tags: eth2devs description: Notes from the regular proof of stake [Eth2] implementers call image: https://benjaminion.xyz/f/favicon-96x96.png --- # 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](https://github.com/ethereum/consensus-specs/releases/tag/v1.1.0-beta.3), 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](https://github.com/eth2-clients/eth2-networks/issues/59). Prysm ran into [an issue](https://github.com/prysmaticlabs/prysm/issues/9450) 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](https://ethresear.ch/t/using-total-difficulty-threshold-for-hardfork-anchor-what-could-go-wrong/10357). 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](https://github.com/ethereum/consensus-specs/issues/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