Skip to content

Should ignore committee_index in attestation production API post-Electra #8252

@Alleysira

Description

@Alleysira

Description

Hello developers,

I am conducting API testing on an Electra PoS devnet chain and have noticed inconsistencies in the Beacon-API responses across different CL clients: Prysm, Lighthouse, Teku, Nimbus, Lodestar, and Grandine.

Specifically, when calling the endpoint /eth/v1/validator/attestation_data with non-zero committee_index, I observed that Prysm, Nimbus lodestar, grandine returns normal results, lighthouse and teku rejected, return 500/400.

The testing retusts of all CL clients:

# prysm
{"data": {"beacon_block_root": "0xaeb31c5b33360376fa39ac193e4b61833fdb452ed73d2d0d0ac953ffd6fa5003", "index": "0", "slot": "36", "source": {"epoch": "0", "root": "0x0000000000000000000000000000000000000000000000000000000000000000"}, "target": {"epoch": "1", "root": "0xe34d3e4e527ac41350bdaddf938b6a4428d87d3175ce1f6499f836a3b68451cf"}}}
# lighthouse
{"code": 500, "message": "UNHANDLED_ERROR: BeaconStateError(NoCommittee { slot: Slot(36), index: 4 })", "stacktraces": []}
# teku
{"code": 400, "message": "Invalid committee index 4 - expected between 0 and 0"}
# nimbus
{"data": {"beacon_block_root": "0xaeb31c5b33360376fa39ac193e4b61833fdb452ed73d2d0d0ac953ffd6fa5003", "index": "0", "slot": "36", "source": {"epoch": "0", "root": "0x0000000000000000000000000000000000000000000000000000000000000000"}, "target": {"epoch": "1", "root": "0xe34d3e4e527ac41350bdaddf938b6a4428d87d3175ce1f6499f836a3b68451cf"}}}
# lodestar
{"data": {"beacon_block_root": "0xaeb31c5b33360376fa39ac193e4b61833fdb452ed73d2d0d0ac953ffd6fa5003", "index": "0", "slot": "36", "source": {"epoch": "0", "root": "0x0000000000000000000000000000000000000000000000000000000000000000"}, "target": {"epoch": "1", "root": "0xe34d3e4e527ac41350bdaddf938b6a4428d87d3175ce1f6499f836a3b68451cf"}}}
# grandine
{"data": {"beacon_block_root": "0xaeb31c5b33360376fa39ac193e4b61833fdb452ed73d2d0d0ac953ffd6fa5003", "index": "0", "slot": "36", "source": {"epoch": "0", "root": "0x0000000000000000000000000000000000000000000000000000000000000000"}, "target": {"epoch": "1", "root": "0xe34d3e4e527ac41350bdaddf938b6a4428d87d3175ce1f6499f836a3b68451cf"}}}

The Beacon-api spec do not have clear definitions of how invalid committee_index should be handled. However, discussions in discord ETH R&D and ethereum/beacon-APIs#511 seems to come to conclusion that the provided committee_index should be ignored.

Thanks for your time!

Version

  • Lighthouse/v8.0.0-rc.1-1fb94ce/x86_64-linux
  • Prysm/v6.1.3 (linux amd64)
  • teku/v25.9.3+72-g5ff7d1ce26/linux-x86_64/-eclipseadoptium-openjdk64bitservervm-java-21
  • Nimbus/v25.9.2-9839f1-stateofus
  • Lodestar/v1.35.0/a8e3089
  • Grandine/1.1.5-7a383ef0/x86_64-linux

Present Behaviour

Reject requests with non-zero committee_index with 500 and

"UNHANDLED_ERROR: BeaconStateError(NoCommittee { slot: Slot(36), index: 4 })"

Expected Behaviour

Ignore the committee_index and set the committee_index to 0 in the AttestationData

Steps to resolve

  1. Start the testnet with:
kurtosis run --enclave con-testnet github.com/ethpandaops/ethereum-package --args-file config.yaml
  1. config.yaml:
participants:
  - el_type: geth
    cl_type: prysm
    el_image: ethereum/client-go:v1.16.5
    cl_image: gcr.io/offchainlabs/prysm/beacon-chain:v6.1.3

  - el_type: geth
    cl_type: lighthouse
    el_image: ethereum/client-go:v1.16.5
    cl_image: sigp/lighthouse:v8.0.0-rc.1

  - el_type: geth
    cl_type: teku
    el_image: ethereum/client-go:v1.16.5
    cl_image: ethpandaops/teku:master-5ff7d1c

  - el_type: geth
    cl_type: nimbus
    el_image: ethereum/client-go:v1.16.5
    cl_image: statusim/nimbus-eth2:multiarch-v25.9.2

  - el_type: geth
    cl_type: lodestar
    el_image: ethereum/client-go:v1.16.5
    cl_image: chainsafe/lodestar:v1.35.0

  - el_type: geth
    cl_type: grandine
    el_image: ethereum/client-go:v1.16.5
    cl_image: sifrai/grandine:2.0.0.rc0

network_params:
  network_id: "251021"
  num_validator_keys_per_node: 11

additional_services:
  - dora
  1. Call the lighthouse node with
curl -X GET "http://127.0.0.1:lighthouse_port/eth/v1/validator/attestation_data?slot=36&committee_index=4" | jq

Metadata

Metadata

Assignees

No one assigned

    Labels

    HTTP-APIbugSomething isn't workingelectraRequired for the Electra/Prague fork

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions