Merge main into v2 #289
Merged
Merge main into v2 #289
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…inite points on the elliptic curve
…ent points at infinity in elliptic curve
… of PointAtInfinity and FinitePoint
… the other is not
…eFromAffine function
…clude x and y coordinates for consistency
…oordinates for better representation of PointAtInfinity
…o use object destructuring for cleaner code and improve readability
…nity for type consistincey
…ineOnCurve function to destructure parameters and use them directly in calculations
…ntAtInfinity functions as they are not being used in the codebase
…t token usage permissions The MayUseToken type and object were added to represent the permissions for token usage in a transaction. It includes two boolean fields: parentsOwnToken to indicate if the parent owns the token, and inheritFromParent to specify if the token usage should be inherited from the parent. The check method was also added to enforce the constraint that a transaction cannot both have the parent own the token and inherit the token usage from the parent at the same time. This addition provides a structured way to handle token usage permissions within the transaction leaves.
- Check if parentsOwnToken and inheritFromParent are instances of Bool - Throw an error if the fields are not of type Bool - This ensures that the correct types are passed to the MayUseToken object, preventing potential runtime errors due to incorrect types being used in the check function
…ermissions The MayUseToken type was added to the derivedLeafTypesSignable function to represent the token usage permissions for a zkApp account. It includes two boolean fields: - parentsOwnToken: indicates if the parent account owns the token - inheritFromParent: indicates if the token usage permission should be inherited from the parent account This allows for more granular control over token usage permissions in zkApp accounts. feat(transaction-leaves): export MayUseToken type in transaction leaf type definitions The MayUseToken type is now exported from the transaction-leaves-bigint.ts and transaction-leaves-json.ts files. This makes the type available for use in other parts of the project that deal with transaction leaves and zkApp account permissions. feat(gen): include MayUseToken in generated transaction types The generated transaction types in transaction-bigint.ts and transaction.ts now include the MayUseToken type in the CustomTypes definition. This ensures that the MayUseToken type is properly integrated into the generated transaction types and can be used when working with transactions.
…inheritFromParent fields The type checking of the `parentsOwnToken` and `inheritFromParent` fields in the `MayUseToken` object was simplified by using the `Bool.check()` method instead of manually checking the types and throwing an error. This change improves code readability and maintainability by utilizing the built-in type checking functionality provided by the `Bool` class.
…en object The check function is no longer needed in the MayUseToken object, as the validation logic can be handled elsewhere in the codebase. This change simplifies the MayUseToken object and improves separation of concerns.
…ify MayUseToken type The createMayUseToken function was removed as it was not providing any additional functionality. The MayUseToken type was simplified to directly use the signable function with the parentsOwnToken and inheritFromParent fields of type Bool. This change reduces the complexity of the code without changing its behavior.
[Main] Fix MayUseToken vulnerability in AccountUpdates
Accept .provable and some other type improvements
Update AffineCurve equal method to account for points at infinity
fix(finite-field): optimize equal method by avoiding modulo operation when possible refactor(finite-field): use more descriptive variable names in equal method The isSquare and sqrt methods were not taking the input modulo p, which could lead to incorrect results for inputs outside the field. The equal method was performing a modulo operation unnecessarily in some cases, which could be avoided by first checking if the inputs are already in the correct range. The variable names in the equal method were also improved for clarity.
… and isSquare methods The commit adds two new test cases to the finite field unit tests: 1. It asserts that calling `sqrt` with a non-canonical zero (i.e., `p`) should return the same result as calling it with a canonical zero (`0n`). This ensures that the `sqrt` method handles non-canonical zero inputs correctly. 2. It asserts that calling `isSquare` with a non-canonical zero (`p`) should return the same result as calling it with a canonical zero (`0n`). This ensures that the `isSquare` method treats non-canonical zero inputs the same way as canonical zero. These tests were added to improve the robustness of the finite field implementation by verifying that it correctly handles non-canonical zero values, which are equivalent to the canonical zero value in the field.
…stead of p - x for improved readability and consistency with other functions fix(finite-field): use mod in isEven function to ensure the result is always within the field range and avoid potential issues with large numbers
…g input to ensure it's in the field The changes in the `sqrt` and `isSquare` functions were made to ensure that the input value is always within the finite field before performing any operations. This is done by modding the input value by the field's prime modulus `p` at the beginning of each function. The reason for this change is to handle cases where the input value might be outside the field, which could lead to incorrect results or even errors. By modding the input, we guarantee that all operations are performed on values within the field, ensuring the correctness of the results. This refactoring improves the robustness and reliability of the `sqrt` and `isSquare` functions, making them more consistent with the expected behavior of finite field arithmetic.
- Assert that negating non-canonical zero (p) returns canonical zero (0n) - Assert that non-canonical zero (p) is considered even These additional test cases ensure that the finite field implementation handles non-canonical zero correctly by treating it as equivalent to the canonical zero representation.
…the number modulo p before checking the least significant bit This fixes a bug where the isEven function would incorrectly classify numbers greater than the field size as even. By first reducing the number modulo p, we ensure that the least significant bit correctly determines the parity of the number within the field.
… method implementation
Fix and finite field operations (isSquare, sqrt)
shimkiv
approved these changes
Aug 1, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.