[BUG] v2.0.4 Fresh Sync Fails: Official Snapshot 404 & Alternative Snapshot Failed to deserialise blob

[Ha4rmfull]

1. Describe the bug

After upgrading to v2.0.4 as per the latest announcement, a fresh node installation fails to sync.

The sync process fails in two different ways:

Official Path (Default): The node crashes because it tries to download snapshot files that are missing from the official Google Storage (HTTP 404 error).

Alternative Path (graphops.xyz): Using the community-suggested snapshot URL (--snapshots-url) allows the snapshot to be downloaded, but the node then gets stuck in a permanent error loop (Failed to deserialise blob), apparently due to data incompatibility.

2. Steps to Reproduce

My Setup:

Server A (Aztec Node): Running aztecprotocol/aztec:2.0.4 (installed via aztec-up 2.0.4).

Server B (L1 Node): Dedicated Geth/Prysm node.

Geth: v1.16.4-stable

Prysm: v6.1.2 (running with the required --subscribe-all-data-subnets flag)

L1 Node Health Check (Server B) - All systems are healthy and synced:

Geth is synced

$ curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' http://localhost:8545
{"jsonrpc":"2.0","id":1,"result":false}

Prysm is synced

$ curl http://localhost:3500/eth/v1/node/syncing
{"data":{"head_slot":"...","sync_distance":"0","is_syncing":false,"is_optimistic":false,"el_offline":false}}

Geth Version

$ docker exec geth-sepolia geth --version
geth version 1.16.4-stable-41714b49

Prysm Version

$ docker exec prysm-beacon-sepolia /beacon-chain --version
beacon-chain version Prysm/v6.1.2/38955fd08c57516226a84f880e25d19283343352. Built at: 2025-10-09 14:18:57+00:00

Reproduction Path 1: Official Snapshot (Fails with 404)

Run aztec-up 2.0.4 on Server A.

Run rm -rf ~/.aztec/testnet/data/ to ensure a clean install.

Start the node using the standard command (no special flags):

aztec start --node --archiver --sequencer
--network testnet
--l1-rpc-urls 'http://[MY_L1_NODE_IP]:8545'
--l1-consensus-host-urls 'http://[MY_L1_NODE_IP]:3500'
--sequencer.validatorPrivateKey [REDACTED]
--sequencer.coinbase [REDACTED]
--p2p.p2pIp [REDACTED]
--sequencer.governanceProposerPayload 0xDCd9DdeAbEF70108cE02576df1eB333c4244C666

Result: The node starts, tries to download the snapshot for L2 block 41525, and immediately crashes with a 404 Not Found error.

Log Snippet (Path 1):

[08:04:43.966] INFO: node Syncing from snapshot at L1 block 9434485 L2 block 41525
...
[08:04:49.736] ERROR: cli Error: Error fetching file from https://storage.googleapis.com/aztec-testnet/snapshots/testnet/.../nullifier-tree-20251018...db: Request failed with status code 404
...
Error: Error fetching file from https://storage.googleapis.com/aztec-testnet/snapshots/testnet/.../nullifier-tree-20251018...db: Request failed with status code 404
at HttpFileStore.download (file:///usr/src/yarn-project/stdlib/dest/file-store/http.js:51:19)

Reproduction Path 2: Alternative Snapshot (Fails with Deserialise Error)

Run rm -rf ~/.aztec/testnet/data/ again.

Start the node, this time adding the alternative snapshot URL:

aztec start --node --archiver --sequencer
--network testnet
--snapshots-url https://snapshots.aztec.graphops.xyz/files/
--l1-rpc-urls 'http://[MY_L1_NODE_IP]:8545'
... [rest of config] ...

Result: The node successfully downloads the snapshot from graphops.xyz but then gets stuck in a permanent error loop, unable to parse blob data from my healthy L1 node.

Log Snippet (Path 2):
(This is the error shown in the blob.png file, which I will attach below)

[08:09:06.105] WARN: node:blob-sink:client Failed to deserialise blob {"commitment":"0xb12fc..."}
[08:09:06.105] WARN: node:blob-sink:client Failed to deserialise blob {"commitment":"0x844b4..."}
[08:09:06.105] WARN: node:blob-sink:client Failed to fetch blobs for 0x5737897b... from all blob sources {"l1ConsensusHostUrls":["http://[MY_L1_NODE_IP]:3500"]}

(You can attach your blob.png file here)

3. Expected Behavior

The node should successfully download all required files from the official snapshot URL (storage.googleapis.com) and begin syncing normally without 404 or Failed to deserialise blob errors.

4. Conclusion

Both available snapshot paths for v2.0.4 appear to be non-functional.

The official path is missing critical files.

The alternative path seems to be incompatible with the current node version or L1 data.

This prevents any operator from performing a fresh sync. Could the team please investigate the official snapshot files for v2.0.4 on Google Storage?

Thank you.

Code Reference

// === FAILED PATH 1: Official Snapshot (Crashes with 404) ===
// The node tries to sync from L2 block 41525 and fails:
[08:04:49.736] ERROR: cli Error: Error fetching file from https://storage.googleapis.com/.../nullifier-tree...db : Request failed with status code 404

// === FAILED PATH 2: Alternative "graphops.xyz" Snapshot (Loops with Error) ===
// The node downloads the snapshot but then gets stuck in this loop:
[08:09:06.105] WARN: node:blob-sink:client Failed to deserialise blob {"commitment":"0xb12fc..."}
[08:09:06.105] WARN: node:blob-sink:client Failed to fetch blobs for 0x5737897b...