[ZK Stack] - GET /proof_generation_data and POST /verify_proof/:number do not work as expected

[thecodingshrimp]

Team or Project

No response

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

1.82.0

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

When starting zkstack_server with the command zkstack server --components=api,tree,eth,state_keeper,housekeeper,commitment_generator,da_dispatcher,proof_data_handler,vm_r unner_protective_reads,vm_runner_bwip,external_proof_integration_api and then trying to get proof_generation_data or verifying proofs I get an error response.

In particular, I'm following the proving a batch documentation and try to execute curl -v -F proof=@{path_to_proof_binary {address_of_API}/verify_proof/{l1_batch_number}.

The error message below requires to use application/json, but the documentation does not reflect that. Could you update it?

Expected Behavior

$ curl -v -F proof=@{path_to_proof_binary} {address_of_API}/verify_proof/{l1_batch_number} should return 200 or error when proof is not valid.

When executing a GET endpoint (/proof_generation_data) it should return the requested data. Instead, it returns POST is required

Current Behavior

$ curl -v -F proof=@l1_batch_proof_1_0_28_0.cbor http://localhost:3050/verify_proof/1
* Host localhost:3050 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:3050...
* connect to ::1 port 3050 from ::1 port 41774 failed: Connection refused
*   Trying 127.0.0.1:3050...
* Connected to localhost (127.0.0.1) port 3050
> POST /verify_proof/2 HTTP/1.1
> Host: localhost:3050
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 3228
> Content-Type: multipart/form-data; boundary=------------------------I8tsM4K0ee9AIOtMUcV7yd
> 
* We are completely uploaded and fine
< HTTP/1.1 415 Unsupported Media Type
< content-type: text/plain
< vary: origin, access-control-request-method, access-control-request-headers
< access-control-allow-origin: *
< content-length: 81
< date: Tue, 17 Jun 2025 14:33:50 GMT
< 
Supplied content type is not allowed. Content-Type: application/json is required
* Connection #0 to host localhost left intact

and

curl -v -X GET http://localhost:3050/proof_generation_data
* Host localhost:3050 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:3050...
* connect to ::1 port 3050 from ::1 port 46886 failed: Connection refused
*   Trying 127.0.0.1:3050...
* Connected to localhost (127.0.0.1) port 3050
> GET /proof_generation_data HTTP/1.1
> Host: localhost:3050
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 2
> 
< HTTP/1.1 405 Method Not Allowed
< content-type: text/plain
< vary: origin, access-control-request-method, access-control-request-headers
< access-control-allow-origin: *
< content-length: 50
< date: Tue, 17 Jun 2025 15:19:44 GMT
< 
Used HTTP Method is not allowed. POST is required
* Connection #0 to host localhost left intact

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[kaymomin]

Thank you for bringing this to our attention @thecodingshrimp. I’m forwarding your report to the appropriate team to review and address the issue.

[Artemka374]

Hi @thecodingshrimp, thanks for reaching out! We will take a look at errors and docs(they are indeed outdated). Overall, as far as I understand, the docs are a bit misleading in that case, because you don't really need to run the API yourself to prove a batch.

• If you run server and prover components locally, the batch data should be just passed through with help of proof-data-handler and prover-gateway components.
• If you want to prove a batch from real environment, you have the following APIs that you can access:
  • mainnet - https://prover-api.zksync.io
  • testnet - https://prover-api.testnet-sepolia.era.zksync.dev
• Overall, the API will be able to send the data and verify the batches only if the proof for a batch is already in server's storage - only then you'll be able to access it through prover API. If you are running it locally it should just work out of the box.

[thecodingshrimp]

@EmilLuta sorry for the delays, I was off myself for the last week.

1. You used prover api to get proofs & it failed due to incompatibility (json vs other formats).

If you mean with prover api the external_proof_integration_api API component from the zkstack server command, then yes.

3. You are trying to generate proofs, but fail to send them to the sequencer.

No. I was able to generate proofs, compress, and finalize them on l1 already. My question is about the possibility of getting the proofs binary from the external_proof_integration_api API component from the zkstack server command and then validating the proof via the same component. According to your website it should be possible to verify the finalized and compressed proof settled on l1 this way. Am I wrong?

What are the exact problems you are facing on communication? You mentioned "client and how the server's api is accessed", but I'm not sure I know which of them you mean:
3.1. client as in proof_data_handler client or some other client (I.E. EthSender)
3.2. server's API as in proof_data_handler, Prover API, maybe some database access?

My problem is reaching the external_proof_integration_api API component from the zksync era server with a simple curl command, like I described in the problem description above. I hope that makes it more clear.

[EmilLuta]

Ah, this definitely helps, thanks!

I'll go through each paragraph/answer. On the first one, indeed, that's not something we usually run on any other stack but ZKsync ERA. The reason behind it -- we run it for ZKsync ERA to help with prover decentralization (have external parties retrieve proof inputs such that they can generate a proof that then we can validate against our backend).

As such, think of that component as "private" or "internal". We might be breaking that version more often than the rest of the stack.

possibility of getting the proofs binary from the external_proof_integration_api

That service is only meant to provide prover input & verify a proof against an already generated proof by the sequencer. The reason you might not be able to do so is either:

1. the proof you tried to validate was incorrect (if you used the one on your sequencer that was settled on L1, very unlikely, but it's possible you used a different intermediary format)
2. we might've broken the backwards compatibility setup for the specific version you're running on.

a simple curl command

Looking at your requests, I see:

< HTTP/1.1 415 Unsupported Media Type
< content-type: text/plain

Can you please use content type json (Content-Type: application/json)?

On the second request, it must be a GET. You're using a POST.

Hope this answers and thanks for the clarifications!

[thecodingshrimp]

@EmilLuta thanks for the clarification on external_proof_integration_api! Does that mean in turn that zkStack server does not provide an API endpoint where I can fetch the generated proof binary? Meaning, that I would have to provide either a custom API endpoint for clients to download the proof binary or setup a cloud blob storage container where I make the proofs available to the public?

As such, think of that component as "private" or "internal". We might be breaking that version more often than the rest of the stack.

Isn't that counter intuitive? Shouldn't people on the public network be able to validate your proofs verifying the state of l2 on l1 at all times? Or is that possible through another part of your system?

Looking at your requests, I see:
< HTTP/1.1 415 Unsupported Media Type
< content-type: text/plain
Can you please use content type json (Content-Type: application/json)?

According to the implementation of the endpoint /verify_proof/{batch_nr} (defined here), your server requires an "application/octet-stream" (see ExternalProof). This is also backed by the documentation on how to validate a prove with the sequencer. I don't know how to use application/json in this case, could you provide me with an example?

On the second request, it must be a GET. You're using a POST.

You mean the other way around, right? I'm using a GET and it tells me I should use a POST instead. I pointed out in the original post that it somehow expects a POST for a GET endpoint (according to the /proof_generation_data endpoint in the external_proof_integration_api component it says clearly that its a GET endpoint).

[EmilLuta]

Does that mean in turn that zkStack server does not provide an API endpoint where I can fetch the generated proof binary?

Yes, that's correct.

Isn't that counter intuitive? Shouldn't people on the public network be able to validate your proofs verifying the state of l2 on l1 at all times? Or is that possible through another part of your system?

The expectation is that they would do so on L1/Settlement Layer (and not server side). The proofs themselves are validated on-chain, so I'm not sure why people on the public network would need them from a centralized (potentially malicious) server when they have all the data needed on-chain.

I'm not sure for the other 2 endpoints, but I can loop @Artemka374 who developed them. I've tested them locally (a long-long time ago) and I know we have partners who are integrating with them (in our production environment for ZKsync Era).

Hope this helps.