Skip to content

Releases: sigp/lighthouse

Previous Leon

04 Sep 07:29
v4.4.1
Compare
Choose a tag to compare

Summary

This is a low-priority release. It contains several minor bug fixes and performance improvements which we recommend rolling out on mainnet nodes at your convenience. This release also includes support for the Holešky testnet, with genesis on 15 September 2023.

Note that there is no v4.4.0 release due to a bug found late in the release cycle. The bug was fixed in PR #4687, which is included in this release.

The highlights of v4.4.1 are:

  • [NEW] Introduction of the lighthouse validator-manager command for managing validators on a running validator client. Documentation can be found in a new chapter of the Lighthouse book: https://lighthouse-book.sigmaprime.io/validator-manager.html.
  • Improved scheduling for HTTP requests (#4462). Lighthouse will now balance the load of HTTP requests against other important duties, and avoid becoming overwhelmed. We hope that this improves stability for nodes supporting a large number of validators or processing frequent HTTP queries.
  • Disk space savings for new nodes through state pruning (#4610, #4663).
  • Bugfix for backfill sync erroring upon completion (#4465).
  • Support for the Holešky testnet via --network holesky (#4653).
  • Support for the Chiado Gnosis testnet via --network chiado (#4530).

🐞 Known Issues 🐞

We have identified a minor bug in the code related to state pruning that can cause an error message to be logged for a limited time after upgrading:

ERRO Missing chunk in forwards iterator

It can be safely ignored, as it does not impact the node's ability to follow the chain or perform validator duties. However, API queries for historic blocks & states may fail until the issue resolves itself. This only affects nodes with an existing database. Nodes with lower --slots-per-restore-point will heal faster, and we expect the maximum time to heal to be around 8192 slots (~27 hours). The issue is being tracked in #4697.

⚠️ Breaking Changes ⚠️

Breaking Change: State pruning for new nodes

Newly synced nodes will no longer store historic states by default. This applies both to checkpoint sync and genesis sync. Node operators may opt-in to historic state storage by reconstructing states with the --reconstruct-historic-states flag.

Existing nodes will continue storing historic states newer than the checkpoint from which they synced. We are working on a command to prune historic states from existing nodes, which will likely be available in the next release.

The pruned status of a node can be determined using the /lighthouse/database/info API, which will show the value of state_upper_limit as 18446744073709551615. For more details see #4610, #4663.

Breaking Change: Inclusion delay in HTTP rewards API

Support for the phase0 hard fork was added to the attestation rewards API. This required the addition of a new field for the inclusion_delay, which has been standardised upstream in beacon-APIs: https://ethereum.github.io/beacon-APIs/#/Rewards/getAttestationsRewards.

See #4474, #4520 for details.

Breaking Change: HTTP status code for duplicate blocks

Lighthouse will now return an HTTP 202 ACCEPTED response when attempting to publish a block that is already known. This behaviour goes against the current beacon-APIs spec, but is likely better for the majority of API consumers. Previously, a 400 BAD REQUEST response could cause the caller (usually a validator client) to think that block publication had failed when it had not. We have begun a discussion to change the spec to allow the new error code.

The status code can also be set to a custom value using the flag --http-duplicate-block-status. See #4655 for details.

New HTTP APIs

The Lighthouse BN supports the following new HTTP APIs:

  • SSZ variant of POST /eth/v{1,2}/beacon/blocks (#4479).
  • SSZ variant of POST /eth/v{1,2}/beacon/blinded_blocks (#4504).
  • POST /eth/v1/validator/liveness/{epoch} (#4343).
  • GET /eth/v1/builder/states/{state_id}/expected_withdrawals (#4390).

Update Priority

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

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

See Update Priorities more information about this table.

The Beacon Node may be updated without also updating the Validator Client. However we recommend upgrading both components for consistency.

All Changes

  • Release v4.4.1 (#4690)
  • Remove double-locking deadlock from HTTP API (#4687)
  • Release v4.4.0 (#4673)
  • Pin foundry toolchain version to fix stuck CI jobs
  • feat: add chiado (#4530)
  • Fix bug in block root storage (#4663)
  • Add Holesky (#4653)
  • Increase web3signer_tests timeouts (#4662)
  • Show --gui flag in help text (#4660)
  • Do not log slot clock error prior to genesis (#4657)
  • Send success code for duplicate blocks on HTTP (#4655)
  • update dependencies (#4639)
  • rust 1.72 lints (#4659)
  • Use lockfile with cross and fix audit fail (#4656)
  • Revive mplex (#4619)
  • Implement expected withdrawals endpoint (#4390)
  • Remove Antithesis docker build workflow (#4642)
  • Fix the link of anvil in lighthouse book (#4641)
  • Fix beacon-processor-max-workers (#4636)
  • ForkChoice: remove an impossible case for parent_checkpoints (#4626)
  • Remove checkpoint alignment requirements and enable historic state pruning (#4610)
  • Fix Prefer Builder Flag (#4622)
  • Update blst to 0.3.11 (#4624)
  • add metrics::VALIDATOR_DUTIES_SYNC_HTTP_POST for post_validator_duties_sync (#4617)
  • attester_duties: remove unnecessary case (#4614)
  • Don't kill SSE stream if channel fills up (#4500)
  • Fix disable backfill flag not working correctly (#4615)
  • Improve HTTP API error messages + tweaks (#4595)
  • ForkChoice: remove head_block_root field (#4590)
  • opt maybe_update_best_child_and_descendant: remove an impossible case (#4583)
  • Use the native concurrency property to cancel workflows (#4572)
  • Fix bug of init_from_beacon_node (#4613)
  • use account_manager::CMD instead of magic string (#4612)
  • remove optional_eth2_network_config (#4611)
  • minor optimize process_active_validator: avoid a call to state.get_validator (#4608)
  • align editorconfig with rustfmt (#4600)
  • Fix some typos (#4565)
  • Improve transport connection errors (#4540)
  • Use BeaconProcessor for API requests (#4462)
  • Add validator-manager (#3502)
  • Increase slashing protection test SQL timeout to 500ms (#4574)
  • Support SSZ request body for POST /beacon/blinded_blocks endpoints (v1 & v2) (#4504)
  • Update doppelganger note about sync committee contributions (#4425)
  • Shift networking configuration (#4426)
  • CommitteeCache.get_all_beacon_committees: set correct capacity to avoid realloc (#4557)
  • CommitteeCache.initialized: fail early if possible (#4556)
  • fix typo (#4555)
  • upgrade to libp2p 0.52 (#4431)
  • Deprecate exchangeTransitionConfiguration functionality (#4517)
  • Update Lighthouse book FAQ (#4510)
  • add ssz support in request body for /beacon/blocks endpoints (v1 & v2) (#4479)
  • Development feature flag - Disable backfill (#4537)
  • Add Eth Version Header (#4528)
  • Fix incorrect ideal rewards calculation (#4520)
  • Fix bug in lcli transition-blocks and improve pretty-ssz (#4513)
  • Restore upstream arbitrary (#4372)
  • Implement liveness BeaconAPI (#4343)
  • Add self-hosted runners v2 (#4506)
  • Phase 0 attestation rewards via Beacon API (#4474)
  • Cleanup unreachable code in lcli::generate_bootnode_enr and some tests (#4485)
  • Speed up CI by installing foundry with Github action (#4505)
  • Rust 1.71 lints (#4503)
  • CI fix: add retries to eth1 sim tests (#4501)
  • Clean up local testnet files without prompting (#4498)
  • Remove wget dependency (#4497)
  • Update mev-rs and remove patches (#4496)
  • Remove instances of required arguments with default values (#4489)
  • Use unique arg names for eth1-sim (#4463)
  • Fix HTTP state API bug and add --epochs-per-migration (#4236)
  • bump proc-macro2 (#4464)
  • Remove hidden re-exports to appease Rust 1.73 (#4495)
  • Add state-root command and network support to lcli (#4492)
  • Move the BeaconProcessor into a new crate (#4435)
  • Bump default checkpoint sync timeout to 3 minutes (#4466)
  • Correct checks for backfill completeness (#4465)

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-v4.4.1-x86_64-apple-darwin.tar.gz PGP Signature
x86_64 lighthouse-v4.4.1-x86_64-apple-darwin-portable.tar.gz PGP Signature
<img src="https://simpleicons.org/icons/linux.svg" style="w...
Read more

Priest Witherspoon

05 Jul 01:47
v4.3.0
Compare
Choose a tag to compare

Summary

This is a low-priority release for Mainnet, Goerli and Sepolia users. However, this release schedules the Capella upgrade for Gnosis (#4433) on UTC Tue 01/08/2023, 11:34:20, therefore this release is high-priority for Gnosis users.

For all networks, this release contains new features, bug-fixes and optimisations including:

  • Add Sigma Prime IPv6 boot nodes (#4394)
  • Implement broadcast_validation APIs (#4316)
  • Schedule Capella for Gnosis chain (#4433)
  • Significantly reduce bandwidth by ignoring "aggregate subsets" (#3493)
  • Reduced bandwidth for nodes running multiple validators by subscribing to less subnets (#4304)
  • Allow setting validator graffiti via PATCH lighthouse/validators/{validator_pubkey} (#4417)
  • Add a CLI flag for the builder validator/register_validator batch size (#4399)
  • Re-enable maxperf for Windows releases (#4371)
  • Enable slasher broadcast by default (#4368)
  • Downgrade a CRIT log in the VC for builder timeouts (#4366)
  • Switch default slasher backend to LMDB (#4360)

Bandwidth Reductions

There are two major reductions to bandwidth use in this release. The first change in #3493 benefits all nodes, and works by ignoring redundant attestation aggregates received via gossip. This brings Lighthouse to parity with other clients which had already implemented this change.

The second change in #4304 overhauls the handling of attestation subnet subscriptions. Previously Lighthouse would subscribe to 1 attestation subnet for each connected validator, up to the total of 64. Now, every Lighthouse node will subscribe to 2 subnets total. For nodes with 0-2 validators, this is a minor change, while for nodes with multiple validators this represents a significant reduction.

Large staking operators who are accustomed to being subscribed to all subnets may want to opt back in using the --subscribe-all-subnets flag. Although this increases bandwidth significantly, it also improves block rewards by a few percent, and can provide stability for the node and the network.

Breaking Changes

The breaking changes in this release only apply to users who use the --slasher flag.

Breaking Change: Enable Slasher Broadcasting by Default

Lighthouse will now set --slasher-broadcast true by default. This only applies to users who run with the --slasher flag and means that any slashings detected will be broadcast to the network immediately.

Previously, Lighthouse would store the slashing privately in the hope that it may include it in a block of its own. Whilst this behaviour is profit-maximising, it is only effective if there are no slashers on the network running with --slasher-broadcast true. In practice we've observed that almost all slashings are immediately broadcast, so the profit-maximising strategy is unlikely to yield any additional rewards. Broadcasting by default prioritises network health and resilience, and we recommend that users switch from profit-maximising to broadcasting.

The old behaviour can be achieved with --slasher-broadcast false.

Breaking Change: Use LMDB for the Default Slasher Backend

The default slasher backend has been changed back to LMDB. This only applies to users who run with the --slasher flag.

If an MDBX database exists and the MDBX backend is enabled then MDBX will continue to be used. Our release binaries and Docker images will continue to include MDBX for as long as it is practical, so users of these should not notice any difference.

The main benefit is for users compiling from source. These users no longer have to struggle to compile MDBX and deal with the compatibility issues that arise.

Update Priority

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

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

See Update Priorities more information about this table.

This release is high-priority for Gnosis users. Gnosis users must update both the Beacon Node and Validator Client.

For mainnet users, the Beacon Node may be updated without also updating the Validator Client. However we recommend upgrading both components for consistency.

All Changes

  • Release v4.3.0 (#4452)
  • Ipv6 bootnodes update (#4394)
  • Cache target attester balances for unrealized FFG progression calculation (#4362)
  • Update node health endpoint (#4310)
  • added debounce to log (#4269)
  • Add broadcast validation routes to Beacon Node HTTP API (#4316)
  • avoid relocking head during builder health check (#4323)
  • Schedule Capella for Gnosis chain (#4433)
  • Tidy formatting of Reqwest errors (#4336)
  • Aggregate subsets (#3493)
  • Bump openssl deps (#4421)
  • Add lint-fix task to automatically fix some Clippy warnings. (#4419)
  • Add support for updating validator graffiti (#4417)
  • Configure the validator/register_validator batch size via the CLI (#4399)
  • Update Lighthouse book on Doppelganger Protection (#4418)
  • Remove legacy max-skip-slots checks (#4403)
  • Improve ENR logic for ipv6 (#4395)
  • Correct table formatting in Lighthouse book (#4407)
  • Remove CountUnrealized (#4357)
  • Use JSON by default for Deposit Snapshot Sync (#4397)
  • Rework internal rpc protocol handling (#4290)
  • Re-enable maxperf for Windows releases (#4371)
  • Minor revision in Lighthouse book (#4385)
  • Use MediaType accept header parser (#4216)
  • Update discv5 to expand ipv6 support (#4319)
  • Enable slasher broadcast by default (#4368)
  • Fix Anvil compilation on Windows (#4381)
  • feat: added new info about logs and config features (#4378)
  • Downgrade a CRIT in the VC for builder timeouts (#4366)
  • Switch default slasher backend to LMDB (#4360)
  • Always log the value of relay and local blocks for comparison (#4352)
  • Appease clippy in Rust 1.70 (#4365)
  • Update Nethermind (#4361)
  • Add an option to disable inbound rate limiter (#4327)
  • Expose execution block hash calculation (#4326)
  • Update Lighthouse Book API and Advanced Usage section (#4300)
  • Addition to Lighthouse Book faq.md (#4273)
  • Fix libpq typo in beacon.watch README (#4356)
  • Remove unused crate publishing Github action and script (#4347)
  • Add SSH tunneling in Lighthouse UI Siren (#4328)
  • Shift subnet backbone structure (attnets revamp) (#4304)
  • Add libpq-dev and docker to the to the list of additional requirements for developers in the Book (#4282)
  • Fix Rust 1.71.0 warnings (#4348)
  • Fix geth scripts (#4342)
  • swap unnecessary write lock to read lock in block_verification (#4340)
  • Add db inspect --output values option to support dumping raw db values (#4324)
  • Update blog link in README (#4322)
  • chore: Bellatrix occurred for Gnosis (#4301)
  • Keep payload cache idempotent (#4256)

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-v4.3.0-x86_64-apple-darwin.tar.gz PGP Signature
x86_64 lighthouse-v4.3.0-x86_64-apple-darwin-portable.tar.gz PGP Signature
x86_64 lighthouse-v4.3.0-x86_64-unknown-linux-gnu.tar.gz PGP Signature
x86_64 lighthouse-v4.3.0-x86_64-unknown-linux-gnu-portable.tar.gz PGP Signature
aarch64 lighthouse-v4.3.0-aarch64-unknown-linux-gnu.tar.gz PGP Signature
aarch64 lighthouse-v4.3.0-aarch64-unknown-linux-gnu-portable.tar.gz PGP Signature
x86_64 lighthouse-v4.3.0-x86_64-windows.tar.gz PGP Signature
<img src="h...
Read more

EXPERIMENTAL Tree States v4.2.990

27 Jun 11:14
v4.2.990-exp
6954de6
Compare
Choose a tag to compare
Pre-release

Disclaimer

⚠️ 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.

Summary

This is an alpha release of upcoming changes to Lighthouse which improve disk usage and state management.

For more information about this family of releases, please see the v3.4.0-tree.1 release notes.

Compared to the previous release the main changes are:

  • Capella support
  • Freezer database rewritten to use hierarchical diffs (even lower disk usage, around 100 GiB for an archive node)

⚠️ Backwards Compatibility ⚠️

This release is not backwards compatible with stable Lighthouse or prior tree-states releases. It uses a different database schema (v23) 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.

There are several breaking changes to CLI flags:

  • The secret dummy flag --unsafe-and-dangerous-mode must be supplied. This is to prevent accidental upgrades to the release by users who don't know what they're getting themselves into. Unfortunately we found that far too many people accidentally ran previous tree-states releases on mainnet.
  • The flags --slots-per-restore-point and --historic-state-cache-size are deprecated and no longer necessary due to the freezer database using hierarchical diffs.

Known Issues

Expect a few sharp edges. Some things you may run into:

  • aarch64 (ARM) support is currently broken. As a result there are no binaries for ARM.
  • The Docker image on DockerHub is for x86_64/modern CPUs only. It was built manually to work around the ARM issue.
  • WARN Parent state is not advanced is logged excessively during sync. This is harmless, albeit annoying.
  • Block processing is a bit slower than stable Lighthouse.

If you observe any panics, crashes or major performance regressions, please open an issue!

Building from source

Build the v4.2.990-exp tag.

Binaries

See pre-built binaries documentation.

A Docker image for x86_64 only is available on DockerHub as sigp/lighthouse:v4.2.990.

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

Fast Aging Alien

23 May 06:04
v4.2.0
Compare
Choose a tag to compare

Summary

This is a medium-priority release for Mainnet users. It contains important improvements to the resilience of Lighthouse, however there is no immediate urgency to upgrade.

Users who connect their VC to multiple BNs will have reduced risk of missed attestations and orphaned blocks when there is an offline EE (#4295).

Support for "proposer-only" BNs has been added to Lighthouse. Although we don't recommend this functionality for most stakers, it may be useful for enterprise operations or in the case of a large-scale attack on Ethereum. Read about this advanced feature in the documentation.

This release contains many notable features, optimisations and bug fixes:

  • Add a lighthouse/logs SSE endpoint to the VC API to expose logging (#4074)
  • Update Gnosis Capella preset (#4302)
  • Update Sepolia bootnodes (#4297)
  • Prioritise the head state in the shuffling cache (#4296)
  • Improve VC fallback behaviour when an EE is offline (#4295)
  • Add a flag for storing invalid blocks as SSZ files (#4194)
  • Fix bug with attestation verification on fork boundaries (#4263)
  • Reduce bandwidth over the VC<>BN API using dependant roots (#4170)
  • Fix bug when computing withdrawals root (#4249)
  • Backfill blocks only to the WSP by default (#4082)
  • Massively improve historic state lookup performance via the API (#4228)
  • Enable build profiles for Docker source builds (#4237)
  • Prevent disconnection from trusted peers (#4159)
  • Provide support for "proposer-only" BNs to mitigate targeted DoS attacks (#4182)
  • Add attestation inclusion distance to the HTTP API (#4148)

Breaking Changes

Breaking Change: Database Schema V17

To reduce complexity in the fork choice algorithm, the database schema has been upgraded to v17 (#4265). 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 at any time.

Breaking Change: Backfilling

After a checkpoint sync, Lighthouse will only backfill to the most recent weak subjectivity checkpoint unless the --genesis-backfill flag is provided (#4082). The previous behaviour was to always backfill to the genesis block.

The --genesis-backfill flag is not required for staking. Nodes performing "archive" duties may wish to add this flag so they may download and store the entire history of the chain.

Omitting the --genesis-backfill flag for new BN databases will result in reduced disk usage and reduced network bandwidth during sync. Nodes which are already synced to genesis will maintain their history, even if the --genesis-backfill flag is not present. In a future release we will enable existing nodes to prune old blocks from their database so that they can achieve reduced disk usage without a re-sync.

Breaking Change: Graceful Handling of Offline EEs

The Lighthouse VC will now detect when the BN indicates that its EE (e.g., Geth, Nethermind, Besu, Erigon, etc) is offline. The VC will then prefer a BN with an online EE (#4295).

This functionality is only possible when the VC has multiple (aka "fallback") BNs provided via the --beacon-nodes flag.

If there is no alternative BN with an online EE, the VC will go back to the previous behaviour of attempting to perform its duties regardless of the EE status.

Breaking Change: Updated LLVM Version

Windows users may fail to compile Lighthouse if their LLVM version is earlier than 15.0 (#4220). Upgrading can typically be achieved with choco upgrade llvm.

Update Priority

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

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

See Update Priorities more information about this table.

The Beacon Node may be updated without also updating the Validator Client. However we recommend upgrading both components for consistency.

All Changes

  • v4.2.0 (#4309)
  • Logging via the HTTP API (#4074)
  • Avoid excessive logging of BN online status (#4315)
  • Update gnosis capella preset (#4302)
  • add more sepolia bootnodes (#4297)
  • Add more metrics for tracking sync messages (#4308)
  • Enshrine head state shuffling in the shuffling_cache (#4296)
  • Implement el_offline and use it in the VC (#4295)
  • Fix PERSIST_ETH1_CACHE / PERSIST_OP_POOL Metrics (#4278)
  • Post merge local testnets (#3807)
  • Remove redundant gossipsub tests (#4294)
  • Don't requeue already-known RPC blocks (#4214)
  • Add a flag for storing invalid blocks (#4194)
  • Replace ganache-cli with anvil (#3555)
  • DB migration for fork choice cleanup (#4265)
  • Attestation verification uses head state fork (#4263)
  • Reduce bandwidth over the VC<>BN API using dependant roots (#4170)
  • Update links in Lighthouse Book (#4279)
  • Fix attestation withdrawals root mismatch (#4249)
  • Fix log on initializing external block builder (#4267)
  • Add branching instructions to the contribution guide (#4272)
  • Do not attempt to resubscribe to core topics (#4271)
  • Backfill blocks only to the WSP by default (#4082)
  • improve api-bn.md (#4244)
  • use state cache to optimise historical state lookup (#4228)
  • Update Lighthouse book Sec 3-6 and FAQ (#4221)
  • simplify calculate_committee_fraction (#4213)
  • Update igd to v0.12.1 (#4257)
  • Un-deprecate test utils functions such as extend_chain (#4255)
  • Enable build profiles for Docker source builds (#4237)
  • Maintain trusted peers (#4159)
  • Prepare CI for merge queues (#4252)
  • remove withdrawal warning (#4207)
  • Logfile no restrict help text for windows (#4165)
  • Feat: lighthouse book - ui authentication (#4232)
  • Split common crates out into their own repos (#3890)
  • Separate BN for block proposals (#4182)
  • add attestation inclusion distance in http api (#4148)
  • Fix Rust 1.69 lints (#4222)
  • Update LLVM version to 15.0 in CI workflows (#4220)

Binaries

See pre-built binaries documentation.

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

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

Uncle Steve

20 Apr 05:24
v4.1.0
Compare
Choose a tag to compare

Summary

This is a high-priority release for Mainnet users. It fixes an issue which caused excessive CPU usage shortly after the Mainnet Capella upgrade (#4183).

Users on v4.0.1 or earlier should upgrade as soon as possible. This release is less important for users already running v4.0.2-rc.0; that release already contains an effective fix. However the fix in this release is more accurate so we recommend that v4.0.2-rc.0 users upgrade to this release at their next convenience.

We expect the conditions that caused excessive CPU usage are unlikely to return, however we recommend users upgrade to bolster the resilience of the Ethereum network.

This release also contains new improvements that were not present in v4.0.1 or v4.0.2-rc.0:

  • The /eth/v1/debug/fork_choice HTTP endpoint was added (#4003)
  • The PATCH lighthouse/validators/{pubkey} endpoint has been optimised (#4126)
  • The HTTP API has been updated to include references to the finalized checkpoint (#3753)
  • Backfilling has been rate-limited to mitigate validator performance issues after a recent checkpoint sync. The old behaviour can be obtained with the --disable-backfill-rate-limiting flag (#3936)
  • The Lighthouse VC can now create signed voluntary exit messages via the HTTP API (#4119)
  • The --disable-peer-scoring flag has been added for developer usage (#4135)
  • The proposer boost re-orging strategy is now configurable and more cautious by default (#4151)
  • Payload reconstruction via the HTTP API now uses the dedicated EE endpoint, addressing an issue with Erigon compatibility (#4102)
  • Lighthouse now supplies a user-agent to builders (#4199)

With this release we are also encouraging users to re-enable mev-boost and re-orgs if they had previously disabled them. The latency issues with the MEV relays have resolved, and re-orgs should be more reliable now that improvements to gossip have been rolled out by other clients. If you experience a missed block or failed re-org running Lighthouse v4.1.0 please reach out.

Compiling from Source

Users who compile from source should ensure they update Rust and checkout and pull the stable branch before building:

  • Most users can update Rust with rustup update
  • Checkout and pull the stable branch with git checkout stable && git pull

Breaking Changes

Breaking Change: Minimum Supported Rust Version 1.68.2

The minimum supported Rust version has been set to 1.68.2 to address a serious bug in prior Rust releases (see #4204 for more information).

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.1.0 (/home/karlm/lighthouse/lighthouse)` cannot be built because it requires rustc 1.68.2 or newer

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

Breaking Change: New Fields Added to HTTP API Responses

The HTTP API has been updated to include references to the finalized checkpoint (#3753).

This aligns Lighthouse with the standard BeaconAPIs, which added these fields in ethereum/beacon-APIs#254.

Update Priority

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 Medium ---

See Update Priorities more information about this table.

The Beacon Node may be updated without also updating the Validator Client. However we recommend upgrading both components for consistency.

All Changes

  • Release v4.1.0 (#4191)
  • Check lateness of block before requeuing it (#4208)
  • Bump Rust version (MSRV) (#4204)
  • Set user agent on requests to builder (#4199)
  • Use efficient payload reconstruction for HTTP API (#4102)
  • Address observed proposers behaviour (#4192)
  • Use head state for exit verification (#4183)
  • Update Lighthouse book and some FAQs (#4178)
  • Avoid processing redundant RPC blocks (#4179)
  • Make re-org strat more cautious and add more config (#4151)
  • Remove Redundant Trait Bound (#4169)
  • Remove the unused ExecutionOptimisticForkVersionedResponse type (#4160)
  • Add a flag to disable peer scoring (#4135)
  • CI fix: move download web3signer binary out of build script (#4163)
  • Add beacon.watch (#3362)
  • remove dup log (#4155)
  • Ban peer race condition (#4140)
  • Add new validator API for voluntary exit (#4119)
  • Rate limiting backfill sync (#3936)
  • Update database-migrations.md (#4149)
  • update README of local_testnet (#4114)
  • Test failing CI tests due to port conflicts (#4134)
  • Add finalized to HTTP API responses (#3753)
  • Correct log for ENR (#4133)
  • Optimise update_validators by decrypting key cache only when necessary (#4126)
  • Add debug fork choice api (#4003)
  • improve error message (#4141)
  • Update Rust version in lcli Dockerfile (#4121)
  • Update arbitrary (#4139)

Binaries

See pre-built binaries documentation.

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

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

Goddess Beth

13 Apr 01:03
v4.0.2-rc.0
35d8c98
Compare
Choose a tag to compare

Summary

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.

Building from Source

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).

Breaking Changes

There are no breaking changes in this release.

Update Priority

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.

All Changes

  • Bump versions
  • Empty commit
  • Use head state for exit verification

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-v4.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

Campaign Manager Morty

27 Mar 05:20
v4.0.1
Compare
Choose a tag to compare

Summary

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:

  • Improve the resilience of the fork choice algorithm (#3962)
  • Add a flag to speed up responses to the committees HTTP API (#4081)
  • Improve payload reconstruction by utilising a new execution engine API endpoint (#4028)
  • Reduce false-positive ERRO logs claiming that builder blocks were published late (#4073)
  • Fix a bug that resulted in a harmless ERRO Dialing an already dialing peer log (#4056)
  • Add support for IPv6 (#4046)

v4.0.0 Release Retracted

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:

  • Any node running v4.0.0 should immediately upgrade to this release since v4.0.0 is not reliable.
  • Any node running v4.0.1-rc.0 may choose to continue on that release or upgrade to this release. This release and the rc.0 release are functionally identical.
  • Any node running v3.5.1 or earlier should upgrade to this release at their next convenience (certainly before the Capella upgrade).

These release notes have been written with respect to v3.5.1 rather than the previous retracted release of v4.0.0.

Mainnet Capella/Shanghai ("Shapella") Upgrade

The Capella/Shanghai ("Shapella") upgrade will occur on mainnet at:

  • Epoch 194048
  • April 12, 2023, 10:27:35pm UTC

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:

  • Upgrade their Lighthouse BN(s) to a v4.x.x release.
  • Upgrade their Lighthouse VC(s) to v4.x.x release.
  • Upgrade their Execution Engine(s) to a Shanghai-ready release:

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.

🐛 Known Issues 🐛

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: erigontech/erigon#7172.

Breaking Changes

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.

Breaking Change: Database Schema V16

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.

Breaking Change: Minimum Supported Rust Version 1.66

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.

Update Priority

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.

All Changes

  • Release v4.0.1 (#4125)
  • Release Candidate v4.0.1-rc.0 (#4123)
  • Fix fork choice error message (#4122)
  • Release v4.0.0 (#4112)
  • Fork choice modifications and cleanup (#3962)
  • Set Capella fork epoch for Mainnet (#4111)
  • Reduce verbosity of reprocess queue logs (#4101)
  • Customisable shuffling cache size (#4081)
  • Improve Lighthouse Connectivity Via ENR TCP Update (#4057)
  • Ignore self as a bootnode (#4110)
  • Reconstruct Payloads using Payload Bodies Methods (#4028)
  • Clarify "Ready for Capella" (#4095)
  • Reduce false positive logging for late builder blocks (#4073)
  • Make more noise when the EL is broken (#3986)
  • Siren Ui Lighthouse Version Requirments (#4093)
  • Correct a race condition when dialing peers (#4056)
  • Remove Router/Processor Code (#4002)
  • Complete match for has_context_bytes (#3972)
  • Add parent_block_number to payload SSE (#4053)
  • Support for Ipv6 (#4046)
  • Correct /lighthouse/nat implementation (#4069)
  • Added warning when new jwt is generated (#4000)
  • Appease Clippy 1.68 and refactor http_api (#4068)
  • Fix order of arguments to log_count (#4060)

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-v4.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
<img src="https://...
Read more

Tophat Jones

23 Mar 11:34
v4.0.1-rc.0
b2525d6
Compare
Choose a tag to compare
Tophat Jones Pre-release
Pre-release

🚨 Hot-Fix for v4.0.0 🚨

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):

  • If you have not upgraded to v4.0.0 and are on v3.5.1, then take no action. Do not upgrade to v4.0.0 or v4.0.1-rc.0.
  • If you have already upgraded to v4.0.0, then upgrade to v4.0.1-rc.0 immediately.

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.

All Changes

  • Release Candidate v4.0.1-rc.0 (#4123)
  • Fix fork choice error message (#4122)

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-v4.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

Tumblorkians

07 Mar 23:17
v3.5.1
Compare
Choose a tag to compare

Summary

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:

  • Add a flag to always use payloads from builders (#4052)
  • Set Capella fork epoch for Goerli (#4044)
  • Optimise signing in the VC to prevent late blocks (#4033)
  • Add a BN latency measurement to the VC to help diagnose late blocks (#4024, #4051)
  • Fix a bug where Lighthouse rejects an invalid block message from the EE (#4037)
  • Delete Kiln and Ropsten configs (#4038)
  • Improve compilation flexibility by allowing building without MDBX (#3888)

Breaking Changes

There are no breaking changes that affect Mainnet users.

⚠️ Breaking Change: Removal of Kiln and Ropsten Configs ⚠️

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 Capella Hard Fork

Goerli is upgrading to Capella on 14/03/2023 at 10:25:36 pm UTC! :tada:

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.

VC to BN Latency Measurements

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]))

Known Issues

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 #3964 for details.

Update Priority

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.

All Changes

  • Release v3.5.1 (#4049)
  • Add a flag to always use payloads from builders (#4052)
  • Set Capella fork epoch for Goerli (#4044)
  • Add VC metric for primary BN latency (#4051)
  • Log a WARN in the VC for a mismatched Capella fork epoch (#4050)
  • Update dependencies incl tempfile (#4048)
  • Optimise attestation selection proof signing (#4033)
  • Optimise payload attributes calculation and add SSE (#4027)
  • Add latency measurement service to VC (#4024)
  • Permit a null LVH from an INVALID response to newPayload (#4037)
  • Log a debug message when a request fails for a beacon node candidate (#4036)
  • Cleaner logic for gossip subscriptions for new forks (#4030)
  • Delete Kiln and Ropsten configs (#4038)
  • Clean capella (#4019)
  • Add more logs in the BN HTTP API during block production (#4025)
  • Docs for Siren (#4023)
  • Use consensus-spec-tests v1.3.0-rc.3 (#4021)
  • Add content-type header to metrics server response (#3970)
  • Allow compilation with no slasher backend (#3888)
  • Execution Integration Tests Correction (#4034)

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-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

Gazorpazorpfield

23 Feb 00:07
v3.5.0
Compare
Choose a tag to compare

Summary

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:

  • ⚠️ Database schema upgrade to v15 ⚠️
  • HTTP API returns 404 rather than 405 for an unknown route (#3836)
  • Add CLI flag to specify the format of logs written to the logfile (#3839)
  • Switch allocator to jemalloc (#3697)
  • Implement new rewards APIs (#3822, #3903, #3907)
  • Add attestation duty slot metric (#2704)
  • Reduce some EE and builder related ERRO logs to WARN (#3966)
  • Use Local Payload if More Profitable than Builder (#3934)

Breaking Changes

⚠️ Breaking Change: Database Schema v15 ⚠️

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.

⚠️ Breaking Change: Minimum Supported Rust Vesion ⚠️

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.

Breaking Change: HTTP API Unknown Routes

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 Capella Hard Fork

Sepolia is upgrading to Capella on 2023/2/28 at 4:04:48 AM UTC! :tada:

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.

Known Issues

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 #3964 for details.

Update Priority

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.

All Changes

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.

Binaries

See pre-built binaries documentation.

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

System Architecture Binary PGP Signature
x86_64 lighthouse-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