FAFO Deep Dive 🧠 The two bottlenecks to blockchain scaling are state growth and throughput. State growth means that you have to store data about every user account, every smart contract, and every transaction - requiring gigantic fast disks. Throughput means you want to process many transactions in a short period of time, like when the president drops a memecoin. FAFO, a new blockchain transaction scheduler from LayerZero, optimizes the throughput problem. Since blockchains are decentralized databases, and we know how to heavily optimize database writes, why is transaction throughput such a problem in the year 2025? Blockchains have special properties, known as authenticated data structures (think merkle tree) that compress the entire state into a single bytes blockhash to prove things about the current state. This blockhash makes features like L2s and light clients and even chaining blocks together possible. The difference between storage structures in blockchains and databases is that databases neatly pack storage slots together, while blockchains tend to spread out storage slots. This makes reads and writes much more expensive in a blockchain, because you're reading from all different partitions of the SSD. So the first trouble is that you need to minimize SSD reads/writes at all costs. The second trouble is that while databases are built to be massively parallel, blockchain transactions cannot always be parallelized. What if two people try to buy the same Uniswap coin at the exact same price with zero slippage? Only one of them will succeed. So blockchains need to order conflicting transactions. So the key to increasing transaction throughput is (1) minimizing the number of reads/writes from storage; (2) parallelizing transaction processing as much as possible while handling conflicting txs. Turns out that one solution fixes both these problems at the same time! Transactions are conflicting only if they read from or write to the same storage slots. The SVM and EVM take different approaches here. The SVM makes you hardcode which storage slots you're going to read/write at transaction submission time, which lets the nodes be more aggressive on optimization but creates a harder developer experience for composable applications. The EVM has optional access lists that were never really gaspriced correctly so they go unused, and lets any transaction touch any auth'd storage slot without any prior warning. FAFO is a sequence of algorithms that work on any VM, although the benefit will be highest on EVM. The key idea is to group nonconflicting transactions into frames, and then run each transaction within a frame on a separate compute core for intra-block parallelism. The thought process here is not novel, but the best-in-class implementations of each stage are. 1) ParaLyze - Every mempool transaction is speculatively analyzed to see what storage slots it will touch. This is done upfront with heuristics rather than perfect computation. 2) ParaFramer - Every mempool transaction is then greedily packed into frames (groups of nonconflicting transactions) using bloom filters on storage slots for probabilistic conflict detection (every conflict is guaranteed detected, and some false positives are too). 3) ParaScheduler - Because storage slot read/writes are expensive, you want to execute every transaction that touches a specific storage slot in sequence. For example, 10 Uniswap swaps on the same pool should happen right in order, then you don't have to reload the Uniswap storage data from disk multiple times. - For each predicted storage slot a directed acylic graph (DAG) of transactions is computed by separate cores. A DAG is a fancy way of saying A should happen before B should happen before C, like A -> B -> C. Then the transactions in each DAG are executed in ordered direct succession, minimizing storage slot reads while avoiding conflicts. TLDR - FAFO gets up to 1.1m EVM transactions per second on reth, specifically solving the throughput problem (without addressing bandwidth or state needs). - Speculative state slot preprocessing, frame construction with bloom filters, and then frame DAGs on storage slots for execution. - It's a heuristic algorithm not an optimal solution, but a strong improvement on existing naive methods. - Probably most relevant for new single-sequencer chains like MegaETH where bandwidth is not a concern, but also useful for shorter blocktimes on Ethereum/Monad while preserving decentralization.