You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use this library to fetch blobs from the beacon chain. We noticed that when using Prysm as the beacon node the SSZ decoding of blob sidecars fails (see issue).
The error is happening here, due to the response from Prysm having an extra four bytes at the start (it appears to be an offset to the first element).
I suspect this maybe a Prysm encoding bug, as the spec reads as if the offset isn't required when a response is just an array of ojects.
Just wanted to double check and see if you had any insight/any other reports of this. Thank you 🙏
The text was updated successfully, but these errors were encountered:
It's possible that this library is the incorrect one, did you resolve the issue to know if providing the number of elements in the array (which I assume are the first four items in the data) is required?
After further investigation it appears that this is a prysm issue, as testing against lighthouse, nimbus and teku returns the same SSZ and it is prysm which is the odd one out. Did you raise an issue with them regarding this?
Hi 👋
We use this library to fetch blobs from the beacon chain. We noticed that when using Prysm as the beacon node the SSZ decoding of blob sidecars fails (see issue).
The error is happening here, due to the response from Prysm having an extra four bytes at the start (it appears to be an offset to the first element).
I suspect this maybe a Prysm encoding bug, as the spec reads as if the offset isn't required when a response is just an array of ojects.
Just wanted to double check and see if you had any insight/any other reports of this. Thank you 🙏
The text was updated successfully, but these errors were encountered: