{"id":"59cf82ce-7920-47b3-842d-02a656d4a96c","arxiv_id":"2501.03245","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"gECC batches elliptic-curve operations and reduces integer multiply-add instructions to achieve multi-fold ECDSA/ECDH throughput gains on Nvidia GPUs.","lead":"The paper presents gECC, a GPU framework that speeds up elliptic curve cryptography by batching curve operations and optimizing modular multiplication at the hardware-instruction level. On an Nvidia A100, it reports 4 to 5.6x throughput gains over the leading GPU ECC library and 1.56x for a blockchain workload.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Headline speedups 5.56x/4.94x are not reproduced by Tables 4 and 5, and no ECDH benchmark is reported, so the central quantitative claim is unverifiable as stated.","rationale":"The reader's CONDITIONAL verdict is appropriate: the paper's engineering contributions are plausible and the architecture is described in enough detail to be credible, but the headline numbers need to be reconciled with the experimental tables before the central claim can be accepted. My stress-test focuses on a more directly load-bearing issue than the reader's weakest assumption: the exact speedups quoted in the abstract and introduction are not obtainable from any table in the paper, and the ECDH claim is not backed by a corresponding experiment. This is a verification gap, not a theoretical flaw in the batching or modular arithmetic approach. If the mismatches turn out to be typographical, the corrected numbers still support a strong result (3.8-5.7x across components), so the verdict should remain CONDITIONAL rather than escalate to REJECT. The proposed concrete test—recomputing ratios and locating or running the missing benchmark—would settle the discrepancy directly. I do not adopt the reader's modinv/modmul-ratio concern as the primary one because the paper's own breakdown quantifies batch inversion as a minority contributor (~21%), meaning the headline speedups do not hinge on that ratio alone. However, the reader did flag internal inconsistencies generally, so there is partial agreement.","tokens_in":24900,"tokens_out":7070,"duration_ms":56906,"concrete_test":"Recompute every speedup ratio from the throughput values in Tables 4 and 5: verify 14,141,978/3,386,544 = 4.18, 4,372,853/773,481 = 5.65, 14,389,168/3,810,161 = 3.78, and 6,689,186/1,427,610 = 4.69. Then search the paper, supplementary material, and the public repository for any configuration that yields 5.56x ECDSA verification, 4.94x ECDH, or 4.04x FPMUL. If no such configuration exists, run the missing end-to-end ECDH benchmark on the A100 and report the measured speedup; the abstract and introduction must be corrected to match the actual experimental data.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract's central claim is specific: 5.56x for ECDSA and 4.94x for ECDH compared to the state-of-the-art GPU system (RapidEC). The paper's own tables do not reproduce these numbers. Table 4 gives ECDSA signature generation 14,141,978/3,386,544 = 4.18x and verification 4,372,853/773,481 = 5.65x, not 5.56x. Table 5 shows maximum FPMUL speedup 14,389,168/3,810,161 = 3.78x and maximum UPMUL speedup 6,689,186/1,427,610 = 4.69x; no row reaches 4.94x, and the introduction's claim of 4.04x FPMUL is also absent. The abstract's 4.94x for ECDH is especially problematic: no end-to-end ECDH experiment appears anywhere in Section 5. Section 5.1 says ECDH throughput is dominated by FPMUL, yet the FPMUL data never exceed 3.78x. These discrepancies mean the headline numbers either come from an unreported configuration, contain arithmetic or transcription errors, or conflate ECDH with UPMUL. The central quantitative claim is therefore not supported by the presented evidence. The reader's modinv/modmul-ratio concern, while valid, is secondary: the breakdown in Figure 9 shows batch inversion contributes roughly 21% over RapidEC+OM, so even an unfavorable ratio would not erase the multi-fold gains attributed to modular arithmetic and memory management. The unresolved number mismatch is the more direct threat to the headline claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents gECC, a CUDA framework for high-throughput elliptic curve cryptography on GPUs, targeting the SM2 curve on NVIDIA A100 and V100. The framework batches EC operations via Montgomery's trick, uses a Gather-Apply-Scatter mechanism for batch modular inversion, introduces multi-level cache management and column-major data layout, fuses PADD/PDBL kernels, and optimizes modular multiplication at the SASS level by reducing IMAD instructions through predicate-register carries and IADD3 substitutions. The evaluation compares against RapidEC, CGBN, and DPF, and reports multi-fold speedups for ECDSA, ECDH, point multiplication, and modular multiplication, plus a 1.56x improvement in a FISCO-BCOS blockchain application. The claimed headline speedups are 5.56x for ECDSA and 4.94x for ECDH in the abstract; however, these numbers are not consistently reproduced by the tables in Section 5, and no end-to-end ECDH benchmark is presented.","tokens_in":25247,"tokens_out":7541,"duration_ms":61501,"significance":"If the reported results hold, gECC would be a strong systems contribution: it appears to be the first GPU implementation of batched PMUL using Montgomery's trick, it provides a detailed SASS-level analysis of modular multiplication bottlenecks, and it includes useful ablation experiments (RapidEC+OM, RapidEC+OM+BI, RapidEC+OM+BF, gECC-MO, gECC-MO-KF) that isolate the effect of each optimization. The paper also makes the code publicly available, which supports reproducibility. The main weakness is that the central quantitative claims in the abstract and introduction are internally inconsistent with Tables 4 and 5, and the ECDH claim is not backed by any dedicated experiment. These issues are correctable but must be fixed before the paper can be accepted.","major_comments":[{"comment":"The abstract's headline '5.56x for ECDSA' is not reproduced by Table 4. Section 1 states 4.18x for signature generation and 5.56x for signature verification; Table 4 gives 14,141,978/3,386,544 = 4.18x for generation and 4,372,853/773,481 = 5.65x for verification. The value 5.56x does not appear in Table 4, so the abstract's ECDSA number appears to be a rounding or transcription of the verification-only speedup. Please correct the number to 5.65x and state that it refers to signature verification, or provide an end-to-end ECDSA experiment whose result is 5.56x, and update the abstract accordingly.","section":"Abstract and §5.2"},{"comment":"The abstract's 4.94x for ECDH is not supported by any experiment in the paper. Section 5.1 states that ECDH throughput is dominated by FPMUL and that 'we only report the throughput value of the FPMUL operation,' but no ECDH benchmark appears in Section 5. Table 5 gives a maximum FPMUL speedup of 14,389,168/3,810,161 = 3.78x (batch size 2^14). The introduction's pair 'up to 4.04x and 4.94x' for FPMUL and UPMUL also does not match Table 5, whose maxima are 3.78x and 6,689,186/1,427,610 = 4.69x. The 4.94x figure must be either an actual ECDH measurement (which should be added) or a correctly labeled UPMUL value; as written, the most prominent quantitative claim is unverifiable.","section":"§5.1 and Table 5"},{"comment":"The crossover argument for affine coordinates with Montgomery's trick (N > 20) is derived from CPU latency ratios: Section 2.2 states that modinv/modadd is about 500 and modmul/modadd about 5 'on a mainstream server.' Since the target platform is the A100, and the affine-batching design depends on modular inversion being substantially more expensive than modular multiplication on that GPU, the crossover should be established on the target hardware. Please measure the modinv/modmul latency ratio on the A100 and V100, and if the ratio differs from the CPU-based estimate, re-derive the crossover and re-examine the batch-size claims in Section 5.3.","section":"§3.1"},{"comment":"The claim that 'our design ensures constant time' is not substantiated. Algorithm 3 contains a scalar-dependent branch 'if s[i] == 1 then Qj = Rj' (line 22), and Section 4.1's own microarchitectural analysis shows that instruction issue behavior is sensitive to instruction order and dependencies. On a GPU, a per-thread branch on a secret scalar can produce warp divergence whose timing depends on the scalar bits. Please either remove the constant-time claim, qualify it to 'no secret-dependent operation count' with supporting evidence, or provide a side-channel evaluation showing that the branch does not leak timing information.","section":"§3.4, Algorithm 3"}],"minor_comments":[{"comment":"There are several typos and terminology issues: 'Votal V100' should be 'Volta V100', 'PUML operation' should be 'PMUL operation', and 'SP' is used for what appears to be the A100's SM or warp scheduler; please define the term consistently with CUDA terminology.","section":"§5.1 and §3.4"},{"comment":"The notation for the floating-point implementation is inconsistent: Table 3 and parts of Section 4 use 'DPF-1', while Section 5.4 and Figure 12 use 'DFP-1'. Please use one name throughout.","section":"Table 3 and §5.4"},{"comment":"The statement that modmul and modinv have about 5x and 500x the latency of modadd on a mainstream server has no citation or measurement; please add a reference or move the measurement to the evaluation section.","section":"§2.2"},{"comment":"The normalized-throughput axis labels and the scientific-notation values in Figures 9 and 10 are difficult to read; please enlarge the fonts and label the bars with the exact numeric values used in the text.","section":"Figures 9 and 10"}],"recommendation":"major_revision","confidential_remarks":"The main blockers are the unreconciled headline numbers (5.56 vs 5.65, 4.94 vs 4.69/3.78) and the absence of any ECDH benchmark despite the ECDH claim in the abstract. These are fixable within the manuscript's scope, so I recommend major revision rather than rejection. I would also ask the authors to justify or soften the constant-time claim, since the scalar-dependent branch in Algorithm 3 makes it questionable as stated."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things before reading. First, the paper has real substance: batching PMUL on GPUs with Montgomery's trick plus a GAS-style batch inversion is a genuine extension of RapidEC and DPF-ECC, and the SASS instruction-issue analysis that motivates IMAD reduction is a useful method on its own. Second, the central quantitative claim is currently not reproducible from the paper's own data. The abstract says 5.56x for ECDSA and 4.94x for ECDH; Section 5.2 reports 4.18x for signature generation and 5.65x for verification, and Section 5.3's FPMUL table peaks at 3.78x, with no end-to-end ECDH experiment anywhere. The introduction's 4.04x/4.94x for FPMUL/UPMUL also don't match Table 5 (max 3.78x and 4.69x). This is a load-bearing inconsistency, not a cosmetic one, because the headline is the speedup.\n\nWhat the paper does well: the design detail is credible and specific. The column-major data layout, the find-then-recompute fusion for Montgomery's trick, the L2 persistent cache for intermediate arrays, and the SM2-specific IADD3 reduction are all concrete and, as far as I know, new for GPU ECC. The code is public. The breakdown experiments (RapidEC+OM, +BI, +BF) are the right way to attribute gains, and they largely support the qualitative story even if the arithmetic in the abstract is off.\n\nSoft spots, in proportion. The number mismatch is the big one and must be fixed. The modinv/modmul latency ratio is borrowed from CPU numbers and not measured on the A100, but I'd call that secondary: the breakdown in Figure 9 shows batch inversion adding about 21% over RapidEC+OM, so even an unfavorable ratio wouldn't erase the modular-arithmetic gains. There are no error bars or repeated-run variance, which is common in this literature but still worth asking for. The constant-time claim is asserted in one sentence with no leakage test and no demonstration that the dummy operations actually execute in constant time; for a cryptography paper that deserves either evidence or careful softening.\n\nWho this is for: people working on GPU acceleration of public-key crypto, blockchain transaction processing, and maybe PSI. It deserves a serious referee, but only after the authors reconcile the abstract, introduction, and tables, add an actual ECDH measurement, and either substantiate or drop the constant-time claim. I'd send it to review rather than desk reject, with the number inconsistency as the main revision driver.","headline":"Real GPU-ECC engineering with a genuinely useful SASS-level analysis, but the headline speedups as printed do not match the paper's own tables, and the claimed ECDH result is not actually benchmarked.","tokens_in":25821,"tokens_out":2101,"would_cite":true,"duration_ms":19487,"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":"A GPU framework that batches elliptic-curve operations and trims integer multiply-add instructions claims 5.56x ECDSA and 4.94x ECDH speedups over the leading GPU library.","keywords":["elliptic curve cryptography","GPU acceleration","modular multiplication","Montgomery's trick","batch inversion","SM2 curve","IMAD instructions","ECDSA"],"falsifier":"Benchmark on an A100 the latency of a single 256-bit modular inversion versus a 256-bit modular multiplication, both using the SM2 prime; if the inversion-to-multiplication ratio is below about 20, the $N > 20$ crossover derived in Section 3.1 no longer holds and the reported batch-based speedups would not reproduce.","tokens_in":24695,"feed_emoji":"⚡","tokens_out":7749,"duration_ms":61580,"temperature":0.7,"pith_summary":"The paper sets out to show that the throughput bottleneck of elliptic-curve cryptography on GPUs is not hardware but design: existing GPU libraries optimize single EC operations, while gECC batches thousands of operations and reworks the underlying modular arithmetic. Its core proposal is to use affine coordinates instead of Jacobian coordinates, paying for the extra modular inversions with Montgomery's trick so $N$ inversions collapse into one, and to schedule that inversion with a gather-apply-scatter pattern that avoids warp divergence. On the arithmetic side, the paper identifies the count of Integer Multiply-Add (IMAD) instructions, not raw instruction count, as the true bottleneck in 256-bit modular multiplication, and reduces it with predicate-register carry propagation and, for the SM2 curve's special prime, IADD3 additions in place of IMAD. If the claims hold, GPU systems could sign and verify ECDSA 4.18x and 5.56x faster than the state-of-the-art GPU library and raise a real permissioned blockchain's transaction throughput by 1.56x. This matters because ECC underpins TLS, verifiable databases, private set intersection, and blockchain.","feed_headline":"GPU batching speeds elliptic-curve crypto up to 5.56x","feed_subtitle":"Cutting multiply-add instructions and batching inversions lifts ECDSA and ECDH throughput on GPUs.","key_machinery":"The load-bearing machinery is a stack of three moving parts. Montgomery's trick ([1]) compresses $N$ modular inversions into one inversion plus $3N$ multiplications, making affine-coordinate formulas competitive; a gather-apply-scatter (GAS) scheduling pattern ([34]) runs the compress/inverse/decompress steps across warps so that only one inversion per streaming processor is needed, avoiding divergence. The third part is the SASS-level instruction analysis: the paper measures issue rates of DFMA, DADD, IMAD, and IADD3 on Ampere GPUs, finds IMAD the bottleneck at roughly 136 instructions per 256-bit Montgomery multiplication, and cuts it by carrying the high-word carry through predicate registers, reordering IMADs to avoid register moves, and using the SM2 prime $q = 2^{256} - 2^{224} - 2^{96} + 2^{64} - 1$ to replace IMAD with IADD3 in the reduction phase. The L2 persistent cache and column-major data layout handle the large intermediate arrays.","core_discovery":"The central discovery is that two seemingly unrelated bottlenecks dominate ECC throughput on GPUs and can be attacked together. First, batching: replacing point-by-point Jacobian computation with affine-coordinate formulas batched by Montgomery's trick converts $N$ modular inversions into one inversion plus $3N$ multiplications, and the paper derives that affine batching wins over Jacobian once the batch size $N$ exceeds 20. Second, microarchitecture: by disassembling SASS instructions and measuring issue rates, the paper finds that 256-bit modular multiplication is gated by IMAD instruction count and by register bank conflicts, not by floating-point throughput; their fix uses predicate registers to carry the high-word carry and reorders IMAD instructions to reduce register moves, then exploits the SM2 prime $q = 2^{256} - 2^{224} - 2^{96} + 2^{64} - 1$ to replace further IMADs with IADD3. On the author's measurements, these optimizations yield 1.63-1.72x faster modular multiplication than the fastest single-thread integer baseline, 4.18x faster ECDSA signature generation, 5.56x faster signature verification, 4.94x faster ECDH fixed-point multiplication, and 1.56x higher throughput in a FISCO-BCOS blockchain deployment.","pith_inferences":["The paper's IMAD-count analysis is framed for Ampere GPUs; applying the same framework to a different architecture would require re-measuring issue rates, since the 4-cycle IMAD issue interval and IADD3 2-cycle interval are hardware-specific.","The affine-coordinate batching strategy is not curve-specific in principle, but the IADD3-based reduction gain depends on the SM2 prime's special form; other standardized curves like secp256k1 would need their own reduction identities to see the same arithmetic-level boost.","The reported gains assume large concurrent workloads; applications with batch sizes below the $N > 20$ crossover would not see the inversion-amortization benefit and could even regress.","The GAS-style batch inversion could carry over to other finite-field settings where inversion is expensive, such as pairing-based or post-quantum primitives that rely on modular inversions, though the instruction-level tuning would differ."],"forward_implications":["For batch sizes above about $N > 20$, affine-coordinate EC operations with Montgomery's-trick batching outperform Jacobian-coordinate operations, so throughput-oriented GPU ECC libraries can safely abandon the usual Jacobian choice.","Minimizing IMAD instructions matters more than raw instruction count: programs with fewer SASS instructions can run slower if their issue rate is lower, so future GPU arithmetic optimization should be guided by issued-cycle estimation, not instruction totals.","The SM2 curve's special prime admits a reduction phase built almost entirely from 72 IADD3 instructions instead of hundreds of IMADs, giving 1.63-1.72x over the fastest integer-based baseline on V100 and A100.","End-to-end, the framework lifts ECDSA signature generation to 14,141,978 per second, signature verification to 4,372,853 per second, and a four-node FISCO-BCOS blockchain from about 5,948 to 9,313 transactions per second."],"supporting_citations":[{"why":"Supplies Montgomery's trick, the batch-inversion method that turns $N$ modular inversions into one inversion plus $3N$ multiplications.","marker":"[1]"},{"why":"RapidEC is the state-of-the-art GPU ECC baseline that gECC compares against for ECDSA, point multiplication, and modular multiplication throughput.","marker":"[33]"},{"why":"Provides Montgomery multiplication, the base modular multiplication algorithm whose SOS variant the paper optimizes at the SASS level.","marker":"[42]"},{"why":"CGBN is the integer-based modular multiplication library that supplies the IMAD instruction counts and the CGBN-1/2/4 baselines.","marker":"[35]"},{"why":"DPF is the floating-point-based modular multiplication implementation that gECC disassembles and outperforms with integer-only arithmetic.","marker":"[36]"},{"why":"sppark's carry-propagation approach is the starting point for gECC's technique of minimizing IMAD instructions via predicate registers.","marker":"[50]"},{"why":"Defines the SM2 curve and the SCA-256 prime modulus used for the IADD3-based fast reduction optimization.","marker":"[29]"},{"why":"Provides the Gather-Apply-Scatter (GAS) parallel pattern that gECC adapts to schedule batch modular inversion without warp divergence.","marker":"[34]"},{"why":"Documents the A100 L2 cache persistence feature that gECC relies on for storing batch intermediate arrays.","marker":"[53]"}],"fun_headline_variants":["GPU ECC 5.56x: batch inversions, trim IMAD instructions","Batching and IMAD reduction boost GPU ECC 5.56x","Batching + IMAD cuts speed GPU elliptic-curve crypto 5.56x","How to get 5.56x GPU ECC: batch inversions and drop IMADs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The batching advantage rests on the assumption, imported from CPU latency figures rather than measured on the A100, that modular inversion is roughly 100x more expensive than modular multiplication; if the real ratio is near 20x or below, affine-coordinate batching loses to Jacobian coordinates.","fun_headline_variants_meta":{"raw":{"variants":["GPU ECC 5.56x: batch inversions, trim IMAD instructions","Batching and IMAD reduction boost GPU ECC 5.56x","Batching + IMAD cuts speed GPU elliptic-curve crypto 5.56x","How to get 5.56x GPU ECC: batch inversions and drop IMADs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001264,"raw_usage":{"total_tokens":5275,"prompt_tokens":1144,"completion_tokens":4131,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":760,"completion_tokens_details":{"reasoning_tokens":4048}},"tokens_in":760,"tokens_out":4131,"duration_ms":22909,"temperature":1.0,"reasoning_tokens":4048,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T10:14:50.234178+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Benchmark on an A100 the latency of a single 256-bit modular inversion versus a 256-bit modular multiplication, both using the SM2 prime; if the inversion-to-multiplication ratio is below about 20, the $N > 20$ crossover derived in Section 3.1 no longer holds and the reported batch-based speedups would not reproduce.","supporting_citations":[{"cited_title":"Speeding the pollard and elliptic curve methods of factorization.Mathematics of computation, 48(177):243–264, 1987","cited_arxiv_id":null,"evidence_quote":"Supplies Montgomery's trick, the batch-inversion method that turns $N$ modular inversions into one inversion plus $3N$ multiplications."},{"cited_title":"Accelerating elliptic curve digital signature algorithms on gpus","cited_arxiv_id":null,"evidence_quote":"RapidEC is the state-of-the-art GPU ECC baseline that gECC compares against for ECDSA, point multiplication, and modular multiplication throughput."},{"cited_title":"Modular multiplication without trial division","cited_arxiv_id":null,"evidence_quote":"Provides Montgomery multiplication, the base modular multiplication algorithm whose SOS variant the paper optimizes at the SASS level."},{"cited_title":"Cgbn: Cuda accelerated multiple precision arithmetic (big num) using cooperative groups, 2018","cited_arxiv_id":null,"evidence_quote":"CGBN is the integer-based modular multiplication library that supplies the IMAD instruction counts and the CGBN-1/2/4 baselines."},{"cited_title":"Faster modular exponentiation using double precision floating point arithmetic on the gpu","cited_arxiv_id":null,"evidence_quote":"DPF is the floating-point-based modular multiplication implementation that gECC disassembles and outperforms with integer-only arithmetic."},{"cited_title":"Zero-knowledge template library, 2024","cited_arxiv_id":null,"evidence_quote":"sppark's carry-propagation approach is the starting point for gECC's technique of minimizing IMAD instructions via predicate registers."},{"cited_title":"Public key cryptographic algorithm sm2 based on elliptic curves, 2016","cited_arxiv_id":null,"evidence_quote":"Defines the SM2 curve and the SCA-256 prime modulus used for the IADD3-based fast reduction optimization."},{"cited_title":"Gonzalez, Yucheng Low, Haijie Gu, Danny Bickson, and Carlos Guestrin","cited_arxiv_id":null,"evidence_quote":"Provides the Gather-Apply-Scatter (GAS) parallel pattern that gECC adapts to schedule batch modular inversion without warp divergence."},{"cited_title":"Nvidia a100 tensor core gpu architecture, 2022","cited_arxiv_id":null,"evidence_quote":"Documents the A100 L2 cache persistence feature that gECC relies on for storing batch intermediate arrays."}],"review_version":1}