lighthouse 4.4.1 #141543
Merged
lighthouse 4.4.1 #141543
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chenrui333
approved these changes
Sep 6, 2023
|
🤖 An automated task has requested bottles to be published to this PR. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bumpCreated with
brew bump-formula-pr.release notes
lighthouse validator-managercommand 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.--network holesky(#4653).--network chiado(#4530).:lady_beetle: Known Issues :lady_beetle:
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:
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-pointwill heal faster, and we expect the maximum time to heal to be around 8192 slots (~27 hours). The issue is being tracked in sigp/lighthouse#4697.:warning: Breaking Changes :warning:
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-statesflag.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/infoAPI, which will show the value ofstate_upper_limitas18446744073709551615. For more details see #4610, #4663.Breaking Change: Inclusion delay in HTTP rewards API
Support for the
phase0hard fork was added to the attestation rewards API. This required the addition of a new field for theinclusion_delay, which has been standardised upstream inbeacon-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 ACCEPTEDresponse when attempting to publish a block that is already known. This behaviour goes against the currentbeacon-APIsspec, but is likely better for the majority of API consumers. Previously, a400 BAD REQUESTresponse 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 sigp/lighthouse#4655 for details.New HTTP APIs
The Lighthouse BN supports the following new HTTP APIs:
POST /eth/v{1,2}/beacon/blocks(#4479).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.
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
web3signer_teststimeouts (#4662)--guiflag in help text (#4660)ForkChoice: remove an impossible case forparent_checkpoints(#4626)metrics::VALIDATOR_DUTIES_SYNC_HTTP_POSTforpost_validator_duties_sync(#4617)attester_duties: remove unnecessary case (#4614)head_block_rootfield (#4590)maybe_update_best_child_and_descendant: remove an impossible case (#4583)concurrencyproperty to cancel workflows (#4572)init_from_beacon_node(#4613)optional_eth2_network_config(#4611)state.get_validator(#4608)BeaconProcessorfor API requests (#4462)validator-manager(#3502)exchangeTransitionConfigurationfunctionality (#4517)lcli::generate_bootnode_enrand some tests (#4485)--epochs-per-migration(#4236)BeaconProcessorinto a new crate (#4435)Binaries
See pre-built binaries documentation.
The binaries are signed with Sigma Prime's PGP key:
15E66D941F697E28F49381F426416DC3F30674B0