{"id":"04771700-fe17-44d2-bec4-0c3316a7faa7","arxiv_id":"2412.12481","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"An Intel FPGA implementation of multi-scalar multiplication for BN128 and BLS12-381 reports 110x to 150x speedups over libsnark and claims the first FPGA result for BLS12-381.","lead":"This paper describes an FPGA design that speeds up multi-scalar multiplication, the main computation in zero-knowledge proofs, by 110 to 150 times compared with a common software library. It is one of the first published FPGA implementations for the BLS12-381 and BN128 elliptic curves used in blockchain systems.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The speedup claim is anchored to an outdated CPU library (libsnark) and a low-power T4 GPU, so the 110x-150x CPU speedup and GPU edge are not established as meaningful bounds without a state-of-the-art baseline.","rationale":"The reader's weakest_assumption correctly identifies the baselines as the most load-bearing assumption. The abstract qualitatively promises a large speedup over a 'reference software library,' and the strongest claim extends this to a statement about being much faster than a server CPU. The CPU baseline being libsnark, and the GPU baseline being a T4, means the measured numbers do not bound against current software or hardware. This is not an internal arithmetic error; the resource tables and power measurements are largely internally consistent, and the functional validation against libsnark golden vectors is a positive step. However, the performance claim's significance is conditional on the reference points, so a CONDITIONAL verdict is appropriate. I also note a secondary presentation issue: Table III's 'Number of Modular Multiplications' column appears to list point-add counts rather than modular multiplications, since the stated 23x reduction is inconsistent with the literal numbers (8128 versus 22); this does not invalidate the measured results but does suggest the theoretical complexity section needs correction. The concrete test of rerunning the CPU baseline with a modern library would settle whether the central speedup claim generalizes beyond the specific legacy library used.","tokens_in":15562,"tokens_out":11181,"duration_ms":97111,"concrete_test":"Reproduce Table IX's 64M-point BLS12-381 MSM timing on the same Xeon Silver 4310 using a current multi-threaded MSM library such as arkworks or Bellman, and record thread scaling; if this modern CPU time is below 150 seconds (versus 1658 seconds for libsnark), then the claimed 110x-150x speedup is not representative of modern CPU software and the headline should be re-scoped.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central performance claim rests on the choice of reference baselines in Section V and Table IX. The CPU column uses libsnark (with OpenMP) on a Xeon Silver 4310, and the GPU column uses Bellperson on a low-power NVIDIA T4. libsnark is a 2018-era reference implementation, not a performance-tuned MSM library; modern libraries such as arkworks or Bellman can be substantially faster on a multi-core CPU. The CPU baseline is also under-specified: no thread count, no OpenMP scaling curve, and no evidence that the libsnark MSM kernel is actually parallelized. If a current optimized CPU library were used, the reported 110x-150x speedup could shrink by an order of magnitude. Likewise, the T4 is not representative of datacenter GPUs, so the 1.14x-1.5x margin does not bound performance against an A100-class accelerator. This is a benchmark-fairness concern that directly affects the practical meaning of the headline result.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents an FPGA-based accelerator for the multi-scalar multiplication (MSM) step of zk-SNARK proving, targeting the BN128 and BLS12-381 elliptic curves on an Intel Agilex device. The proposed architecture, called SAB, uses a scalable bucket-array manager (BAM), a recursive bucket-combination unit (IS-RBAM), and a unified point-add/double pipeline (UDA) in Jacobian coordinates with non-Montgomery modular arithmetic. The authors report functional validation against libsnark golden vectors, resource utilization tables, power measurements, and performance numbers showing up to roughly 124x speedup over libsnark on CPU for BLS12-381 and up to about 148x for BN128 at 64M points, with 1.14-1.5x speedup over Bellperson on an NVIDIA T4 GPU for large MSMs.","tokens_in":15743,"tokens_out":8788,"duration_ms":74795,"significance":"If the reported numbers are accepted, the work is a solid engineering contribution: it demonstrates a working FPGA MSM implementation for BLS12-381 and BN128, reports a high-frequency unified point processor, and provides detailed resource and power data, which are often absent from FPGA acceleration papers. The functional validation against libsnark golden vectors is a particular strength. The main significance caveat is that the headline speedups are defined against a specific, dated CPU reference implementation and a single low-power GPU; the paper's conclusions about the FPGA's advantage are therefore narrower than the abstract's broad phrasing suggests. The architecture itself appears sound and the resource tables are broadly internally consistent, apart from the errors noted below.","major_comments":[{"comment":"The CPU baseline used for the headline speedup is not consistently described. Figure 4 and the CPU execution times in Table IX correspond to a single-threaded libsnark run (throughput of approximately 0.04 M-MSM-PPS for BLS12-381), whereas Section V.D.4 states that the comparison used 'multiple core libsnark implementation while using OpenMP'. If the CPU numbers are single-threaded, the reported 110x-150x speedup is an upper bound against a dated, single-threaded reference implementation and does not bound the gap against modern multi-threaded MSM libraries. Please clarify the exact threading configuration used for the CPU times, and add a comparison against a current optimized library such as arkworks or Bellman, or explicitly scope the speedup claim to the libsnark baseline.","section":"Section V, Table IX and Section V.B"},{"comment":"The column labeled 'Number of Modular Multiplications' is inconsistent with the claimed reduction factors. For BN128, Table II gives m x 8128 modular multiplications for double-and-add; a Pippenger cost of m x 22 implies a 369x reduction, not the claimed 23x. The numbers become consistent if the entries 22 and 32 are interpreted as point operations that each cost about 16 modular multiplications. Please correct the table's column definition, recompute the reduction factors, and fix the curve name typo 'BL12-381'.","section":"Table III"},{"comment":"The power-normalized comparison is made against a single NVIDIA T4, a low-power GPU, and the paper explicitly acknowledges this. However, the conclusion that the FPGA provides a 'reasonable power advantage' over GPUs is not supported beyond the T4 class. Since the manuscript emphasizes efficiency and performance/watt, please either benchmark against a datacenter-scale GPU (e.g., A100) or explicitly restate the efficiency conclusion as being specific to the T4 class rather than to GPUs in general.","section":"Section V.D.4 and Figure 8"}],"minor_comments":[{"comment":"The input comment says 'k // Scalar bitwidth', but in Section II.F, k is defined as the limb bitwidth (window size), not the full scalar bitwidth. Please correct the comment.","section":"Algorithm 2"},{"comment":"The abstract states '110x-150x faster compared to reference software library', but Table IX shows a maximum of 124x for BLS12-381; the 150x figure comes from the BN128 row of Table X for a 64M-point MSM. Please qualify the range with the MSM size and curve, and correct the grammatical errors 'extensive rely' and 'comapred'.","section":"Abstract and Section V.D.4"},{"comment":"The axis labels and legends for Figures 4 and 6 are not described in the text; please add explicit axis labels and legends so the reader can interpret the MSM size and throughput units.","section":"Figures 4 and 6"},{"comment":"The claim that the M20K resource increase is acceptable because M20K was 'initially a very low utilized resource' is not substantiated by absolute numbers. Please report the M20K utilization as a percentage of the device capacity.","section":"Table VII"},{"comment":"The paper does not state how many runs were performed for each measurement and whether any run-to-run variance was observed. Since the FPGA execution times are measured with a host-side stopwatch, please report the number of repetitions and the variance or standard deviation.","section":"Section V.A (Methodology)"},{"comment":"The related-work section is thin and does not survey recent FPGA MSM results beyond CycloneMSM and ZPrize; since the paper claims to be the first FPGA implementation for BLS12-381/BN128, please broaden the survey to include more recent works on FPGA-based MSM and zk-SNARK acceleration, and justify the 'first' claim against the cited literature.","section":"Section III (Related Work)"}],"recommendation":"major_revision","confidential_remarks":"The paper is a credible engineering effort with a working FPGA design and golden-vector validation. The main concern is that the headline performance claims are anchored to an outdated CPU library and a low-power GPU, and the manuscript's own text contains a contradiction about the CPU threading configuration. These issues are fixable with additional measurements and clearer wording. I would also suggest the editor ask the authors to correct Table III, which currently contains a clear numerical inconsistency, and to include an availability statement for the RTL/oneAPI code, as the lack of a release limits reproducibility."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a solid engineering paper with a genuine new result—a working FPGA implementation of MSM for BLS12-381 and BN128, validated against libsnark golden vectors. The architecture details are real: the recursive bucket manager (IS-RBAM), the unified double-add pipeline (UDA), and the non-Montgomery standard-form arithmetic are concrete contributions, not just rehashed ideas. The resource and throughput tables are internally consistent, and the fact that they close timing above 600 MHz for 381-bit arithmetic on Agilex is respectable. The move from Montgomery to standard form to cut DSP usage by 63% is a sensible trade-off, clearly explained.\n\nThe main soft spot is the benchmarking, and the stress-test note lands. The 110x-150x CPU speedup is against libsnark, a 2018-era reference library, with the CPU setup under-specified—no thread count, no evidence the OpenMP path actually parallelizes the MSM kernel. The GPU comparison uses a T4, a low-power card, so the small FPGA edge (1.14x-1.5x) does not bound performance against a datacenter GPU. That means the headline numbers are real but not strong bounds against modern software or high-end accelerators. The paper should either benchmark against a current library like arkworks or Bellman and an A100-class GPU, or explicitly frame the claims as 'vs these specific baselines.' This is a fixable issue, not a fatal one—the engineering contribution stands regardless.\n\nOther issues are minor but worth fixing: no error bars or run-to-run variance, no released artifacts (which hurts reproducibility), a 'first' claim that is only as strong as the literature survey, and some sloppy table formatting (e.g., Table IV looks garbled). These are all addressable in revision.\n\nMy take: the central architectural result is novel within the cited space, the functional validation is grounded, and the performance claims are plausible when read carefully. The benchmarking needs to be tightened before the headline numbers are taken at face value, but the paper deserves serious peer review. I'd bring it to a reading group focused on accelerator benchmarking methods.","headline":"Solid engineering, real first for BLS12-381 FPGA MSM, but headline speedups are baseline-dependent and need a tougher comparison before taking the numbers at face value.","tokens_in":16301,"tokens_out":1825,"would_cite":true,"duration_ms":18150,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["94A60","14G50","11T71"],"pacs":[],"model":"deepseek-v4-flash","headline":"110x-150x speedup: Intel FPGA accelerates zk-SNARK proving","keywords":["zero-knowledge proofs","zk-SNARK","multi-scalar multiplication","FPGA acceleration","elliptic curve cryptography","BLS12-381","BN128","Intel Agilex"],"falsifier":"Take the same 1M to 64M-point BLS12-381 MSM workloads and run them on a current, heavily optimized MSM library (for example the one used by Filecoin's bellperson on a modern GPU such as an A100, or a recent multi-threaded CPU implementation), then compare wall-clock times against the reported FPGA numbers; if the optimized baseline matches or beats the FPGA, the claimed 110x-150x CPU speedup and GPU advantage do not hold as stated.","tokens_in":15367,"feed_emoji":"🔐","tokens_out":5112,"duration_ms":43173,"temperature":0.7,"pith_summary":"The paper claims that a single Intel Agilex FPGA can accelerate the dominant compute step of zk-SNARK proof generation—multi-scalar multiplication (MSM) on the elliptic curves BLS12-381 and BN128—by 110x to 150x compared with a reference multi-threaded CPU library. The authors propose a scalable hardware architecture that combines a recursive bucket method with a unified, fully pipelined point addition/doubling unit built from non-Montgomery modular arithmetic. They report that this is the first FPGA implementation of MSM for these two curves, and that it runs within 1.1x-1.5x of a T4 GPU's speed while using less power. The significance would be that FPGAs become a practical accelerator option for production zk-SNARK provers, which currently struggle with the enormous compute cost of proof generation.","feed_headline":"110x-150x speedup: Intel FPGA accelerates zk-SNARK proving","feed_subtitle":"The Agilex design targets the MSM bottleneck on BLS12-381 and BN128 curves, and also edges out a T4 GPU per watt.","key_machinery":"The machinery is the SAB (Scalable Architecture for Bucket Algorithm): a host-managed memory layout streams scalars and points into multiple Bucket Array Manager (BAM) kernels, each of which runs Pippenger's bucket method; an Independently Scalable Recursive Bucket Array Manager (IS-RBAM) replaces the standard double-and-add combination phase with a smaller recursive MSM; and a single high-throughput Unified Double and Add (UDA) pipeline performs both point addition and doubling at one operation per cycle. The UDA runs in Jacobian coordinates and uses LUT-based modular multipliers (after Ozturk's method) so that each modular multiplication needs only one integer multiplier rather than three, which is what makes the 381-bit BLS12-381 implementation fit.","core_discovery":"On its own terms, the paper's central claim is that a carefully engineered FPGA point processor, shared across an array of bucket-array managers, can keep the MSM computation running at close to one elliptic-curve operation per clock cycle, and that this throughput beats the reference software by over two orders of magnitude. The core design is the UDA (Unified Double and Add) pipeline, which fuses point addition and doubling into a single datapath using 18 modular multipliers instead of the 25 a separate implementation would need, and which operates on standard (non-Montgomery) numbers using a LUT-based modular multiplication method to fit the wider 381-bit curves on-chip. This made possible the first reported FPGA MSM for BLS12-381 and BN128, with execution times falling from 1659 seconds on the reference CPU to 15 seconds on the FPGA for a 64-million-point MSM.","pith_inferences":["The 110x-150x CPU speedups and small GPU advantage are measured against libsnark on a 48-core Xeon and a low-power T4 GPU; against a currently optimized MSM library or a high-end GPU, the relative gains would likely be much smaller, so the headline ratios should be read as a conservative lower bound rather than a universal comparison.","The paper profiles MSM-G2 and NTT as taking even larger shares of prover time than MSM-G1, so extending this architecture to those operations (which the authors list as future work) could compound end-to-end speedups, but memory bandwidth and multi-FPGA coordination would become the next bottlenecks.","The reported linear scaling of throughput and power efficiency with BAM replication is extrapolated from only two scale factors; testing on a larger FPGA or a multi-FPGA board would confirm whether the trend holds when memory channels and resource contention grow.","The decision to use standard-form (non-Montgomery) arithmetic with LUT-based modular multiplication trades DSP blocks for M20K blocks; on FPGAs with different memory-to-DSP ratios, the optimal tradeoff point would shift, which suggests the design can be tuned per device family."],"forward_implications":["MSM can be offloaded to an FPGA with over 100x speedup versus the libsnark reference on large MSM sizes, so a zk-SNARK prover's total time could drop dramatically once the remaining NTT and G2 MSM components are also accelerated.","The architecture scales throughput almost linearly by replicating BAM units, with power-normalized throughput improving similarly, though only scale factors 1 and 2 were demonstrated on the available FPGA.","Because the implementation works in generic Weierstrass/Jacobian form rather than Twisted Edwards form, it covers widely deployed curves like BLS12-381 and BN128, making it more directly applicable to current blockchain systems.","The unified UDA point processor with 18 modular multipliers and standard-form arithmetic is a reusable building block for other large-bitwidth elliptic-curve hardware accelerators.","Recursive use of the bucket method in IS-RBAM reduces the number of point additions and doublings in the combination phase, which is a structural algorithmic improvement that could also benefit software implementations."],"supporting_citations":[{"why":"Supplies the bucket method that the architecture parallelizes and recursively reuses.","marker":"[21]"},{"why":"Source for the software profile and golden test vectors, and the CPU baseline for speedup claims.","marker":"[18]"},{"why":"GPU implementation used as the T4 comparison baseline for BLS12-381 MSM.","marker":"[31]"},{"why":"LUT-based modular multiplication technique that reduces the modular multiplier from three integer multipliers to one, enabling the 381-bit design.","marker":"[27]"},{"why":"Insight that point add and double share compute, used to fuse the PA+PD pipeline into UDA with 18 multipliers.","marker":"[24]"},{"why":"Provides the Jacobian-coordinate point addition and doubling formulas the UDA pipeline implements.","marker":"[23]"},{"why":"Prior FPGA MSM for BLS12-377 in Twisted Edwards form, contrasted as less general than this Weierstrass/Jacobian approach.","marker":"[12]"}],"fun_headline_variants":["Intel FPGA speeds zk-SNARK proofs 110x-150x on BLS12-381","First FPGA acceleration for BLS12-381 and BN128 zk-SNARKs","FPGA cuts 64M-point MSM from 1659s to 15s for zk-SNARKs","18 multipliers in UDA pipeline give zk-SNARK FPGA 110x-150x"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The central claim rests on the fairness of the comparison baselines: the speedups of 110x-150x versus CPU and the small edge over GPU are measured against libsnark on a 48-core Xeon and a low-power T4, not against the fastest available software or high-end GPU MSM implementations.","fun_headline_variants_meta":{"raw":{"variants":["Intel FPGA speeds zk-SNARK proofs 110x-150x on BLS12-381","First FPGA acceleration for BLS12-381 and BN128 zk-SNARKs","FPGA cuts 64M-point MSM from 1659s to 15s for zk-SNARKs","18 multipliers in UDA pipeline give zk-SNARK FPGA 110x-150x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000645,"raw_usage":{"total_tokens":2988,"prompt_tokens":995,"completion_tokens":1993,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":611,"completion_tokens_details":{"reasoning_tokens":1887}},"tokens_in":611,"tokens_out":1993,"duration_ms":14749,"temperature":1.0,"reasoning_tokens":1887,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T14:01:58.180767+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take the same 1M to 64M-point BLS12-381 MSM workloads and run them on a current, heavily optimized MSM library (for example the one used by Filecoin's bellperson on a modern GPU such as an A100, or a recent multi-threaded CPU implementation), then compare wall-clock times against the reported FPGA numbers; if the optimized baseline matches or beats the FPGA, the claimed 110x-150x CPU speedup and GPU advantage do not hold as stated.","supporting_citations":[{"cited_title":"On the evaluation of powers and related problems,","cited_arxiv_id":null,"evidence_quote":"Supplies the bucket method that the architecture parallelizes and recursively reuses."},{"cited_title":"libsnark: a c++ library for zksnark proofs,","cited_arxiv_id":null,"evidence_quote":"Source for the software profile and golden test vectors, and the CPU baseline for speedup claims."},{"cited_title":"Accessed: January 2023","cited_arxiv_id":null,"evidence_quote":"GPU implementation used as the T4 comparison baseline for BLS12-381 MSM."},{"cited_title":"Design and implementation of a low-latency modular multiplication algorithm,","cited_arxiv_id":null,"evidence_quote":"LUT-based modular multiplication technique that reduces the modular multiplier from three integer multipliers to one, enabling the 381-bit design."},{"cited_title":"Accessed: June 2023","cited_arxiv_id":null,"evidence_quote":"Insight that point add and double share compute, used to fuse the PA+PD pipeline into UDA with 18 multipliers."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the Jacobian-coordinate point addition and doubling formulas the UDA pipeline implements."},{"cited_title":"FPGA acceleration of multi-scalar multiplication: Cyclonemsm,","cited_arxiv_id":null,"evidence_quote":"Prior FPGA MSM for BLS12-377 in Twisted Edwards form, contrasted as less general than this Weierstrass/Jacobian approach."}],"review_version":1}