**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**
Closes https://github.com/ChainSafe/lodestar/issues/8606
**Description**
This updates our implementation to be compliant with latest spec
https://github.com/ethereum/beacon-APIs/pull/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 https://github.com/ChainSafe/lodestar/pull/5344
**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 https://github.com/ChainSafe/lodestar/issues/8661
Adds proposer duties v2 endpoint which works the same as v1 but uses
previous epoch to determine dependent root to account for deterministic
proposer lookahead changes in fulu.
https://github.com/ethereum/beacon-APIs/pull/563
**Motivation**
Client teams have been instructed to increase default gas limits to 60M
for Fusaka.
**Description**
This will ensure that validators signal 60M by default and updates
docs/tests to work with the new 60M configuration.
---------
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
**Motivation**
This was a feature we developed for [rescuing
Holesky](https://blog.chainsafe.io/lodestar-holesky-rescue-retrospective/)
as part of https://github.com/ChainSafe/lodestar/pull/7501 to quickly
sync nodes to head during a period of long non-finality (~3 weeks).
While it's unlikely we will have such a long period of non-finality on
mainnet, this feature is still useful to have for much shorter periods
and testing purposes on devnets.
It is now part of [Ethereum protocol
hardening](https://github.com/eth-clients/diamond) mitigations described
[here](https://github.com/eth-clients/diamond/blob/main/mitigations/nfin-checkpoint-001.md)
> Ordinary checkpoint sync begins from the latest finalized checkpoint
(block and/or state). As an escape hatch during non-finality, it is
useful to have the ability to checkpoint sync from an unfinalized
checkpoint. A client implementing this mitigation MUST support
checkpoint sync from an arbitrary non-finalized checkpoint state.
We will support this with the exception that our checkpoint state needs
to be an epoch boundary checkpoint.
**Description**
The main feature of this PR is to allow initializing a node from an
unfinalized checkpoint state either retrieved locally or from a remote
source.
This behavior is disabled by default but can be enabled by either adding
- the `--lastPersistedCheckpointState` flag to load from the last safe
persisted checkpoint state stored locally
- or `--unsafeCheckpointState` to provide a file path or url to an
unfinalized checkpoint state to start syncing from which can be used
with new endpoint `GET /eth/v1/lodestar/persisted_checkpoint_state` to
sync from a remote node or by sharing states from `checkpoint_states`
folder
Both of these options are not safe to use on a network that recently
finalized an epoch and must only be considered if syncing from last
finalized checkpoint state is unfeasible.
An unfinalized checkpoint state persisted locally is only considered to
be safe to boot if
- it's the only checkpoint in it's epoch to avoid ambiguity from forks
- its last processed block slot is at an epoch boundary or last slot of
previous epoch
- state slot is at an epoch boundary
- state slot is equal to `epoch * SLOTS_PER_EPOCH`
But even if these criteria are met, there is chance that the node will
end up on a minority chain as it will not be able to pivot to another
chain that conflicts with the checkpoint state it was initialized from.
Other existing flags (like `--checkpointState`) are unchanged by this PR
and will continue to expect a finalized checkpoint state.
Previous PRs https://github.com/ChainSafe/lodestar/pull/7509,
https://github.com/ChainSafe/lodestar/pull/7541,
https://github.com/ChainSafe/lodestar/pull/7542 not merged to unstable
are included.
Closes https://github.com/ChainSafe/lodestar/issues/7963
cc @twoeths
---------
Co-authored-by: twoeths <10568965+twoeths@users.noreply.github.com>
Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation**
- to be able to take profile in Bun
**Description**
- implement `profileBun` api using `console.profile()` apis
- as tested, it only supported up to 3s or Bun will crash so I have to
do a for loop
- cannot take the whole epoch, or `debug.bun.sh` will take forever to
load
- refactor: implement `profileThread` as wrapper of either
`profileNodeJS` or `profileBun`
- note that NodeJS and Bun works a bit differently:
- NodeJS: we can persist to a file, log into server and copy it
- Bun: need to launch `debug.bun.sh` web page as the inspector, profile
will be flushed from node to to the inspected and rendered live there
**Steps to take profile**
- start beacon node with `--inspect` and look for `debug.bun.sh` log
- launch the specified url, for example
`https://debug.bun.sh/#127.0.0.1:9229/0qoflywrwso`
- (optional) the UI does not show if the inspector is connected to app
or not, so normally I wait for the sources to be launched
- `curl -X POST
http://localhost:9596/eth/v1/lodestar/write_profile?thread=main`
- look into `Timelines` tab in `https://debug.bun.sh/`, check `Call
tree` there
- (optional) export Timeline to share it
**Sample Profile**
[Timeline%20Recording%201
(4).json.zip](https://github.com/user-attachments/files/22788370/Timeline.20Recording.201.4.json.zip)
---------
Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
**Motivation**
Make the types exports consistent for all packages.
All modern runtimes support [conditional
exports](https://nodejs.org/api/packages.html#conditional-exports) and
there are caveats when we have both conditional exports and normal
exports present in a package.json. This PR tend to make all exports
follow same consistent and modern pattern.
**Description**
- We were using subpath exports for some packages and module exports for
other
- Keep all the types export consistent as subpath exports.
- Remove "types" and "exports` directive from package.json
- Remove `typesVersions`, this is useful only if we have different
version of types for different versions of Typescript. Or having
different types files for different file paths.
**Steps to test or reproduce**
- Run all CI
**Motivation**
Add `src` directory to package sources along with the `lib` files to
have working source map.
**Description**
- Add `src` to the files.
**Steps to test or reproduce**
- Run all tests
**Motivation**
- #7280
**Description**
- Add `"bun"` export to all packages that points to the _typescript
source_ rather than the transpiled javascript
- Allows for bun to use typescript directly
**Motivation**
Enable the organize import back which was disabled in #7982 to isolate
the changes for import ordering
**Description**
- Update the organize import config
- Fix all linting errors
**Steps to test or reproduce**
- Run all tests
---------
Co-authored-by: Cayman <caymannava@gmail.com>
**Motivation**
Use latest `module` and `moduleResolution` for TS.
**Description**
- To use [subpath
imports](https://nodejs.org/api/packages.html#subpath-imports) in the PR
#8320 we need to update the module solution strategy for TS.
- That requires to change the `module` for the TS as well.
- Earlier tried to stay with `node18` or `node20`, but the `ts-node`
does not work with that.
- Maintaining different tsconfig for ts-node is more of hassle on wrong
run.
- So decided to stick with `nodenext` strategy for `moduleResolution`
**Steps to test or reproduce**
Run all tests
---------
Co-authored-by: Cayman <caymannava@gmail.com>
**Motivation**
This is required to pass spec tests since spec example was updated in
https://github.com/ethereum/beacon-APIs/pull/550
**Description**
Update `payload_attributes` event test data
**Note:** we already emit all required fields, no changes needed there
**Motivation**
Use the more type aware version of Biome to get benefit from type safety
rules.
**Description**
- Keep the rules matching to previous behavior
- Add explanation to all ignore as it's required in new version
**Steps to test or reproduce**
Run all tests
---------
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
**Motivation**
Make the code transition for compatibility with the Bun.
**Description**
- The dependency `cpu-features` is not compatible with the `Bun`
- Removed the direct dependency
- Upgrade the `@chainsafe/persistent-merkle-tree` and `@chainsafe/ssz`
so the hasher detection is done implicitly.
- Latest commit for
[hahstree](e86a8b136a)
has the support for fallback, which is not used in the
`@chainsafe/persistent-merkle-tree`
**Steps to test or reproduce**
Run all tests
**Motivation**
Seems like all other clients populate this field and it hasn't been
deprecated on the spec side as our code comments might suggest.
**Description**
Return subcommittee assignments from state sync committees endpoint
Closes https://github.com/ChainSafe/lodestar/issues/7903
**Motivation**
- address
https://github.com/ChainSafe/lodestar/pull/6353#discussion_r2255325445
**Description**
Our block production and publishing data flow was messy. The data types
and utility functions are jumbled, duplicate functions, differences from
spec functions, etc. To that end, this refactors things that touch this
proposal data flow.
- Tweak the fork-agnostic `BlockContents` type to also include pre-deneb
`BeaconBlock`
- this allows us to remove `BlockOrContents` variables and types
- Remove `Contents` (It isn't actually needed)
- Collect all `produced*` caches into `blockProductionCache`
- make blinded block reconstruction more typesafe
- Separate blobs+proofs sanity validation from cells+proof sanity
validation
- Delete duplicated `BlobsBundle` type
- Remove duplicate spec function `computeDataColumnSidecars` in favor of
`getDataColumnSidecars*` functions
- Refactor `computeBlobSidecars` into `getBlobSidecars` from the spec
---------
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
**Motivation**
- https://github.com/ethereum/beacon-APIs/pull/546
**Description**
Add `GET /eth/v1/beacon/blobs/{block_id}` endpoint to retrieve blobs
- pre-fulu we can just return data stored in db
- post-fulu we need to reconstruct the blobs from stored data column
sidecars
As per ACDC 160, we need `submitBlindedBlockV2` which has empty response
to cope with increasing size of blob bundles.
This PR adds `submitBlindedBlockV2`. Will call this endpoint and not
publish blinded blocks as they are published by builder post-fulu.
Spec reference: https://github.com/ethereum/builder-specs/pull/123
---------
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
**Motivation**
- https://github.com/ethereum/consensus-specs/pull/4354
**Description**
- add concept of fork boundaries (`ForkBoundary`) which include both
normal hard-forks (phase0, altair, etc.) and Blob Parameter Only (BPO)
forks and are used to un-/subscribe to gossip topics and compute the
fork digest primarily for domain separation on the p2p layer
- mix in blob parameters (`BlobParameters`) when computing fork digest
(`computeForkDigest`) post-fulu
- update ENR fork id (`ENRForkID`) to consider fork boundaries (next
fork digest (`nfd`) will be updated in
https://github.com/ChainSafe/lodestar/pull/8023)
- cache pre-computed fork digests by epoch instead of fork name in
genesis config cache
---------
Co-authored-by: NC <17676176+ensi321@users.noreply.github.com>
**Motivation**
Right now we only emit `blob_sidecar` event during block import when we
have received all blobs but this is not ideal as the event is mostly
used to gather timing information of when blobs are received by nodes in
the network. We should emit the event as soon as possible similar to
https://github.com/ChainSafe/lodestar/pull/7953.
**Description**
Emit `blob_sidecar` event as soon as we receive `BlobSidecar`
- through `publishBlock` api if we are proposer
- on `blob_sidecar` gossip topic from the network
- from engine api via `engine_getBlobsV1` method
- from req/resp via `blob_sidecars_by_root` method
**Motivation**
- Closes https://github.com/ChainSafe/lodestar/issues/7969
**Description**
We need to ignore `statuses` field if it's set to `null` based on note
in beacon-api spec
> Either or both may be `null` to signal that no filtering on that
attribute is desired.
I am not exactly sure why that note is there, I think the intend was to
clarify how to handle the case if the field is omitted, and not if it's
explicitly set to `null` as the schema itself only allows type to be
`array`.
In any case, this is simple for us to handle, we can just convert the
`null` value to `undefined` during request parsing and handle it the
same way as if it was omitted in downstream code.
**Motivation**
- https://github.com/ethereum/beacon-APIs/pull/539
**Description**
Add `GET /eth/v1/beacon/states/{state_id}/proposer_lookahead` endpoint
to retrieve proposer lookahead from state
