---
tags: eth2devs
description: Notes from the regular proof of stake [Eth2] implementers call
image: https://benjaminion.xyz/f/favicon-96x96.png
---
# PoS Implementers’ Call #75 - 2021-11-04
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]
Agenda: https://github.com/ethereum/pm/issues/412
Livestream: https://youtu.be/9U_xj_zCMYg
Note that the eth2.0-pm repo is being deprecated and migrated.
## Kintsugi Office Hours
[Kintsugi milestones](https://notes.ethereum.org/@djrtwo/kintsugi-milestones).
Successor to the Amphora testnet. Target to have a persistent testnet at the end of November: Dec 1 or 2 testnet launch. Weekly devnets meanwhile.
First parts of the fortnightly Eth1 and Eth2 devs calls respectively will be devoted to "office hours" with cross-team updates and discussion.
Expect some minor spec changes during the month, but decreasing as we progress.
### Kintsugi Client Updates
**Geth**
Started implementing Kintsugi spec. Finished but for latest API changes. Expect to update today.
Updated test vectors. Not quite current, fork choice tests still lag.
Haven't merged Amphora changes or reverse sync into master yet. These are a blocker to getting a working testnet. Hacked things together for the Interop, but want to do Kintsugi in production quality. Might be a week or so until Geth is able to sync a network.
**Nethermind**
Just started implementation of Kintsugi spec.
**Teku**
Merging Amphora over to master currently and making the Merge code production quality. Will try to continue this in parallel with Kintsugi.
**Prysm**
Aligning to the new spec.
**Lighthouse**
Also just started. Production ready optimistic sync is under development. Mods to API for early notifications of block proposals.
**Grandine**
Working on tests. But missing integration with execution layer. Expect that to be done in 1-2 weeks.
**Nimbus**
Tracking the spec and about to do November implementation planning.
**Lodestar**
Expect to start implementation next week.
### Planning
Skip devnet next week since people are just getting started. Put up first devnet on 18th November.
[Terence] How does everyone feel about testing optimistic sync? Merge-mock would be a good tool. [Lightclient] Updating merge-mock API now, longer term plan to accept static test vectors.
[Danny] Hive is also available. [Proto] There is a PR for introducing Eth2 clients into Hive. If that's stable, then we'll be able to run the Merge fork with a small config change. Hive will start everything up nicely. Can then plan some more complex test scenarios.
[Marius] Has started fuzzing clients. Some differences in behaviour already found. Also has a tool for sending fast transactions.
Execution clients need standalone tests around the random opcode etc. EF has a test team working on EVM test vectors. [Lightclient] Post-merge, how will Eth1 clients ingest test data? Currently tests are supplied as RLP blobs to an import command. In particular with respect to forking/block trees. [Marius] These are probably not the important tests right now. Straightforward opcode and block tests are easy. [Danny] Action: create a list test vectors to run. Marius has a list of [risky scenarios](https://hackmd.io/z2h_RAJoTHWSRka-9MDEVg). We can start with this.
[Mikhail] Testing of blocks for post-merge should be done via `engine_executePayload` since Eth1 clients won't be reading blocks by any other means (that might follow different code paths).
The #merge-interop channel on Discord is where most conversations are happening. Next week's ACD will also host Kintsugi office hours to start. Can do intermediate calls if required.
[Proto] A PR was merged with respect to fork choice today. Is this canonical for the next devnet? [Danny] Yes, and other updates in the next few days will be included. [Marius] Could we put versioning on the Kintsugi spec to help keep in sync? [Danny] By one means or another we will make updates and expectations clear to teams. We do not expect many changes, and don't want to hold changes back unnecessarily.
Design options for deduplication of execution payloads across layers: let's pick up these discussions this week.
## Other Client updates
**Teku**
Doing a lot of work on the [key management API](https://github.com/ethereum/beacon-APIs/pull/151).
[Danny] Should this be specified in the Beacon API repo, or separately? Leaning toward new API, new repo. Action: move it over to a new repo.
**Lighthouse**
Happy with Altair fork. Chatting with Flashbots about post-merge MEV [many of us are...]. Paul H has put together a doc on this to be circulated. Slasher DB optimisations and deduplication of attestations lead to great disk usage savings.
Need to discuss exiting from Pyrmont to save on infrastructure fees.
**Prysm**
Lots of optimisations on beacon tree structure. Standardisations on beacon validator key API. Looking at proposer boost fork choice modification and doing some refactoring in protoarray implementation in anticipation.
**Grandine**
Studying Altair rewards.
**Lodestar**
Connecting with the Portal Network folks to figure out decentralising networking on the light client.
## Pyrmont
We previously decided to kill Pyrmont. Prater is taking the load.
Could we kill it in an interesting way? Turn off half of validators? Save it for a merge test? But testnets are now easy to set up, so not necessary to keep it.
[Saulius] How much of Pyrmont is run by client teams? [Danny] Rocket Pool used to be a big user, but has now moved on. Believe it's safe to kill Pyrmont now. Action: Danny will do a blog post next week and promote EOL for Pyrmont.
EF runs ~30% of validators. Have already done non-finality tests on Pyrmont. Lighthouse will just exit their validators. Not much value in doing more testing.
## Fork Choice Vulnerabilities
Danny wrote a blog post recently.
These are serious attacks. The proposer boost fix has been thoroughly analysed by Stanford team - believe this is the best remedy prior to the Merge. Was specced in April; Teku has implemented it already. Will do a final pass on the PR, write some tests by the end of the month. Latest inclusion date will be the Merge fork.
## Spec discussion and AOB
[Ansgar] Working on how to handle missed slots with respect to EIP-1559 base fee calculations. There is [an EIP](https://eips.ethereum.org/EIPS/eip-4396) available for this. Might reduce incentives for targetted DoS attacks on validators. Is this a high priority (mitigating targetted DoS attacks) pre-Merge? [Danny] Targetted DoS is definitely an issue or a large operator being down. This is a "nice to have", but not essential. To be discussed on next ACD.
[Mikhail] Anyone want to talk about the latest fork choice updates? [...crickets...]
* * *
# Chat highlights
From danny to Everyone: 02:02 PM
: https://github.com/ethereum/pm/issues/412
From danny to Everyone: 02:04 PM
: https://notes.ethereum.org/@djrtwo/kintsugi-milestones
From Mehdi Zerouali to Everyone: 02:11 PM
: https://github.com/sigp/lighthouse/pull/2768
From MariusVanDerWijden to Everyone: 02:25 PM
: https://hackmd.io/z2h_RAJoTHWSRka-9MDEVg
From MariusVanDerWijden to Everyone: 02:36 PM
: We should also start doing some benchmarks. I resynced Pithos today (took 50 min on Lighthouse) with geth consuming ~5% CPU 300MB RAM, Lighthouse 400% CPU 300MB RAM for a basically empty chain
LH datadir: 1.2GB Geth: 150MB
From Alex Stokes to Everyone: 02:39 PM
: is this for the remote signer? or something else?
From Adrian Sutton to Everyone: 02:40 PM
: This is for validator clients so there’s standard APIs to add and remove validator keys
From Alex Stokes to Everyone: 02:40 PM
: i’m guessing this
https://github.com/ethereum/beacon-APIs/pull/151
From James He to Everyone: 02:40 PM
: that’s right
From Ansgar Dietrichs to Everyone: 02:58 PM
: https://eips.ethereum.org/EIPS/eip-4396