-
Notifications
You must be signed in to change notification settings - Fork 927
Description
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
- Start the testnet with:
kurtosis run --enclave con-testnet github.com/ethpandaops/ethereum-package --args-file config.yaml
- 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
- 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