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

Account Abstraction - Custom Validation Signature Scheme #229

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from
julio4 marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
// ANCHOR: custom_signature_scheme
use starknet::secp256_trait::{
Secp256PointTrait, Signature as Secp256Signature, recover_public_key, is_signature_entry_valid
};
Expand Down Expand Up @@ -131,3 +132,4 @@ impl U256TryIntoSignerType of TryInto<u256, SignerType> {
}
}

// ANCHOR_END: custom_signature_scheme
29 changes: 25 additions & 4 deletions src/advanced-concepts/custom_signature_validation.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,38 @@
# Custom Signature Validation Scheme

Account Abstraction on Starknet supports various signature schemes. This means 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 et al are some of the custom signatures that can be validated on Starknet currently.
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.

### The Concepts of Accounts and Signers

i. **Account:** All accounts are smart contracts that can hold assets and execute transactions on Starknet protocol, these account contracts however must implement some specific methods outlined in SNIP-6.
i. **Account:** All accounts are smart contracts that can hold assets and execute transactions on Starknet, these account contracts however must implement some specific methods outlined in SNIP-6. For further reading: [Account contract](https://starknet-by-example.voyager.online/advanced-concepts/account_abstraction/account_contract.html).

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.
### Signature validation on Starknet

To implement custom validation method on Starknet you have to ensure that the contract contains these three methods: `is_valid_signature`, `__validate__` and `__execute__`. These are the building block for account contracts on Starknet as contained in the SNIP-6.
On Starknet transactions are signed offchain, which means that the signature process happens outside the blockchain. The signed transaction is then submitted to Starknet network for verification and execution. Read more: [Starknet-js docs](https://www.starknetjs.com/docs/guides/signature/)

All Account contracts on Starknet must implement the SNIP-6 standard as mentioned earlier. The methods implemented in the SNIP-6 standard provide means to move offchain signatures onchain and execute them.

`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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


julio4 marked this conversation as resolved.
Show resolved Hide resolved

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:
julio4 marked this conversation as resolved.
Show resolved Hide resolved

a. the message has not been altered.
b. the signer owns the private key corresponding to the public key.


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.
julio4 marked this conversation as resolved.
Show resolved Hide resolved

### Custom signature validation sample

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


```rust
{{#rustdoc_include ../../listings/advanced-concepts/custom_signature_validation/src/custom_signature.cairo:custom_signature_scheme}}
```