Resumo Técnico: bioETH-Beacon

Declaração do Problema

O protocolo Beacon da Global Alliance for Genomics and Health (GA4GH) permite que pesquisadores consultem se variantes genômicas específicas existem em uma coorte e, opcionalmente, recebam contagens agregadas. No entanto, as implementações padrão sofrem de duas lacunas críticas de privacidade:

1. Visibilidade do Host: A instituição anfitriã observa todas as consultas em texto simples (plaintext), incluindo a identidade do pesquisador, a variante específica consultada e as contagens retornadas.
2. Inferência de Membro: Os pesquisadores recebem contagens em texto simples, o que permite que adversários realizem consultas repetidas sobre variantes raras. Através de testes de razão de verossimilhança, isso permite ataques de inferência de membro que podem confirmar a presença de um indivíduo específico na coorte.

Embora medidas organizacionais (confiança, governança de acesso, limitação de taxa) possam mitigar parcialmente esses riscos, o próprio protocolo não fecha essas lacunas.

Metodologia

O bioETH-Beacon é um protótipo de pesquisa que implementa a consulta de "contagem agregada" da GA4GH diretamente em uma Máquina Virtual Ethereum com Criptografia Totalmente Homomórfica (fhEVM), utilizando especificamente o coprocessador Zama TFHE. O sistema opera inteiramente dentro do domínio criptografado, garantindo que nem o host nem o observador da blockchain tenham acesso aos dados genômicos brutos ou ao conteúdo das consultas.

Arquitetura Central

O sistema é construído sobre uma arquitetura de contrato de duas camadas:

• Camada Pública (BeaconRegistry): Gerencia metadados do conjunto de dados, aprovações de contribuintes, políticas de limitação de taxa e compromissos de integridade. Não contém estado criptografado.
• Camada Criptografada (família ConfidentialBeacon): Armazena arrays criptografados de marcador-contagem e executa o kernel de varredura. Mantém todo o estado genômico em texto cifrado (ciphertext).

Níveis de Execução e Famílias de Consulta

O design é organizado em uma grade de 3×4 níveis por família de consulta para parametrizar o equilíbrio entre privacidade e custo computacional:

• Níveis de Execução:
  • T3 (Referência): Varredura totalmente criptografada. IDs de marcadores, valores de filtro e contagens são todos criptografados. O custo escala linearmente com o número de entradas carregadas ($\Theta(N)$).
  • T4 (Otimização de Largura): Estreita o acumulador de euint64 para euint32 para reduzir os custos de profundidade da Unidade de Computação Homomórfica (HCU), desde que as contagens caibam em 32 bits.
  • T5 (Pré-agregado): Utiliza um conjunto fixo de $M$ slots de marcadores públicos. Os contribuintes carregam contagens para slots específicos. As consultas varrem $M$ slots em vez de $N$ entradas ($\Theta(M)$), reduzindo significativamente o gas da consulta, mas revelando quais marcadores estão presentes (embora as contagens permaneçam criptografadas).
• Famílias de Consulta:
  • Genótipo: Consulta base para presença de marcador.
  • Sexo, Idade, Fenótipo: Filtros categóricos de eixo único (ex: 5 baldes para sexo, 7 para idade).
  • G1 (Multi-filtro): Um único contrato avaliando um predicado conjuntivo de quatro vias (marcador $\land$ sexo $\land$ idade $\land$ fenótipo) em uma única consulta criptografada, evitando a divulgação de contagens intermediárias de eixo único.

Mecanismos Principais

1. Kernel de Varredura Oblíqua: O contrato realiza uma cadeia de FHE.eq (verificação de igualdade), FHE.select e FHE.add sobre cada entrada sem saídas antecipadas, garantindo execução de tempo constante independentemente do resultado da consulta.
2. Fragmentação (Chunking): Devido aos limites de profundidade sequencial no coprocessador FHE (5M unidades), as varreduras são divididas em fragmentos. O artigo identifica um tamanho de fragmento empírico seguro de 29 entradas para acumuladores euint64 (teto analítico de 37, recomendado para implantação de 23).
3. Injeção de Ruído Limitada: Para mitigar a inferência de membro, o sistema adiciona ruído uniforme limitado ($\nu \sim \mathcal{U}\{0, \dots, B-1\}$) ao resultado nos caminhos suportados (Genótipo T3/T4/T5 e G1). Crucialmente, este ruído é amostrado dentro do coprocessador FHE, impedindo que o coordenador escolha a injeção de ruído zero. Esta é uma característica de anti-prospecção, não uma garantia formal de privacidade diferencial.
4. Controle de Acesso: A descriptografia do resultado é delegada a um Serviço de Gerenciamento de Chaves (KMS) off-chain. Apenas o solicitante nomeado na chamada FHE.allow do contrato pode recuperar a contagem em texto simples.

Principais Contribuições

1. Primeira Implementação de Beacon em fhEVM: Um protótipo de contrato inteligente executando a primitiva de contagem agregada do Beacon inteiramente em dados criptografados, ocultando IDs de marcadores, contagens e valores de filtro (exceto no T5, onde a presença do marcador é pública).
2. Espaço de Design 3×4: Um design estruturado de 13 contratos implantados (12 na grade + 1 multi-filtro G1) oferecendo variados níveis de privacidade e custo, desde criptografia total (T3) até busca pré-agregada (T5).
3. Injeção de Ruído On-Chain: Um mecanismo para adicionar ruído limitado dentro do coprocessador FHE, evitando a manipulação do valor do ruído pelo coordenador.
4. Invariantes de Segurança: Definição e verificação de 1s invariantes de segurança explícitas através da suíte de contratos, cobrindo privacidade de estado, padrões de execução de consulta e controle de acesso.
5. Avaliação Empírica: Benchmarks em painéis sintéticos derivados do PGS Catalog (variando de 16 a 100.000 marcadores) medindo gas, contagem de transações e tempo de execução (wall time).

Resultados

• Escalabilidade: Os custos de upload escalam linearmente com o número de entradas não nulas ($N$). Os custos de consulta para T3/T4 escalam linearmente com $N$, enquanto o T5 permanece constante em relação a $N$ (dependente de um $M$ fixo).
• Eficiência de Gas: Em um benchmark fixo de $M=20$ com $N=500$ entradas:
  • O T5 reduziu o gas de consulta em 94% (de ~24.9M para ~1.45M) e o gas de upload em 53% comparado ao T3.
  • O T4 mostrou economia de gas EVM negligível em testes locais, mas oferece uma redução de 24% nos custos de HCU em uma rede real.
• Ponto de Cruzamento: Para o painel P1K, o T5 torna-se mais econômico que o T3 para o ciclo de vida total de gas (upload + consulta) quando $N$ excede aproximadamente 246–484 entradas, dependendo da razão consulta-upload.
• Corretude: A verificação de ponta a ponta confirmou que as contagens descriptografadas correspondiam aos valores esperados em configurações sintéticas.
• Sobrecarga de Ruído: A injeção de ruído limitado adiciona ~215k de gas EVM e ~162k de HCU por consulta, representando <1% do custo total da consulta em $N=500$.

Significância e Alegações

O artigo posiciona o bioETH-Beacon como um protótipo de pesquisa, não uma implementação clínica pronta para produção. Sua principal significância reside em demonstrar que:

• A consulta genômica confidencial é viável em uma blockchain pública usando FHE sem um avaliador de computação confiável designado.
• O problema da "dupla divulgação" dos Beacons tradicionais pode ser abordado mantendo as consultas e os resultados criptografados, com a descriptografia restrita ao solicitante autorizado via um KMS off-chain.
• Uma abordagem em camadas permite que consórcios equilibrem requisitos de privacidade com custos computacionais (ex: usando T5 para cargas de trabalho densas e de alta consulta, onde a presença do marcador não é sensível).

Os autores afirmam explicitamente que o sistema não elimina a suposição de confiança do KMS off-chain e não fornece privacidade diferencial formal. Serve como um bloco de construção fundamental para o futuro compartilhamento de dados genômicos confidenciais, onde nem o host nem o solicitante podem ser totalmente confiáveis.