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.release notes
:warning: Deprecated CLI Flags :warning:
The following beacon node flags have been deprecated. You should remove them, but the beacon node will still start if they are provided.
--light-client-server:crab: Minimum Supported Rust Version :crab:
We have updated the Minimum Supported Rust Version (MSRV) for this release from 1.80.0 to 1.83.0.
This is only relevant to users compiling Lighthouse from source.
You can update your Rust compiler using:
IPv6 by Default
Lighthouse will now automatically listen on IPv6 if it detects a globally-routable address. We expect for the majority of users with IPv4-only setups that this change will have no effect, but that it will benefit users with correctly configured IPv6 stacks.
The default IPv6 listening port has been changed from port 9090 to port 9000 (same as IPv4) to make firewalling easier. The IPv6 port can be adjusted using the flag
--port6.You can opt-out of IPv6 by using the flag
--listen-address 0.0.0.0to only listen on IPv4.For more information, see the Lighthouse blog:
Gas Limit Enforcement
Lighthouse BN now enforces gas limit preferences when validating execution payloads from external builders (e.g.
mev-boostrelays). You can configure the gas limit for all validators connected to a VC using--gas-limit, or set individual limits in thevalidator_definitions.yml, or using the VC HTTP API.:zap: Electra :zap:
The Electra hard fork, paired with the Prague hard fork on the execution layer – together known as Pectra – brings several new features to Ethereum.
The headline change is known as Max EB, and raises the maximum effective balance a single validator may wield from 32 ETH to 2048 ETH. Once adopted, this will allow the network to run more efficiently with a lower validator count, while retaining the same level of security. Max EB even removes some centralisation vectors from staking incentives so that solo validators are able to tap into the compounding rewards previously enjoyed exclusively by large operators.
The process of switching a validator's max effective balance is a consolidation, which transfers stake from one validator to another. Consolidations are triggered via a smart contract call, and are fully opt-in and voluntary. If you are a solo operator with a small number of validators, there is no need to consolidate, although you may choose to do so.
Information about consolidation tooling has been added to the Lighthouse book:
Bug Fixes
State Cache Misses
A number of users reported seeing an increased number of state cache misses following the update to v7.0.0:
We have restored the state cache size to 128 in order to reduce cache misses, and will continue optimising the cache for non-finality. See the issue for details: sigp/lighthouse#7363
Bugfix for
InsufficientPeersBoth v7.0.1 and v7.0.0 include a bugfix for a regression in attestation subscription logic, resolving
InsufficientPeerserrors.New Features
redb. This is still experimental and only reccommended for expert users.--network hoodi).Optimisations
BlocksByRange/BlobsByRangeduring non-finality.Update Priority
This table provides priorities for which classes of users should update particular components.
Update priority is Low if you have already updated to v7.0.0.
See Update Priorities for more information about this table.
Compatible Execution Clients
You must update both the consensus client (Lighthouse) and execution client to be ready for Pectra.
All Changes
/eth/v2/beacon/pool/attestationshonorscommittee_index(#7298)light_client/updatesendpoint returns spec compliant SSZ data (#7230)cargo auditfailure (#7313)pending_consolidationsBeacon API endpoint (#7290)--invalid-block-roots(#7042)RUSTSEC-2024-0437(#7114)epochs-per-blob-prunedefault to 256 (#7113)RUSTSEC-2025-0009(#7086)sync_tolerance_epochsflag to control the proposer prep routines (#7044)--long-timeouts-multiplierCLI flag (#7047)--disable-attestingflag to validator client (#7046)SYNC_TOLERANCE_EPOCHSfor range sync testing (#7030)trivialandready-for-mergelabels to satisfy if base is notstable(#6997)GET v2/validator/aggregate_attestationis backwards compatible (#6984)RUSTSEC-2025-0006(#6972)SingleAttestationconversion (#6934)POST /eth/v2/beacon/pool/attestationsbugfixes (#6867)rust_eth_kzg(#6848)node/identityAPI (#6827)SingleAttestationimplementation (#6488)getBlobsrace condition (#6756)v1.5.0-beta.0(#6731)--datadirflag is present (#6748)getBlobSidecarssupport for PeerDAS (#6755)getBlobsor reconstruction (#6686)ZeroizeStringin favour ofZeroizing<String>(#6661)Binaries
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key:
15E66D941F697E28F49381F426416DC3F30674B0