# Lighthouse v2.5.0

## Summary

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:

- Add `execution_optimistic` flag to HTTP responses (#3070, #3374)
- Fix slow eth1 cache syncing times (#3358)
- Full support for builder specs v0.2.0 (i.e. `mev-boost` support) (#3134)
- Retrospective verification of optimistically-synced merge transition blocks (#3372)
- Improve peer management when the EL is offline (#3384)

## Breaking Changes

### Breaking Change: Database Migrations

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](https://lighthouse-book.sigmaprime.io/database-migrations.html) documentation for detailed instructions.

### Breaking Change: Addition of `execution_optimistic` flag to HTTP API

The `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](https://ethereum.github.io/beacon-APIs).

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.

#### Example:

// Lighthouse v2.4.0
{ "data": "object" }

// Lighthouse v2.5.0
{ "data": "object", "execution_optimistic": "boolean" }

### Reminder: CLI changes in v2.4.0

The previous release ([v2.4.0](https://github.com/sigp/lighthouse/releases/tag/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](https://github.com/sigp/lighthouse/releases/tag/v2.4.0) to understand these changes.

## Update Priority

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](https://lighthouse-book.sigmaprime.io/installation-priorities.html) for more information about this table.*

## All Changes

* v2.5.0 (#3392)
* Indicate that invalid blocks are optimistic (#3383)
* Enable `count-unrealized` by default (#3389)
* Fix penalties in sync methods (#3384)
* Initial Commit of Retrospective OTB Verification (#3372)
* Builder Specs v0.2.0 (#3134)
* Don't return errors when fork choice fails (#3370)
* Remove equivocating validators from fork choice (#3371)
* Downgrade Geth to v1.10.20 in EE integration tests (#3382)
* Fix antithesis docker builds (#3380)
* Allow setting web3signer version through environment (#3368)
* Return ResourceUnavailable if we are unable to reconstruct execution payloads (#3365)
* Allow syncing or accepted in integration test (#3378)
* Reformat tables and add borders (#3377)
* Fix some typos (#3376)
* Refuse to sign sync committee messages when head is optimistic (#3191)
* Add `is_optimistic` to `eth/v1/node/syncing` response (#3374)
* Strict fee recipient (#3363)
* Add merge transition docs (#3361)
* Fix Block Cache Range Math for Faster Syncing (#3358)
* Realized unrealized experimentation (#3322)
* Add `execution_optimistic` flag to HTTP responses (#3070)