* added new endpoint version(v2) for validator aggregate and proof
* review improvements
* introduced nim template for proof executiion
---------
Co-authored-by: Pedro Miranda <pedro.miranda@nimbus.team>
* add: get_extended_sample_count with test
* drop return
* reviews
* review fix
* fixed
* fix doc
* hooked to all_tests
* rm bin
* add updated test file
* early return, maybe need results?
* refactor function intricacies
* drop columnsCount
* attestation pool support and tests
* REST endpoints changes
* initial ncli and validator client support
* updated tests file
* fixed typos
* review improvements
* remove V1 endpoint
* revert v1 removal
* V2 endpoint version available to pre electra
---------
Co-authored-by: Pedro Miranda <pedro.miranda@nimbus.team>
The comment in `readExecutionTransaction` is not actually relevant when
the `rlp.decode` template is called from a non-generic function.
The function still cannot be simply inlined; `is_valid_versioned_hashes`
is itself generic and would require an `export eth_types_rlp` to work
properly (generic sandwich issue). The non-generic function wrapper
seems simpler and avoids injecting RLP into importing modules.
Normally, running LC and DAG sync at same time is fine, but on tiny
devnet where some peer may not support the LC data, we can end up in
situation where peer gets disconnected when DAG is in sync, because
DAG sync never uses any req/resp on local devnet (perfect nw conditions)
so the LC sync over minutes removes the peer as sync is stuck.
We don't need to actively sync LC from network if DAG is already synced,
preventing this specific low peer devnet issue (there are others still).
LC is still locally updated when DAG finalized checkpoint advances.
* check blob versioned hashes when no EL is connected
When no EL is conencted, we have to at the very least ensure that the
data in the beacon block is consistent with the execution payload.
We already do this for the block hash, but also have to do it for the
`blob_kzg_commitments`. To validate that they are linked with the
execution payload, we have to RLP decode all EIP-4844 blob transactions
and compare their blob versioned hashes with the hashed commitments.
* simplify loop in case where `blob_versioned_hashes` doesn't exist
* skip blob transaction parsing pre Deneb
* remove option to select Capella fork choice algo
With Deneb having run stable for quite a while now, it's time to remove
the option to select the prior fork choice algo from Capella.
* also remove usage from test
Followup on incorrect upgrade procedure in #6375 where `blob_gas_used`
was accidentally copied into `excess_blob_gas` when running Electra
`LightClientStore` with earlier `LightClient(Bootstrap|Update)`.
On `ELECTRA_FORK_EPOCH`, PeerDAS is not yet activated, hence the current
mechanism based on `BlobSidecar` is still in use. With EIP-7688, the
generalized indices of `BeaconBlockBody` get reindexed, changing the
length of the inclusion proof within the `BlobSidecar`. Because network
Req/Resp operations allow responses across fork boundaries, this creates
the need for a `ForkedBlobSidecar` in that layer, same as already done
for `ForkedSignedBeaconBock` for similar reasons.
Note: This PR is only needed if PeerDAS is adopted _after_ EIP-7688.
If PeerDAS is adopted _before_ EIP-7688, a similar PR may be needed for
forked columns. Coincidental `Forked` jank can only be fully avoided if
both features activate at the same epoch, actual changes to blobs aside.
Delaying EIP-7688 for sole purpose of epoch alignemnt is not worth it.
The fork digest determines the underlying data type on libp2p gossip,
so it's important to use the matching fork digest instead of picking
whatever wall epoch happens to be.
To avoid "forked" types creeping into `BlobSidecar`, move the reduction
to `BlobSidecarInfoObject` to the sole caller. The info object is fork
agnostic, so does not need "forked" if `BlobSidecar` ever updates.
* Fix blob syncing for Electra
`BlobSidecar` requests on libp2p have a context prefix based on:
> The `<context-bytes>` field is calculated as context =
> `compute_fork_digest(fork_version, genesis_validators_root)`
We currently only process blobs if that indicates Deneb, meaning that
on Electra we incorrectly report `InvalidContextBytes` and refuse to
process the blob response data.
Fix this, and also ensure that the code no longer needs maintenance
with every fork unrelated to blobs.
* fix
When no EL is connected, it is still required to validate the block hash
of `ExecutionPayload` to prevent attacks that trick us into attesting to
a circular chain with invalid in-between block hashes. This is already
done through Deneb but was still missing in Electra to be rectified now.
* bump nim-eth to `d8fda55c79dd48ba564f3cb540b968f4a1c1aae6`
- Overhaul of ENR implementation - part I
- Rework of ENR decoding code
- Update discv5 to use non deprecated ENR calls and simplify code
- simplify .nimble file
- avoid warnings when processing `GasInt` for RLP
- define Electra types and RLP encoding
* explicitly indicate consensus types over nim-eth types in EL manager
* extend light client protocol for Electra
Add missing Electra support for light client protocol:
- https://github.com/ethereum/consensus-specs/pull/3811
Tested against PR consensus-spec-tests, the test runner automatically
picks up the new tests once available.
* workaround `version-2-0`: `Error: cannot instantiate: 'SomeUnsignedInt'`
* fix initialization when Electra not scheduled
* try reduce stack size in test
* put correct sync committee branch version into DB
* adjust fork schedule in light client data tests
* further reduce stack size
* split function into multiple parts
* rename variable
* regenerate test reports to cover new Electra tests
* add Nim bug reference
Including sync contributions into a block affects validator rewards.
When we have not received aggregate sync contributions, but have seen
individual messages, we can produce the contributions locally, improving
validator rewards when subscribing to all subnets or when having a
non-aggregating attached validator in the sync committee.
Add missing Electra support for light client protocol:
- https://github.com/ethereum/consensus-specs/pull/3811
Tested against PR consensus-spec-tests, the test runner automatically
picks up the new tests once available.
Addresses two inaccuracies in light client data size documentation:
1. `SyncCommittee` pubkeys serialize are 48 bytes not 64 bytes
2. Some of the estimates used 1000 vs 1024 bytes/KB, aligned to 1024
Bellatrix light client data does not contain the EL block hash, so we
had to follow blocks gossip to learn the EL `block_hash` of such blocks.
Now that Bellatrix is obsolete, we can simplify EL syncing logic under
light client scenarios. Bellatrix light client data can still be used
to advance the light client sync itself, but will no longer result in
`engine_forkchoiceUpdated` calls until the sync reaches Capella. This
also frees up some memory as we no longer have to retain blocks.
Using `let contextFork = consensusFork` no longer seems to work to avoid
capturing the `var` loop variable; it ends up being `Electra` for all
handlers. Use `closureScope` as a more sustainable fix.
`ValidatorSig` uses `blob` but `TrustedSig` uses `data`, aligning the
names reduces code duplication and improves clarity. It also simplifies
`StableContainer` compatibility checks.
`ValidatorSig` uses `blob` but `TrustedSig` uses `data`, aligning the
names reduces code duplication and improves clarity. It also simplifies
`StableContainer` compatibility checks.
Pedro Miranda
tersec
Agnish Ghosh
Etan Kissling
Pedro Miranda
Jacek Sieka
Etan Kissling
Eugene Kabanov
Kim De Mey
Jhett Black
andri lim