This article will focus on StarkNet Native AA, StarkNet Wallet UX, and Comparison with the EIP-4337.
Author: ChiHaoLu(chihaolu.eth) @ imToken Labs
Special thanks to NIC Lin for reviewing this post.
Intro
Background
-
Familiar with Smart Contract Wallet and its features
-
Basic Concept of EIP-4337
-
Basic Concept of ZK-Rollup
Recap Account Abstraction
The essence of Account Abstraction can be distilled into two key points: Signature abstraction and Payment abstraction.
The aim of Signature abstraction is to enable various account contracts to utilize different validation schemes. This means that users are not limited to using only certain digital signature algorithms, but can instead choose any validation mechanism they prefer.
Meanwhile, Payment abstraction seeks to offer users a range of payment options for transactions. For instance, it is possible to pay using ERC-20 tokens instead of the native token, or to have a third party sponsor the transaction.
Table of Contents
-
AA Mechanism in StarkNet
-
Quick Look at the StarkNet AA Contract
-
UX in StarkNet’s AA
-
StarkNet AA Features
-
Summary & Comparison
AA Mechanism in StarkNet
When a user sends a transaction, it first encounters the Sequencer. As a Layer 2 solution, StarkNet does not have a role similar to the miners of the past, and this is where the Sequencer comes into play. A Sequencer must:
-
Determine transaction order
-
Verify transactions
-
Execute transactions
-
Construct blocks
Image Source: Draw by Myself
The individual responsible for these tasks is known as the Sequencer. In the context of StarkNet, the Account Abstraction Mechanism is defined within the Sequencer (with StarkNet OS). To elaborate, StarkNet AA takes inspiration from ERC-4337 and follows the four stages of transaction processing to verify the transaction, collect the fee, and execute the transaction.
In the Verification Phase:
Once a user's transaction is received, the Sequencer will verify that the nonce is valid and that the transaction is authorized by the account owner by invoking the "validate" function in the Account Contract.
Since StarkNet employs a AA account system, users are able to implement their preferred verification logic in this validation function, rather than being limited to ECDSA as in Ethereum. We will explore this feature in more detail in the AA Features section.
Once the verification has been successfully completed, the Sequencer will charge a fee from the Account Contract. If the transaction failed here, it won't charge any fee.
In the Execution Phase:
The next step is for the Sequencer to execute the transaction in the StarkNet OS, which functions similarly to the EVM.
During this process, the Sequencer generates a trace, which serves as a record of the execution process rather than the output of the function. The trace is then sent to the Prover for further processing.
Quick Look at the StarkNet AA Contract
In the previous section, we learned about the steps involved in executing a transaction within StarkNet. In this section, we will shift our attention to the implementation of an Account Contract in StarkNet and explore its key aspects.
What is the purpose of an Account Contract?
In StarkNet, an account contract serves as the main entity for users to interact with the blockchain. In addition to executing transactions sent by users, it is mainly responsible for:
-
Authorization Verification: Before executing a transaction, the Sequencer will first verify that the transaction has been authorized by invoking the validation function on the account contract.
-
Replay Protection: Sequencer will verify the nonce of the account contract. (You can find more information about StarkNet’s nonce mechanism here)
Entrypoints of StarkNet Account Contract
These entrypoints are different from the 4337 account contract.
An Account Contract must implement these mandatory Interfaces, which are the main entry points of an Account Contract:
-
__validate_declare__() -
__validate_deploy__() -
__validate__() -
__execute__()
Irrespective of the action being performed (such as calling, declaring, or deploying a contract), the corresponding __validate__() function series is invoked first.
For instance, if you wish to swap ETH for USDC on a DEX, the sequencer will initially invoke __validate__() to verify whether the transaction is authorized by you before calling __execute__() to complete the swap.
Consequently, the input parameters for __validate__() will be identical to those of __execute__().
UX in StarkNet’s AA
Account is Contract
StarkNet does not support EOAs, as all accounts are treated as contracts.
To create a new account, a contract must be deployed. The Account Contract can be utilized for various activities within StarkNet, including transfers, swaps, and the invocation of other contracts using arbitrary data.
Deployed by itself
Creating an account involves the following steps:
-
Generate a new keypair (generate public and private keys and store them securely; in this step, the account has not been deployed).
-
Compute your would-be account address off-chain.
-
Transfer ETH to this undeployed account (e.g. transferred from another Deployed Account or StarkGate).
-
Send the
deploy_accounttype transaction to deploy this account.
UX?
Deployment UX between AA wallet and EOA wallet
Users may find it confusing to use an AA wallet, because they do not need to deploy anything and can simply deposit ETH and engage in various transactions with EOA wallet. However, in StarkNet, every user must deploy their account first, which may lead to confusion regarding why they need to pay to "set up a wallet."
ArgentX offers an excellent UX solution by hiding the account deployment transaction from the user's perspective. Users can create a wallet, deposit sufficient ether, and engage in various transactions without being aware of the account deployment transaction. Behind the scenes, ArgentX will initiate the account deployment transaction for the user before sending the user's first transaction.
Therefore, users will not be aware that an account deployment transaction has occurred in the first place.
Astute users may notice that the transaction fee for the first transaction is higher than expected. This is because ArgentX charges the deployment fee in the first transaction.
Other UX Differences with EOA Wallet?
The user experience of using a StarkNet AA wallet is not significantly different from that of using an Ethereum EOA wallet, except for the account deployment process.
Other UX Difference with 4337?
While 4337 allows users to send the UserOp before deploying the Wallet Contract, and the Entry Point Contract will deploy the wallet contract with the initcode embedded in the UserOp, in StarkNet, you must deploy the account contract first before sending any transactions to it.
StarkNet AA Features
EIP-4337 also share the same features.
Now that we understand users can define the functionality of their account, we can see that an account contract can perform a simple signature check and call the destination, or it can be programmed to do almost anything.
More Operations
-
Only agree to pay for the transaction if some conditions are satisfied.
-
Daily Txs Limitation
-
Black/White Addresses List
-
-
Use funds withdrawn from a mixer to pay for the transaction.
-
…
MultiCall / Batch transactions
By wrapping a series of calls, such as approve() and transferFrom() in ERC-20, as MultiCalls and submitting them to the Account Contract, we can execute multiple operations in a single transaction. This way, we can avoid signing and paying a basic transaction fee for each individual call if they were all made as standalone transactions.
Different Validation Method
We have the freedom to design our own validation mechanism in the validate functions. For example, we can verify signatures using various algorithms such as Stark Curve, secp256k1, secp256r1, and even employ a Multi-Signature mechanism. Moreover, these signature algorithms can be Quantum Resistant and Gas-Efficient as well.
Plugin
Account Contract can also implement Plugin mechanism which allows for future extensions. You can add a Plugin that can be used in both the validate and execute functions to extend the features of your account.
- Session Key: The user can authorize a Dapp (e.g., Game-Fi or Social-Fi Blog) to execute transactions on their behalf with constrained capabilities for a predefined period. This eliminates the need for the user to sign transactions every time.
Paymaster
The current transaction fee in StarkNet is tied to the use of Ether. However, in the future, StarkNet will allow users to choose how to pay for transaction fees. To enable this, StarkNet follows the guidelines laid out in EIP 4337 and allows the transaction to specify a specific contract, a paymaster, to pay for their transaction.
During the validation phase, the sequencer needs to validate that the paymaster has sufficient funds to cover the transaction.
Once validation is complete and successful, the sequencer will request the paymaster to pay for the transaction before it is executed.
Users can choose to pay the Paymaster using ERC-20 or a credit card prior to sending the transaction, or allow the Paymaster to request an ERC-20 fee from the Account Contract after the transaction has been executed.
Summary & Comparison
Summary
From the previous section, we have learned what these two goals mean:
-
Signature Abstraction: We can achieve Signature abstraction using different curves, multi-sig, hardware signers, 2FA, 3FA, or even plugins, by implementing them in our validate series function.
-
Payment Abstraction: We can expect that the paymaster will be implemented in StarkNet, which will allow us to use tokens other than ETH to pay for transactions, and even request others to pay on our behalf.
Comparison between StarkNet AA & 4337
The main differences between EIP-4337 and StarkNet Native AA are:
-
Sequencer in Starknet is functionally equivalent to Bundler in 4337.
-
We must deploy the Account Contract before sending the transaction in StarkNet AA.
Reference
-
StarkNet Tx & State
-
StarkNet AA
-
My previous articles on Ethereum AA