Removed MST approach on Polynomial Interpolation approach (#277)

* Removed MST approach, 'zk_prover' on v2

* updated README on contract

* Rename kzg_prover to prover

* Fix maximum entries in polynomial interpolation approach (#276)

* Add range check sufficiency explanation in the chip docs (#278)

---------

Co-authored-by: Alex Kuzmin <[email protected]>

.github/workflows/benchmark.yml

@@ -37,11 +37,11 @@ jobs:
 
       - name: Run Benchmark Tests
         run: |
-          cd kzg_prover
+          cd prover
           cargo bench
 
       - name: Upload Benchmark Results
         uses: actions/upload-artifact@v2
         with:
           name: benchmark-results
-          path: kzg_prover/target/criterion
+          path: prover/target/criterion

.github/workflows/rust.yml

@@ -46,21 +46,11 @@ 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
-        run: |
-          cd zk_prover
-          cargo test --release --features dev-graph -- --nocapture
-      
       - name: Test KZG Prover
         run: |
-          cd kzg_prover
+          cd prover
           cargo test --release -- --nocapture
 
-      - name: Test Nova Prover
-        run: |
-          cd zk_prover
-          cargo run --release --example nova_incremental_verifier
-
       - 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,7 +6,7 @@ edition = "2021"
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
 [dependencies]
-summa-solvency = { path = "../kzg_prover" }
+summa-solvency = { path = "../prover" }
 halo2_proofs = { git = "https://github.com/summa-dev/halo2"}
 csv = "1.2.2"
 futures = "0.3.28"

backend/README.md

@@ -50,7 +50,7 @@ cargo test --release -- --nocapture
 
 ### Generating and updating verifier contract for Backend
 
-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](../kzg_prover/bin/gen_verifier.rs#L26-L28)
+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)
 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.

backend/scripts/update_verifier_contract.sh

@@ -3,12 +3,12 @@ set -e
 
 # Build the verifier contract
 echo "1. Building verifier contracts"
-cd ../kzg_prover
+cd ../prover
 cargo run --release --bin generate_verifier
 
 # Generate Commitment and Proofs for Encoded Polynomials
 echo "2. Generate Commitment and Proofs for Encoded Polynomials"
-cd ../kzg_prover
+cd ../prover
 cargo run --release --bin generate_commitment_and_proofs
 
 # Deploy contracts to local environment

contracts/README.md

@@ -1,14 +1,16 @@
 # Summa Smart Contract
 
-The [Summa smart contract](src/Summa.sol) acts as a registrar for Centralized Exchanges (CEXs) to commit to their liabilities by submitting a Merkle sum tree (MST) root of all the CEX liabilities owed to its users. Users can then verify their inclusion into the liabilities commitment, and the public can compare the committed total sums with the assets owned by the CEX onchain.
+The [Summa smart contract](src/Summa.sol) serves as a registrar for Custodians to affirm their liabilities by submitting a polynomial commitment of all liabilities owed to their users. Users can verify their inclusion in the liabilities commitment, allowing public comparison of the committed total sums with the assets owned by the Custodian onchain.
+
 
 ## Features
 
-- **Address Ownership Proofs**: CEXs should submit the proof of address ownership for all addresses that hold the assets included into the commitment by using `submitProofOfAddressOwnership` function. The proofs are accepted optimistically and subject to off-chain verification.
+- **Address Ownership Proofs**: Custodians should submit proof of address ownership for all addresses holding assets included in the commitment using the `submitProofOfAddressOwnership` function. These proofs are accepted optimistically and subject to off-chain verification.
+
+- **Liabilities Commitments**: Custodians can commit to their liabilities in the form of polynomial commitments and the corresponding total sums representing snapshots of the liabilities at a given timestamp through the `submitCommitment` function.
 
-- **Liabilities Commitments**: CEXs can submit commitments to its liabilities in the form of MST roots and the corresponding total sums that represent the snapshots of the liabilities at a given timestamp by using `submitCommitment` function.
+- **Inclusion Verification**: Users can verify the polynomial commitment of their balances into the liabilities using the `verifyInclusionProof` function. This function calls the underlying smart contract [InclusionVerifier](src/InclusionVerifier.sol) module. refer to the module's [readme](./../prover/README.md) for details.
 
-- **Inclusion Verification**: Users are able to verify the zero-knowledge proof of inclusion of their balances into the MST using `verifyInclusionProof` function. The function is calling the underlying smart contract [Verifier](src/InclusionVerifier.sol). The verifier is generated from the [zk_prover](./../zk_prover/) module (see module's [readme](./../zk_prover/README.md)).
 
 ## Installation
 
@@ -36,14 +38,14 @@ npx hardhat coverage
 ## Deploying
 
 ```shell
-npx hardhat run scripts/deploy.ts --network localhost
+npx hardhat run scripts/deploy.ts
 ```
 
-The following Summa contract parameters are passed to its constructor inside the deployment script:
+The Summa contract deployment script is designed to streamline setup by automatically deploying three verifier contracts along with one verifying key contract. It then configures the deployment with specific parameters, which include:
+
+- The number of currencies;
+- the number of bytes used to represent the balance of a cryptocurrency in the polynomials;
 
-- verifier contract address (set automatically after the script deploys the verifier);
-- the number of levels of the Merkle sum tree;
-- the number of bytes used to represent the balance of a cryptocurrency in the Merkle sum tree.
+The deployment script updates the latest deployment address for the chain in the  [deployments](./../backend/src/contracts/deployments.json) file in the backend. This allows the backend module to connect to the deployed contract seamlessly.
 
-The deployment script writes the latest deployment address for the chain to the [deployments](./../backend/src/contracts/deployments.json) file in the backend project. This data can later be used by the backend module to connect to the deployed contract.
-The deployment script will copy the contract ABIs from the ./artifacts/src/ to the [backend](./../backend/src/contracts/abi/) module. The backend buildscript will then be able to generate the updated contract interfaces (see the backend [readme](./../backend/README.md)).
+Additionally, the script transfers the contract ABIs from `./artifacts/src/` to the [backend](./../backend/src/contracts/abi/) module. Subsequently, the backend build script generates the updated contract interfaces (for more details, see the backend [readme](./../backend/README.md)).

contracts/test/Summa.ts

@@ -384,7 +384,7 @@ describe("Summa Contract", () => {
       const commitmentCalldataJson = fs.readFileSync(
         path.resolve(
           __dirname,
-          "../../kzg_prover/bin/commitment_solidity_calldata.json"
+          "../../prover/bin/commitment_solidity_calldata.json"
         ),
         "utf-8"
       );
@@ -444,7 +444,7 @@ describe("Summa Contract", () => {
       const commitmentCalldataJson = fs.readFileSync(
         path.resolve(
           __dirname,
-          "../../kzg_prover/bin/commitment_solidity_calldata.json"
+          "../../prover/bin/commitment_solidity_calldata.json"
         ),
         "utf-8"
       );
@@ -457,7 +457,7 @@ describe("Summa Contract", () => {
       const inclusionCalldataJson = fs.readFileSync(
         path.resolve(
           __dirname,
-          "../../kzg_prover/bin/inclusion_proof_solidity_calldata.json"
+          "../../prover/bin/inclusion_proof_solidity_calldata.json"
         ),
         "utf-8"
       );

contracts/test/Verifiers.ts

@@ -14,7 +14,7 @@ describe("Verifier Contracts", () => {
       "src/VerifyingKey.sol:Halo2VerifyingKey",
     ) as Halo2VerifyingKey;
 
-    const commitmentJson = fs.readFileSync(path.resolve(__dirname, "../../kzg_prover/bin/commitment_solidity_calldata.json"), "utf-8");
+    const commitmentJson = fs.readFileSync(path.resolve(__dirname, "../../prover/bin/commitment_solidity_calldata.json"), "utf-8");
     const commitmentCalldata = JSON.parse(commitmentJson);
 
     return {
@@ -127,7 +127,7 @@ describe("Verifier Contracts", () => {
       const inclusionJson = fs.readFileSync(
         path.resolve(
           __dirname,
-          "../../kzg_prover/bin/inclusion_proof_solidity_calldata.json"
+          "../../prover/bin/inclusion_proof_solidity_calldata.json"
         ),
         "utf-8"
       );

kzg_prover/README.md → prover/README.md

@@ -25,7 +25,7 @@ Halo2 allows to efficiently implement the described algorithm for the following
 
 The algorithm works as follows:
 
-1. Assign all the user balances to an unblinded advice column of the [circuit](../kzg_prover/src/circuits/univariate_grand_sum.rs). The unblinded advice column is a special kind of advice column without the random values (blinding factors) added at the bottom. The constant term of such polynomial correctly yields the grand total of user balances according to (1) because the polynomial only interpolates the user balances but not the blinding factors (as in the case with a normal advice column).
+1. Assign all the user balances to an unblinded advice column of the [circuit](../prover/src/circuits/univariate_grand_sum.rs). The unblinded advice column is a special kind of advice column without the random values (blinding factors) added at the bottom. The constant term of such polynomial correctly yields the grand total of user balances according to (1) because the polynomial only interpolates the user balances but not the blinding factors (as in the case with a normal advice column).
 2. Assign the user IDs (e.g., hashes of user emails) to another (normal) advice column.
 3. Generate the ZK-SNARK proof for the circuit, effectively interpolating the balance values into a polynomial and performing a KZG commitment to this polynomial.
 4. Perform a KZG opening proof of the polynomial at $x=0$ and publicly reveal the constant term $a_0$ of the polynomial. The public can then calculate the liabilities by multiplying the $a_0$ by $d + 1$ where $d$ is the polynomial degree.
@@ -54,7 +54,7 @@ To generate commitments and proofs with the sample data located in `entry_16.csv
 cargo run --bin generate_commitment_and_proofs
 ```
 
-This script will generate `commitment_solidity_calldata.json` and `inclusion_proof_solidity_calldata.json` in the `kzg_prover/bin`.<br>
+This script will generate `commitment_solidity_calldata.json` and `inclusion_proof_solidity_calldata.json` in the `prover/bin`.<br>
 These two JSON files will be used for testing in the `contracts`.
 
 ## Documentation
@@ -109,7 +109,7 @@ the following technique is proposed to further improve the performance of the un
 
 Step 4 of the algorithm establishes the relation between the chunks containing individual user liabilities and the grand sum of all user liabilities. The proof of inclusion generation in step 3 should be carried out using the amortized KZG approach in the similar fashion as in the non-chunked version of Summa.
 
-The proof of concept implementation of the suggested approach can be found in the [example file](kzg_prover/examples/chunked_univariate_grand_sum.rs). To execute the example, use the command:
+The proof of concept implementation of the suggested approach can be found in the [example file](prover/examples/chunked_univariate_grand_sum.rs). To execute the example, use the command:
 
 ```shell
 cargo run --release --example chunked_univariate_grand_sum