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

Riepilogo Tecnico: bioETH-Beacon

Problema

Il protocollo Beacon della Global Alliance for Genomics and Health (GA4GH) consente ai ricercatori di interrogare se varianti genomiche specifiche esistano all'interno di una coorte e, opzionalmente, di riceverne i conteggi aggregati. Tuttavia, le implementazioni standard soffrono di due lacune critiche di privacy:

1. Visibilità dell'Host: L'istituzione ospitante osserva tutte le query in chiaro, inclusi l'identità del ricercatore, la variante specifica interrogata e i conteggi restituiti.
2. Inferenza di Appartenenza (Membership Inference): I ricercatori ricevono conteggi in chiaro, il che consente agli avversari di eseguire query ripetute su varianti rare. Attraverso test di rapporto di verosimiglianza, ciò consente attacchi di inferenza di appartenenza che possono confermare la presenza di un individuo specifico nella coorte.

Sebbene le misure organizzative (fiducia, governance dell'accesso, limitazione del tasso) possano mitigare parzialmente questi rischi, il protocollo stesso non colma queste lacune.

Metodologia

bioETH-Beacon è un prototipo di ricerca che implementa la query "aggregate count" della GA4GH direttamente su una Ethereum Virtual Machine con FHE (fhEVM), utilizzando specificamente il coprocessore Zama TFHE. Il sistema opera interamente all'interno del dominio criptato, garantendo che né l'host né l'osservatore della blockchain possano accedere ai dati genomici grezzi o al contenuto delle query.

Architettura Core

Il sistema è costruito su un'architettura di contratto a due livelli:

• Livello Pubblico (BeaconRegistry): Gestisce i metadati del dataset, le approvazioni dei contributori, le policy di limitazione del tasso e gli impegni di integrità. Non contiene stato criptato.
• Livello Criptato (famiglia ConfidentialBeacon): Memorizza array di marker-count criptati ed esegue il kernel di scansione. Contiene tutto lo stato genomico in forma di ciphertext.

Tier di Esecuzione e Famiglie di Query

Il design è organizzato in una griglia 3×4 tra tier e famiglie di query per parametrizzare il compromesso tra privacy e costo computazionale:

• Tier di Esecuzione:
  • T3 (Riferimento): Scansione criptata completa. ID dei marker, valori di filtro e conteggi sono tutti criptati. Il costo scala linearmente con il numero di voci caricate ($\Theta(N)$).
  • T4 (Ottimizzato per la Larghezza): Restringe l'accumulatore da euint64 a euint32 per ridurre i costi di profondità dell'Unità di Computazione Omoformica (HCU), a condizione che i conteggi rientrino nei 32 bit.
  • T5 (Pre-aggregato): Utilizza un set fisso di $M$ slot di marker pubblici. I contributori caricano i conteggi in slot specifici. Le query scansionano $M$ slot invece di $N$ voci ($\Theta(M)$), riducendo significativamente il gas della query ma rivelando quali marker sono presenti (sebbene i conteggi rimangano criptati).
• Famiglie di Query:
  • Genotipo: Query base per la presenza di marker.
  • Sesso, Età, Fenotipo: Filtri categorici a singolo asse (es. 5 bucket per il sesso, 7 per l'età).
  • G1 (Multi-filtro): Un singolo contratto che valuta un predicato congiuntivo a quattro vie (marker $\land$ sesso $\land$ età $\land$ fenotipo) in una singola query criptata, impedendo la divulgazione di conteggi intermedi a singolo asse.

Meccanismi Chiave

1. Kernel di Scansione Oblivious: Il contratto esegue una catena di FHE.eq (controllo di uguaglianza), FHE.select e FHE.add su ogni voce senza uscite anticipate, garantendo un'esecuzione a tempo costante indipendentemente dal risultato della query.
2. Chunking (Frammentazione): A causa dei limiti di profondità sequenziale del coprocessore FHE (5M unità), le scansioni sono suddivise in chunk. Il documento identifica una dimensione di chunk empirica sicura di 29 voci per accumulatori euint64 (tetto analitico 37, raccomandazione di deployment 23).
3. Iniezione di Rumore Limitata: Per mitigare l'inferenza di appartenenza, il sistema aggiunge rumore uniforme limitato ($\nu \sim \mathcal{U}\{0, \dots, B-1\}$) al risultato sui percorsi supportati (Genotipo T3/T4/T5 e G1). Fondamentalmente, questo rumore viene campionato dent'interno del coprocessore FHE, impedendo al coordinatore di scegliere l'iniezione di rumore zero. Questa è una funzione anti-probing, non una garanzia formale di differential privacy.
4. Controllo dell'Accesso: La decrittazione del risultato è delegata a un servizio di gestione delle chiavi (KMS) off-chain. Solo il richiedente nominato nella chiamata FHE.allow del contratto può recuperare il conteggio in chiaro.

Contributi Chiave

1. Prima Implementazione Beacon su fhEVM: Un prototipo di smart contract che esegue la primitiva di conteggio aggregato del Beacon interamente su dati criptati, nascondendo ID dei marker, conteggi e valori di filtro (eccetto in T5 dove la presenza del marker è pubblica).
2. Design Spazio 3×4: Una struttura di 13 contratti implementati (12 nella griglia + 1 multi-filtro G1) che offrono vari livelli di privacy e costo, dalla crittografia completa (T3) alla ricerca pre-aggregata (T5).
3. Iniezione di Rumore On-Chain: Un meccanismo per aggiungere rumore limitato all'interno del coprocessore FHE, impedendo la manipolazione del valore del rumore da parte del coordinatore.
4. Invarianti di Sicurezza: Definizione e verifica di 11 invarianti di sicurezza espliciti attraverso la suite di contratti, che coprono la privacy dello stato, i pattern di esecuzione delle query e il controllo dell'accesso.
5. Valutazione Empirica: Benchmark su pannelli sintetici derivati dal PGS Catalog (da 16 a 100.000 marker) misurando gas, conteggi delle transazioni e tempo di esecuzione (wall time).

Risultati

• Scalabilità: I costi di upload scalano linearmente con il numero di voci non nulle ($N$). I costi di query per T3/T4 scalano linearmente con $N$, mentre T5 rimane costante rispetto a $N$ (dipendente da $M$ fisso).
• Efficienza del Gas: In un benchmark fisso con $M=20$ e $N=500$ voci:
  • T5 ha ridotto il gas della query del 94% (da ~24.9M a ~1.45M) e il gas di upload del 53% rispetto a T3.
  • T4 ha mostrato risparmi di gas EVM trascurabili nei test locali, ma offre una riduzione del 24% dei costi HCU su una rete live.
• Punto di Incrocio (Crossover Point): Per il pannello P1K, T5 diventa più conveniente di T3 per il gas del ciclo di vita totale (upload + query) quando $N$ supera circa 246–484 voci, a seconda del rapporto query-upload.
• Correttezza: La verifica end-to-end ha confermato che i conteggi decriptati corrispondevano ai valori attesi attraverso configurazioni sintetiche.
• Overhead del Rumore: L'iniezione di rumore limitato aggiunge circa 215k di gas EVM e ~162k di HCU per query, rappresentando <1% del costo totale della query a $N=500$.

Significatività e Rivendicazioni

Il documento posiziona bioETH-Beacon come un prototipo di ricerca, non come un deployment clinico pronto per la produzione. La sua principale significatività risiede nel dimostrare che:

• L'interrogazione genomica riservata è fattibile su una blockchain pubblica utilizzando FHE senza un valutatore di calcolo designato e fidato.
• Il problema della "doppia divulgazione" dei Beacon tradizionali può essere affrontato mantenendo query e risultati criptati, con la decrittazione limitata al richiedente autorizzato tramite un KMS off-chain.
• Un approccio a livelli permette ai consorzi di bilanciare i requisiti di privacy rispetto ai costi computazionali (ad esempio, utilizzando T5 per carichi di lavoro densi e ad alta frequenza di query dove la presenza del marker non è sensibile).

Gli autori dichiarano esplicitamente che il sistema non elimina l'assunzione di fiducia del KMS off-chain e non fornisce una differential privacy formale. Esso funge da blocco costruttivo fondamentale per la futura condivisione di dati genomici riservati, dove né l'host né il richiedente possono essere pienamente fidati.