🧬 biology

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

bioETH-Beacon est un prototype de contrat intelligent qui permet des requêtes de type beacon génomique confidentielles et sur chaîne avec des décomptes chiffrés et un bruit borné sur une machine virtuelle Ethereum entièrement homomorphe (fhEVM), éliminant ainsi le besoin d'un évaluateur de calcul de confiance tout en atténuant les risques de confidentialité tels que l'inférence d'appartenance et l'exposition des requêtes en clair.

Auteurs originaux : Christos Galanopoulos, Kimon Antonios Provatas, Ilias Georgakopoulos-Soares

Publié 2026-06-19

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Christos Galanopoulos, Kimon Antonios Provatas, Ilias Georgakopoulos-Soares

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ⚕️ Ceci est une explication générée par l'IA d'un preprint qui n'a pas été évalué par des pairs. Ce n'est pas un avis médical. Ne prenez pas de décisions de santé basées sur ce contenu. Lire la clause de non-responsabilité complète

Imaginez une immense bibliothèque mondiale d'informations génétiques. Dans cette bibliothèque, des chercheurs veulent poser des questions simples comme : « Est-ce que quelqu'un dans ce groupe de personnes a déjà été identifié avec cette erreur de frappe génétique spécifique ? »

Actuellement, si vous posez cette question, le bibliothécaire (l'hôpital qui détient les données) voit exactement ce que vous demandez et vous donne une réponse claire comme « Oui, 5 personnes ». Cela crée deux problèmes :

Le Bibliothécaire en Sait Trop : L'hôpital peut voir vos centres d'intérêt de recherche.
Le Problème du « Stalker » (Harceleur) : Si un chercheur pose des questions sur des erreurs très rares de manière répétée, il peut mathématiquement déterminer si une personne spécifique (comme une célébrité ou un voisin) fait partie du groupe, même sans connaître son nom.

bioETH-Beacon est une nouvelle « bibliothèque intelligente » expérimentale construite sur un type spécial de blockchain qui utilise le Chiffrement Entièrement Homomorphe (FHE). Considérez le FHE comme une boîte en verre magique et incassable. Vous pouvez placer des données à l'intérieur, effectuer des calculs dessus et obtenir un résultat, sans jamais ouvrir la boîte ni voir les données à l'intérieur.

Voici comment l'article explique ce système en utilisant des analogies simples :

1. La Boîte en Verre Magique (Le Système)

Au lieu d'un bibliothécaire humain, la bibliothèque utilise un Smart Contract (un programme informatique qui s'exécute automatiquement).

Les Hôpitaux (Propriétaires des données) placent leurs données génétiques dans la boîte en verre. Ils les chiffrent d'abord, de sorte que même l'hôpital ne puisse plus voir les chiffres une fois qu'ils sont à l'intérieur.
Les Chercheurs (Demandeurs) placent leurs questions dans la boîte. Ils chiffrent également la question pour que la boîte ne sache pas ce qu'elle recherche.
La Magie : La boîte effectue la recherche et le comptage pendant que tout est encore verrouillé à l'intérieur. Elle n'ouvre jamais la boîte pour lire les données.
Le Résultat : La boîte recrache une réponse chiffrée. Seul le chercheur spécifique qui a posé la question possède la clé pour déverrouiller cette réponse précise. L'hôpital, la blockchain et même l'ordinateur qui fait tourner la boîte ne voient jamais les données brutes ni le chiffre final.

2. Le Bruit « Anti-Stalker » (Protection de la Vie Privée)

L'article traite du « Problème du Stalker » (Inférence de l'appartenance à un groupe). Si un chercheur demande : « Y a-t-il une erreur rare ? » et obtient « 0 », il sait que cette personne n'est pas là. S'il obtient « 1 », il sait qu'elle l'est.

Pour empêcher cela, bioETH-Beacon ajoute du Bruit Borné à certaines réponses.

L'Analogie : Imaginez que la bibliothèque soit légèrement brumeuse. Si la vraie réponse est « 5 personnes », le système peut ajouter aléatoirement un peu de « statique » et vous dire « 6 » ou « 4 ».
Le Piège : L'article est très honnête à ce sujet : ce n'est pas un bouclier parfait. Si un harceleur pose la même question 20 fois, il pourra éventuellement obtenir la « vraie » réponse en cherchant le chiffre le plus bas. C'est pourquoi le système utilise aussi des Limites de Débit (comme un videur) pour empêcher quiconque de poser la même question trop souvent.
Note Importante : Cette fonction de « brume » n'est utilisée que pour certains types de questions (marqueurs génétiques et recherches complexes à filtres multiples). Pour des questions plus simples (comme les filtres d'âge ou de genre), le système donne le nombre exact, mais uniquement à des chercheurs approuvés et de confiance.

3. Les Trois Voies Rapides (Les Tiers)

L'article décrit une « grille 3x4 » de différentes manières d'exécuter la recherche, jouant sur l'équilibre entre Vie Privée et Vitesse/Coût.

Voie 1 (T3 - L'Or Standard) : La recherche examine chaque donnée une par une. Tout est caché. C'est la plus privée, mais c'est la plus longue (et elle coûte le plus de « gas », qui est la commission pour utiliser la blockchain).
Voie 2 (T4 - La Boîte Plus Fine) : La recherche examine toujours tout, mais elle utilise un conteneur de nombres plus petit et plus léger. C'est légèrement plus rapide sur un réseau réel, mais le fonctionnement est identique.
Voie 3 (T5 - Les Étagères Pré-groupées) : C'est la voie rapide. Avant que la recherche ne commence, la bibliothèque organise les données en 20 « étagères » (emplacements) prédéfinies. Le chercheur demande : « Combien y en a-t-il sur l'étagère 3 ? ». Le système ne vérifie que ces 20 étagères, pas toute la bibliothèque.
- Le Compromis : Pour obtenir cette vitesse, le système doit révéler quelles étagères existent (c'est-à-dire quels marqueurs génétiques sont suivis), mais il garde toujours les comptages cachés. C'est excellent pour les données denses mais moins privé concernant ce qui est suivi.

4. La Super-Requête « Multi-Filtre »

Il existe un contrat spécial nommé « G1 » qui agit comme une super-recherche. Au lieu de poser trois questions séparées (« Est-elle de sexe féminin ? », « A-t-elle plus de 40 ans ? », « A-t-elle cette maladie ? »), vous pouvez poser une seule question complexe : « Trouvez des femmes de plus de 40 ans ayant cette maladie ».

Pourquoi c'est important : Si vous posiez ces trois questions séparément, quelqu'un pourrait assembler les réponses pour en apprendre davantage que prévu. Le contrat G1 effectue les trois vérifications en même temps à l'intérieur de la boîte en verre et vous donne une seule réponse chiffrée.

5. Ce que l'Article Dit Réellement (Le Réalité Check)

Les auteurs sont très clairs sur ce que ceci est et ce que ce n'est pas :

C'est un Prototype : Il s'agit d'un projet de recherche, pas d'un produit médical fini prêt à être utilisé par les hôpitaux demain.
Il Utilise des Données Synthétiques : Ils ont testé cela en utilisant des données fictives générées à partir de catalogues génétiques publics, et non des dossiers de patients réels.
Il Présente des Limites :
- Le « bruit de brume » n'est pas une garantie de confidentialité parfaite ; il rend simplement l'espionnage plus difficile.
- Si la base de données devient énorme (des millions de marqueurs), le système pourrait être perturbé par des « collisions » (deux erreurs différentes qui se ressemblent), ils doivent donc utiliser des conteneurs de nombres plus grands.
- Le système fait toujours confiance à un « Service de Gestion des Clés » (un tiers) pour distribuer les clés permettant de déverrouiller les réponses. Si ce tiers est piraté, la confidentialité est rompue.

Résumé

bioETH-Beacon est une expérience ingénieuse qui prouve que l'on peut effectuer une recherche génétique mondiale sur une blockchain publique sans que personne (pas même l'hôpital ou l'ordinateur) ne voie les données réelles ou les questions spécifiques. Il utilise une « boîte en verre » pour compter les éléments, ajoute un peu de « statique » pour dérouter les harceleurs, et propose différents réglages de vitesse selon le niveau de confidentialité requis. C'est une étape prometteuse vers la recherche médicale privée, mais cela reste encore une phase de test.

Résumé Technique : bioETH-Beacon

Énoncé du Problème

Le protocole Beacon de la Global Alliance for Genomics and Health (GA4GH) permet aux chercheurs de vérifier si des variants génomiques spécifiques existent au sein d'une cohorte et, éventuellement, de recevoir des décomptes agrégés. Cependant, les déploiements standards souffrent de deux lacunes critiques en matière de confidentialité :

Visibilité de l'Hôte : L'institution hôte observe toutes les requêtes en clair, y compris l'identité du chercheur, le variant spécifique interrogé et les décomptes retournés.
Inférence de l'Appartenance : Les chercheurs reçoivent des décomptes en clair, ce qui permet à des adversaires d'effectuer des requêtes répétées sur des variants rares. Par le biais de tests de rapport de vraisemblance, cela permet des attaques d'inférence d'appartenance qui peuvent confirmer la présence d'un individu spécifique dans la cohorte.

Bien que des mesures organisationnelles (confiance, gouvernance de l'accès, limitation de débit) puissent atténuer partiellement ces risques, le protocole lui-même ne comble pas ces lacunes.

Méthodologie

bioETH-Beacon est un prototype de recherche qui implémente la requête de « décompte agrégé » (aggregate count) de la GA4GH directement sur une machine virtuelle Ethereum à chiffrement totalement homomorphe (fhEVM), utilisant spécifiquement le coprocesseur TFHE de Zama. Le système opère entièrement dans le domaine chiffré, garantissant que ni l'hôte ni l'observateur de la blockchain ne puissent accéder aux données génomiques brutes ou au contenu des requêtes.

Architecture Centrale

Le système repose sur une architecture de contrat à deux couches :

Couche Publique (BeaconRegistry) : Gère les métadnées du jeu de données, les approbations des contributeurs, les politiques de limitation de débit et les engagements d'intégrité. Elle ne contient aucun état chiffré.
Couche Chiffrée (famille ConfidentialBeacon) : Stocke les tableaux chiffrés de marqueurs-comptages et exécute le noyau de balayage (scan kernel). Elle détient tout l'état génomique sous forme de ciphertext.

Niveaux d'Exécution et Familles de Requêtes

La conception est organisée selon une grille de 3×4 niveaux par famille de requêtes pour paramétrer le compromis entre confidentialité et coût computationnel :

Niveaux d'Exécution :
- T3 (Référence) : Balayage chiffré complet. Les identifiants de marqueurs, les valeurs de filtre et les décomptes sont tous chiffrés. Le coût évolue linéairement avec le nombre d'entrées téléchargées ( $\Theta(N)$ ).
- T4 (Optimisé pour la Largeur) : Réduit l'accumulateur de euint64 à euint32 pour réduire les coûts de profondeur de l'unité de calcul homomorphe (HCU), à condition que les décomptes tiennent sur 32 bits.
- T5 (Pré-agrégé) : Utilise un ensemble fixe de $M$ emplacements de marqueurs publics. Les contributeurs téléchargent les décomptes vers des emplacements spécifiques. Les requêtes scannent $M$ emplacements plutôt que $N$ entrées ( $\Theta(M)$ ), réduisant considérablement le gaz de la requête mais révélant quels marqueurs sont présents (bien que les décomptes restent chiffrés).
Familles de Requêtes :
- Génotype : Requête de base pour la présence de marqueurs.
- Sexe, Âge, Phénotype : Filtres catégoriels à axe unique (ex: 5 compartiments pour le sexe, 7 pour l'âge).
- G1 (Multi-filtre) : Un contrat unique évaluant un prédicat conjonctif à quatre voies (marqueur $\land$ sexe $\land$ âge $\land$ phénotype) en une seule requête chiffrée, empêchant la divulgation de décomptes intermédiaires à axe unique.

Mécanismes Clés

Noyau de Balayage Oblivieux : Le contrat effectue une chaîne FHE.eq (vérification d'égalité), FHE.select et FHE.add sur chaque entrée sans sortie précoce, garantissant une exécution en temps constant quel que soit le résultat de la requête.
Découpage (Chunking) : En raison des limites de profondeur séquentielle du coprocesseur FHE (5M d'unités), les balayages sont divisés en blocs. L'article identifie une taille de bloc empirique sûre de 29 entrées pour les accumulateurs euint64 (plafond analytique 37, déploiement recommandé 23).
Injection de Bruit Borné : Pour atténuer l'inférence d'appartenance, le système ajoute un bruit uniforme borné ( $\nu \sim \mathcal{U}\{0, \dots, B-1\}$ ) au résultat sur les chemins supportés (Génotype T3/T4/T5 et G1). Crucialement, ce bruit est échantillonné à l'intérieur du coprocesseur FHE, empêchant le coordinateur de choisir une injection de bruit nul. Il s'agit d'une fonctionnalité anti-probing, et non d'une garantie formelle de confidentialité différentielle.
Contrôle d'Accès : Le déchiffrement du résultat est délégué à un service de gestion de clés (KMS) hors ligne. Seul le demandeur nommé dans l'appel FHE.allow du contrat peut récupérer le décompte en clair.

Contributions Clés

Première Implémentation de Beacon sur fhEVM : Un prototype de contrat intelligent exécutant la primitive de décompte agrégé de Beacon entièrement sur des données chiffrées, masquant les identifiants de marqueurs, les décomptes et les valeurs de filtre (sauf en T5 où la présence de marqueurs est publique).
Espace de Conception 3×4 : Une grille structurée de 13 contrats déployés (12 dans la grille + 1 multi-filtre G1) offrant divers niveaux de confidentialité et de coût, du chiffrement complet (T3) à la recherche pré-agrégée (T5).
Injection de Bruit On-Chain : Un mécanisme pour ajouter du bruit borné à l'intérieur du coprocesseur FHE, empêchant la manipulation de la valeur du bruit par le coordinateur.
Invariants de Sécurité : Définition et vérification de 11 invariants de sécurité explicites à travers la suite de contrats, couvrant la confidentialité de l'état, les modèles d'exécution de requête et le contrôle d'accès.
Évaluation Empirique : Benchmarks sur des panels synthétiques dérivés du PGS Catalog (allant de 16 à 100 000 marqueurs) mesurant le gaz, le nombre de transactions et le temps de traitement.

Résultats

Scalabilité : Les coûts de téléchargement évoluent linéairement avec le nombre d'entrées non nulles ( $N$ ). Les coûts de requête pour T3/T4 évoluent linéairement avec $N$ , tandis que T5 reste plat par rapport à $N$ (dépendant de $M$ fixe).
Efficacité du Gaz : Dans un benchmark à $M=20$ $M = 20$ fixe avec $N=500$ $N = 500$ entrées :
- T5 a réduit le gaz de requête de 94 % (de ~24,9M à ~1,45M) et le gaz de téléchargement de 53 % par rapport à T3.
- T4 a montré des économies de gaz EVM négligeables dans les tests locaux mais offre une réduction de 24 % des coûts HCU sur un réseau réel.
Point de Croisement : Pour le panel P1K, T5 devient plus rentable que T3 pour le cycle de vie total du gaz (téléchargement + requête) lorsque $N$ dépasse environ 246–484 entrées, selon le ratio requête/téléchargement.
Exactitude : La vérification de bout en bout a confirmé que les décomptés déchiffrés correspondaient aux valeurs attendues à travers les configurations synthétiques.
Surcoût du Bruit : L'injection de bruit borné ajoute ~215k de gaz EVM et ~162k HCU par requête, représentant <1 % du coût total de la requête à $N=500$ .

Signification et Revendications

L'article positionne bioETH-Beacon comme un prototype de recherche, et non comme un déploiement clinique prêt pour la production. Sa signification principale réside dans la démonstration que :

La requête génomique confidentielle est réalisable sur une blockchain publique utilisant la FHE sans évaluateur de calcul de confiance désigné.
Le problème de la « double divulgation » des Beacons traditionnels peut être résolu en gardant les requêtes et les résultats chiffrés, le déchiffrement étant restreint au demandeur autorisé via un KMS hors ligne.
Une approche par paliers permet aux consortiums d'équilibrer les exigences de confidentialité et les coûts de calcul (par exemple, en utilisant T5 pour des charges de travail denses à haute fréquence de requête où la présence de marqueurs n'est pas sensible).

Les auteurs déclarent explicitement que le système ne supprime pas l'hypothèse de confiance du KMS hors ligne et ne fournit pas de confidentialité différentielle formelle. Il sert de bloc de construction fondamental pour le partage futur de données génomiques confidentielles où ni l'hôte ni le demandeur ne peuvent être pleinement approuvés.