description: Notes from the regular Eth2 implementers call
# Eth2 Implementers’ Call #30 - 2019-12-19
[Quick contemporaneous notes by Ben Edgington]
## Testing and Release updates
v0.9.3 was released with substantive changes to state transition and networking. Adding an attestation subnet bitfield to the ENR was omitted. It's backward compatible, so v0.9.4 will be released today including it.
BLS standard to be released into `dev` very soon. To be merged first week of Jan.
Least Authority will be doing a comprehensive specification review, targetting v.0.10 early Jan.
Fork choice test still pending. Harmony team just [filed an issue](https://github.com/ethereum/eth2.0-spec-tests/issues/17) to propose a format. They also finished a beacon data processor. Handles delayed attestations. Could be useful for generating fork choice tests. Having integration tests is important.
Sigma Prime: Beacon fuzz is running at v0.9.1. Will upgrade to v0.9.3 or 4 when at least three teams have done so. There can now be multiple Python interpreters per process, allowing Trinity to be onboarded. Nimbus has been onboarded. Beacon Fuzz has identified its first crash! [Fuzzit](https://fuzzit.dev/) is a cloud-based fuzzing as a service platform - taking a look at it for long-term use. Also looking at _libprotobuf-mutator_ to allow protobufs to be mutated for fuzzing. Namespace clashes still an issue for onboarding clients - another person has been brought on to help with this.
Independently, Lighthouse has implemented an RPC fuzzer. Recommend teams do this for their clients.
Muskoka framework can deploy multiple clients. Not as fast as fuzzing, but gives wider coverage. The fuzz-failure mentioned above can be incorporated.
## Client updates
Working towards testnets. Merged attestation aggregation. Merged updates to PySSZ (hashroot calculation) - big speedup. Separating out validator client. Sync stability. Eth1 data component.
Minimal viable sync, good progress. Aim to join a testnet soon. Refactoring storage layer for reliability. P2P enhancements and continuing with discv5 integration.
Running mainnet config with 16k validators and a single beacon node. Required a lot of optimisation. Working towards a testnet reboot with v0.9.2. Redesigning some parts of the service. Stopping automatic propagation of pubsub messages. Fixing bugs.
Attestation aggregation is merged. Benchmarking tool similar to zcli. Working on how to manage a fleet of Nimbus nodes, reporting etc. Stack traces with lower overhead.
Pure Nim libp2p is now integrated. Next week's testnet will combine both old daemon and new native stacks. Only blocker to joining other testnets is discv5. Up to v0.9.3 spec.
Starting some Phase 2 work, such as EE development and Wasm generation.
Finalising v0.9.2 update. Working on SSZ caching - will help with prototyping light client servers. Will be upgrading libp2p soon and refactoring - will be able to implement validation of incoming messages.
Started 16k validator testnet in mainnet config with 4 beacon nodes. Lasted a week before a couple of beacon nodes got stuck in a loop and ran out of resources. Managed to recover, but the issue re-occurred. Have taken testnet down, will reboot with fixed bugs next week.
Lesson: storing state before blocks led to dangling pointers to blocks when client terminated. Now doing the reverse.
Blockexplorer is now supported.
Gossipsub is being merged into rust and naive aggregagtion is being implemented.
Continuing to test against Prysmatic testnet. Fixing syncing issues (it's slow). Getting into discovery protocol (Kademlia). Aim to join as many testnets as possible.
Still early. Working on validator, block creation. Next is peering. On spec v0.9.1 for most things. Various options for libp2p, but there is work needed on this front. May use Go daemon to start with. Rust library is another option.
Working on fork choice tests, [gossipsub simulations](https://hackmd.io/ZMBsjqdqSAK026iFFu_2JQ), and discv5 simulations. Filed some issues with naive attestation aggregation.
## Research Updates
The PegaSys Eth2 R&D team is re-forming to focus on Phase 1 and Phase 2 reasearch. It's a combination of the Artemis and Harmony teams. Name is "[TXRX](https://twitter.com/TXRXResearch)".
Main research areas are (1) short-term data availability. Need a STARK-friendly hash function to do this properly, but interim solutions exist. (2) How Eth transfers will work in Phase 2. Cross-shard messages are outside the base protocol, but Ether needs to be in-protocol. Could do an in-protocol, guaranteed cross-shard messaging, but this could be coupling things too tightly. Alternative is an Eth Execution Environment that all block producers understand. [Detailed description ensues...].
Phase 2 call coming mid-Jan. Will focus on cross-shards Txs, and the fee market.
Continuing to work on tooling for the contract EE. Planning to make EE tooling resemble Truffle. Releasing first chapter of Eth2 book in the next couple of weeks.
Different challenges compared with Eth1 (block producers have state) and Eth2 (block producers do not have state).
Will is focusing on top 4 Eth1 contracts and how they might be rewritten for Eth2, to guide Eth2 design, in particular cross-shard comms.
[Question (Vitalik)] Is anyone working on Eth1-Eth2 bridge? TXRX team plans to have Mikhail working on this.
Currently refining research plans. Planning a workshop around Stanford Blockchain Conference, focusing on Phase 2.
Planning [1-day event in Barcelona](https://ethbarcelona.github.io/), May 15, 2020. Would welcome Eth2.0 teams' participation.
Continuing to think about zero-knowledge proofs. Dan Boneh found an issue with the optimal SNARK construction described on last call. Trying to combine optimal prover and optimal verifier - so far this has not been possible.
## Highlights from Client Survey
Not yet processed. Initial impression is that Noise libp2p needs to be progressed.
Mostly [discussed yesterday](/@benjaminion/SJ3W0qwAH) on the Networking call.
## Spec discussion
[Proposal](https://github.com/ethereum/eth2.0-specs/issues/1537) to use timestamps rather than block depth when voting on the canonical Eth1 chain. This would improve cacheing, and simplify implementation. **Please review the issue asap**.
Waiting for Genesis complicates the implementation. "Running a node before it knows what the blockchain is". The Genesis event adds another (one-off) failure point. Would be easier if there were a script (EF to write?) that produces the genesis state that all clients can use, moving Genesis handling outside the beacon node. This is equivalent to starting the node from a known, trusted state, which clients already do. Clients could still use the current flow as an alternative if they don't like this. **Paul Hauner to create an issue for comments**.
## Open discussion
Next call probably 9th Jan.
* * *
# Chat highlights
From danny to Everyone: 02:03 PM
From Mikhail Kalinin to Everyone: 02:05 PM
From trentonvanepps to Everyone: 02:37 PM
From Mikhail Kalinin to Everyone: 02:39 PM
: yes, https://twitter.com/TXRXResearch
From Leo BSC to Everyone: 02:53 PM
From danny to Everyone: 03:01 PM