description: Notes from the regular proof of stake [Eth2] implementers call
# PoS Implementers’ Call #64 - 2021-05-20
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]
Note that the specific Merge call will be moved to just ahead of this call from two weeks hence.
## Client updates
Altair: successful tests on networking and gossip. Finalising changes to the validator client. Doing a detailed review of Altair changes ahead of merge into master branch.
Nocturne node ran without incident. Published a blogpost on the v1.4.0 release. Weak subjectivity sync is working, but backfilling blocks is not done yet. Interested in whether everybody is backfilling to Genesis or not. [Adrian] Teku is backfilling to Genesis right now, but we would like to shorten that to the weak subjectivity period when this is reasonable to do, i.e. when other clients don't need the data to sync.
Altair: working on many infrastructure changes around the validator client, the Merge, and Altair. Expect to do Altair testing soon. v1.3.0 release includes a migration guide between clients. New command to test validator performance for hardware verification. Now have official binaries for MacOS, including M1 processor. Improved slashing protection DB, with better disk I/O. Will allow more validators on same H/W, e.g. Raspberry Pi. Improved validation of attestations received so that they are not rebroadcast. Also improved attestation subnet transition times.
Coming soon, yet another large I/O improvement, to do with caching of state.
Altair looking good. All parts are in place. Small networks of multiple nodes are working smoothly. Lots of PRs raised against the [standard REST API](https://github.com/ethereum/eth2.0-APIs/pulls) to support Altair - some remain open, mostly based of Jim McDonald's initial proposal. Teku's implementation is mostly done, except "state" stuff which is nearly there.
Propose running a tiny devnet with an Altair node that other teams can try syncing against.
Aligned with alpha 5 on Altair. Passing state transition tests. Working on networking etc. Bit behind due to lack of generics in Go.
v1.3.9 is out. Several improvements: updated Go library; max-cover algorithm for block proposals; working on weak subjectivity sync. Production optimised slasher to be released next week.
All Altair pieces done up to alpha 3. Small testnet running. Upgrading now to alpha 5. Also creating a light client prototype: currently hooks into a mock beacon chain. Will attach it to Altair when ready.
### Spec and testing
Alpha 5 had several refinements. Alpha 6 due tomorrow, basically more testing, features are stable. Resolution of [resource unavailable](https://github.com/ethereum/eth2.0-specs/issues/2414) error code should be in the next days. This is not a complete spec freeze, but basically stable subject to further feedback from teams.
Plan to fully freeze spec and set fork dates once interop is demonstrated.
Targetting first half of June for short lived testnets and final spec. July to fork testnets still looking good.
Fuzzing update [Mehdi]: found a couple of interesting bugs; working with teams to fix. Two client teams are ready for fuzzing of Altair now, two not.
[Proto] There is a PR open to [improve the config format](https://github.com/ethereum/eth2.0-specs/pull/2390). It separates compile time config from runtime config. **Action: review and send feedback** With sufficient feedback, it can go into tomorrow's release. Constant values remain unchanged, only focused on client configuration experience.
## Research Updates
Rayonsim and Merge latest: Just closed the testnet yesterday. It was a success :tada: Three execution clients, four consensus clients. Now need to rebase on production code in clients and separate out the API. Also need to work on the transition process and state sync. There is time to do the research and spec work while client teams work on London and Altair. Plan a future larger testnet with state sync and transition. There is an ongoing conversation about the nature of the consensus API.
Q: Will we need another endpoint in the API for state sync? A: The current message set ought to be sufficient.
Also note that work on sharding and withdrawals continues. Devnets will be run outside the Rayonism project. Latest design for withdrawals: https://hackmd.io/@zilm/withdrawal-spec
Has added Altair to the [annotated spec](https://github.com/ethereum/annotated-spec/blob/master/altair/beacon-chain.md) repo.
## Spec discussion
[Hsiao-Wei] Request for feedback on [Align fork epoch with the start of `EPOCHS_PER_SYNC_COMMITTEE_PERIOD`](https://github.com/ethereum/eth2.0-specs/pull/2417). [Jacek] An 8192 epoch boundary might be also cutting with the grain of the spec since it is the size of the first layer of the block root accumulator. Use hash tree root of accumulated block roots as the reference. This would be very convenient for large archive nodes, or putting states onto BitTorrent. [Adrian] Some corner cases when sync committees do not line up with the fork, but nothing too hairy; Teku can handle any fork epoch. Avoiding being close to the end of a sync committee period makes sense, since it takes time to find peers. [Danny] But the first two sync committees are the same, so it probably doesn't matter too much since the first one is effectively double length. [Dankrad] Aligning the timing is inconvenient and will lead to difficult trade-offs - it could take a while to find a convenient time for the fork. General view seems to be that _not_ syncing with the sync committee period is ok.
[Update: see [this PR](https://github.com/ethereum/eth2.0-specs/pull/2428) for a more coherent explanation of Jacek's proposal.]
* * *
# Chat highlights
From danny to Everyone: 03:09 PM
From protolambda to Everyone: 03:18 PM
From terence to Everyone: 03:25 PM
From Mikhail Kalinin to Everyone: 03:26 PM
From Hsiao-Wei Wang to Everyone: 03:27 PM