➕Proof Of Solvency

The design doc for proof of solvency can be found by the binance team here

I here talk about the recursive implementation for mina from how I implement it

The Gnark Implmentation

the following picture is the circuit implementated by the binance team. It is not pretty to look at

Recursive Snark Implementation

The above implementation through recursive snarks can be boiled down just a simple circuit

In this circuit here are the outlines of the circuit

Base Asset List Verification (verifyAssetList)

This is the initial step in the recursive approach. It verifies a single asset entry in the CEX's asset list using a Merkle Map.

• Inputs:

  • witness: The Merkle proof (or witness) to validate the entry in the Merkle Map.

  • elementId, TotalEquity, TotalDebt, USDTPrice: Information about the asset to be verified.

  • assetListCommitment: The root of the Merkle Map (the commitment to the entire asset list).

• Operation:

  • It hashes the asset information and computes the Merkle Map's root and key.

  • It asserts that the computed key and root match the provided assetListCommitment.

This is the base proof, and its output is used as an input for the next recursive proof.

2. Recursive Asset List Verification (verifyAssetListRecursive)

In this method, the proof recursively verifies the updated asset list after the base verification.

• Inputs: Similar to the base method but with an additional input:

  • proof: A self-proof (i.e., the previous proof that was generated).

• Operation:

  • It first verifies the previous proof (proof.verify()).

  • Then, it computes the new Merkle root and checks whether it matches the updated assetListCommitment.

This step recursively chains the proof verification, ensuring that each update to the asset list is valid.

3. Recursive User Batch Operations (UserBatch)

Similarly, for users, the program verifies user batch operations. Here, after verifying the assets, the users' equity and debt are aggregated across assets.

• Recursive Structure:

  • UserBatchBase: This is the base method where a batch of user data is verified.

  • UserBatch: This method recursively verifies each batch update based on the last operation's proof.

This recursive verification of user operations ensures that for each new batch of users, their balances and commitments are updated correctly based on the previous proof.

Recursive Pattern

The recursive approach in zkSNARK is achieved by making each verification method dependent on the proof of the previous step. The program maintains the integrity of all prior proofs by verifying them recursively, chaining each step like this:

1. Start with an initial asset or user batch (base method).

2. For each new operation, generate a proof that verifies the current state and checks that it matches the result of the previous proof (recursive method).

3. Keep chaining these proofs, each verifying the next, to maintain consistency and correctness of the entire process.

This recursive proof aggregation is critical for ensuring that all changes across asset lists and user balances are valid, without the need to recompute everything from scratch.