Guarantee usernames stays inside field

[sebastiantf]

Description

usernames are being converted into BigUint and then to into field elements: https://github.com/zBlock-2/summa-solvency-schneier/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/zk_prover/src/circuits/merkle_sum_tree.rs#L252

iirc, Summa is not really bothered about how the usernames are constructed, but it is expected to be a hash of a unique combination of user id and/or email address (not fully sure)

What happens if an exchange settles on a format for constructing the usernames, uses Summa a few times, but at some point in the future for specific usernames, the BigUint conversion overflows the field? Would they have to change the username construction procedure? Is that possible considering the previous rounds they've already committed? Hence should Summa also consider the username construction procedure and have some restrictions around that procedure?

[sifnoc]

What happens if an exchange settles on a format for constructing the usernames, uses Summa a few times, but at some point in the future for specific usernames, the BigUint conversion overflows the field? Would they have to change the username construction procedure? Is that possible considering the previous rounds they've already committed? Hence should Summa also consider the username construction procedure and have some restrictions around that procedure?

As discussed with Parsley in early Mar, a Custodian can intentionally create an overflow on a username to hide the exclusion of a user entry from the MST. For example, consider two users, A and B, who have the same balance (which is a common occurrence on exchanges). The Custodian can generate the same leaf-hash for both users with different usernames - one under the modulus and the other over the modulus. This allows the Custodian to exclude one of the entries from the MST.

However, we can mitigate the Custodian's motivation to cause an overflow by adding a verification step to the verifyInclusionProof function.

[0xalizk]

Should overflow be checked in circuit as well in cases where core Summa is imported as lib in some external zkDapps which may miss checking in-contract?

It can be modularized as an optional feature with default=true so it can be switched off for better performance.

[sifnoc]

Should overflow be checked in circuit as well in cases where core Summa is imported as lib in some external zkDapps which may miss checking in-contract?

It can be modularized as an optional feature with default=true so it can be switched off for better performance.

I think this is a good idea to add an optional feature enabling range checks for usernames in the circuit. I will create an issue with details for any contributors.