{"id":"3c0c71b3-c79b-45bd-b757-d6c2f0567fcd","arxiv_id":"2506.08461","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A client-side FHE accelerator using a streaming, reconfigurable NTT/FFT engine reports 1112x and 963x speedups over a CPU for encode/encrypt and decode/decrypt, with a 28.6 mm2 die in 28nm.","lead":"ABC-FHE is a new hardware accelerator for client-side fully homomorphic encryption, designed to handle the large polynomial degrees needed for bootstrapping. It reports large speedups over CPU and prior accelerators while fitting in a small die area and low power, potentially making client-side FHE practical.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section V.C's linear op-count scaling of prior accelerator latencies is the load-bearing assumption; if prior designs become memory-bound at N=2^16, the reported 214x/82x speedups are overestimates.","rationale":"I read the paper as making two separable claims: (1) ABC-FHE is an area- and power-reasonable client-side FHE accelerator supporting bootstrappable parameters, with synthesis numbers of 28.638 mm2 and 5.654 W; and (2) it is 1112x/963x faster than CPU and 214x/82x faster than SOTA client accelerators. Claim (1) has independent support from the synthesis table and architectural description, though the cycle-level simulator is not released and the 'optimized task scheduling' contribution is named but never described. Claim (2) is the central quantitative claim, and its SOTA portion rests almost entirely on the scaling methodology in Sec. V.C. The linear op-count scaling is the weakest link because the paper's own architectural motivation in Secs. I and III is that larger parameters create DRAM bottlenecks in non-streaming designs; a linear compute-based scaling ignores exactly the effect the paper says matters. This is not a disagreement with consensus; it is an internal tension in the evaluation methodology. It does not warrant rejection because the CPU-relative speedups and the synthesis results are independent and plausible, and a corrected comparison would likely still show large speedups. It does, however, warrant the CONDITIONAL verdict already given; my proposed check would either confirm the numbers or reveal how much they are overstated. I agree with the reader's identification of the same weakest assumption.","tokens_in":12474,"tokens_out":6461,"duration_ms":84089,"concrete_test":"Recompute the Fig. 5(a) SOTA speedups with a memory-aware scaling rule: for each prior accelerator, estimate its DRAM traffic per ciphertext for N=2^16 and 24 levels using its stated on-chip capacity and external bandwidth, and scale its published latency by max(compute_op_ratio, DRAM_traffic_ratio) instead of by op count alone. If the adjusted speedups fall by more than 20% from 214x and 82x, the headline claims need a caveat. Alternatively, if the authors release their cycle-level simulator, run the same comparison with a non-streaming prior architecture under LPDDR5 bandwidth and report the resulting speedups.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The headline speedups over SOTA accelerators in Fig. 5(a) and Sec. V.C are computed by taking [22]'s and [34]'s published latencies for smaller non-bootstrappable parameters and scaling them 'by the proportion of operations.' This assumes execution time scales linearly with arithmetic operation count when moving to N=2^16 and 24 levels. That assumption conflicts with the paper's own motivation: Sec. I argues that prior non-streaming architectures suffer severe DRAM bandwidth limits and that [34] fetches parameters from DRAM. For a larger polynomial degree and more levels, memory traffic grows with N, so a non-streaming design's latency should grow at least proportionally to memory traffic, with additional stalls when output per cycle exceeds DRAM bandwidth. The op-count scaling ignores these effects and therefore understates the prior works' latency at bootstrappable parameters, inflating ABC-FHE's relative speedup. No memory model, sensitivity analysis, or cycle-level description of the prior designs is provided to justify the linear rule. The CPU speedup numbers are less affected, but the SOTA comparisons of 214x and 82x are not robust until this scaling is validated.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes ABC-FHE, a client-side CKKS accelerator designed for bootstrappable parameters (polynomial degree up to 2^16 and 24 levels). The architecture combines two reconfigurable streaming cores, each containing a reconfigurable Fourier engine that switches between NTT and FFT modes, a modular streaming engine, an on-chip PRNG, and a unified on-the-fly twiddle-factor generator. The authors report synthesis results of 28.638 mm2 area and 5.654 W power in 28 nm at 600 MHz, and cycle-level simulator speedups of up to 1112x and 963x over a CPU for encoding/encryption and decoding/decryption, respectively, and 214x and 82x over prior client-side accelerators [22], [34].","tokens_in":12701,"tokens_out":5500,"duration_ms":66872,"significance":"If the reported results are valid, the paper makes a useful contribution to an under-served part of the FHE stack: client-side operations under bootstrappable parameters. The workload analysis in Section II.D is valuable, and the concrete microarchitectural choices, including the reconfigurable NTT/FFT datapath, on-chip generation of randomness and twiddle factors, and the area-optimized Montgomery multiplier, are significant engineering contributions. The use of a cycle-level simulator plus 28 nm synthesis for area and power is a strength. The main weakness is the comparison methodology against prior accelerators, which rests on an unvalidated linear-scaling assumption; this directly affects the headline 214x and 82x speedup claims.","major_comments":[{"comment":"The reported 214x and 82x improvements over state-of-the-art accelerators are computed by scaling the published latencies of [22] and [34] 'by the proportion of operations' because those designs do not support N=2^16, 24-level parameters. This assumes execution time scales linearly with arithmetic operation count. The paper's own Section I argues that non-streaming designs are DRAM-bandwidth-limited and that [34] fetches parameters from DRAM; under larger N and more levels, memory traffic and stalls should grow at least proportionally to data volume, and likely faster when output per cycle exceeds DRAM bandwidth. No memory model, cycle-level description, or sensitivity analysis for the prior designs is provided to justify the linear rule. Please either re-run the comparison with memory-aware scaling of the prior works, provide a range of speedups under alternative scaling assumptions, or restrict the claims to CPU comparisons. Without this, the SOTA speedups are not established.","section":"Section V.C, Fig. 5(a)"},{"comment":"The choice of FP55 with a 43-bit mantissa is load-bearing for the area, power, and latency results, but the bootstrapping-precision experiment is only described as 'iteratively reduced the floating-point mantissa bitwidth and evaluated Boot. prec.' No details are given for the precision simulation: what model and dataset are used, what CKKS parameter set and noise budget, how many bootstrapping operations are performed, and how Boot. prec. is computed. Without this, a reader cannot assess whether 43 bits is sufficient or whether the 23.39-bit result is an artifact of a particular test. Please provide the evaluation setup and, ideally, a plot of Boot. prec. versus mantissa width with the 19.29-bit threshold marked.","section":"Section III, Fig. 3(c)"},{"comment":"The NTT-friendly Montgomery multiplier claim needs a clearer statement of the supported prime set. Equation (8) restricts primes to Q = 2^{p_bw} + k*2^{n+1} + 1, and Eq. (11) further restricts k to particular signed sums of three powers of two. The text asserts that the design 'still sufficiently supports 20-40 encryption levels' and mentions 443 primes for N=2^16, but it does not show that the required RNS moduli all satisfy Eqs. (8)-(11) or count how many primes of each bitwidth satisfy the restrictions. Please provide a prime-count verification for the parameter sets used in the evaluation.","section":"Section IV.A, Eqs. (8)-(11)"}],"minor_comments":[{"comment":"The section heading reads 'EVALUTATION'; please correct to 'EVALUATION'.","section":"Section V heading"},{"comment":"The sentence 'NTT and FFT, which perform complex-number and modular computations, respectively' appears to swap the two operations: NTT is modular arithmetic and FFT is complex-number arithmetic.","section":"Section II.B"},{"comment":"The inset graph showing bootstrapping precision versus mantissa bitwidth lacks labeled axes and a legend; the text refers to a 'drop-off point' but the curve is not described clearly.","section":"Figure 3(c)"},{"comment":"There are several typographical errors, including 'eleminating' (should be 'eliminating') and 'reconfigurablility' (should be 'reconfigurability').","section":"Section III"},{"comment":"The statement that prior FPGA and ASIC results were 'normalized to match ABC-FHE's 600 MHz frequency' should clarify whether memory latency is also scaled with frequency or held constant, since this affects the comparison.","section":"Section V.C"}],"recommendation":"major_revision","confidential_remarks":"The paper is a credible architecture contribution with a clear workload analysis and reasonable synthesis-based results. The main risk is not internal inconsistency but the comparison methodology against prior accelerators; the linear-scaling assumption in Section V.C needs to be validated or replaced with a memory-aware model. I would be willing to consider a revised version that addresses this issue and the FP55 precision methodology."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know about this paper. First, the architecture itself is a genuine contribution: a streaming, reconfigurable NTT/FFT engine for client-side CKKS with on-chip PRNG and unified on-the-fly twiddle generation, plus a cleverly restricted Montgomery multiplier that saves area. The area and power numbers (28.6 mm2, 5.65 W in 28nm) are plausible for a synthesis study, and the workload analysis showing the 10:1 imbalance between encryption and decryption is useful. Second, the headline speedups over prior accelerators (214x and 82x) rest on a weak assumption: the authors scale prior designs' latencies by \"the proportion of operations\" to compare at N=2^16 and 24 levels. That assumes linear scaling with op count, which their own introduction argues against—they say non-streaming designs hit DRAM bandwidth limits at larger N. If those designs become memory-bound, the linear scaling understates their latency and flatters ABC-FHE. The CPU speedups are direct measurements and fine, but the SOTA comparisons are not robust.\n\nThe other soft spots are minor. The \"optimized task scheduling\" mentioned in the abstract is claimed but never really described—I didn't find it in the microarchitecture sections. And everything is simulated, not taped out, so the area/power are estimates. On the plus side, the Montgomery reduction derivation is shown clearly, and the FP55 bitwidth choice is backed by a bootstrapping precision experiment with a defined threshold. The paper is honest about what it does and doesn't support.\n\nBottom line: this is a solid architecture paper with one load-bearing evaluation weakness. If I were refereeing, I'd ask for a better comparison—either a memory-aware model of the prior designs or a release of the simulator—before trusting the 214x/82x numbers. The architecture itself deserves serious consideration.\n\nRecommendation: send to peer review, but expect a request for major revisions on the evaluation.","headline":"A plausible client-side FHE accelerator with a real architecture contribution, but the headline speedups over prior work rest on a shaky linear-scaling assumption that likely overstates the gap.","tokens_in":13241,"tokens_out":2353,"would_cite":true,"duration_ms":26762,"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":"ABC-FHE claims a client-side FHE accelerator that supports bootstrappable parameters, reaching up to 1112x speedup over CPU for encode/encrypt and 963x for decode/decrypt.","keywords":["fully homomorphic encryption","CKKS","client-side accelerator","NTT/FFT","streaming architecture","bootstrapping","Montgomery multiplication","twiddle factor generation"],"falsifier":"Take a prior client-side accelerator, such as the compact RNS-CKKS en/decoding/decryption accelerator, and measure its encode/encrypt and decode/decrypt latency directly at polynomial degree $2^{16}$ with the same 24-level parameters; if the measured latency is higher than the paper's linearly scaled estimate, the 214x and 82x speedups are overstated. On the ABC-FHE side, running the same workload while reducing DRAM bandwidth below the assumed 68.4 GB/s would test whether the streaming design truly avoids a memory bottleneck.","tokens_in":12290,"feed_emoji":"🔐","tokens_out":8959,"duration_ms":89595,"temperature":0.7,"pith_summary":"ABC-FHE is a chip design whose goal is to remove the client-side bottleneck in fully homomorphic encryption (FHE), specifically the encode/encrypt and decode/decrypt steps of the CKKS scheme at large polynomial degrees (up to $2^{16}$) that support bootstrapping. Prior client-side accelerators were limited to smaller parameters and hit DRAM bandwidth walls when scaled up. The paper claims that a streaming architecture with a reconfigurable Fourier engine and on-chip generation of random values and twiddle factors can handle bootstrappable parameters while remaining small enough for client devices, reporting 28.638 mm$^2$ die area and 5.654 W power in 28nm technology. Against a CPU it reports speedups of up to 1112x for encoding and encryption and 963x for decoding and decryption; against the prior state-of-the-art client accelerator, up to 214x and 82x, respectively.","feed_headline":"A 28 mm2 chip claims 1000x client-FHE speedup","feed_subtitle":"ABC-FHE targets CKKS encode/encrypt and decode/decrypt at degree 2^16 in 28nm, with 28.6 mm2 and 5.65 W.","key_machinery":"The load-bearing object is the Reconfigurable Fourier Engine (RFE), composed of four pipelined NTT lanes that switch between 44-bit integer modular arithmetic (NTT) and a custom 55-bit floating-point format (FFT) by reconfiguring the modular multipliers into complex-number multipliers. The pipeline is a multi-path delay commutator (MDC) radix-$2^n$ design, and the paper argues that radix-$2^n$ is the only family that preserves the twiddle factor pattern needed to fold nega-cyclic pre/post-processing into the existing multiplier stages, eliminating extra multipliers. Two supporting mechanisms carry the memory argument: the unified on-the-fly twiddle factor generator (OTF TF Gen), shared across all lanes, produces each stage's twiddle factors from small seeds and step sizes, and an on-chip PRNG generates random masks, errors, and keys. Together they keep the streaming cores fed without large off-chip parameter fetches, which the paper identifies as the bottleneck that capped earlier client accelerators.","core_discovery":"The paper's central claim is that client-side CKKS processing under bootstrappable parameters can be implemented as a compact streaming datapath: a reconfigurable Fourier engine (RFE) that executes both integer NTT and complex FFT on the same pipelined lanes, with a modular streaming engine (MSE) for RNS, CRT, and elementwise operations. The RFE uses a radix-$2^n$ multi-path delay commutator pipeline, chosen because only radix-$2^n$ keeps the twiddle-factor pattern needed to merge nega-cyclic pre/post-processing into the multiplier schedule, reaching the theoretical minimum of $P/2 \\times \\log_2 N$ multipliers. A custom 'NTT-friendly' Montgomery multiplier selects primes of the form $2^{p_{bw}} + k \\cdot 2^{n+1} + 1$ so that reduction becomes shift-and-add, cutting modular multiplier area by 41.2% versus vanilla Montgomery and 67.7% versus Barrett. The design generates twiddle factors on the fly from a 26.4 KB seed memory and random masks, errors, and keys from a 128-bit-seed PRNG, replacing over 99.9% of the on-chip storage that would otherwise be needed, and thereby avoiding DRAM traffic that would stall the streaming pipeline. With these pieces, the paper reports the speedups listed above and projects scaling to roughly 0.9 mm$^2$ and 2.1 W in 7nm.","pith_inferences":["If the streaming-plus-on-chip-generation design is as effective as claimed, it suggests a broader recipe for FHE client accelerators: minimize off-chip state by generating keys, masks, errors, and twiddle factors on-chip, rather than caching them; this recipe may transfer to BFV/BGV client operations, which share the same NTT structure.","The paper's speedup comparison scales prior accelerators by operation proportion, so the 214x and 82x figures are conditional on linear scaling; a direct measurement of the previous chips at $N=2^{16}$ would be the cleanest test of the comparison.","The FP55 format selected via the bootstrapping-precision curve (23.39 bits at 43 mantissa bits) is a design parameter worth reusing: the same iterative mantissa-reduction methodology could be applied to other approximate workloads that need a known precision floor.","The NTT-friendly prime restriction changes the parameter landscape: a direct security and functionality audit should confirm that the restricted prime set still covers the bootstrapping levels and security margins that CKKS deployments require."],"forward_implications":["Client-side FHE moves from a dominant bottleneck to a minor one: with ABC-FHE's numbers, encode/encrypt and decode/decrypt take milliseconds at $N=2^{16}$, making interactive or edge FHE workloads practical.","Bootstrappable parameters become usable on the client: supporting $N$ up to $2^{16}$ with 24 levels means the full CKKS bootstrapping pipeline can run end-to-end, not just small-parameter toy cases.","The same hardware can serve encryption and decryption asymmetrically: the two reconfigurable cores can double throughput on one direction or run encrypt and decrypt concurrently, matching the 10:1 workload imbalance the paper measures.","On-chip parameter generation removes the need for high-bandwidth memory: because twiddle factors and random values are generated internally, the design runs under LPDDR5-class bandwidth, which is realistic for client devices.","The area optimizations compound: twiddle scheduling, NTT-friendly Montgomery multipliers, and NTT/FFT reconfigurability reduce RFE area by 31%, and the resulting 28nm footprint scales to under 1 mm$^2$ in 7nm."],"supporting_citations":[{"why":"The state-of-the-art client-side RNS-CKKS en/decoding and en/decryption accelerator that ABC-FHE compares against; its latency is scaled by operation proportion.","marker":"[34]"},{"why":"Aloha-HE, a low-area client-side accelerator limited to non-bootstrappable parameters, also scaled in the comparison.","marker":"[22]"},{"why":"Trinity, the server-side FHE accelerator used to show that client-side operations now dominate end-to-end latency.","marker":"[9]"},{"why":"High-precision RNS-CKKS on fixed smaller word-size architectures, supplying the double-scale technique that justifies 36-bit primes and the 44-bit datapath.","marker":"[1]"},{"why":"SHARP, which sets the bootstrapping precision threshold (19.29 bits) used to choose the FP55 FFT datapath.","marker":"[19]"},{"why":"Johnston's parallel pipeline FFT, the MDC backbone that ABC-FHE's pipelined NTT lanes are based on.","marker":"[16]"},{"why":"Roy et al.'s compact ring-LWE cryptoprocessor, the source of merging nega-cyclic pre/post-processing with twiddle factors.","marker":"[30]"},{"why":"Montgomery's modular multiplication without trial division, the algorithm that the NTT-friendly Montgomery multiplier optimizes.","marker":"[25]"},{"why":"Sarangi and Baas's DeepScaleTool, used to project the 28nm design to 7nm area and power.","marker":"[31]"}],"fun_headline_variants":["Client-FHE chip hits 1112x speedup in just 28.6 mm2","ABC-FHE: 28nm accelerator gives 1000x client-FHE speedup","Streaming FHE design: 1000x faster client operations","Reconfigurable NTT/FFT engine yields 1000x client-FHE gains"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the prior accelerators' performance can be fairly estimated by scaling their measured latency by the proportion of operations, since they cannot run the bootstrappable parameters ABC-FHE targets; if real memory-bound and pipeline effects make their latency grow faster than that linear scaling, the claimed speedups over them shrink.","fun_headline_variants_meta":{"raw":{"variants":["Client-FHE chip hits 1112x speedup in just 28.6 mm2","ABC-FHE: 28nm accelerator gives 1000x client-FHE speedup","Streaming FHE design: 1000x faster client operations","Reconfigurable NTT/FFT engine yields 1000x client-FHE gains"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000856,"raw_usage":{"total_tokens":3836,"prompt_tokens":1180,"completion_tokens":2656,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":796,"completion_tokens_details":{"reasoning_tokens":2565}},"tokens_in":796,"tokens_out":2656,"duration_ms":23362,"temperature":1.0,"reasoning_tokens":2565,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T05:10:16.733304+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a prior client-side accelerator, such as the compact RNS-CKKS en/decoding/decryption accelerator, and measure its encode/encrypt and decode/decrypt latency directly at polynomial degree $2^{16}$ with the same 24-level parameters; if the measured latency is higher than the paper's linearly scaled estimate, the 214x and 82x speedups are overstated. On the ABC-FHE side, running the same workload while reducing DRAM bandwidth below the assumed 68.4 GB/s would test whether the streaming design truly avoids a memory bottleneck.","supporting_citations":[{"cited_title":"A compact and efficient hardware accelerator for rns-ckks en/decoding and en/decryption,","cited_arxiv_id":null,"evidence_quote":"The state-of-the-art client-side RNS-CKKS en/decoding and en/decryption accelerator that ABC-FHE compares against; its latency is scaled by operation proportion."},{"cited_title":"Aloha-he: A low- area hardware accelerator for client-side operations in homomorphic encryption,","cited_arxiv_id":null,"evidence_quote":"Aloha-HE, a low-area client-side accelerator limited to non-bootstrappable parameters, also scaled in the comparison."},{"cited_title":"High- precision rns-ckks on fixed but smaller word-size architectures: theory and application,","cited_arxiv_id":null,"evidence_quote":"High-precision RNS-CKKS on fixed smaller word-size architectures, supplying the double-scale technique that justifies 36-bit primes and the 44-bit datapath."},{"cited_title":"Parallel pipeline fast fourier transformer,","cited_arxiv_id":null,"evidence_quote":"Johnston's parallel pipeline FFT, the MDC backbone that ABC-FHE's pipelined NTT lanes are based on."},{"cited_title":"Compact ring-lwe cryptoprocessor,","cited_arxiv_id":null,"evidence_quote":"Roy et al.'s compact ring-LWE cryptoprocessor, the source of merging nega-cyclic pre/post-processing with twiddle factors."},{"cited_title":"Deepscaletool: A tool for the accurate estimation of technology scaling in the deep-submicron era,","cited_arxiv_id":null,"evidence_quote":"Sarangi and Baas's DeepScaleTool, used to project the 28nm design to 7nm area and power."}],"review_version":1}