Devcon5 presentations, Eth1 integration, BLS updates, Multi-client testnet preparation

Summary

Sigma Prime was at Devcon5! Eight of our team members were in Osaka, some for their first Devcon and others for their first time in Japan. Everyone learned a lot at the conference and had a great time in the Land of the Rising Sun. This Wednesday, we are hosting the monthly ETHSydney meetup at our office as a Devcon5 debrief where we will speak about what we found interesting. If you're in Sydney, come along to hear about ours and the community's highlights from Devcon5, and to get an update on the progress of Lighthouse.

Since Devcon5, we've been hard at work on the following topics:

• Eth1 integration
• Discovery v5 Standardisation
• Validator Slashing Protection
• Swap-or-not-shuffle Formal Model in Isabelle
• Merging Beacon Node and Validator Client Binaries
• BLS Update
• Testing Update
• Tightening Key File Permissions

Devcon5 Presentations

Optimising Eth2

During the eth2 client summit, Michael gave a presentation titled "Optimising eth2", during which he described some of the optimisation work undertaken by the Lighthouse development team. As you may know, the eth2 specification is optimised for readability. This means that a naive implementation of the specification would result in a slow and inefficient beacon node, potentially preventing all incoming blocks, attestations, and other network-level messages from being processed within the 6-second slot time. As a result, implementers are required to optimise the specification without affecting the correctness of the state-transition functions.

Michael gave three examples of optimisations implemented in Lighthouse:

• Caching the committee for the relevant epochs, instead of computing it every slot;
• Using protolambda's optimisation for the shuffling function;
• Pre-computing attestation information and re-using it throughout the epoch state transition functions.

The first of these optimisations actually led the development team to identify a bug in the eth2 specification, which was fixed by the research team in v0.8.2 .

We were happy to hear that this talk inspired Prysmatic labs to implement some of these optimisations!

If you missed Michael's talk, worry not, the recording and slides are available here.

Security Considerations for Eth2

Paul and Adrian gave a talk titled "Ethereum 2.0 Security Considerations", which provided an overview of the security concepts and principles for eth2. The topics covered during this presentation are:

• Validator failure mode
• Beacon node attack surface
• Validator privacy
• Differential fuzzing

The objective of this talk was to provide information security professionals with an introduction to eth2, highlighting the risks (overall attack surface), the approach followed by the various engineering teams involved in eth2, along with an overview of the software components leveraged for the Phase 0 Beacon Chain. Adrian closed the presentation by explaining how Sigma Prime is currently implementing a differential fuzzer, which can help detect any deviation/differences between the outputs produced by each implementation.

During the last eth2 implementers call, Mehdi provided an update on the work conducted by Sigma Prime for an eth2 differential fuzzer, named beacon-fuzz. More details about this project can be found on the following repositories:

• https://github.com/sigp/beacon-fuzz
• https://github.com/sigp/beacon-fuzz-corpora

Eth1 Integration

Paul is getting very close to having the eth1 integration ready for review and merge. Beacon nodes must connect to an eth1.x node to retrieve the following information:

• Logs emitted by the deposit contract;
• Appropriate Eth1Data information, which includes the deposit root (get_deposit_root()), the deposit count (get_deposit_count()), and the relevant block hash);

For performance optimisation purposes, we're implementing simple caching Eth1Data that will allow Lighthouse to detect the eth2 genesis and then produce blocks accordingly in a timely fashion.

Once this PR is merged into our master branch, Lighthouse will be considered feature complete for Mainnet launch.

In the process of testing the deposit contract, we have identified a mismatch between the Prysm Sapphire testnet and the specification which was raised in this issue

Discovery v5 Standardisation

Devcon5 was also a great opportunity for us to work with other teams and individuals involved in eth2 research and development. Specifically, an ad-hoc meeting was organised between teams interested in discussing the new discovery protocol, discv5, which is specified here. The meeting primarily discussed implementation challenges, design choices and future work in getting discv5 ready for mainnet.

Adrian has also managed to achieve interoperability between the Rust and Go discv5 implementations. By connecting the two implementations and debugging them both, he identified several discrepancies between our Rust implementation, the Go (reference) implementation, and the specification. This process led to multiple edits, including updates to Go implementation, the Rust implementation and the specification.

As such, and as mentioned by Felix during the eth2 implementers call, the Rust and Go versions are "100% compliant with the Discv5 specification"!

During the meeting at Devcon5, topic discovery was discussed extensively. Topics allow nodes to be identified by their capabilities, which is particularly useful for eth2 so that a Beacon node needing to sync a specific shard can attempt to find a peer (another Beacon node) which has an up-to-date state for that shard. While the specification for topic discovery is yet to be finalised, we do have a PR that adds this feature to our rust-libp2p stack.

Additionally, we have spent significant time helping other clients achieve interoperability with the Go and Rust implementations of discv5 by producing a new comprehensive list of test vectors that can be found here. While this is not something that our client immediately needs (as it's currently conformant with the specification), we think that it will be very helpful to other implementers when they ensure their client can interoperate correctly at the networking layer.

Validator Client Slashing Protection

A validator client should ensure that a slashable message is never signed. Specifically, a validator client must never sign a slashable attestation or a slashable block proposal:

• A validator client must never sign two different blocks during the same epoch (protection from proposer_slashings)
• A validator client must never sign a surround vote (protection from attestation_slashings)
• A validator client must never sign a double vote (protection from attestation_slashings)

Scott has been hard at work defining the logic to enforce these checks, and has also implemented two proof-of-concepts in Rust and Python. His suggested solution requires the validator client to store validator-specific information (two structs: ValidatorHistoricalBlock & ValidatorHistoricalAttestation). Given the assumption that there will be 82,125 epochs in a year, the total information stored for each validator would only grow by ~6.89 MB per year at most.

Scott has also formalised the algorithm used for the validator client slashing protection in this document, in an attempt to prove its correctness.

After further testing, this important security feature will be incorporated into Lighthouse's validator client.

Swap-or-not Shuffle Formal Modelling

The eth2 specification defines the compute_shuffled_index function which is used to shuffle the validators into committees. This function leverages the swap-or-not shuffling algorithm described in detail by this paper. This algorithm, if implemented naively, takes a long time to process large validator sets. A few months ago, @protolambda described an optimised algorithm for the swap-or-not shuffling method. Since then, all clients (Lighthouse included) have implemented this optimisation for their shuffling functions.

Michael's background in formal verification leads him to write mathematical proofs for miscellaneous algorithms. After Devcon5, Michael felt inspired and wrote a formal model of the swap-or-not shuffling algorithm using Isabelle, an automated, interactive, higher order logic theorem prover. This work proves that under some mild assumptions about the input list, the swap-or-not shuffle does indeed yield a valid permutation.

This is the first step in formally proving the equivalence between protolambda's optimised algorithm and the official shuffling method as defined by the eth2 specification.

Miscellaneous

Merging Beacon Node and Validator Client Binaries

To simplify user experience, large scale testing, and multi-client testnet onboarding, we have merged the validator client and the beacon node into one single binary (this has been done in the eth1 branch on our Lighthouse repository). In addition to being more user-friendly (less binaries = less confusion for end users), this approach has the advantage of reducing the combined, total binary size (compared to the size of the validator client binary + the beacon node binary).

To run Lighthouse as a beacon node:

$ ./lighthouse beacon

To run Lighthouse as a validator client:

$ ./lighthouse validator

Testing Update

We have added a significant number of unit tests to our repository (see PR #559). These additional tests target the Lighthouse Beacon block processing function, and allow us to test multiple edge cases and invalid state transitions (e.g. inserting blocks with invalid deposit_counts, invalid merkle proofs, incorrect signatures, etc.).

Furthermore, we have now integrated the Ethereum Foundation's test vectors into our CI. Every time our CI is triggered (i.e. every time a PR is submitted), the EF test vectors are processed in addition to our own unit tests.

BLS Update

Recently, a new BLS threshold signature library has caught the eye of various eth2 researchers and implementers. This library can be found here and is named after its author, herumi. While the core components are written in C++ and C#, this library uses a custom JIT assembler to provide optimised assembly instructions.

Kirk spent some time benchmarking this library and it appears to be the fastest available BLS library which is compatible with the eth2 requirements:

• 0.3 ms for signing
• 1.1 ms for signature verification

As a comparison, the library we're currently using (Apache Milagro) has the following performances:

• 1.0 ms for signing
• 2.6 ms for signature verification

These numbers show a 2.4x speedup for signature verification (which is by far the most frequent BLS operation in eth2). We're very excited about this work and we will certainly consider integrating herumi into Lighthouse if the author of the library provides bindings for Rust in the near future.

Security

• While working on the eth1 integration (see the Eth1 Integration section of this post), Paul identified a new attack vector that could allow a malicious actor to manipulate the deposit contract to gain an early majority (controlling at least 50% of the validators in either the first of second epochs after genesis). This concern has been raised with the research team in this issue and was fixed in the latest release of the specification (v0.9.0)
• While reviewing our code base for security issues, we've noticed that the account manager stored private keys with unnecessary, extensive file permissions (-rw-r--r--). This has now been fixed (see PR #551): the permissions on private key files are now -rw------- (or 0600 in permission bits).
• We have extended the Lighthouse security RfP by 10 days to allow more vendors to submit a bid.
• Our MolochDAO grant proposal has been submitted by Mariano Conti, MakerDAO developer and member of Moloch. You can track its progress here. Many thanks to Mariano for championing our Moloch grant request and to all the Molochians who supported our request.

Next Steps

We are currently working on finalising the eth1 integration, polishing our CLI, updating our tree hash caching, upgrading to the latest version of the eth2 specification, updating our syncing strategy and integrating the latest networking developments into Lighthouse.

A public multi-client testnet seems very close - stay tuned for exciting announcements!