We don't really need to call compute_inputs_commitment here. The pipe_words_to_memory (or pipe_double_words_to_memory) have already done the heavy-lifting of computing the hash - so, we just need to extract it from the stack. This could be done like so:

# => [C, B, A, dest_ptr', NOTE_INPUTS_COMMITMENT, num_inputs, dest_ptr]

exec.rpo256::squeeze_digest
# => [COMPUTED_COMMITMENT, dest_ptr', NOTE_INPUTS_COMMITMENT, num_inputs, dest_ptr]

movup.4 drop
# => [COMPUTED_COMMITMENT, NOTE_INPUTS_COMMITMENT, num_inputs, dest_ptr]

assert_eqw.err=ERR_NOTE_DATA_DOES_NOT_MATCH_COMMITMENT
# => [num_inputs, dest_ptr]

The issue with this is that pipe_words_to_memory computes the hash over the padded inputs (we need to pad with zeros to obtain full words for copying) - and with this PR, we've switched to committing to unpadded inputs, so the results will mismatch.

I agree this is a bit wasteful - we're only using the instruction to move data from advice stack to memory, and performing the verification separately. Ideally we'd have either a way to:

• A) purely move words to memory without hashing, call it copy_words_to_memory
• B) pipe an arbitrary number of elements, with the hashing done with exec.rpo256::hash_elements - i.e. similar to the current pipe_{words/double_words}_to_memory, but one that works over the exact number of elements, not full words. Call it pipe_elements_to_memory.

I can foresee use cases for both instructions, so maybe both are useful independently of which approach we take here?

In any case for this PR we won't have this instruction in miden-vm ready. But once the new instruction(s) is available, I'd prefer approach B) here, as actually reduces the surface of exposed procedures and lets us get rid of the note::compute_inputs_commitment procedure (pipe_elements_to_memory would take care of exactly computing the inputs commitment)

The issue with this is that pipe_words_to_memory computes the hash over the padded inputs (we need to pad with zeros to obtain full words for copying) - and with this PR, we've switched to committing to unpadded inputs, so the results will mismatch.

This shouldn't be an issue. Because of how the padding rule works for RPO, padding the last permutation with zeros should not change the resulting hash. Previously, there was an issue which how to do this but adv.push_mapvaln.8 instruction solves this.

So, we should be able to use pipe_double_words_to_memory and then just get the digest from the values on the stack. This would avoid the need to hash the memory again.

purely move words to memory without hashing, call it copy_words_to_memory

This could work but it would double the cost (in terms of the number of cycles and memory accesses). The main idea of pipe_double_words_to_memory (and other instructions) is that we can copy to memory and hash at the same time. The ability to specify the padding amount adv.push_mapvaln let's us work with any number of inputs.

pipe an arbitrary number of elements, with the hashing done with exec.rpo256::hash_elements - i.e. similar to the current pipe_{words/double_words}_to_memory, but one that works over the exact number of elements, not full words. Call it pipe_elements_to_memory.

We could (and maybe should) add such a procedure - but it would be much more expensive (like several times more expensive) then the pipe_double_words_to_memory approach.

In any case for this PR we won't have this instruction in miden-vm ready. But once the new instruction(s) is available, I'd prefer approach B) here, as actually reduces the surface of exposed procedures and lets us get rid of the note::compute_inputs_commitment procedure (pipe_elements_to_memory would take care of exactly computing the inputs commitment)

The main motivation for introducing adv.push_mapvaln.8 was to avoid using such a procedure :)

thanks, done in chore: squeeze rpo digest instead of rehashing