refactor: random fixes and readability improvements #11129
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
benesjan
force-pushed
the
01-07-chore_fixing_aztec-nr_warnings
branch
from
35f4b12 to
b7b7b66
Compare
benesjan
force-pushed
the
01-09-refactor_random_fixes_and_readability_improvements
branch
from
8a4cad3 to
8f11ff7
Compare
| @@ -269,6 +269,7 @@ impl PrivateContext { | |||
| // for the correct public key has been received. | |||
| get_key_validation_request(pk_m_hash, key_index) | |||
| }; | |||
| assert_eq(request.pk_m.hash(), pk_m_hash, "Obtained invalid key validation request"); | |||
There was a problem hiding this comment.
I find assert_eq nicer to read than assert(left == right) so I sneaked this change in here and in other places.
I think we didn't use it before as it was not yet implemented.
There was a problem hiding this comment.
This assert is not present in the origianl code though?
noir-projects/aztec-nr/aztec/src/macros/functions/initialization_utils.nr
Show resolved
Hide resolved
| + (U128::from_integer(self.post.unwrap_unchecked()) << 32) | ||
| + (U128::from_integer(self.block_of_change) << 64) | ||
| + (U128::from_integer(self.post.is_some()) << 96) | ||
| + (U128::from_integer(self.pre.is_some()) << 97); |
There was a problem hiding this comment.
Warnings fix. As discussed in a PR down the stack now I don't work with u64 limbs but I just pack directly. I needed to use U128 here to avoid overflows.
There was a problem hiding this comment.
Can't we use Field directly? If Field doesn't support shifts then lets just multiply by the corresponding power of two. U128 will make this unnecessarily expensive.
| @@ -13,7 +13,7 @@ use dep::aztec::{ | |||
| }, | |||
| }; | |||
|
|
|||
| global VALUE_NOTE_LEN: u32 = 3; // 3 plus a header. | |||
| pub global VALUE_NOTE_LEN: u32 = 3; // 3 plus a header. | |||
There was a problem hiding this comment.
Warnings fix --> value was used in a test contract.
There was a problem hiding this comment.
Which test contract? Accessing this is an antipattern.
noir-projects/noir-protocol-circuits/crates/types/src/abis/sponge_blob.nr
Show resolved
Hide resolved
| assert(value <= next_power_2); | ||
|
|
||
| prev_power_2 | ||
| } |
There was a problem hiding this comment.
As proposed by Nico in a PR down the stack. Made sense to separate this into a separate func as it makes it easier to figure out how the height should be constrained.
Changes to public function bytecode sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
| @@ -269,6 +269,7 @@ impl PrivateContext { | |||
| // for the correct public key has been received. | |||
| get_key_validation_request(pk_m_hash, key_index) | |||
| }; | |||
| assert_eq(request.pk_m.hash(), pk_m_hash, "Obtained invalid key validation request"); | |||
There was a problem hiding this comment.
This assert is not present in the origianl code though?
| + (U128::from_integer(self.post.unwrap_unchecked()) << 32) | ||
| + (U128::from_integer(self.block_of_change) << 64) | ||
| + (U128::from_integer(self.post.is_some()) << 96) | ||
| + (U128::from_integer(self.pre.is_some()) << 97); |
There was a problem hiding this comment.
Can't we use Field directly? If Field doesn't support shifts then lets just multiply by the corresponding power of two. U128 will make this unnecessarily expensive.
| @@ -13,7 +13,7 @@ use dep::aztec::{ | |||
| }, | |||
| }; | |||
|
|
|||
| global VALUE_NOTE_LEN: u32 = 3; // 3 plus a header. | |||
| pub global VALUE_NOTE_LEN: u32 = 3; // 3 plus a header. | |||
There was a problem hiding this comment.
Which test contract? Accessing this is an antipattern.
noir-projects/noir-protocol-circuits/crates/types/src/merkle_tree/variable_merkle_tree.nr
Outdated
Show resolved
Hide resolved
| // Find size of tree required | ||
| let height = unsafe { | ||
| //@safety This is safe because we derive next and previous powers of 2 below based on the height | ||
| // and the powers are then checked against the input value. | ||
| get_height(value, 0) | ||
| }; | ||
|
|
||
| let next_power_2 = 2 << height; | ||
| let prev_power_2 = next_power_2 / 2; | ||
| assert((value == 0) | (value == 1) | (value > prev_power_2)); | ||
| assert(value <= next_power_2); |
There was a problem hiding this comment.
| // Find size of tree required | |
| let height = unsafe { | |
| //@safety This is safe because we derive next and previous powers of 2 below based on the height | |
| // and the powers are then checked against the input value. | |
| get_height(value, 0) | |
| }; | |
| let next_power_2 = 2 << height; | |
| let prev_power_2 = next_power_2 / 2; | |
| assert((value == 0) | (value == 1) | (value > prev_power_2)); | |
| assert(value <= next_power_2); | |
| let next_power_exponent = unsafe { | |
| //@safety This is a hint that we'll use to compute the next and previous powers of two, which we check to be | |
| // larger and smaller than respectively. The get_height function happens to return exactly what we need. | |
| get_height(value, 0) | |
| }; | |
| let next_power_2 = 2 << next_power_exponent; | |
| let prev_power_2 = next_power_2 / 2; | |
| assert((value == 0) | (value == 1) | (value > prev_power_2)); | |
| assert(value <= next_power_2); |
This is more readable I think. Also this is odd - it seems like prev_power_2 is almost complete unconstrained if value is 0 or 1, it can be any value except 0.
…ree/variable_merkle_tree.nr Co-authored-by: Nicolás Venturo <[email protected]>
In a PR down the stack I fixed safety warnings. When doing that I stumbled upon a random hodgepodge of issues. I am fixing them in this PR to not clutter the original one.