Invalid Blob Sidecars SSZ Encoding

[danyalprout]

Describe the bug

Hi 👋

It appears that when you make a /eth/v1/beacon/blob_sidecars/<slot> request to Prysm it prefixes the response with an additional four bytes (I'm assuming this is an non standard offset).

I believe this is specific to Prysm and other CL clients don't do this -- I've personally verified Lighthouse and this issue, mentions testing Nimbus & Teku too.

Attached the responses from Prysm and Lighthouse for slot 9378623 below:
lh-out-hex.txt
prysm-out-hex.txt

Has this worked before in a previous version?

I don't believe so.

🔬 Minimal Reproduction

1. Fetch the data from Prysm curl -H "Accept: application/octet-stream;q=1,application/json;q=0.9" "https://prysm-url/eth/v1/beacon/blob_sidecars/9378623" > prysm-out
2. Fetch the data from another CL client (e.g. Lighthouse) curl -H "Accept: application/octet-stream;q=1,application/json;q=0.9" "lh-url/eth/v1/beacon/blob_sidecars/5302905" > lh-out
3. Convert the responses to hex xxd lh-out > lh-out.hex && xxd prysm-out > prysm-out.hex
4. Diff the responses, see the leading four bytes 0400 0000

Error

No response

Platform(s)

Linux (x86)

What version of Prysm are you running? (Which release)

Prysm/v5.0.3

Anything else relevant (validator index / public key)?

No response

[nisdas]

Thanks for the report @danyalprout , have you been able to run v5.0.4 to see if it is still an issue ? We have had a few fixes for the blob sidecars endpoint