From 9b5e8ad18d7ebedf5f8e93060610b2db61a1a6a5 Mon Sep 17 00:00:00 2001 From: Alex Kuzmin Date: Mon, 27 Nov 2023 12:23:51 +0800 Subject: [PATCH] Remove asset file description from example readme --- backend/README.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/backend/README.md b/backend/README.md index 17511021..a68e233d 100644 --- a/backend/README.md +++ b/backend/README.md @@ -6,10 +6,11 @@ This directory contains the backend implementation for the Summa Proof of Solven ### Round -The `Round` component represents a specific period or cycle in the Summa Proof of Solvency protocol. It encapsulates the state of the system at a given time, including the snapshot of assets and liabilities, as well as the associated proofs. - The `Round` struct integrates with the `Snapshot` and `SummaSigner` to facilitate the generation and submission of proofs to the contract. +The `Round` component represents a specific period or cycle in the Summa Proof of Solvency protocol. It encapsulates the state of the system at a given time, including the snapshot of assets and liabilities, as well as the associated proofs. +The `Round` struct integrates with the `Snapshot` and `SummaSigner` to facilitate the generation and submission of proofs to the contract. Key Features: + - Initialization of a new round with specific parameters. - Building a snapshot of the current state. - Submitting commitment to the contract. @@ -20,6 +21,7 @@ Key Features: The `AddressOwnership` component is responsible for managing and verifying the ownership of addresses. It ensures that addresses used in the protocol owned by the respective participants. This component interacts with the `SummaSigner` to submit proofs of address ownership to on-chain. Key Features: + - Initialization with specific signer details. - Dispatching proofs of address ownership to the contract. @@ -49,8 +51,8 @@ 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_ASSETS = 2` and `N_BYTES=14`, as indicated [here](https://github.com/summa-dev/summa-solvency/blob/master/zk_prover/examples/gen_inclusion_verifier.rs#L21-L22). -If you intend to work with different parameters, you'll need to adjust these hard-coded values and then generate new verifier contract. - +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. #### Using the Bash Script @@ -91,7 +93,6 @@ If executed successfully, you'll see: 1. Ownership proofs are submitted successfully! ``` - ### 2. Submit Commitment 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`. @@ -101,11 +102,10 @@ Without publishing the commitment, users cannot verify their inclusion proof on 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. -To initialize the `Round` instance, you'll need paths to specific CSV files (`assets.csv` and `entry_16.csv`) and the `ptau/hermez-raw-11` file. Here's what each file does: +To initialize the `Round` instance, you'll need paths to the user asset balances CSV file (`entry_16.csv`) and the `ptau/hermez-raw-11` file. The files serve the following purpose: -- `assets.csv`: Calculates the total balance of assets for the solvency proof. Only the CEX can generate this file. -- `entry_16.csv`: Used to build the Merkle sum tree, with each leaf element derived from sixteen entries in the CSV. -- `ptau/hermez-raw-11`: Contains parameters for constructing the zk circuits. +- `entry_16.csv`: contains the username and asset balance entries for each CEX user (necessary to build the commitment). Asset balance column names have the following format: `balance__`, where and are the names of the assets and their corresponding blockchains. values are the same as in the Address Ownership Proof step; +- `ptau/hermez-raw-11`: contains parameters for constructing the zk circuits. Using the `Round` instance, the solvency proof is dispatched to the Summa contract with the `dispatch_solvency_proof` method. @@ -136,12 +136,13 @@ Users receive the proof for a specific round and use methods available on the de In this step, the user has to: - 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 +- 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 The result will display as: + ``` 4. Verifying the proof on contract verifier for User #0: true ```