Pith. sign in

REVIEW 4 major objections 6 minor 23 references

FAFO: Over 1 million TPS on a single node running EVM while still Merkleizing every block

T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read FAFO reorders transactions before block formation, letting one 96-core server execute over 1.1 million EVM transfers per second while still Merkleizing state after every block.

desk verdict A real architectural idea with a head-turning TPS claim, but the correctness argument for dropping mismatched transactions doesn't hold as written and the benchmark doesn't yet support the headline. read the letter →

arxiv 2507.10757 v1 pith:RM7UWZ43 submitted 2025-07-14 cs.DC cs.NI

Ryan Zarick , Isaac Zhang , Daniel Wong , Thomas Kim , Bryan Pellegrino , Mignon Li , Kelvin Wong This is my paper · ORCID
classification cs.DCcs.NI
keywords blockchainexecutiontransactionschedulingparallelBloomfilterconflictserializabilityEVMMerkleizationtransaction-levelparallelism
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

FAFO is a blockchain transaction scheduler that reorders transactions before a block is formed, rather than trying to parallelize an already-ordered block. The paper's claim is that this dissolves the data-contention bottleneck: on a 96-core machine, FAFO executes over 1.1 million native ETH transfers per second and over half a million ERC20 transfers per second, while still writing a Merkle-tree commitment to world state after every block. A reader should care because this suggests high-throughput EVM execution does not require sharding or giving up verifiability; the same machine also produces the state commitments that light clients and stateless validation need. The central architectural bet is that conflict-serializable schedules (concurrent executions equivalent to a serial order) can be constructed cheaply ahead of time from approximate read/write sets using compact, cache-friendly Bloom filters.

What carries the argument

The load-bearing mechanism is the four-stage FAFO pipeline. ParaLyze starts each transaction with an approximate read/write set (the storage slots it is predicted to read and write); ParaBloom and ParaFramer pack non-conflicting transactions into frames, representing each frame's aggregate read and write sets as two 2048-bit Bloom filters, with 64 frame-pairs fitting into 32 KiB, half of the L1 cache; and ParaScheduler reconstructs the frames and builds one happens-before DAG per storage slot, dispatching a transaction as soon as all its ancestors have completed. The admissibility condition doing the work is that a transaction can join a frame only when its predicted reads and writes intersect neither the frame's aggregate writes nor its aggregate reads in a conflicting way. The paper argues this produces a conflict-serializable schedule, costs only about 8 percent of the available transaction-level parallelism to Bloom-filter false positives, and is cheap enough that the scheduler alone handles over 2 million transactions per second when execution is skipped.

What would settle it

Rerun the same 500K-transaction-per-thread benchmark with full-size EVM addresses and storage keys, and record both throughput and the fraction of transactions ParaScheduler drops because actual read/write sets diverge from predicted ones; if native throughput falls materially below 1.1 million transactions per second, the compressed 6-byte input format was load-bearing.

Watch

Extended reading notes

Core claim

FAFO's central discovery is that the throughput ceiling of EVM execution is not the EVM itself but the way transactions are ordered: when a single producer reorders transactions into conflict-free frames before block formation, parallel execution becomes a scheduling problem rather than a speculation problem. The pipeline stages approximate read/write sets for each transaction, packs non-conflicting transactions into frames via 64 pairs of 2048-bit Bloom filters, and then reconstructs the frames as per-storage-slot DAGs so that each transaction runs only after every conflicting predecessor finishes. Transactions whose actual read/write set differs from the predicted one are dropped and rescheduled. On the paper's synthetic transfer workloads this pipeline exceeds 1.1 million native transactions per second and 565,956 ERC20 transactions per second on one node, and the same pipeline Merkleizes world state after every block.

Load-bearing premise

The headline numbers come from a synthetic benchmark in which each transfer is a compressed 24-byte record with 6-byte addresses; if real EVM's 20-byte addresses and 32-byte storage keys change cache behavior and Bloom filter occupancy enough, the measured throughput may not transfer to actual EVM workloads.

Editorial extensions

If this is right

  • One node can match the throughput of sharded deployments with 91 percent lower cost.
  • Merkleizing after every block is preserved at this throughput, so light-client and stateless-validation use cases are not sacrificed for speed.
  • Throughput scales near-linearly with additional CPU cores until the workload's transaction-level parallelism is exhausted, so capacity can be added with cores rather than nodes.
  • Because reordering happens before block formation, validators execute a pre-planned conflict-free stream instead of speculating, and the producer can change scheduling policy without requiring a validator-side hard fork.
  • Sharding and this scheduler are orthogonal and can be composed if a deployment needs additional throughput.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Frame packing depends on what is pending in the mempool at scheduling time, so FAFO's throughput should be read as an upper envelope for deep mempools; a shallow or low-arrival mempool would yield smaller frames and less parallelism, a regime the paper does not measure.
  • The roughly 8 percent transaction-level-parallelism loss from Bloom-filter false positives is a tunable trade-off; larger or hierarchical filters could trade some cache for more parallelism, and the paper's cache-fitting rule suggests how to set that knob on wider CPUs.
  • The optimistic drop-and-reschedule path means data-dependent contracts could be dropped repeatedly; a stress test with adversarial contracts whose read/write sets change under state would clarify whether the pipeline guarantees progress, not just average throughput.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents FAFO, a transaction scheduler for EVM execution that reorders transactions before block formation using approximate read/write sets. The system has four components: ParaLyze (static analysis), ParaBloom/ParaFramer (Bloom-filter-based frame packing), ParaScheduler (DAG-based parallel dispatch), and block formation with the QMDB verifiable database. The authors report over 1.1 million native ETH transfers per second and over 565,000 ERC20 transfers per second on a 96-core AWS Graviton3 instance, with an ablation showing the scheduler alone processes over 2 million transactions per second. They claim a 91% cost reduction relative to sharded execution and that FAFO scales linearly with CPU cores. The evaluation is based on synthetic transfer workloads with controlled skew and contention.

Significance. If the correctness argument and performance numbers hold, FAFO would be a significant result: it demonstrates that a single node can execute a high-throughput EVM chain while still producing a Merkleized state, which is important for verifiability and light clients. The paper is clearly written, names the design components precisely, ships an open-source implementation, and provides an ablation study isolating scheduler overhead. These are concrete strengths. However, the significance is contingent on two unresolved points: the correctness of the mismatch-drop path in ParaScheduler and the representativeness of the synthetic benchmark with compressed 6-byte addresses. Neither point is merely cosmetic; both directly affect the central claims of the paper.

major comments (4)
  1. [§2.5] The drop-after-execute mechanism for transactions whose actual read/write set diverges from the approximate set is not specified at the level needed to preserve conflict-serializability. The text states that after execution the actual set is compared and, on mismatch, T_i is 'dropped from the stream' and returned to the mempool, but it never states whether writes were applied to QMDB during execution or staged. If writes were applied, dropping the transaction from the output stream cannot undo them, and re-execution would double-apply them; if writes were staged, the paper must specify how staged writes are discarded and how concurrent transactions that read them are invalidated. Section 2.3 explicitly admits that approximate sets can be inaccurate for data-dependent flows, so this path is not hypothetical. The paper should report the measured mismatch rate and describe the rollback or staging protocol; as written, the claimed guarantee in Section 2.5 is unsupported.
  2. [§3.2] The headline TPS numbers in Table 1 are obtained from a synthetic workload in which each transfer is a 24-byte record with 6-byte addresses, whereas real EVM accounts use 20-byte addresses and storage keys are 32 bytes. The paper does not explain how these 6-byte addresses map to the storage slots used by ParaLyze and QMDB, nor does it measure how Bloom filter occupancy, hashing cost, and cache locality change with realistic key sizes. Because ParaBloom is the component that enables the scheduler's throughput, this modeling choice could materially affect the result. The paper should include a benchmark with 20-byte addresses (and 32-byte storage keys) and report the resulting TPS, at least for the native-transfer workload. In addition, no repeated-run variance or same-hardware comparison against Block-STM or ParallelEVM is provided, so the relative performance claims in Section 4 are not directly evidenced.
  3. [§3.3] The claim that FAFO 'Merkleizes every block' is not supported by any measurement in the evaluation. Section 2.2 assumes without loss of generality that the verifiable database is not a bottleneck, and the benchmarks report transfer throughput but do not measure the time to compute the Merkle root, flush storage, or form a block. Since the title and abstract make Merkleization a central differentiator, the paper should report per-block Merkleization cost in the same end-to-end run, or explicitly state that Table 1 excludes this cost.
  4. [§2.5] The proof that the DAG schedule is conflict-serializable is incomplete. The text argues per-storage-slot schedules S_a are conflict-serializable and that waiting for all schedules S_a to permit T_i yields a conflict-serializable schedule across all slots, but no invariant connects the per-slot serial orders to a single global serial transaction order. Also, the proof assumes an unbounded number of cores and never relaxes that assumption to the finite-core case used in the experiments. A precise inductive argument, or a counterexample-based discussion, is needed to substantiate the correctness claim.
minor comments (6)
  1. [§2.4] In Algorithm 1, lines 18 and 19 use the subscripts cARTj and cAWTj, which appear to refer to the frame-level aggregate sets for the new frame; the notation is inconsistent with the frame index F_i used elsewhere and should be corrected.
  2. [§3.3] Figures 3 and 4 contain no error bars and the text does not state the number of repeated runs; the reader cannot assess run-to-run variance or the statistical significance of the reported scaling behavior.
  3. [§3.2] The benchmark description says 512 threads issue 500K batched transfers each, but the test instance has 96 vCPUs; please clarify whether these are hardware threads, processes, or oversubscribed threads and how they are mapped to cores.
  4. [§1] The introduction calls FAFO the 'first blockchain transaction scheduler' to reorder before block formation, but Section 4 itself cites proposer-side scheduling and reordering work; the novelty claim should be qualified to match the related-work discussion.
  5. [§3.3] The cost comparison reports a 91% lower monthly cost ($6,013 vs $65,361) without specifying instance types, usage assumptions, or pricing snapshot details; a reproducible cost breakdown is needed.
  6. [§3.2] The parameterization notation 'Native α=0' and 'ERC20 α=A, γ=Y' is used in the figures but not formally defined in the text; a concise definition or table would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the throughput headline is an empirical measurement, and the scheduler design does not reduce to its inputs.

full rationale

FAFO's central claim is an end-to-end throughput measurement on a defined synthetic workload (Section 3.2, Table 1), not a quantity derived from the model's own parameters. The conflict-detection and scheduling components (ParaBloom, ParaFramer, ParaScheduler) are described with algorithmic definitions and evaluated by measured TPS/TLP; no fitted parameter is renamed as a prediction. The ParaLyze approximation is explicitly stated to be approximate (§2.3), and the scheduler handles divergence by dropping transactions (§2.5); whether that mechanism is correct is a soundness question, not a circularity one. Citations to the authors' QMDB [23] and vApps [22] papers supply components and applications context, but the scheduler's concurrency argument and the benchmark numbers do not depend on those citations for their derivation. The cost comparison uses independent cloud pricing. No equation is shown to be equivalent to its own input, and no uniqueness theorem or prior result is invoked to force the design choice. The main limitations (synthetic 6-byte address workload, sparse ERC20 ParaLyze coverage, unspecified rollback on dropped transactions) are empirical and engineering gaps rather than definitional circularity.

Assumptions & free parameters 2 free parameters · 6 assumptions · 4 invented entities

The central TPS claim relies on design choices (ParaBloom layout) tuned to L1 cache, an unmeasured accuracy assumption for static RW-set prediction, a protocol-level assumption about block producer timescales, and a benchmark representation that compresses EVM addresses. These are not fitted to data in the statistical sense, but they are hand-chosen configurations and domain assumptions that the result depends on.

free parameters (2)
  • ParaBloom frame count = 64 frames
    Number of active frames chosen to fit into 32 KiB, half of the L1 cache; affects conflict detection overhead and false positive rate.
  • Bloom filter size = 2048 bits
    Filter width per frame; the paper states larger filters reduce false positives but increase cache pressure; 2048 is a manual hardware-specific choice.
assumptions (6)
  • domain assumption Approximate read/write sets from ParaLyze are accurate enough that dropped transactions are rare; otherwise throughput collapses due to rescheduling.
    Section 2.3 and 2.5: ParaLyze simulates without persisting writes, so state divergence is possible; the paper states 'we expect this to be rare in practice' with no measurement.
  • domain assumption Conflict-serializability is a sufficient correctness condition for blockchain EVM execution semantics.
    Section 2.1 relies on Eswaran et al. [8] but does not prove EVM's state transition function only needs conflict-serializable storage schedules.
  • ad hoc to paper The underlying verifiable database (QMDB) is not a bottleneck.
    Section 2.2: 'Without loss of generality, we assume that the underlying verifiable database is not a bottleneck of the system.' Assumed, not measured in the benchmark.
  • domain assumption Block producer election occurs on a long timescale so a large pool of transactions is available.
    Section 2.2: protocol-level assumption true for EOS/Solana-style chains but not Ethereum's 12s slots.
  • domain assumption The 6-byte address representation in the benchmark preserves real EVM performance behavior.
    Section 3.2: transactions are 24-byte records with 6-byte addresses; real EVM uses 20-byte addresses and 32-byte storage keys.
  • domain assumption ERC20 workloads can rely on EIP-2930 access lists or similar metadata for accurate RW sets.
    Section 3.2: 'We only run ParaLyze on a subset of the ERC20 transfers, to simulate the behavior of the system if EIP-2930 is implemented.'
invented entities (4)
  • ParaBloom independent evidence
    purpose: Cache-friendly Bloom filter structure that tracks aggregate read/write sets per frame for fast conflict checks.
    Open-sourced in the FAFO repository; can be executed and measured independently of the paper's claims.
  • ParaFramer independent evidence
    purpose: Greedy algorithm that packs non-conflicting transactions into frames using ParaBloom.
    Implemented in the FAFO codebase; frame packing is directly observable via the scheduling stream.
  • ParaScheduler independent evidence
    purpose: DAG-based dispatcher that executes transactions as soon as their conflict ancestors finish.
    Implemented in the FAFO codebase; its output schedule can be compared against serial execution.
  • ParaLyze independent evidence
    purpose: Static transaction analyzer that approximates each transaction's read/write sets before execution.
    Implemented in the FAFO codebase; its predictions can be checked against actual read/write sets.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FAFO: Over 1 million TPS on a single node running EVM while still Merkleizing every block." pith.science (2026). https://pith.science/paper/RM7UWZ43

@misc{pith2026250710757,
  author       = {Pith},
  title        = {Pith review of: FAFO: Over 1 million TPS on a single node running EVM while still Merkleizing every block},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RM7UWZ43}},
  note         = {Machine review of arXiv:2507.10757}
}
read the original abstract

Current blockchain execution throughput is limited by data contention, reducing execution layer parallelism. Fast Ahead-of-Formation Optimization (FAFO) is the first blockchain transaction scheduler to address this problem by reordering transactions before block formation for maximum concurrency. FAFO uses CPU-optimized cache-friendly Bloom filters to efficiently detect conflicts and schedule parallel transaction execution at high throughput and low overhead. We integrate the Rust EVM client (REVM) into FAFO and achieve over 1.1 million native ETH transfers per second and over half a million ERC20 transfers per second on a single node (Table 1), with 91% lower cost compared to state-of-the-art sharded execution. Unlike many other existing high throughput blockchain execution clients, FAFO uses QMDB to Merkleize world state after every block, enabling light clients and stateless validation for ZK-based vApps. FAFO scales with minimal synchronization overhead, scaling linearly with additional CPU resources until it fully exploits the maximum parallelism of the underlying transaction flow. FAFO proves that the high throughput necessary to support future decentralized applications can be achieved with a streamlined execution layer and innovations in blockchain transaction scheduler design. FAFO is open-sourced at https://github.com/LayerZero-Labs/fafo.

Figures

Figures reproduced from arXiv: 2507.10757 by the authors.

Figure 1
Figure 1. System Architecture. Concurrent instances of ParaLyze preprocesses transactions, ParaFramer packs frames using ParaBloom, and ParaScheduler produces the final transaction execution ordering and defines block boundaries. The optimal schedule can be constructed via an op￾timal coloring of a precedence graph across all transac￾tions, and real-world performance is maximized if the size of each color class is roughly equ… view at source ↗
Figure 2
Figure 2. ParaBloom Layout. Each active frame stores two 2048-bit Bloom filters (read and write). 2.4 ParaFramer & ParaBloom: Conflict de￾tection and frame packing ParaBloom identifies and groups non-conflicting trans￾actions into frames, and ParaFramer forms the transac￾tion stream from these frames. This transaction stream is parallelism-aware, with average TLP greater than or equal to the average number of transactions per… view at source ↗
Figure 3
Figure 3. FAFO scales linearly. FAFO extracts about 130 TLP from nativeα=0, theoretically allowing it to scale up to 130 CPU cores. FAFO efficiently uses each additional CPU core, up to the maximum available (96). • α (Contention Ratio): The probability of transfer￾ring to a hot address. We represent the specific benchmark parameterization of workload (e.g., ERC20), skew Y, and contention ratio A as ERC20α=A,γ=Y (if α = 0, we… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: We run FAFO under varying combinations of [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 22 canonical work pages

  1. [1]

    Amazon ec2 on-demand pricing

    AMAZONWEBSERVICES. Amazon ec2 on-demand pricing. Ac- cessed: 2025-06-23

    work page 2025

  2. [2]

    S., KUMARI, S., PERI, S., RATHOR, S.,ANDSO- MANI, A

    ANJANA, P. S., KUMARI, S., PERI, S., RATHOR, S.,ANDSO- MANI, A. Optsmart: a space efficient opt imistic concurrent exe- cution of smart contracts.Distributed and Parallel Databases 42, 2 (2024), 245–297

    work page 2024

  3. [3]

    EOS.IO Technical White Paper v2, March 2018

    BLOCK.ONE. EOS.IO Technical White Paper v2, March 2018. Accessed: 2025-02-27

    work page 2018

  4. [4]

    Eip-2930: Op- tional access lists, 2020

    BUTERIN, VITALIK ANDMARTINSWENDE. Eip-2930: Op- tional access lists, 2020. Ethereum Improvement Proposal

    work page 2020

  5. [5]

    CELLARY, W., MORZY, T.,ANDGELENBE, E.Concurrency control in distributed database systems, vol. 3. Elsevier, 2014

    work page 2014

  6. [6]

    Forerunner: Constraint-based specula- tive transaction execution for ethereum

    CHEN, Y., GUO, Z., LI, R., CHEN, S., ZHOU, L., ZHOU, Y.,ANDZHANG, X. Forerunner: Constraint-based specula- tive transaction execution for ethereum. InProceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (2021), pp. 570–587

    work page 2021

  7. [7]

    Adding concurrency to smart contracts

    DICKERSON, T., GAZZILLO, P., HERLIHY, M.,ANDKOSKI- NEN, E. Adding concurrency to smart contracts. InProceedings of the ACM Symposium on Principles of Distributed Computing (2017), pp. 303–312

    work page 2017

  8. [8]

    P., GRAY, J

    ESWARAN, K. P., GRAY, J. N., LORIE, R. A.,ANDTRAIGER, I. L. The notions of consistency and predicate locks in a database system.Commun. ACM 19, 11 (Nov. 1976), 624–633. 7

    work page 1976

Show all 23 references
  1. [9]

    Block-STM: Scaling blockchain execution by turning ordering curse to a per- formance blessing

    GELASHVILI, R., SPIEGELMAN, A., XIANG, Z., DANEZIS, G., LI, Z., MALKHI, D., XIA, Y.,ANDZHOU, R. Block-STM: Scaling blockchain execution by turning ordering curse to a per- formance blessing. InProceedings of the 28th ACM SIGPLAN Annual Symposium on Principles and Practice of P...

    2023

  2. [10]

    Compute engine pricing

    GOOGLECLOUD. Compute engine pricing. Accessed: 2025-06- 23

    2025

  3. [11]

    Shardines: Aptos’ sharded execution engine blazes to 1m tps, 2025

    LABS, A. Shardines: Aptos’ sharded execution engine blazes to 1m tps, 2025. Archived on 2025-02-11

    2025

  4. [12]

    Paral- lelevm: Operation-level concurrent transaction execution for evm-compatible blockchains

    LIN, H., FENG, H., ZHOU, Y.,ANDWU, L. Paral- lelevm: Operation-level concurrent transaction execution for evm-compatible blockchains. InProceedings of the Twentieth European Conference on Computer Systems(2025), pp. 211–225

    2025

  5. [13]

    Smart contract parallel execution with fine-grained state accesses

    QI, X., JIAO, J.,ANDLI, Y. Smart contract parallel execution with fine-grained state accesses. In2023 IEEE 43rd International Conference on Distributed Computing Systems (ICDCS)(2023), IEEE, pp. 841–852

    2023

  6. [14]

    RUAN, P., LOGHIN, D., TA, Q.-T., ZHANG, M., CHEN, G., ANDOOI, B. C. A transactional perspective on execute-order- validate blockchains. InProceedings of the 2020 ACM SIG- MOD International Conference on Management of Data(2020), pp. 543–557

    2020

  7. [15]

    Toward high-performance blockchain system by blurring the line between ordering and execution

    RYU, D.,ANDPARK, C. Toward high-performance blockchain system by blurring the line between ordering and execution. In SC24: International Conference for High Performance Comput- ing, Networking, Storage and Analysis(2024), IEEE, pp. 1–16

    2024

  8. [16]

    Parallel transaction execution in public blockchain systems

    SHAHID, R. Parallel transaction execution in public blockchain systems. Master’s thesis, University of Waterloo, 2024

    2024

  9. [17]

    M., AGRAWAL, D.,AND DITTRICH, J

    SHARMA, A., SCHUHKNECHT, F. M., AGRAWAL, D.,AND DITTRICH, J. Blurring the lines between blockchains and database systems: the case of hyperledger fabric. InProceedings of the 2019 International Conference on Management of Data (2019), pp. 105–122

    2019

  10. [18]

    Ht- fabric: A fast re-ordering and parallel re-execution method for a high-throughput blockchain

    SONG, J., JEONG, J., LEE, J., NA, I.,ANDKIM, M.-S. Ht- fabric: A fast re-ordering and parallel re-execution method for a high-throughput blockchain. InProceedings of the 33rd ACM International Conference on Information and Knowledge Man- agement(2024), pp. 2118–2127

    2024

  11. [19]

    The sui smart contracts platform

    THEMYSTENLABSTEAM. The sui smart contracts platform

  12. [20]

    Ethereum: A secure decentralized generalized trans- action ledger

    WOOD, G. Ethereum: A secure decentralized generalized trans- action ledger. InEthereum Yellow Paper(2014)

    2014

  13. [21]

    Solana: A new architecture for a high perfor- mance blockchain v0

    YAKOVENKO, A. Solana: A new architecture for a high perfor- mance blockchain v0. 8.13, 2018

    2018

  14. [22]

    vapps: Verifiable applications at internet scale.arXiv preprint arXiv:2504.14809(2025)

    ZHANG, I., ZARICK, R., PELLEGRINO, B., LI, T., WONG, D., KIM, T., ROY, U., GUIBAS, J.,ANDKULKARNI, K. vapps: Verifiable applications at internet scale.arXiv preprint arXiv:2504.14809(2025)

    2025 arXiv

  15. [23]

    Qmdb: Quick merkle database

    ZHANG, I., ZARICK, R., WONG, D., KIM, T., PELLEGRINO, B., LI, M.,ANDWONG, K. Qmdb: Quick merkle database. arXiv preprint arXiv:2501.05262(2025). 8

    2025 arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.