chore: v1.39.0 release #8769
Draft
chore: v1.39.0 release #8769
Conversation
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
**Motivation** - once we have `state-transition-z`, we're not able to get `index2pubkey` from a light view of BeaconState in beacon-node **Description** - in `beacon-node`, use `index2pubkey` of BeaconChain instead as a preparation for working with `state-transition-z` - it's ok to use `state.epochCtx.index2pubkey` in `state-transition` since it can access the full state there part of #8652 --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motiviation** All networks have completed the merge transition and most execution clients no longer support pre-merge so it's not even possible anymore to run a network from a genesis before bellatrix, unless you keep it to phase0/altair only, which still works after this PR is merged. This code is effectively tech debt, no longer exercised and just gets in the way when doing refactors. **Description** Removes all code related to performing the merge transition. Running the node pre-merge (CL only mode) is still possible and syncing still works. Also removed a few CLI flags we added for the merge specifically, those shouldn't be used anymore. Spec constants like `TERMINAL_TOTAL_DIFFICULTY` are kept for spec compliance and ssz types (like `PowBlock`) as well. I had to disable a few spec tests related to handling the merge block since those code paths are removed. Closes #8661
**Motivation** - as a preparation for lodestar-z integration, we should not access pubkey2index from CachedBeaconState **Description** - use that from BeaconChain instead part of #8652 Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation** - improve memory by transferirng gossipsub message data from network thread to the main thread - In snappy decompression in #8647 we had to do `Buffer.alloc()` instead of `Buffer.allocUnsafe()`. We don't have to feel bad about that because `Buffer.allocUnsafe()` does not work with this PR, and we don't waste any memory. **Description** - use `transferList` param when posting messages from network thread to the main thread part of #8629 **Testing** I've tested this on `feat2` for 3 days, the previous branch was #8671 so it's basically the current stable, does not see significant improvement but some good data for different nodes - no change on 1k or `novc` - on hoodi `sas` node we have better memory there on main thread with same mesh peers, same memory on network thread <img width="851" height="511" alt="Screenshot 2025-12-12 at 11 05 27" src="https://github.com/user-attachments/assets/8d7b2c2f-8213-4f89-87e0-437d016bc24a" /> - on mainnnet `sas` node, we have better memory on network thread, a little bit worse on the main thread <img width="854" height="504" alt="Screenshot 2025-12-12 at 11 08 42" src="https://github.com/user-attachments/assets/7e638149-2dbe-4c7e-849c-ef78f6ff4d6f" /> - but for this mainnet node, the most interesting metric is `forward msg avg peers`, we're faster than majority of them <img width="1378" height="379" alt="Screenshot 2025-12-12 at 11 11 00" src="https://github.com/user-attachments/assets/3ba5eeaa-5a11-4cad-adfa-1e0f68a81f16" /> --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation** All networks are post-electra now and transition period is completed, which means due to [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) we no longer need to process deposits via eth1 bridge as those are now processed by the execution layer. This code is effectively tech debt, no longer exercised and just gets in the way when doing refactors. **Description** Removes all code related to eth1 bridge mechanism to include new deposits - removed all eth1 related code, we can no longer produce blocks with deposits pre-electra (syncing blocks still works) - building a genesis state from eth1 is no longer supported (only for testing) - removed various db repositories related to deposits/eth1 data - removed various `lodestar_eth1_*` metrics and dashboard panels - deprecated all `--eth1.*` flags (but kept for backward compatibility) - moved shared utility functions from eth1 to execution engine module Closes #7682 Closes #8654
`yarn build:watch` and `yarn build:ifchanged` no longer work since #8675 since `lerna exec` requires to install a separate package `@lerna-lite/exec` to work properly
**Motivation** - as a preparation for lodestar-z integration, we should not access config from any cached BeaconState **Description** - use chain.config instead part of #8652 --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation** <!-- Why does this PR exist? What are the goals of the pull request? --> This PR is to fix eth-clients/mainnet#13 Already created this as well eth-clients/mainnet#14 <!-- A clear and concise general description of the changes of this pull request. --> <!-- If applicable, add screenshots to help explain your solution --> <!-- Link to issues: Resolves #111, Resolves #222 --> Closes #issue_number **AI Assistance Disclosure** - [ ] External Contributors: I have read the [contributor guidelines](https://github.com/ChainSafe/lodestar/blob/unstable/CONTRIBUTING.md#ai-assistance-notice) and disclosed my usage of AI below. <!-- Insert any AI assistance disclosure here -->
**Motivation** As noted in #8680 (comment) we cannot sync through bellatrix anymore. While I don't think it's a big deal it's simple enough to keep that functionality as that code is pretty isolated and won't get in our way during refactors and with gloas won't be part of the block processing pipeline anymore due to block/payload separation. **Description** Restore code required to perform sync through bellatrix - re-added `isExecutionEnabled()` and `isMergeTransitionComplete()` checks during block processing - enabled some spec tests again that were previously skipped - mostly copied original code removed in [#8680](#8680) but cleaned up some comments and simplified a bit
…8669) **Motivation** Closes #8606 **Description** This updates our implementation to be compliant with latest spec ethereum/beacon-APIs#368. For sync committee aggregation selection (unchanged) - we call `submitSyncCommitteeSelections` at the start of the slot - the timeout is still based on `CONTRIBUTION_DUE_BPS` into the slot (8 seconds) - we call the endpoint for all duties of this slot - logic has been moved to duties service For attestation aggregation selection - we call `submitBeaconCommitteeSelections` at the start of the epoch for current and next epoch (2 separate calls) - the timeout uses default which is based on `SLOT_DURATION_MS` (12 seconds) - we only call `prepareBeaconCommitteeSubnet` once the above call either resolved or failed, this should be fine as it's not that time sensitive (one epoch lookahead) - if duties are reorged, we will call `submitBeaconCommitteeSelections` with duties of affected epoch - logic has been moved to duties service Previous PR #5344
…8708) Since #8669 we might call the committee selection apis even if we don't have any duties which is unnecessary and charon doesn't like it. ``` lodestar-1 | Dec-19 16:16:47.001[] error: Error on sync committee aggregation selection slot=13278082 - JSON is not an array lodestar-1 | Error: JSON is not an array lodestar-1 | at value_fromJsonArray (file:///usr/app/node_modules/@chainsafe/ssz/src/type/arrayBasic.ts:162:11) lodestar-1 | at ListCompositeType.fromJson (file:///usr/app/node_modules/@chainsafe/ssz/src/type/array.ts:121:12) lodestar-1 | at ApiResponse.value (file:///usr/app/packages/api/src/utils/client/response.ts:115:51) lodestar-1 | at SyncCommitteeDutiesService.runDistributedAggregationSelectionTasks (file:///usr/app/packages/validator/src/services/syncCommitteeDuties.ts:385:36) lodestar-1 | at processTicksAndRejections (node:internal/process/task_queues:103:5) ```
These errors aren't really critical and might be common right now because we moved from per slot to per epoch in #8669 and not all validator clients doing the same will cause calls to time out if signature threshold in DVT middleware is not reached.
**Motivation** - we will not be able to access `pubkey2index` or `index2pubkey` once we switch to a native state-transition so we need to be prepared for that **Description** - pass `pubkey2index`, `index2pubkey` from cli instead - in the future, we should find a way to extract them given a BeaconState so that we don't have to depend on any implementations of BeaconStateView, see #8706 (comment) Closes #8652 --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation** - we use the whole CachedBeaconStateAllForks to get all block signatures, turn out we only need the validator indices of the current SyncCommittee **Description** given this `getConfig` api: ```typescript getDomain(domainSlot: Slot, domainType: DomainType, messageSlot?: Slot): Uint8Array ``` we currently pass `state.slot` as the 1st param. However it's the same to `block.slot` in `state-transition` and the same epoch when we verify blocks in batch in [beacon-node](https://github.com/ChainSafe/lodestar/blob/b255111a2013d43d5f65889274294e2740493c28/packages/beacon-node/src/chain/blocks/verifyBlock.ts#L62) - so we can just use `block.slot` instead of passing the whole CachedBeaconStateAllForks in `getBlockSignatureSets()` api - still have to pass in `currentSyncCommitteeIndexed` instead part of #8650 --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
…ition (#8716) **Motivation** #8711 (review) **Description** Prevent duplicate aggregates passing gossip validation due to race condition by checking again if we've seen the aggregate before inserting it into op pool. This is required since we run multiple async operations in-between first check and inserting it into op pool. <img width="942" height="301" alt="image" src="https://github.com/user-attachments/assets/2701a92e-7733-4de3-bf4a-ac853fd5c0b7" /> `AlreadyKnown` disappears since we now filter those out properly during gossip validation which is important since we don't wanna re-gossip those aggregates.
**Motivation** - the reward apis tightly couple to state-transition functions like `beforeProcessEpoch() processBlock() processAttestationAltair()` so it needs to be moved there **Description** - move api type definitions to `types` package so that it can be used everywhere - move reward apis implementation to `state-transition` package Closes #8690 --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation** A recent internal infrastructure change includes renaming default host instance on our dashboards. **Description** This PR allows our dashboards to easily default to the new infrastructure host instance for display.
**Motivation** - @philknows wants **Description** - allow multiple index ranges in validator - this should only be used in testing and not in production
**Motivation** Use the latest package manager which is more aligned with multi-runtime support. **Description** - Migrate yarn.lock file to pnpm-lock.yaml (`pnpm import`) - Update the scripts to use pnpm - Update the workflows to use pnpm **Steps to test or reproduce** - Run all tests **Useful commands migraiton** | Yarn 1 | pnpm | |---|---| | yarn | pnpm install | | yarn add dep | pnpm add dep | | yarn workspace "@lodestar/config" add dep | pnpm add dep --filter "@lodestar/config" | | yarn workspace foreach run build | pnpm -r build |
Updated Dockerfile to streamline installation and build process. **Motivation** After the last PR, the dockerfile wasn't building anymore. This PR fixes it. **Description** <!-- A clear and concise general description of the changes of this pull request. --> <!-- If applicable, add screenshots to help explain your solution --> <!-- Link to issues: Resolves #111, Resolves #222 --> Closes #issue_number **AI Assistance Disclosure** - [ ] External Contributors: I have read the [contributor guidelines](https://github.com/ChainSafe/lodestar/blob/unstable/CONTRIBUTING.md#ai-assistance-notice) and disclosed my usage of AI below. <!-- Insert any AI assistance disclosure here -->
Fixing [this](https://github.com/ethpandaops/ethereum-package/actions/runs/20928843912/job/60134147175#step:5:482) ```sh Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'triple-beam' imported from /usr/app/packages/logger/lib/interface.js at Object.getPackageJSONURL (node:internal/modules/package_json_reader:316:9) at packageResolve (node:internal/modules/esm/resolve:768:81) at moduleResolve (node:internal/modules/esm/resolve:858:18) at defaultResolve (node:internal/modules/esm/resolve:990:11) at #cachedDefaultResolve (node:internal/modules/esm/loader:718:20) at #resolveAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:735:38) at ModuleLoader.resolveSync (node:internal/modules/esm/loader:764:52) at #resolve (node:internal/modules/esm/loader:700:17) at ModuleLoader.getOrCreateModuleJob (node:internal/modules/esm/loader:620:35) at ModuleJob.syncLink (node:internal/modules/esm/module_job:143:33) { code: 'ERR_MODULE_NOT_FOUND' } Node.js v24.12.0 ``` **Motivation** <!-- Why does this PR exist? What are the goals of the pull request? --> **Description** <!-- A clear and concise general description of the changes of this pull request. --> <!-- If applicable, add screenshots to help explain your solution --> <!-- Link to issues: Resolves #111, Resolves #222 --> Closes #issue_number **AI Assistance Disclosure** - [ ] External Contributors: I have read the [contributor guidelines](https://github.com/ChainSafe/lodestar/blob/unstable/CONTRIBUTING.md#ai-assistance-notice) and disclosed my usage of AI below. <!-- Insert any AI assistance disclosure here -->
**Motivation** Add `semver` dependency to the workflow. **Description** - Add `semver` dependency to the package.json Used here https://github.com/ChainSafe/lodestar/blob/b79f41e05427f9ce5f5371a93ad0a9f6b89d6f2b/.github/workflows/publish-dev.yml#L57
**Motivation** This PR is to enforce using nodeJS patched builds due to [January 13, 2026 Security Releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases) **Description** This PR will ensure that source builds will only use patched versions of nodeJS that are not vulnerable to the disclosed issues above. --------- Co-authored-by: Nazar Hussain <nazarhussain@gmail.com>
**Motivation** Make the CI publish workflow work. **Description** - Add a dependency which was missing Used here https://github.com/ChainSafe/lodestar/blob/7ac2136122a9bbe20b2c068acd55c48652740054/scripts/release/utils.mjs#L5
**Motivation** Fix the root level binary path **Description** - Add `@ChainSafe/lodestar` to root level dependency
**Motivation** Use the `package/cli/bin/lodestar.js` as execution path for the binary. **Description** - Use the binary path from the cli package Closes #8755
**Motivation** - to get proposer's Signature Set, we pass CachedBeaconStateAllForks just to get config and state slot **Description** - pass config and state slot instead of `CachedBeaconStateAllForks` part of #8657 Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
Refactor so our codebase is more aligned with the recent spec change. Majority of the refactor is in `getExpectedWithdrawals`. See ethereum/consensus-specs#4766 and ethereum/consensus-specs#4765 for context. - Logic of each of the (gloas's builder withdrawals, electra's pending partial withdrawals and capella's sweep withdrawals) will live in their own respective function - `withdrawnBalances` is replaced by `balanceAfterWithdrawals`. Instead of tracking amounts getting withdrawn, it tracks remaining balance of each validator after withdrawals. Note the builder pending withdrawal logic is outdated. It is out of this refactor PR's scope. Will update it in the following PR. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Both eth-docker and rocketpool rely on `node_modules/.bin/lodestar` and we wanna avoid breaking existing deployments.
) Follow up on #8761, we run `pnpm install --frozen-lockfile --prod` during docker build and right now we don't create `.bin/lodestar` as cli package is a dev dependency.
Our docker and binary size is 2x since we switched to pnpm but this fixes it by correctly pruning dev dependencies. <img width="1854" height="210" alt="image" src="https://github.com/user-attachments/assets/6f651370-20ca-4492-b520-ad692c936b87" /> <img width="1826" height="203" alt="image" src="https://github.com/user-attachments/assets/52871f34-191e-4705-9f9f-00292c02b463" /> After the fix <img width="1843" height="198" alt="image" src="https://github.com/user-attachments/assets/f3c3a8ea-8656-454e-bb80-84b10f91d8ce" />
Using `pnpm prune --prod` is causing strange dependency errors
```
/home/runner/work/lodestar/lodestar/lodestar dev
Unpacking Lodestar binary, please wait...
node:internal/modules/package_json_reader:316
throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'bigint-buffer' imported from /tmp/caxa/applications/lodestar/aegznqzqps/0/packages/utils/lib/bytes/browser.js
at Object.getPackageJSONURL (node:internal/modules/package_json_reader:316:9)
at packageResolve (node:internal/modules/esm/resolve:768:81)
at moduleResolve (node:internal/modules/esm/resolve:858:18)
at defaultResolve (node:internal/modules/esm/resolve:990:11)
at #cachedDefaultResolve (node:internal/modules/esm/loader:718:20)
at #resolveAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:735:38)
at ModuleLoader.resolveSync (node:internal/modules/esm/loader:764:52)
at #resolve (node:internal/modules/esm/loader:700:17)
at ModuleLoader.getOrCreateModuleJob (node:internal/modules/esm/loader:620:35)
at ModuleJob.syncLink (node:internal/modules/esm/module_job:143:33) {
code: 'ERR_MODULE_NOT_FOUND'
```
we can just clean up all modules and reinstall only prod dependencies,
which seems to be very fast and negligible for build times
Contributor
Summary of ChangesHello @philknows, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request streamlines the project's infrastructure by migrating to pnpm and removing outdated Eth1-related functionalities. These changes enhance build efficiency, simplify the codebase by eliminating deprecated modules, and centralize execution layer utilities, aligning the project with the current state of the Ethereum network. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Contributor
Performance Report✔️ no performance regression detected Full benchmark results
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces significant changes, primarily migrating the project's package manager from Yarn to pnpm and completely removing the Eth1 deposit tracking and merge block tracking logic from the beacon node. This aligns with the current state of Ethereum, where all networks are post-merge, simplifying the codebase. Additionally, there's a substantial refactoring of configuration and pubkey cache passing, making these dependencies more explicit across various functions. The changes also include updates to GitHub Actions workflows, documentation, and Grafana dashboards to reflect these architectural shifts. Overall, these are positive changes that streamline the project and remove deprecated functionality.
Comment on lines
9
to
+10
| } from "@lodestar/fork-choice"; | ||
| import {ForkSeq, SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY} from "@lodestar/params"; | ||
| import {ForkSeq} from "@lodestar/params"; |
Contributor
There was a problem hiding this comment.
The removal of assertValidTerminalPowBlock and SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY imports signifies a major architectural change, as the beacon node no longer performs these Eth1-related merge checks. This simplifies the execution payload verification process, assuming all networks are post-merge.
Comment on lines
+208
to
211
| // Post-merge, we're always safe to optimistically import | ||
| case ExecutionPayloadStatus.ACCEPTED: | ||
| case ExecutionPayloadStatus.SYNCING: { | ||
| // Check if the entire segment was deemed safe or, this block specifically itself if not in | ||
| // the safeSlotsToImportOptimistically window of current slot, then we can import else | ||
| // we need to throw and not import his block | ||
| const safeSlotsToImportOptimistically = | ||
| opts.safeSlotsToImportOptimistically ?? SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY; | ||
| if (!isOptimisticallySafe && blockInput.slot + safeSlotsToImportOptimistically >= currentSlot) { | ||
| const execError = new BlockError(block, { | ||
| code: BlockErrorCode.EXECUTION_ENGINE_ERROR, | ||
| execStatus: ExecutionPayloadStatus.UNSAFE_OPTIMISTIC_STATUS, | ||
| errorMessage: `not safe to import ${execResult.status} payload within ${opts.safeSlotsToImportOptimistically} of currentSlot`, | ||
| }); | ||
| return {executionStatus: null, execError} as VerifyBlockExecutionResponse; | ||
| } | ||
|
|
||
| case ExecutionPayloadStatus.SYNCING: | ||
| return {executionStatus: ExecutionStatus.Syncing, execError: null}; |
Contributor
There was a problem hiding this comment.
The removal of the optimistic import check for ACCEPTED and SYNCING statuses, along with the UNSAFE_OPTIMISTIC_STATUS error, is a direct consequence of assuming all networks are post-merge. This simplifies the logic and removes unnecessary complexity.
Comment on lines
90
to
+103
| // will either validate or prune invalid blocks | ||
| // | ||
| // We need to track and keep updating if its safe to optimistically import these blocks. | ||
| // The following is how we determine for a block if its safe: | ||
| // | ||
| // (but we need to modify this check for this segment of blocks because it checks if the | ||
| // parent of any block imported in forkchoice is post-merge and currently we could only | ||
| // have blocks[0]'s parent imported in the chain as this is no longer one by one verify + | ||
| // import.) | ||
| // | ||
| // | ||
| // When to import such blocks: | ||
| // From: https://github.com/ethereum/consensus-specs/pull/2844 | ||
| // A block MUST NOT be optimistically imported, unless either of the following | ||
| // conditions are met: | ||
| // | ||
| // 1. Parent of the block has execution | ||
| // | ||
| // Since with the sync optimizations, the previous block might not have been in the | ||
| // forkChoice yet, so the below check could fail for safeSlotsToImportOptimistically | ||
| // | ||
| // Luckily, we can depend on the preState0 to see if we are already post merge w.r.t | ||
| // the blocks we are importing. | ||
| // | ||
| // Or in other words if | ||
| // - block status is syncing | ||
| // - and we are not in a post merge world and is parent is not optimistically safe | ||
| // - and we are syncing close to the chain head i.e. clock slot | ||
| // - and parent is optimistically safe | ||
| // | ||
| // then throw error | ||
| // | ||
| // | ||
| // - if we haven't yet imported a post merge ancestor in forkchoice i.e. | ||
| // - and we are syncing close to the clockSlot, i.e. merge Transition could be underway | ||
| // | ||
| // | ||
| // 2. The current slot (as per the system clock) is at least | ||
| // SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY ahead of the slot of the block being | ||
| // imported. | ||
| // This means that the merge transition could be underway and we can't afford to import | ||
| // a block which is not fully validated as it could affect liveliness of the network. | ||
| // | ||
| // | ||
| // For this segment of blocks: | ||
| // We are optimistically safe with respect to this entire block segment if: | ||
| // - all the blocks are way behind the current slot | ||
| // - or we have already imported a post-merge parent of first block of this chain in forkchoice | ||
| const currentSlot = chain.clock.currentSlot; | ||
| const safeSlotsToImportOptimistically = opts.safeSlotsToImportOptimistically ?? SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY; | ||
| let isOptimisticallySafe = | ||
| parentBlock.executionStatus !== ExecutionStatus.PreMerge || | ||
| lastBlock.slot + safeSlotsToImportOptimistically < currentSlot; | ||
|
|
||
| for (let blockIndex = 0; blockIndex < blockInputs.length; blockIndex++) { | ||
| const blockInput = blockInputs[blockIndex]; | ||
| // If blocks are invalid in consensus the main promise could resolve before this loop ends. | ||
| // In that case stop sending blocks to execution engine | ||
| if (signal.aborted) { | ||
| throw new ErrorAborted("verifyBlockExecutionPayloads"); | ||
| } | ||
| const verifyResponse = await verifyBlockExecutionPayload( | ||
| chain, | ||
| blockInput, | ||
| preState0, | ||
| opts, | ||
| isOptimisticallySafe, | ||
| currentSlot | ||
| ); | ||
| const verifyResponse = await verifyBlockExecutionPayload(chain, blockInput, preState0); |
Contributor
There was a problem hiding this comment.
The removal of complex logic related to isOptimisticallySafe and SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY simplifies the execution payload verification process. This change reflects the assumption that all networks are now post-merge, making these optimistic import conditions unnecessary.
| import {bellatrix, electra} from "@lodestar/types"; | ||
| import {ErrorAborted, Logger, toRootHex} from "@lodestar/utils"; | ||
| import {IEth1ForBlockProduction} from "../../eth1/index.js"; | ||
| import {ExecutionPayloadStatus, IExecutionEngine} from "../../execution/engine/interface.js"; |
Contributor
There was a problem hiding this comment.
Removing the IEth1ForBlockProduction import and eth1 property from VerifyBlockExecutionPayloadModules confirms that the execution payload verification process is now entirely decoupled from Eth1 interaction.
Comment on lines
18
to
19
| import {CAPELLA_OWL_BANNER} from "./utils/ownBanner.js"; | ||
| import {POS_PANDA_MERGE_TRANSITION_BANNER} from "./utils/pandaMergeTransitionBanner.js"; | ||
| import {FULU_ZEBRA_BANNER} from "./utils/zebraBanner.js"; |
Contributor
There was a problem hiding this comment.
The removal of POS_PANDA_MERGE_TRANSITION_BANNER and logOnPowBlock function indicates a complete removal of Eth1 merge transition logging, which is consistent with the overall deprecation of Eth1 merge tracking.
| "wideLayout": true | ||
| }, | ||
| "pluginVersion": "9.3.2", | ||
| "pluginVersion": "10.4.1", |
Contributor
There was a problem hiding this comment.
Updating the pluginVersion from 9.3.2 to 10.4.1 indicates a significant Grafana version upgrade. Ensure all dashboard features and queries are compatible with the new version.
Comment on lines
136
to
139
| execAborted: null, | ||
| executionStatuses, | ||
| executionTime, | ||
| mergeBlockFound, | ||
| }; |
Contributor
There was a problem hiding this comment.
The removal of mergeBlockFound from the returned SegmentExecStatus is consistent with the overall deprecation of Eth1 merge tracking. This streamlines the output of the execution payload verification.
| "mode": "palette-classic" | ||
| }, | ||
| "custom": { | ||
| "axisBorderShow": false, |
Contributor
There was a problem hiding this comment.
Adding axisBorderShow: false to custom options for Grafana panels is a good visual consistency improvement, especially if it aligns with the overall dashboard design.
Comment on lines
+19
to
21
| config: BeaconConfig, | ||
| index2pubkey: Index2PubkeyCache, | ||
| bls: IBlsVerifier, |
Contributor
There was a problem hiding this comment.
Adding config and index2pubkey as explicit parameters to verifyBlocksSignatures is a good refactoring. It makes the function's dependencies clear and improves testability by allowing these to be easily mocked or provided.
export async function verifyBlocksSignatures(
config: BeaconConfig,
index2pubkey: Index2PubkeyCache,
bls: IBlsVerifier,
Comment on lines
+46
to
+54
| config, | ||
| index2pubkey, | ||
| currentSyncCommitteeIndexed, | ||
| block, | ||
| indexedAttestationsByBlock[i], | ||
| { | ||
| skipProposerSignature: opts.validProposerSignature, | ||
| } | ||
| ) |
Contributor
There was a problem hiding this comment.
Passing config, index2pubkey, and currentSyncCommitteeIndexed explicitly to getBlockSignatureSets improves the function's purity and makes its dependencies explicit. This is a good step towards better modularity.
bls.verifySignatureSets(
getBlockSignatureSets(
config,
index2pubkey,
currentSyncCommitteeIndexed,
block,
indexedAttestationsByBlock[i],
{
skipProposerSignature: opts.validProposerSignature,
}
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.
Motivation
This marks the release of v1.39.0 at RC.4. Supersedes #8766.