Consider the following snippet taken from verify_scr in the function hash_messages in bitvm/src/chunk/wrap_hasher.rs:
// bottom of the stack contains the calculated hash, bring it to the top
for _ in 0..Fq::N_LIMBS {
OP_DEPTH OP_1SUB OP_ROLL
}
// top of altstack contains the claimed hash for corresponding message
{Fq::fromaltstack()}
// compare hashes
{Fq::equal(1, 0)}
The purpose of this snippet is to roll a U256 (a hash) to the top, then to fetch another U256 from the altstack, and compare them. However, to obtain the number of stack elements to roll, Fq::N_LIMBS is used. Similarly, fromaltstack and equal belonging to the Fq type are used. This is correct in this case after unpacking the values, as in all three cases only the number of limbs is relevant, and both U256 and Fq consist of the same number of limbs, namely nine. However, semantically, it would be more correct to use U256::N_LIMBS, U256::fromaltstack(), and U256::equal(1, 0) rather than Fq::N_LIMBS, Fq::fromaltstack(), and Fq::equal(1, 0). Apart from making the code clearer, using the semantically correct type also prevents bugs from occuring should configurations (such as number of bits per limb) change.