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

refactor!: using native u128 type #12213

Merged
merged 20 commits into from
Feb 26, 2025
Merged

Conversation

benesjan
Copy link
Contributor

@benesjan benesjan commented Feb 24, 2025

Fixes #11324
Fixes #12188

Copy link
Contributor Author

benesjan commented Feb 24, 2025

This stack of pull requests is managed by Graphite. Learn more about stacking.

@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from 5d46e61 to db93615 Compare February 24, 2025 09:52
@benesjan benesjan added the e2e-all CI: Deprecated, use ci-full. Enable all master checks. label Feb 24, 2025
@benesjan benesjan marked this pull request as ready for review February 24, 2025 09:52
@benesjan benesjan changed the title refactor: using native u128 type refactor!: using native u128 type Feb 24, 2025
@benesjan benesjan marked this pull request as draft February 24, 2025 11:02
@benesjan benesjan marked this pull request as ready for review February 24, 2025 11:48
@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from 4a41fe7 to 49aa800 Compare February 24, 2025 13:02
@@ -63,7 +79,7 @@ await contract.methods
txHash.hash,
toBoundedVec(txEffects!.data.noteHashes, MAX_NOTE_HASHES_PER_TX),
txEffects!.data.nullifiers[0],
wallet.getAddress(),
Copy link
Contributor Author

@benesjan benesjan Feb 24, 2025

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

@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from f8914a4 to f54fbd9 Compare February 24, 2025 18:01
@benesjan benesjan marked this pull request as draft February 24, 2025 18:02
@benesjan benesjan marked this pull request as ready for review February 24, 2025 18:27
@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from f54fbd9 to 12259a6 Compare February 24, 2025 19:01
@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch 3 times, most recently from 51c4068 to 2a6b583 Compare February 25, 2025 15:22
#[public]
fn u128_from_integer_overflow() -> U128 {
let should_overflow: Field = 2.pow_32(128); // U128::max() + 1;
U128::from_integer(should_overflow)
Copy link
Contributor Author

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');
Copy link
Contributor Author

@benesjan benesjan Feb 25, 2025

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 () => {
Copy link
Contributor Author

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.

@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from 2a6b583 to f6949f1 Compare February 25, 2025 18:16
@benesjan benesjan removed the e2e-all CI: Deprecated, use ci-full. Enable all master checks. label Feb 26, 2025
@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from f6949f1 to 1fa2b77 Compare February 26, 2025 01:06
@@ -588,13 +574,3 @@ fn fancier_test() {
let deserialized = Fancier::deserialize(serialized);
assert(deserialized == fancier);
}

#[test]
fn contains_u128_test() {
Copy link
Contributor Author

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.

Copy link
Contributor

@sklppy88 sklppy88 left a 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;
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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.

Copy link
Member

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.

@benesjan benesjan marked this pull request as draft February 26, 2025 13:53
@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from 5915e27 to ca92e98 Compare February 26, 2025 13:54
@benesjan benesjan marked this pull request as ready for review February 26, 2025 14:45
@benesjan benesjan enabled auto-merge (squash) February 26, 2025 14:47
@benesjan benesjan disabled auto-merge February 26, 2025 15:22
@benesjan benesjan force-pushed the 02-24-refactor_using_native_u128_type branch from cc9de73 to 30141fc Compare February 26, 2025 17:00
@benesjan benesjan enabled auto-merge (squash) February 26, 2025 17:01
@benesjan benesjan merged commit 52ae8cc into master Feb 26, 2025
10 checks passed
@benesjan benesjan deleted the 02-24-refactor_using_native_u128_type branch February 26, 2025 17:25
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.

Migrate Aztec.nr to use native u128 GasEstimator issue triggered by changing U128 serialization
3 participants