We hope you’re all managing to stay sane and safe. Here’s a quick update from us.
April milestones
Our main goals this month are the following:
Implement specification v0.11.1
Our main focus this month is implementing specification v0.11.1 in order to be ready for the multi-client testnet (later this month?).
v0.11.1 is an especially important release, since it serves as the multi-client testnet target. In other words, it’s essential that all clients are running software consistent with this version of the specification for a full interop to happen.
The spec changes (between v0.11.0 and v0.11.1) are mostly networking related (consensus hasn’t changed), so we’re pretty close to being up to speed.
Mainnet testnet configuration
As it stands, we don’t currently have a testnet with mainnet parameters: a mainnet configuration requires many more validators, larger committees, and four times more slots per epoch (32 vs 8 in our current testnet).
Since we can only debug at epoch boundaries, testing with a mainnet config means we have to wait longer to debug issues (this is the main reason we haven’t released one yet).
Naturally, there are a certain bugs that can only be found by running a testnet with a mainnet config. With multi-client testnets fast approaching, this is one of our key priorities.
Node discovery improvements
We continue making improvements to Discovery v5.
This includes adding features like ENR updates to ensure we’re compatible with v0.11.1
It also involves introducing more tests, and improvements + bug fixes that are important for the general functioning of the protocol. While we won’t enumerate them here, see this issue for a complete list.
Benchmarks
We’d like to have some benchmarks in place with respect to staking, signing and validating on a phone.
This would give us a good indication of how close we are to achieving our mission of performing well on resource-restricted devices and provide a general indication of ethereum’s ability to scale.
Technical debt repayments
Audit time is coming up fast. Over the last few months, it’s clear we’ve lost some time due to moving fast on some components and not keeping the quality at a good level. Once we audit, it will be harder to make code changes, so it’s important we pay off our technical debt now.
As part of this, we plan to improve the test suites covering block, validator and attestation pools so that when we refactor we can be sure we’re not introducing any regressions.
Stretch goals
You can find our stretch goals here. Let’s go through a couple that are worth elaborating on:
Bootstrapping documentation and streamlining
As it stands, starting a node is quite a messy experience. In order to start discovering peers, you need to either hardcode the IP of a fixed node, or use ENR to connect with a trusted peer. You also need an eth1 bridge to make sure you’re listening to the eth1 deposit contract.
It’s not really clear to outsiders how all of this works. So we need a document that explains all this machinery and a script that makes it easy to do.
This is directly relevant to another of our stretch goals: to publish a guide on writing a custom testnet preset (a community request for all clients).
Per-topic log levels
Right now we have multiple services in Nim beacon chain, all producing logs.
It would be useful to be able to set (and subscribe to) log levels on a per-topic basis, in order to:
- Save money: we have a fixed AWS budget and logs consume a not insignificant percentage of it.
- Make debugging easier: by for example being able to set trace (verbose) levels on libp2p logs.
We imagine the levels looking something like this:
type LogLevel = enum
NONE, TRACE, DEBUG, INFO, NOTICE, WARN, ERROR, FATAL
For more, see here.
Some highlights since last time
- Fixed a big memory leak in nim-libp2p.
- Implemented snappy– a fast compression/decompression library – support for gossipsub.
- Reduced the length of our trace logs, which has allowed our testnet1 to finalise.
- Fork choice rule rewrite: it’s now optimized, tested, and handles corner cases correctly.
- A script to start both Lighthouse and Nim beacon chain with the same configuration – although there are a couple of bugs left to iron out we feel like we’re pretty close to a successful interop.
We hope you found this update informative :) We’ll be posting another in a couple weeks time. Until then, you can keep track of our progress here. 💛
