🧬 biology

bioETH-Beacon: A Confidential On-Chain Genomic Beacon with Encrypted Counts, Filters, and Bounded Noise over a Fully Homomorphic EVM

bioETH-Beacon is a smart-contract prototype that enables confidential, on-chain genomic beacon queries with encrypted counts and bounded noise over a fully homomorphic Ethereum Virtual Machine (fhEVM), thereby eliminating the need for a trusted compute evaluator while mitigating privacy risks like membership inference and plaintext query exposure.

Original authors: Christos Galanopoulos, Kimon Antonios Provatas, Ilias Georgakopoulos-Soares

Published 2026-06-19

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Christos Galanopoulos, Kimon Antonios Provatas, Ilias Georgakopoulos-Soares

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ⚕️ This is an AI-generated explanation of a preprint that has not been peer-reviewed. It is not medical advice. Do not make health decisions based on this content. Read full disclaimer

Imagine a massive, global library of genetic information. In this library, researchers want to ask simple questions like, "Has anyone in this group of people ever been found with this specific genetic typo?"

Currently, if you ask this question, the librarian (the hospital holding the data) sees exactly what you asked, and you get a clear answer like "Yes, 5 people." This creates two problems:

The Librarian Knows Too Much: The hospital can see your research interests.
The "Stalker" Problem: If a researcher asks about very rare typos over and over, they can mathematically figure out if a specific person (like a celebrity or a neighbor) is in the group, even without seeing their name.

bioETH-Beacon is a new, experimental "smart library" built on a special kind of blockchain that uses Fully Homomorphic Encryption (FHE). Think of FHE as a magical, unbreakable glass box. You can put data inside, perform math on it, and get a result out, all without ever opening the box or seeing the data inside.

Here is how the paper explains this system using simple analogies:

1. The Magic Glass Box (The System)

Instead of a human librarian, the library uses a Smart Contract (a computer program that runs automatically).

The Hospitals (Data Owners) put their genetic data into the glass box. They encrypt it first, so even the hospital can't see the numbers once they are inside.
The Researchers (Requesters) put their questions into the box. They also encrypt the question so the box doesn't know what it's looking for.
The Magic: The box performs the search and counting while everything is still locked inside. It never opens the box to read the data.
The Result: The box spits out an encrypted answer. Only the specific researcher who asked the question has the key to unlock that specific answer. The hospital, the blockchain, and even the computer running the box never see the raw data or the final number.

2. The "Anti-Stalker" Noise (Privacy Protection)

The paper addresses the "Stalker Problem" (Membership Inference). If a researcher asks, "Is there a rare typo?" and gets "0," they know that person isn't there. If they get "1," they know they are.

To stop this, bioETH-Beacon adds Bounded Noise to some answers.

The Analogy: Imagine the library is slightly foggy. If the real answer is "5 people," the system might randomly add a little bit of "static" and tell you "6" or "4."
The Catch: The paper is very honest: this isn't a perfect shield. If a stalker asks the same question 20 times, they might eventually get the "real" answer by looking for the lowest number. So, the system also has Rate Limits (like a bouncer) to stop anyone from asking the same question too many times.
Important Note: This "foggy" feature is only used for certain types of questions (genetic markers and complex multi-filter searches). For simpler questions (like age or gender filters), the system gives the exact number, but only to trusted, approved researchers.

3. The Three Speed Lanes (Tiers)

The paper describes a "3x4 grid" of different ways to run the search, trading off between Privacy and Speed/Cost.

Lane 1 (T3 - The Gold Standard): The search looks at every single piece of data one by one. Everything is hidden. It's the most private but takes the longest (and costs the most "gas," which is the fee for using the blockchain).
Lane 2 (T4 - The Slimmer Box): The search still looks at everything, but it uses a smaller, lighter container for the numbers. It's slightly faster on a real network but works the same way.
Lane 3 (T5 - The Pre-Grouped Shelves): This is the fast lane. Before the search starts, the library organizes the data into 20 pre-defined "shelves" (slots). The researcher asks, "How many are on Shelf 3?" The system only checks those 20 shelves, not the whole library.
- The Trade-off: To get this speed, the system has to reveal which shelves exist (i.e., which genetic markers are being tracked), but it still keeps the counts hidden. This is great for dense data but less private about what is being tracked.

4. The "Multi-Filter" Super-Query

There is a special "G1" contract that acts like a super-search. Instead of asking three separate questions ("Is it a female?", "Is she over 40?", "Does she have this disease?"), you can ask one complex question: "Find females over 40 with this disease."

Why it matters: If you asked these three questions separately, someone could piece together the answers to learn more than intended. The G1 contract does all three checks at once inside the glass box and gives you one single, encrypted answer.

5. What the Paper Actually Says (The Reality Check)

The authors are very clear about what this is and what it is not:

It is a Prototype: This is a research project, not a finished medical product ready for hospitals to use tomorrow.
It Uses Synthetic Data: They tested it using fake data generated from public genetic catalogs, not real patient records.
It Has Limits:
- The "foggy noise" isn't a perfect privacy guarantee; it just makes spying harder.
- If the database gets huge (millions of markers), the system might get confused by "collisions" (two different typos looking the same), so they have to use bigger number containers.
- The system still trusts a "Key Management Service" (a third party) to hand out the keys to unlock the answers. If that third party is hacked, the privacy is broken.

Summary

bioETH-Beacon is a clever experiment that proves you can run a global genetic search on a public blockchain without anyone (not even the hospital or the computer) seeing the actual data or the specific questions. It uses a "glass box" to count things, adds a little "static" to confuse stalkers, and offers different speed settings depending on how much privacy you need. It's a promising step toward private medical research, but it's still in the testing phase.

Technical Summary: bioETH-Beacon

Problem Statement

The Global Alliance for Genomics and Health (GA4GH) Beacon protocol enables researchers to query whether specific genomic variants exist within a cohort and, optionally, receive aggregate counts. However, standard deployments suffer from two critical privacy gaps:

Host Visibility: The host institution observes all queries in plaintext, including the researcher's identity, the specific variant queried, and the returned counts.
Membership Inference: Researchers receive plaintext counts, allowing adversaries to perform repeated queries on rare variants. Through likelihood-ratio tests, this enables membership-inference attacks that can confirm the presence of a specific individual in the cohort.

While organizational measures (trust, access governance, rate limiting) can partially mitigate these risks, the protocol itself does not close these gaps.

Methodology

bioETH-Beacon is a research prototype that implements the GA4GH "aggregate count" query directly on a Fully Homomorphic Encryption (FHE) Ethereum Virtual Machine (fhEVM), specifically utilizing the Zama TFHE coprocessor. The system operates entirely within the encrypted domain, ensuring that neither the host nor the blockchain observer can access raw genomic data or query contents.

Core Architecture

The system is built on a two-layer contract architecture:

Public Layer (BeaconRegistry): Manages dataset metadata, contributor approvals, rate-limit policies, and integrity commitments. It contains no encrypted state.
Encrypted Layer (ConfidentialBeacon family): Stores encrypted marker-count arrays and executes the scan kernel. It holds all genomic state in ciphertext.

Execution Tiers and Query Families

The design is organized as a 3×4 tier-by-query-family grid to parameterize the trade-off between privacy and computational cost:

Execution Tiers:
- T3 (Reference): Full encrypted scan. Marker IDs, filter values, and counts are all encrypted. Cost scales linearly with the number of uploaded entries ( $\Theta(N)$ ).
- T4 (Width-Optimized): Narrows the accumulator from euint64 to euint32 to reduce Homomorphic Computation Unit (HCU) depth costs, provided counts fit within 32 bits.
- T5 (Pre-aggregated): Uses a fixed set of $M$ public marker slots. Contributors upload counts to specific slots. Queries scan $M$ slots rather than $N$ entries ( $\Theta(M)$ ), significantly reducing query gas but revealing which markers are present (though counts remain encrypted).
Query Families:
- Genotype: Base query for marker presence.
- Sex, Age, Phenotype: Single-axis categorical filters (e.g., 5 buckets for sex, 7 for age).
- G1 (Multi-filter): A single contract evaluating a four-way conjunctive predicate (marker $\land$ sex $\land$ age $\land$ phenotype) in one encrypted query, preventing the disclosure of intermediate single-axis counts.

Key Mechanisms

Oblivious Scan Kernel: The contract performs an FHE.eq (equality check), FHE.select, and FHE.add chain over every entry without early exits, ensuring constant-time execution regardless of the query result.
Chunking: Due to sequential-depth limits in the FHE coprocessor (5M units), scans are broken into chunks. The paper identifies a safe empirical chunk size of 29 entries for euint64 accumulators (analytic ceiling 37, recommended deployment 23).
Bounded Noise Injection: To mitigate membership inference, the system adds bounded uniform noise ( $\nu \sim \mathcal{U}\{0, \dots, B-1\}$ ) to the result on supported paths (Genotype T3/T4/T5 and G1). Crucially, this noise is sampled inside the FHE coprocessor, preventing the coordinator from choosing zero-noise injection. This is an anti-probing feature, not a formal differential privacy guarantee.
Access Control: Result decryption is delegated to an off-chain Key Management Service (KMS). Only the requester named in the contract's FHE.allow call can retrieve the plaintext aggregate.

Key Contributions

First fhEVM Beacon Implementation: A smart-contract prototype executing the Beacon aggregate-count primitive entirely on encrypted data, hiding marker IDs, counts, and filter values (except in T5 where marker presence is public).
3×4 Design Space: A structured grid of 13 deployed contracts (12 in the grid + 1 G1 multi-filter) offering varying levels of privacy and cost, from full encryption (T3) to pre-aggregated lookup (T5).
On-Chain Noise Injection: A mechanism for adding bounded noise inside the FHE coprocessor, preventing coordinator manipulation of the noise value.
Security Invariants: Definition and verification of 11 explicit security invariants across the contract suite, covering state privacy, query execution patterns, and access control.
Empirical Evaluation: Benchmarks on synthetic panels derived from the PGS Catalog (ranging from 16 to 100,000 markers) measuring gas, transaction counts, and wall time.

Results

Scaling: Upload costs scale linearly with the number of non-zero entries ( $N$ ). Query costs for T3/T4 scale linearly with $N$ , while T5 remains flat relative to $N$ (dependent on fixed $M$ ).
Gas Efficiency: In a fixed- $M=20$ $M = 20$ benchmark with $N=500$ $N = 500$ entries:
- T5 reduced query gas by 94% (from ~24.9M to ~1.45M) and upload gas by 53% compared to T3.
- T4 showed negligible EVM gas savings in local tests but offers a 24% reduction in HCU costs on a live network.
Crossover Point: For the P1K panel, T5 becomes more cost-effective than T3 for total lifecycle gas (upload + query) when $N$ exceeds approximately 246–484 entries, depending on the query-to-upload ratio.
Correctness: End-to-end verification confirmed decrypted counts matched expected values across synthetic configurations.
Noise Overhead: The bounded noise injection adds ~215k EVM gas and ~162k HCU per query, representing <1% of total query cost at $N=500$ .

Significance and Claims

The paper positions bioETH-Beacon as a research prototype, not a production-ready clinical deployment. Its primary significance lies in demonstrating that:

Confidential genomic querying is feasible on a public blockchain using FHE without a designated trusted compute evaluator.
The "double-disclosure" problem of traditional Beacons can be addressed by keeping queries and results encrypted, with decryption restricted to the authorized requester via an off-chain KMS.
A tiered approach allows consortiums to balance privacy requirements against computational costs (e.g., using T5 for dense, high-query workloads where marker presence is not sensitive).

The authors explicitly state that the system does not eliminate the trust assumption of the off-chain KMS and does not provide formal differential privacy. It serves as a foundational building block for future confidential genomic data sharing where neither the host nor the requester can be fully trusted.