Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hash arbitrary number of elements in masm #750

Merged
merged 11 commits into from
Jul 2, 2024
Merged

Conversation

Fumuran
Copy link
Contributor

@Fumuran Fumuran commented Jun 12, 2024

This PR implements compute_inputs_hash function in note.masm which allows to compute RPO hash of arbitrary number of Felt elements.

TODO:

  • Implement compute_inputs_hash
  • Update changelog
  • Update docs

@Fumuran Fumuran requested a review from bobbinth June 12, 2024 20:55
@Fumuran Fumuran linked an issue Jun 12, 2024 that may be closed by this pull request
Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Not a full review, but I left a couple of comments inline.

miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Show resolved Hide resolved
@partylikeits1983
Copy link
Contributor

partylikeits1983 commented Jun 17, 2024

@Overcastan Is it easy to get the note serial number or serial number hash easily?

Once it is possible to hash an arbitrary number of elements in masm, and get the serial number, you can use this procedure: #757

If you can only get the hash, that's fine too, you'd just modify this procedure a bit.

@Fumuran
Copy link
Contributor Author

Fumuran commented Jun 18, 2024

@partylikeits1983 I thought that note serial number is kind of user input, isn't it? So we can add it as an input to the procedure, but in that case versatility of this procedure will decrease. But I don't know the exact use case for it, so if at the moment of this procedure call we always have the note serial number, it should be fine to add it as an input.

@Fumuran Fumuran marked this pull request as ready for review June 19, 2024 21:53
@Fumuran Fumuran requested a review from bobbinth June 19, 2024 22:12
@partylikeits1983
Copy link
Contributor

Should we add a test for this?

@Fumuran
Copy link
Contributor Author

Fumuran commented Jun 21, 2024

I was thinking about that, but there is a problem: ideally we want to have something similar to tests in native.rs, but to do so in miden-base we essentially need to copy the whole test-utils crate.
Probably it makes sense to create a different PR just to implement testing for modules here in base, since we need to implement quite a few testing utilities.

@bobbinth
Copy link
Contributor

I was thinking about that, but there is a problem: ideally we want to have something similar to tests in native.rs, but to do so in miden-base we essentially need to copy the whole test-utils crate.
Probably it makes sense to create a different PR just to implement testing for modules here in base, since we need to implement quite a few testing utilities.

I think once we finalize the procedure here, we should basically copy it (with some minor modifications) to the native hash module (which will be renamed to rpo in the future) and test it there. Once we move miden-base to the next version of Miden VM, we'll just start using the procedure from the rpo module.

@Fumuran
Copy link
Contributor Author

Fumuran commented Jun 24, 2024

I implemented this function using cdrop instructions, but I'm not sure that it will be better in performance and more easy to understand. I think I could try to optimize it by dividing into two cases: we need to drop more than 4 elements and less than 4 elements, which will make this function faster, although even more complicated.

@Fumuran
Copy link
Contributor Author

Fumuran commented Jun 25, 2024

I thought that if we are going to check all 7 top stack elements by hand anyway, we can simplify the cdrop implementation even further, removing latch variable and cdrop instruction. This implementation uses ifs, so I'm not sure that it will be faster, but it is more simple for sure.

@bobbinth
Copy link
Contributor

I thought that if we are going to check all 7 top stack elements by hand anyway, we can simplify the cdrop implementation even further, removing latch variable and cdrop instruction. This implementation uses ifs, so I'm not sure that it will be faster, but it is more simple for sure.

Using if's will introduce quite a bit of overhead here - so, we should probably go back to using cdrop's.

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you. I left a few comments inline.

Before merging this PR, let's make a similar PR in miden-base to update the rpo module (the PR would need to made against Al's branch). That one is already using a new padding rule - and so, I think, the code should be a bit simpler.

In that PR, let's rename hash_memory into hash_memory_words and name the function you wrote in this PR hash_memory.

miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
@Fumuran Fumuran force-pushed the andrew-hash-more-than-8 branch 2 times, most recently from 80103e5 to 74d3199 Compare June 26, 2024 17:36
@Fumuran
Copy link
Contributor Author

Fumuran commented Jun 26, 2024

Since hash_memory is called from (yet) non-existent module rpo, tests are keep failing.

@bobbinth
Copy link
Contributor

Since hash_memory is called from (yet) non-existent module rpo, tests are keep failing.

We won't be able to update miden-base to the latest miden-vm for some time - but we need to merge this PR soon. Could you bring back the previous implementation (the one on which the miden-vm PR is based on). For the implementation in this PR, we should still use the old padding rule.

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you. I left some more comments inline.

Also, it would be good to test it somehow - even if manually (i.e., we don't need to create a lot of code for this, I just want to make sure similar tests as we did have in miden-vm work with this too).

miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
miden-lib/asm/miden/note.masm Outdated Show resolved Hide resolved
@Fumuran Fumuran requested a review from bobbinth July 1, 2024 14:35
Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you! I left a few small comments inline. After these are addressed, we can merge.

# => [num_inputs/8, num_inputs%8, inputs_ptr]

# get the end_addr for hash_memory procedure (end address for pairs of words)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this should say "hash_memory_even" procedure.

Comment on lines 442 to 463
let code = "
use.miden::note

begin
push.1.2.3.4.1000 mem_storew dropw
push.5.6.7.8.1001 mem_storew dropw
push.9.10.11.12.1002 mem_storew dropw
push.13.14.15.16.1003 mem_storew dropw

push.5.1000
exec.note::compute_inputs_hash

push.8.1000
exec.note::compute_inputs_hash

push.15.1000
exec.note::compute_inputs_hash

push.0.1000
exec.note::compute_inputs_hash
end
";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add comments to explain what is being hashed here.

Comment on lines 465 to 484
let process = tx_context.execute_code(code).unwrap();
let expected_stack = [
Felt::new(0),
Felt::new(0),
Felt::new(0),
Felt::new(0),
Felt::new(10300020282439016154),
Felt::new(3516596904277416676),
Felt::new(11018788508269249672),
Felt::new(7921509648524809116),
Felt::new(13608701685256682132),
Felt::new(16013969809933496273),
Felt::new(15720844923951376941),
Felt::new(15975159621759139720),
Felt::new(12095223039215569196),
Felt::new(16902760742589336416),
Felt::new(12194156716918087419),
Felt::new(2777745863384272413),
];
assert_eq!(process.get_stack_state()[0..16], expected_stack);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to compute these dynamically? Or at least write comments about how these were computed?

@Fumuran Fumuran requested a review from bobbinth July 2, 2024 17:55
Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks good! Thank you!

@bobbinth bobbinth merged commit 89437d1 into next Jul 2, 2024
12 checks passed
@bobbinth bobbinth deleted the andrew-hash-more-than-8 branch July 2, 2024 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using hmerge to hash 9 or more stack elements
3 participants