description: Notes from the regular Eth2 implementers call
# Eth2 Implementers’ Call #38 - 2020-04-23
[Quick contemporaneous notes by Ben Edgington]
## Testing and Release updates
Release schedule for specs: anything v0.11.x (excluding `x==0`) will be backwards compatible. A v0.11.2 is under review for release today, and it is backwards compatible.
v0.12 is coming, and will include the update to the latest BLS standard (hash to curve). Also an additional validation condition on the fork choice. Not sure about fork choice tests. Will *not* be interoperable with v0.11.
Modified rewards and penalities tests, and refactoring of the existing function to make it less monolithic, is coming (certainly for v0.12, maybe for v0.11.x since non-breaking): 90% of implementation bugs lie in this area. There is a current instance of a bug on the Topaz network here. Topaz will be restarted for v0.12; not planning to restart in the mean time.
The long-term, persistent, multi-client testnet will be v0.12.
Network testing [Proto]: Rumor includes new functionalities (e.g. RPC types). Changed direction for network test vectors. Actively instrumenting all clients is too much work. Instead implement an approach closer to the current spec tests. Clients configure themselves from the tests and run the test script.
Beaconfuzz [Mehdi]. Found about 5 bugs on Nimbus. Two minor bugs on zrnt. SSZ bug on Lighthouse - see blogpost for info. A lot of implementations are treating beacon state as trusted, this is risky if we are moving to warp sync. Clearing up the treatment of overflows and underflows has helped on this. Beaconfuzz design doc to be shared next week.
## Client updates
Getting up to latest spec compliance. Passing v0.11 spec tests. Snappy compression and a few ENR things are outstanding. Fixing up CLI.
Topaz testnet has 21000 validators. 41k slots since genesis. Only one finality failure, now fixed. Could sync Lighthouse until first epoch, but then hit bug mentioned above. Optimisations and improved UX.
- Our JVM libp2p Noise implementation is now interoperating with Lighthouse. From what I understand, the Go implementation needs some upstream fixes before we'll be able to fully interoperate with Prysm using Noise.
- We've implemented batch verification of signatures within blocks for a modest but worthwhile speedup.
- The protoarray forkchoice algorithm has been implemented and tested using Alex Vlasov's fork choice tests.
- Our hot-state management has been reworked to keep all hot state completely in memory. On restarts we regenerate it by replaying blocks onto the last finalised state. The has improved sync speed by a factor of 3 or so.
- Our focus for the current sprint is finishing up all the network changes for v0.11.1. State transition is up to date.
[Raul] Go libp2p Noise fix still pending.
Steady progress on v0.11 testnet. Internal changes to forkchoice. Ops work for running Trinity. Integration with Milagro BLS.
Switched Testnet 1 to mainnet configuration. Some performance improvements to implement. Performance is dominated by hash tree root. There are also some stack overflows. Currently use update and rewind states to apply blocks, but concerned that this could be a DoS vector.
On networking, have improved sync algorithm. Debugging discovery and libp2p and fixing memory leaks. Preparing for audit, cleaning code and checking libraries.
Fixed an interop bug in genesis generation.
On comments above about DoS vector, Nimbus uses "sparse storage": assumes every stored block has a verified signature. In finalised section, state roots are "flattened out".
4k and 16k validator testnets are being run. Not quite up to latest spec. Hope to launch long-running 16k testnet next week. Master is now at v0.11.1 state transition. Have raised several PRs against networking spec. Using ansible to automate testnets.
Some syncing interop progress. Implemented Rust stable futures. Safe arithmetic. Rust linter to find unchecked arithmetic. Server side events for HTTP API. Slashing protection database improvements.
General individual client testnet updates above.
[Afri] Updated testnet spec to v0.11. Started bootstrapping network based on Teku, but not much progress. In general, expect to have mainly single client testnets for a while and do interoperability on shorter-lived testnets: "fail fast" testnets.
[Paul H] Config directory in the repo for testnets is now full of Phase 1 stuff. Not clear what Phase 0 _config.yaml_ should look like now. Would be good to separate out. Prysm will also publish their network config.
## Research Updates
Held steering panel recently. Mikhail working on Eth1--Eth2 merger doc to be published soon. Joe working on cross-shard transaction modelling. Jonny working on _prkl_ network monitoring tool; connected to Topaz and is able to see the DHT and connect to peers. Alex continuing on clock sync, verifiable pre-compiles for execution environments, and fork choice test suite. Dimitry working on discv5 simulation and can analyse around 14 properties.
There is a fix to fork choice. Need to check that beacon block root and target for attestation are in the same chain. Minor change. [PR is up](https://github.com/ethereum/eth2.0-specs/pull/1742).
Also working on fuzzy fork choice tests, and orchestrated attacks.
Continuing to work on account abstraction for Eth1x. Also looking at Eth1x64 proposal[^fn]
[^fn]: Personal note: :disappointed:
Related: Blog post from Axic
Phase 1. Updating current spec. Looking to make it as stable as possible (phase 1 "freeze"). **Action: it's a good time to review the spec.**
There was an API call on Monday. A small working group is trying to make it as RESTful as possible. [Marin] Some updates to the Google spreadsheet. Combine APIs into a smaller set.
[Paul H] There are lots of different verification conditions on attestations, but they might still be valid for fork choice. Needs a lot of care to get right.
## Spec discussion
Danny and Proto working on breaking up the rewards and penalties function into smaller testable units.
[Vitalik] Some good ideas that may be too late for Ph0, but might make it into Ph1. Something about slashing and uniqueness/equivocation. Also make an invariant around the maximum rewards: make it strictly proportional to the inverse sqrt of the number of validators. [Danny] Current spec meets this modulo slashing [and maybe whistle-blower rewards?]
## Open discussion
[Preston] Timelines on future spec releases? [Danny] v0.11.2 is imminent. v0.12 depends on release of next draft of IETF standard; could be any time. Ideally first week of May, perhaps. As for modified rewards function and testing, asap, probably next week. v0.12 is the target for beacon chain genesis, barring finding any critical bugs.
* * *
# Chat highlights
From danny to Everyone: 03:02 PM
From danny to Everyone: 03:28 PM
From Aditya to Everyone: 03:37 PM