{"id":"85c29047-ecdf-4073-93a2-ee7853a04b7e","arxiv_id":"2507.10757","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"FAFO, an ahead-of-formation transaction scheduler with Bloom-filter conflict detection, reports 1.1M native transfer TPS on a single node with per-block Merkleization.","lead":"A blockchain execution layer from LayerZero Labs reorders transactions before blocks are formed, using cache-friendly Bloom filters to find parallel transactions, and reports over 1.1 million simple ETH transfers per second on one 96-core server while still computing Merkle proofs each block. The result is a claim that high EVM throughput may not require sharding, but the evidence currently rests on a narrow synthetic benchmark.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Correctness gap: dropping mismatched transactions after execution without described rollback cannot preserve conflict-serializability.","rationale":"The reader's concern about 6-byte addresses is a benchmark-fidelity issue: even if real 20-byte addresses slow the system down, the method could still be correct. The gap I identify is a correctness issue: if mismatched transactions are dropped after execution without rollback, the schedule is not guaranteed to be conflict-serializable, and no amount of re-running with realistic addresses fixes that. The paper itself flags the trigger condition in §2.3 and then specifies the handling in §2.5, so both parts are in-scope and the absent rollback is a missing support rather than an external standard. I am not claiming the implementation is fraudulent; the code may contain an undocumented rollback mechanism. But as written, the paper does not demonstrate that the divergence path preserves correctness, and the central claim depends on it. Therefore the verdict should move from CONDITIONAL to UNVERDICTED until the proposed test and code inspection resolve the gap. If the test shows correct rollback, the reader's conditional verdict remains appropriate, but the additional address-size benchmark would still be needed for the throughput claim.","tokens_in":8879,"tokens_out":8082,"duration_ms":99089,"concrete_test":"Check out the pinned FAFO commit and inspect the ParaScheduler code path for the case RWTi != dRWTi. The deciding test: (1) build a two-transaction workload where T2's actual write set contains a slot S not in its approximate set and T1 writes S concurrently; (2) run FAFO and compare the final QMDB state against the serial order T1 then T2 after T2 is dropped; (3) if T2's write appears in the final state, or T2 is re-executed on top of its own write, the scheduler is not conflict-serializable. Also report whether the repo contains any rollback, abort, or snapshot code path reached by this branch. This single test distinguishes a documentation gap from a correctness failure.","verdict_should_be":"UNVERDICTED","load_bearing_attack":"The central correctness argument in §2.5 requires that a transaction whose actual read/write set differs from its approximate set be removed so the executed schedule remains conflict-serializable. The paper says this happens after execution: the actual read/write set is recorded and compared, and if it differs, the transaction is dropped from the stream and returned to the mempool for rescheduling. No rollback, write-set staging, or snapshot/abort mechanism is described anywhere. This matters because §2.3 admits that approximate read/write sets may sometimes be inaccurately captured for data-dependent flows or workloads that heavily modify global state, so the mismatch path is not hypothetical. If the transaction's writes were already applied to QMDB during execution, dropping it from the output stream cannot undo them, and re-executing it later double-applies them. If the writes were only staged, the paper must specify how staged writes are discarded and how transactions that read them are invalidated. As written, the drop-after-execute step is inconsistent with the claimed guarantee, and the 1M TPS result does not establish correct high-throughput EVM execution.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":9077,"tokens_out":5447,"duration_ms":59814,"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":[{"comment":"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.","section":"§2.5"},{"comment":"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.","section":"§3.2"},{"comment":"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.","section":"§3.3"},{"comment":"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.","section":"§2.5"}],"minor_comments":[{"comment":"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.","section":"§2.4"},{"comment":"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.","section":"§3.3"},{"comment":"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.","section":"§3.2"},{"comment":"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.","section":"§1"},{"comment":"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.","section":"§3.3"},{"comment":"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.","section":"§3.2"}],"recommendation":"major_revision","confidential_remarks":"The paper's central performance claim is striking, but the two load-bearing issues in the authors' response will determine whether the result survives: the correctness of the mismatch-drop path in ParaScheduler and the representativeness of the 6-byte-address benchmark. The open-source release is a positive signal, and the design narrative is coherent, but I would want to see the correctness protocol made fully precise and at least one realistic-address benchmark before recommending acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a legitimate engineering contribution with a genuinely different scheduling placement, but the paper as written does not establish the headline claim. The drop-after-execute rule in §2.5 hides a correctness gap, and the benchmark compresses away the EVM's real address size.\n\nWhat's new: FAFO reorders transactions before block formation, which is a real departure from replica-side schedulers like OptME and DMVCC. The ParaBloom design—64 pairs of 2048-bit Bloom filters that fit in L1 cache—is a smart, concrete way to do conflict checks cheaply. The open-sourced code and the linear scaling plot in Figure 3 give me confidence the system works on its own benchmarks. The 91% cost comparison is rough but directionally reasonable.\n\nWhere it gets soft. The correctness argument for dropping mismatched transactions is not just under-specified; as written it cannot preserve conflict-serializability. §2.5 says a transaction whose actual R/W set differs from its approximate set is 'dropped from the stream' after execution and returned to the mempool. If its writes were already applied to QMDB, dropping it from the output doesn't undo them, and re-executing later double-applies them. If writes are staged, the paper must say how staged writes are discarded and how dependent reads are invalidated. Without that, the guarantee doesn't hold. This is load-bearing, not a footnote.\n\nThe benchmark evidence is also thinner than the abstract implies. The 24-byte transaction records with 6-byte addresses are a serious stand-in for EVM state access. Real EVM uses 20-byte addresses and 32-byte storage keys, which changes Bloom filter occupancy and cache behavior. There's no repeated-run variance, no same-hardware baseline against Block-STM or ParallelEVM, and no reported drop rate for mispredicted R/W sets. These are addressable, but they make the headline number an upper bound on a synthetic workload.\n\nWho this is for. Systems folks working on parallel EVM execution will want to read it, and the ahead-of-formation idea is worth taking seriously. But I would not cite the throughput claim yet, and the correctness gap needs to be fixed or explicitly designed around before the paper can be trusted.\n\nRecommendation: send to peer review—it's a real systems idea and the issues are fixable—but the referee should demand a rollback/staging mechanism and a benchmark with realistic address sizes before acceptance.","headline":"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.","tokens_in":9627,"tokens_out":3127,"would_cite":false,"duration_ms":34837,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["blockchain execution","transaction scheduling","parallel execution","Bloom filter","conflict serializability","EVM","Merkleization","transaction-level parallelism"],"falsifier":"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.","tokens_in":8669,"feed_emoji":"⚡","tokens_out":13298,"duration_ms":139299,"temperature":0.7,"pith_summary":"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.","feed_headline":"Transaction scheduler hits 1.1 million EVM TPS on one node","feed_subtitle":"Reordering transactions before block formation avoids the conflict bottleneck while still committing every block to a Merkle tree.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines conflict-serializability, the correctness condition FAFO's schedule must satisfy when it runs transactions concurrently.","marker":"[8]"},{"why":"Supplies the verifiable database that Merkleizes world state after every block, supporting the claim that high throughput need not sacrifice state commitments.","marker":"[23]"},{"why":"Defines the EVM and its transaction semantics, the execution model whose throughput FAFO benchmarks.","marker":"[20]"},{"why":"Provides the sharded execution baseline and cost figures used in the paper's 91-percent-cheaper comparison.","marker":"[11]"},{"why":"Documents the abort overhead and modest speedups of optimistic parallel EVM execution that FAFO's pre-block reordering is designed to avoid.","marker":"[12]"}],"fun_headline_variants":["FAFO: 1.1M EVM TPS on one node, Merkleized","Reordering transactions unlocks 1.1M EVM TPS on a single node","High-throughput EVM: 1.1M TPS with Merkleization intact","Before-block reordering achieves 1.1M TPS on one node","FAFO scheduler: >1M TPS per node while Merkleizing blocks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["FAFO: 1.1M EVM TPS on one node, Merkleized","Reordering transactions unlocks 1.1M EVM TPS on a single node","High-throughput EVM: 1.1M TPS with Merkleization intact","Before-block reordering achieves 1.1M TPS on one node","FAFO scheduler: >1M TPS per node while Merkleizing blocks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000526,"raw_usage":{"total_tokens":2547,"prompt_tokens":961,"completion_tokens":1586,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":577,"completion_tokens_details":{"reasoning_tokens":1476}},"tokens_in":577,"tokens_out":1586,"duration_ms":11946,"temperature":1.0,"reasoning_tokens":1476,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:26:19.002948+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"P., GRAY, J","cited_arxiv_id":null,"evidence_quote":"Defines conflict-serializability, the correctness condition FAFO's schedule must satisfy when it runs transactions concurrently."},{"cited_title":"Ethereum: A secure decentralized generalized trans- action ledger","cited_arxiv_id":null,"evidence_quote":"Defines the EVM and its transaction semantics, the execution model whose throughput FAFO benchmarks."},{"cited_title":"Shardines: Aptos’ sharded execution engine blazes to 1m tps, 2025","cited_arxiv_id":null,"evidence_quote":"Provides the sharded execution baseline and cost figures used in the paper's 91-percent-cheaper comparison."},{"cited_title":"Paral- lelevm: Operation-level concurrent transaction execution for evm-compatible blockchains","cited_arxiv_id":null,"evidence_quote":"Documents the abort overhead and modest speedups of optimistic parallel EVM execution that FAFO's pre-block reordering is designed to avoid."}],"review_version":1}