feat(proof_data_handler): add new endpoints to the TEE prover interface API

[pbeza]

What ❔

This PR introduces three new endpoints to the prover interface API:

1. /tee/proof_inputs - for fetching input data for the TEE verifier. It is intended for TEE workers to obtain a batch to process.
2. /tee/submit_proofs/<l1_batch_number> - for submitting TEE proof.
3. /tee/register_attestation - for registering TEE attestation.

The first two introduced API endpoints correspond to the existing, analogous /proof_generation_data and /submit_proof/<l1_batch_number> endpoints used for the ZK proofs.

The state of batches (e.g., proven, taken, etc.) is tracked in the database. The TeeVerifierInputProducer generates serialized TEE prover inputs, which are then stored in the object store.

To run the unit tests, you need to use the following command: zk test rust --package zksync_proof_data_handler --lib tests. Running cargo test directly fails because the zk command sets up an additional database for testing purposes.

To test it manually, run the ZK server with the command:

zk server --components proof_data_handler --use-node-framework

and then send an HTTP request:

• to get TEE verifier input data:

  curl -X POST -H "Content-Type: application/json" --data-raw "{}" -vvv http://127.0.0.1:3320/tee/proof_inputs
  

  To inspect the database for the TEE verifier input data jobs, run:

  $ PGPASSWORD='notsecurepassword' psql -h 127.0.0.1 -p 5432 -U postgres
  # \c zksync_local
  # SELECT * FROM tee_verifier_input_producer_jobs;
  

• register TEE attestation:

  curl -X POST -H "Content-Type: application/json" --data-raw '{ "attestation": [ 4, 3, 2, 1, 0 ], "pubkey": [ 5, 6, 7, 8, 9 ] }' -vvv http://127.0.0.1:3320/tee/register_attestation
  

  To inspect the database for the TEE attestations, run:

  $ PGPASSWORD='notsecurepassword' psql -h 127.0.0.1 -p 5432 -U postgres
  # \c zksync_local
  # SELECT * FROM tee_attestations;
  

• to submit TEE proof:

  curl -X POST -H "Content-Type: application/json" --data-raw '{ "signature": [ 0, 1, 2, 3, 4 ], "pubkey": [ 5, 6, 7, 8, 9 ], "proof": [ 10, 11, 12, 13, 14 ] }' -vvv http://127.0.0.1:3320/tee/submit_proofs/1
  

  To inspect the database for the TEE proofs, run:

  $ PGPASSWORD='notsecurepassword' psql -h 127.0.0.1 -p 5432 -U postgres
  # \c zksync_local
  # SELECT * FROM tee_proof_generation_details;
  

Why ❔

This PR contributes to the effort outlined in the docs:

• https://www.notion.so/matterlabs/2FA-for-zk-rollups-with-TEEs-a2266138bd554fda8846e898fef75131?pvs=4
• https://www.notion.so/matterlabs/Proof-2F-verification-with-SGX-5fca2c619dd147938971cc00ae53e2b0?pvs=4

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zk fmt and zk lint.
• Spellcheck has been run via zk spellcheck.

[pbeza]

@popzxc @RomanBrodetski @haraldh @thomasknauth Again: CI checks are passing, and manual tests have been successfully redone. From my perspective, it's ready to merge. ✅

Sorry for the mess with rebasing and force pushing. I didn't expect it to make incremental code review harder. I will merge instead of rebase next time.

[popzxc]

👍

[pbeza]

@popzxc @RomanBrodetski are we good to merge? This is my first PR to be merged, so I'm not sure about the process. How many reviewers need to approve it before we can merge?

[popzxc]

@pbeza generally up to the reviewee. If your PR is approved, you are free to merge, but it's not uncommon

• either for the reviewer to suggest waiting for a 2nd review (e.g. if reviewer doesn't feel confident about some part of the diff), or
• for the reviewee to ask for more reviews (e.g. if the change is complex and they want more eyes to at least skim through it).

So overall, we trust people to decide what would be the safest and most productive approach.

[pbeza]

Got it, I don't have permission to merge, which is why I asked. Thanks for the clarification.