FAFO: Fast Ahead-of-Formation Optimization

• FAFO is a blockchain scheduling architecture that reorders EVM transactions ahead-of-formation to maximize transaction-level parallelism while preserving block state through QMDB.
• It uses a four-stage pipeline—ParaLyze, ParaFramer/ParaBloom, ParaScheduler, and Block Formation—with Bloom filters and DAG-based scheduling to efficiently manage conflicts under high contention.
• Empirical results highlight over 1M TPS on a single node, showcasing significant throughput gains and cost reduction compared to traditional sequential and speculative execution approaches.

Searching arXiv for the specified papers to ground the article and verify metadata. Fast Ahead-of-Formation Optimization (FAFO) denotes a proposer-side transaction scheduling and execution pipeline for Ethereum Virtual Machine (EVM) workloads that reorders transactions before block formation to maximize transaction-level parallelism (TLP) while still Merkleizing every block through QMDB-backed state persistence (Zarick et al., 14 Jul 2025). In a separate and terminologically distinct usage, the phrase is described as “conceptually aligned” with affine formation control design, where the interaction structure is optimized offline in advance to accelerate online stabilization dynamics; however, that paper does not explicitly define FAFO as its own formal framework (Li et al., 25 Aug 2025). Taken together, these sources establish FAFO primarily as a blockchain scheduling architecture, while also motivating a broader “ahead-of-time optimization” interpretation in distributed control.

1. Definition and terminological scope

In the blockchain setting, FAFO is an end-to-end EVM execution pipeline that reorders transactions ahead of block formation, groups non-conflicting transactions into frames using approximate read/write sets, uses a cache-resident Bloom-filter structure called ParaBloom to detect conflicts cheaply, schedules and executes the framed transactions using a DAG-based scheduler called ParaScheduler, and persists state in QMDB so that each block still has a Merkle root (Zarick et al., 14 Jul 2025). The key architectural choice is that the heavy parallelization logic occurs before the block is formed and disseminated, so validators can replay the resulting stream with low overhead.

The motivating problem is data contention. Real EVM workloads are described as exhibiting hotspots, with “0.1% of storage slots account for 62% of accesses,” and many parallel EVM schemes based on optimistic concurrency control (OCC) and speculative execution are reported to deliver only “2–5× speedups” under contention (Zarick et al., 14 Jul 2025). FAFO targets this regime by shifting the optimization problem from post hoc execution of a fixed block to proposer-side construction of a conflict-aware stream.

A common terminological misconception is to treat “FAFO” as an already standardized cross-domain acronym. The available evidence is narrower. The blockchain paper formally introduces “FAFO: Over 1 million TPS on a single node running EVM while still Merkleizing every block” (Zarick et al., 14 Jul 2025). By contrast, the formation-control paper states only that its affine formation design objective is “conceptually aligned with a ‘Fast Ahead-of-Formation Optimization (FAFO)’ idea,” namely an offline optimization of the interaction structure to accelerate online convergence (Li et al., 25 Aug 2025). This suggests a broader editorial umbrella for ahead-of-time optimization, but not a settled shared nomenclature.

2. Pipeline architecture and proposer-side scheduling

FAFO is organized as a four-stage pipeline: ParaLyze, ParaFramer + ParaBloom, ParaScheduler, and Block Formation (Zarick et al., 14 Jul 2025). ParaLyze preprocesses mempool transactions and computes approximate read/write sets. ParaFramer and ParaBloom detect approximate conflicts and pack non-conflicting transactions into frames. ParaScheduler builds conflict DAGs and dynamically schedules parallel execution of the framed stream. Block Formation then synchronizes, flushes state, Merkleizes via QMDB, and inserts block headers.

The architecture treats the mempool as the raw input and constructs a parallelism-optimized transaction stream before block segmentation. This differs from conventional order-execute pipelines in which a proposer supplies a block and execution clients attempt to parallelize it afterward. FAFO’s design therefore relocates scheduling from the validator path to the producer path. The source describes this as allowing the producer to use “arbitrarily sophisticated (and upgradable) scheduling heuristics” without requiring all validators to replicate the same heavy logic or triggering hard forks (Zarick et al., 14 Jul 2025).

The interaction between components is explicit. Transactions arrive at ParaLyze, which simulates each transaction against a snapshot state, or uses metadata such as EIP-2930 access lists, to produce an approximate read/write set $\widehat{RW}_T$. ParaFramer then attempts to insert each transaction into an active frame whose aggregate read/write summaries do not conflict with the candidate. Finalized frames are passed to ParaScheduler, which reconstructs the frames, builds per-slot DAGs, and dispatches executable transactions to worker threads running REVM against QMDB-backed state. After execution, ParaScheduler checks whether the actual $RW_T$ matches $\widehat{RW}_T$; mismatches are dropped and returned to the mempool for rescheduling (Zarick et al., 14 Jul 2025).

The producer-side assumption is also part of the model. FAFO assumes a block producer is elected for a sufficiently long interval, “as in EOS, Solana,” so that it observes a large enough batch of pending transactions to expose substantial TLP (Zarick et al., 14 Jul 2025). This is not merely an implementation detail; it is a condition under which ahead-of-formation scheduling becomes operationally meaningful.

3. Conflict model, frame construction, and scheduling mechanics

FAFO defines two transactions as conflicting when they both access the same storage location and at least one access is a write. For transactions $T_i$ and $T_j$ with true read and write sets $(R_i, W_i)$ and $(R_j, W_j)$, a conflict exists if

$$(R_i \cap W_j) \cup (W_i \cap R_j) \cup (W_i \cap W_j) \neq \varnothing.$$

A schedule is then conflict-serializable if its effect is equivalent to some serial schedule in which conflicting accesses occur in the same order (Zarick et al., 14 Jul 2025).

ParaLyze computes approximate read/write sets

$$\widehat{RW}_{T_i} = \{\widehat{R}_{T_i}, \widehat{W}_{T_i}\}.$$

These are typically obtained by simulation against a snapshot state. Because multiple transactions may be simulated against the same initial state, the approximation can differ from eventual execution-time behavior. For some subsets of transactions, such as ERC20 transfers with EIP-2930 access lists, the approximation may be exact (Zarick et al., 14 Jul 2025). This makes FAFO neither purely static analysis nor optimistic speculative execution; it is a hybrid pipeline in which conservative prescheduling is followed by post-execution validation.

ParaBloom is the key conflict-detection structure. For each active frame $F$, it maintains a Bloom filter for the frame’s aggregate read set $RW_T$0 and another for the aggregate write set $RW_T$1. A candidate transaction $RW_T$2 is admissible if

$RW_T$3

with the set intersections checked approximately through Bloom membership tests (Zarick et al., 14 Jul 2025). The false-positive probability is given approximately by

$RW_T$4

The implementation is intentionally cache-centric. The reported parameters are a 64-bit CPU with a 64 KiB L1 cache; 64 frames; and, for each frame, two 2048-bit Bloom filters, giving 4096 bits or 512 bytes per frame. The resulting 64 frames $RW_T$5 512 bytes equals 32 KiB, which fits in half of L1. The frame index is represented via a 64-bit word, one bit per frame, permitting efficient bitset operations (Zarick et al., 14 Jul 2025). The stated empirical effect is that Bloom filter false positives reduce achievable TLP by about 8%, which is characterized as acceptable given the net throughput gains.

ParaFramer uses greedy frame packing. It traverses the transaction list once and assigns each transaction to the lowest-index active frame for which it is admissible. If a transaction conflicts with all active frames, the largest frame by transaction count is finalized, sent to ParaScheduler, reset, and reused for the new transaction (Zarick et al., 14 Jul 2025). The rationale is explicit: FAFO does not attempt optimal global coloring of the precedence graph, because that would be too expensive and incompatible with streaming and latency constraints.

ParaScheduler then constructs per-slot DAGs using true read/write sets. For each storage slot $RW_T$6, a DAG $RW_T$7 is maintained; when a transaction $RW_T$8 touches $RW_T$9, edges are added from prior conflicting accesses to enforce the relevant happens-before relation, avoiding redundant transitive edges (Zarick et al., 14 Jul 2025). A transaction can execute only when its predecessors in all relevant DAGs have completed. Because frames are constructed to be internally conflict-free with respect to approximate sets, ParaScheduler does not need to check intra-frame conflicts, only cross-frame edges, which reduces DAG construction overhead.

4. Determinism, correctness, and authenticated state

FAFO’s correctness target is conflict-serializability. The source argues first that, for each storage slot $\widehat{RW}_T$0, the local schedule induced by DAG $\widehat{RW}_T$1 is conflict-serializable for that slot, because conflicting operations are ordered consistently with the original stream and execution only proceeds when all predecessors on $\widehat{RW}_T$2 have finished. Second, for a transaction touching multiple slots, ParaScheduler dispatches it only when all predecessors in each relevant per-slot DAG have completed. Third, because the global schedule respects all per-slot serializable orders simultaneously, it is conflict-serializable in the classic database-theoretic sense. Fourth, the total order of the underlying stream ensures that the union of per-slot precedence graphs is acyclic (Zarick et al., 14 Jul 2025).

Determinism is treated operationally rather than abstractly. For a given block producer running FAFO with fixed configuration, the sequence of frames, the conflict DAGs, and the actual execution order are described as fully determined by the mempool transaction set, the deterministic ParaLyze simulation, the deterministic ParaFramer/ParaBloom packing, and the deterministic ParaScheduler policy (Zarick et al., 14 Jul 2025). Validators need not reproduce the proposer’s heavy scheduling path; they may replay a linearized execution order or run the same deterministic ParaScheduler logic and obtain the same state root and receipts.

Approximation errors are handled conservatively. When actual $\widehat{RW}_T$3 differs from $\widehat{RW}_T$4, the transaction is dropped after execution, its effects are discarded, and it is returned to the mempool for rescheduling (Zarick et al., 14 Jul 2025). Dynamic calls, re-entrancy, and hidden state dependencies are therefore not ignored; they are detected implicitly in the actual read/write sets during execution, and any mismatch relative to the precomputed approximation is converted into retry rather than inconsistency.

A central architectural property is that FAFO still Merkleizes the entire world state after every block via QMDB. At block boundaries, execution threads synchronize, state changes are flushed from REVM to QMDB, QMDB computes the new authenticated state root, and the root is embedded in the block header (Zarick et al., 14 Jul 2025). This is presented as critical for light clients, stateless validation, and ZK-based vApps. The paper contrasts this with high-throughput designs that Merkleize infrequently or omit block-level Merkleization entirely.

5. Throughput, scaling, and cost characteristics

The reported evaluation uses an AWS i8g.metal-24xl instance with 96 vCPUs, 768 GiB DRAM, and 6 local NVMe SSDs in RAID0 providing approximately 22.5 TB, 2.16M IOPS, 26 GB/s read, and 20 GB/s write. The software stack consists of REVM for EVM execution, QMDB for verifiable storage, and a Rust implementation of the FAFO pipeline with ARM-optimized code paths and cache-aware data layouts (Zarick et al., 14 Jul 2025).

Two synthetic workloads are evaluated: native ETH transfer and ERC20 transfer. Native transfer alters two state slots: sender balance and receiver balance. ERC20 transfer alters three state slots: sender ETH balance for gas or fees, sender token balance, and receiver token balance. The workload model includes a contention ratio $\widehat{RW}_T$5 and a hot-set size $\widehat{RW}_T$6, with smaller $\widehat{RW}_T$7 implying more concentrated hotspots (Zarick et al., 14 Jul 2025).

The headline throughput numbers are summarized below.

Workload	Throughput
Native ETH transfers	1,121,732 TPS
ERC20 transfers	565,956 TPS

These results are reported for the full FAFO pipeline integrated with REVM and QMDB, with every block state Merkleized (Zarick et al., 14 Jul 2025).

Scaling behavior is described as linear with core count for the workload $\widehat{RW}_T$8 up to the 96 cores tested, with FAFO extracting about 130 TLP and extrapolated linear scaling until core count exceeds that TLP level (Zarick et al., 14 Jul 2025). Under high contention, including a case with 99% of requests hitting 0.0001% of keys, the paper reports that FAFO still achieves greater than 130 TLP and greater than 1.1M TPS. An additional observation is that, for very small $\widehat{RW}_T$9 and high $T_i$0, throughput can increase because hot account contexts fit entirely in L1 cache, improving execution efficiency per transaction (Zarick et al., 14 Jul 2025).

The scheduling overhead is evaluated separately in an ablation study. Running only ParaFramer and ParaScheduler, without REVM execution, yields more than 2M TPS, which is used to argue that scheduling and conflict detection overhead is small relative to execution (Zarick et al., 14 Jul 2025). This point is tied directly to the L1-resident design of ParaBloom, the greedy frame-packing strategy, and the reduced DAG overhead obtained by omitting intra-frame conflict checks.

Cost is also treated quantitatively. The paper states that FAFO’s single-node configuration achieves about 1M TPS for approximately USD \$T_i$165,361 per month on GCP according to referenced benchmarks, corresponding to a 91% cost reduction (Zarick et al., 14 Jul 2025). Because the cost comparison is defined in terms of benchmark cloud compute configurations, it should be read as a benchmarked infrastructure comparison rather than a universal cost law.

6. Relation to other execution models, broader usage, and limits

Relative to sequential EVM execution, FAFO is distinguished by reordering transactions ahead of block formation rather than merely optimizing the execution of an already fixed block (Zarick et al., 14 Jul 2025). Relative to OCC-based or speculative parallel EVM systems such as Block-STM, ParallelEVM, Forerunner, OptME, and DMVCC, FAFO is described as not relying on speculative execution and aborts as the primary mechanism. Instead, it performs proposer-side reordering using approximate read/write sets and Bloom-filter-based conflict avoidance, with validators replaying a near-optimal conflict-serializable order (Zarick et al., 14 Jul 2025).

Relative to sharded execution, FAFO is presented as orthogonal rather than contradictory. Sharding scales horizontally but introduces cross-shard communication, synchronization, and shared sequencer complexity, whereas FAFO reaches similar throughput on one node and could in principle be applied per shard in a sharded system (Zarick et al., 14 Jul 2025). The paper also notes implications for rollups and ZK-based execution environments, particularly because per-block Merkle roots are preserved through QMDB.

The main limitations are explicitly bounded. The benchmarks are synthetic ETH and ERC20 transfers; real workloads involving DEXes, DeFi composability, and more complex storage behavior may exhibit different conflict patterns. Approximate read/write sets can be inaccurate for dynamic behaviors, and mis-approximation leads to drops and rescheduling that reduce effective throughput. The full FAFO pipeline raises hardware demands on producers, even if validator-side overhead is lower (Zarick et al., 14 Jul 2025). These caveats matter because the reported million-TPS performance is contingent on the interaction between the scheduler, the workload, and the hardware profile.

The second paper in the source set uses the phrase in a different way. In affine formation control, the central problem is to design a stress matrix $T_i$2 and associated graph so that the formation dynamics

$T_i$3

are stable, sparse, and fast-converging. That paper formulates a centralized offline convex optimization which pre-computes the stress matrix for a desired formation, balancing $T_i$4-promoted sparsity against a spectral-shaping term that increases the smallest nonzero eigenvalue and therefore convergence speed (Li et al., 25 Aug 2025). It then states that this is “conceptually aligned with a ‘Fast Ahead-of-Formation Optimization (FAFO)’ idea” because the formation interaction structure is optimized offline in advance to make online stabilization as fast as possible.

This cross-domain appearance should be interpreted cautiously. The blockchain paper establishes FAFO as a named system with defined components, performance claims, and an open-source implementation (Zarick et al., 14 Jul 2025). The formation-control paper instead offers a mathematically related intuition: optimize the interaction structure ahead of deployment, then exploit the resulting fast online dynamics (Li et al., 25 Aug 2025). A plausible implication is that “ahead-of-formation optimization” can function as a generic design pattern across distributed systems, but the explicit acronym FAFO is formalized only in the blockchain context within the provided sources.