Conversation
Member
|
CI is failing. You can check for lints with |
chong-he
added
waiting-on-author
Author
mergify
Bot
added
ready-for-review
## Description After a restart, a Lighthouse node can fail to resume syncing on a Gloas network. This can happen when the node persists a Gloas beacon block before it fully imports the payload envelope. A restart then clears the in-memory pending payload cache. Sync downloads the envelope and custody columns for the block again, but reprocessing the known block does not restore its signed execution payload bid. Lighthouse cannot join the downloaded components, and the lookup can run out of attempts. Dependent blocks then stop progressing. Custody-column and execution-proof processing now load the bid from the persisted block when the cache is empty. Envelope processing reuses the bid from the block that it already loaded.
## Issue Addressed Part of FOCIL (EIP-7805). This puts the inclusion list store from sigp#9744 onto `BeaconChain` and adds the read wrappers that will be used by gossip verification, fork-choice enforcement, and block production. ## Proposed Changes * Add an `inclusion_list_store` field to `BeaconChain`, initialise it from `ChainSpec` in `builder.rs`, and prune it in `per_slot_task`. * Add `inclusion_list_committee`, which resolves the ordered committee for a slot and returns it together with the dependent root used to key the store. * Add `get_inclusion_list_transactions`, `get_inclusion_list_bits`, and `is_inclusion_list_bits_inclusive` as wrappers around the store reads. * Add `BeaconChainError::InclusionListStoreError`. * Add tests covering each read path, the epoch boundary case, and pruning through `per_slot_task`. This is independent of sigp#9846, and nothing is calling these wrappers yet. Gossip verification will be the follow-up. ## Additional Info The wrappers take an anchor block root rather than using the head. `with_committee_cache` only resolves a block's own or next epoch shuffling, while inclusion list reads use `slot - 1`. Once per epoch, that falls into the previous epoch and fails when using the head root. There's a test covering this case. `with_committee_cache` already gives us the attester shuffling decision root, so we get both the committee and the store key from the same lookup. This is also the root that the producer puts in the message as `dependent_root`. `get_inclusion_list_transactions` only needs to resolve the shuffling for the dependent root and then discards the committee, since that root comes out of the same lookup. Co-authored-by: Eitan Seri- Levi <eserilev@gmail.com>
## Issue Addressed Part of FOCIL (EIP-7805). This adds `engine_newPayloadV6`, as specified in [Bogota](https://github.com/ethereum/execution-apis/blob/main/src/engine/bogota.md). ## Proposed Changes * Add `ENGINE_NEW_PAYLOAD_V6` and the `new_payload_v6` capability. * Add `inclusion_list_transactions` to `NewPayloadRequestHeze`. * Add `new_payload_v6_heze` and dispatch Heze requests to it. * Add `inclusion_list_satisfied` to `PayloadStatusV1` for the new `inclusionListSatisfied` response field. * Route the method in the mock EL, and fix its Heze fork check, which required V5. * Add tests for deserialising the response with and without `inclusionListSatisfied`. Nothing constructs a `NewPayloadRequestHeze` yet, so this doesn't change any behaviour. I also cleaned up the two now stale `TODO(heze)`s. ## Additional Info I kept `inclusion_list_satisfied` on `PayloadStatusV1` rather than introducing a `PayloadStatusV2`. The new field is `BOOLEAN|null`, and the existing fields already use `Option` for the same reason. The alternative would be to introduce a versioned superstruct like `PayloadAttributes`, but that would mean making changes outside `execution_layer`. I'm fine with going that way if that's preferred. The Heze arm in `payload_notifier.rs` will need the transactions from the store. That part follows once sigp#9960 merges.
…API 5/5) (sigp#9807) Final PR of the Gloas builder API stack: - sign builder request-auth and preferences (REQUEST_AUTH signing domain, web3signer message type) - add the builder configuration store (`builder_definitions.yml`) and book documentation - add the builder-preferences service and switch block production to `POST` produceBlockV4 with a `BuilderConfig` body, threading the `Eth-Builder-Url` header through block publication - remove the now-unused legacy `GET` produceBlockV4 client methods
## Description Adds the per-validator builder configuration endpoints from [ethereum/keymanager-APIs#88](ethereum/keymanager-APIs#88). - `GET /eth/v1/validator/{pubkey}/builder_config` returns the configuration in use for the validator. - `POST /eth/v1/validator/{pubkey}/builder_config` replaces and persists the full configuration on a per-validator basis. It does not merge with the previous entry. - `DELETE /eth/v1/validator/{pubkey}/builder_config` removes the stored entry, so the validator inherits the global configuration again. The API stores per-validator entries under `validator_configs` in `builder_definitions.yml`. Changes made by `POST` and `DELETE` apply to subsequent builder preference publication and Gloas block production without a restart. When `auth_data` is omitted, global and per-validator builder configurations use the builder URL's lowercase ASCII hostname, following [ethereum/builder-specs#168](ethereum/builder-specs#168), [ethereum/beacon-APIs#642](ethereum/beacon-APIs#642) and [ethereum/keymanager-APIs#94](ethereum/keymanager-APIs#94). URLs with and without a trailing slash produce the same auth data. Closes sigp#9796 Closes sigp#10076 Co-authored-by: Mark Mackey <mark@sigmaprime.io>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Issue Addressed
Addressed the following 2 checklist items in #9045
GET /eth/v1/beacon/pool/payload_attestationsendpointGET /eth/v1/beacon/pool/payload_attestationsSSZ response to use ProgressiveListProposed Changes
get_payload_attestationsfunction is called at the time of block production. This further changed the pool which now holdsPayloadAttestationinstead ofPayloadAttestationMessage, keyed byPayloadAttestationData.get_payload_attestationsbecomes a filter-and-clone function as wellget_all_payload_attestationsfunction which returns the aggregated payload attestations in the pool based on the optionalslotfilter. An omittedslotreturns all of the aggregated payload attestations in the pool. The new function will be used by theGET beacon/pool/payload_attestationsendpoint and kept separate from the existingget_payload_attestationsfunctionGET beacon/pool/payload_attestationsas per beacon API spec of the endpoint. It serves JSON or SSZ, depending onAcceptheader with the SSZ response returning aProgressiveListas per beacon-APIs#635 changeshttp_apiandnetworktests now assert on the aggregation bits for the message'sdatainstead of the pool's message/aggregate count