{"id":"a89be472-28f8-4910-b366-8a6f3eda2b8d","arxiv_id":"2607.05920","paper_version":3,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A Numba CUDA-Python library for non-RNS CKKS-BGV on GPUs reaches latency comparable to CPU C++ non-RNS FHE libraries with far lower implementation complexity.","lead":"LibFHE is a pure-Python/Numba CUDA library that implements the original non-RNS CKKS-BGV scheme on GPUs. It claims performance on par with optimized CPU C++ non-RNS libraries while making FHE far easier to use inside Python AI stacks.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.5","headline":"The comparability claim rests on absolute T4 latencies alone, with no named CPU Non-RNS baseline or matched parameters.","rationale":"The paper’s engineering contribution—a pure-Python Numba CUDA library for the more flexible Non-RNS CKKS-BGV scheme—is real and the absolute T4 numbers are useful. However the strongest claim is comparative, not absolute. Because §7 supplies only self-reported GPU latencies and never names or times a CPU Non-RNS counterpart under matched parameters, the comparability assertion remains unsupported. That is precisely the load-bearing gap the reader identified. No deeper mathematical inconsistency or hidden assumption in the hybrid limb/RNS pipeline is required to weaken the claim; the missing baseline is already decisive. Therefore the CONDITIONAL verdict stands unchanged pending the concrete side-by-side experiment above (or full open-source release that would let others run it).","tokens_in":24109,"tokens_out":481,"duration_ms":5653,"concrete_test":"Reproduce the original HEAAN (or a maintained Non-RNS C++ CKKS) under exactly the same parameters (N=2^16, log Q=1024, log p=60/30, log s=2) on a contemporary multi-core CPU; report wall-clock times for mult, leftrotate and bootstrap. If LibFHE amortized times are within ~2–3× of that CPU baseline, the claim holds; if they are an order of magnitude slower, the claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim (abstract, §1.3, §8) is that optimized CUDA-Python Non-RNS CKKS-BGV reaches performance comparable to highly optimized CPU-based Non-RNS C++ libraries. The only quantitative support is Table 1 absolute latencies on a Tesla T4 (N=2^16, log Q=1024, cnum=4, amortized bootstrap ~58 s). No named Non-RNS C++ baseline (original HEAAN or equivalent), no identical parameter set, no side-by-side numbers, and no CPU reference timings appear in §7. Without that anchor the word “comparable” is unfalsifiable; the absolute numbers alone cannot establish the claim. The reader correctly flags this as the weakest assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"LibFHE is a Numba/CUDA-Python library that implements the original (non-RNS) CKKS-BGV scheme on GPUs. The authors argue that RNS-CKKS forces rigid modulus chains and 64-bit arithmetic poorly matched to GPU datapaths, while a limb-based radix representation plus temporary RNS/NTT only for multiplication restores dynamic scale control and simplifies kernel fusion. They describe a hybrid limb↔RNS pipeline (Garner reconstruction, precomputed twiddles, matrix four-step NTT, Karatsuba), a CipherTensor batch abstraction with pairwise/broadcast modes, and a HEAAN-style API. Table 1 reports absolute latencies on a Tesla T4 (N=2^16, log Q=1024, cnum=4), including amortized bootstrap ~58 s. The central claim is that this optimized CUDA-Python Non-RNS design reaches performance comparable to highly optimized CPU Non-RNS C++ libraries while improving programmability and AI/ML integration.","tokens_in":24297,"tokens_out":1156,"duration_ms":9859,"significance":"If the comparability claim were substantiated, the work would be a useful systems contribution: a pure-Python, wrapper-free FHE path that reclaims original-CKKS precision flexibility and lowers the barrier for encrypted ML. The hybrid representation, CipherTensor batching, and explicit Non-RNS motivation are concrete engineering ideas. The manuscript also ships a public Colab notebook and states an intent to open-source, which supports reproducibility. At present, however, the significance is limited by the absence of any named Non-RNS C++ baseline under matched parameters, so the headline claim remains unfalsifiable.","major_comments":[{"comment":"Abstract, §1.3 and §8 assert that optimized CUDA-Python Non-RNS implementations achieve performance comparable to highly optimized CPU-based Non-RNS C++ FHE libraries. Table 1 and §7 report only absolute Tesla T4 latencies (amortized bootstrap ~58 s, mult ~2 s) under N=2^16, log Q=1024, cnum=4. No named Non-RNS C++ baseline (original HEAAN or equivalent), no identical parameter set, and no side-by-side CPU timings appear. Without that anchor the word “comparable” is unfalsifiable; absolute numbers alone cannot establish the claim. A matched-parameter comparison (or an explicit retraction of the comparability language) is required.","section":null},{"comment":"§7.2.1 and Table 1: bootstrapping is the dominant cost and the only full-FHE operation, yet it is reported solely as wall-clock latency with no noise-growth, precision, or correctness metrics after refresh, and no comparison to any published Non-RNS or RNS bootstrap figure under the same (log p=30, log q=40, log T=2) setting. The central “Full Homomorphic Encryption” claim therefore rests on an uncontextualized absolute number.","section":null},{"comment":"§4.1.3 and §5.1: the hybrid limb↔RNS design is presented as the key enabler of Non-RNS flexibility, but the manuscript supplies no micro-benchmarks isolating conversion cost versus pure-RNS or pure-limb baselines, nor any measurement of the claimed “negligible bandwidth” of the in-place shared-memory transform. Without those numbers the architectural advantage remains qualitative.","section":null}],"minor_comments":[{"comment":"§1.1 and Abstract open with an unsupported claim that “there is still no indicator pointing toward a fifth-generation successor”; this rhetorical framing is unnecessary and should be removed or substantiated.","section":null},{"comment":"Table 1 caption and §7.2.2: clarify that all times are post-JIT warm-up and that amortized figures are total/cnum, not single-ciphertext latency.","section":null},{"comment":"§6.2.2 lists riterotate_broadcast_into as “To Be Done”; either implement it or remove the stub from the public API description.","section":null},{"comment":"Notation for CipherTensor attributes (log p, log q, log s) is introduced late; a short parameter table early in §6 would help.","section":null},{"comment":"Several related-work citations (Cheddar, WarpDrive, TensorFHE) are discussed only qualitatively; a short quantitative comparison table, even if only for NTT or mult, would strengthen §1.2.","section":null}],"recommendation":"major_revision","confidential_remarks":"The manuscript is an engineering systems paper whose central claim is currently unsupported by the only quantitative evidence provided. If the authors can add a matched Non-RNS CPU baseline (or honestly rephrase the claim to absolute GPU latencies plus programmability), the work becomes a reasonable contribution for a systems/crypto venue. Without that revision the paper over-claims. Scope is appropriate for a specialized FHE or high-performance crypto track; it is not a pure theory paper."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"The new thing here is a complete Numba CUDA-Python implementation of original non-RNS CKKS-BGV, with CipherTensor batching, hybrid limb/RNS conversion only for mult, four-step NTT, and a HEAAN-style API. That combination is not in the literature. The author is right that Full-RNS freezes the modulus chain and kills the dynamic scale control that made early HEAAN attractive for mixed-precision ML. The hybrid representation (32-bit limbs as primary, temporary 30-31-bit RNS + NTT only for ring mult, Garner reconstruction) is cleanly motivated and the precomputation + matrix-lift NTT details are practical.\n\nWhat it does well: the systems writing is clear, the API surface is usable, and Table 1 gives absolute T4 numbers after JIT warm-up (amortized bootstrap ~58 s, mult ~2 s, etc.). Shipping a pure-Python path that can sit next to PyTorch without pybind11 is a real convenience for the PPML crowd. Math and citations look standard and honest; no circularity.\n\nSoft spot, and it is the load-bearing one: the abstract, contributions, and conclusion all claim performance \"comparable to highly optimized CPU-based Non-RNS C++ libraries.\" Section 7 never names HEAAN (or any other Non-RNS C++ baseline), never shows matched parameters, and never reports a single CPU reference timing. Absolute T4 latencies alone cannot support the word \"comparable.\" Bootstrap at 58 s also sits high relative to modern GPU RNS numbers, with no context. Code is only partially public. Those gaps make the strongest claim currently unfalsifiable.\n\nThis is for systems people who want a programmable non-RNS GPU path and for ML folks who care more about Python integration than absolute speed. It is not a theory paper and does not claim order-of-magnitude wins. I would bring it to reading group as an engineering case study. A serious editor should send it to referees; the missing baselines are fixable and the artifact is real. Engage if you care about non-RNS flexibility or Python FHE tooling; otherwise wait for the open-source release and proper numbers.","headline":"Solid pure-Python GPU non-RNS CKKS-BGV library with real engineering work, but the headline \"comparable to CPU C++\" claim has no baselines.","tokens_in":24914,"tokens_out":541,"would_cite":false,"duration_ms":6777,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"Optimized CUDA-Python can match CPU C++ speed for original non-RNS CKKS-BGV fully homomorphic encryption while staying pure Python.","keywords":["Fully Homomorphic Encryption","CKKS","BGV","non-RNS","CUDA-Python","Numba","Number Theoretic Transformation","GPU acceleration"],"falsifier":"Run the same non-RNS CKKS-BGV parameter set (N=2^16, log Q=1024, same precision and slot counts) on a published CPU C++ non-RNS library and on LibFHE, then check whether amortized per-ciphertext latencies for multiply, rotate, and bootstrap are within a small constant factor of each other.","tokens_in":24955,"feed_emoji":"🔐","tokens_out":658,"duration_ms":7316,"temperature":0.7,"pith_summary":"This paper argues that the original, non-RNS form of the CKKS-BGV fully homomorphic encryption scheme can be accelerated on GPUs from pure Python (via Numba and native CUDA-Python bindings) well enough to match the speed of highly optimized CPU C++ non-RNS libraries. Most modern libraries switched to residue-number-system (RNS) variants for hardware speed, but that choice freezes the modulus chain and loses the original scheme's flexible, continuous control of precision and scale. By keeping coefficients in a 32-bit limb (radix) format most of the time and converting only temporarily into RNS+NTT for multiplications, the authors reclaim that flexibility while still exploiting GPU parallelism. They package ciphertexts into batch tensors so many of them share a single kernel launch, and they precompute twiddle factors and conversion constants so the hot path stays lightweight. The practical payoff is a library that sits naturally inside Python AI/ML stacks, needs no fragile C++ wrappers, and still delivers usable performance for encrypted arithmetic and even bootstrapping.","feed_headline":"Python CUDA matches C++ speed for original non-RNS FHE","feed_subtitle":"LibFHE keeps CKKS flexible precision while amortizing GPU kernels across ciphertext batches","key_machinery":"Hybrid limb/RNS pipeline with CipherTensor batching: coefficients live in 32-bit limbs for flexible arithmetic; they are converted in-place only for NTT-domain multiplications, then reconstructed via Garner's mixed-radix CRT, all driven from Numba JIT kernels that amortize work across multiple ciphertexts.","core_discovery":"An optimized pure-Python CUDA implementation of the original non-RNS CKKS-BGV scheme can reach performance comparable to highly optimized CPU-based non-RNS C++ FHE libraries, while cutting implementation complexity and improving programmability for AI/ML workflows.","pith_inferences":[],"forward_implications":[],"fun_headline_variants":["LibFHE: CUDA-Python hits C++ speeds on non-RNS CKKS-BGV","GPU Python matches optimized C++ for original CKKS-BGV FHE","Non-RNS CKKS-BGV reaches C++ parity via CUDA-Python LibFHE","LibFHE gives Python bare-metal GPU speed for non-RNS FHE","CUDA-Python non-RNS FHE matches CPU C++ library performance"],"cache_read_input_tokens":128,"weakest_assumption_plain":"That the self-reported Tesla T4 latencies under the chosen parameters already prove the library is competitive with existing CPU C++ non-RNS libraries, even though no side-by-side numbers or named baselines appear.","fun_headline_variants_meta":{"raw":{"variants":["LibFHE: CUDA-Python hits C++ speeds on non-RNS CKKS-BGV","GPU Python matches optimized C++ for original CKKS-BGV FHE","Non-RNS CKKS-BGV reaches C++ parity via CUDA-Python LibFHE","LibFHE gives Python bare-metal GPU speed for non-RNS FHE","CUDA-Python non-RNS FHE matches CPU C++ library performance"]},"model":"grok-4.5","effort":"low","cost_usd":0.003234,"raw_usage":{"total_tokens":1071,"prompt_tokens":702,"num_sources_used":0,"completion_tokens":93,"cost_in_usd_ticks":32340000,"prompt_tokens_details":{"text_tokens":702,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":276,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":702,"tokens_out":93,"duration_ms":3827,"temperature":1.0,"reasoning_tokens":276,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-14T16:09:13.344700+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Run the same non-RNS CKKS-BGV parameter set (N=2^16, log Q=1024, same precision and slot counts) on a published CPU C++ non-RNS library and on LibFHE, then check whether amortized per-ciphertext latencies for multiply, rotate, and bootstrap are within a small constant factor of each other.","supporting_citations":[],"review_version":3}