Skip to content

Time Bird
Compare
Choose a tag to compare
@github-actions github-actions released this 25 Jan 02:13
· 352 commits to stable since this release
v4.6.0
This tag was signed with the committer’s verified signature.
paulhauner Paul Hauner
GPG key ID: C850DDDF5D100807
Learn about vigilant mode.
1be5253
This commit was created on github.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

Summary

This medium-priority release provides valuable features, performance improvements and bug fixes for mainnet users. It also enables the Deneb upgrade on the Sepolia, Holesky and Chiado testnets.

The Deneb upgrades are scheduled for:

  • Sepolia: Jan 30 2024 @ 22:51:12 (GMT+0)
  • Chiado: Jan 31 2024 @ 18:15:40 (GMT+0)
  • Holesky: Feb 7 2024 @ 11:34:24 (GMT+0)

All Sepolia, Holesky and Chiado users must upgrade both their testnet VCs and BNs before the respective upgrade time. Failing to upgrade will require the user to manually resync their nodes.

This release also includes a variety of new features and a few breaking changes. Please see the section on Breaking Changes below.

Users who rely exclusively on builder blocks (e.g., RocketPool) should be sure to read the "Standard block V3 endpoint" section.

Standard block V3 endpoint

The new produce block V3 API has been standardized across clients (ethereum/beacon-APIs#339). This endpoint allows us to give validators more control over whether to prefer a local or builder payload during proposals. The validator client will not use this new endpoint by default; it must be enabled by adding --produce-block-v3 to the validator client. This mode will be enabled by default in the future. With the advent of V3, the following BN flags will no longer be supported:

  • --builder-profit-threshold
  • --always-prefer-builder-payload

Please refer to the Breaking Changes section below for detailed information and necessary actions.

Per-validator configuration of whether to use an external builder is still possible via the builder_proposals field. This has been extended to allow each validator to specify one of the following:

  • builder_boost_factor: a percentage multiplier to apply to the builder's payload value when choosing between a builder proposal and a local proposal.
  • prefer_builder_proposals: a boolean flag to indicate preference for blocks constructed by builders, regardless of payload value.

The block V3 endpoint also allows validators working with multiple beacon nodes (e.g. via Vouch) to compare rewards between beacon nodes before selecting payloads. This is done by exposing the consensus rewards of the block, as well as the execution rewards of the payload directly to the validator.

On the block V2 endpoints, if a validator is using the blinded block flow and gets exceptionally unlucky, falling back to another beacon node at an inopportune time, it could miss its proposal. This is no longer possible with the V3 endpoint.

NOTE: If you are using --builder-proposals you must also set --builder-boost-factor 100 to work around a bug, see below.

Known Issues 🐞

There is a bug in the validator client flag --builder-proposals which causes the VC not to use builder proposals when the following conditions are met:

  • The flag --builder-proposals is set, and
  • The --produce-block-v3 flag is set, and
  • No other flags or configuration affecting the builder-boost-factor are set, e.g. --builder-boost-factor, --prefer-builder-proposals, or per-validator builder_boost_factor.

The bug has been identified and fixed in this PR which will part of our next release: #5151.

Until then, the workaround is to add --builder-boost-factor 100 to the validator client flags. The 100% setting is the intended default, and will cause Lighthouse to use the builder payload only when it is more profitable than a local payload. You may also set a different value (see Breaking Changes for more information on this flag).

Execution layer payload selection input

Recent changes in the execution APIs have also provided a new should_override_builder field along with each local payload. Lighthouse will check if this is set to true and return a local payload if it is. This field allows the execution layer to monitor the mempool and look for signs of ongoing censorship from block builders. It can signal its suggestion to use a local payload to combat censorship to the consensus layer to select a local payload in these scenarios.

Validator broadcast

Validator clients can now be configured to publish messages to all connected beacon nodes using the --broadcast flag. This allows users to improve redundancy when publishing messages related to validator duties. The flag can be configured with specific message types (attestations,sync-committee,blocks, subscriptions). It can also be configured to make sure subscriptions are not sent to all beacon nodes (--broadcast none). This replaces the now deprecated --disable-run-on-all flag. Thanks @uvizhe for the contribution!

More information is available in the Redundancy section of the Lighthouse book.

(see #4920)

Networking Improvements

Some extensive changes have been made to the networking components in this release. We have focused on a number of performance and structural changes to the gossipsub protocol and discovery mechanism. Some of the main gossipsub changes are listed in issue (#4918). An overview of the primary changes are:

  • Removed gossipsub flood publishing (#4383) - Aimed to reduce message propagation latency and lighten the memory footprint
  • Upgraded libp2p to v0.53.* (#4935)
  • Enabled concurrent discovery RPC requests
  • Improved handling of slow peers at the gossipsub level
  • Handled memory allocations in message transmission in gossipsub
  • Improved prioritisation of messages in gossipsub

Standard Liveness Endpoint

The validator client now uses the standard liveness endpoint for doppelganger protection (see #4853). This makes the Lighthouse VC's doppelganger protection compatible with any beacon node that implements the standard liveness endpoint.

Major Changes

  • Deneb support, enabled on Sepolia, Holesky and Chiado (#5089)
  • Deneb support, enabled on Goerli (#5036)
  • Fix an OOM crash caused by a build-up of messages in gossipsub send queues (#4918)
  • Changes to builder vs local block preference flags (#4629, #5086)
  • Fixes an issue with blob storage after checkpoint sync (#5119)
  • Prevent database corruption that could occur while shutting down (#5084)
  • Other networking improvements (libp2p upgrade, disable flood publishing)
  • Checkpoint sync required by default (#5038)
  • New HTTP APIs
  • Database fixes for Holesky nodes (#4820, #4985)
  • Faster fork choice by default (#4971)
  • Faster block production, decreasing the chance of being reorged (#4925)
  • Validator client broadcast feature (#4920, https://lighthouse-book.sigmaprime.io/redundancy.html#broadcast-modes)
  • More efficient subscriptions in the validator client, which reduces load on machines with large numbers of validators (#4806)
  • Attestation simulator (#4880)
  • Missed block tracking (#4731)
  • Command to prune states from the database (#4835)
  • Fixes to rewards APIs (#4807, #4877)

New HTTP APIs

The Lighthouse BN supports the following new HTTP APIs:

⚠️ Breaking Changes ⚠️

VC and BN Compatibility

The Lighthouse VC now uses the liveness endpoint from the standard API, rather than a custom Lightouse endpoint (#4853). This only affects the --enable-doppelganger-protection feature.

When Doppelganger protection is enabled, Lighthouse VCs from this version will not work with Lighthouse BNs prior to v4.4.1 (released Sept. 2023).

Database Migration v19

To support Deneb, this release includes an automatic upgrade from v17 to v19.

Some Goerli users might notice a delay of one or two minutes when starting up for the first time after the upgrade. Lighthouse is correcting a issue with blob storage after checkpoint sync, no user intervention is required (see: #5119).

To downgrade, follow the instructions in the book for Database Migrations.

Checkpoint sync is required by default

Genesis sync will no longer work without the use of --allow-insecure-genesis-sync. Checkpoint sync should always be preferred to protect yourself from long-range attacks. Additionally, genesis sync is not compatible with data availability checks that are added in Deneb. On chains that have been running for less than ~2 weeks, genesis sync will still work without --allow-insecure-genesis-sync, so this change won't impact local testnets or short-lived testnets.

Removed flags

The following flags have been deprecated in prior releases and are being removed. Lighthouse will not start up if any are included in the startup command.

  • --spec for lighthouse bn
  • --eth1-endpoint for lighthouse bn
  • --eth1-endpoints for lighthouse bn
  • --beacon-node for lighthouse vc
  • --server for lighthouse vc
  • --delete-lockfiles for lighthouse vc
  • --allow-unsynced for lighthouse vc
  • --strict-fee-recipient for lighthouse vc
  • --merge for lighthouse bn
  • --count-unrealized for lighthouse bn
  • --count-unrealized-full for lighthouse bn
  • --http-disable-legacy-spec for lighthouse bn
  • --minify for lighthouse account validator slashing-protection import/export

(see #4906)

Deprecated flags

The following flags should be removed from setups. If they are not removed, they will have no effect.

Deprecated: --builder-profit-threshold BN flag

Prefer using the -min-bid flag in mev-boost. Alternatively, the new --builder-boost-factor VC flag can be used to achieve a similar effect using a percentage multiplier (see #5086). For example, using --builder-boost-factor 120 increases a builder proposal's value by 20% for comparison, effectively making it 120% of its actual value and thereby favoring it over a local payload by this margin. Alternatively, to prefer local payloads, set a value lower than 100. For example --builder-boost-factor 50 will only use the builder payload if it is 2x more profitable than the local payload. To use builder boost flag, --produce-block-v3 must also be enabled.

Deprecated: --always-prefer-builder-payload BN flag

Use the new and equivalent --prefer-builder-proposals VC flag to restore this functionality (see #5086). You must also use the --produce-block-v3 flag.

Deprecated: --disable-run-on-all VC flag

This flag has been superseded by the --broadcast flag. Use --broadcast none to disable broadcast to all nodes (see #4920).

Rust MSRV

The minimum supported Rust version has been updated from 1.69.0 to 1.73.0

Users who compile from source (i.e., not Docker or pre-built binary users) will receive the following error if they are using an earlier version of Rust:

lighthouse v4.6.0 (/home/sigp/lighthouse/lighthouse)` cannot be built because it requires rustc 1.73.0 or newer

Users can typically obtain the latest version of Rust by running rustup update.

Update Priority

This table provides priorities for which classes of users should update particular components.

User Class Beacon Node Validator Client
Staking Users Medium Medium
Non-Staking Users Medium ---

See Update Priorities more information about this table.

The Beacon Node must be running v4.4.1 or later to support a VC running this release. We recommend updating both the VC and BN to the same release.

This release is high-priority for Sepolia, Holesky and Chiado users. Those users must update both the VC and BN.

All Changes

A full list of changes can be viewed at: v4.5.0...v4.6.0.

Binaries

See pre-built binaries documentation.

The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0

System Architecture Binary PGP Signature
x86_64 lighthouse-v4.6.0-x86_64-apple-darwin.tar.gz PGP Signature
x86_64 lighthouse-v4.6.0-x86_64-apple-darwin-portable.tar.gz PGP Signature
x86_64 lighthouse-v4.6.0-x86_64-unknown-linux-gnu.tar.gz PGP Signature
x86_64 lighthouse-v4.6.0-x86_64-unknown-linux-gnu-portable.tar.gz PGP Signature
aarch64 lighthouse-v4.6.0-aarch64-unknown-linux-gnu.tar.gz PGP Signature
aarch64 lighthouse-v4.6.0-aarch64-unknown-linux-gnu-portable.tar.gz PGP Signature
x86_64 lighthouse-v4.6.0-x86_64-windows.tar.gz PGP Signature
x86_64 lighthouse-v4.6.0-x86_64-windows-portable.tar.gz PGP Signature
System Option - Resource
Docker v4.6.0 sigp/lighthouse

Contributors

uvizhe
Assets 18
Loading