description: Notes from the regular proof of stake [Eth2] implementers call
# PoS Implementers’ Call #78 - 2021-12-16
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]
Livestream: https://youtu.be/SKPQSR9CD24 (apparently this did not stream automatically - if a recording can be found then it will be uploaded later.)
## Kintsugi office hours
Devnet 3 has been running for a week; just launching the Kintsugi testnet.
Devnet 3 had a bunch of config issues to start with, but has been stable since, and several client issues have been worked out. Prysm and Besu joined towards the end of the week.
The Kintsugi testnet started today. Lots of [resources](https://kintsugi.themerge.dev/) are available. Not yet reached Merge - should happen today.
Feel free to join Kintsugi. EF blog post planned for Monday. Client teams, please double check that your [info on joining](https://hackmd.io/dFzKxB3ISWO8juUqPpJFfw?both) is correct.
- [merge-devnet-3 tracker](https://github.com/eth-clients/merge-testnets/issues/3).
- [Kintsgi Tracker](https://github.com/eth-clients/merge-testnets/issues/4)
### Research updates
[Mikhail] [Proposed changes](https://github.com/ethereum/execution-apis/pull/146) to the API.
1. `getPayloadBodies` method - **last call for comments!** Will merge it this week if no objections.
2. [Refine message ordering](https://github.com/ethereum/execution-apis/pull/148) proposal. Try to avoid any statefulness for the sake of load-balanced deployments. **Please review!**
Working further on optimistic sync; ideas welcome. It is not straightforward. For example, there is an edge case with the transition block (lengthy technical discussion ensues - sorry, too detailed to capture). Several open questions remain.
[Jacek] There is an alternative to optimistic sync: light client sync. We'd need to complete the light client protocol before the Merge, and all clients would need to serve light sync information. [Mikhail] Is light client sync as safe as a normal sync from weak subjectivity checkpoint? [Vitalik] There are more security assumptions with light client sync, such as relying on smaller committees than the whole validator set. Also, there is a defacto 1-day weak subjectivity assumption, since sync committees update daily. So if beacon chain not finalised within a day there could be an issue. There is a `light client sync` Discord channel, or `merge general` is ok.
[Marius] is prepping a shadow fork of Goerli, with deposit contract. Made 100 deposits. Documenting this currently. This will allow better testing of syncing.
[Saulius] was there a conclusion as to what we should display to end users as a block number post-Merge? [Mikhail] feels this should remain as-is for execution payloads (i.e. block height on the execution chain), but explorers can link through to the beacon block as well.
## Client updates
Working towards a release. Mostly Merge/Kintsugi stuff for now.
Mainly focusing on Merge. Micro-optimisations. Switch from Protobuf to native Go struct to help memory usage.
Working on key manager API: v2.0.5 has alpha version of key manager API standard. Has been a cross-client team collaboration. All clients plan to support Web3Signer as well. Should help home stakers and pre-packaged nodes to migrate more easily between clients.
Planning pre-release soon with Kintsgi v3 and v1.1.6 updates. Proposer boosting is in place but disabled by default.
Realised that some caches were not doing well with short term reorgs. Optimising this.
Work on optimistic sync and its edge cases. Open for discussion.
Working on an incident and performance analysis platform to monitor the beacon chain for issues or regressions. Not ready to reveal just yet.
Log4j drama - a couple of releases to handle this: v21.12.2 is latest.
Validator key management is implemented, but not yet published. Continuing to work on authentication.
Also continuing to work on the Merge. All integrated and ready for Kintsugi in v21.12.2.
Mainly working on Merge code. Experimenting with replacing RocksDB with DBx.
Light clients: did a complete demo at CSCON. Working with EF to get this on Kintsugi. Working on key manager. Working on stable release process, and fixing some reported vulnerabilities.
## Spec discussion and AOB
[Leo] New version of [Migalabs crawler](https://medium.com/@migalabs/6268387a88dc) released.
Next meeting: do we need one on the 30th? No enthusiasm. There is an ACD in 3 weeks that we can use to catch up.
Naming: good response! There is [a shortlist](https://notes.ethereum.org/@hww/stars-of-B). Cat Herders breakout room planned on Dec 20th, 14:30 UTC to make a decision on the star name for consensus layer Merge upgrade.
* * *
# Chat highlights
From pari to Everyone 02:03 PM
From Tim Beiko to Everyone 02:06 PM
From Mikhail Kalinin to Everyone 02:07 PM
From Saulius Grigaitis to Everyone 02:40 PM
: The issue I mentioned https://github.com/sigp/lighthouse/issues/2691
From james to Everyone 02:42 PM
From james to Everyone 02:43 PM
: Discussions have been on the stakehouse channel for key manager api standards
From pari to Everyone 02:46 PM
: @Sean, couple of people from Eth research, RIG and DevOps started thinking of a similar network p2p monitor. Maybe we can merge efforts or see how they are different to avoid re-development efforts?
From seananderson to Everyone 02:47 PM
: Thanks @Pari, will pass the message along!
From Leo BSC to Everyone 02:49 PM
From Hsiao-Wei Wang to Everyone 02:51 PM
: Next CL hard fork (The Merge) code name nominations: https://notes.ethereum.org/@hww/stars-of-B