Bot releases are visible (Hide)
Published by github-actions[bot] over 1 year ago
This high-priority hot-fix address high CPU usage experienced after the Capella upgrade (April 12 UTC).
We recommend all mainnet users update to this release to prevent high CPU usage from interfering with normal node operations (e.g., staking).
This hot-fix only applies to the Beacon Node. There is no need to upgrade the Validator Client from v4.0.1 (or v4.0.1-rc.0) to this release.
This hot-fix is not yet applied to the unstable
or stable
branches. To build from source, use the hotfix-exit-verification
branch (or checkout the v4.0.2-rc.0
tag).
There are no breaking changes in this release.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High | Low |
Non-Staking Users | High | --- |
See Update Priorities more information about this table.
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.0.2-rc.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.2-rc.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.2-rc.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.2-rc.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v4.0.2-rc.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v4.0.2-rc.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.2-rc.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.2-rc.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v4.0.2-rc.0 | sigp/lighthouse |
Published by github-actions[bot] over 1 year ago
This release is mandatory for all mainnet users (except for those running v4.0.1-rc.0). It enables the Capella/Shanghai ("Shapella") upgrade (#4111), which will occur at April 12, 2023, 10:27:35pm UTC. Any node which is not updated to Lighthouse a v4.x.x release before 10:27pm on April 12th (UTC) will stop following the chain and will need to be resynced. For stakers, this would result in missed rewards and penalties.
For clarity, all mainnet Lighthouse users must be running a v4.x.x release on their BNs and VCs by April 12, 2023, 10:27:35pm UTC.
This release also contains various bug-fixes, optimisations and new features:
ERRO Dialing an already dialing peer
log (#4056)This release replaces the v4.0.0 release which was retracted due to the discovery of a bug. A v4.0.1-rc.0 hot-fix was published to patch that bug. That bug fix is also included in this release.
This release (v4.0.1) replaces both v4.0.0 and v4.0.1-rc.0.
We have the following advice for users:
These release notes have been written with respect to v3.5.1 rather than the previous retracted release of v4.0.0.
The Capella/Shanghai ("Shapella") upgrade will occur on mainnet at:
All Lighthouse Beacon Nodes and Validator Clients must be upgraded to a reliable v4.x.x release to ensure they follow the correct chain. The following table demonstrates which releases are reliable, Shapella-ready releases:
Release | Is Reliable, Shapella-Ready v4.x.x Release |
---|---|
v3.5.1 | ❌ No |
v4.0.0 | ❌ No |
v4.0.1-rc.0 | ✅ Yes |
v4.0.1 | ✅ Yes |
Any release after v4.0.1 | ✅ Yes |
Preparation for the Shapella upgrade is much simpler than the preparation required for "The Merge" (Bellatrix). To be Shapella ready, users just need to:
If your execution engine does not yet have a Shanghai-ready release then it is safe to upgrade Lighthouse to v4.x.x without also upgrading the execution engine. An up-to-date execution engine will be required before April 12th, though.
There are no new flags to be added or removed for the Shapella upgrade, simply upgrade and wait.
Lighthouse will start periodically emitting the following logs two weeks before the Shapella upgrade (29th of March):
Not ready for Capella
if Lighthouse has detected that the execution engine is too outdated to support Shanghai.Ready for Capella
if Lighthouse has detected a modern execution engine release.Just because Lighthouse is logging Ready for Capella
does not indicate that your execution engine is on the correct version. There is no way for Lighthouse to determine this exactly and users are responsible for ensuring that their execution engine is using the latest release.
Fixed as of Erigon v2.42.0
There was a bug in Erigon v2.41.0 and earlier which caused Erigon to time out when paired with Lighthouse v4.0.1. This was reflected in the Lighthouse logs as an error log containing the phrase TimedOut
, like this:
ERRO Error during execution engine upcheck error: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(8551), path: "/", query: None, fragment: None }, source: TimedOut }), service: exec
The issue is resolved in Erigon v2.42.0 and later, see this issue for details: https://github.com/ledgerwatch/erigon/issues/7172.
There are no breaking changes between this release and v4.0.0 and v4.0.1-rc.0. The following changes are with reference to v3.5.1.
To support changes to the fork choice algorithm, the database schema has been upgraded to v16. The schema upgrade will be applied automatically upon upgrading and should not take more than a few seconds.
To downgrade, follow the instructions in the book for Database Migrations.
Users may downgrade anytime before the Capella upgrade. Prior Lighthouse releases are not compatible with Capella, so downgrading is fundamentally impossible after the upgrade occurs.
The minimum supported Rust version has been set to 1.66. 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.0.0 (/home/karlm/lighthouse/lighthouse)` cannot be built because it requires rustc 1.66 or newer
Users can typically obtain the latest version of Rust by running rustup update
.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High | High |
Non-Staking Users | High | --- |
See Update Priorities more information about this table.
has_context_bytes
(#3972)http_api
(#4068)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.0.1-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v4.0.1-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v4.0.1-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v4.0.1 | sigp/lighthouse |
Published by github-actions[bot] over 1 year ago
This release is a hot-fix to patch a bug introduced in v4.0.0, which was published Wednesday, March 22, 2023 11:56:00 PM UTC. The v4.0.0 release has been removed from the Github releases page.
The bug was found by our fuzzers and has not been triggered on any networks. If triggered, it would result in temporary periods of effective downtime of several slots.
It is unlikely that this bug will present itself on mainnet, however we recommend the following actions for all networks (Mainnet, Goerli, Prater, Sepolia, Gnosis, etc):
We are not recommending v4.0.0 users downgrade to v3.5.1 since a manual database migration is required. Users familiar with database migrations are safe to downgrade.
If you are not sure if you've updated, you can run lighthouse --version
to find out.
The Docker stable
flag has been updated to point to the patched version. If you have updated your stable
Docker containers after Wednesday, March 22, 2023 11:04:00 PM UTC, we recommend updating again to obtain the patch.
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.0.1-rc.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-rc.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-rc.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-rc.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v4.0.1-rc.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v4.0.1-rc.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-rc.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v4.0.1-rc.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v4.0.1-rc.0 | sigp/lighthouse |
Published by github-actions[bot] over 1 year ago
This release is a low-priority release for all users except for those using the Goerli test network.
For Goerli (aka Prater) users, this release includes the Capella fork parameters (#4044). Goerli will undergo the Capella upgrade (a.k.a "hardfork") on 14/03/2023 at 10:25:36 pm UTC. Goerli users must update to this version or later before the Capella upgrade. Users that fail to upgrade will cease to follow the chain and will be required to resync.
Users of Ethereum Mainnet or other networks/testnets (e.g., Sepolia, Gnosis Chain) may choose to update to this release to take advantage of various optimisations and bug fixes.
Notable changes in this release include:
There are no breaking changes that affect Mainnet users.
The --network kiln
and --network ropsten
flags are no longer supported. Kiln was deprecated Q3 2022 and Ropsten was deprecated in Q4 2022. Removing these networks has reduced the size of the Lighthouse binary by approximately 30MiB.
Dedicated Ropsten and Kiln users can still use these networks by manually obtaining the testnet configuration directories and using the --testnet-dir
flag.
Goerli is upgrading to Capella on 14/03/2023 at 10:25:36 pm UTC! 🎉
Goerli users must update both the Lighthouse beacon node and validator client before March 14. Failure to update will result in missed validator duties and a corrupt beacon node database (requiring a re-sync).
Goerli users must also ensure they are running a compatible execution engine. The Ethereum Foundation will publish a "Goerli Shapella Announcement" in the coming days which will contain more information and a list of compatible execution layer releases.
Lighthouse will emit INFO Ready for Capella
logs when both itself and the execution engine are ready for the Capella upgrade. Conversely, Lighthouse will emit WARN Not ready for Capella
logs when it detects a misconfiguration.
In #4024 and #4051 we added new Prometheus metrics for monitoring the round-trip latency between a VC and the BN. The latency measurement is the time it takes the VC to send, receive and parse a call to the BN's eth/v1/node/version
endpoint.
There are two new metrics exposed by the VC:
vc_beacon_node_latency_primary_endpoint
: shows the latency for the primary BN.vc_beacon_node_latency
: shows the latency for all BNs, with the endpoint URL as the endpoint
label.Producing a block requires two HTTP calls between the VC and the BN. Therefore, latency on this connection can contribute significantly to block publishing delays. Blocks which are published late are more likely to be orphaned.
Those using Grafana+Prometheus can use the following query to view the 99th percentile latency for their primary BN:
histogram_quantile(0.99, rate(vc_beacon_node_latency_primary_endpoint_bucket[$__rate_interval]))
The optimised maxperf
profile is currently not working on Windows due to a suspected regression in the Rust compiler. The pre-compiled Windows binaries have been built with the release
profile instead and may exhibit slightly reduced performance compared to previous versions. See https://github.com/sigp/lighthouse/issues/3964 for details.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Low Priority | Low Priority |
Non-Staking Users | Low Priority | --- |
The Beacon Node may be updated without the Validator Client, however we recommend updating both components for completeness.
Goerli users must update both the beacon node and the validator client.
See Update Priorities for more information about this table.
WARN
in the VC for a mismatched Capella fork epoch (#4050)null
LVH from an INVALID
response to newPayload
(#4037)v1.3.0-rc.3
(#4021)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.5.1-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.1-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.1-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.1-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.5.1-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.5.1-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.1-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.1-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.5.1 | sigp/lighthouse |
Published by github-actions[bot] over 1 year ago
This release is a low-priority release for all users (including mainnet), except for those using the Sepolia test network
For Sepolia users, this release includes the Capella fork parameters. Sepolia will undergo the Capella upgrade (a.k.a "hardfork") on 2023/2/28 at 4:04:48 AM UTC. Sepolia users must update to this version or later before the Capella upgrade. Users that fail to upgrade will cease to follow the chain and will be required to resync.
Ethereum mainnet, Ethereum testnet (e.g., Goerli, Ropsten) and Gnosis users may choose to update to this release, but it is low-priority.
Alongside the Sepolia changes, this release includes:
To support Capella the database schema has been upgraded to v15. The schema upgrade will be applied automatically upon upgrading and should not take more than a few seconds.
To downgrade, follow the instructions in the book for Database Migrations.
Users may downgrade anytime before the Capella upgrade. Prior Lighthouse releases are not compatible with Capella, so downgrading is fundamentally impossible after the upgrade occurs.
Users building from source will have to update their Rust compiler version to at least 1.65.0 using a command like:
rustup update stable
Newer versions of the compiler including the latest (v1.67.1 at time of writing) will also work.
Older versions will log an error during compilation.
Previously, the Beacon Node HTTP would return 405
(method not allowed) for an unknown route (e.g. http://localhost:5052/not_a_real_route
). Lighthouse will now return a 404
(not found) error.
Sepolia is upgrading to Capella on 2023/2/28 at 4:04:48 AM UTC! 🎉
Sepolia users must update both the Lighthouse beacon node and validator client before February 28. Failure to update will result in missed validator duties and a corrupt beacon node database (requiring a re-sync).
Sepolia users must also ensure they are running a compatible execution engine. The Ethereum Foundation Sepolia Shapella Annoucement contains more information and a list of compatible execution layer releases.
Lighthouse will emit INFO Ready for Capella
logs when both itself and the execution engine are ready for the Capella upgrade. Conversely, Lighthouse will emit WARN Not ready for Capella
logs when it detects a misconfiguration.
The optimised maxperf
profile is currently not working on Windows due to a suspected regression in the Rust compiler. The pre-compiled Windows binaries have been built with the release
profile instead and may exhibit slightly reduced performance compared to previous versions. See https://github.com/sigp/lighthouse/issues/3964 for details.
This table provides priorities for which classes of mainnet users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Low Priority | Low Priority |
Non-Staking Users | Low Priority | --- |
Note: this update is high-priority for Sepolia users.
The Beacon Node may be updated without the Validator Client, however we recommend updating both components for completeness. Sepolia users must update both the beacon node and the validator client.
See Update Priorities for more information about this table.
This release contains the Capella functionality (#3763), which has been the result of several months of work. To ensure rightful attribution to its contributors, we have elected to perform a merge commit rather than our usual squash-merge. This has created an unusually complex history on the stable
branch, so we have omitted the full list of changes in this release.
The full list of commits between this version (v3.5.0) and the previous version (v3.4.0) can be viewed on Github.
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.5.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.5.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.5.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.5.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.5.0 | sigp/lighthouse |
Published by github-actions[bot] over 1 year ago
⚠️ You should not run this alpha release supporting mainnet validators ⚠️
If you are looking for the latest Lighthouse release please go to https://github.com/sigp/lighthouse/releases/latest.
This is an alpha release of upcoming changes to Lighthouse which improve disk usage and state management.
For more information about the -tree.X
family of releases, please see the v3.4.0-tree.1
release notes.
Compared to the previous release the main changes are:
unstable
, including new rewards APIs.Note that there is no v3.4.0-tree.2
release due to a build failure.
This release is not backwards compatible with stable Lighthouse. It uses a different database schema (v20) for which no automatic upgrade or downgrade is implemented. We intend to implement an automatic upgrade process once the new schema is finalized. A re-sync will be required to run future versions of tree-states
.
This release is backwards compatible with the prior tree-states
release (v3.4.0-tree.1
).
Please only run this release if you are willing to re-sync now, and again in several weeks/months.
Expect a few sharp edges. Some things you may run into:
WARN Parent state is not advanced
is logged excessively during sync. This is harmless, albeit annoying.maxperf
profile (use release
).Build the v3.4.0-tree.3
tag.
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.4.0-tree.3-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.3-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.3-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.3-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.4.0-tree.3-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.4.0-tree.3-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.3-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.3-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.4.0-tree.3 | sigp/lighthouse |
Published by github-actions[bot] almost 2 years ago
⚠️ You should not run this alpha release supporting mainnet validators ⚠️
If you are looking for the latest Lighthouse release please go to https://github.com/sigp/lighthouse/releases/latest.
This is an alpha release of upcoming changes to Lighthouse which improve disk usage and state management.
We are making this alpha release so that expert users may help us test these improvements. It is not backwards-compatible and not recommended for mainnet validators.
For the adventurous, the main benefits are:
--slots-per-restore-point=32
and --reconstruct-historic-states
.We hope that this is useful for running block explorers and supporting other beacon chain analytics. We are using it internally at SigP to run some of our analytics.
Aside from the experimental tree-states
changes this release is up-to-date with Lighthouse v3.4.0 and includes the same features.
This release is not backwards compatible with stable Lighthouse. It uses a different database schema (v20) for which no automatic upgrade or downgrade is implemented. We intend to implement an automatic upgrade process once the new schema is finalized. A re-sync will be required to run future versions of tree-states
.
Please only run this release if you are willing to re-sync now, and again in several weeks/months.
Expect a few sharp edges. Some things you may run into:
WARN Parent state is not advanced
is logged excessively during sync. This is harmless, albeit annoying.BeaconState
does not quote integers for some fields. This will be fixed shortly, but SSZ can be used as a workaround.The fundamental change supporting these improvements is a change to the in-memory representation of the BeaconState
from flat vectors to copy-on-write trees. This enables many more BeaconState
s to be stored in memory, but comes at the cost of increased iteration time. As a result, block and epoch processing times are slower. To mitigate this we are working on new caches and optimisations which bring block processing times back in line with stable Lighthouse. This puts the tree-states
branch in a slightly awkward spot, because we cannot responsibly merge it until it is better than stable Lighthouse on every possible metric (a Pareto improvement).
Seeing as tree-states
alters the database schema quite drastically, we also decided to roll in a few other improvements. The plan is to get the new schema as close to perfect as possible so that in a future release everyone can upgrade once with minimal fuss.
Build the v3.4.0-tree.1
tag.
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.4.0-tree.1-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.1-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.1-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.1-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.4.0-tree.1-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.4.0-tree.1-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.1-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-tree.1-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.4.0-tree.1 | sigp/lighthouse |
Published by github-actions[bot] almost 2 years ago
This high-priority release contains important bug fixes, optimizations and a notable change to fork choice which incentivizes the timely production of blocks.
Other interesting changes include:
Lighthouse nodes running this version (or later) will attempt to re-org blocks which arrive late and subsequently receive very few votes from other validators. Lighthouse will not attempt a re-org unless it is confident that its own block will become the head and the action is in the best interests of the Ethereum network.
It is expected that re-orging a late block will be significantly profitable for the entity which performs the re-org. The loss induced by the validator which produced the late block will incentivize performance improvements.
See Late Block Re-orgs in the Lighthouse Book for more information.
This release contains two breaking changes regarding the validator monitor on the BN.
A new flag has been added to the Beacon Node: --validator-monitor-individual-tracking-threshold
. The default value is 64
, which means that when the validator monitor is tracking more than 64 validators then it will stop tracking per-validator metrics and only track values via the new total
label. It will also stop logging per-validator logs and only emit aggregated logs (the exception being that exit and slashing logs are always emitted).
The new total
label tracks the aggregated metrics of all validators in the validator monitor (as opposed to each validator being tracking individually using its pubkey as the label). It only tracks values which are easily aggregated (e.g. total count of attestations seen) and omits values which are not easily aggregated (e.g. most recent inclusion distance).
These changes were introduced in #3728 to address issues with untenable Prometheus cardinality and log volume when using the validator monitor with high validator counts (e.g., 1000s of validators). Users with less than 65 validators will see no change in behavior (apart from the added total
metric). Users with more than 65 validators who wish to maintain the previous behavior can set something like --validator-monitor-individual-tracking-threshold 999999
.
The validator monitor will no longer emit WARN
and ERRO
logs for sub-optimal attestation performance. The logs will now be emitted at INFO
level. This change was introduced to avoid cluttering the WARN
and ERRO
logs with alerts that are frequently triggered by the actions of other network participants (e.g., a missed block) and require no action from the user.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High Priority | Medium Priority |
Non-Staking Users | High Priority | --- |
The Beacon Node may be updated without the Validator Client, however we recommend updating both components for completeness.
See Update Priorities more information about this table.
INFO
(#3727)validator_monitor
metrics to the HTTP API (#3760)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.4.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.4.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.4.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.4.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.4.0 | sigp/lighthouse |
Published by paulhauner almost 2 years ago
This release is a low-priority release for all users, except those using the Gnosis Chain.
For Gnosis users, this release includes the Gnosis Merge parameters. Gnosis users will need to update to this release before November 30th or they will fail to go through the merge transition and will be left following the wrong chain. Therefore, this release is high-priority for Gnosis users.
Ethereum mainnet and Ethereum testnet (e.g., Goerli, Sepolia) users may choose to update to this release, but it is low-priority.
Alongside the Gnosis changes, this release includes:
--checkpoint-sync-url-timeout
flag (#3710)To support new features the database schema has been upgraded to v13. The schema upgrade will be applied automatically upon upgrading and should not take more than a few seconds.
To downgrade, follow the instructions in the book for Database Migrations.
The signing of sync committee messages by the validator client has been improved in a way that is incompatible with old versions of the Lighthouse beacon node. We do not expect many users to be affected because only versions prior to v3.0.0 are incompatible.
For details please see: https://github.com/sigp/lighthouse/pull/3624
Gnosis chain is merging! 🎉
The expected timeline is:
You must update both the Lighthouse beacon node and validator client before November 30. Failure to update will result in missed validator rewards and a corrupt beacon node database (requiring a re-sync).
You must also ensure you're running a compatible verison of Nethermind (v1.14.6 or newer) and that it is correctly connected to your Lighthouse beacon node. For further instructions please see:
We are pleased to announce the readiness of deposit snapshot sync, which enables nodes to quickly sync the deposit contract.
When setting up a new Lighthouse node using checkpoint sync, a snapshot of the deposit contract will be downloaded from the checkpoint sync provider. Initially the only supported provider is Lighthouse v3.3.0, although we expect checkpointz
and the other clients soon will roll out support soon.
If the checkpoint sync provider does not support the feature you'll see a pair of warning logs:
WARN Remote BN does not support EIP-4881 fast deposit sync
WARN Failed to finalize deposit cache
These warnings are harmless, and Lighthouse will gracefully fallback to syncing the deposit contract cache from the execution node.
Depsosit snapshot support is the result of many months of work by @ethDreamer, who not only implemented the feature in Lighthouse but also wrote the spec for it, EIP-4811.
For further details on the implementation see: https://github.com/sigp/lighthouse/pull/2915
This table provides priorities for which classes of mainnet users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Low Priority | Low Priority |
Non-Staking Users | Low Priority | --- |
Note: this update is high-priority for Gnosis chain users.
The Beacon Node may be updated without the Validator Client, however we recommend updating both components for completeness. Gnosis users must update both the beacon node and the validator client.
See Update Priorities for more information about this table.
mut
(#3736)Published by michaelsproul about 2 years ago
This medium-priority release is a patch release for the recently released v3.2.0, fixing a performance regression.
Please see the release notes for v3.2.0 for a summary of included features and breaking changes:
https://github.com/sigp/lighthouse/releases/tag/v3.2.0
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Medium Priority | Medium Priority |
Non-Staking Users | Low Priority | --- |
The Beacon Node may be updated without the Validator Client and vice versa, as long as both BN and VC are running a v3.x release.
Beacon nodes and validator clients on pre-v3.0.0 versions have been unable to follow the chain since September 6 2022 when the Bellatrix hard fork was activated.
See Update Priorities for more information about this table.
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.2.1-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.1-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.1-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.1-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.2.1-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.2.1-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.1-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.1-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.2.1 | sigp/lighthouse |
Published by github-actions[bot] about 2 years ago
This medium-priority release contains bugfixes, optimisations and new features. We would like to see this release widely deployed on mainnet in the coming weeks.
Notable changes include:
There are also some minor breaking changes, described in Breaking Changes. In particular, users compiling from source must ensure that a Protobuf compiler is installed. The --eth1-endpoints
flag should also be removed.
Prior versions of Lighthouse are affected by a bug which sometimes causes blocks with 0 attestations to be proposed, e.g. at slot 4992544. We estimate that around 1 in 700 blocks on mainnet are affected.
The impact of this bug is two-fold:
The bug was in validation code that was intended to prevent invalid attestations from being included in blocks, which was misfiring and blocking valid attestations.
We regret that this bug existed on mainnet as long as it did. It is present in all prior versions of Lighthouse except v2.4.0 and v2.5.0, meaning that all mainnet-capable releases are affected.
As more validators upgrade to v3.2.0 we hope to see improved attestation performance across the entire network, as well as increased block rewards for proposers running Lighthouse. Note that the bug does not result in decreased block rewards at the execution layer, as these rewards are due to included transactions rather than attestations.
For more detail on how the bugfix was implemented and tested please see this PR: https://github.com/sigp/lighthouse/pull/3629.
Thanks to Moshe Revah (@moshe-blox) for noticing the issue and bringing it to our attention.
In a first step to improve the Lighthouse validator client's fallback behaviour we have implemented broadcast of subscriptions and preparation messages to fallback beacon nodes. This means that running fallback nodes with --subscribe-all-subnets
is no longer required.
The extra messages might impose some additional bandwidth and processing load on both the VC and the BN, but our testing indicates that it is quite minimal and significantly less than the overhead of running unnecessarily with --subscribe-all-subnets
.
If you are running multiple beacon nodes and would like to opt-out of the broadcast behaviour you can do so using --disable-run-on-all
as a flag to lighthouse vc
.
Users running a single beacon node with each validator client are unaffected and do not need to add any flags or take any action.
For implementation details please see this PR: https://github.com/sigp/lighthouse/pull/3529.
This release includes two improvements to reduce block processing times by around 35%.
The first optimisation is algorithmic and nets a 20% improvement by avoiding re-calculation of the proposer index (see https://github.com/sigp/lighthouse/pull/3604).
The second improvement comes from enabling aggressive compiler optimisations, including LTO. These compiler optimisations are enabled in the pre-compiled binaries and Docker images, but are not be enabled for source builds by default due to the substantial increase in build time. Users building from source may opt-in via the maxperf
compilation profile.
There are no less than 3 new flags for controlling interaction with the execution layer client, all contributed by external contributors:
--disable-deposit-contract-sync
: prevent Lighthouse from syncing the deposit contract logs. This is useful if running an execution node for a purpose other than staking. It should not be used for staking nodes as it will cause missed block proposals.
--execution-timeout-multiplier N
: set a longer timeout for responses from the execution layer. This is useful for low-powered nodes which may struggle to follow the chain if they timeout continually. We don't recommend using this flag for staking as such low-powered nodes are unlikely to be able to support validators.
--execution-jwt-secret-key KEY
: set the JWT secret via the CLI rather than from a file. This comes at the cost of reduced security, as the secret will be leaked to other users on the same machine. It is intended for use in automated provisioning systems.
All flags apply to lighthouse bn
. For further documentation please see lighthouse bn --help
.
Thanks to @pinkiebell, @GeemoCandama and @mariuspod for these contributions!
libp2p
has been updated to v0.48.0 which brings several improvements and lays the groundwork for further reductions in bandwidth. Please see https://github.com/sigp/lighthouse/pull/3547 for details.
Upgrading to v3.2.0 can be done with minimal changes to configuration. We expect most users will be able to upgrade without any changes. However, if you are still using multiple nodes with --eth1-endpoints
you must remove them, see below.
Downgrading to v3.1.2 after upgrading is also supported, so long as any new flags are removed before switching back (e.g. --execution-jwt-secret-key
).
--eth1-endpoints
We have simplified some code by the removal of fallback support from --eth1-endpoints
, which has been deprecated since The Merge.
If you are still using the --eth1-endpoints
flag with multiple endpoints we recommend that you remove the flag entirely. Failure to remove it before upgrading will result in lighthouse bn
failing to start.
If you are using --eth1-endpoint
or --eth1-endpoints
with a single argument then Lighthouse will still start, but the value of the flag will be ignored.
The only network that hasn't merged at time of writing is Gnosis Chain. If you would like to run a Gnosis node with fallback eth1 nodes we recommend remaining on a prior version such as v2.5.0 (which is also free of the block proposal bug).
For more information on the removal of fallback eth1 nodes please see https://github.com/sigp/lighthouse/pull/3594, and the Merge Migration guide in the book.
Building from source now requires a Protobuf compiler (protoc
) to be installed. The Build from Source instructions in the book have been updated to document this change.
For example, on Ubuntu, protoc
can be installed with:
sudo apt install protobuf-compiler
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Medium Priority | Medium Priority |
Non-Staking Users | Low Priority | --- |
The Beacon Node may be updated without the Validator Client and vice versa, as long as both BN and VC are running a v3.x release.
Beacon nodes and validator clients on pre-v3.0.0 versions have been unable to follow the chain since September 6 2022 when the Bellatrix hard fork was activated.
See Update Priorities for more information about this table.
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.2.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.2.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.2.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.2.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.2.0 | sigp/lighthouse |
Published by github-actions[bot] about 2 years ago
This low-priority release contains several optimisations to improve performance on the newly merged mainnet!
Notable changes include:
There are also a few minor breaking changes, described in Breaking Changes.
Note that there is no v3.1.1 release due to a minor bug that was found and fixed before that release had been fully published.
One issue we've noticed on mainnet is that requests to the execution node sometimes time out.
ERRO Error fetching block for peer error: ExecutionLayerErrorPayloadReconstruction(0x4092070250431d93d6b0331ec940bf467407302038347382ab57d4e945527e08, EngineError(Api { error: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("localhost")), port: Some(8551), path: "/", query: None, fragment: None }, source: TimedOut }) }))
To reduce the number of requests made to the execution node, we have made payload pruning optional in v3.1.2. Payload pruning is the process by which Lighthouse avoids storing execution payloads in its database. When enabled, Lighthouse will fetch payloads from the execution node on-demand. Although this saves disk space it imposes substantial load on the execution node when a syncing peer requests blocks from Lighthouse.
When upgrading to v3.1.2 you should make a choice to enable or disable payload pruning:
--prune-payloads false
flag on the beacon node. Lighthouse will keep all execution payloads in its database and serve them to peers directly. This will consume slightly more disk space but will reduce load on the execution node. This is recommended for users who have seen frequent timeouts and users running on constrained devices (particularly where I/O is scarce). We hope that this may be particularly helpful to users running Besu, which seems to timeout more frequently.You may freely switch between --prune-payloads false
and the default configuration (equivalent to --prune-payloads true
). If you are unsure, we recommend starting out with --prune-payloads false
, as any payloads deleted after running with payload pruning enabled will remain deleted. Our medium-term goal is to make payload pruning efficient enough to be usable by all nodes, and we are collaborating with the execution client devs on this.
For more information on the implementation of this feature please see https://github.com/sigp/lighthouse/pull/3565, https://github.com/sigp/lighthouse/pull/3587.
This release includes a ~20% reduction in the time it takes to compute the merkle root of a beacon block (#3581). Since the merge introduced transactions to the beacon chain, computing the merkle root of a block has become more significant. This optimisation will result in faster block imports and therefore better attestation performance (i.e., more accurate head votes).
Additionally, the cache which stores information required to verify attestations has been modified to prevent duplicate work in some scenarios (#3574). Previously, it was possible for multiple attestations being processed on different threads to load the same BeaconState
from disk at the same time. This resulted in excess memory and CPU usage. With the new behaviour, the first attestation will load a single BeaconState
and other attestations will wait for that operation to complete.
Reduces bandwidth by limiting the time we are subscribed to subnets to a smaller time frame when needed. Upgrades to libp2p have allowed us to reduce our subscription time period.
For more information see https://github.com/sigp/lighthouse/pull/3419.
To give validators greater control over their interaction with external block builders, we have added a new flag --builder-profit-threshold
which filters out blocks from builders that pay the proposer less than a threshold value.
Please see the documentation for a full description: https://lighthouse-book.sigmaprime.io/builders.html#builder-profit-threshold
Note that this flag is for the beacon node, as the beacon node has lowest-latency access to both the builder payload and the local payload.
We hope that this feature compensates for the deprecation of --strict-fee-recipient
(see below).
You can upgrade to Lighthouse v3.1.2 without making any changes to your configuration, although you should be aware of the changes in behaviour listed below.
Downgrading to v3.1.0 after upgrading is also supported, so long as the new --prune-payloads
and --builder-profit-threshold
flags are removed before switching back to v3.1.0.
--strict-fee-recipient
The --strict-fee-recipient
flag for the validator client has been deprecated and no longer has any effect.
We took the decision to deprecate the flag for two reasons:
strict-fee-recipient
flag were used. This means the flag effectively disabled the external block builders entirely, which is not useful.If you are using --strict-fee-recipient
in your Lighthouse VC flags you should remove it. However, if you don't remove it Lighthouse will still start, but will log a warning. In future we will likely remove the flag entirely.
Two breaking changes were made to non-standard APIs and parameters:
/eth/v2/validator/blocks/{slot}
endpoint now uses the standard skip_randao_verification
parameter rather than the previously Lighthouse-only parameter verify_randao
.POST /lighthouse/analysis/block_rewards
now accepts blinded blocks for improved efficiency and better compatibility with MEV builders.We expect these changes will only affect a small number of expert users. For more information please see https://github.com/sigp/lighthouse/pull/3540.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Low Priority | Low Priority |
Non-Staking Users | Low Priority | --- |
The Beacon Node may be updated without the Validator Client, however both components must be updated to support the merge. Beacon nodes and validator clients on pre-v3.0.0 versions have been unable to follow the chain since September 6 2022 when the Bellatrix hard fork was activated.
See Update Priorities for more information about this table.
oneshot_broadcast
(#3596)oneshot_broadcast
for committee promises (#3595)skip_randao_verification
and blinded block rewards API (#3540)SmallVec
for TreeHash
packed encoding (#3581)lcli block-root
tool (#3580)axum
deps (#3570)InvalidValidatorIndex
error (#3503)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.1.2-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.2-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.2-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.2-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.1.2-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.1.2-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.2-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.2-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.1.2 | sigp/lighthouse |
Published by github-actions[bot] about 2 years ago
This high-priority release contains an important fix to ensure that Lighthouse does not attempt to produce invalid blocks. Furthermore, it improves block production efficiency, thereby increasing the likelihood of a Lighthouse-produced block being included in (and rewarded by) the canonical chain.
We recommend all mainnet users update before the Bellatrix upgrade on Sept 6, 2022, 11:34:47am UTC. Testnet users should upgrade at their next convenience.
Notable changes include:
The Ethereum mainnet network will upgrade to proof-of-stake on or around the 15th of September 2022. Before that, the Beacon Chain will perform the "Bellatrix" upgrade on Sept 6, 2022, 11:34:47am UTC.
Users do not have until Sept 15th to be "ready for the merge", rather they must be ready by Sept 6th. There is less than a week before users must be merge ready. See Merge Migration for more information.
There is one database migration in this release: v12 (#3312).
Older database versions will automatically upgrade to the latest version without user intervention. The migration may cause start-up to take a few minutes longer than usual, but subsequent restarts will be just as fast as previously.
Downgrading requires the user to use the lighthouse db
tool. See the Database Migrations documentation for detailed instructions.
Lighthouse will now return readonly: true
rather than readonly: null
on the GET /eth/v1/keystores
endpoint. This does not affect any other behaviour beyond that return value. We do not expect this behaviour to have an adverse impact on users.
--execution-jwt
flagsA bugfix was made to the --execution-jwt
flag such that it can only be provided if --execution-endpoint
is also provided. We hope that this has minimal impact on user setups as a node should either be configured with both flags (merge-ready) or neither (legacy). Full details are in https://github.com/sigp/lighthouse/pull/3494.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High Priority | High Priority |
Non-Staking Users | High Priority | --- |
The Beacon Node may be updated without the Validator Client, however both components must be updated to support the merge. A validator client running a pre-v3.0.0 release will not produce blocks after the Bellatrix upgrade.
See Update Priorities for more information about this table.
readonly: false
for local keystores (#3490)block_lookup_failed
EF test (#3489)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.1.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.1.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.1.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.1.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.1.0 | sigp/lighthouse |
Published by github-actions[bot] about 2 years ago
This high-priority release contains the parameters to enable the mainnet merge scheduled for September 2022. All mainnet users must upgrade to this release (or a subsequent release) before the Bellatrix fork on Sept 6, 2022, 11:34:47am UTC.
Users who fail to upgrade their nodes before the Bellatrix fork (September 6th) will stop following the canonical chain. We recommend upgrading to v3.0.0 at your earliest convenience.
In addition to upgrading to v3.0.0 (or later), users will also need to make other changes to their nodes. These changes will be familiar to Goerli/Prater users. For more information, please see our Merge Migration documentation.
Users will also be required to ensure that their "execution layer" client (i.e. Besu, Erigon, Geth or Nethermind) is also on a version with the latest merge parameters. We expect all consensus and execution layer clients to have merge-ready releases by 2022-08-23 (UTC). We recommend that users who are already using the --execution-endpoint
flag to wait until their execution layer client has released a merge-compatible release and update both clients together. Updating Lighthouse before the execution layer is not harmful, but it will result in noisy ExchangeTransitionConfigurationFailed
errors. The Ethereum Foundation is expected to publish an announcement on 2022-08-23 (UTC) with detailed information about which client releases are mainnet-ready.
There are also other valuable improvements and fixes in this release making it relevant to Prater/Goerli users as well:
lcli
(#3252)gas_limit
API (#3450)This release marks the culmination of over four years hard work by Lighthouse contributors. Upgrading Ethereum to proof-of-stake has been an incredibly complex and challenging task requiring hundreds of individuals to collaborate across borders, timezones and languages.
This upgrade will do no less than change the world. It will show the blockchain industry that we can all do better. It will show the world that Ethereum is willing to risk its own existence for the sake of this planet and those who inhabit it.
To everyone who has contributed to Lighthouse by running testnets, reporting issues, building documentation, supporting users and writing code, this is your success. You built Lighthouse and you upgraded Ethereum.
The breaking changes in this release are not expected to have significant negative impact on users.
As previously mentioned, this release contains the "total terminal difficulty" and "Bellatrix fork epoch" parameters (#3462). The Lighthouse developers understand that there is wide-reaching and enthusiatic consensus about these values.
To support these changes, the /eth/v1/config/spec
now returns values related to Bellatrix. More detail can be found in #3425.
blinded_blocks
API ChangesAs per #3429:
eth/v2/validator/blinded_blocks/{slot}
endpoint was removed since it did not exist in the beacon-API spec.version
value is now returned for the eth/v1/validator/blinded_blocks/{slot}
endpoint, as per the beacon-API spec.lcli
The skip-slots
and transition-blocks
commands in lcli
were overhauled to provide additional functionality and improved UX in #3252. Since lcli
is a tool intended for developers we do not expect production users to be affected by these changes.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High Priority | High Priority |
Non-Staking Users | High Priority | --- |
The Beacon Node may be updated without the Validator Client, however both components must be updated to support the merge. A validator client running a pre-v3.0.0 release will not produce blocks after the Bellatrix upgrade.
See Update Priorities for more information about this table.
PayloadStatus
returns (#3486)v1.2.0 rc.3
(#3483)lcli
functions (#3252)crypto/bls
: make blst
dependency optional (#3387)validator/blinded_blocks/{slot}
endpoint conforms to spec (#3429)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v3.0.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.0.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.0.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.0.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.0.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v3.0.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.0.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v3.0.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v3.0.0 | sigp/lighthouse |
Published by github-actions[bot] about 2 years ago
This high-priority release contains important fixes for mainnet users.
There were two separate bugs introduced into fork choice in v2.4.0 and v2.5.0.
The first bug results in a steady memory footprint increase of 100MB per month. It has been less than two weeks since that release so it's unlikely that a significant memory increase can be observed, yet. It was fixed in #3408.
The second bug can result in an error during fork choice. This error will only be triggered in rare timing-based circumstances and will resolve itself within seconds. It was fixed in #3402.
Furthermore, an incompatibility between Lighthouse VCs running v2.5.0 and BNs running a version prior to v2.5.0 (or Nimbus BNs) was detected and fixed in #3410.
There are no breaking changes in this release. If users have not already upgraded to v2.5.0 they should read the v2.5.0 release notes for the breaking changes in that release.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High Priority | Low Priority |
Non-Staking Users | High Priority | --- |
The Beacon Node may be updated without the Validator Client, however we recommend updating both components.
See Update Priorities for more information about this table.
owning_ref
soundness (#3415)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v2.5.1-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.1-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.1-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.1-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.5.1-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.5.1-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.1-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.1-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v2.5.1 | sigp/lighthouse |
Published by github-actions[bot] about 2 years ago
This medium-priority release contains a fix for mainnet users experiencing slow "eth1 cache" syncing times (several hours or more). A synced eth1 cache is required for reliable block production.
For Prater/Goerli users, this release contains several new features and bug fixes. The developers kindly request that all Prater/Goerli users update to this release before the Bellatrix upgrade (2022-08-04 12:24 pm UTC). This release is very close to what will be used for the mainnet merge (presently unscheduled). This release should get as much testing as possible during the Prater/Goerli upgrade. Any Prater/Goerli users on v2.3.1 must upgrade to this release before the Bellatrix upgrade or they will follow the wrong chain.
Improvements and fixes include:
execution_optimistic
flag to HTTP responses (#3070, #3374)mev-boost
support) (#3134)There are two database migrations in this release; v10 (#3322) and v11 (#3371).
Older database versions will automatically upgrade to the latest version without user intervention.
Downgrading requires the user to use the lighthouse db
tool. See the Database Migrations documentation for detailed instructions.
execution_optimistic
flag to HTTP APIThe execution_optimistic
flag has been added alongside the data
field on some (but not all) HTTP API responses as per v2.3.0 of the standard Beacon API.
It is unclear if adding a field at this section of the API is truly a breaking change or not, however we list it here for completeness.
// Lighthouse v2.4.0
{ "data": "object" }
// Lighthouse v2.5.0
{ "data": "object", "execution_optimistic": "boolean" }
The previous release (v2.4.0) contained several changes to CLI flags relating to the merge. Whilst we expect these changes to be largely inconsequential, users on a pre-v2.4.0 release should read the v2.4.0 release notes to understand these changes.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Medium Priority | Low Priority |
Non-Staking Users | Low Priority | --- |
The Beacon Node may be updated without the Validator Client, however we recommend updating both components.
See Update Priorities for more information about this table.
count-unrealized
by default (#3389)is_optimistic
to eth/v1/node/syncing
response (#3374)execution_optimistic
flag to HTTP responses (#3070)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v2.5.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.5.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.5.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.5.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v2.5.0 | sigp/lighthouse |
Published by github-actions[bot] over 2 years ago
This low-priority release contains improvements for mainnet validators and support for the upcoming Goerli/Prater merge. This release is recommended for all validators on all networks.
Whilst this release is "low-priority" for mainnet, Prater users must upgrade to this release (or a subsequent release) before 2022-08-04 12:24 pm UTC for the Bellatrix fork. Failure to upgrade in time will leave nodes following the wrong chain.
Improvements and fixes include:
NonConsecutive
eth1 endpoint errors (#3273)feerecipient
API (#3213)--network goerli
flag (#3346)--network goerli
Since Prater and Goerli will be merging, there is a consensus among the Ethereum community to begin to refer to the "Prater" beacon chain as the "Goerli" beacon chain. This helps convey the idea that the beacon chain and execution chain both form a single, unified chain.
To this end, this release supports the --network goerli
flag. Whilst this flag will connect to exactly the same network as when using --network prater
, it will result in a default data directory in ~/.lighthouse/goerli
, rather than ~/.lighthouse/prater
.
For users already using --network prater
, we recommend sticking with this value. Switching to --network goerli
will trigger Lighthouse to use a new data directory and therefore resync the beacon chain and ignore any existing validators. It's possible to migrate the prater
directory across to the goerli
name, however we do not have instructions for that at this stage.
In summary,
--network prater
--network goerli
The only difference is naming.
The breaking changes in this release should be inconsequential for mainnet users. However the changes may have some impact for users of post-merge testnets.
The MSRV was set to Rust 1.62 in #3304. Version 1.62 was released on June 30, 2022. If you are using an older version of Rust, please update before compiling.
finalized_checkpoint
SSE eventIn #3244, the state
field of the finalized_checkpoint
SSE endpoint now represents the state root of the finalized block, rather than the state root at the finalized slot. See #3244 for more information.
This change aligns Lighthouse with Teku's behaviour. It should be inconsequential for most users.
--suggested-fee-recipient-file
The --suggested-fee-recipient-file
provided a path to a file which contained a mapping of validator public key to suggested fee recipient. With the addition of the feerecipient
API (#3213), this feature was deemed an unncessary burden to mainain. The feature has been removed in this release, the validator client will fail to start if --suggested-fee-recipient-file
is present.
The reasoning for this decision can be found at #3264.
This release stabilises the flags that will be used for the beacon node after the merge. Whilst there are some functional changes to the flags we have worked to ensure that the BN will still start even when using deprecated flags; deprecated flags or features will be ignored and a deprecation notice logged.
The --merge
flag has been deprecated and no longer has any effect (it is permitted but ignored). Support for the merge will be enabled whenever --execution-endpoint
is supplied.
Support for multiple execution endpoints and payload builders has been removed. Only one value may be supplied for all related CLI flags. This has involved renaming some flags to remove the plural; the plural version now aliases to the singular version, but only supports a single value. Some jwt
flags have been renamed for clarity. The full list of renamed flags is below:
Old Flag (aliased to "New Flag") | New Flag |
---|---|
--execution-endpoints |
--execution-endpoint |
--jwt-secrets |
--execution-jwt |
--jwt-id |
--execution-jwt-id |
--jwt-version |
--execution-jwt-version |
--payload-builders |
--payload-builder |
Additionally, the --eth1-endpoints
flag will be ignored if the --execution-endpoint
flag is provided. Any requests that were sent to the --eth1-endpoints
will instead be sent to the --execution-endpoint
.
This list of changes does appear complex, however we believe that migration to the new format should be rather simple. We expect all existing CLI configurations to still work, but with some deprecated values ignored.
Here are some examples for demonstration:
# Still works exactly as before. Multiple eth1-endpoints will still be
# utilised since `--execution-endpoints` is not present.
lighthouse \
bn \
--eth1-endpoints http://localhost:8545,https://third-party.com
# Still works, however `--eth1-endpoints` will be ignored in favor
# of `--execution-endpoints`.
lighthouse \
bn \
--merge \
--execution-endpoints http://localhost:8551 \
--jwt-secrets jwt.hex \
--eth1-endpoints http://localhost:8545,https://third-party.com
# Still works, however only the `192.168.1.1` server will be used.
# The seconds will be ignored.
lighthouse \
bn \
--merge \
--execution-endpoints http://192.168.1.1:8551,http://192.168.1.2:8551 \
--jwt-secrets jwt-1.hex,jwt-2.hex
# These are the minimum ideal flags for the merge.
# The --http flag is also required for staking.
lighthouse \
bn \
--execution-endpoint http://192.168.1.1:8551 \
--execution-jwt jwt.hex
In the penultimate release (v2.3.0), the Docker base image was updated from Ubuntu 20.04 to Ubuntu 22.04 LTS. Older versions of Docker are unable to run the new image due to an incompatibility, so please ensure that you update your Docker engine past version 20.10.10 (released Oct 2021). Please see https://github.com/sigp/lighthouse/issues/3230 for more information.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | Low Priority | Low Priority |
Non-Staking Users | Low Priority | --- |
Please note: this update is high-priority for Prater users.
The Beacon Node may be updated without the Validator Client, however we recommend updating both components.
See Update Priorities for more information about this table.
--network
flag as duplicate of Prater: Option A (#3346)reqwest::Client
between validators when using Web3Signer (#3335)#[derive(Default)]
on enums (#3304)--release
to disallowed-from-async lint (#3325)execution_layer
crate (#3284)cpufeatures
dep optional (#3309)execution_layer
crate (#3257)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v2.4.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.4.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.4.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.4.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.4.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.4.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.4.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.4.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v2.4.0 | sigp/lighthouse |
Published by github-actions[bot] over 2 years ago
This is a release candidate. It is not production-ready and not recommended for mainnet use.
For more information on release candidates, see: https://lighthouse-book.sigmaprime.io/advanced-release-candidates.html
This release-candidate provides the updated total terminal difficulty (TTD) value for the Sepolia testnet. We recommend all users who wish to participate in the Sepolia merge to upgrade to this release.
Users on other networks (Mainnet, Prater, Ropsten, etc) do not need to upgrade to this release.
execution_layer
crate (#3257)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v2.3.2-rc.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.2-rc.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.2-rc.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.2-rc.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.3.2-rc.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.3.2-rc.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.2-rc.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.2-rc.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v2.3.2-rc.0 | sigp/lighthouse |
Published by github-actions[bot] over 2 years ago
This high-priority release contains important bug-fixes and improvements that we recommend for all users.
Notable changes include:
There are no known breaking changes in this release.
In the previous release (v2.3.0), the Docker base image was updated from Ubuntu 20.04 to Ubuntu 22.04 LTS. Older versions of Docker are unable to run the new image due to an incompatibility, so please ensure that you update your Docker engine past version 20.10.10 (released Oct 2021). Please see https://github.com/sigp/lighthouse/issues/3230 for more information.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High Priority | Low Priority |
Non-Staking Users | High Priority | --- |
The Beacon Node may be updated without the Validator Client, however we recommend updating both components.
See Update Priorities for more information about this table.
per_epoch_processing
low-hanging-fruit (#3254)master
branch (#3228)safe_arith
methods (#3229)lcli indexed-attestations
(#3221)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v2.3.1-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.1-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.1-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.1-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.3.1-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.3.1-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.1-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.1-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v2.3.1 | sigp/lighthouse |
Published by github-actions[bot] over 2 years ago
This high priority release contains important bug-fixes and improvements that we recommend for all users. Importantly, fixes are included for the recent 7-block re-org on mainnet. Fast and widespread adoption of this release will help protect the network from repetition of this event.
This release also contains fixes to increase the chances of getting head votes and producing blocks during degenerate scenarios.
Notable changes include:
Accept
header parsing (#3185)Thanks to external contributors @ackintosh, @huitseeker, @zsluedem and @petertdavies. Special shout-out to @tthebst who contributed two important PRs to this release (#3162, #3188).
Use the --network ropsten
flag to join the Ropsten testnet.
This release introduces support for the Ropsten Beacon Chain with the updated total terminal difficulty (TTD) value of 1e32
. We recommend all Ropsten users running v2.3.0-rc.0
to upgrade to this version before the Ropsten beacon chain genesis (less than 12 hours away, at the time of writing).
This release contains a backwards-incompatible database schema migration for any network that has undergone "the merge" (see #3157). At the time of writing, this includes Kiln and Kintsugi but excludes Prater and Mainnet. For clarity:
v2.3.0
are able to downgrade to v2.2.x
and v2.1.x
releases using lighthouse db
v2.3.0
are not able to downgrade to any prior releaseSee the Database Migrations documentation for more information on downgrading.
The Docker base image has been updated from Ubuntu 20.04 to Ubuntu 22.04 LTS. Older versions of Docker are unable to run the new image due to an incompatibility, so please ensure that you update your Docker engine past version 20.10.10 (released Oct 2021). Please see https://github.com/sigp/lighthouse/issues/3230 for more information.
This table provides priorities for which classes of users should update particular components.
User Class | Beacon Node | Validator Client |
---|---|---|
Staking Users | High Priority | Medium Priority |
Non-Staking Users | High Priority | --- |
The Beacon Node may be updated without the Validator Client, however we recommend updating both components.
See Update Priorities for more information about this table.
PayloadIdUnavailable
(#3190)TaskExecutor
to be used in async
tests (#3178)See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key: 15E66D941F697E28F49381F426416DC3F30674B0
System | Architecture | Binary | PGP Signature |
---|---|---|---|
x86_64 | lighthouse-v2.3.0-x86_64-apple-darwin.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.0-x86_64-apple-darwin-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.0-x86_64-unknown-linux-gnu.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.0-x86_64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.3.0-aarch64-unknown-linux-gnu.tar.gz | PGP Signature | |
aarch64 | lighthouse-v2.3.0-aarch64-unknown-linux-gnu-portable.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.0-x86_64-windows.tar.gz | PGP Signature | |
x86_64 | lighthouse-v2.3.0-x86_64-windows-portable.tar.gz | PGP Signature | |
System | Option | - | Resource |
Docker | v2.3.0 | sigp/lighthouse |