--- tags: eth2devs description: Notes from the regular Eth2 implementers call image: https://benjaminion.xyz/f/favicon-96x96.png --- # Eth2 Implementers’ Call #43 - 2020-07-09 [Quick contemporaneous notes by Ben Edgington] Agenda: https://github.com/ethereum/eth2.0-pm/issues/165 Livestream: https://youtu.be/4IooxDX_GfU ## Testing and Release updates v0.12.2 is on its way. It is backward compatible. Just tuning gossipsub parameters before release. [Proto] released Rumor v2 last week. Improved scripting. Lots of new commands. Still doing some work on some commands (e.g. sync). Phase 1 test generation has begun. Python Eth2 spec (pyspec) has been updated. It is likely that using Rumor will be the best way to implement fork choice tests, rather than implementing interfaces in all clients to do this. Proto is releasing a tutorial for Rumor. [Danny] Recommends that all teams take a look at Rumor. [Mehdi] Beaconfuzz update. Write up coming. Dockerisation of Beaconfuzz completed so that it can be run by users at home. There is a Discord channel for reporting and discussion. Found two high-severity vulnerabilities: one in Nimbus (client crash), one in Loadstar (memory exhaustion due to invalid ENRs). Upstream patch to Rust snappy crate has finally been fixed. Switching focus back to differential fuzzing now. Found 26 bugs total so far across all clients. ## Testnets Altona running well. A period of non-finality occurred and passed. Danny reaching out to teams to check readiness for large public testnet. A couple of stability things and UX things to be worked on, but almost there. Danny has been using Proto's scripts to spin up networks that can be used as attack-nets. EF plans to run these all on their side so as not to burden client teams. ## Client updates **Lodestar** Merged v0.12 branch. Lurking in the Altona network, but not yet synced to head. Gossipsub 1.1 not yet merged. Started connecting Chrome debugger to Lodestar - very handy. Optimised some of state-transition. Further work on stability side. Closing in on minimum-viable client. **Trinity** Working on syncing Altona. Refactoring fork choice to implement proto-array. Work on syncing - can connect to Lighthouse nodes and pull blocks, but very slow. Will work on optimising. **Nethermind** Mostly focused on Eth1 client for now. Hope to re-engage with Eth2 soon. Nethermind published [an article](https://medium.com/nethermind-eth/using-nethermind-to-run-a-validator-in-eth2-5c227653e197) on using the client as an Eth1 data provider for beacon nodes. It works. **Nimbus** Fixing bugs raised by joining Altona: gossip and missed attestations. Audit starts on Monday. Working on an [auditors' handbook](https://status-im.github.io/nim-beacon-chain/). Also an article on [using Nimbus](https://status-im.github.io/nim-beacon-chain/). **Prysm** Lot of work on key management. New features around creating accounts. Remote keystore. Integrating Supranational Blst library. Initial results are promising. Initial sync speed much improved, via batch signature verification (2-3x improvement). **Lighthouse** Working on REST API to help UI work. Also integrating Blst library, seeing good speedup. Working on peer scoring. Investigating reports of a deadlock. Also observed some issues with attestation efficiency. Working on a Slasher - design phase. Refining DB access atomicity. Have responded to ToB audit and will publish the report. Are selecting auditor for a second security review. **Teku** Finished improvements to memory management. Memory usage much more stable. Now persist protoarry to disk for quicker start up. Peer management improvements. Prioritising connections for even exposure to subnets. Fixed [interesting bug](https://www.symphonious.net/2020/07/06/exploring-ethereum-2-the-curious-case-of-the-invisible-fork/) that caused some invalid attestations. ## Incident response Mehdi (Sigma Prime) will be working on formalising the incident management response framework for Eth2. Will create a small working group with a rep from each client. [Mamy] Timezones are a challenge: need to make sure a spread of people is available from each team across TZs. ## Weak subjectivity Aditya published research and recommendations on [handling weak subjectivity](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2). How to handle client-side, and how to distribute updated states? A variety of ways are discussed in the doc. Want feedback from client teams. [Danny] Whatever else we do, it is important to allow a user to override. Clients could either encode the state-root or entire state into releases. There is an implied regularity of release. Around 1 week is realistic with expected numbers of validators. [Jacek] Expecting client teams to sign-off on a state makes us targets to be coerced into signing something different. And mistakes could lead to liability issues. [Aditya] But it won't break the network if we get it wrong, at least. [Danny] What would be the best UX around this? Are there decentralised solutions? [Zahary] Could require multiple signatures on the state from client teams and EF (web of trust-like). [Jacek] A web of trust is more desirable that relying on one client team. [Aditya] We should offer a range of options. [Jacek] This activity is currently not incentivised for client teams. [Terence] We should make a working group to discuss. **Action: Aditya to convene weak subjectivity WG.** **Action: client teams need to implement an interface to be able to load up arbitrary states if they don't already have one.** ## Research Updates **TX/RX** Onotole transpiler for the Phase 1 spec is being worked into Teku. Mikhail has made a simulator for Phase 1 that is running well. **Vitalik** Can we change the spec to allow easier verification of state transitions? Signature verification and end of epoch processing take the most compute resources. Epoch processing involves walking through the whole validator set. Can we reduce this or improve it with a Snark? Recomputing the validator balance merkle tree is about 1 million hashes. Could we instead use a Kate commitment to store validator balances? A balance update then becomes an elliptic curve addition. Benefit is being able to update on-the-fly rather then everything at the end of epoch. Still O(N), but less work than hashing. This could be augmented with a proof that balances were modified correctly, and everyone else just checks the proof. Putting signature verification in a Snark for the whole transition is also interesting. ## Networking Do we need non-snappy Req/Resp domain? Seems that people are leaning towards "no", but need to see efficiency numbers on this before final decision. Refining gossipsub parameters. There is [a PR](https://github.com/ethereum/eth2.0-specs/pull/1958) in the spec repo for discussion. [Jacek] Has a modification to the GOODBYE message to give reasons for disconnect. Wonders whether to put this up as a PR to the spec. **Action: Jacek to make PR and client teams to comment** Getting some more visibility into gossip is going to be important. We have little insight at the moment when things like attestations fail to be included. Good project for someone to pick up if possible. ## Spec discussion There is a v09 of hash to curve out. Carl has looked though and neither v08 nor v09 changes affect Eth2. It is sufficient to support v07. ## Open discussion [Carl] Eth2 Launchpad. We are getting much closer on standards around keystores. [Notes from Mamy](https://github.com/ethereum/eth2.0-pm/issues/161). Recommended: run through the Launchpad process and check how it fits with your client's workflow. A single password encrypts all a user's validators. **Action: Do this. Make client modifications as required. And document the process.** Plan to be using Launchpad on next testnet. * * * # Chat highlights From danny to Everyone: 03:21 PM : https://github.com/ethereum/eth2.0-pm/issues/165 From Mamy to Everyone: 03:38 PM : https://status-im.github.io/nim-beacon-chain/auditors-book/ From Tomasz Stanczak to Everyone: 03:38 PM : also logs extraction in Nethermind is super fast - we created a hierarchy of bloom filters for logs based on something that Parity had but with some additional heuristic around the fill ratio of blooms From Mamy to Everyone: 03:38 PM : https://status-im.github.io/nim-beacon-chain/ From Tomasz Stanczak to Everyone: 03:38 PM : so if you want to get all the deposits at once you should see nice results From Meredith Baxter to Everyone: 03:44 PM : https://www.symphonious.net/2020/07/06/exploring-ethereum-2-the-curious-case-of-the-invisible-fork/ From Me to Everyone: 03:48 PM : https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2 From Carl Beekhuizen to Everyone: 04:21 PM : https://github.com/ethereum/eth2.0-pm/issues/161 From Carl Beekhuizen to Everyone: 04:21 PM : https://github.com/ethereum/eth2.0-pm/issues/161 https://serene-carson-3331d5.netlify.app/ [password omitted]