Refactor smart contract for the polynomial encoding version (aka Summa v2)

[alxkzmn]

• the commitment phase should accept the KZG commitments instead of the MST-related parameters:

function submitCommitment(
        uint256[] memory kzgCommitments,
        Cryptocurrency[] memory cryptocurrencies,
        uint256 timestamp
    ) public onlyOwner;

• verifyInclusionProof function can be removed until Consider using a Solidity KZG verifier for user inclusion #241 is resolved;
• a new verification function should be added to verify the ZK proof of the polynomial encoding

function verifyPolynomialEncoding(
        bytes memory proof,
        uint256 timestamp
    ) public view returns (bool);

[alxkzmn]

The info above is a bit outdated. Let's take a look at the difference between the V1 and V2 contracts.

In V1, the zkSNARK was used to prove the individual user inclusion, so the smart contract verifier was verifying the individual user inclusion as well.
In V2, the zkSNARK is used to constrain the range of user balances that went into the polynomials. We can call it a proof of the correct polynomial interpolation, and the Custodian will need to publicly share this proof only once. The proof is the same for everyone since it proves the validity of the used data structure/commitment scheme (polynomial). the verifier for this proof is called verifyPolynomialEncoding in the first message.

The inclusion proof in V2 is not the zkSNARK proof but is a KZG proof. During the zkSNARK proof generation Halo2 commits to advice polynomials using the KZG commitment (https://github.com/summa-dev/halo2/blob/8386d6e64fc33baccf626869123185890b8284dc/halo2_proofs/src/plonk/prover.rs#L394). We are taking advantage of this to produce the user inclusion proofs. Since there are already the balance polynomial commitments inside the zkSNARK proof transcript (https://github.com/summa-dev/halo2/blob/8386d6e64fc33baccf626869123185890b8284dc/halo2_proofs/src/plonk/prover.rs#L406), we can perform the KZG opening proofs individually for each user based on these commitments to show the inclusion of their balances into advice polynomials. It also means that the zkSNARK proof transcript contains as many KZG commitment points as there are cryptocurrencies. The function submitCommitment in the first message was referring to these transcript points as uint256[] memory kzgCommitments, but I think it's better to just store the full transcript in the contract right after verifying the zk-proof inside verifyPolynomialEncoding.

Each user expects to receive a KZG opening proof, but also needs to verify the proof against the committed points, that is why we need to store the zkSNARK proof transcript. The user needs to read the balance polynomial KZG commitment from the transcript (similarly to https://github.com/summa-dev/halo2/blob/8386d6e64fc33baccf626869123185890b8284dc/halo2_proofs/src/plonk/verifier.rs#L108) and use it together with the balance value to verify the KZG proof. The algorithm would go roughly as follows:

• generate the user inclusion KZG opening proof in the backend using the best performing prover (e.g., GWC). This algorithm doesn't have to be the same as the KZG opening used in Halo2 for the zkSNARK itself;
• pass the proof to the user;
• provide a KZG verification view function in the smart contract that takes three arguments: 1) opening proof; 2) user X index in the polynomials (may be already known to the user); 3) user balance and ID values (definitely known to the user). This function will verify the KZG proof using the same algorithm that was used to produce it (e.g., GWC). It will slice the transcript bytes stored in the contract to extract the KZG commitment points and perform the necessary calculations using the provided arguments.

[sifnoc]

The smart contract for V2 has been implemented, as detailed in #267