If you'd like a genuinely random number, this link will generate a number in the given range. Just plug the value into the url above and download the file.
1.2 Rename the file
Next, rename the file to something unique. It is important that the entire proof request be a unique string. This may be done via unique input files, or accomplished with a nonce (not used here).
For this example, we have downloaded witness-46807.json and renamed it here:
~/Downloads/mynewwitness-46807.json
1.3 Calculate the hash
For this step, you will need to have built gevulot-cli and have it in your path. Call it with the calculate-hash action, and pass in the witness file.
gevulot-cli calculate-hash --file ~/Downloads/mynewwitness-46807.json
The hash of the file is: 77263b62caae635536c7fefe99e249c55dec5625fecdb550cf83c26108e3f03a
1.4 Upload to a public http server
Lastly, you will need a public url for for the file. An S3 bucket would be one option. Just make sure the file has public read permissions.
Execute the proof
2.1 The parameters structure for the proof
Use the json structure below as a template for creating the parameter inputs. You will observe:
three arguments are passed in as key/value pairs
two folders are used
the /gevulot path is used for static files embedded in the prover image. In this case, there is one, a 512MB proof parameters file, with degree k = 22.
the /workspace path is used for dynamic file instances
one input file is passed in, namely our witness. Edit the url and hash values, the latter associated with the local_path property.
the output proof from the prover is referenced as an input into the verifier.
In sum, you will have to edit witness file data in four places:
the argument list, for the -w parameter
the vm-path property
the file_url property
the local_path property, which holds the file hash string
Programs send to execution correctly. Tx hash:7bdd606c3ba5c5c34e32a598dba8ecd8b0964918a29508fc33e286fce8e5e092
Verify the results
Use the transaction hash to get the verifier output.
3.1 View the transaction
First, you can query the transaction itself, by calling gevulot-cli with the get-tx action and the hash. It will return the parameters passed into the exec call, along with some additional metadata.
Now, print out the transaction tree using the print-tx-tree action and the txhash you got back from the exec call. The tree will eventually contain leaves, from which you can read the verifier results.
In the case of The Taiko prover, it can take 6-7 minutes for a proof to complete. Until then, no tree will be found.
An error while fetching transaction tree: RPC response error:not found: no root tx found for e462679e6d3345d76005ee42301e01065db688e080c10adb2648ad645c77d1a5
When the proof completes, you will see a tree like this
Under payload.Verification.verification, we see a string encoded as base64. Use jq plus base64 to decode that at the command line. Now we can read the json text generated by the verifier.
