Account Abstraction - Custom Validation Signature Scheme #229

OkoliEvans · 2024-06-30T11:28:12Z

Issue(s): Close #191

Description

Please provide a brief description of the changes made in this pull request and how they address the related issue.

Checklist

CI Verifier: Run ./scripts/cairo_programs_verifier.sh successfully
Contract Tests: Added tests to cover the changes

julio4

Please review #200 for the basic of account abstraction already explained.
Try to keep a more neutral tone, do not use words such as thief, newbies...

OkoliEvans · 2024-07-16T12:00:50Z

@julio4 Pls check the adjustments I made, also the custom signature validation I used was the standard implementation for Secp256r1 and Secp256k1 used by Argent. Let me know what needs to be added or removed pls

julio4

It looks good to me, I requested some changes.
Lastly, it would be great to add a few notes on cryptography theory about "digital signature" before going into the implementation (not a deep dive, just a global overview)

src/advanced-concepts/custom_signature_validation.md

julio4 · 2024-07-19T04:35:14Z

src/advanced-concepts/custom_signature_validation.md

+ii. **Signers:** These are responsible for digitally signing transactions and provide the authorization needed to initiate transactions. 
+Digital signatures are cryptographic proofs that transactions are authorized by corresponding accounts.
+
+In summary, Starknet accounts are normal blockchain accounts that hold assets and initiate transactions onchain, while signers provide the authorization required to ensure that transactions originating from these accounts are secure, valid and executed.


Maybe put more emphasis on the fact that signers are offchain, and that the implementation of the validation functions of SNIP-6 dictate how to "link" signers onchain, by verify the signatures in account contracts. You can compare it with EOA in Ethereum, and explains that it adds more flexibility.

With great power comes great responsibility, so a small advisory on potential security issues with improper validation implementation would be great as well.

I would still think that an emphasis on the offchain part of signers is missing

src/advanced-concepts/custom_signature_validation.md

listings/advanced-concepts/custom_signature_validation/src/custom_signature.cairo

OkoliEvans · 2024-07-21T12:15:14Z

Made some adjustments based on your review @julio4

src/advanced-concepts/custom_signature_validation.md

OkoliEvans · 2024-07-24T11:40:36Z

Reviews implemented and pushed @julio4

julio4 · 2024-08-08T05:46:39Z

src/advanced-concepts/custom_signature_validation.md

@@ -1,12 +1,15 @@
 # Custom Signature Validation Scheme

-Account Abstraction is a native feature on Starknet, this makes it possible for anyone to implement custom signature schemes. The implication is that signature schemes on Starknet are not limited to just one, any standard signature scheme can be validated, for example Starknet signature, Secp256k1, Secp256r1, Eip191 etc are some of the custom signatures that can be validated on Starknet currently. 
+Digital signatures are a fundamental aspect of modern cryptography, used to verify the authenticity and integrity of digital messages or transactions. They are based on public-key cryptography, where a pair of keys (a public key and a private key) are used to create and verify signatures.
+Private keys are kept secret and secure by the owner, and are used to sign the message or transaction, while the public key can be used by anyone to verify the signature.


secured

to sign data such as messages or transactions

and can be verified by anyone with the public key

julio4 · 2024-08-08T05:50:55Z

src/advanced-concepts/custom_signature_validation.md

+Digital signatures are a fundamental aspect of modern cryptography, used to verify the authenticity and integrity of digital messages or transactions. They are based on public-key cryptography, where a pair of keys (a public key and a private key) are used to create and verify signatures.
+Private keys are kept secret and secure by the owner, and are used to sign the message or transaction, while the public key can be used by anyone to verify the signature.
+
+Account Abstraction is a native feature on Starknet, this makes it possible for anyone to implement custom signature schemes. The implication is that signature schemes on Starknet are not limited to just one, any standard signature scheme can be validated, for example Starknet signature, Secp256k1, Secp256r1, Eip191 etc are some of the custom signatures that can be validated on Starknet currently.


Little redundant, you can compact it like this:
Account Abstraction is a native feature on Starknet, this makes it possible for anyone to implement custom signature schemes and use it to validate transactions with the implementation of the signature validation logic.

julio4 · 2024-08-08T05:54:15Z

src/advanced-concepts/custom_signature_validation.md

+ii. **Signers:** These are responsible for digitally signing transactions and provide the authorization needed to initiate transactions. 
+Digital signatures are cryptographic proofs that transactions are authorized by corresponding accounts.
+
+In summary, Starknet accounts are normal blockchain accounts that hold assets and initiate transactions onchain, while signers provide the authorization required to ensure that transactions originating from these accounts are secure, valid and executed.


I would still think that an emphasis on the offchain part of signers is missing

julio4

Thank you for applying the changes, it is better!
Overall you should try to keep the sentences as straightforward as possible. There's lots of sentences you can simplify and make it more digestible for readers. I added some comments with examples.

And lastly I would like to break the last part, the actual implementation example, in specific block with some comment on what part of the implementation it is.

julio4 · 2024-08-08T05:55:35Z

src/advanced-concepts/custom_signature_validation.md

@@ -17,18 +20,14 @@ All Account contracts on Starknet must implement the SNIP-6 standard as mentione

 `is_valid_signature` returns true if the signature is valid, `__validate__` validates the signature and marks them as 'VALIDATED', while `__execute__` executes the validated transaction. Sample implementation of SNIP-6 standard: [Sample SNIP-6 Implementation](https://starknet-by-example.voyager.online/advanced-concepts/account_abstraction/account_contract.html#minimal-account-contract-executing-transactions)


Could you use relative path to account contract instead of absolute url

julio4 · 2024-08-08T05:56:34Z

src/advanced-concepts/custom_signature_validation.md

@@ -17,18 +20,14 @@ All Account contracts on Starknet must implement the SNIP-6 standard as mentione

 `is_valid_signature` returns true if the signature is valid, `__validate__` validates the signature and marks them as 'VALIDATED', while `__execute__` executes the validated transaction. Sample implementation of SNIP-6 standard: [Sample SNIP-6 Implementation](https://starknet-by-example.voyager.online/advanced-concepts/account_abstraction/account_contract.html#minimal-account-contract-executing-transactions)

-
-On Ethereum, EOAs directly sign transactions onchain using their private keys. This onchain signing of transactions is more secure and straightforward but less flexible. Offchain signing employed on Starknet gives room for more flexibility aside the ability to implement custom signature schemes, however, care must be taken to validate all signatures meticulously to ensure that:
+On Ethereum, only **one** signature scheme is used for signing messages and transactions, and also for signature authentications: the Elliptic Curve Digital Signature Algorithm (ECDSA). That means that no other signature algorithms can be validated on Ethereum, making it more secure but less flexible.


On Ethereum, only one signature scheme is used: ECDSA. It makes Ethereum more secure but also less flexible.

julio4 · 2024-08-08T05:58:15Z

src/advanced-concepts/custom_signature_validation.md

 In summary, Starknet accounts are normal blockchain accounts that hold assets and initiate transactions onchain, while signers provide the authorization required to ensure that transactions originating from these accounts are secure and valid.

-Digital signatures are a fundamental aspect of modern cryptography, used to verify the authenticity and integrity of digital messages or transactions. They are based on public-key cryptography, where a pair of keys (a public key and a private key) are used to create and verify signatures.
-Private keys are kept secret and secure by the owner, and are used to sign the message or transaction, while the public key can be used by anyone to verify the signature.
-
 ### Custom signature validation sample

 The example below shows a sample implementation of `Secp256r1` and `Secp256k1` signature schemes:


As it can be a bit complex in one big block, try to break it in each steps of the implementation

OkoliEvans · 2024-08-13T20:43:30Z

@julio4 Please check the adjustments and let me know what else to do

draft PR for issue 191

f991163

julio4 reviewed Jul 1, 2024

View reviewed changes

OkoliEvans added 4 commits July 16, 2024 12:25

Merge branch 'NethermindEth:main' into main

ba167af

edited custom-signature.md file

60e7a6e

Merge remote-tracking branch 'origin/main'

70eafc0

edited custom-signature.md file

cd066bb

julio4 requested changes Jul 19, 2024

View reviewed changes

OkoliEvans added 3 commits July 21, 2024 00:49

Merge branch 'NethermindEth:main' into main

03ed5dd

added more details to custom signature scheme

cbbb89f

Merge remote-tracking branch 'origin/main'

03a1349

julio4 reviewed Jul 24, 2024

View reviewed changes

src/advanced-concepts/custom_signature_validation.md Outdated Show resolved Hide resolved

src/advanced-concepts/custom_signature_validation.md Outdated Show resolved Hide resolved

made some adjustments based on PR review

bd15631

julio4 reviewed Aug 8, 2024

View reviewed changes

julio4 requested changes Aug 8, 2024

View reviewed changes

julio4 changed the title ~~draft PR for issue 191~~ Account Abstraction - Custom Validation Signature Scheme Aug 8, 2024

OkoliEvans added 3 commits August 13, 2024 21:38

Merge branch 'NethermindEth:main' into main

dda41c8

Edited draft PR on Custom signature validation

d531ed6

Merge remote-tracking branch 'origin/main'

5b62bf7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Account Abstraction - Custom Validation Signature Scheme #229

Account Abstraction - Custom Validation Signature Scheme #229

OkoliEvans commented Jun 30, 2024 •

edited by julio4

Loading

julio4 left a comment

OkoliEvans commented Jul 16, 2024

julio4 left a comment

julio4 Jul 19, 2024

julio4 Aug 8, 2024

OkoliEvans commented Jul 21, 2024

OkoliEvans commented Jul 24, 2024

julio4 Aug 8, 2024

julio4 Aug 8, 2024

julio4 Aug 8, 2024

julio4 left a comment

julio4 Aug 8, 2024

julio4 Aug 8, 2024

julio4 Aug 8, 2024

OkoliEvans commented Aug 13, 2024

		@@ -17,18 +20,14 @@ All Account contracts on Starknet must implement the SNIP-6 standard as mentione

		`is_valid_signature` returns true if the signature is valid, `__validate__` validates the signature and marks them as 'VALIDATED', while `__execute__` executes the validated transaction. Sample implementation of SNIP-6 standard: [Sample SNIP-6 Implementation](https://starknet-by-example.voyager.online/advanced-concepts/account_abstraction/account_contract.html#minimal-account-contract-executing-transactions)

Account Abstraction - Custom Validation Signature Scheme #229

Are you sure you want to change the base?

Account Abstraction - Custom Validation Signature Scheme #229

Conversation

OkoliEvans commented Jun 30, 2024 • edited by julio4 Loading

Description

Checklist

julio4 left a comment

Choose a reason for hiding this comment

OkoliEvans commented Jul 16, 2024

julio4 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OkoliEvans commented Jul 21, 2024

OkoliEvans commented Jul 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

julio4 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OkoliEvans commented Aug 13, 2024

OkoliEvans commented Jun 30, 2024 •

edited by julio4

Loading