Introduction
On Ethereum there are two types of accounts:
The former type is the only one that can initiate transactions, while the latter is the only one that can implement arbitrary logic. For some use-cases, like smart-contract wallets or privacy protocols, this difference can create a lot of friction.
As a result, such applications require L1 relayers, e.g. an EOA to help facilitate transactions from a smart-contract wallet.
Accounts in ZKsync Era can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. This feature, called "account abstraction" (AA), aims to resolve the issues described above.
Native Account Abstraction on ZKsync Era fundamentally changes how accounts operate by introducing the concept of Smart Accounts and Paymasters. Smart Accounts are fully programmable, allowing for various customizations such as signature schemes, native multi-sig capabilities, spending limits, and application-specific restrictions.
Paymasters, conversely, can sponsor transactions for users, enabling users to pay transaction fees in ERC20 tokens. This innovative approach to account management significantly enhances user experience, security, and flexibility, paving the way for broader adoption of blockchain technology.
Account versioning
Account versioning in ZKsync facilitates future updates and changes to the account abstraction protocol by allowing accounts to specify which version of the protocol they support. This capability ensures backward compatibility and supports evolutionary development without disrupting existing account functionalities. The versions supported currently are:
None
: Indicates a basic contract that is not designed to initiate transactions. Such accounts are passive and should not be used as thefrom
field in a transaction.Version1
: Supports the initial version of the account abstraction protocol, incorporating all foundational features and specifications.
Nonce ordering
Nonce ordering is a critical aspect that dictates how transactions from accounts are processed concerning their sequence. Accounts in ZKsync can choose between two types of nonce ordering:
Sequential
: Nonces must follow a strict sequential order similar to externally owned accounts (EOAs). This setting ensures that transactions are processed in a specific sequence, requiring transactionX
to be processed before transactionX+1
.Arbitrary
: Allows transactions to be processed in any order, regardless of their nonce values. While this mode offers flexibility, it currently may lead to transactions being rejected or stuck in the mempool due to nonce mismatches.
It's important to note that these settings serve as guidelines to the operator for managing the mempool and are not enforced by system contracts. However, they provide a framework for expected transaction handling.
Returned magic value
Both accounts and paymasters in ZKsync are required to return a specific magic value during transaction validation. This magic value is critical for ensuring the integrity and correctness of transactions on the mainnet:
- Validation Enforcement: On the mainnet, the magic value is strictly enforced to confirm that transactions meet all protocol criteria before execution.
- Fee Estimation: During fee estimation, the magic value is not considered, focusing solely on the computational costs associated with executing the transaction.
To aid in accurate fee estimations, accounts are advised to execute all operations during validation as they would under normal circumstances but return an invalid magic value only at the end of the validation process. This approach helps in approximating the transaction's cost more accurately.