-
Notifications
You must be signed in to change notification settings - Fork 11.8k
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
Fix grammar errors in utilities documentation #5105
base: master
Are you sure you want to change the base?
Conversation
|
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.
Hey, thanks for your PR. Mostly looks good but I'd like to take the opportunity to update the reference to web3.js if you don't mind.
This commit updates the ECDSA documentation to reference the more current `ethers` and `viem` libraries for generating Ethereum account ECDSA signatures. Changes made: - Updated reference from `web3.eth.sign` to `signMessage` function in the ethers library and viem documentation. These changes provide more relevant and up-to-date information for developers using the ECDSA functions. I have ensured that the updated links point to the correct sections of the ethers and viem documentation. Co-authored-by: Ernesto García <ernestognw@gmail.com>
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.
Thanks!
@@ -8,11 +8,11 @@ Here are some of the more popular ones. | |||
|
|||
=== Checking Signatures On-Chain | |||
|
|||
At a high level, signatures are a set of cryptographic algorithms that allow for a _signer_ to prove himself owner of a _private key_ used to authorize an piece of information (generally a transaction or `UserOperation`). Natively, the EVM supports the Elliptic Curve Digital Signature Algorithm (https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm[ECDSA]) using the secp256k1 curve, however other signature algorithms such as P256 and RSA are supported. | |||
At a high level, signatures are a set of cryptographic algorithms that allow for a _signer_ to prove they are the owner of a _private key_ used to authorize a piece of information (generally a transaction or `UserOperation`). Natively, the EVM supports the Elliptic Curve Digital Signature Algorithm (https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm[ECDSA]) using the secp256k1 curve, however, other signature algorithms such as P256 and RSA are supported. |
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.
At a high level, signatures are a set of cryptographic algorithms that allow for a _signer_ to prove they are the owner of a _private key_ used to authorize a piece of information (generally a transaction or `UserOperation`). Natively, the EVM supports the Elliptic Curve Digital Signature Algorithm (https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm[ECDSA]) using the secp256k1 curve, however, other signature algorithms such as P256 and RSA are supported. | |
At a high level, signatures are a set of cryptographic algorithms that allow for a _signer_ to prove they have access to the _private key_ used to authorize a piece of information (generally a transaction or `UserOperation`). Natively, the EVM supports the Elliptic Curve Digital Signature Algorithm (https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm[ECDSA]) using the secp256k1 curve, however, other signature algorithms such as P256 and RSA are supported. |
@@ -34,7 +34,7 @@ WARNING: Getting signature verification right is not trivial: make sure you full | |||
|
|||
P256, also known as secp256r1, is one of the most used signature schemes. P256 signatures are standardized by the National Institute of Standards and Technology (NIST) and it's widely available in consumer hardware and software. | |||
|
|||
These signatures are different to regular Ethereum Signatures (secp256k1) in that they use a different elliptic curve to perform operations but have similar security guarantees. | |||
These signatures are different to regular Ethereum Signatures (secp256k1) in that they use different elliptic curve to perform operations but have similar security guarantees. |
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 think "use a different elliptic curve" is correct here. You would drop the a
if it was multiple curves.
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.
These signatures are different to regular Ethereum Signatures (secp256k1) in that they use different elliptic curve to perform operations but have similar security guarantees. | |
These signatures are different to regular Ethereum Signatures (secp256k1) in that they use different elliptic curves to perform operations but have similar security guarantees. |
|
||
Commonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires to load such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory. | ||
Commonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires loading such a struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory. |
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.
Lets discuss the content here. Packing is done in storage. Memory and Calldata do not pack values.
What does it mean that packing "requires loading such a struct from either calldata or memory" ?
When you do packing, that is reading/writting to storage. This is a storage <> stack thing (sstore/sload). The packing is prepared on the stack.
This pull request addresses several grammar errors in the documentation of utilities.
Changes made:
I have ensured the changes adhere to the engineering guidelines and all tests and linters have been run successfully.