A closer look at Layer Zero's FAFO: 1 million TPS on Ethereum?

Key information

• FAFO (Fast Ahead-of-Formation Optimization) is a protocol that reorders transactions to optimize their execution.
• FAFO enables a form of parallelization that can be adapted to most virtual machines currently on the market.
• In testing, FAFO allowed a single node to execute 1.12 million ETH transfers per second or 565,000 ERC20 transfers.

---

Introducing FAFO

FAFO (Fast Ahead-of-Formation Optimization) is a protocol developed by LayerZero that reorders the order of transactions to optimize their execution. Unlike traditional databases that rely heavily on parallelization, major blockchains operate sequentially, executing transactions one after the other.

While this system is inefficient, it helps avoid collisions — situations where multiple transactions interacting with the same on-chain data would be executed simultaneously. As a result, most blockchains rely on purely linear execution, which does not fully leverage the multi-core processors used by nodes.

Some blockchains, such as Sei, were designed from the start with parallelization in mind to optimize performance. However, this requires developing new consensus mechanisms, using specific programming languages, and contributes to liquidity fragmentation.

With FAFO, LayerZero offers a protocol that reorders transactions to optimize throughput without changing Ethereum’s consensus or execution layer. It’s worth noting that although the LayerZero team developed FAFO around the Ethereum Virtual Machine (EVM), it could theoretically work on most currently available virtual machines.

---

How FAFO works

FAFO’s architecture can be summarized in three components: ParaLyze, ParaFramer, and ParaScheduler.

ParaLyze

For parallelization to work, conflicting transactions must be executed sequentially. For example, if two transactions want to perform a swap on the same pool, it is crucial to define an execution order.

To determine whether two transactions might conflict, we analyze the memory fields each transaction tries to access. ParaLyze’s role is to analyze pending transactions in the mempool and run simulations to estimate the memory regions each transaction will interact with.

At this stage, the transaction order is not yet fixed; rather, it’s a first filtering step aimed at identifying transactions that must be handled sequentially.

ParaFramer

Once ParaLyze has estimated the read and write memory regions for each pending transaction, ParaFramer can start organizing them. Transactions are grouped into frames, each frame consisting of transactions that do not conflict and can thus be executed in parallel.

To efficiently detect potential overlaps among transactions, ParaFramer uses ParaBloom, a data structure that allows fast and resource-efficient comparison of read/write sets.

This is an iterative process during which transactions are examined and placed one by one either into an existing frame if there is no conflict or into a new frame. This creates a sequence of statistically non-conflicting transaction groups.

ParaScheduler

The final step is handled by ParaScheduler, which converts each frame into a Directed Acyclic Graph (DAG). Simply put, this is a schema that describes the sequence of transactions. For instance, if one transaction must occur before another because they access the same memory region, a priority link is established.

Using this graph, ParaScheduler can immediately launch parallel execution of the entire transaction set. Once a transaction is executed, dependencies are updated, and subsequent transactions in the graph sequence can then be executed.

At the end of execution, the system compares actual memory accesses with those predicted by ParaLyze. In the rare cases where discrepancies are found, the transaction is removed from the block and returned to the mempool. This ensures the final block order contains no conflicts while maintaining high throughput.

---

Limitations of FAFO

During testing, the LayerZero team managed to execute 1.12 million ETH transfers per second or 565,000 ERC20 transfers per second.

This throughput is extremely impressive compared to Ethereum’s average of 15 TPS. However, it is not entirely fair to compare the two solely on this metric for several reasons.

The LayerZero team’s test was conducted on a single AWS server with the following configuration: 96 virtual cores, 786 GiB of DRAM, and 6 NVMe SSDs configured in RAID0 for a total of 22.5 TB of storage. For those unfamiliar with hardware, this configuration costs about $6,000 per month at current AWS rates and is 6 to 12 times more powerful than most professional Ethereum nodes.

In the scenario of using FAFO on Ethereum, its performance hypothetically would therefore be 6 to 12 times lower, since the algorithm’s performance scales linearly.

Additionally, the test was performed on a single server. On Ethereum, transaction information is transmitted peer-to-peer, requiring multiple hops between nodes before reaching the entire network, with potential slowdowns depending on each node’s bandwidth.

In practice, FAFO’s performance on Ethereum would likely be much lower, limited by the slowest node’s capacity.

It is important to remember that FAFO is purely a transaction reordering protocol for optimizing execution. It sits between the mempool and block production, without interfering with the consensus or execution layer. While it could theoretically improve transaction throughput, its use on Ethereum would currently be very limited. The 12-second block time imposes a hard limit on the number of transactions that can be processed.

To illustrate, using FAFO on Ethereum today would be like having an ultra-fast race car but hitting a red light every hundred meters.

Furthermore, FAFO optimizes transaction order for execution speed — a criterion that matters little to validators, who prefer selecting transactions paying the highest fees. In the current context and with the block time limitation, FAFO has very limited utility.

---

Potential Use Cases for FAFO

Nevertheless, FAFO remains an interesting protocol that explores the limits of what the EVM can achieve, with a few possible use cases.

Block merkleization

One FAFO feature not yet mentioned is per-block merkleization. Simply put, a Merkle tree is a data structure that summarizes a system’s state via a unique hash. In blockchains, this allows verification that information has been included on the network without downloading everything. Each time a new block is added, a new hash is computed. Merkleization consists of adding a block to the Merkle tree, allowing even those without the full blockchain to verify that their transaction was included.

On Ethereum, this merkleization occurs at every block, but on faster blockchains or L2s, this step is not always systematic. This means that while a transaction might be validated very quickly, it may take several seconds (or even tens of seconds) to obtain proof that it has been included (unless you run a full node).

FAFO enables maintaining high throughput with per-block merkleization. FAFO could therefore be implemented on very fast networks like MegaETH to provide both high performance and high-frequency verification.

EVM implementation

A second possible use case would be an implementation on Ethereum. As we have seen, even though the performance achieved by LayerZero’s team may not be able to reproduce on a blockchain like Ethereum immediately, FAFO offers a way to accelerate transaction execution on the EVM. If FAFO were gradually integrated into Ethereum clients and the gas limit increased or the block time reduced, it could potentially lead to a significant increase in the number of transactions possible on mainnet without reducing network decentralization.

The challenge here is that, in the current framework, validators have more incentive to maximize gas per block rather than execution speed. A practical FAFO implementation would thus require both its integration into execution clients and a modification of the gas limit or a reduction of block time.

However, the real impact of such a measure would probably be a reduction in decentralization. Smaller validators would be forced to use fast but less gas-optimized execution, while larger validators could continue optimizing gas (and thus their revenue) simply by investing in more powerful hardware.

---

Conclusion

In conclusion, with FAFO, the LayerZero team has presented an innovative solution to push the EVM’s boundaries. However, because incentives for validators are unclear, implementing it as-is would likely be a net negative for the network, even if it could theoretically increase transaction throughput.