description: Notes from the regular Eth2 implementers call
# Eth2 Implementers’ Call #37 - 2020-04-09
[Quick contemporaneous notes by Ben Edgington]
## Testing and Release updates
Found a small issue in a couple of tests (expected to fail tests failing for the wrong reason). There is an [open issue](https://github.com/ethereum/eth2.0-specs/issues/1713) in the specs repo. There are a couple of clarifications in the networking spec which are non-breaking. Might release v0.11.2 after collecting any more non-breaking changes.
[Proto] Tooling for testing has been improving. Python spec is optimised and running reasonably fast (40 slots/sec on Lighthouse network). ZRNT doing 49 slots/s with BLS, and 217 w/o BLS.
Network testing [Lakshman]. Creating network testing suite using Rumor. Will contact teams to discuss setting up clients.
## Client updates
**Action: teams to send Danny the tasks they need to complete to get v0.11 testnets running with target timeframe.**
Running v0.11 in final testing. Expect new testnet launch in a couple of days.
Better slashing detection. Initial sync optimised. Integrated with beaconfuzz and found some bugs. Security audit RFP is out.
Working through v0.11 changes. v0.10 was merged a few days ago. About to merge discv5 implementation. Should have a node capable of sync within a couple of weeks.
Up to date with v0.11.1. Doing internal testing before launching new testnet with all protocols for mainnet.
Working on better peer management heuristics. Snappy compression and RPC testing.
Synced to Lighthouse testnet head. Made some good stability improvements. Performance improvements to 7-8 blocks/s with 32k validators. Implemented RocksDB. Improved attestation handling. Just starting to look at v0.11; expect to be ready in ~2 weeks.
Up to date with v0.11.1. Protoarray based fork choice is almost ready. Benchmarks: added BLS benchmark suite, and will publish mobile and raspberry pi figures soon.
On networking: stability improvements. Some edge cases in block syncing. Noise is almost done; Snappy is done; discovery looks good, now refining.
Currently trying to sync to Lighthouse network, but found a strange consensus issue.
On v0.10. Working on sync and session management.
Mainly working on stability and v0.11 updates. Should be ready for testnet in a couple of weeks.
Still working on Coq model - the theorem bound of what is slashable with dynamic validator sets. Also K model, abstract state transition of beacon chain. Working on linking these two. Will share work in next few weeks.
[Afri] Setting up a Lighthouse based testnet, and have incorporated a Teku node. Looking at adding Teku validators. Testnet has stopped and is being reset. Goal is to explore capability of clients. Currently only v0.10 clients. Looking forward to supporting v0.11 and broadening to more clients.
Name of this initiative is [Schlesi](https://github.com/goerli/schlesi).
## Research Updates
Phase 2 things. Lots of discussion over the last couple of months.
Teams have been working on execution environent logic, state provider networks, static vs dynamic state access, and so on. Now looking at how to deliver a stage 1.5 sooner rather than later.
Doing a case-study on putting account abstraction into Eth1.x as a step towards EEs. Also looking at Eth1x64, which is Eth1 on all shards. Need to decide whether Eth1 can be upgraded, or whether we do a new thing in order to deliver execution on Eth2.
Also working on Eth2 book. Will be submitted to Moloch DAO and Gitcoin Grants.
Danny has [posted an article](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) on the relation between Eth1 and 2.
Working on Eth1--Eth2 merge requirements and constraints document.
Updated Mothra (wrapped libp2p) as part of building prkl network monitor.
Also continuing to work on discv5 simulator and fork choice tests.
Hashes and polynomial commitments. Pushing forward on quantifying the benefits of getting rid of Merkle trees using polynomial commitments. There are also possible ways to use Snarks instead.
Some of these ideas may find their way into Phase 1.
Research group is working on a simulation of topics on discv5. Grant proposal will be submitted for this work.
Go implementation is now in Geth master branch.
Supranational, the team working on the VDF project, is implementing a performance-oriented BLS12-381 library that is amenable to formal verification. May do a 3-way collab between EF, Protocol Labs and Supranational.
Already faster than Herumi on all measures. Also there are new ideas for batch operations. Could lead to 2x speedup over Herumi.
[Mamy] is already discussing batch API with Herumi.
Supranational lib is not open source yet, but should be available in a few months.
Will have a specific call on networking either next week or the following.
## API Standardisation
There is an existing APIs repo. Prysm has implemented a somewhat different API which some block explorers are using. It is protobuf based.
Infura is proposing to lead a standardisation effort. Proposal is to start from Prysm's protobuf spec, but there is some push back on this. See discussion on the [agenda](https://github.com/ethereum/eth2.0-pm/issues/141).
Need to decide data format for representing byte strings.
[Age] OpenAPI can be automatically translated to protobufs. [Danny] One issue is that our datatypes are not easily ported to any existing format. One option is to define everything in terms of SSZ. [Mamy] Proposal for a specific API call. [Preston] Pretty much everything in JSON is a string, so we just need some type info. Base64 vs. Hex - it's not a complete blocker for Prysmatic to use hex, just needs some time invested if we go in that direction. Prysm already exposes a JSON endpoint with Base64 encoding. [Raul] OpenAPI recommends using Base64.
[Danny] Let's take this to an issue, and meet on Wednesday to follow up. **Action: Mike Goldin to create an issue**. Three issues: (1) Overall data format; (2) Agreed set of API endpoints; (3) What migrating from protobuf -> OpenAPI or vice versa looks like.
[Mike] Infura's concern: validator APIs are quite well specced, but beacon node API is not yet covered.
[Jacek] Would a one-off conversion of the Prysm protobuf to Swagger/OpenAPI be worth trying? **Action: to try this before next week**.
[Preston] api.prylabs.network is Swagger docs generated from their interface.
## Spec discussion
Reminder: Bug bounty programme is running.
## Open discussion
[Pooja] Request from cat-herders. There is [a survey](https://docs.google.com/forms/d/e/1FAIpQLSeadXscoQgrKznUOAEB_jSzNNFKHWDEFJxKH1LpDsDsC6mXpw/viewform) linked from the agenda comments around EIP process. Would encourage devs to complete it.
* * *
# Chat highlights
From danny to Everyone: 03:02 PM
From protolambda to Everyone: 03:03 PM
From Mamy (Nimbus / Status) to Everyone: 03:06 PM
From Lakshman Sankar to Everyone: 03:06 PM
From protolambda to Everyone: 03:08 PM
@mamy https://github.com/protolambda/not-a-client is the zrnt lighthouse sync experiment. hope you like the name, haha
From danny to Everyone: 03:18 PM
From Mamy (Nimbus / Status) to Everyone: 03:21 PM
I think the repo would be best under the https://github.com/eth2-clients umbrella
we’ve been working to revive the starter scripts in there
From danny to Everyone: 03:22 PM
From Preston - Prysmatic Labs to Everyone: 03:30 PM
link to the BLS library Justin mentioned?
From Mamy (Nimbus / Status) to Everyone: 03:32 PM
it’s not opensource yet
init/update/finish scheme for batch BLS operations: https://github.com/status-im/nim-blscurve/blob/master/blscurve/bls_signature_scheme.nim#L205-L248
and how to use it for various aggregation scheme is below
and this can be used for keys/messages streaming from the network
From Preston - Prysmatic Labs to Everyone: 03:32 PM
ah ok, wanted to try it early. any way to get private access?
From Mamy (Nimbus / Status) to Everyone: 03:35 PM
I’m not sure, we’ve only had discussions on our needs.
From Mamy (Nimbus / Status) to Everyone: 03:45 PM
https://api.prylabs.network/ <— I got .network from the blog post update
From danny to Everyone: 03:48 PM