Describe the bug
There is a range check constraint performed on the leaf node balances of the user that's requesting Proof of Inclusion.
This may be redundant because falsifying these balances will change the hash of the leaf node which is a public input to the circuit.
Additional context
Range check is used in the summa circuit to guard against overflow errors. Malicious prover can artificially increase user balances as well as fill the MST with fake balances to create overflow on the way of calculating the root. This way the prover can underreport liabilities in the MST.
Hash of the leaf node is exposed as a public input of the circuit. User that requests proof of inclusion needs to validate that this public hash equals to hash(user_name, [user_balances]). Therefore if malicious prover tries to modify user balances to a value outside of the range check it will also affect the hash calculations. User will see that the hash doesn't match meaning their balances (or username) has been meddled with. User will not accept such proof.
Impact
Removing the range check on the user's leaf node may slightly increase performance while not weakening security of the circuit,
Describe the bug There is a range check constraint performed on the leaf node balances of the user that's requesting Proof of Inclusion. This may be redundant because falsifying these balances will change the hash of the leaf node which is a public input to the circuit.
Additional context Range check is used in the summa circuit to guard against overflow errors. Malicious prover can artificially increase user balances as well as fill the MST with fake balances to create overflow on the way of calculating the root. This way the prover can underreport liabilities in the MST.
Range check is required for most of the balances in the MST circuit. However, it may be redundant for user's leaf balances. https://github.com/zBlock-2/summa-solvency-diffie/blob/master/zk_prover/src/circuits/merkle_sum_tree.rs#L351
Hash of the leaf node is exposed as a public input of the circuit. User that requests proof of inclusion needs to validate that this public hash equals to
hash(user_name, [user_balances]). Therefore if malicious prover tries to modify user balances to a value outside of the range check it will also affect the hash calculations. User will see that the hash doesn't match meaning their balances (or username) has been meddled with. User will not accept such proof.Impact Removing the range check on the user's leaf node may slightly increase performance while not weakening security of the circuit,