--- tags: eth2devs description: Notes from the regular Eth2 implementers call image: https://benjaminion.xyz/f/favicon-96x96.png --- # Eth2 Implementers’ Call #42 - 2020-06-25 [Quick contemporaneous notes by Ben Edgington] Agenda: https://github.com/ethereum/eth2.0-pm/issues/162 Livestream: https://youtu.be/P1AEmUt9ltg ## Testing and Release updates Releases. Some things are pending: testing improvements. Minor version release expected soon (Tuesday), totally non-substantive. [Proto] Extending Rumor to do chain testing. Higher level commands that allow easier sync tests, benchmarking, fork choice tests, etc. Easier than integrating tests individually into each client. Audits: please provide any feedback, esp. spec bugs found. ## Testnets ### Altona Some delay in the deposit process. We now have the minimum number required (640), and have also reached `MIN_GENESIS` time. This would place the genesis at the weekend, so we may move it until Monday. Afri will not be available from Monday, however. But he does not control any genesis validators, so this should be ok. Proposal: add an extra 4 days (96 hours) to `GENESIS_DELAY`. **Further discussion after call on the Altona Discord channel.** ### Attack nets Danny has circulated a discussion document. Assumption is that there is only a subset of users interested in breaking things, so make them a testnet and provide bounties. EF will likely run this with the stable validator clients available at the time. Swift iterations. Aim is to not put extra burden on client teams. Target, within 2 weeks. Question, do clients need to provide byzantine behaviour via RPC? Not necessary. Burden is on the attackers. Initial attack nets may put validators out of scope and test only DoS, etc. Could gradually release sets of keys to attacking parties to slowly ramp up the pain. ## Client updates **Prysm** Good 2 weeks. Quantstamp audit complete. Focused on fixing the vulnerabilities found. Onyx is stable with 50k validators. Memory use of Prysm is improving. Working on Slasher: improved disk io and performance. Working on validator accounts/key revamp per the EIP revisions and best practice. **Trinity** Up to spec 0.11.3; working on 0.12.1. Preliminary refactoring before working on fork choice updates. Improving sync, and plan to join Altona, but expect performance issues. **Teku** Non-blocking RPC. Supranational Blst library integration started. Memory and storage optimisations. Merged 0.12.1 into master to support Altona as default. **Lighthouse** Preparing for Altona, syncing other clients. Spec 0.12 is ready for merge. Discv5 optimisations. Refactor of fork choice. Peer management scoring. Authentication scheme for the UI. Adding atomicity to database for consistency. Looking at imlpementing Blst library with fallback to Milagro for ARM. Key management work. **Nethermind** Deposit porcessing performance improvements. Lots more work to do on peering and latest spec updates. **Lodestar** 0.12 updates - there except for gossipsub. Won't be ready for Altona genesis, but aim to join later. Debugging transition from sync to gossip. Plan to rewrite validator CLI around key management best practice. **Nimbus** Getting ready for Altona. Performance inprovements, esp. start-up and reloading times: 20-100x improvements by caching keys. Memory leak improvements. Fixed beacon fuzz bugs. Progress on validator split. Ongoing work on BLS backend: Milagro, Herumi, or Blst to be decided. Networking. Metrics for discv5. Can finalise on Onyx. ## Research Updates [Aditya] Weak subjectivity: working on a doc that investigates how clients should handle this. For safety reasons, clients should start from a more recent state than genesis. About 14 days in the past. Part of client team workflow will be to distribute checkpoint states every 7-10 days. For discussion, how to distribute. Further discussion on Discord and next call. [Carl] Key handling. Had a call last week to discuss and agreed many things. Specifically EIP2333 has a breaking change on key derivation. Path requirements have been relaxed for withdrawal keys. For key store, handling Unicode passwords - uses the same mechanisms as mnemonic generation. There is now a description field. EIP 2335 keystores are the minimum that clients should support. Would like to add minimum best practice guidance to the specs repo in lieu of standards. [Vitalik] [GKR post](https://ethresear.ch/t/using-gkr-inside-a-snark-to-reduce-the-cost-of-hash-verification-down-to-3-constraints/7550) on Ethresearch looks worth following (hashes in Snarks). Useful for witness compression, instead of polynomial commitments and Verkle trees. [Dankrad] Concern, however, that it uses algebraic hash function. Witness compression timeline is 3-5 years. Another option is Pedersen hashes. [Leo] Evaluating gossipsub. Would like to collaborate with clients around any weird behaviours observed. [TXRX] Working on validator deanonymisation. See [Packetology](https://ethresear.ch/t/packetology-validator-privacy/7547) series on Ethresearch. Also working on a Phase 1 client. ## Networking Specs currently support both Snappy and non-Snappy in Req/Resp domain. Is there a use case for continuing to support non-Snappy here? Seems not... Clients can always keep it if they want to. [Jacek] Note that we haven't thoroughly analysed the effectiveness of Snappy compression. Intuition is that attestation bit fields compress well. Anyway, we should do the tests. **Action: check compression numbers as a sanity check** (Leo volunteers). There is an [open issue](https://github.com/ethereum/eth2.0-specs/issues/1931) on the specs repo. Not everyone supports _yamux_ in libp2p. There have been some compatibility issues between Lighthouse and Prysm. Easiest is to disable _yamux_ support until it can be debugged. [Jacek] Has been hard to find clients on Witti supporting the latest Noise spec. Which teams have updated? Is the Noise spec versioned? Lighthouse and Prysm can't interconnect with Noise right now. The network is probably falling back to _secio_. Nimbus (and Danny) would rather disable _secio_ completely. **Take discussion to networking Discord channel.** [Jonny] Maximum clock disparity parameter in the spec. Currently set to 500ms - how will we validate this number? Nimbus heuristically increased this number to improve performance on Witti. Avoids having to queue packets (which is the proper solution). A larger value allows more scope for timing attacks. **Jonny to open an issue to discuss.** Also, a scan for other constants that might need tweaking. ## Spec discussion Nope. ## Open discussion Nothing further. * * * # Chat highlights From danny to Everyone: 03:02 PM : https://github.com/ethereum/eth2.0-pm/issues/162 From Me to Everyone: 03:31 PM : https://ethresear.ch/t/using-gkr-inside-a-snark-to-reduce-the-cost-of-hash-verification-down-to-3-constraints/7550 From Leo BSC to Everyone: 03:32 PM : https://github.com/leobago/BSC-ETH2 From Joseph Delong to Everyone: 03:34 PM : https://ethresear.ch/t/packetology-validator-privacy/7547 From Jonathan Rhea to Everyone: 03:35 PM : https://ethresear.ch/t/packetology-eth2-testnet-block-propagation-analysis/7561 From danny to Everyone: 03:40 PM : https://github.com/ethereum/eth2.0-specs/issues/1931