Merged
Conversation
github-actions
bot
added
rust
lighthouse: update homepage Signed-off-by: Rui Chen <[email protected]>
chenrui333
force-pushed
the
bump-lighthouse-4.6.0
branch
from
0c6653f to
ce6dd05
Compare
dtrodrigues
approved these changes
Jan 28, 2024
Contributor
|
🤖 An automated task has requested bottles to be published to this PR. |
github-actions
bot
added
the
CI-published-bottle-commits
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Created by
brew bumpCreated with
brew bump-formula-pr.Details
release notes
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-v3to 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-payloadPlease 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_proposalsfield. 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_builderfield along with each local payload. Lighthouse will check if this is set totrueand 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
--broadcastflag. 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-allflag. 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:
builder_comparison_factorethereum/beacon-APIs#386)POSTAPIs for fetching validators & balances in bulk: Implement POST validators/validator_balances APIs sigp/lighthouse#4872GET /eth/v1/beacon/blob_sidecarsfor Deneb (https://ethereum.github.io/beacon-APIs/#/Beacon/getBlobSidecars):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-protectionfeature.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.
--specforlighthouse bn--eth1-endpointforlighthouse bn--eth1-endpointsforlighthouse bn--beacon-nodeforlighthouse vc--serverforlighthouse vc--delete-lockfilesforlighthouse vc--allow-unsyncedforlighthouse vc--strict-fee-recipientforlighthouse vc--mergeforlighthouse bn--count-unrealizedforlighthouse bn--count-unrealized-fullforlighthouse bn--http-disable-legacy-specforlighthouse bn--minifyforlighthouse 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-thresholdBN flagPrefer using the
-min-bidflag inmev-boost. Alternatively, the new--builder-boost-factorVC flag can be used to achieve a similar effect using a percentage multiplier (see sigp/lighthouse#5086). For example, using--builder-boost-factor 120increases 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-payloadBN flagUse the new and equivalent
--prefer-builder-proposalsVC flag to restore this functionality (see sigp/lighthouse#5086).Deprecated:
--disable-run-on-allVC flagThis flag has been superseded by the
--broadcastflag. Use--broadcast noneto 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:
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.
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