Merge branch 'v2' of https://github.com/summa-dev/summa-solvency into v2

.github/workflows/benchmark.yml

@@ -8,17 +8,23 @@ on:
         required: true
         default: 'no'
 
+<<<<<<< HEAD
 env:
   CARGO_TERM_COLOR: always
 
+=======
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 jobs:
   wakeup:
     runs-on: ubuntu-latest
     if: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.run_benchmark == 'yes' }}
     permissions:
       id-token: write
       contents: read
+<<<<<<< HEAD
 
+=======
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
     steps:
       - uses: actions/checkout@v3
 
@@ -39,13 +45,23 @@ jobs:
     steps:
       - uses: actions/checkout@v3
 
+<<<<<<< HEAD
       - name: Run Benchmark
         run: |
           cd zk_prover
+=======
+      - name: Run Benchmark Tests
+        run: |
+          cd prover
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
           cargo bench
 
       - name: Upload Benchmark Results
         uses: actions/upload-artifact@v2
         with:
           name: benchmark-results
+<<<<<<< HEAD
           path: zk_prover/target/criterion
+=======
+          path: prover/target/criterion
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee

.github/workflows/contracts.yml

@@ -20,4 +20,8 @@ jobs:
       - name: Run Tests
         run: |
           cd contracts
+<<<<<<< HEAD
           npx hardhat node & npx hardhat test
+=======
+          npx hardhat test
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee

.github/workflows/rust.yml

@@ -46,8 +46,9 @@ jobs:
       - name: Install solc
         run: (hash svm 2>/dev/null || cargo install --version 0.2.23 svm-rs) && svm install 0.8.20 && solc --version
 
-      - name: Test Zk Prover
+      - name: Test KZG Prover
         run: |
+<<<<<<< HEAD
           cd zk_prover
           cargo test --release --features dev-graph -- --nocapture
 
@@ -58,6 +59,10 @@ jobs:
           cargo run --release --example gen_commitment
           cargo run --release --example gen_inclusion_proof
           cargo run --release --example nova_incremental_verifier
+=======
+          cd prover
+          cargo test --release -- --nocapture
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 
       - name: Install Foundry
         uses: foundry-rs/foundry-toolchain@v1

README.md

@@ -4,7 +4,7 @@ A monorepo for Summa, zk proof of solvency protocol
 
 ### Subdirectories
 
-- `zk_prover`: Halo2 based zk prover for Summa
+- `prover`: Halo2 based zk prover and KZG polynomial interpolation for Summa
 - `contracts`: Solidity smart contracts for Summa
 - `backend` : Rust API to interact with Summa
 

backend/Cargo.toml

@@ -6,17 +6,31 @@ edition = "2021"
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
 [dependencies]
+<<<<<<< HEAD
 summa-solvency = { path = "../zk_prover" }
+=======
+summa-solvency = { path = "../prover" }
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 halo2_proofs = { git = "https://github.com/summa-dev/halo2"}
 csv = "1.2.2"
 num-bigint = "0.4.3"
 serde = { version = "1.0.166", features = ["derive"] }
+<<<<<<< HEAD
+=======
+halo2_solidity_verifier = { git = "https://github.com/summa-dev/halo2-solidity-verifier", version = "0.1.0", features = ["evm"] }
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 ethers = { version = "2.0.7", default-features = false, features = ["ethers-solc", "legacy"] }
 reqwest = { version = "0.11", features = ["json"] }
 serde_json = "1.0.64"
 tokio = { version = "1.7.1", features = ["full"] }
 base64 = "0.13"
+<<<<<<< HEAD
 num-traits = "0.2.14"
+=======
+bincode = "1.3.3"
+num-traits = "0.2.14"
+rand = "0.8.5"
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 
 [build-dependencies]
 ethers = { version = "2.0.7", default-features = false, features = ["ethers-solc", "legacy"] }

backend/README.md

@@ -27,15 +27,15 @@ Key Features:
 
 ## Prerequisites
 
-The `ptau` file, containing the Powers of Tau trusted setup parameters needed to build the zk circuits, is already included. However, if you wish to test or run the code with a higher number of entries, you may choose to download a different `ptau` file.
+Before testing or running the Summa backend, the ptau file, containing the Powers of Tau trusted setup parameters essential for building the ZK circuits, must be downloaded. Specifically, the `hermez-raw-17` file is required for the [Summa flow](./examples/summa_solvency_flow.rs) example and its associated test case.
 
-You can find the necessary files at https://github.com/han0110/halo2-kzg-srs. To download a specific file, you can use:
+You can find this and other necessary files at https://github.com/han0110/halo2-kzg-srs. To download `hermez-raw-17`, use the command:
 
 ```
-wget https://trusted-setup-halo2kzg.s3.eu-central-1.amazonaws.com/hermez-raw-11
+wget https://trusted-setup-halo2kzg.s3.eu-central-1.amazonaws.com/hermez-raw-17
 ```
 
-After downloading, pass the path to the desired file to the `Snapshot::new` method. If you are using the included `ptau` file, no additional steps are necessary.
+Ensure this file is downloaded before proceeding with the example or test case.
 
 ## Running Test
 
@@ -50,7 +50,11 @@ cargo test --release -- --nocapture
 
 ### Generating and updating verifier contract for Backend
 
+<<<<<<< HEAD
 The verifier contract in the backend were generated using a predefined set of parameters: `N_CURRENCIES = 2` and `N_BYTES=8`, as indicated [here](https://github.com/summa-dev/summa-solvency/blob/master/zk_prover/examples/gen_inclusion_verifier.rs#L21-L22).
+=======
+The verifier contract in the backend were generated using a predefined set of parameters: `N_CURRENCIES = 2`, `N_USERS = 16` and `K = 17` as indicated [here](../prover/bin/gen_verifier.rs#L26-L28)
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 If you intend to work with different parameters, you'll need to adjust these hard-coded values and then generate new verifier contract.
 
 The process described below assists in both generating the verifier and updating the Summa contract, which integrates the new verifier as constructors.
@@ -95,17 +99,30 @@ If executed successfully, you'll see:
 
 ### 2. Submit Commitment
 
+<<<<<<< HEAD
 The CEX must submit a commitment to the Summa contract for each round. This commitment consists of a `timestamp`, the root hash of the Merkle Sum Tree (`mst_root`), and `balances`.
 
 Without publishing the commitment, users cannot verify their inclusion proof on the Summa contract. This is because the inclusion verifier function internally requires the `mst_root`, but users only know the `timestamp` associated with the round and the verifier functions does not requre `mst_root` directly.
+=======
+The CEX must submit a commitment to the Summa contract for each round. This commitment consists of a timestamp, a SNARK proof, a grand sum proof and total balances.
+
+Without CEX publishing the commitment, users cannot verify their inclusion proof on the Summa contract. This is because the inclusion verifier function internally requires the SNARK proof, but users only know the timestamp associated with the round and the verifier functions does not requre the SNARK proof directly.
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 
 In here, we'll introduce you through the process of submitting a commitment using the `Round` to the Summa contract.
 The Round serves as the core of the backend in Summa, and we have briefly described it in the Components section.
 
+<<<<<<< HEAD
 To initialize the `Round` instance, you'll need paths to the liabilities CSV file (`entry_16.csv`) and the `ptau/hermez-raw-11` file. The files serve the following purpose:
 
 - `entry_16.csv`: contains the username and liabilities entries for each CEX user (necessary to build the commitment). Liabilities column names have the following format: `balance_<CRYPTOCURRENCY>_<CHAIN>`, where <CRYPTOCURRENCY> and <CHAIN> are the names of the cryptocurrencies and their corresponding blockchains. <CHAIN> values are the same as in the Address Ownership Proof step;
 - `ptau/hermez-raw-11`: contains parameters for constructing the zk circuits.
+=======
+To initialize the `Round` instance, you'll need paths to the liabilities CSV file (`entry_16.csv`) and the `ptau/hermez-raw-17` file. The files serve the following purpose:
+
+- `entry_16.csv`: contains the username and liabilities entries for each CEX user (necessary to build the commitment). Liabilities column names have the following format: `balance_<CRYPTOCURRENCY>_<CHAIN>`, where <CRYPTOCURRENCY> and <CHAIN> are the names of the cryptocurrencies and their corresponding blockchains. <CHAIN> values are the same as in the Address Ownership Proof step;
+- `ptau/hermez-raw-17`: contains parameters for constructing the zk circuits.
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 
 Using the `Round` instance, the solvency proof is dispatched to the Summa contract with the `dispatch_solvency_proof` method.
 
@@ -117,7 +134,7 @@ If this step successfully ran, you can see this message:
 
 ### 3. Generating and Exporting Inclusion Proofs
 
-Assuming you're a CEX, after committing the `solvency` and `ownership` proofs to the Summa contract, you should generate inclusion proofs for every user. This proof verifies the presence of specific elements in the Merkle sum tree, which is part of the solvency proof.
+Assuming you're a CEX, after committing the commitment and ownership proofs to the Summa contract, you should generate inclusion proofs for every user. This proof verifies the presence of specific elements in the polynomials encoding the username, balances.
 
 After generating the inclusion proof, it's transformed into a JSON format for easy sharing.
 
@@ -135,18 +152,27 @@ Users receive the proof for a specific round and use methods available on the de
 
 In this step, the user has to:
 
+<<<<<<< HEAD
 - Ensure the `leaf_hash` (public input of the proof) aligns with the Poseidon hash of the `username` and `balances` provided by the CEX.
 - Submit the proof to the `verify_inclusion_proof` method on the Summa contract Which will:
   - Retrieve the `mstRoot` from the Summa contract and match it with the `root_hash` in the proof.
   - Retrieve the `rootBalances` from the Summa contract and match it with the `root_balances` in the proof
   - Verify the zk Proof
+=======
+- Ensure the user values in the proof file aligns with `username` and `balances` provided by the CEX.
+- Submit the proof to the `verify_inclusion_proof` method on the Summa contract.
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 
 The result will display as:
 
 ```
 4. Verifying the proof on contract verifier for User #0: true
 ```
 
+<<<<<<< HEAD
 **Note:** In a production environment, users can independently verify their proof using public interfaces, such as Etherscan, as shown below:
 ![Summa contract interface on Etherscan](summa_verifier_interface.png)
 This offers an added layer of transparency and trust.
+=======
+**Note:** In a production environment, users can independently verify their proof using public interfaces, such as Etherscan.
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee

backend/build.rs

@@ -9,6 +9,24 @@ fn main() {
             "Summa",
         ),
         (
+<<<<<<< HEAD
+=======
+            "src/contracts/generated/verifying_key.rs",
+            "Halo2VerifyingKey",
+            "VerifyingKey",
+        ),
+        (
+            "src/contracts/generated/snark_verifier.rs",
+            "Verifier",
+            "SnarkVerifier",
+        ),
+        (
+            "src/contracts/generated/grandsum_verifier.rs",
+            "GrandSumVerifier",
+            "GrandSumVerifier",
+        ),
+        (
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
             "src/contracts/generated/inclusion_verifier.rs",
             "InclusionVerifier",
             "InclusionVerifier",

backend/examples/summa_solvency_flow.rs

@@ -2,20 +2,44 @@
 use std::{error::Error, fs::File, io::BufReader, io::Write};
 
 use ethers::types::U256;
+<<<<<<< HEAD
+=======
+use halo2_proofs::halo2curves::bn256::Fr as Fp;
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 use serde_json::{from_reader, to_string_pretty};
 
 use summa_backend::{
     apis::{
         address_ownership::AddressOwnership,
+<<<<<<< HEAD
         leaf_hash_from_inputs,
         round::{MstInclusionProof, Round},
+=======
+        round::{KZGProof, Round},
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
     },
     contracts::signer::{AddressInput, SummaSigner},
     tests::initialize_test_env,
 };
+<<<<<<< HEAD
 use summa_solvency::merkle_sum_tree::MerkleSumTree;
 
 const N_CURRENCIES: usize = 2;
+=======
+use summa_solvency::{
+    circuits::{
+        univariate_grand_sum::{UnivariateGrandSum, UnivariateGrandSumConfig},
+        utils::{full_prover, generate_setup_artifacts},
+    },
+    cryptocurrency::Cryptocurrency,
+    entry::Entry,
+    utils::parse_csv_to_entries,
+};
+
+const K: u32 = 17;
+const N_CURRENCIES: usize = 2;
+const N_USERS: usize = 16;
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 const USER_INDEX: usize = 0;
 
 #[tokio::main]
@@ -57,6 +81,7 @@ async fn main() -> Result<(), Box<dyn Error>> {
     // 2. Submit Commitment
     //
     // Initialize the `Round` instance to submit the liability commitment.
+<<<<<<< HEAD
     let params_path = "ptau/hermez-raw-11";
     let entry_csv = "../csv/entry_16.csv";
     let mst = MerkleSumTree::from_csv(entry_csv).unwrap();
@@ -68,6 +93,48 @@ async fn main() -> Result<(), Box<dyn Error>> {
     // Sends the commitment, which should ideally complete without errors.
     round.dispatch_commitment().await?;
 
+=======
+    let entry_csv = "../csv/entry_16.csv";
+    let mut entries: Vec<Entry<N_CURRENCIES>> = vec![Entry::init_empty(); N_USERS];
+    let mut cryptos = vec![Cryptocurrency::init_empty(); N_CURRENCIES];
+    parse_csv_to_entries::<&str, N_CURRENCIES>(entry_csv, &mut entries, &mut cryptos).unwrap();
+
+    let univariate_grand_sum_circuit = UnivariateGrandSum::<
+        N_USERS,
+        N_CURRENCIES,
+        UnivariateGrandSumConfig<N_CURRENCIES, N_USERS>,
+    >::init(entries.to_vec());
+
+    // This ptau file is also utilized in the generation of the verifier contract.
+    // It corresponds to the same file used in the `gen_verifier.rs` script.
+    let params_path = "../backend/ptau/hermez-raw-17";
+    let (params, pk, vk) =
+        generate_setup_artifacts(K, Some(params_path), &univariate_grand_sum_circuit).unwrap();
+
+    // Create a proof
+    let instances = vec![Fp::zero(); 1]; // This instance is necessary to verify proof on solidity verifier.
+    let (zk_snark_proof, advice_polys, _) = full_prover(
+        &params,
+        &pk,
+        univariate_grand_sum_circuit.clone(),
+        &[instances.clone()],
+    );
+
+    // Using the `round` instance, the commitment is dispatched to the Summa contract with the `dispatch_commitment` method.
+    let timestamp = 1u64;
+    let mut round = Round::<N_CURRENCIES, N_USERS>::new(
+        &signer,
+        zk_snark_proof,
+        advice_polys,
+        params,
+        vk,
+        timestamp,
+    );
+
+    // Sends the commitment, which should ideally complete without errors.
+    round.dispatch_commitment().await?;
+
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
     println!("2. Commitment is submitted successfully!");
 
     // 3. Generate Inclusion Proof
@@ -88,18 +155,18 @@ async fn main() -> Result<(), Box<dyn Error>> {
 
     // 4. Verify Inclusion Proof
     //
-    // The `snapshot_time` denotes the specific moment when entries were created for the Merkle sum tree.
+    // The `snapshot_time` denotes the specific moment when entries were created for polynomal interpolation.
     // This timestamp is established during the initialization of the Round instance.
-    let snapshot_time = U256::from(1);
+    let snapshot_time = U256::from(timestamp);
 
     // When verifying the inclusion proof from the user's perspective, the user have to fetch `proof`.
     // Assume that the `proof` file has been downloaded from the CEX.
     let proof_file = File::open(format!("user_{}_proof.json", USER_INDEX))?;
     let reader = BufReader::new(proof_file);
-    let downloaded_inclusion_proof: MstInclusionProof = from_reader(reader)?;
 
-    let public_inputs = downloaded_inclusion_proof.get_public_inputs();
+    let downloaded_inclusion_proof: KZGProof = from_reader(reader)?;
 
+<<<<<<< HEAD
     // Verify the `leaf_hash` from the proof file.
     // It's assumed that both `user_name` and `balances` are provided by the CEX.
     // The `balances` represent the user's balances on the CEX at `snapshot_time`.
@@ -123,6 +190,29 @@ async fn main() -> Result<(), Box<dyn Error>> {
     let verification_result = summa_contract
         .verify_inclusion_proof(proof.clone(), public_inputs.clone(), snapshot_time)
         .await?;
+=======
+    // Fetch commitment data from the contract with timestamp, `snapshot_time`.
+    let commitment = summa_contract.commitments(snapshot_time).call().await?;
+
+    // Ensure the length of the commitment matches the expected size for the number of points.
+    assert_eq!(commitment.to_vec().len(), 0x40 * (N_CURRENCIES + 1));
+
+    // Validate the inclusion proof using the contract verifier.
+    let mut verification_result = false;
+
+    if let Some(challenges) = downloaded_inclusion_proof.get_challenge().as_ref() {
+        verification_result = summa_contract
+            .verify_inclusion_proof(
+                snapshot_time,
+                inclusion_proof.get_proof().clone(),
+                challenges.clone(),
+                inclusion_proof.get_input_values().clone(),
+            )
+            .await?;
+    } else {
+        eprintln!("No challenges found in the proof, This may not a inclusion proof");
+    }
+>>>>>>> fec83a747ead213261aecfaf4a01b43fff9731ee
 
     println!(
         "4. Verifying the proof on contract veirifer for User #{}: {}",