Parallelization of Transactions and 2D Nonce Management

Jaume Alavedra
Group 665.svg

Nonces are critical for ensuring the correct ordering and execution of transactions. Traditionally, Externally Owned Accounts (EOAs) use a single-dimensional nonce system, incrementing the nonce value by one with each transaction. This guarantees sequential processing but limits the ability to execute transactions in parallel.

The introduction of smart accounts and account abstraction brings a more advanced two-dimensional (2D) nonce system, enabling parallel execution of user operations (UserOps). This article provides a technical overview of 2D nonce management and its role in transaction parallelization.

Limitations of One-Dimensional Nonces

EOAs use a single-dimensional nonce that increments sequentially. This method ensures that transactions are processed in the order they are created. For instance, if a user initiates three transactions with nonces 1, 2, and 3, they must be executed in that order. This sequential execution can hinder performance and user experience, especially when dealing with independent transactions that could be processed simultaneously.

Two-Dimensional Nonces

Account abstraction introduces two-dimensional nonces, allowing for more flexible and parallel transaction management. A 2D nonce consists of two components:

1. Nonce Key: A unique identifier for a group of related transactions. 2. Nonce Value: The sequential counter within that group. This structure separates transaction dependencies into different groups, enabling parallel execution of independent transactions.

How 2D Nonces Work

The implementation of 2D nonces can be illustrated with the getNonce() method, which combines the nonce sequence number with a left-shifted value of the nonce key:


_10
return nonceSequenceNumber[sender][key] | (uint256(key) << 64);

This method produces a unique nonce by combining the current sequence number with a shifted key value, representing all possible 2D nonces as a single number.

Openfort simplifies the complexity of managing 2D nonces by handling them at the server level. Developers can focus on building their applications without worrying about the underlying nonce management. Openfort's implementation ensures that transactions are automatically assigned the appropriate nonce keys, enabling parallel execution without additional developer intervention.

Parallel User Operations

Parallel user operations are transactions that can be executed independently and simultaneously. By assigning different nonce keys to these operations, users can bypass the sequential execution requirement. For example:

  • Transaction 1: Swap 1 ETH for 4000 USDC.
  • Transaction 2: Swap 4000 USDC for 7000 NATION.
  • Transaction 3: Buy 1 NFT for 100 USDC.

In a traditional EOA setup, Transaction 3 would have to wait for the completion of Transactions 1 and 2. With 2D nonces, Transactions 1 and 2 can be grouped under one nonce key and executed sequentially, while Transaction 3, using a different nonce key, can be executed in parallel.

Other more advance cases can also be covered automatically. For example:

  • Trade 1: Swap 100 USDC to DAI.
  • Trade 2: Swap 100 DAI to USDT.
  • Trade 3: Swap 1 WETH to USDT.

Openfort's server-level 2D nonce management ensures that Trades 1 and 2, which are dependent, are executed sequentially, while Trade 3, which is independent, can be executed in parallel without any additional code.

Share this article