feat: generate params utility (#325)

# Rationale for this change

Initial parameter generation can be expensive depending on the size of
the setups. Since the prover needs to be restarted as easily and quickly
as possible, parameters should be pre-generated in some transparent
process and made available for easy access.

# What changes are included in this PR?

- [x] Add a CLI for generation of public parameters and setups
- [x] Support file I/O for various proof components

# Are these changes tested?
- [x] Round trip file I/O test
- [x] Test digests successfully created

.gitignore

@@ -64,3 +64,6 @@ metastore_db
 # forge test files
 out
 cache
+
+# any output files from generating public params
+output/

Cargo.toml

@@ -36,6 +36,7 @@ curve25519-dalek = { version = "4", features = ["rand_core"] }
 derive_more = { version = "0.99" }
 flexbuffers = { version = "2.0.0" }
 indexmap = { version = "2.1", default-features = false }
+indicatif = "0.17.8"
 itertools = { version = "0.13.0", default-features = false, features = ["use_alloc"] }
 lalrpop = { version = "0.22.0" }
 lalrpop-util = { version = "0.22.0", default-features = false }
@@ -48,13 +49,16 @@ postcard = { version = "1.0" }
 proof-of-sql = { path = "crates/proof-of-sql" } # We automatically update this line during release. So do not modify it!
 proof-of-sql-parser = { path = "crates/proof-of-sql-parser" } # We automatically update this line during release. So do not modify it!
 rand = { version = "0.8", default-features = false }
+rand_chacha = { version = "0.3.1" }
 rand_core = { version = "0.6", default-features = false }
 rayon = { version = "1.5" }
 serde = { version = "1", default-features = false }
 serde_json = { version = "1", default-features = false, features = ["alloc"] }
+sha2 = "0.10.8"
 snafu = { version = "0.8.4", default-features = false }
 sqlparser = { version = "0.45.0", default-features = false }
 tiny-keccak = { version = "2.0.2", features = [ "keccak" ] }
+tempfile = "3.13.0"
 tracing = { version = "0.1.36", default-features = false }
 tracing-opentelemetry = { version = "0.22.0" }
 tracing-subscriber = { version = "0.3.0" }

crates/proof-of-sql/Cargo.toml

@@ -30,20 +30,24 @@ blitzar = { workspace = true, optional = true }
 bumpalo = { workspace = true, features = ["collections"] }
 bytemuck = { workspace = true }
 byte-slice-cast = { workspace = true }
+clap = { workspace = true, features = ["derive"] }
 curve25519-dalek = { workspace = true, features = ["serde"] }
 chrono = { workspace = true, features = ["serde"] }
 derive_more = { workspace = true }
 indexmap = { workspace = true, features = ["serde"] }
+indicatif = { workspace = true }
 itertools = { workspace = true }
 merlin = { workspace = true, optional = true }
 num-traits = { workspace = true }
 num-bigint = { workspace = true, default-features = false }
 postcard = { workspace = true, features = ["alloc"] }
 proof-of-sql-parser = { workspace = true }
 rand = { workspace = true, default-features = false, optional = true }
+rand_chacha = { workspace = true}
 rayon = { workspace = true, optional = true }
 serde = { workspace = true, features = ["serde_derive"] }
 serde_json = { workspace = true }
+sha2 = { workspace = true }
 snafu = { workspace = true }
 sqlparser = { workspace = true }
 tiny-keccak = { workspace = true }
@@ -62,6 +66,7 @@ opentelemetry-jaeger = { workspace = true }
 rand = { workspace = true, default-features = false }
 rand_core = { workspace = true, default-features = false }
 serde_json = { workspace = true }
+tempfile = { workspace = true }
 tracing = { workspace = true }
 tracing-opentelemetry = { workspace = true }
 tracing-subscriber = { workspace = true }
@@ -83,6 +88,11 @@ std = ["snafu/std"]
 [lints]
 workspace = true
 
+[[bin]]
+name = "generate-parameters"
+path = "utils/generate-parameters/main.rs"
+required-features = [ "std", "blitzar"]
+
 [[example]]
 name = "hello_world"
 required-features = ["test"]

crates/proof-of-sql/utils/generate-parameters/README.md

@@ -0,0 +1,68 @@
+# Space and Time ParamGen
+
+A simple tool to generate the Space and Time public network parameters.
+
+## 📑 Table of Contents
+
+- [🚀 Quick Start](#quick-start)
+- [📚 Background](#background)
+- [📚 Additional Resources](#additional-resources)
+
+## <a name="quick-start"></a>🚀 Quick Start
+
+Ensure that you have rust installed. Then, clone this repo and simply run the following:
+
+```bash
+cargo run --release --bin generate-parameters
+```
+
+This generates the setups for both the prover and verifer as two seperate tar.gz files with a default nu value of 14. It saves these parameters at the head of this repo as tar.gz archives.
+
+| Description     | Command | 
+| --------------- | --------------- | 
+| Run the Prover setup only     | ```cargo run --release --bin generate-parameters -- --mode prover```     | 
+|Run the Verifier setup only    | ```cargo run --release --bin generate-parameters -- --mode verifier```    | 
+| Run both Prover and Verifier setups with a custom nu value   | ```cargo run --release --bin generate-parameters -- --mode all --nu 4```    | 
+| Specify an output directory (with --target argument)    | ```cargo run --release --bin generate-parameters -- --mode all --target ./output ```     | 
+
+## <a name="background"></a>📚 Background
+
+### What are public parameters?
+
+There are a wide variety of zero-knowledge proof and argument systems, all offering different performance characterists. The classic example is the [Groth16](https://eprint.iacr.org/2016/260.pdf) argument, a commonly used proof system which establishes a trusted setup (known formally as a common reference string (CRS) or structured reference string (SRS)) to be shared among participants in the network. This setup is structured in such a way that allows arguments of valid computation to be produced with very small sizes. In the case of Groth16, this can be as low as a few group elements or a couple hundred bytes, which is the perfect size to store on a blockchain.
+
+The Space and Time network makes use of a few different argument systems. The Dory polynomial commitment scheme (PCS) is is a SNARK which requires a setup to be established between the proving and verifying parties. The Dory PCS is chosen because it is ammenable to forming proofs and arguments over matrices, which is perfect for the Proof-Of-SQL case, since databases and tables are essentially matrices. The Dory setup process is unique in that it is *transparent*, meaning there is no toxic waste or secret values to forget once the setup is complete. The setup is initialized with an arbitrary random string which establishes common parameters. We choose the random string "SpaceAndTime" for our setup. This string is a "[Nothing-up-my-sleeve number](https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number)", meaning it is easily auditable and has no hidden structure that can be exploited to generate false proofs or compromise the integrity of the system.
+
+The Space and Time implementation of the [Dory PCS](https://eprint.iacr.org/2020/1274) is non-zero knowledge and does not explicty blind the inputs used in the argument of correct sql execution. This yields a leaner implementation and slightly better performance. We may add zero-knowledge blinding in the future, but for now it is not necessary for Proof-Of-SQL to function correctly.
+
+This tool generates the public setups for either the prover or verifier. Both setups are parameterized over a value *nu*, which helps establish the maximum dimension of the table that can be argued against. The prover and the verifer both posses a slightly different setup. The verifier setup is relatively cheap to compute and scales linearly for large nu/table sizes. The prover setup is larger and has a higher cost to compute. We provide pre-computed setups that can easily be downloaded and used with the SxT network in order to skip the expensive generation process, but this repo contains a tool to generate the parameters at your option.
+
+### Table Sizes
+
+The maximum table supported table size for parameters generated by this tool is determined by the value of max nu. For Dynamic Dory, that size is $2^{2 \nu - 1}$. This translates into the number of rows that the parameter can support below:
+
+| ν (nu) | Number of rows    |
+|--------|-------------------|
+|    8   | 33 thousand       |
+|    9   | 131 thousand      |
+|   10   | 524 thousand      |
+|   11   | 2.10 million      |
+|   12   | 8.39 million      |
+|   13   | 33.55 million     |
+|   14   | 134.22 million    |
+|   15   | 536.87 million    |
+|   16   | 2.15 billion      |
+|   17   | 8.59 billion      |
+|   18   | 34.36 billion     |
+|   19   | 137.44 billion    |
+|   20   | 549.76 billion    |
+
+
+NOTE: Setups using the same random string but different nu values remain compatible with each other up to the minimum value of nu shared between them. SxT as of this writing uses a nu value of 16. Setups with smaller values of nu should be compatible with this setup.
+
+
+## <a name="additional-resources"></a>📚 Additional Resources
+
+- [Dory: Efficient, Transparent arguments for Generalised Inner Products and Polynomial Commitments](https://eprint.iacr.org/2020/1274)
+- [Groth16](https://eprint.iacr.org/2016/260.pdf)
+- [Nothing-up-my-sleeve number](https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number)