Menu
Article Update

Lighthouse Update #37

Adrian Manning
Paul Hauner
Michael Sproul

Adrian Manning Paul Hauner Michael Sproul

Category Update

Altair hard-fork testnets, upcoming v1.5.0 release.

TL;DR

  • v1.5.0 is planned for pre-release in early August and will include Altair testnet support.
  • The team has been focussed on Altair development and mutli-client testnet participation.
  • Lighthouse users must ensure their Eth1 node is updated before the London fork on August 4th.

Lighthouse v1.5.0

Update #36 outlined a feature-set for the v1.4.0 release. This release was delivered earlier than expected on June 10th, but with a reduced feature-set. Specifically, the following features were omitted from v1.4.0 and delayed for a v1.5.0 release:

  • Altair Support
  • Doppelganger Protection
  • Remote Signing Support for the VC

Since releasing v1.4.0, the team has been focussing heavily on Altair, Doppelganger support and overhauling portions of the Lighthouse networking stack. Since these works have involved extensive changes to critical code, laborious testing and review was required. To ensure quality is maintained, the team has made the decision to delay remote signer support to the next release. Full remote signing support remains high-priority, however it is blocked on Doppelganger protection for the time being.

For the coming weeks, the team is focussing on nailing a v1.5.0 release in August. Expect to see a pre-release in early-August and a production-ready release sometime after that.

In the v1.5.0 release, users can expect to see:

  • Full Altair testnet support.
  • Improvements in peer management and removal of common WARN messages.
  • Doppelganger protection (for the time being, this feature will be off-by-default).
  • Ability to enable/disable validators via the CLI (#2386)
  • Addition of the reorg server-sent-event to the HTTP API (#2090)
  • Ability to compile on latest version of Rust (#2411)
  • Faster slashing protection history imports (#2030)
  • Addition of the Lighthouse version string to Prometheus metrics (#2427)
  • Faster state lookups via the HTTP API (#2422)
  • Better handling of request time-outs from the VC to the BN (#2352)
  • Faster hashing by utilizing x86_64 SHA extensions (where available) (#2426)
  • Caching and re-processing of attestations for unknown blocks (#2319)
  • Support for the VC HTTP API to listen on 0.0.0.0 (#2467)

Follow progress towards the release with the v1.5.0 tag.

The Altair Upgrade

Altair is the first planned upgrade (hard-fork) for the Beacon Chain. As discussed previously, we've been working hard to implement all the features and changes required to support it. Alongside our internal testing and review works, we've been participating in the multi-client Altair testnets organised by @paritosh from the Ethereum Foundation.

The multi-client testnets have been generally successful so far, albeit with a few hiccups during the transition period. Lighthouse has fared well in these testnets, with no consensus-faults or liveness-failures on our behalf.

We expect to see one more short-lived Altair testnet before increasing the stakes by upgrading Pyrmont or Prater.

We will announce here when more concrete plans emerge for upgrading mainnet.

Networking

Alongside upgrading our networking protocols to be Altair-compliant, we've stepped up our security testing to test resilience in live networks against sophisticated malicious actors.

The result has lead to some significant changes in the structure of our networking stack as well as additions and modifications to the lower level networking protocols such as discv5 and gossipsub. The result is a more streamlined, robust and secure Lighthouse.

In addition to this, we've noticed changes in how the network is behaving at the gossipsub level. In particular, Lighthouse has been penalizing peers who do not fit within the criteria we've set for how a node should behave in an eth2 network. As a result, we've modified some scoring parameters to be more lenient to these behaviours and adjusted settings to make Lighthouse more efficient with respect to the gossipsub layer. Additionally we're in the process of enhancing metrics and re-designing some scoring parameters to give us more insight to how the network is behaving so that we can continue to improve these parameters.

Weak Subjectivity Sync

Weak subjectivity sync is a process whereby a client chooses a recent finalized checkpoint and simply syncs blocks from that point forward. The idea is that a client no longer needs the entire beacon chain history before it can follow the head of the chain; it can just sync the blocks between the finalized checkpoint and the head. This allows users to sync a staking-ready node from scratch in a matter of minutes whilst historic blocks are downloaded in the background.

Since we already have a robust syncing mechanism and have been focusing on more pressing upgrades to the Lighthouse code-base, we haven't prioritised this feature. However, with the Altair updates completed, we're working on completing this sync method and making it available to Lighthouse users in the near future. In the optimistic case, Lighthouse will support this feature in the release after v1.5.0.

London Upgrade

On August 4th UTC the London hard fork will activate on Ethereum mainnet.

You must update your Eth1 node before this date in order for it to continue following the chain. If your Eth1 node is not updated then your Eth2 node will lose the ability to propose blocks on the beacon chain.

Even if you have updated your client recently, please double check as new releases have just been made to address a consensus bug that appeared on the Ropsten testnet. Geth version v1.10.5 is not sufficient, you need v1.10.6 (released the same day as this blog post). A full list of supported clients is as follows:

  • Geth v1.10.6: https://github.com/ethereum/go-ethereum/releases/tag/v1.10.6
  • Besu 21.7.1: https://github.com/hyperledger/besu/releases/tag/21.7.1
  • Nethermind 1.10.79: https://github.com/NethermindEth/nethermind/releases/tag/1.10.79 Erigon
  • 2021.07.04-alpha: https://github.com/ledgerwatch/erigon/releases/tag/v2021.07.04 OpenEthereum
  • v3.3.0-rc.4: https://github.com/openethereum/openethereum/releases/tag/v3.3.0-rc.4

A detailed retrospective on the Ropsten bug can be found here: https://notes.ethereum.org/@timbeiko/ropsten-postmortem

No change is required on Lighthouse's side to support London, Lighthouse v1.4.0 is tested and working with London as deployed on Goerli.

If you need help updating your Eth1 node please reach out in the #general channel of our Discord.

Share