We hope you're all keeping well. We're sorry it's been a while since our last update. Here are the main highlights since last time.
Core
- We're v0.12 spec compatible. In order to do this we've implemented conditional compilation. In plain english, this means we can toggle between v0.11.x and v0.12.x of the spec when compiling (allowing us to make progress with v0.12 without losing compatibility with existing testnets -- for example, Witti is still using v0.11).
- We've managed to speed-up block and attestation processing by about 10~50x. The main speed improvements have come from caching hash-tree-root (which allows us to get a unique hash of a merkle object, for example a Beacon Block or a Beacon State).
- We've implemented EIP2333:BLS12-381 Key Generation. This is an important step for cross-client compatibility, and part of the necessary work that needs to be done leading up to client standards. For more the significance of this EIP, see this excellent post by Carl from the EF.
In addition to the above, we're working on splitting the validator client into a front and a back end. The goal is to separate the needs of a validator client (which just needs to sign transactions) from all the processing under-the-hood required for the beacon node part.
This separation of concerns, is a design goal of the eth2 spec, and opens the door to all sorts of interesting innovations: for example it allows for things like the validator client from Teku communicating with an instance of the beacon node from Nimbus, running on a resource-restricted device.
The goal of this specification is to promote interoperability between beacon nodes and validator clients derived from different projects and to encourage innovation in validator client implementations, independently from beacon node development. For example, the validator client from Lighthouse could communicate with a running instance of the beacon node from Prysm, or a staking pool might create a decentrally managed validator client which utilizes the same API.
-- Ethereum 2.0 Phase 0 -- Beacon Node API for Validator
Security audit
In response to our RfP, we're happy to announce we've received proposals and are finalizing details to hopefully start by end of June. More will be shared soon.
Visualizations
We've made improvements to our beacon node visualization tools, specifically our Grafana monitoring dashboard.
Testnets
We've implemented a very basic mobile use case for the Witti testnet: you're now able to start Nimbus, have your device sleep for a night, and on wakeup it will resync!
This week the focus has very much been on debugging. While we've had active validators for almost 3 weeks now, attestations aren't being produced on time. We hope to fix this by next week.
Guides
We're started work on the nimbus beacon chain book. The goal is to cover all you need to know in order to start validating with the Nimbus client. It covers all the details for running a validator node on Witti from your computer.
We've also updated our guides that take you through how to install Nimbus on your android device. You should now be able to use them to connect to Witti.
Regressions on specific platforms
On Windows 32-bit and ARM 64-bit, our continuous integration is raising alerts (though we have reason to believe the ARM 64 issues are on Travis's side).
We hope that no one is using Windows 32-bit anymore and for ARM 64 (phones, Raspberry Pis), the bug is a corner case unlikely to be triggered.
Misc
libp2p: most of the recent work has been related to interop testing -- fixing gossipsub specific bugs, better resource management, better exception tracking, and adding metrics for pubsub (both, flood and gossip).
We've fixed a bunch of memory usage bugs and leaks (still lots to do).
That's all from us. Have a great weekend and 'til next time! 💛
