Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lighthouse 4.6.0 #161115

Merged
merged 2 commits into from
Jan 28, 2024
Merged

lighthouse 4.6.0 #161115

merged 2 commits into from
Jan 28, 2024

Conversation

chenrui333
Copy link
Member

Created by brew bump


Created with brew bump-formula-pr.

release notes
## 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.

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 sigp/lighthouse#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 (sigp/lighthouse#4918). An overview of the primary changes are:

Standard Liveness Endpoint

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

Major Changes

New HTTP APIs

The Lighthouse BN supports the following new HTTP APIs:

:warning: Breaking Changes :warning:

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: sigp/lighthouse#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 sigp/lighthouse#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 sigp/lighthouse#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.

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

Use the new and equivalent --prefer-builder-proposals VC flag to restore this functionality (see sigp/lighthouse#5086).

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 sigp/lighthouse#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: sigp/lighthouse@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

@github-actions github-actions bot added rust Rust use is a significant feature of the PR or issue bump-formula-pr PR was created using `brew bump-formula-pr` labels Jan 28, 2024
lighthouse: update homepage

Signed-off-by: Rui Chen <rui@chenrui.dev>
Copy link
Contributor

🤖 An automated task has requested bottles to be published to this PR.

@github-actions github-actions bot added the CI-published-bottle-commits The commits for the built bottles have been pushed to the PR branch. label Jan 28, 2024
@BrewTestBot BrewTestBot added this pull request to the merge queue Jan 28, 2024
Merged via the queue into Homebrew:master with commit bd2a0d0 Jan 28, 2024
12 checks passed
@chenrui333 chenrui333 deleted the bump-lighthouse-4.6.0 branch March 4, 2024 17:45
@github-actions github-actions bot added the outdated PR was locked due to age label Apr 3, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bump-formula-pr PR was created using `brew bump-formula-pr` CI-published-bottle-commits The commits for the built bottles have been pushed to the PR branch. outdated PR was locked due to age rust Rust use is a significant feature of the PR or issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants