Account Abstraction

Account abstraction (AA) is a pivotal feature in ZKsync that allows for greater flexibility and functionality in how accounts operate and interact with transactions.

For a comprehensive understanding, it is recommended to review the detailed AA protocol documentation.

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 the from 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 transaction X to be processed before transaction X+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.