Prover

The section helps you create a prover image for markets with confidential inputs that will be used by enclave runners. The prover has three main components.

• generator-client: An HTTP API server used to set up the generator config JSON file required by the generator. The JSON config file includes the contract addresses and other details. It is also used for starting/stopping the generators and the listener.

• listener: Listens to newly assigned ask events and forwards the ask inputs to the respective generator based on the port defined in the config file by the user during the config setup. The listener also submits the proof returned by the generator on-chain.

• generator: Each generator is an HTTP server that is always listening for new ASK requests from the listener. The proof will be generated by the generator, and this proof will be returned to the listener to be submitted on-chain.

To create your own prover, you need to build a generator i.e zkapp_generatorexecutable that is will generator proof. zkapp_generator should expose some endpoints within enclave that will be used by other components of enclaves.

1. Clone a template repo

To create a prover, you need to clone the template prover and replace the proving service with your own service. The other components stay the same. Link to Template Prover

• Wrap Prover code into a server
  • as an example, zkapp_generator should expose endpoint POST /generateProof

API endpoints specification

1. POST /api/generateProof

   Body (JSON)

   {
       "ask": Ask,
       "private_input": Bytes,
       "ask_id": u64,
   }

   Ask struct for reference:

   {
       "market_id": U256,
       "reward": U256,
       "expiry": U256,
       "time_taken_for_proof_generation": U256,
       "deadline": U256,
       "refund_address": Address,
       "prover_data": Bytes,
   }

   Response

   Note : The data field will return the zero-knowledge proof along with status code 200 if the inputs are valid and signature along with status code 400 if the inputs are invalid.

   {
       "message": String,
       "data": String
   }

2. GET /api/benchmark

   Note : The data field should return the proof generation time in milliseconds along with a status code of 200.

   Resoponse

   {
       "message": String,
       "data": String
   }

2. Replace zkapp_generator and build image

You need to replace zkapp_generator with your own binaries. Your binaries must also be named zkapp_generator.

info

If you opt for some other name, don't forget to change the contents in Dockerfile and supervisor.d files

Now, run this command to build the image:

./build.sh

This will generate a file named nitro-enclave.eif.

Ensure that nitro-enclave.eif is saved. Especially on any publicly hosted link

warning

If you build again, the same build will not be generated.

3. Test the enclave

Test the enclave using the following command:

nitro-cli run-enclave --cpu-count4 --memory 5000 --eif-path nitro-enclave.eif --enclave-cid 88 --debug-mode

• Ensure that cid id 88 as it is used for communication to and from the enclave
• Check the logs of the enclave but only in debug mode using:

nitro-cli console --enclave-id $(nitro-cli describe-enclaves | jq -r ".[0].EnclaveID")

Whosoever wishes to run the same enclave can just fetch the nitro-cli.eif file and run it using the same command as above.