Sending 0 as committee_index in GET AttestationData endpoint

[dB2510]

Describe the bug

While integrating lodestar to our Obol distributed validator cluster we found out that when calling GET attestation data endpoint from beacon node, lodestar sends committee index as 0.

lodestar/packages/validator/src/services/attestation.ts

Line 91 in bc20c21

const attestationRes = await this.api.validator.produceAttestationData(0, slot).catch((e: Error) => {

Whereas other clients for ex, lighthouse and teku send committee index obtained at the time of getting attester duties endpoint. This results in timeout since we store attestation data with (slot, committee_index) as key.

Expected behavior

Lodestar should send actual committee_index as query parameter to GET attestation data endpoint rather than sending 0 obtained from attester duties endpoint so that it would be consistent with other clients and spec as well.

Steps to Reproduce

Screenshots

Desktop (please complete the following information):

• OS: macOS Monterey
• Version: v1.1.1
• Branch: v1.1.1
• Commit hash: 90a92dd

[wemeetagain]

We currently call the produceAttestationData once per slot for all connected validators with duties at that slot. We're calling with committee index 0 since the resulting attestation data isn't actually dependent on the committee index. We reuse the result for all connected validators with duties at that slot.

We probably wouldn't want to get rid of this optimization, but we could make the produceAttestationData call with a "real" committee index, eg: the committee index from the first duty in the list of duties for that slot.

Would that resolve yall's issue?

[dB2510]

@wemeetagain yeah that would work for us 👍

[philknows]

Closing via #4695

[dB2510]

Hey @wemeetagain 👋
Sorry for bumping up this issue. Actually the fix doesn't work for us. We call GET attestation data endpoint endpoint for each validator public key like every other client and since AttestationData consists of beacon_block_root (LMD ghost vote) which is head block root, it can change between calls if we have multiple validators attesting in the same slot. This causes conflicts between lodestar and other VCs in the cluster as lodestar queries attestation_data once with 0 as committee_index.

Therefore, lodestar is incompatible in distributed validator cluster with other validator clients like teku and lighthouse.
Would you be open to some changes to this optimisation or something similar?

[nflaig]

Proposed solution #5103 to resolve the Lodestar DVT compatibility issue

[nflaig]

Resolved by #5258