Menu
Article Update

Lighthouse Update #30

Adrian Manning

Adrian Manning

Category Update

Lighthouse v0.3.0

A lot of work over the past few months has culminated into a single release, Lighthouse v0.3.0.

This release brings a lot of breaking changes (which I will outline below) and importantly marks Lighthouse's final stretch to phase 0 mainnet. This release is the target of two concurrent audits, which will be the final (external) audits Lighthouse undertakes before getting the green light for the real deal.

Brief Summary

To summarise this update in dot-point form, the key improvements and developments since our last update are:

Zinken Testnet

The Zinken testnet's genesis state is known (the starting validators are all accounted for) and all clients agree on the state. This means we're ready for the testnet launch which should occur October 12th, 2020, 11:00 pm AEST. The timing of this testnet aligns perfectly to test out the last Lighthouse version with all its shiny new bells-and-whistles.

One issue that was raised in the last testnet, Spadina, was difficulty in finding and maintaining peers. There are a number of reasons for this. Firstly, the Spadina testnet was a small network (compared to its predecessor, Medalla) so to begin with there weren't as many peers to actually connect to. This is compounded by the fact that the DHT (big store of known peers) got combined with Medalla. This means when your client tries to find peers, it has to search through all the Medalla peers to try and find those on the Spadina testnet. This takes time to filter through a large number of non-relevant peers.

Finally, a large number of peers on the network are by default non-contactable. A non-contactable node occurs when a user is behind a home router and (typically) that router is not set up to allow incoming connections from miscellaneous peers on the internet. One must manually set up the home router to do this, and because it is not automatic, we expect there to not be a great deal of non-contactable nodes on Spadina. Lighthouse v0.3.0 introduces UPnP support, which (if a user's router permits) will automatically configure the router settings to allow incoming connections to Lighthouse nodes. We hope this should aid or greatly enhance the connectivity of the Zinken testnet, compared to the Spadina testnet. In either case, we'll find out very soon.

Remote BLS Signer

We have built an initial version of a remote BLS signer. The idea behind this added piece of software is to allow users to completely separate the key storage and signing of validator keys from the client software itself. As this software advances we expect to be able to support a range of hardware security modules (e.g. AWS Cloud HSM, supported hardware wallets, etc.).

Along with this implementation, we have submitted an EIP proposal, EIP 3030 in an attempt to standardise the HTTP API such that all clients and remote signers can be interoperable.

Lighthouse API Status

Throughout its development, Lighthouse has had a variety of accessible endpoints and supported a range of protocols. As these public facing connections will ultimately be what developers and users alike interface with, we (the Lighthouse team and the Eth2 community) have made significant efforts in standardising these endpoints and protocols across all clients. The set of standard protocols can be found here: Ethereum 2.0 Standard API

Lighthouse v0.3.0 marks the transition to using these standards and implements a majority of the endpoints. The final few endpoints should be completed by the next update.

Alongside these, we have additionally introduced a RESTful HTTP API to the Validator Client (VC) itself. The VC has always been designed to be a very lightweight and a minimal piece of Lighthouse as it holds and maintains access to the validator keys. Having the VC only perform the bare minimum of tasks (key signing and organising validator duties) helps in our security model of the system. We can focus on securing this minimal piece of software which is the only part of Lighthouse which directly deals with the private validator keys.

Adding a HTTP API to the VC increases the potential attack surface, however we feel it's well justified in the user experience it adds to using Lighthouse. The API enables our upcoming UI to interface with the validator client and perform various actions on behalf of the validators (such as voluntary exits).

This extra feature will also enhance our metrics to include validator specific data and provide extra information for developers about the current state of the running validators in Lighthouse.

Data Structure Update

Lighthouse previously had a single data structure which could be specified via the --datadir CLI parameter. This has caused a number of issues with users who use Lighthouse across multiple testnets. It was previously possible for users running a new testnet without setting a new datadir to have Lighthouse start in a conflicted state when reading the database of an older testnet. Solving this issue was the primary motivation for the directory restructure.

Lighthouse now separates testnets into their own sub-directories to avoid any conflicts. This is a breaking change however. Users who have synced a testnet previously should adjust the data directory to the new format. See the release notes for further instruction.

Slashing Protection Interchange

We have implemented the slashing protection interchange format. All validator clients in Lighthouse are protected from accidental slashing by a database which keeps track of the history of the validator's activity preventing any future messages from being signed if they could cause a slashable event.

If users wish to migrate their validators from Lighthouse to another client (or from another client to Lighthouse), it is important that this database migrates with them. Not doing so could leave their validators vulnerable to being slashed, which entails a loss of ETH and a forced exit from the validator pool.

The interchange format sets a standard allowing one client's slashing database to be imported to another's. For other clients that implement this standard, this allows a safe migration of validators from one client to another.

Audits

Lighthouse (and its constituent protocols) are undergoing their final round of audits.

Trail of Bits is completing its second part of our audit which is focussed on the networking components of Lighthouse. Trail of Bits previously reviewed the consensus components of Lighthouse and delayed this networking review until v0.3.0, now that we've stabilised all the networking stack.

In parallel, NCC has started their full audit of Lighthouse. They will be reviewing all the components from the networking layer, the cryptographic components and the consensus layer.

Least Authority has also undertaken a review of our rust-libp2p gossipsub protocol. This review has just concluded and no major findings were identified by the engagement team.

We should be able to report on all the findings from all our audits in the next update.

Looking Forward

The upcoming Zinken testnet should demonstrate the state of all the Eth2 clients and we imagine it to run without a hitch. For Lighthouse, as our audits are underway we will still be completing a variety of auxiliary features, such as working on the Lighthouse UI, completing the missing endpoints of the Eth2 API and integrating the latest discovery protocol (discv5.1).

Alongside the final features to be added to Lighthouse, we will be ramping up our internal testing. We will be spinning up number of internal testnets, performing various stress tests and attempting to simulate a variety of unique network conditions and attack scenarios.

Share