-
Notifications
You must be signed in to change notification settings - Fork 324
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
refactor!: using native u128
type
#12213
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
5d46e61
to
db93615
Compare
4a41fe7
to
49aa800
Compare
@@ -63,7 +79,7 @@ await contract.methods | |||
txHash.hash, | |||
toBoundedVec(txEffects!.data.noteHashes, MAX_NOTE_HASHES_PER_TX), | |||
txEffects!.data.nullifiers[0], | |||
wallet.getAddress(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just ran formatter here
f8914a4
to
f54fbd9
Compare
f54fbd9
to
12259a6
Compare
51c4068
to
2a6b583
Compare
#[public] | ||
fn u128_from_integer_overflow() -> U128 { | ||
let should_overflow: Field = 2.pow_32(128); // U128::max() + 1; | ||
U128::from_integer(should_overflow) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this because from_integer
function does not exist on the native u128 type and when casting from Field to u128 there is no overflow check.
); | ||
await expect( | ||
asset.methods.mint_to_private(accounts[0].address, accounts[0].address, overflowAmount).simulate(), | ||
).rejects.toThrow('Cannot satisfy constraint'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a private function this issue does not apply here and we get a proper check on the input arg. The error message is like that as the U128_OVERFLOW_ERROR
used to be on the U128 type and it's no longer present on the u128
one.
@@ -389,16 +387,6 @@ describe('AVM simulator: transpiled Noir contracts', () => { | |||
resolveAvmTestContractAssertionMessage('u128_addition_overflow', results.revertReason!, results.output), | |||
).toMatch('attempt to add with overflow'); | |||
}); | |||
|
|||
it('Expect failure on U128::from_integer() overflow', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this test because from_integer
function does not exist on the native u128 type and when casting from Field to u128 there is no overflow check.
2a6b583
to
f6949f1
Compare
f6949f1
to
1fa2b77
Compare
@@ -588,13 +574,3 @@ fn fancier_test() { | |||
let deserialized = Fancier::deserialize(serialized); | |||
assert(deserialized == fancier); | |||
} | |||
|
|||
#[test] | |||
fn contains_u128_test() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test became pointless as now u128 occupies only 1 field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly such a great change ! 🫡 I have some tiny nits, and a broader open question.
If we have disparity between U128::from_integer(field)
and field as u128
, are we sure that all of these conversions now are safe ? I highlighted one such example in the value_note utils.
let retrieved_note = notes[i].unwrap_unchecked(); | ||
selected[i] = Option::some(retrieved_note); | ||
sum += U128::from_integer(retrieved_note.note.value); | ||
sum += retrieved_note.note.value as u128; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, unrelated to your PR, what happens if note.value > what's storeable in a u128, as we are reading from a full field. Does it just overflow ? It's a bit weird to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed a problem because before the size was checked. I will go through all the occurrences of U128::from_integer(
on master and fix it when it's needed. Wrote this before I realized that we lose the size check with this change. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it in this commit. The size is still not checked when the u128 value is an argument of a public function but that is covered by this issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can do retrieved_note.note.value.assert_max_bit_size::<128>()
before you cast it to a u128 to ensure that it fits.
noir-projects/noir-protocol-circuits/crates/bug-collecting-crate/devex-integers.nr
Outdated
Show resolved
Hide resolved
noir-projects/noir-protocol-circuits/crates/types/src/type_serialization.nr
Show resolved
Hide resolved
5915e27
to
ca92e98
Compare
cc9de73
to
30141fc
Compare
Fixes #11324
Fixes #12188