Key Management Implementation
An important part of the user experience in Blockchain staking relates to managing cryptographic keys. In Eth2, validators have to deal with two separate BLS keys:
- Signing keys: Hot keys, used by validators to sign consensus-level messages and objects such as blocks, attestations, exits, etc.
- Withdrawal keys: This type of key is not actively used by validators and is needed for accessing the validator's ETH after successfully going through the withdrawal/exit process (available in Phase 1).
Paul has been busy implementing the following EIPs for Lighthouse:
- EIP-2333: Key derivation/generation
- EIP-2335: BLS Keystore
- EIP-2386 (draft): BLS Wallet
This will allow our users to generate BLS wallets that can be fully backed up and restored using 12-word strings (a.k.a mnemonics, following the BIP39 standard relying on a 2048 English-language wordlist).
Lighthouse uses a hierarchical key management system for producing validator keys. It is hierarchical because each validator key can be derived from a master key, making the validators keys children of the master key.
Pratically, users will follow these steps to create a single validator:
-
Create a wallet and record the mnemonic:
lighthouse account wallet new --name mywallet --wallet-password mywallet.pass -
Create the voting and withdrawal keystores for one validator:
lighthouse account wallet validator --name mywallet --wallet-password mywallet.pass --count 1
This is very similar to ethdo, a utility built by Jim McDonald in Golang and used within the Prysm client. In fact, we're ensuring full compatibility, meaning that swaping from a client to another will be as easy as copying the wallet (JSON file) or recovering it using the mnemonic.
Schlesi: The First Multiclient Testnet
Since our last update, Afri has been busy putting together Schlesi, the first multiclient testnet for Eth2. This is a huge achievement as it has the potential of becoming The official multiclient testnet, though we should expect frequent testnet reboots over the next couple of days, particularly with the upcoming new Eth2 spec breaking release (v0.12). You can keep an eye on the testnet using the following resources:
This testnet has been bootstraped using Lighthouse and Prysm Beacon Nodes and Validator Clients, with Nimbus and Teku recently joining the party. Lodestar is also successfully syncing Schlesi!
Lighthouse is now configured to connect to Schlesi by default, with the related spec and genesis state baked into our binary. If you want to run a Lighthouse validator on Schlesi, follow the steps outlined in the Lighthouse book.
If you just want to sync the Schlesi chain (i.e. only running a Beacon Node that's not actively participating to the consensus), simply run the following command:
lighthouse bn
Your beacon node should start finding peers and sync its way up to the head of the chain! Please feel free to join our Discord to let us know if you're experiencing any issues.
External Security Review
We're very excited to kick off our first external security assessment with Trail of Bits on May 18th. This is a major milestone for Lighthouse and the first external security audit of an Eth2 client. While we've been taking security extremely seriously throughout the entire development process (extensive fuzzing, internal code reviews, etc.), this first review will be a great opportunity for a reputable independent security firm to take a close look at an Eth2 implementation.
Two security assessors will be diving into our codebase, primarily focussing on the following components:
- State transitions (block processing, attestation processing, etc.)
- Key management
- Slashing protection
- Shuffling algorithm
- Caches in
BeaconChain - Operation pool
- SSZ decoding
- Validator client
- Fork choice
A second review targeting our networking stack (and the changes introduced after this first review) will be scheduled closer to mainnet.
We'd like to thank MolochDAO for helping us partly fund the cost of this assessment!
Additional achievements
Memory footprint
As mentioned in previous updates, the development team has been spending a considerable amount of time optimising Lighthouse in order to minimise our CPU, memory and storage footprints. We're happy to report that we're observing on our local 16k validator testnets nodes using as little as 300MB of memory! These nodes run a beacon node and a validator client with 2,000 validators!
This efficiency gain has a direct impact on the ROI for stakers, particularly for those who will be using cloud-based infrastructure to host their Lighthouse nodes.
Slashing protection
Michael has been busy implementing slashing protection for our validator client, addressing challenges around concurrency safety and atomicity guarantees of database transactions (SQLite). This PR will be merged soon and will prevent users running our validator client from producing slashable messages (double votes and erroneous block proposals).
Consensus bugs
We've been lucky to have Justin Drake dedicate some of his time to review some parts of our codebase, focussing on the consensus-critical portions. In his adventures, he identified two critical bugs both related to the parallelization of our state transition code (see issues #1065 and #1090 for detailed information). These bugs have been fixed by removing parallelism from our state transition functions, which was introduced as an optimisation before our ability to perform batch BLS verification.
Stable Futures and Dependency Upgrades
Adrian and Pawan have been upgrading our codebase to use the latest stable futures, giving us access to the latest version of tokio which handles long-running concurrent tasks much more efficiently and elegantly.
We have also upgraded all the external crates used within Lighthouse to their latest versions.
Discv5
We have moved our discv5 crate to its own dedicated repository:
As mentioned by Felix in the latest Eth2 implementers call, we're expecting more changes to be introduced to the discv5 specification (mostly hardening against potential DoS attack vectors).
BLS Update
The latest spec (v0.12) will introduce substantial breaking changes to the BLS cryptographic primitives used in Eth2. While this new version of the spec is yet to be released, Kirk has already upgraded our BLS library to reflect these changes!