The inclusion proof reveals whether a user holds a specific token

[qpzm]

Description

A sniffer can see whether a user has a specific token because balance polynomials are unblinded.
A sniffer, for example, may be an web3 api endpoint who can see a user's inputs for verifyInclusionProof.

Process

1. Assume $B(w^i) = 0$ and check $e([B(s)]_1 - [0]_1, [1]_2) == e([Q_B(w^i)]_1, [s]_2 - [w^i]_2)$
2. If it is true, the user does not have the token. If It is false, the user has the token.

How to know each terms?

1. $[B(s)]_1$ is the commitment stored in the contract through submitCommitment by a prover.
2. $[Q_B(w^i)]_1$ is given by the verifier as an input for verifyInclusionProof.
3. The index of a user $i$ can be known by a rainbow table trick. It calculates $[s]_{2}- [w^i]_2$ for every i and compare with the challenge input given in verifyInclusionProof.

[qpzm]

Update

values input of the function verifyInclusionProof is the exact user i's balance of token j, namely $B_j(w^i)$.

summa-solvency/contracts/test/Summa.ts

Line 470 in fec83a7

values = inclusionCalldata.user_values;

summa-solvency/prover/bin/inclusion_proof_solidity_calldata.json

Lines 12 to 13 in fec83a7

	"0x108ef",
	"0x48db"

This discloses the user balance without the above-mentioned process, so I also recommend to get $[B_j(w^i)]_1$ as a function input rather than $B_j(w^i)$.

summa-solvency/contracts/src/InclusionVerifier.sol

Lines 125 to 132 in fec83a7

	let value := calldataload(add(evaluation_values_length_pos, add(shift_pos, 0x20)))
	let minus_z := sub(r, value)
	// Assign values on memory for multiplication
	mstore(0x80, mload(G1_X_MPTR))
	mstore(0xa0, mload(G1_Y_MPTR))
	mstore(0xc0, minus_z)
	success := and(success, ec_mul_tmp(success, minus_z))