Open Inkvi opened 1 week ago
I believe it's caused by https://github.com/Layr-Labs/eigenda-proxy/pull/167 since I use Google Storage too.
@Inkvi thank you for filing this issue. Have you verified that the issue is due to blob contents being written to redis differing from the ones written to EigenDA? In the case of #167, there was signature metadata wrapped around the initial blob contents that the aws client couldn't reason about since it was unique to gcp
@Inkvi thank you for filing this issue. Have you verified that the issue is due to blob contents being written to redis differing from the ones written to EigenDA? In the case of #167, there was signature metadata wrapped around the initial blob contents that the aws client couldn't reason about since it was unique to gcp
I haven't had a chance to verify this but based on the code paths for uploading data to EigenDA and to S3/Redis, they shouldn't differ.
Do you know an easy way to download an EigenDA blob for a testnet without writing code?
An update from my side. I tested the latest commit with Redis and there is no issue with verification. The verification only fails for S3 cache when Google Storage is used.
@Inkvi One easy way to check for GCP encoding issues is to download a blob that fails from GCS and inspect the first ~20 bytes of the file to see if there is a chunk-signature=
string.
@Inkvi One easy way to check for GCP encoding issues is to download a blob that fails from GCS and inspect the first ~20 bytes of the file to see if there is a
chunk-signature=
string.
Did exactly that and chunk-sugnature
is there.
6c;chunk-signature=50d1653b4ceb9845d388dd0c4b270e17dea1e9fc2c15b64547aedd544ac51baa
Ä∆<y∏lí¯ç∂â◊ëG Tx⁄⁄qä±≠Éi¡ÚÖÃØCÚü-9qáœ#˝fl˘€ÀŸmÏüº∂H7$ƒµFB˛¬ö◊yƒ˚ø?kgdapd #ÖÖ&Ü¡ ˇˇ}#t
0;chunk-signature=c8ba154eb017d442d2e755a2bf7c9cb13e572eeee7e24be9b50709514f3cd2ac
I cherry-picked https://github.com/Layr-Labs/eigenda-proxy/pull/167 in my fork and it didn't fix the issue for me. chunk-signature
is still present in the uploaded data. I will try again whenever you merge it into main
.
After a blob is successfully dispersed and saved to s3 cache, op-node tries to get it but cache retrieval fails due to a verification error
I tried to use Redis instead of S3 and got the same problem. It exists for fallback as well since they share athe same codepath to retrieve the data.
ghcr.io/layr-labs/eigenda-proxy:v1.4.1
is used.