description: Notes from the regular Eth2 implementers call
# Eth2 Implementers’ Call #51 - 2020-10-29
[Quick contemporaneous notes by Ben Edgington]
## Testing and Release updates
A malformed test vector has been fixed, but not yet released. Most teams have manually worked around. Danny wants to add a couple more tests before releasing an update. Looking at doing some test vector reform to reduce size, generation time, and include fork choice tests. Will try not to change things too much before mainnet. Generally the same structure, but some slight mods.
## State of Medalla
Some instability every 4 or 8 epochs (big periodic drops in participation) [see notes under [Open discussion](#Open-discussion)].
## Client updates
Audit is complete and we are happy with it - will share soon. Performance improvements: rework state-regeneration to improve memory consumption; fix long pause at end of non-finalisation; optimise get-ancestor to make lookups much more efficient.
Updated to discv5.1. Continuing to implement standard API. 20x speed-up in SSZ serialisation for large states. Start client from recent state for weak subjectivity.
Release that updates to v1.0 of spec. Discv5.1 also out on Medalla. Finishing up standard API. Adding HTTP endpoints for WebUI. Monitoring gossipsub v1.1 scoring parameters - will share. Performance updates, in particular memory stuff. Bug fixes.
Getting pubsub up to spec: implement signature policy. Merged in slashing protection interchange format. Finishing up standard API. Completing refactor of core chain logic to pull in into a separate module for independent use. Release coming soon.
Had first Beta release (previously only Alpha). Investigating Medalla performance; may have a fix. Working on standard API. Open issues down from 100 to 70 - just ploughing through them now. ToB audit went well.
Deployed discv5.1 and BLS v4 on Medalla. New optimisations. Running stably; memory usage roughly constant. Working on some new Makefile targets to run benchmarks more easily. Working on a way to start from a weak subjectivity state. Reduced required data for this - would like to discuss standardising the format for checkpoint states.
## Research Updates
Phase 1 data availability work. Exploring expedited data availability that makes shards explicitly data shards using Kate commitments. Looking at subnet structure for data availability sampling. Proto is doing some prototyping. Investigating bringing shard block time to much less than one slot.
Question: Which type of erasure codes? Just standard Reed--Solomon with BLS12-381 for the elliptic curve.
Continuing to work on network crawler. Can find IP addresses, country, city, latency of clients. Will post [link to data](https://github.com/leobago/BSC-ETH2/blob/master/Armiarma/Armiarma.md).
### Serving historical blocks
When starting from a weak-subjectivity state, how to handle serving historical blocks. Spec: blocks-by-range requests should be served within the WSP. So clients should backfill blocks at least that far (could go all the way back to genesis, but not required). What happens when you receive a request for blocks you don't have needs better definition. [Meredith] Teku is planning to backfill blocks, but this takes time, so we still need to handle this case meanwhile. [Age] Could advertise what blocks we support via ENR or metadata. If not present, it means the client has all the required blocks (back through WSP). [Danny] Returning an error is better than returning empty data. [Meredith] Putting info about available blocks on the STATUS message could work.
Lighthouse does a PING every 30s with metadata sequence number; looks like Teku does every 10s; Prysm twice per epoch; Nimbus not at all.
**Danny will look into it and create an issue for discussion on the specs repo.**
### Standardising checkpoint format for WSP
Starting from weak subjectivity period. Problem: to make Merkle proofs to check deposit inclusion we need the entire set of historical deposits. There is a way to do this incrementally give a subset of the deposit merkle tree.
Suggest standard format: `State:Deposits(compressed):metadata`.
**Discuss further in WSP Telegram group.**
### Gossipsub v1.1
It's a good time to review the scoring parameters and get them into the specs.
Lighthouse has some nodes set up with this and you can see how they score other nodes. However, for the network to function well, all nodes should have similar parameters. Might we worth studying in a smaller network before pushing to Medalla. But, behaviour may differ according to total number of validators. Can the params be adjusted based on validator set size? [Ben@SigP] has a Python script to estimate these and update at runtime.
**Please review [the issue](https://github.com/ethereum/eth2.0-specs/issues/2009#issuecomment-712190681) on the specs repo.**
## Spec discussion
## Open discussion
Progress on Blst audit? Expect final feedback next week, and can then "pull the trigger on everything".
[Dankrad] Inactivity leak on Medalla does not seem to be leading to increase in participation. [Danny] Likely due to an instability in Prysm that every few epochs raises resource consumption on nodes. Prysmatic team is getting a fix out. [Danrad] Would be good to check the stats in any case to ensure that there is no problem. [Danny] Agreed.
* * *
# Chat highlights
From Leo BSC to Everyone: 02:18 PM
From danny to Everyone: 02:33 PM