Extend OpenZeppelin Cairo Contract to Support Multiple Signers

[neotheprogramist]

Description

We need to expand the current account contract available at OpenZeppelin's cairo-contracts. This enhancement will allow it to support WebAuth signers and session tokens. Additionally, for better integration with our project, we should import the open-zeppelin repository into the scarb project and introduce the modified version of this contract within our repo.

Objectives

1. Multiple Signer Support: The extended account contract should seamlessly integrate:

   • WebAuthn Signer
   • Stark Pair
   • Session Tokens

2. Signature Data Enhancement: When signatures are made, the type of signer employed must be evident within the signature data.

3. Default Signer: On account registration, the default signer should be set to the WebAuthn signer.

4. Proposal Creation: Before embarking on such a significant task, drafting a proposal detailing the changes and the new interface can act as a foundation for the development. This blueprint will ensure alignment among all team members.

Acceptance Criteria

• Extension of the account contract to incorporate multiple signers.
• Signature data should clearly indicate the type of signer used.
• Integration of the default WebAuthn signer during the registration process.
• Draft and finalize a detailed proposal before development.

Suggested Development Order

1. Migrate Account Smart Contract to starknet-foundry Project - Issue #16

   • Branch Name: 14-1-foundry-account

2. Enhance Contract with Stark Pair Integration - Issue #19

   • Branch Name: 14-2-stark-pair-auth

3. Enhance Contract with WebAuthn Signer - Issue #17

   • Branch Name: 14-3-webauthn

4. Enhance Contract with Session Tokens Integration - Issue #18

   • Branch Name: 14-4-sessions

5. Enhance Account Contract to Support Multiple WebAuthn Credentials and Session Tokens - Issue #20

   • Branch Name: 14-5-multi-webauthn

[tarrencev]

This looks good. Worth noting the Stark Pair is the native curve and can be generated on the rust side simply with https://github.com/xJonathanLEI/starknet-rs and verified inside cairo with syscalls

Regarding the Signature data should clearly indicate the type of signer used, please take a look at the previous Cairo 0 implementation at https://github.com/cartridge-gg/cartridge-controller/blob/01a7a7b708490ab1cc85150f03b0ec35286b9851/src/controller/library.cairo#L28

The approach was for the first element in the signature to signify the key. 0 for default or otherwise mapped to a boolean if set by the public key.

In contrast to the existing implementation, where it only supports a single webauthn signer and arbitrary stark pairs, we would like this one to support multiple webauthn credentials and session tokens too. Accounts should be able to add other signers.

For the session token, the flow is:

• Construct the session token payload
• Generate a stark pair key
• Sign the session token root hash
• Register the stark pair with the account contract, using webauthn to sign the txn

[piniom]

Do you know:
What is the reason behind the __execute__ being underscored?
Is the is_valid_signature called somewhere implicitly (like upon every transaction)? If not what is the relationship between the is_valid_signature and __execute__?

[neotheprogramist]

Do you know: What is the reason behind the __execute__ being underscored? Is the is_valid_signature called somewhere implicitly (like upon every transaction)? If not what is the relationship between the is_valid_signature and __execute__?

The question is referring specifically to this piece of code
https://github.com/OpenZeppelin/cairo-contracts/blob/main/src/account/account.cairo#L77-L108

[neotheprogramist]

Underscored Methods: __execute__ and __validate__

The methods __execute__ and __validate__ are surrounded by double underscores because they are special methods that are directly invoked by the StarkNet protocol. Here's a clearer understanding:

1. __execute__ and __validate__ are internal methods that the StarkNet protocol interacts with when processing transactions.
2. It is crucial for these methods to ensure that their caller is always zero. If this check isn't enforced, it introduces a significant security vulnerability. The check to ensure the caller is zero verifies that the call was made directly by the StarkNet protocol and not an external entity.

The is_valid_signature Function

The is_valid_signature function evolved in its role within the StarkNet network:

1. Originally, is_valid_signature was not part of the essential interface.
2. However, as the StarkNet network embraced account abstraction more fully, the function became a required element.
3. Unlike the underscored methods, is_valid_signature can be invoked from other contracts or viewed externally.

When it comes to signature checks:

• Signatures can be verified during either the validation (__validate__) or execution (__execute__) steps.
• However, it's more efficient to reject invalid signatures during the validation phase. This approach ensures you don’t bear any costs for failed transactions. It's advisable to always handle signature checks in the validation step to prevent malicious entities from depleting funds with failing transactions.

Purpose of the Account Contract

Think of the account contract as a standard "Externally Owned Account (EOA)" but with added advantages:

1. It acts as your identity within the StarkNet network.
2. You can transfer funds or perform actions (like ERC20 transactions) using this account contract.
3. An essential feature is that you can change the associated key, offering flexibility and security.

Deploying ERC20 with an Account Contract

When deploying an ERC20 contract on StarkNet, you pass the account contract to the deploy_erc20 function. The reason for this:

1. The deploy_erc20 function requires knowledge of the recipient of the initial token supply.
2. Passing the account contract provides this information, effectively setting up the recipient for the ERC20's initial tokens.