Handle getProof without storage root idx

[ftheirs]

Pathfinder encounters an error when querying the storage_root_idx results in None. This PR addresses these cases by handling the error and populating contract_proof with an empty vector instead.

---

While working with a devnet on Madara, we discovered a condition that occurs only in the initial blocks of the chain. From block 1 to block 9, the storage_root_idx query returns None, causing Pathfinder to immediately throw an error.
This error is propagated instead of being handled appropriately at the application layer, specifically in SNOS. Returning an empty vector allows us to continue with our workflow and handle this situation more gracefully.

On the other hand, the error received is not descriptive, forcing SNOS to interrupt execution. For example:

{"error":{"code":-32603,"message":"Internal error"},"id":1,"jsonrpc":"2.0"}

Steps to reproduce:

1. Clone repositories

git clone [email protected]:eqlabs/pathfinder.git
git clone [email protected]:madara-alliance/madara

2. Run Madara

cd madara
cargo run --release -- \
    --name madara \
    --base-path $(pwd)/madara-db \
    --rpc-port 9944 \
    --rpc-cors "*" \
    --rpc-external \
    --sequencer \
    --chain-config-path configs/presets/devnet.yaml \
    --feeder-gateway-enable \
    --gateway-enable \
    --gateway-external \
    --gas-price 1234 \
    --blob-gas-price 10 \
    --rpc-methods unsafe \
    --no-l1-sync

3. Start Pathfinder

cd ../pathfinder
cargo run --bin pathfinder -- \
    --network custom \
    --chain-id MADARA_DEVNET \
    --ethereum.url wss://eth-sepolia.g.alchemy.com/v2/WIUR5JUZXieEBkze6Xs3IOXWhsS840TX \
    --gateway-url http://localhost:8080/gateway \
    --feeder-gateway-url http://localhost:8080/feeder_gateway \
    --storage.state-tries archive \
    --data-directory ~/pathfinder/data \
    --http-rpc 127.0.0.1:9545

4. Retrieve a storage proof using curl from any block between 1 and 9

curl --request POST \
    --url http://127.0.0.1:9545/rpc/pathfinder/v0.1 \
    --header 'accept: application/json' \
    --header 'content-type: application/json' \
    --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "pathfinder_getProof",
  "params": [
    { "block_number": 5 }, "0x1", ["0x0"]
  ]
}
'

[CHr15F0x]

I don't have access to the custom blocks that you're using but I did a quick test with storage_root_idx hardcoded to return None and I've got a few questions:

1. using pathfinder from latest main and pathfinder_getProof yields a pathfinder specific error, not an Internal error:

{"error":{"code":10001,"message":"Proof is missing"},"id":1,"jsonrpc":"2.0"}

2. this is inconsistent with your results, so could you please let us know more about the setup:

• pathfinder version used,
• custom blocks 0..=9 that you used for this test (I imagine these were just empty?).

[kkovaacs]

Some more information:

• Madara creates empty blocks every 10s. These blocks are actually empty (no transactions). This also means that storage is completely empty up to block 10, where the system contract at address 0x1 is first updated with the block hash of block 0.
• Storage being empty indeed leads to Pathfinder returning a ProofMissing error -- which is actually an issue. Returning an empty response for cases where storage is empty would be better behavior.
• However, when Pathfinder is running with pruned Merkle tries a missing root index might also mean that we no longer have the Merkle tries around for the block in the request. In this case ProofMissing is indeed the correct behavior.

[kkovaacs]

@ftheirs One more question: do you have plans on migrating to the new starknet_getStorageProof method that has been added to JSON-RPC 0.8? That's a more future-proof version of the old Pathfinder-specific methods.