Resumen Técnico: bioETH-Beacon

Declaración del Problema

El protocolo Beacon de la Alianza Global para la Genómica y la Salud (GA4GH) permite a los investigadores consultar si existen variantes genómicas específicas dentro de una cohorte y, opcionalmente, recibir recuentos agregados. Sin embargo, las implementaciones estándar sufren dos brechas de privacidad críticas:

1. Visibilidad del Host: La institución anfitriona observa todas las consultas en texto plano, incluyendo la identidad del investigador, la variante específica consultada y los recuentos devueltos.
2. Inferencia de Membresía: Los investigadores reciben recuentos en texto plano, lo que permite a los adversarios realizar consultas repetidas sobre variantes raras. A través de pruebas de razón de verosimilitud, esto permite ataques de inferencia de membresía que pueden confirmar la presencia de un individuo específico en la cohorte.

Si bien las medidas organizativas (confianza, gobernanza de acceso, limitación de tasa) pueden mitigar parcialmente estos riesgos, el protocolo en sí mismo no cierra estas brechas.

Metodología

bioETH-Beacon es un prototipo de investigación que implementa la consulta de "recuento agregado" de GA4GH directamente en una Máquina Virtual Ethereum con Computación Totalmente Homomórfica (fhEVM), utilizando específicamente el coprocesador TFHE de Zama. El sistema opera enteramente dentro del dominio cifrado, asegurando que ni el host ni el observador de la blockchain puedan acceder a los datos genómicos brutos o al contenido de las consultas.

Arquitectura Central

El sistema se construye sobre una arquitectura de contratos de dos capas:

• Capa Pública (BeaconRegistry): Gestiona los metad datos del conjunto de datos, las aprobaciones de los contribuyentes, las políticas de limitación de tasa y los compromisos de integridad. No contiene estado cifrado.
• Capa Cifrada (familia ConfidentialBeacon): Almacena arreglos de marcador-recuento cifrados y ejecuta el kernel de escaneo. Contiene todo el estado genómico en forma de texto cifrado.

Niveles de Ejecución y Familias de Consultas

El diseño está organizado en una rejilla de 3×4 niveles por familia de consultas para parametrizar el compromiso entre privacidad y costo computacional:

• Niveles de Ejecución:
  • T3 (Referencia): Escaneo cifrado completo. Los IDs de los marcadores, los valores de filtro y los recuentos están todos cifrados. El costo escala linealmente con el número de entradas cargadas ($\Theta(N)$).
  • T4 (Optimización de Ancho): Reduce el acumulador de euint64 a euint32 para reducir los costos de profundidad de la Unidad de Computación Homomórfica (HCU), siempre que los recuentos quepan en 32 bits.
  • T5 (Pre-agregado): Utiliza un conjunto fijo de $M$ ranuras de marcadores públicos. Los contribuyentes cargan recuentos en ranuras específicas. Las consultas escanean $M$ ranuras en lugar de $N$ entradas ($\Theta(M)$), lo que reduce significativamente el gas de la consulta pero revela qué marcadores están presentes (aunque los recuentos permanecen cifrados).
• Familias de Consultas:
  • Genotipo: Consulta base para la presencia de marcadores.
  • Sexo, Edad, Fenotipo: Filtros categóricos de un solo eje (por ejemplo, 5 cubetas para sexo, 7 para edad).
  • G1 (Multi-filtro): Un único contrato que evalúa un predicado conjuntivo de cuatro vías (marcador $\land$ sexo $\land$ edad $\land$ fenotipo) en una sola consulta cifrada, evitando la divulgación de recuentos intermedios de un solo eje.

Mecanismos Clave

1. Kernel de Escaneo Oblivioso: El contrato realiza una cadena de FHE.eq (verificación de igualdad), FHE.select y FHE.add sobre cada entrada sin salidas tempranas, asegurando una ejecución de tiempo constante independientemente del resultado de la consulta.
2. Fragmentación (Chunking): Debido a los límites de profundidad secuencial en el coprocesador FHE (5M unidades), los escaneos se dividen en fragmentos. El artículo identifica un tamaño de fragmento empírico seguro de 29 entradas para acumuladores euint64 (techo analítico 37, recomendado para despliegue 23).
3. Inyección de Ruido Acotado: Para mitigar la inferencia de membresía, el sistema añade ruido uniforme acotado ($\nu \sim \mathcal{U}\{0, \dots, B-1\}$) al resultado en las rutas soportadas (Genotipo T3/T4/T5 y G1). Crucialmente, este ruido se muestrea dentro del coprocesador FHE, evitando que el coordinador elija la inyección de ruido cero. Esta es una característica anti-sondeo, no una garantía formal de privacidad diferencial.
4. Control de Acceso: La desencriptación del resultado se delega a un Servicio de Gestión de Claves (KMS) fuera de la cadena. Solo el solicitante nombrado en la llamada FHE.allow del contrato puede recuperar el recuento en texto plano.

Contribuciones Clave

1. Primera Implementación de Beacon en fhEVM: Un prototipo de contrato inteligente que ejecuta la primitiva de recuento agregado de Beacon enteramente sobre datos cifrados, ocultando los IDs de los marcadores, los recuentos y los valores de filtro (excepto en T5 donde la presencia del marcador es pública).
2. Espacio de Diseño 3×4: Una rejilla estructurada de 13 contratos desplegados (12 en la rejilla + 1 multi-filtro G1) que ofrecen diversos niveles de privacidad y costo, desde el cifrado total (T3) hasta la búsqueda pre-agregada (T5).
3. Inyección de Ruido On-Chain: Un mecanismo para añadir ruido acotado dentro del coprocesador FHE, evitando la manipulación del valor del ruido por parte del coordinador.
4. Invariantes de Seguridad: Definición y verificación de 11 invariantes de seguridad explícitos a través de la suite de contratos, que cubren la privacidad del estado, los patrones de ejecución de consultas y el control de acceso.
5. Evaluación Empírica: Benchmarks en paneles sintéticos derivados del PGS Catalog (que oscilan entre 16 y 100,000 marcadores) midiendo gas, recuento de transacciones y tiempo de ejecución (wall time).

Resultados

• Escalabilidad: Los costos de carga escalan linealmente con el número de entradas no nulas ($N$). Los costos de consulta para T3/T4 escalan linealmente con $N$, mientras que T5 permanece plano respecto a $N$ (dependiente de un $M$ fijo).
• Eficiencia de Gas: En un benchmark de $M$ fijo = 20 con $N=500$ entradas:
  • T5 redujo el gas de consulta en un 94% (de ~24.9M a ~1.45M) y el gas de carga en un 53% comparado con T3.
  • T4 mostró una reducción insignificante en el gas de la EVM en pruebas locales, pero ofrece una reducción del 24% en los costos de HCU en una red real.
• Punto de Cruce: Para el panel P1K, T5 resulta más rentable que T3 para el gas del ciclo de vida total (carga + consulta) cuando $N$ supera aproximadamente 246–484 entradas, dependiendo de la relación consulta-carga.
• Correctitud: La verificación de extremo a extremo confirmó que los recuentos desencriptados coincidían con los valores esperados a través de configuraciones sintéticas.
• Sobrecarga de Ruido: La inyección de ruido acotado añade ~215k de gas de EVM y ~162k de HCU por consulta, lo que representa <1% del costo total de la consulta en $N=500$.

Significancia y Reivindicaciones

El artículo posiciona a bioETH-Beacon como un prototipo de investigación, no como un despliegue clínico listo para producción. Su principal significancia radica en demostrar que:

• La consulta genómica confidencial es factible en una blockchain pública utilizando FHE sin un evaluador de cómputo designado de confianza.
• El problema de la "doble divulgación" de los Beacons tradicionales puede abordarse manteniendo las consultas y los resultados cifrados, restringiendo la desencriptación al solicitante autorizado mediante un KMS fuera de la cadena.
• Un enfoque por niveles permite a los consorcios equilibrar los requisitos de privacidad frente a los costos computacionales (por ejemplo, usando T5 para cargas de trabajo densas y de alta consulta donde la presencia del marcador no es sensible).

Los autores declaran explícitamente que el sistema no elimina el supuesto de confianza del KMS fuera de la cadena y no proporciona privacidad diferencial formal. Sirve como un bloque de construcción fundamental para el futuro intercambio de datos genómicos confidenciales donde ni el host ni el solicitante pueden ser plenamente confiables.