{"id":"8f90f37b-eb4f-4778-ba6f-d283c158ebc0","arxiv_id":"2508.11095","paper_version":1,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"HEIR is a unified MLIR-based compiler framework that targets all mainstream homomorphic encryption techniques, libraries, and accelerators, positioned by its authors as the emerging standard HE compiler.","lead":"Homomorphic encryption lets computers calculate on encrypted data, but it is hard to program. HEIR is a new compiler framework built on MLIR that aims to put every homomorphic encryption technique, library, and hardware accelerator under one roof.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"HEIR's abstraction layers may not preserve HE semantics; porting selected literature examples does not establish universal portability.","rationale":"The reader's weakest_assumption correctly identifies semantic fidelity of the abstraction layers as the load-bearing risk. My stress-test agrees and adds a concrete falsification test: differential testing against native libraries on an independent corpus. The reader's UNVERDICTED verdict is appropriate because the full text is absent and the central evidence for the universal claim is not verifiable. No internal inconsistency can be assessed; the concern is about evidence and scope, not authorial conduct. If the differential test passes on a broad corpus, the universal claim would be substantially supported; until then, the abstract's 'large fraction' and 'de facto' claims remain unverified. Thus no change to the reader's verdict is needed.","tokens_in":908,"tokens_out":2397,"duration_ms":27596,"concrete_test":"Construct an independent corpus from HEbench and recent HE papers (listing inclusion criteria), compile each benchmark to three backends (SEAL/BFV, OpenFHE/BGV, OpenFHE/CKKS) via HEIR, and run differential tests against the native library implementations. For each benchmark, check (a) decryption correctness within agreed precision, (b) noise budget at each step matches native implementation's predicted noise, and (c) end-to-end runtime within a stated factor. Also run a randomized fuzzer over circuit shapes (depth, plaintext slots, rotation patterns). If any backend mismatch or noise divergence appears, the abstraction layer is leaky and the portability claim is falsified.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that HEIR is a universal HE compiler, validated by porting a large fraction of the HE literature. The load-bearing premise is that the MLIR abstraction layers faithfully capture HE operations—noise growth, ciphertext packing, modulus switching, bootstrapping—so that optimizations at those layers are correct and backend-portable. The abstract offers no evidence for this semantic fidelity. Porting the author-chosen literature does not rule out abstraction leaks: if an optimization depends on scheme-specific noise behavior that HEIR's generic ops don't encode, generated code may be incorrect or unportable for circuits outside the chosen examples. Additionally, the claim that HEIR is 'emerging as de facto' is an adoption claim that cannot be supported by the paper's own porting exercise. Since the full text is unavailable, no evidence of differential testing, conformance suites, or independent benchmarks is visible. This makes the universal claim unverified, not false.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces HEIR, a Homomorphic Encryption Intermediate Representation built on MLIR, and claims that it provides a unified framework for building HE compilers. The abstract states that HEIR supports all mainstream HE techniques, integrates with major HE libraries and hardware accelerators, addresses the full HE stack including Python frontends, and introduces HE-specific abstraction layers for implementing optimizations. The authors claim to validate HEIR's design by porting a large fraction of the HE literature and argue that HEIR can handle more complicated and diverse programs than prior work, and that it is emerging as the de facto HE compiler for academia and industry. Because only the abstract was available for review, the assessment here is necessarily limited to the claims and evidence presented in that abstract.","tokens_in":1109,"tokens_out":2276,"duration_ms":29969,"significance":"If the central claims are substantiated, HEIR would be a highly significant contribution to the HE community: a common compiler substrate on which optimizations, benchmarks, and hardware backends could be expressed once and reused across schemes and libraries. The MLIR-based design and the explicit goal of covering frontends, mid-level optimizations, and backends are promising strengths, and the claim of porting a large fraction of the HE literature suggests substantial engineering effort. However, the abstract provides no quantitative evaluation, no benchmark protocol, no comparison numbers, and no artifact link. As a result, the significance of the work cannot yet be assessed from the manuscript itself; the reader is asked to take the validation and adoption claims on faith.","major_comments":[{"comment":"The central validation claim is 'we validate HEIR's design by porting a large fraction of the HE literature to HEIR.' This is load-bearing, yet the abstract gives no details: which papers were ported, how many, what selection criteria were used, what 'porting' means in terms of correctness (e.g., does the generated code produce results matching the original implementation?), and what constitutes success. Without this information, the porting exercise cannot be distinguished from cherry-picking or from ports that only cover a narrow subset of each cited technique. The manuscript should specify the ported literature set and the conformance criterion.","section":"Abstract, validation claim"},{"comment":"The paper claims HEIR introduces abstraction layers that support 'all mainstream techniques' and integrate with 'all major software libraries and hardware accelerators.' The load-bearing premise is that these abstraction layers faithfully capture HE semantics, including noise growth, modulus switching, key switching, bootstrapping, and packing. The abstract provides no evidence of semantic fidelity, such as differential testing against native libraries or a conformance suite. Porting selected literature examples does not rule out abstraction leaks for circuits outside the chosen examples. The authors should describe how semantic equivalence to backend libraries is established.","section":"Abstract, semantic fidelity"},{"comment":"The claim that HEIR 'can tackle more complicated and diverse programs than prior literature' is unsupported by any comparative benchmark, program-size metric, or complexity measure. The abstract presents no evaluation protocol, no baseline systems, no runtime or accuracy comparisons, and no artifact repository. Without these, the claim is not falsifiable. A revision should include a reproducible benchmark suite and a comparison against at least one prior HE compiler framework.","section":"Abstract, 'more complicated and diverse programs' claim"},{"comment":"The claim that HEIR is 'emerging as the de facto HE compiler for academic research and industry development' is an adoption claim. It cannot be established by the paper's own porting exercise, regardless of how extensive the ported examples are. Supporting evidence would need to include external adopters, independent usage, or community uptake data. If such evidence is unavailable, the claim should be removed or weakened to a statement about the authors' aspirations for HEIR.","section":"Abstract, 'de facto HE compiler' claim"}],"minor_comments":[{"comment":"The abstract uses both 'aims to support' and 'includes support for' without making the current status clear. The reader cannot tell which features are implemented and which are planned. Please state the current capability level explicitly.","section":"Abstract, phrasing"},{"comment":"No repository URL, version, or commit hash is provided. For an infrastructure paper, a link to the public codebase is essential for reproducibility and for enabling the community to assess the 'de facto' claim.","section":"General"},{"comment":"The phrase 'large fraction of the HE literature' is vague. Provide a concrete count, e.g., 'N of M surveyed papers from a defined bibliographic source,' to make the claim measurable.","section":"Abstract, terminology"}],"recommendation":"major_revision","confidential_remarks":"This review is based solely on the abstract because the full text was not provided to me. The abstract-only basis is itself a limitation, but within that scope the paper's central empirical claims are undersupported. If the full manuscript contains the missing evaluation (port list, conformance methodology, benchmarks, artifact link), then major comments 1–3 may be straightforwardly addressable. The 'de facto' adoption claim in the abstract is the riskiest; I would suggest the authors reframe it or back it with external evidence, otherwise it may draw justified criticism. The paper is potentially a strong fit for a systems/compiler venue if the artifacts and evaluation are as substantial as the claims imply."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: the HEIR abstract is a classic 'infrastructure manifesto' — the pitch is sensible and the design has real content, but the evidence is all in a full text I haven't seen. If the code is public and the porting list is real, this could be a genuinely useful substrate for HE research. If not, it's just a slide deck.\n\nWhat's actually new: applying MLIR to HE with scheme-aware abstraction layers is not just a port of EVA or CHET. The claim to support multiple schemes, frontends, libraries, and accelerators under one IR is a design bet that goes beyond prior single-scheme or single-library compilers. That's worth engaging with.\n\nWhat it does well: the abstract correctly identifies the fragmentation problem and proposes an architecture, not just a benchmark. The enumeration of contributions — framework, literature porting, ecosystem argument — is honest enough.\n\nSoft spots: the universal and 'de facto' language is doing a lot of work. Porting a 'large fraction' of the literature is a coverage claim with no denominator, and 'emerging as de facto' is an adoption claim that a paper cannot establish on its own. The stress-test concern about semantic fidelity is the right one: if the abstraction layers don't preserve noise growth and scheme-specific semantics, then optimizations at those layers can be wrong or unportable. That's a real risk, not a contrived one. But it's a risk you can only assess with the full paper, not the abstract.\n\nBottom line: this is a paper for HE researchers and compiler people. The significance is real if the artifact exists. I'd send it to peer review — not because the abstract proves anything, but because the claims are concrete and checkable, and the potential payoff is high. My own verdict would be 'provisional' until I see the code and the porting evidence.\n\n— [Your name]","headline":"The HEIR abstract is a plausible infrastructure pitch with real design content, but the evidence is all in a full text we haven't seen; peer review should hinge on whether the artifact and porting claims hold up.","tokens_in":1604,"tokens_out":1799,"would_cite":false,"duration_ms":21905,"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":"One compiler aims to unify the homomorphic encryption stack","keywords":["homomorphic encryption","compiler","MLIR","intermediate representation","fully homomorphic encryption","optimization","benchmarking","hardware accelerators"],"falsifier":"Find a mainstream HE program whose scheme-specific behavior (for example, a native noise-growth heuristic, a ciphertext packing layout, or a library-specific key-switching detail) cannot be expressed by any HEIR dialect without changing program semantics. Showing one such program would falsify the universality claim; the paper's own porting list is the starting place to look for gaps.","tokens_in":791,"feed_emoji":"🔐","tokens_out":3027,"duration_ms":31242,"temperature":0.7,"pith_summary":"This paper introduces HEIR, a compiler framework for homomorphic encryption built on MLIR, and argues that a single intermediate representation can express the full range of HE techniques. The claim is that HEIR's HE-specific abstraction layers let researchers implement optimizations once and run them across schemes, libraries, and hardware accelerators, ending the fragmentation that makes HE optimizations hard to combine or compare. The authors support this by porting a large fraction of the HE literature into HEIR and by positioning HEIR as the emerging de facto compiler for the field. If the paper is right, the practical consequence is that future HE research can be validated and benchmarked on a common substrate, and production HE systems get a common compilation path.","feed_headline":"One compiler aims to unify the homomorphic encryption stack","feed_subtitle":"Ports much of the HE literature onto shared abstraction layers so optimizations and benchmarks compare directly.","key_machinery":"The load-bearing object is the HE-specific intermediate representation (IR) built on MLIR: abstraction layers that represent encryption schemes, ciphertext types, noise budgets, and operations such as key switching and relinearization. These layers are what allow scheme-agnostic optimizations to be written once and lowered to different backends; if the IR faithfully captures the semantics of each HE scheme, porting a paper's algorithm becomes translation into the IR.","core_discovery":"On its own terms, the paper's central discovery is that the MLIR compiler framework can host a set of homomorphic-encryption-specific abstraction layers thick enough to cover mainstream HE schemes (BFV, BGV, CKKS, FHEW, and others), frontends including Python, and the optimized building blocks used in the literature. HEIR is presented not as another optimizer but as a platform on which optimizations are written, combined, and compared. The authors claim to validate this by porting a large fraction of the HE literature to HEIR, which they argue handles more complicated and diverse programs than prior approaches. The evidence offered is the breadth of the ported works and the claim that HEIR i","pith_inferences":["If the abstraction layers are faithful, HEIR could serve as a normal form for HE algorithms, analogous to how common IRs made other compiler ecosystems composable; the paper itself only claims porting success, not this broader consequence.","A natural testable extension is to measure whether optimizations written once in HEIR match the performance of hand-tuned native implementations on each backend; the abstract does not report such numbers.","The universality claim implies that any future HE scheme with genuinely new semantics must either fit into the existing abstraction layers or force new dialects; that boundary is a place to watch."],"forward_implications":["New HE optimizations can be expressed once in HEIR and tested against any supported library or accelerator, making head-to-head comparison the default.","The HE research community gains a shared benchmarking substrate, so papers can report numbers on the same compiled pipelines.","Production users can swap HE backends without rewriting application code, as long as their computation is expressible in the IR.","The set of ported papers becomes a living registry of HE techniques, each translatable into a canonical form."],"supporting_citations":[],"fun_headline_variants":["MLIR-based HEIR unifies homomorphic encryption compilers","HEIR: one platform to compare all HE optimizations","Homomorphic encryption converges in a single MLIR compiler","HEIR puts mainstream HE schemes on one compiler stack"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"HEIR's claim of universality rests on the assumption that the HE-specific abstraction layers faithfully capture the semantics of every mainstream homomorphic encryption scheme and backend without distortion.","fun_headline_variants_meta":{"raw":{"variants":["MLIR-based HEIR unifies homomorphic encryption compilers","HEIR: one platform to compare all HE optimizations","Homomorphic encryption converges in a single MLIR compiler","HEIR puts mainstream HE schemes on one compiler stack"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000577,"raw_usage":{"total_tokens":2549,"prompt_tokens":727,"completion_tokens":1822,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":471,"completion_tokens_details":{"reasoning_tokens":1756}},"tokens_in":471,"tokens_out":1822,"duration_ms":16818,"temperature":1.0,"reasoning_tokens":1756,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:08:36.159593+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Find a mainstream HE program whose scheme-specific behavior (for example, a native noise-growth heuristic, a ciphertext packing layout, or a library-specific key-switching detail) cannot be expressed by any HEIR dialect without changing program semantics. Showing one such program would falsify the universality claim; the paper's own porting list is the starting place to look for gaps.","supporting_citations":[],"review_version":1}