{"id":"0d89e308-06f6-492d-b32c-2bcb1a732e28","arxiv_id":"2501.18780","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"HashEmAll implements Griffin, Rescue-Prime, and Reinforced Concrete on FPGAs over the BN254 field, reporting up to 23x throughput speedups versus a CPU baseline.","lead":"This paper presents HashEmAll, FPGA circuits that run three zero-knowledge-friendly hash functions much faster than they run on a CPU, with the fastest design claiming a 23x speedup. A smart generalist might read it to see whether consumer FPGAs can make zero-knowledge proof applications, like Merkle tree commitments, practical.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Claimed 10–23x speedups rely on a single-thread CPU baseline plus ideal zero-I/O FPGA throughput; against a 64-core CPU or with PCIe transfer included, the headline advantage may not hold.","rationale":"The reader’s weakest assumption roughly matches: the CPU baseline is under-specified and I/O is ignored. I agree with that assessment and would not move the verdict. The work has a credible modular RTL library and internally consistent synthesis numbers; the issue is the fairness and scope of the comparison. The proposed check is decisive because, if a multi-thread CPU reaches or exceeds the FPGA, the abstract’s “outperform CPU implementations by at least 10×” is false for exactly the parallel Merkle-tree workload the paper motivates. Even if the check passes, the Griffin_L 9.94× result versus the “at least 10×” abstract claim should be corrected. I do not see a deeper flaw in the arithmetic modules or sponge construction from the text alone; the concern is an evaluation-protocol concern, not an internal inconsistency in the hardware design.","tokens_in":13498,"tokens_out":9527,"duration_ms":104364,"concrete_test":"Run the same ZKFriendlyHashZoo Rust implementations of Rescue-Prime, Griffin, and Reinforced Concrete over BN254 on the same AMD Ryzen 3990X using all 64 hardware threads (e.g., Rayon par_iter over 10^6 independent hashes), and report aggregate hashes/s with the same input sizes as Table II. If the 64-thread CPU throughput reaches or exceeds the FPGA’s ideal saturated-pipeline throughput for any of the three hashes, then the claimed 10–23× speedup is an artifact of comparing against a single-thread CPU on an embarrassingly parallel workload.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The load-bearing assumption behind the headline is not the FPGA arithmetic; it is the comparison protocol. Table II reports CPU throughputs from the ZKFriendlyHashZoo replicated on an AMD 3990X, but the paper never states whether this is one thread, how the Rust code was compiled, or whether CPU time includes input/output. Section VI.B explicitly computes FPGA throughput from synthesis at ~100 MHz with a saturated pipeline and “ignore the overhead of I/O traffic in and out of the FPGA board.” For the paper’s own motivating workload, Merkle-tree hashing is embarrassingly parallel (Section II.C), so the relevant CPU baseline is all 64 cores of the 3990X, not one. A conservative estimate from the paper’s own single-thread numbers (Rescue-Prime 2.4, Griffin 8.7, RC 294 kops/s) gives 64-core ceilings of roughly 154, 557, and 18,800 kops/s; RC_L’s 6,896 kops/s is the only FPGA number in that range, and the CPU would beat it. The abstract’s “at least 10×” is also internally contradicted by Griffin_L’s 9.94× in Table II. If a multi-threaded CPU or a real PCIe streaming loop closes the gap, the central claim is an artifact of an ideal pipeline and a single-core baseline.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents HashEmAll, a collection of FPGA implementations of three ZK-friendly hash functions (Rescue-Prime, Griffin, and Reinforced Concrete) over the BN254 prime field. For each hash, the authors provide an area-optimized and a latency-optimized variant, built from reusable modules for modular multiplication, power mapping, and fast division. The implementations are synthesized on a Virtex UltraScale+ device and evaluated for resource utilization, frequency, latency, throughput, and power. The central claim is that the latency-optimized designs outperform CPU implementations from the ZKFriendlyHashZoo by at least 10x, with Reinforced Concrete achieving 23.44x, and that the Reinforced Concrete design reaches latencies comparable to SHA-3.","tokens_in":13760,"tokens_out":4288,"duration_ms":47758,"significance":"If the performance claims hold, this is an useful step toward practical hardware acceleration of ZK-friendly hashing: it is, to the authors' knowledge, the first FPGA realization of Griffin, Rescue-Prime, and Reinforced Concrete, and it provides an open-source, modular library that can be reused for other hashes and field sizes. The modular design, explicit area-versus-latency trade-offs, and public repository are strengths, as is the reporting of synthesis results, resource usage, and power. The main significance issue is that the headline speedups depend on comparison choices that are not fully disclosed or are internally inconsistent; the underlying FPGA arithmetic is not the main risk, but the empirical comparison protocol must be sharpened before the 'at least 10x' and 'practical' claims can be accepted as stated.","major_comments":[{"comment":"The abstract states that latency-optimized HashEmAll designs 'outperform CPU implementations by at least 10x' and Section VII repeats 'speedup of at least an order of magnitude.' This is directly contradicted by Table II, which reports Griffin_L at 9.94x, and by Section VI.B, which says the smallest speedup is Griffin_L. The headline should be corrected to an accurate range, such as 'from 9.9x to 23.4x' or 'up to 23x,' unless the CPU baseline is changed so that all designs cross the 10x threshold.","section":"Abstract and Section VII"},{"comment":"The CPU baseline is under-specified. The paper says the CPU numbers are replicated on an AMD Ryzen 3990X using the ZKFriendlyHashZoo repository [39], but it does not state whether the measurements are single-threaded or multi-threaded, which compiler and optimization flags were used, or whether CPU throughput/latency includes input/output overhead. Since Section II.C motivates Merkle-tree hashing as an embarrassingly parallel workload, a single-threaded CPU baseline is not the natural comparison for that use case, and a 64-thread baseline would materially reduce the reported speedups. The authors should disclose the threading model and, if single-threaded, either add a multi-threaded comparison or explicitly scope all speedup claims to single-threaded CPU implementations.","section":"Section VI.A and Table II"},{"comment":"The evaluation explicitly assumes a fully saturated pipeline and ignores I/O traffic in and out of the FPGA board. This is a reasonable ideal-throughput metric, but it is not sufficient to support the abstract's broader 'practical' and 'real-world' claims, since real systems must transfer hash inputs and outputs over PCIe or another interface. Please quantify the I/O impact at representative transfer sizes, or restate the headline claims as on-FPGA saturated-pipeline throughput rather than end-to-end system performance.","section":"Section VI.B"},{"comment":"The SHA-3 comparison is not apples-to-apples and should be removed or reframed. The paper says RC_L 'has a comparable run time with SHA-3,' citing a reported SHA-3 latency of 419.2 ns from [16], but that is a CPU latency, while RC_L's 0.145 us amortized latency is an FPGA permutation latency computed with zero I/O overhead and fully saturated pipelines. The input widths and computation environments also differ. The related introductory claim that HashEmAll achieves runtime 'in the same order of magnitude' as SHA-3 is consequently unsupported by the data presented.","section":"Section VI.B"}],"minor_comments":[{"comment":"The RCL row has formatting errors: the LUT utilization entry is missing a closing parenthesis and the FF entry is missing a percent sign; these should be corrected as '316,049 (18.28%)' and '169,043 (4.89%)'.","section":"Table I"},{"comment":"The sentence 'This results also out This' is incomplete and should be rewritten; it appears to be a leftover fragment from an earlier draft.","section":"Section VI.B"},{"comment":"In the definition of Griffin's permutation, the input is written as x = (x0, ..., xm), which suggests m+1 elements, but the text says the state size is m. The notation should be x = (x0, ..., x_{m-1}) for clarity.","section":"Section III.C"},{"comment":"The notation 'Result = (x x D/s_i) >> 508' is missing the multiplication symbol; it should read 'Result = (x * (D/s_i)) >> 508' to avoid confusion with the modular multiplication operator.","section":"Section V.A"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the scope of the journal and the core FPGA design work appears solid, but the empirical comparison and headline claims need revision. The internal 'at least 10x' vs. 9.94x inconsistency is an easy fix, but the underspecified CPU baseline and the ideal-pipeline assumptions are load-bearing for the main contribution. I do not see evidence of intentional misrepresentation, but the current presentation overstates the strength of the comparison. The open-source repository and modular architecture are genuine strengths; I would be willing to review a revised version."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper delivers what it says on the tin: the first FPGA implementations of Griffin, Rescue-Prime, and Reinforced Concrete, plus sensible area- and latency-optimized variants. The modular design, especially the reconfigurable multiplier and LUT-based division for Reinforced Concrete, is genuinely useful engineering, and the synthesis results are self-consistent and reproducible in principle (the repo is cited). I'd trust the internal throughput and resource numbers as measured on the Virtex UltraScale+.\n\nThe soft spots are all in the comparison protocol, not the arithmetic. The abstract claims \"at least 10×,\" but Table II shows Griffin_L at 9.94×—a minor inconsistency, but it makes the claim literally false. More importantly, the CPU baseline is not specified: the paper says it replicated the ZKFriendlyHashZoo benchmarks on a Ryzen 3990X, but does not say how many threads, which compiler flags, or whether the measured time includes input/output. The paper also explicitly ignores PCIe I/O and assumes a saturated pipeline when computing FPGA throughput. That's fine for a niche comparison, but it makes the \"at least 10×\" a statement about a very specific setup, not a general result. The stress-test's point about multi-core CPUs is fair: for Merkle-tree hashing, which the paper itself flags as embarrassingly parallel, a 64-core CPU could close or reverse the gap on throughput. The paper should at least disclose that the baseline is single-threaded, or better, compare against a multi-threaded software implementation for the throughput claims. The SHA-3 comparison is also misleading: a CPU latency of 419 ns is compared against FPGA amortized throughput, which mixes metrics.\n\nThe claim about being the first to approach SHA-3 speed in ZK-friendly hashing is overbroad, since Monolith already does that in software; the paper cites Monolith but doesn't benchmark against it. That's a citable omission.\n\nNone of this invalidates the core hardware contribution. The designs are real, the speedups over a single-thread CPU are plausible, and the modular approach is clearly explained. The right fix is a revised comparison section with a fully specified baseline and honest scope.\n\nA serious referee should see this; it's a useful reference for anyone building ZK hardware accelerators. I'd want the comparison protocol tightened before publication.","headline":"HashEmAll is a credible FPGA engineering effort with first hardware implementations of three ZK-friendly hashes, but the headline speedups rest on an under-specified, likely single-threaded CPU baseline and ideal zero-I/O pipeline assumptions.","tokens_in":14348,"tokens_out":1499,"would_cite":true,"duration_ms":19875,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Latency-optimized FPGA designs make zero-knowledge-friendly hashing 10-23x faster than CPU implementations.","keywords":["zero-knowledge proofs","ZK-friendly hash functions","FPGA acceleration","Griffin hash","Rescue-Prime","Reinforced Concrete","BN254 field","modular arithmetic hardware"],"falsifier":"Run the same three hashes on the same FPGA and CPU in an end-to-end Merkle tree construction, streaming real data blocks on and off the board, and compare total time per tree; if the aggregate speedup falls below one order of magnitude, the fully saturated-pipeline assumption does not hold for practical workloads.","tokens_in":13281,"feed_emoji":"⚡","tokens_out":10621,"duration_ms":98345,"temperature":0.7,"pith_summary":"Zero-knowledge-friendly hash functions such as Griffin, Rescue-Prime, and Reinforced Concrete are cheap inside arithmetic circuits but slow on ordinary CPUs because they rely on wide finite-field arithmetic. The paper argues that FPGAs can close this gap: it introduces HashEmAll, a modular library of pipelined arithmetic blocks over the BN254 prime field that implements all three hashes in both area-optimized and latency-optimized variants. The latency-optimized designs are reported to achieve at least 10x higher throughput than a Rust CPU implementation, with the Reinforced Concrete design reaching 23x and latency comparable to SHA-3. If these numbers hold, hardware hashing becomes practical for ZKP workloads such as Merkle tree commitments and recursive proofs, and the same modules could be reused for other hashes and field sizes.","feed_headline":"FPGA hash cores run 10-23x faster than CPU for ZK-friendly hashes","feed_subtitle":"Latency-optimized Reinforced Concrete matches SHA-3 speed, unblocking Merkle-tree and recursive-proof workloads on FPGAs.","key_machinery":"The mechanism is a set of modular arithmetic units for the BN254 prime field. The reconfigurable modular multiplier has three modes: MULT for quadratic function evaluation, DECOMPOSE for the Bars decomposition of Reinforced Concrete, and COMPOSE for recomposing field elements. Division inside DECOMPOSE is replaced by a lookup-table scaled reciprocal and a bit shift, avoiding expensive division hardware. Power maps x^d and $x^{{1/d}}$ for Rescue-Prime and Griffin are computed with square-and-multiply, using two parallel multipliers for the latency variant. These blocks are pipelined and arranged in a sponge construction; area-optimized designs use one pipeline for a batch of 13 inputs, while latency-optimized designs replicate pipelines (Griffin with batch 39, Reinforced Concrete with batch 26) to raise throughput.","core_discovery":"The central claim is that the expensive finite-field operations that make ZK-friendly hashes slow in plaintext can be offloaded to reconfigurable hardware with a small set of reusable building blocks: a reconfigurable modular multiplier, lookup-table-based fast division, and square-and-multiply power mapping. Pipelining these blocks inside a sponge framework yields permutation implementations whose amortized throughput on a Virtex UltraScale+ exceeds the CPU baseline by 3.31x to 23.44x across the three hashes, with every latency-optimized variant above one order of magnitude. The paper further claims this is the first FPGA realization of these three hashes, that the best design (Reinforced Concrete) reaches SHA-3-class latency, and that the modular design extends to other ZK-friendly hashes and field sizes with minimal overhead.","pith_inferences":["An end-to-end benchmark that includes FPGA board I/O and non-saturated batch arrival would likely lower the reported 10-23x speedups, so the headline claim should be validated under realistic streaming workloads.","Because the paper measures the permutation rather than the full sponge hash, the speedup for hashing short messages may be smaller; a testable extension is to measure full absorption/squeezing of multi-block messages.","The same modular arithmetic approach could target 64-bit Goldilocks fields, where CPU native arithmetic is fast; whether the FPGA advantage persists on such fields is an open question that the paper's methodology could answer.","If the HashEmAll modules are integrated with proof-generation accelerators that handle NTT and MSM, the next bottleneck in ZKP proving could be addressed on a single FPGA rather than in separate systems."],"forward_implications":["With latency-optimized HashEmAll, a single FPGA can hash ZK-friendly functions at least an order of magnitude faster than the CPU baseline, which removes the hashing bottleneck in Merkle-tree and recursive-proof pipelines.","The best design, Reinforced Concrete, reaches a per-hash latency comparable to SHA-3, so ZK-friendly hashing no longer carries a plaintext penalty for proof systems that support lookups.","Because the area-optimized variants use far fewer DSPs and LUTs, the designs can be deployed on smaller, lower-cost FPGAs rather than high-end boards.","The modular arithmetic blocks are field-parameterizable, so the same library can be extended to other ZK-friendly hashes and other prime fields, such as a 64-bit Goldilocks field, with minimal changes."],"supporting_citations":[{"why":"Defines the Rescue-Prime permutation and its round functions, the target of one of HashEmAll's accelerators.","marker":"[14]"},{"why":"Defines the Griffin permutation including the quadratic layer and MDS linear layer, the second accelerator target.","marker":"[15]"},{"why":"Defines Reinforced Concrete and supplies the CPU benchmark numbers that HashEmAll compares against.","marker":"[16]"},{"why":"The open-source FPGA library whose optimized modular multiplication blocks this work reuses and extends.","marker":"[30]"},{"why":"Defines the pairing-friendly prime field over which all hash functions are realized.","marker":"[32]"},{"why":"Provides the square-and-multiply algorithm underlying the fast power mapping module.","marker":"[36]"},{"why":"Defines the sponge construction that converts each accelerated permutation into a hash function.","marker":"[37]"},{"why":"Source of the CPU hashing timings that this work replicates and claims to beat by up to 23x.","marker":"[39]"}],"fun_headline_variants":["FPGAs make ZK-friendly hashes 10-23x faster","Run ZK-proof hashing 23x faster on FPGAs","FPGA cores beat CPU 23x for ZK proof hashes","Offload ZK hashing to FPGAs: up to 23x faster","HashEmAll FPGAs speed ZK hashes 10-23x"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The reported speedups rest on the assumption that the FPGA pipeline is always fully saturated with a ready batch of requests and that board I/O traffic is free; real workloads with small or irregular input batches will see smaller gains.","fun_headline_variants_meta":{"raw":{"variants":["FPGAs make ZK-friendly hashes 10-23x faster","Run ZK-proof hashing 23x faster on FPGAs","FPGA cores beat CPU 23x for ZK proof hashes","Offload ZK hashing to FPGAs: up to 23x faster","HashEmAll FPGAs speed ZK hashes 10-23x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000723,"raw_usage":{"total_tokens":3284,"prompt_tokens":1027,"completion_tokens":2257,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":643,"completion_tokens_details":{"reasoning_tokens":2155}},"tokens_in":643,"tokens_out":2257,"duration_ms":18400,"temperature":1.0,"reasoning_tokens":2155,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T22:28:29.023462+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same three hashes on the same FPGA and CPU in an end-to-end Merkle tree construction, streaming real data blocks on and off the board, and compare total time per tree; if the aggregate speedup falls below one order of magnitude, the fully saturated-pipeline assumption does not hold for practical workloads.","supporting_citations":[{"cited_title":"Pairing-friendly elliptic curves of prime order,","cited_arxiv_id":null,"evidence_quote":"Defines the pairing-friendly prime field over which all hash functions are realized."},{"cited_title":"Fast square-and-multiply exponentiation for rsa,","cited_arxiv_id":null,"evidence_quote":"Provides the square-and-multiply algorithm underlying the fast power mapping module."},{"cited_title":"Horst meets fluid-spn: Griffin for zero-knowledge applica- tions,","cited_arxiv_id":null,"evidence_quote":"Defines the Griffin permutation including the quadratic layer and MDS linear layer, the second accelerator target."},{"cited_title":"Reinforced concrete: a fast hash function for verifiable computation,","cited_arxiv_id":null,"evidence_quote":"Defines Reinforced Concrete and supplies the CPU benchmark numbers that HashEmAll compares against."},{"cited_title":"Amaze: Accelerated mimc hardware architecture for zero-knowledge applications on the edge,","cited_arxiv_id":null,"evidence_quote":"The open-source FPGA library whose optimized modular multiplication blocks this work reuses and extends."},{"cited_title":"Sponge functions,","cited_arxiv_id":null,"evidence_quote":"Defines the sponge construction that converts each accelerated permutation into a hash function."},{"cited_title":"Hash functions for zero-knowledge applications zoo,","cited_arxiv_id":null,"evidence_quote":"Source of the CPU hashing timings that this work replicates and claims to beat by up to 23x."}],"review_version":1}