Parameter width is inconsistent

[0xKarl98]

Inconsistency
summa uses broken merkle summation tree at arity of 2 .

According to poseidon paper, the relation between width and arity under merkle tree instance should be : width = arity + 1 .

Thus in this case , the width should be 2+1 = 3 .

Furthur more , inside the hackmd file , the width t being used is 5.

Mitigation
Consider to make the width parameter all be 3 .

[flyingnobita]

Doesn't Summa use a rate of 1 and width of 2?

PoseidonChip::<PoseidonSpec, 2, 1, { N_CURRENCIES + 1 }>::configure(
PoseidonChip::<PoseidonSpec, 2, 1, { N_CURRENCIES + 2 }>::configure(
rate

[0xKarl98]

Yeah in the actual implementation , the width is of 2 , but in this doc , saying the width is 5

and i think the width should be 3 , which is the arity + 1 , denoted by poseidon paper

[igorline]

@0xKarl98 why should it be 3?

[0xKarl98]

Because in summa's mst , the arity of it is 2 , meaning the number of children each node has is at most 2

according to poseidon paper , under poseidon-128 , when arity is 2 , the width = arity + 1 = 3

Also , if you check poseidon paper at sector 4.1 , it says :

We focus on two possible widths, namely t = 3 and t = 5, as they correspond to popular cases of 2-to-1 and 4-to-1 compression functions. In the Merkle tree case, this corresponds to trees of arity 2
and 4, respectively .

[igorline]

I am not sure arity of the tree is related to the algorithm of the hash function

[obatirou]

Here are my notes about the Poseidon parameters for Summa: https://hackmd.io/@obatirou/r1r0M7sha (you need to be signed-in to access it). From my understanding, I do not think this is an issue. They changed it following benchmark for better verification time and the rate should not influence the security of the hash. A few things need to be confirmed but adding explanation / justification to the documentation would be great from Summa. Let me know your thoughts on this.