Pith. sign in

REVIEW 3 major objections 6 minor 32 references

if-ZKP: Intel FPGA-Based Acceleration of Zero Knowledge Proofs

T0 review · 3 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read 110x-150x speedup: Intel FPGA accelerates zk-SNARK proving

desk verdict 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. read the letter →

arxiv 2412.12481 v1 pith:6BAPYEOA submitted 2024-12-17 cs.AR cs.CR

Shahzad Ahmad Butt , Benjamin Reynolds , Veeraraghavan Ramamurthy , Xiao Xiao , Pohrong Chu , Setareh Sharifian , Sergey Gribok , Bogdan Pasca This is my paper · ORCID
classification cs.ARcs.CR MSC 94A6014G5011T71
keywords zero-knowledgeproofszk-SNARKmulti-scalarmultiplicationFPGAaccelerationellipticcurvecryptographyBLS12-381BN128IntelAgilex
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

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.

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 (3)
  1. [Section V, Table IX and Section V.B] 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.
  2. [Table III] 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'.
  3. [Section V.D.4 and Figure 8] 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.
minor comments (6)
  1. [Algorithm 2] 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.
  2. [Abstract and Section V.D.4] 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'.
  3. [Figures 4 and 6] 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.
  4. [Table VII] 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.
  5. [Section V.A (Methodology)] 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.
  6. [Section III (Related Work)] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the MSM accelerator is an empirical hardware implementation validated against golden references, with measured rather than fitted performance claims.

full rationale

The paper's central claims are measured hardware results: an Intel Agilex FPGA implementation of MSM for BN128 and BLS12-381, with reported throughput, power, and speedups. The algorithmic derivation chain follows the standard bucket/Pippenger MSM method (Algorithm 2) and standard point addition/doubling formulas from EFD and blst; no derived quantity is defined in terms of the claim it is supposed to support. Functional correctness is checked by comparing FPGA outputs against golden references generated with libsnark, not assumed from the design. Performance comparisons use external, explicitly identified baselines (libsnark on a Xeon CPU, Bellperson on an NVIDIA T4 GPU in Table IX), so the speedup is a measured ratio against named software, not an identity or a fitted parameter renamed as a prediction. The cited prior Intel FPGA arithmetic papers ([25], [26], [28], [29]) are building-block implementation references and are not invoked as uniqueness constraints or as the justification for the main result. There are legitimate benchmark-fairness caveats: libsnark is an older reference library and the T4 is a low-power GPU, so the absolute speedup numbers may not carry over to modern optimized software or high-end datacenter GPUs. However, benchmark choice affects the generality of the comparison, not the circularity of the derivation, and the paper does not reduce its central claim to a self-citation chain or to a definitional equivalence.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claim is an engineering systems result. It rests on standard cryptographic formulas and previously published modular arithmetic IP, plus two hand-chosen design parameters (bucket limb width and replication factor S). No fitted mathematical constants or postulated entities are introduced; the main caveat is that the hand-chosen parameters and benchmark selection shape the reported speedups.

free parameters (2)
  • Bucket window bitwidth (limb size) = not disclosed
    Table III says results used 'tailored parameters optimized for hardware implementation'; this window size controls the number of bucket operations and the claimed compute reduction (23x and 24x).
  • Architectural scaling factor S = 1 and 2
    S scales BAM and IS-RBAM instances; the paper states scaling is limited by FPGA resources and that higher S improves throughput nearly linearly. It is chosen by resource availability, not by a derivation.
assumptions (5)
  • standard math Elliptic curve point addition and doubling formulas from EFD (ref [23]) are correct for short Weierstrass curves in Jacobian coordinates.
    Used in Section IV-B3 to build the UDA pipeline.
  • domain assumption The LUT-based modular multiplication method (ref [27]) and DSP-based method (ref [29]) compute modulo p correctly for the BN128 and BLS12-381 primes.
    Section IV-B1 relies on these IP blocks for all field arithmetic.
  • standard math Pippenger's bucket algorithm (ref [21]) computes MSM correctly under the chosen limb splitting.
    Used in Section II-F and Algorithm 2; correctness of the recursive combination is assumed.
  • domain assumption libsnark's MSM output is a correct golden reference for functional verification.
    Section V-A uses libsnark to generate test vectors and compare FPGA results against golden references.
  • domain assumption The Intel Agilex FPGA board and OneAPI BSP provide the documented memory bandwidth and clock behavior.
    Section V-C relies on board behavior for throughput and power measurements.

how reviews work

0 comments
Cite this review

Pith. "Pith review of if-ZKP: Intel FPGA-Based Acceleration of Zero Knowledge Proofs." pith.science (2026). https://pith.science/paper/6BAPYEOA

@misc{pith2026241212481,
  author       = {Pith},
  title        = {Pith review of: if-ZKP: Intel FPGA-Based Acceleration of Zero Knowledge Proofs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6BAPYEOA}},
  note         = {Machine review of arXiv:2412.12481}
}
read the original abstract

Zero-Knowledge Proofs (ZKPs) have emerged as an important cryptographic technique allowing one party (prover) to prove the correctness of a statement to some other party (verifier) and nothing else. ZKPs give rise to user's privacy in many applications such as blockchains, digital voting, and machine learning. Traditionally, ZKPs suffered from poor scalability but recently, a sub-class of ZKPs known as Zero-knowledge Succinct Non-interactive ARgument of Knowledges (zk-SNARKs) have addressed this challenge. They are getting significant attention and are being implemented by many public libraries. In this paper, we present a novel scalable architecture that is suitable for accelerating the zk-SNARK prover compute on FPGAs. We focus on the multi-scalar multiplication (MSM) that accounts for the majority of computation time spent in zk-SNARK systems. The MSM calculations extensive rely on modular arithmetic so highly optimized Intel IP Libraries for modular arithmetic are used. The proposed architecture exploits the parallelism inherent to MSM and is implemented using the Intel OneAPI framework for FPGAs. Our implementation runs 110x-150x faster compared to reference software library, uses a generic curve form in Jacobian coordinates and is the first to report FPGA hardware acceleration results for BLS12-381 and BN128 family of elliptic curves.

Figures

Figures reproduced from arXiv: 2412.12481 by the authors.

Figure 1
Figure 1. Sharing of Elliptic Curve Add/Double unit for Compute [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. SAB: Scalable Architecture for Bucket Algorithm [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Unified Double and Add Pipeline (UDA) ally becoming a bottleneck in the overall system performance. In addition, because of the area overhead that comes with high level design IP implementations, we did not save nearly as many FPGA resources as we had hoped. To remove the performance bottleneck resulting from slow point double, an implementation was devised based on a fused point add and point double calculation for… view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: MSM Throughput running on CPU TABLE VII SYSTEM LEVEL RESOURCE UTILIZATION Design Variant ALMs DSP Blocks M20K BN128 PAPD-Montgomery(S=2) 715,603 5005 4642 BN128 UDA-Standard(S=2) 571,408 1975 6501 BN128 UDA-Standard(S=1) 537,348 1975 5616 BLS12-381 UDA-Standard(S=2) 83…
Figure 6
Figure 6. Figure 6: FPGA Performance Across Curve and Scaling [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: FPGA Power Normalized Performance for BLS12-381 Curve [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: FPGA vs. GPU Comparison for Normalized Throughput [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 27 canonical work pages

  1. [1]

    On the size of pairing-based non-interactive arguments,

    J. Groth, “On the size of pairing-based non-interactive arguments,” in Advances in Cryptology–EUROCRYPT 2016: 35th Annual Interna- tional Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II 35 . Springer, 2016, pp. 305–326

    2016

  2. [2]

    Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowl- edge,

    A. Gabizon, Z. J. Williamson, and O. Ciobotaru, “Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowl- edge,” Cryptology ePrint Archive , 2019

    2019

  3. [3]

    Accessed: November 2022

    (2022) Snarks research at protocol labs. Accessed: November 2022. [Online]. Available: https://research.protocol.ai/sites/snarks/

    work page 2022

  4. [4]

    Accessed: May 2023

    (2023) ZPrize 2022. Accessed: May 2023. [Online]. Available: https://github.com/z-prize/2022-entries

    work page 2023

  5. [5]

    Doubly- efficient zksnarks without trusted setup,

    R. S. Wahby, I. Tzialla, A. Shelat, J. Thaler, and M. Walfish, “Doubly- efficient zksnarks without trusted setup,” in 2018 IEEE Symposium on Security and Privacy (SP) . IEEE, 2018, pp. 926–943

    work page 2018

  6. [6]

    Sonic: Zero- knowledge snarks from linear-size universal and updatable structured reference strings,

    M. Maller, S. Bowe, M. Kohlweiss, and S. Meiklejohn, “Sonic: Zero- knowledge snarks from linear-size universal and updatable structured reference strings,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security , 2019, pp. 2111–2128

    work page 2019

  7. [7]

    Constructing elliptic curves with prescribed embedding degrees,

    P. S. Barreto, B. Lynn, and M. Scott, “Constructing elliptic curves with prescribed embedding degrees,” in Security in Communication Networks: Third International Conference, SCN 2002 Amalfi, Italy, September 11–13, 2002 Revised Papers 3. Springer, 2003, pp. 257–267

    work page 2002

  8. [8]

    Pairing-friendly elliptic curves of prime order,

    P. S. Barreto and M. Naehrig, “Pairing-friendly elliptic curves of prime order,” in International workshop on selected areas in cryptography . Springer, 2005, pp. 319–331

    work page 2005

Show all 32 references
  1. [9]

    Faster addition and doubling on elliptic curves,

    D. J. Bernstein and T. Lange, “Faster addition and doubling on elliptic curves,” in Advances in Cryptology–ASIACRYPT 2007: 13th International Conference on the Theory and Application of Cryptology and Information Security, Kuching, Malaysia, December 2-6, 2007. Proceedings 13....

    2007

  2. [10]

    Twisted edwards curves,

    D. J. Bernstein, P. Birkner, M. Joye, T. Lange, and C. Peters, “Twisted edwards curves,” in Progress in Cryptology–AFRICACRYPT 2008: First International Conference on Cryptology in Africa, Casablanca, Mo- rocco, June 11-14, 2008. Proceedings 1 . Springer, 2008, pp. 389–405

    2008

  3. [11]

    PipeZK: Accelerating Zero-Knowledge Proof with a Pipelined Architecture,

    Y . Zhang, S. Wang, X. Zhang, J. Dong, X. Mao, F. Long, C. Wang, D. Zhou, M. Gao, and G. Sun, “PipeZK: Accelerating Zero-Knowledge Proof with a Pipelined Architecture,” in 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA) , 2021, pp. 416–428

    2021

  4. [12]

    FPGA acceleration of multi-scalar multiplication: Cyclonemsm,

    K. Aasaraai, D. Beaver, E. Cesena, R. Maganti, N. Stalder, and J. Varela, “FPGA acceleration of multi-scalar multiplication: Cyclonemsm,” Cryp- tology ePrint Archive , 2022

    2022

  5. [13]

    CuZK: Accelerating Zero-Knowledge Proof with a Faster Parallel Multi-Scalar Multiplication Algorithm on GPUs,

    T. Lu, C. Wei, R. Yu, C. Chen, W. Fang, L. Wang, Z. Wang, and W. Chen, “CuZK: Accelerating Zero-Knowledge Proof with a Faster Parallel Multi-Scalar Multiplication Algorithm on GPUs,” Cryptology ePrint Archive, 2022

    2022

  6. [14]

    GZKP: A GPU Accelerated Zero-Knowledge Proof System,

    W. Ma, Q. Xiong, X. Shi, X. Ma, H. Jin, H. Kuang, M. Gao, Y . Zhang, H. Shen, and W. Hu, “GZKP: A GPU Accelerated Zero-Knowledge Proof System,” in Proceedings of the 28th ACM International Con- ference on Architectural Support for Programming Languages and Operating Systems, V...

    2023

  7. [15]

    Enabling zero knowledge proof by accelerating zk-SNARK kernels on GPU,

    N. Ni and Y . Zhu, “Enabling zero knowledge proof by accelerating zk-SNARK kernels on GPU,” Journal of Parallel and Distributed Computing, vol. 173, pp. 20–31, 2023

    2023

  8. [16]

    Accelerating zkSNARKs on modern architectures,

    M. Vezenov, “Accelerating zkSNARKs on modern architectures,” Ph.D. dissertation, Lehigh University, 2022

    2022

  9. [17]

    Accelerating the Plonk zkSNARK Proving System using GPU Architectures,

    T. Derei, “Accelerating the Plonk zkSNARK Proving System using GPU Architectures,” Ph.D. dissertation, Lehigh University, 2023

    2023

  10. [18]

    libsnark: a c++ library for zksnark proofs,

    S. Lab et al., “libsnark: a c++ library for zksnark proofs,” 2023

    2023

  11. [19]

    Pairing-friendly curves for the 128-bit security level,

    G. Bertoni, A. Menezes, and P. Schwabe, “Pairing-friendly curves for the 128-bit security level,” IETF, Internet-Draft draft-irtf-cfrg-pairing- friendly-curves-08, October 2019

    2019

  12. [20]

    Pairing-friendly elliptic curves of prime order,

    P. S. L. M. Barreto and M. Naehrig, “Pairing-friendly elliptic curves of prime order,” in Selected Areas in Cryptography – SAC 2005 , ser. Lecture Notes in Computer Science, B. Preneel and S. Tavares, Eds., vol. 3897. Springer, 2006, pp. 319–331

    2005

  13. [21]

    On the evaluation of powers and related problems,

    N. Pippenger, “On the evaluation of powers and related problems,” in 17th Annual Symposium on Foundations of Computer Science (sfcs 1976). IEEE Computer Society, 1976, pp. 258–263

    1976

  14. [22]

    zk-snark library,

    zkcrypto, “zk-snark library,” GitHub repository, 2024. [Online]. Available: https://github.com/zkcrypto/bellman

    2024

  15. [23]

    D. J. Bernstein and T. Lange. (2007) Explicit-formulas database. Accessed: [2023-12-29]. [Online]. Available: http://www.hyperelliptic. org/EFD/g1p/auto-shortw-jacobian-0.html#addition-add-2007-bl

    2007

  16. [24]

    Accessed: June 2023

    (2024) blst. Accessed: June 2023. [Online]. Available: https://github. com/supranational/blst

    2024

  17. [25]

    High precision, high performance FPGA adders,

    M. Langhammer, B. Pasca, and G. Baeckler, “High precision, high performance FPGA adders,” in 27th IEEE Annual International Symposium on Field-Programmable Custom Computing Machines, FCCM 2019, San Diego, CA, USA, April 28 - May 1, 2019 . IEEE, 2019, pp. 298–306. [Online]. Ava...

    2019

  18. [26]

    Efficient FPGA modular multiplication implementation,

    M. Langhammer and B. Pasca, “Efficient FPGA modular multiplication implementation,” in FPGA ’21: The 2021 ACM/SIGDA International Symposium on Field Programmable Gate Arrays, Virtual Event, USA, February 28 - March 2, 2021 , L. Shannon and M. Adler, Eds. ACM, 2021, pp. 217–223...

    2021

  19. [27]

    Design and implementation of a low-latency modular multiplication algorithm,

    E. ¨Ozt¨urk, “Design and implementation of a low-latency modular multiplication algorithm,” IEEE Transactions on Circuits and Systems I: Regular Papers, vol. 67, no. 6, pp. 1902–1911, 2020

    1902

  20. [28]

    CSAIL2019 crypto- puzzle solver architecture,

    S. Gribok, B. Pasca, and M. Langhammer, “CSAIL2019 crypto- puzzle solver architecture,” in Proceedings of the 2023 ACM/SIGDA International Symposium on Field Programmable Gate Arrays, FPGA 2023, Monterey, CA, USA, February 12-14, 2023 , P. Ienne and Z. Zhang, Eds. ACM, 2023, p...

    2023

  21. [29]

    Low-Latency Modular Ex- ponentiation for FPGAs,

    M. Langhammer, S. Gribok, and B. Pasca, “Low-Latency Modular Ex- ponentiation for FPGAs,” in 2022 IEEE 30th Annual International Sym- posium on Field-Programmable Custom Computing Machines (FCCM) . IEEE, 2022, pp. 1–9

    2022

  22. [30]

    Meet the Powerful IA-840f: Enterprise-Class Intel Agilex Based FPGA Accelerator,

    “Meet the Powerful IA-840f: Enterprise-Class Intel Agilex Based FPGA Accelerator,” https://www.bittware.com/products/ia-840f/, 2023, accessed: 2023-12-29

    2023

  23. [31]

    Accessed: January 2023

    (2024) bellperson. Accessed: January 2023. [Online]. Available: https://github.com/filecoin-project/bellperson

    2024

  24. [32]

    libsnark: a C++ library for zkSNARK proofs,

    C. T. Ltd., “libsnark: a C++ library for zkSNARK proofs,” 2023

    2023

Pith tools

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