Blockchains públicas oferecem transparência e integridade ao custo da privacidade – cada transação e estado de contrato são expostos a todos os participantes. Essa abertura cria problemas como ataques de MEV (Miner Extractable Value), copy-trading e vazamento de lógica de negócios sensível. A privacidade programável visa resolver esses problemas permitindo computações em dados privados sem revelar os próprios dados. Dois paradigmas criptográficos emergentes estão tornando isso possível: Máquinas Virtuais de Criptografia Totalmente Homomórfica (FHE-VM) e Coprocessadores de Conhecimento Zero (ZK). Essas abordagens permitem computação off-chain ou criptografada com verificação on-chain, preservando a confidencialidade enquanto mantêm a correção trustless. Neste relatório, mergulhamos fundo nas arquiteturas FHE-VM e ZK-coprocessor, comparamos seus trade-offs e exploramos casos de uso em finanças, identidade, saúde, mercados de dados e aprendizado de máquina descentralizado.
Máquina Virtual de Criptografia Totalmente Homomórfica (FHE-VM)
A Criptografia Totalmente Homomórfica (FHE) permite computações arbitrárias em dados criptografados sem nunca descriptografá-los. Uma Máquina Virtual FHE integra essa capacidade em contratos inteligentes de blockchain, permitindo estado e lógica de contrato criptografados. Em uma blockchain habilitada para FHE (frequentemente chamada de fhEVM para designs compatíveis com EVM), todas as entradas, armazenamento de contrato e saídas permanecem criptografados durante toda a execução. Isso significa que os validadores podem processar transações e atualizar o estado sem aprender nenhum valor sensível, alcançando a execução on-chain com confidencialidade de dados.
Arquitetura e Design da FHE-VM
Uma FHE-VM típica estende um tempo de execução de contrato inteligente padrão (como a Ethereum Virtual Machine) com suporte nativo para tipos de dados e operações criptografadas. Por exemplo, a FHEVM da Zama introduz inteiros criptografados (euint8, euint32, etc.), booleanos criptografados (ebool) e até mesmo arrays criptografados como tipos de primeira classe. Linguagens de contrato inteligente como Solidity são aumentadas por meio de bibliotecas ou novos opcodes para que os desenvolvedores possam realizar operações aritméticas (add, mul, etc.), lógicas e comparações diretamente em textos cifrados. Nos bastidores, essas operações invocam primitivas FHE (por exemplo, usando a biblioteca TFHE) para manipular bits criptografados e produzir resultados criptografados.
O armazenamento de estado criptografado é suportado para que as variáveis do contrato permaneçam criptografadas no estado da blockchain. O fluxo de execução é tipicamente:
- Criptografia do Lado do Cliente: Os usuários criptografam suas entradas localmente usando a chave FHE pública antes de enviar transações. A chave de criptografia é pública (para criptografia e avaliação), enquanto a chave de descriptografia permanece secreta. Em alguns designs, cada usuário gerencia sua própria chave; em outros, uma única chave FHE global é usada (discutido abaixo).
- Computação Homomórfica On-Chain: Mineradores/validadores executam o contrato com opcodes criptografados. Eles realizam as mesmas operações homomórficas determinísticas nos textos cifrados, para que o consenso possa ser alcançado sobre o novo estado criptografado. Crucialmente, os validadores nunca veem dados em texto claro – eles apenas veem texto cifrado "sem sentido", mas ainda podem processá-lo de forma consistente.
- Descriptografia (Opcional): Se um resultado precisar ser revelado ou usado off-chain, uma parte autorizada com a chave privada pode descriptografar o texto cifrado de saída. Caso contrário, os resultados permanecem criptografados e podem ser usados como entradas para transações futuras (permitindo computações consecutivas em estado criptografado persistente).
Uma consideração de design importante é o gerenciamento de chaves. Uma abordagem é de chaves por usuário, onde cada usuário detém sua chave secreta e apenas eles podem descriptografar saídas relevantes para eles. Isso maximiza a privacidade (ninguém mais pode descriptografar seus dados), mas as operações homomórficas não podem misturar dados criptografados sob chaves diferentes sem protocolos complexos de múltiplas chaves. Outra abordagem, usada pela FHEVM da Zama, é uma chave FHE global: uma única chave pública criptografa todos os dados do contrato e um conjunto distribuído de validadores detém partes da chave de descriptografia de limiar. As chaves públicas de criptografia e avaliação são publicadas on-chain, para que qualquer pessoa possa criptografar dados para a rede; a chave privada é dividida entre os validadores que podem descriptografar coletivamente, se necessário, sob um esquema de limiar. Para evitar que a conivência de validadores comprometa a privacidade, a Zama emprega um protocolo FHE de limiar (baseado em sua pesquisa Noah’s Ark) com "inundação de ruído" para tornar as descriptografias parciais seguras. Apenas se um quórum suficiente de validadores cooperar, um texto claro pode ser recuperado, por exemplo, para atender a uma solicitação de leitura. Em operação normal, no entanto, nenhum nó único jamais vê o texto claro – os dados permanecem criptografados on-chain o tempo todo.
O controle de acesso é outro componente crucial. As implementações de FHE-VM incluem controles refinados para gerenciar quem (se houver alguém) pode acionar descriptografias ou acessar certos campos criptografados. Por exemplo, a fhEVM da Cypher suporta Listas de Controle de Acesso em textos cifrados, permitindo que os desenvolvedores especifiquem quais endereços ou contratos podem interagir ou recriptografar certos dados. Alguns frameworks suportam recriptografia: a capacidade de transferir um valor criptografado da chave de um usuário para a de outro sem expor o texto claro. Isso é útil para coisas como mercados de dados, onde um proprietário de dados pode criptografar um conjunto de dados com sua chave e, após a compra, recriptografá-lo para a chave do comprador – tudo on-chain, sem nunca descriptografar publicamente.
Garantindo Correção e Privacidade
Alguém pode perguntar: se todos os dados são criptografados, como garantimos a correção da lógica do contrato? Como a cadeia pode impedir operações inválidas se não consegue "ver" os valores? A FHE por si só não fornece uma prova de correção – os validadores podem realizar os passos homomórficos, mas não podem inerentemente dizer se a entrada criptografada de um usuário era válida ou se um desvio condicional deveria ser tomado, etc., sem descriptografar. Provas de conhecimento zero (ZKPs) podem complementar a FHE para resolver essa lacuna. Em uma FHE-VM, tipicamente os usuários devem fornecer uma prova ZK atestando certas condições de texto claro sempre que necessário. O design da Zama, por exemplo, usa uma Prova ZK de Conhecimento de Texto Claro (ZKPoK) para acompanhar cada entrada criptografada. Isso prova que o usuário conhece o texto claro correspondente ao seu texto cifrado e que ele atende aos critérios esperados, sem revelar o próprio texto claro. Tais "textos cifrados certificados" impedem que um usuário mal-intencionado envie uma criptografia malformada ou um valor fora do intervalo. Da mesma forma, para operações que exigem uma decisão (por exemplo, garantir que o saldo da conta ≥ valor do saque), o usuário pode fornecer uma prova ZK de que essa condição é verdadeira nos textos claros antes que a operação criptografada seja executada. Dessa forma, a cadeia não descriptografa ou vê os valores, mas ganha confiança de que as transações criptografadas seguem as regras.
Outra abordagem em rollups FHE é realizar validação off-chain com ZKPs. A Fhenix (um rollup L2 usando FHE) opta por um modelo otimista onde um componente de rede separado chamado Rede de Serviço de Limiar pode descriptografar ou verificar resultados criptografados, e qualquer computação incorreta pode ser contestada com uma prova de fraude. Em geral, combinar FHE + ZK ou provas de fraude garante que a execução criptografada permaneça trustless. Os validadores ou descriptografam coletivamente apenas quando autorizados, ou verificam provas de que cada transição de estado criptografada foi válida sem precisar ver o texto claro.
Considerações de desempenho: As operações FHE são computacionalmente pesadas – muitas ordens de magnitude mais lentas que a aritmética normal. Por exemplo, uma simples adição de 64 bits no Ethereum custa ~3 gas, enquanto uma adição em um inteiro criptografado de 64 bits (euint64) na FHEVM da Zama custa aproximadamente 188.000 gas. Mesmo uma adição de 8 bits pode custar ~94k gas. Essa enorme sobrecarga significa que uma implementação direta em nós existentes seria impraticavelmente lenta e cara. Projetos de FHE-VM enfrentam isso com bibliotecas criptográficas otimizadas (como a biblioteca TFHE-rs da Zama para bootstrapping de portões binários) e modificações personalizadas na EVM para desempenho. Por exemplo, o cliente Geth modificado da Cypher adiciona novos opcodes e otimiza a execução de instruções homomórficas em C++/assembly para minimizar a sobrecarga. No entanto, alcançar uma taxa de transferência utilizável requer aceleração. O trabalho em andamento inclui o uso de GPUs, FPGAs e até mesmo chips fotônicos especializados para acelerar as computações FHE. A Zama relata que seu desempenho FHE melhorou 100x desde 2024 e está visando milhares de TPS com aceleração de GPU/FPGA. Servidores coprocessadores FHE dedicados (como o LightLocker Node da Optalysys) podem ser conectados a nós validadores para descarregar operações criptografadas para hardware, suportando >100 transferências ERC-20 criptografadas por segundo por nó. À medida que o hardware e os algoritmos melhoram, a lacuna entre FHE e computação em texto claro diminuirá, permitindo que contratos privados se aproximem de velocidades mais práticas.
Compatibilidade: Um objetivo chave dos designs de FHE-VM é permanecer compatível com os fluxos de trabalho de desenvolvimento existentes. As implementações fhEVM da Cypher e da Zama permitem que os desenvolvedores escrevam contratos em Solidity com mudanças mínimas – usando uma biblioteca para declarar tipos e operações criptografadas. O resto do conjunto de ferramentas do Ethereum (Remix, Hardhat, etc.) ainda pode ser usado, pois as modificações subjacentes estão principalmente no nível do cliente/nó. Isso diminui a barreira de entrada: os desenvolvedores não precisam ser especialistas em criptografia para escrever um contrato inteligente confidencial. Por exemplo, uma simples adição de dois números pode ser escrita como euint32 c = a + b; e a FHEVM cuidará dos detalhes específicos da criptografia nos bastidores. Os contratos podem até interoperar com contratos normais – por exemplo, um contrato criptografado poderia produzir um resultado descriptografado para um contrato padrão, se desejado, permitindo uma mistura de partes privadas e públicas em um ecossistema.
Projetos FHE-VM Atuais: Vários projetos são pioneiros neste espaço. A Zama (uma startup de FHE sediada em Paris) desenvolveu o conceito central da FHEVM e bibliotecas (TFHE-rs e uma biblioteca fhevm-solidity). Eles não pretendem lançar sua própria cadeia, mas sim fornecer infraestrutura para outros. A Inco é uma blockchain L1 (construída no Cosmos SDK com Evmos) que integrou a FHEVM da Zama para criar uma cadeia confidencial modular. Suas testnets (chamadas Gentry e Paillier) demonstram transferências ERC-20 criptografadas e outras primitivas DeFi privadas. A Fhenix é um rollup otimista de Camada 2 do Ethereum usando FHE para privacidade. Ela decidiu por uma abordagem otimista (prova de fraude) em vez de ZK-rollup devido ao alto custo de fazer FHE e ZK juntos para cada bloco. A Fhenix usa a mesma biblioteca TFHE-rs (com algumas modificações) e introduz uma Rede de Serviço de Limiar para lidar com descriptografias de forma descentralizada. Existem também equipes independentes como a Fhenix (agora rebatizada) e startups explorando híbridos MPC + FHE. Além disso, a Cypher (da Z1 Labs) está construindo uma rede de Camada 3 focada em IA e privacidade, usando uma fhEVM com recursos como cofres secretos e suporte a aprendizado federado. O ecossistema é nascente, mas está crescendo rapidamente, impulsionado por financiamento significativo – por exemplo, a Zama se tornou um "unicórnio" com mais de US$ 130 milhões arrecadados até 2025 para avançar a tecnologia FHE.
Em resumo, uma FHE-VM permite contratos inteligentes que preservam a privacidade ao executar toda a lógica em dados criptografados on-chain. Este paradigma garante confidencialidade máxima – nada sensível é exposto em transações ou estado – enquanto aproveita o consenso de blockchain existente para integridade. O custo é o aumento da carga computacional sobre os validadores e a complexidade no gerenciamento de chaves e na integração de provas. A seguir, exploramos um paradigma alternativo que descarrega a computação totalmente off-chain e usa a cadeia apenas para verificação: o coprocessador de conhecimento zero.
Coprocessadores de Conhecimento Zero (ZK-Coprocessors)
Um coprocessador ZK é um novo padrão de arquitetura de blockchain onde computações caras são realizadas off-chain, e uma prova de conhecimento zero sucinta de sua correção é verificada on-chain. Isso permite que contratos inteligentes aproveitem um poder computacional e dados muito maiores do que a execução on-chain permitiria, sem sacrificar a natureza trustless. O termo coprocessador é usado por analogia aos coprocessadores de hardware (como um coprocessador matemático ou GPU) que lidam com tarefas especializadas para uma CPU. Aqui, a "CPU" da blockchain (a VM nativa como a EVM) delega certas tarefas a um sistema de prova de conhecimento zero que atua como um coprocessador criptográfico. O coprocessador ZK retorna um resultado e uma prova de que o resultado foi calculado corretamente, que o contrato on-chain pode verificar e então usar.
Arquitetura e Fluxo de Trabalho
Em uma configuração típica, um desenvolvedor de dApp identifica partes da lógica de sua aplicação que são muito caras ou complexas para execução on-chain (por exemplo, grandes computações sobre dados históricos, algoritmos pesados, inferência de modelos de ML, etc.). Eles implementam essas partes como um programa off-chain (em uma linguagem de alto nível ou DSL de circuito) que pode produzir uma prova de conhecimento zero de sua execução. O componente on-chain é um contrato inteligente verificador que verifica as provas e disponibiliza os resultados para o resto do sistema. O fluxo pode ser resumido como:
- Requisição – O contrato on-chain aciona uma requisição para que uma certa computação seja feita off-chain. Isso pode ser iniciado por uma transação de usuário ou por um contrato chamando a interface do coprocessador ZK. Por exemplo, um contrato DeFi pode chamar “provarTaxaDeJuros(estadoAtual)” ou um usuário chama “consultarDadosHistoricos(consulta)”.
- Execução e Prova Off-Chain – Um serviço off-chain (que pode ser uma rede descentralizada de provadores ou um serviço confiável, dependendo do design) pega a requisição. Ele reúne todos os dados necessários (estado on-chain, entradas off-chain, etc.) e executa a computação em uma Máquina Virtual ZK (ZKVM) especial ou circuito. Durante a execução, um traço de prova é gerado. No final, o serviço produz uma prova sucinta (por exemplo, um SNARK ou STARK) atestando que “Computar a função F na entrada X resulta na saída Y” e, opcionalmente, atestando a integridade dos dados (mais sobre isso abaixo).
- Verificação On-Chain – A prova e o resultado são retornados para a blockchain (geralmente por meio de uma função de callback). O contrato verificador verifica a validade da prova usando verificação criptográfica eficiente (verificações de emparelhamento, etc.). Se válida, o contrato pode agora confiar na saída Y como correta. O resultado pode ser armazenado no estado, emitido como um evento ou alimentado em lógica de contrato adicional. Se a prova for inválida ou não for fornecida dentro de algum tempo, a requisição pode ser considerada falha (e potencialmente alguma lógica de fallback ou timeout é acionada).
Figura 1: Arquitetura de um Coprocessador ZK (exemplo do RISC Zero Bonsai). Off-chain, um programa é executado em uma ZKVM com entradas da chamada do contrato inteligente. Uma prova de execução é retornada on-chain por meio de um contrato de retransmissão, que invoca um callback com os resultados verificados.
Criticamente, o custo de gas on-chain para verificação é constante (ou cresce muito lentamente), independentemente de quão complexa foi a computação off-chain. Verificar uma prova sucinta pode custar na ordem de algumas centenas de milhares de gas (uma fração de um bloco do Ethereum), mas essa prova pode representar milhões de passos computacionais feitos off-chain. Como um desenvolvedor brincou, “Quer provar uma assinatura digital? ~$15. Quer provar um milhão de assinaturas? Também ~$15.”. Essa escalabilidade é uma grande vitória: dApps podem oferecer funcionalidades complexas (análise de big data, modelos financeiros elaborados, etc.) sem sobrecarregar a blockchain.
Os principais componentes de um sistema de coprocessador ZK são:
-
Ambiente de Geração de Prova: Pode ser uma ZKVM de propósito geral (capaz de executar programas arbitrários) ou circuitos personalizados adaptados a computações específicas. As abordagens variam:
- Alguns projetos usam circuitos feitos à mão para cada consulta ou função suportada (maximizando a eficiência para essa função).
- Outros fornecem uma Linguagem Específica de Domínio (DSL) ou uma DSL Embutida que os desenvolvedores usam para escrever sua lógica off-chain, que é então compilada em circuitos (equilibrando facilidade de uso e desempenho).
- A abordagem mais flexível é uma zkVM: uma máquina virtual (geralmente baseada em arquiteturas RISC) onde programas podem ser escritos em linguagens padrão (Rust, C, etc.) e automaticamente provados. Isso sacrifica o desempenho (simular uma CPU em um circuito adiciona sobrecarga) pela máxima experiência do desenvolvedor.
-
Acesso e Integridade de Dados: Um desafio único é alimentar a computação off-chain com os dados corretos, especialmente se esses dados residem na blockchain (blocos passados, estados de contrato, etc.). Uma solução ingênua é fazer com que o provador leia de um nó de arquivo e confie nele – mas isso introduz suposições de confiança. Em vez disso, os coprocessadores ZK normalmente provam que quaisquer dados on-chain usados eram de fato autênticos, vinculando-se a provas de Merkle ou compromissos de estado. Por exemplo, o programa de consulta pode pegar um número de bloco e uma prova de Merkle de um slot de armazenamento ou transação, e o circuito verificará essa prova contra um hash de cabeçalho de bloco conhecido. Existem três padrões:
- Dados Inline: Colocar os dados necessários on-chain (como entrada para o verificador) para que possam ser verificados diretamente. Isso é muito caro para grandes volumes de dados e mina todo o propósito.
- Confiar em um Oráculo: Ter um serviço de oráculo alimentando os dados para a prova e atestando por eles. Isso é mais simples, mas reintroduz a confiança em um terceiro.
- Provar a Inclusão de Dados via ZK: Incorporar provas de inclusão de dados no histórico da cadeia dentro do próprio circuito de conhecimento zero. Isso aproveita o fato de que cada cabeçalho de bloco do Ethereum se compromete com todo o estado anterior (via raiz de estado) e histórico de transações. Ao verificar provas de Merkle Patricia dos dados dentro do circuito, a prova de saída garante ao contrato que “esta computação usou dados genuínos da blockchain do bloco N” sem necessidade de confiança adicional.
A terceira abordagem é a mais trustless e é usada por coprocessadores ZK avançados como Axiom e Xpansion (aumenta o custo de prova, mas é preferível por segurança). Por exemplo, o sistema da Axiom modela a estrutura de blocos do Ethereum, a trie de estado e a trie de transações dentro de seus circuitos, para que possa provar declarações como “a conta X tinha saldo Y no bloco N” ou “uma transação com certas propriedades ocorreu no bloco N”. Ele aproveita o fato de que, dado um hash de bloco confiável recente, pode-se provar recursivamente a inclusão de dados históricos sem confiar em nenhuma parte externa.
-
Contrato Verificador: Este contrato on-chain contém a chave de verificação e a lógica para aceitar ou rejeitar provas. Para SNARKs como Groth16 ou PLONK, o verificador pode fazer alguns emparelhamentos de curva elíptica; para STARKs, pode fazer alguns cálculos de hash. Otimizações de desempenho como agregação e recursão podem minimizar a carga on-chain. Por exemplo, o Bonsai da RISC Zero usa um wrapper STARK-para-SNARK: ele executa uma VM baseada em STARK off-chain para velocidade, mas depois gera uma pequena prova SNARK atestando a validade do STARK. Isso reduz o tamanho da prova de centenas de kilobytes para algumas centenas de bytes, tornando a verificação on-chain viável e barata. O verificador Solidity então apenas verifica o SNARK (que é uma operação de tempo constante).
Em termos de implantação, os coprocessadores ZK podem funcionar como redes semelhantes a camada-2 ou como serviços puramente off-chain. Alguns, como a Axiom, começaram como um serviço especializado para o Ethereum (com o apoio da Paradigm), onde os desenvolvedores enviam consultas para a rede de provadores da Axiom e obtêm provas on-chain. O slogan da Axiom era fornecer aos contratos do Ethereum “acesso trustless a todos os dados on-chain e computação expressiva arbitrária sobre eles.” Ele efetivamente atua como um oráculo de consulta onde as respostas são verificadas por ZKPs em vez de confiança. Outros, como o Bonsai da RISC Zero, oferecem uma plataforma mais aberta: qualquer desenvolvedor pode enviar um programa (compilado para uma ZKVM compatível com RISC-V) e usar o serviço de prova do Bonsai por meio de um contrato de retransmissão. O padrão de retransmissão, como ilustrado na Figura 1, envolve um contrato que media requisições e respostas: o contrato do dApp chama o retransmissor para pedir uma prova, o serviço off-chain escuta isso (por exemplo, via evento ou chamada direta), computa a prova, e então o retransmissor invoca uma função de callback no contrato do dApp com o resultado e a prova. Este modelo assíncrono é necessário porque a prova pode levar de segundos a minutos, dependendo da complexidade. Ele introduz uma latência (e uma suposição de liveness de que o provador responderá), enquanto as computações FHE-VM acontecem sincronicamente dentro de um bloco. Projetar a aplicação para lidar com esse fluxo de trabalho assíncrono (possivelmente semelhante às respostas de Oráculo) faz parte do uso de um coprocessador ZK.
Projetos Notáveis de Coprocessador ZK
-
Axiom: A Axiom é um coprocessador ZK adaptado para o Ethereum, focado originalmente em provar consultas de dados on-chain históricos. Ele usa o framework de prova Halo2 (um SNARK do tipo Plonk) para criar provas que incorporam as estruturas criptográficas do Ethereum. No sistema da Axiom, um desenvolvedor pode consultar coisas como “qual era o estado do contrato X no bloco N?” ou realizar uma computação sobre todas as transações em um intervalo. Nos bastidores, os circuitos da Axiom tiveram que implementar a lógica de estado/trie do Ethereum, até mesmo realizando operações de curva elíptica e verificação de SNARK dentro do circuito para suportar recursão. A Trail of Bits, em uma auditoria, notou a complexidade dos circuitos Halo2 da Axiom modelando blocos e estados inteiros. Após a auditoria, a Axiom generalizou sua tecnologia em uma OpenVM, permitindo que código Rust arbitrário fosse provado com a mesma infraestrutura baseada em Halo2. (Isso reflete a tendência de passar de circuitos específicos de domínio para uma abordagem ZKVM mais geral.) A equipe da Axiom demonstrou consultas ZK que o Ethereum nativamente não pode fazer, permitindo acesso sem estado a quaisquer dados históricos com integridade criptográfica. Eles também enfatizaram a segurança, capturando e corrigindo bugs de circuito sub-restringidos e garantindo a solidez. Embora o produto inicial da Axiom tenha sido descontinuado durante sua mudança de foco, sua abordagem permanece um marco nos coprocessadores ZK.
-
RISC Zero Bonsai: A RISC Zero é uma ZKVM baseada na arquitetura RISC-V. Sua zkVM pode executar programas arbitrários (escritos em Rust, C++ e outras linguagens compiladas para RISC-V) e produzir uma prova STARK de execução. O Bonsai é o serviço em nuvem da RISC Zero que fornece essa prova sob demanda, atuando como um coprocessador para contratos inteligentes. Para usá-lo, um desenvolvedor escreve um programa (digamos, uma função que realiza matemática complexa ou verifica uma resposta de API off-chain), o envia para o serviço Bonsai e implanta um contrato verificador correspondente. Quando o contrato precisa dessa computação, ele chama o retransmissor Bonsai, que aciona a geração da prova e retorna o resultado via callback. Uma aplicação de exemplo demonstrada foi a computação de governança off-chain: a RISC Zero mostrou uma DAO usando o Bonsai para contar votos e computar métricas de votação complexas off-chain, e então postar uma prova para que o contrato Governor on-chain pudesse confiar no resultado com custo mínimo de gas. A tecnologia da RISC Zero enfatiza que os desenvolvedores podem usar paradigmas de programação familiares – por exemplo, escrever uma função em Rust para computar algo – e o trabalho pesado de criação de circuitos é tratado pela zkVM. No entanto, as provas podem ser grandes, então, como observado anteriormente, eles implementaram uma compressão SNARK para verificação on-chain. Em agosto de 2023, eles verificaram com sucesso provas da RISC Zero na testnet Sepolia do Ethereum, custando na ordem de 300k de gas por prova. Isso abre as portas para que dApps do Ethereum usem o Bonsai hoje como uma solução de escalabilidade e privacidade. (O Bonsai ainda está em alfa, não pronto para produção, e usa uma configuração SNARK temporária sem uma cerimônia.)
-
Outros: Existem vários outros players e iniciativas de pesquisa. A Expansion/Xpansion (como mencionado em um blog) usa uma abordagem de DSL embutida, onde os desenvolvedores podem escrever consultas sobre dados on-chain com uma linguagem especializada, e ela lida com a geração de provas internamente. O Cairo da StarkWare e o zkEVM da Polygon são VMs de ZK-rollup mais gerais, mas sua tecnologia poderia ser reaproveitada para uso semelhante a coprocessadores, verificando provas dentro de contratos L1. Também vemos projetos no domínio ZKML (ZK Machine Learning), que efetivamente atuam como coprocessadores para verificar a inferência de modelos de ML ou resultados de treinamento on-chain. Por exemplo, uma configuração zkML pode provar que “uma inferência de rede neural em entradas privadas produziu a classificação X” sem revelar as entradas ou fazer a computação on-chain. Estes são casos especiais do conceito de coprocessador aplicado à IA.
Suposições de confiança: Os coprocessadores ZK dependem da solidez das provas criptográficas. Se o sistema de prova for seguro (e qualquer configuração confiável for feita honestamente), então uma prova aceita garante que a computação foi correta. Nenhuma confiança adicional no provador é necessária – mesmo um provador mal-intencionado não pode convencer o verificador de uma declaração falsa. No entanto, existe uma suposição de liveness: alguém deve realmente realizar a computação off-chain e produzir a prova. Na prática, isso pode ser uma rede descentralizada (com incentivos ou taxas para fazer o trabalho) ou um único operador de serviço. Se ninguém fornecer a prova, a requisição on-chain pode permanecer não resolvida. Outro aspecto sutil de confiança é a disponibilidade de dados para entradas off-chain que não estão na blockchain. Se a computação depende de alguns dados privados ou externos, o verificador não pode saber se esses dados foram fornecidos honestamente, a menos que medidas adicionais (como compromissos de dados ou assinaturas de oráculo) sejam usadas. Mas para computações de dados puramente on-chain, os mecanismos descritos garantem uma natureza trustless equivalente à própria cadeia (a Axiom argumentou que suas provas oferecem "segurança criptograficamente equivalente ao Ethereum" para consultas históricas).
Privacidade: Provas de conhecimento zero também suportam inerentemente a privacidade – o provador pode manter as entradas ocultas enquanto prova declarações sobre elas. Em um contexto de coprocessador, isso significa que uma prova pode permitir que um contrato use um resultado que foi derivado de dados privados. Por exemplo, uma prova pode mostrar “a pontuação de crédito do usuário > 700, então aprove o empréstimo” sem revelar a pontuação de crédito real ou os dados brutos. O caso de uso da Axiom era mais sobre dados publicamente conhecidos (histórico da blockchain), então a privacidade não era o foco lá. Mas a zkVM da RISC Zero poderia ser usada para provar asserções sobre dados secretos fornecidos por um usuário: os dados permanecem off-chain e apenas o resultado necessário vai para on-chain. Vale a pena notar que, ao contrário da FHE, uma prova ZK geralmente não fornece confidencialidade contínua do estado – é uma prova única. Se um fluxo de trabalho precisa manter um estado secreto entre transações, pode-se construí-lo fazendo com que o contrato armazene um compromisso com o estado e cada prova mostrando uma transição de estado válida do compromisso antigo para o novo, com os segredos ocultos. É essencialmente assim que os zk-rollups para transações privadas (como Aztec ou Zcash) funcionam. Portanto, os coprocessadores ZK podem facilitar máquinas de estado totalmente privadas, mas a implementação não é trivial; muitas vezes eles são usados para computações únicas onde a entrada ou a saída (ou ambas) podem ser privadas conforme necessário.
Experiência do desenvolvedor: Usar um coprocessador ZK geralmente requer o aprendizado de novas ferramentas. Escrever circuitos personalizados (opção (1) acima) é bastante complexo e geralmente feito apenas para fins específicos. Opções de nível superior como DSLs ou zkVMs facilitam a vida, mas ainda adicionam sobrecarga: o desenvolvedor deve escrever e implantar código off-chain e gerenciar a interação. Em contraste com a FHE-VM, onde a criptografia é principalmente tratada nos bastidores e o desenvolvedor escreve código de contrato inteligente normal, aqui o desenvolvedor precisa particionar sua lógica e possivelmente escrever em uma linguagem diferente (Rust, etc.) para a parte off-chain. No entanto, iniciativas como as DSLs Noir, Leo, Circom ou a abordagem da RISC Zero estão melhorando rapidamente a acessibilidade. Por exemplo, a RISC Zero fornece modelos e integração com o Foundry para que um desenvolvedor possa simular seu código off-chain localmente (para correção) e depois conectá-lo perfeitamente a testes em Solidity por meio do callback do Bonsai. Com o tempo, podemos esperar frameworks de desenvolvimento que abstraiam se uma parte da lógica é executada via prova ZK ou on-chain – o compilador ou as ferramentas podem decidir com base no custo.
FHE-VM vs Coprocessador ZK: Comparação
Tanto as FHE-VMs quanto os coprocessadores ZK permitem uma forma de “computação em dados privados com garantia on-chain”, mas diferem fundamentalmente em arquitetura. A tabela abaixo resume as principais diferenças:
| Aspecto | FHE-VM (Execução Criptografada On-Chain) - | Coprocessador ZK (Prova Off-Chain) - |
|---|
| Onde a computação acontece | Diretamente on-chain (todos os nós executam operações homomórficas em textos cifrados). - | Off-chain (um provador ou rede executa o programa; apenas uma prova é verificada on-chain). - |
| Confidencialidade dos dados | Criptografia total: os dados permanecem criptografados o tempo todo on-chain; os validadores nunca veem o texto claro. Apenas os detentores das chaves de descriptografia podem descriptografar as saídas. - | Conhecimento zero: as entradas privadas do provador nunca são reveladas on-chain; a prova não revela segredos além do que está nas saídas públicas. No entanto, quaisquer dados usados na computação que devam afetar o estado on-chain devem ser codificados na saída ou no compromisso. Os segredos permanecem off-chain por padrão. - |
| Modelo de confiança | Confiança na execução por consenso e na criptografia: se a maioria dos validadores seguir o protocolo, a execução criptografada é determinística e correta. Nenhuma confiança externa é necessária para a correção da computação (todos os nós a recomputam). Deve-se confiar na segurança do esquema FHE (geralmente baseada na dificuldade de problemas de reticulado) para a privacidade. Em alguns designs, também se confia que não ocorrerá conluio de validadores suficientes para usar indevidamente as chaves de limiar. - | Confiança na segurança do sistema de prova (solidez do SNARK/STARK). Se a prova for verificada, o resultado é correto com certeza criptográfica. Os provadores off-chain não podem enganar a matemática. Há uma suposição de liveness sobre os provadores para realmente fazerem o trabalho. Se estiver usando uma configuração confiável (por exemplo, SRS de SNARK), deve-se confiar que ela foi gerada honestamente ou usar sistemas transparentes/sem configuração. - |
| Custo on-chain e escalabilidade | Alto custo por transação: As operações homomórficas são extremamente caras computacionalmente, e cada nó deve realizá-las. Os custos de gas são altos (por exemplo, mais de 100k de gas para uma única adição de 8 bits). Contratos complexos são limitados pelo que cada validador pode computar em um bloco. A taxa de transferência é muito menor do que a de contratos inteligentes normais, a menos que hardware especializado seja empregado. A escalabilidade é melhorada por criptografia mais rápida e aceleração de hardware, mas fundamentalmente cada operação aumenta a carga de trabalho da cadeia. - | Baixo custo de verificação: Verificar uma prova sucinta é eficiente e de tamanho constante, então o gas on-chain é modesto (centenas de milhares de gas para qualquer tamanho de computação). Isso desvincula a complexidade dos limites de recursos on-chain – grandes computações não têm custo extra on-chain. Assim, ele escala em termos de carga on-chain. Off-chain, o tempo de prova pode ser significativo (minutos ou mais para tarefas enormes) e pode exigir máquinas poderosas, mas isso não desacelera diretamente a blockchain. A taxa de transferência geral pode ser alta, desde que as provas possam ser geradas a tempo (potenciais redes de provadores paralelas). - |
| Latência | Os resultados estão disponíveis imediatamente na mesma transação/bloco, já que a computação ocorre durante a execução. Sem viagens de ida e volta adicionais – operação síncrona. No entanto, um tempo de processamento de bloco mais longo pode aumentar a latência da blockchain se as operações FHE forem lentas. - | Inerentemente assíncrono. Geralmente requer uma transação para solicitar e uma transação posterior (ou callback) para fornecer a prova/resultado. Isso introduz um atraso (possivelmente de segundos a horas, dependendo da complexidade da prova e do hardware de prova). Não é adequado para finalidade instantânea de uma única transação – mais como um modelo de trabalho assíncrono. - |
| Garantias de privacidade | Forte: Tudo (entradas, saídas, estado intermediário) pode permanecer criptografado on-chain. Você pode ter um estado criptografado de longa duração que várias transações atualizam sem nunca revelá-lo. Apenas ações de descriptografia autorizadas (se houver) revelam saídas, e estas podem ser controladas por chaves/ACLs. No entanto, considerações de canal lateral como uso de gas ou logs de eventos devem ser gerenciadas para que não vazem padrões (designs de fhEVM buscam execução alheia aos dados com gas constante para operações para evitar vazamentos). - | Seletiva: A prova revela o que quer que esteja nas saídas públicas ou seja necessário para verificar (por exemplo, um compromisso com o estado inicial). Os designers podem garantir que apenas o resultado pretendido seja revelado, e todas as outras entradas permaneçam ocultas com conhecimento zero. Mas, ao contrário da FHE, a blockchain normalmente não armazena o estado oculto – a privacidade é alcançada mantendo os dados totalmente off-chain. Se um estado privado persistente for necessário, o contrato pode armazenar um compromisso criptográfico com ele (para que as atualizações de estado ainda revelem um novo compromisso a cada vez). A privacidade é limitada pelo que você escolhe provar; você tem flexibilidade para provar, por exemplo, que um limiar foi atingido sem revelar valores exatos. - |
| Aplicação da integridade | Por design, todos os validadores recomputam o próximo estado homomorficamente, então se um ator mal-intencionado fornecer um resultado de texto cifrado errado, outros detectarão uma incompatibilidade – o consenso falha a menos que todos obtenham o mesmo resultado. Assim, a integridade é aplicada por execução redundante (como na blockchain normal, apenas em dados criptografados). Provas ZK adicionais são frequentemente usadas para aplicar regras de negócio (por exemplo, o usuário não pôde violar uma restrição) porque os validadores não podem verificar diretamente as condições de texto claro. - | A integridade é aplicada pelo contrato verificador que verifica a prova ZK. Desde que a prova seja verificada, o resultado é garantido como consistente com alguma execução válida do programa off-chain. Nenhuma suposição de maioria honesta é necessária para a correção – mesmo um único verificador honesto (o próprio código do contrato) é suficiente. O contrato on-chain simplesmente rejeitará qualquer prova falsa ou ausente (semelhante a como rejeitaria uma assinatura inválida). Uma consideração: se o provador abortar ou atrasar, o contrato pode precisar de lógica de fallback (ou os usuários podem precisar tentar novamente mais tarde), mas não aceitará resultados incorretos. - |
| Experiência do desenvolvedor | Prós: Pode usar em grande parte linguagens de contrato inteligente familiares (Solidity, etc.) com extensões. A confidencialidade é tratada pela plataforma – os desenvolvedores se preocupam principalmente com o que criptografar e quem detém as chaves. A composição de contratos criptografados e normais é possível, mantendo a composabilidade do DeFi (apenas com variáveis criptografadas). Contras: Deve entender as limitações da FHE – por exemplo, sem saltos condicionais diretos em dados secretos sem tratamento especial, profundidade de circuito limitada (embora o bootstrapping em TFHE permita computação de comprimento arbitrário ao custo de tempo). Depurar lógica criptografada pode ser complicado, pois não se pode inspecionar facilmente os valores em tempo de execução sem a chave. Além disso, o gerenciamento de chaves e permissões adiciona complexidade ao design do contrato. | Prós: Potencialmente usar qualquer linguagem de programação para a parte off-chain (especialmente com uma zkVM). Aproveitar código/bibliotecas existentes no programa off-chain (com ressalvas para compatibilidade com ZK). Nenhuma criptografia personalizada necessária pelo desenvolvedor se estiver usando uma ZKVM geral – eles escrevem código normal e obtêm uma prova. Além disso, a computação pesada pode usar bibliotecas (por exemplo, código de aprendizado de máquina) que nunca seriam executadas on-chain. Contras: Os desenvolvedores devem orquestrar a infraestrutura off-chain ou usar um serviço de prova. Lidar com fluxos de trabalho assíncronos e integrá-los com a lógica on-chain requer mais trabalho de design (por exemplo, armazenar um estado pendente, esperar por um callback). Escrever circuitos eficientes ou código zkVM pode exigir o aprendizado de novas restrições (por exemplo, sem ponto flutuante, usar ponto fixo ou primitivas especiais; evitar ramificações pesadas que aumentam o tempo de prova; otimizar para contagem de restrições). Há também o fardo de lidar com falhas de prova, timeouts, etc., que não são preocupações no Solidity regular. O ecossistema de ferramentas está crescendo, mas é um novo paradigma para muitos. |
Ambas as abordagens estão sendo ativamente aprimoradas, e até vemos convergência: como observado, ZKPs são usados dentro de FHE-VMs para certas verificações e, inversamente, alguns pesquisadores propõem o uso de FHE para manter as entradas do provador privadas em ZK (para que um provador na nuvem não veja seus dados secretos). É concebível que sistemas futuros as combinem – por exemplo, realizando FHE off-chain e depois provando a correção disso para a cadeia, ou usando FHE on-chain, mas provando com ZK para clientes leves que as operações criptografadas foram feitas corretamente. Cada técnica tem seus pontos fortes: a FHE-VM oferece privacidade contínua e interação em tempo real ao custo de computação pesada, enquanto os coprocessadores ZK oferecem escalabilidade e flexibilidade ao custo de latência e complexidade.
Casos de Uso e Implicações
O advento da privacidade programável desbloqueia uma riqueza de novas aplicações de blockchain em várias indústrias. Abaixo, exploramos como FHE-VMs e coprocessadores ZK (ou híbridos) podem capacitar vários domínios, permitindo contratos inteligentes que preservam a privacidade e uma economia de dados segura.
DeFi Confidencial e Finanças
Em finanças descentralizadas, a privacidade pode mitigar o front-running, proteger estratégias de negociação e satisfazer a conformidade sem sacrificar a transparência onde necessário. O DeFi Confidencial poderia permitir que os usuários interagissem com protocolos sem revelar suas posições para o mundo.
-
Transações Privadas e Saldos Ocultos: Usando FHE, pode-se implementar transferências de tokens confidenciais (saldos e transações ERC-20 criptografados) ou pools blindados em uma L1 de blockchain. Nenhum observador pode ver quanto de um token você possui ou transferiu, eliminando o risco de ataques direcionados com base em participações. Provas ZK podem garantir que os saldos permaneçam sincronizados e que não ocorra gasto duplo (semelhante ao Zcash, mas em plataformas de contrato inteligente). Um exemplo é um AMM (Criador de Mercado Automatizado) confidencial onde as reservas do pool e as negociações são criptografadas on-chain. Arbitragistas ou front-runners não podem explorar o pool porque não conseguem observar o slippage de preço até que a negociação seja liquidada, reduzindo o MEV. Apenas após algum atraso ou por meio de um mecanismo de controle de acesso, alguns dados podem ser revelados para auditoria.
-
Leilões e Negociações Resistentes a MEV: Mineradores e bots exploram a transparência das transações para fazer front-run em negociações. Com criptografia, você poderia ter um mempool criptografado ou leilões em lote onde as ordens são enviadas em texto cifrado. Apenas depois que o leilão é concluído, as negociações são descriptografadas. Este conceito, às vezes chamado de Fluxo de Ordens Justo, pode ser alcançado com descriptografia de limiar (vários validadores descriptografam coletivamente o lote) ou provando os resultados do leilão via ZK sem revelar lances individuais. Por exemplo, um coprocessador ZK poderia pegar um lote de lances selados off-chain, computar o preço de compensação do leilão e produzir apenas esse preço e os vencedores com provas. Isso preserva a justiça e a privacidade dos lances perdedores.
-
Empréstimos e Derivativos Confidenciais: Em empréstimos DeFi, os usuários podem não querer revelar o tamanho de seus empréstimos ou garantias (isso pode afetar o sentimento do mercado ou convidar à exploração). Uma FHE-VM pode manter um livro de empréstimos criptografado onde os detalhes de cada empréstimo são criptografados. A lógica do contrato inteligente ainda pode aplicar regras como condições de liquidação, operando em fatores de saúde criptografados. Se a proporção de garantia de um empréstimo cair abaixo do limiar, o contrato (com a ajuda de provas ZK) pode sinalizá-lo para liquidação sem nunca expor valores exatos – ele pode apenas produzir um sinalizador sim/não em texto claro. Da mesma forma, posições secretas de derivativos ou opções poderiam ser gerenciadas on-chain, com apenas métricas de risco agregadas reveladas. Isso poderia impedir o copy trading e proteger estratégias proprietárias, incentivando mais participação institucional.
-
Privacidade em Conformidade: Nem todos os contextos financeiros desejam anonimato total; às vezes, a divulgação seletiva é necessária para regulamentação. Com essas ferramentas, podemos alcançar a privacidade regulamentada: por exemplo, as negociações são privadas para o público, mas uma bolsa regulamentada pode descriptografar ou receber provas sobre certas propriedades. Poder-se-ia provar via ZK que “esta negociação não envolveu um endereço na lista negra e ambas as partes são verificadas por KYC” sem revelar identidades para a cadeia. Esse equilíbrio poderia satisfazer as regras de Combate à Lavagem de Dinheiro (AML), mantendo as identidades e posições dos usuários confidenciais para todos os outros. A FHE poderia permitir que um contrato de oficial de conformidade on-chain examinasse transações criptografadas em busca de sinais de risco (com uma chave de descriptografia acessível apenas sob ordem judicial, por exemplo).
Identidade Digital e Dados Pessoais
Os sistemas de identidade têm muito a ganhar com a tecnologia de privacidade on-chain. Atualmente, colocar credenciais ou atributos pessoais em um livro-razão público é impraticável devido às leis de privacidade e à relutância do usuário. Com FHE e ZK, a identidade auto-soberana pode ser realizada de forma a preservar a privacidade:
-
Credenciais de Conhecimento Zero: Usando provas ZK (já comuns em alguns projetos de identidade), um usuário pode provar declarações como “Tenho mais de 18 anos”, “Tenho uma carteira de motorista válida” ou “Ganho acima de $50k (para pontuação de crédito)” sem revelar nenhuma outra informação pessoal. Os coprocessadores ZK podem aprimorar isso lidando com verificações mais complexas off-chain, por exemplo, provando que a pontuação de crédito de um usuário está acima de um limiar, consultando um banco de dados de crédito privado de maneira semelhante à Axiom, produzindo apenas um sim/não para a blockchain.
-
KYC Confidencial em DeFi: Imagine um protocolo DeFi que, por lei, deve garantir que os usuários sejam verificados por KYC. Com a FHE-VM, as credenciais de um usuário podem ser armazenadas criptografadas on-chain (ou referenciadas via DID), e um contrato inteligente pode realizar uma computação FHE para verificar se as informações de KYC atendem aos requisitos. Por exemplo, um contrato poderia verificar homomorficamente se nome e CPF em um perfil de usuário criptografado correspondem a uma lista de usuários sancionados (também criptografada), ou se o país do usuário não é restrito. O contrato obteria apenas um "aprovado/reprovado" criptografado que pode ser descriptografado por limiar pelos validadores da rede para um sinalizador booleano. Apenas o fato de o usuário ser permitido ou não é revelado, preservando a confidencialidade das PII e alinhando-se com os princípios do GDPR. Essa divulgação seletiva garante conformidade e privacidade.
-
Acesso Baseado em Atributos e Divulgação Seletiva: Os usuários poderiam manter um conjunto de credenciais verificáveis (idade, cidadania, habilidades, etc.) como atributos criptografados. Eles podem autorizar certos dApps a executar computações sobre eles sem divulgar tudo. Por exemplo, um DApp de recrutamento descentralizado poderia filtrar candidatos realizando pesquisas em currículos criptografados (usando FHE) – por exemplo, contar anos de experiência, verificar uma certificação – e somente se uma correspondência for encontrada, contatar o candidato off-chain. Os detalhes privados do candidato permanecem criptografados, a menos que ele escolha revelar. As provas ZK também podem permitir que os usuários provem seletivamente que possuem uma combinação de atributos (por exemplo, mais de 21 anos e dentro de um determinado CEP) sem revelar os valores reais.
-
Verificação de Identidade Multi-Partes: Às vezes, a identidade de um usuário precisa ser verificada por várias partes (digamos, verificação de antecedentes pela empresa A, verificação de crédito pela empresa B). Com ferramentas homomórficas e ZK, cada verificador poderia contribuir com uma pontuação ou aprovação criptografada, e um contrato inteligente pode agregá-las a uma decisão final sem expor as contribuições individuais. Por exemplo, três agências fornecem bits "aprovado/reprovado" criptografados, e o contrato produz uma aprovação se todos os três forem aprovados – o usuário ou a parte interessada só vê o resultado final, não qual agência específica pode tê-lo reprovado, preservando a privacidade do registro do usuário em cada agência. Isso pode reduzir o viés e o estigma associados, por exemplo, a uma verificação falha revelando um problema específico.
Saúde e Compartilhamento de Dados Sensíveis
Os dados de saúde são altamente sensíveis e regulamentados, mas a combinação de dados de várias fontes pode desbloquear um valor imenso (para pesquisa, seguros, medicina personalizada). A blockchain poderia fornecer uma camada de confiança para a troca de dados se a privacidade for resolvida. Contratos inteligentes confidenciais poderiam permitir novos ecossistemas de dados de saúde:
-
Troca Segura de Dados Médicos: Os pacientes poderiam armazenar referências a seus registros médicos on-chain de forma criptografada. Um contrato habilitado para FHE poderia permitir que uma instituição de pesquisa executasse análises em um coorte de dados de pacientes sem descriptografá-los. Por exemplo, um contrato poderia calcular a eficácia média de um medicamento em resultados de pacientes criptografados. Apenas resultados estatísticos agregados saem descriptografados (e talvez apenas se um número mínimo de pacientes for incluído, para evitar a reidentificação). Os pacientes poderiam receber micropagamentos por contribuir com seus dados criptografados para pesquisa, sabendo que sua privacidade é preservada porque até mesmo a blockchain e os pesquisadores só veem texto cifrado ou provas agregadas. Isso fomenta um mercado de dados para a saúde que respeita a privacidade.
-
Processamento de Sinistros de Seguro Preservando a Privacidade: O processamento de sinistros de seguro de saúde poderia ser automatizado por meio de contratos inteligentes que verificam condições em dados médicos sem expor os dados à seguradora. Um sinistro poderia incluir um código de diagnóstico criptografado e um custo de tratamento criptografado; o contrato, usando FHE, verifica as regras da apólice (por exemplo, cobertura, franquia) nesses dados criptografados. Ele poderia produzir uma aprovação e um valor de pagamento sem nunca revelar o diagnóstico real para a blockchain da seguradora (apenas o paciente e o médico tinham a chave). Provas ZK poderiam ser usadas para mostrar que os dados do paciente vieram dos registros de um hospital certificado (usando algo como a Axiom para verificar a assinatura ou a inclusão de registro de um hospital) sem revelar o registro em si. Isso garante a privacidade do paciente enquanto previne fraudes.
-
Computação de Dados Genômicos e Pessoais: Dados genômicos são extremamente sensíveis (são literalmente o projeto do DNA de uma pessoa). No entanto, a análise de genomas pode fornecer insights valiosos sobre a saúde. As empresas poderiam usar a FHE-VM para realizar computações em genomas criptografados enviados pelos usuários. Por exemplo, um contrato inteligente poderia executar um modelo de risco gene-ambiente em dados genômicos criptografados e dados ambientais criptografados (de wearables, talvez), produzindo uma pontuação de risco que apenas o usuário pode descriptografar. A lógica (talvez um algoritmo de pontuação de risco poligênico) é codificada no contrato e executada homomorficamente, para que os dados genômicos nunca apareçam em texto claro. Dessa forma, os usuários obtêm insights sem fornecer às empresas dados brutos de DNA – mitigando preocupações tanto de privacidade quanto de propriedade de dados.
-
Epidemiologia e Saúde Pública: Durante situações como pandemias, o compartilhamento de dados é vital para modelar a propagação de doenças, mas as leis de privacidade podem dificultar o compartilhamento de dados. Coprocessadores ZK poderiam permitir que autoridades de saúde pública enviassem consultas como “Quantas pessoas na região X testaram positivo nas últimas 24h?” para uma rede de dados de hospitais por meio de provas. Cada hospital mantém os registros de teste dos pacientes off-chain, mas pode provar ao contrato da autoridade a contagem de positivos sem revelar quem. Da mesma forma, o rastreamento de contatos poderia ser feito combinando trilhas de localização criptografadas: os contratos podem computar interseções de históricos de localização criptografados de pacientes para identificar focos, produzindo apenas as localizações dos focos (e talvez uma lista criptografada de IDs afetados que apenas o departamento de saúde pode descriptografar). As trilhas de localização brutas dos indivíduos permanecem privadas.
Mercados de Dados e Colaboração
A capacidade de computar dados sem revelá-los abre novos modelos de negócios em torno do compartilhamento de dados. Entidades podem colaborar em computações sabendo que seus dados proprietários não serão expostos:
-
Mercados de Dados Seguros: Vendedores podem disponibilizar dados de forma criptografada em um mercado de blockchain. Compradores podem pagar para executar análises específicas ou modelos de aprendizado de máquina no conjunto de dados criptografado por meio de um contrato inteligente, obtendo o modelo treinado ou resultados agregados. Os dados brutos do vendedor nunca são revelados ao comprador ou ao público – o comprador pode receber apenas um modelo (que ainda pode vazar algumas informações nos pesos, mas técnicas como privacidade diferencial ou controle da granularidade da saída podem mitigar isso). Provas ZK podem garantir ao comprador que a computação foi feita corretamente sobre o conjunto de dados prometido (por exemplo, o vendedor não pode trapacear executando o modelo em dados falsos porque a prova o vincula ao conjunto de dados criptografado comprometido). Este cenário incentiva o compartilhamento de dados: por exemplo, uma empresa poderia monetizar dados de comportamento do usuário permitindo que algoritmos aprovados sejam executados neles sob criptografia, sem entregar os próprios dados.
-
Aprendizado Federado e IA Descentralizada: No aprendizado de máquina descentralizado, várias partes (por exemplo, diferentes empresas ou dispositivos) querem treinar conjuntamente um modelo em seus dados combinados sem compartilhar dados entre si. As FHE-VMs se destacam aqui: elas podem permitir o aprendizado federado, onde as atualizações do modelo de cada parte são agregadas homomorficamente por um contrato. Como as atualizações são criptografadas, nenhum participante aprende as contribuições dos outros. O contrato poderia até mesmo realizar partes do ciclo de treinamento (como passos de descida de gradiente) on-chain sob criptografia, produzindo um modelo atualizado que apenas partes autorizadas podem descriptografar. O ZK pode complementar isso provando que a atualização de cada parte foi computada seguindo o algoritmo de treinamento (impedindo que um participante mal-intencionado envenene o modelo). Isso significa que um modelo global pode ser treinado com total auditabilidade on-chain, mas os dados de treinamento de cada contribuinte permanecem privados. Os casos de uso incluem o treinamento conjunto de modelos de detecção de fraude entre bancos ou a melhoria de assistentes de IA usando dados de muitos usuários sem centralizar os dados brutos.
-
Análises Interorganizacionais: Considere duas empresas que desejam encontrar sua interseção de clientes para uma campanha de parceria sem expor suas listas completas de clientes uma à outra. Elas poderiam criptografar suas listas de IDs de clientes e enviar um compromisso. Um contrato habilitado para FHE pode computar a interseção nos conjuntos criptografados (usando técnicas como interseção de conjuntos privados via FHE). O resultado poderia ser uma lista criptografada de IDs de clientes comuns que apenas um terceiro mutuamente confiável (ou os próprios clientes, por algum mecanismo) pode descriptografar. Alternativamente, uma abordagem ZK: uma parte prova à outra em conhecimento zero que “temos N clientes em comum e aqui está uma criptografia desses IDs” com uma prova de que a criptografia de fato corresponde a entradas comuns. Dessa forma, eles podem prosseguir com uma campanha para esses N clientes sem nunca trocar suas listas completas em texto claro. Cenários semelhantes: calcular métricas da cadeia de suprimentos entre concorrentes sem revelar detalhes de fornecedores individuais, ou bancos coletando informações de crédito sem compartilhar dados completos de clientes.
-
Computação Segura Multi-Partes (MPC) em Blockchain: FHE e ZK essencialmente trazem conceitos de MPC para on-chain. Lógicas de negócios complexas abrangendo várias organizações podem ser codificadas em um contrato inteligente de forma que as entradas de cada organização sejam compartilhadas secretamente ou criptografadas. O contrato (como um facilitador de MPC) produz saídas como divisões de lucro, cálculos de custo ou avaliações de risco conjuntas em que todos podem confiar. Por exemplo, suponha que várias empresas de energia queiram liquidar um mercado de negociação de energia. Elas poderiam alimentar seus lances e ofertas criptografados em um leilão de contrato inteligente; o contrato calcula os preços de compensação e as alocações em lances criptografados, e produz a alocação e o custo de cada empresa apenas para essa empresa (via criptografia para sua chave pública). Nenhuma empresa vê os lances das outras, protegendo informações competitivas, mas o resultado do leilão é justo e verificável. Essa combinação de transparência de blockchain e privacidade de MPC poderia revolucionar consórcios e consórcios empresariais que atualmente dependem de terceiros confiáveis.
Aprendizado de Máquina Descentralizado (ZKML e FHE-ML)
Trazer o aprendizado de máquina para blockchains de forma verificável e privada é uma fronteira emergente:
-
Inferência de ML Verificável: Usando provas ZK, pode-se provar que “um modelo de aprendizado de máquina f, quando recebe a entrada x, produz a saída y” sem revelar x (se forem dados privados) ou o funcionamento interno de f (se os pesos do modelo forem proprietários). Isso é crucial para serviços de IA em blockchain – por exemplo, um oráculo de IA descentralizado que fornece previsões ou classificações. Um coprocessador ZK pode executar o modelo off-chain (já que os modelos podem ser grandes e caros de avaliar) e postar uma prova do resultado. Por exemplo, um oráculo poderia provar a declaração “A imagem de satélite fornecida mostra pelo menos 50% de cobertura arbórea” para apoiar um contrato de crédito de carbono, sem revelar a imagem de satélite ou possivelmente até mesmo o modelo. Isso é conhecido como ZKML e projetos estão trabalhando na otimização de redes neurais amigáveis a circuitos. Isso garante a integridade das saídas de IA usadas em contratos inteligentes (sem trapaças ou saídas arbitrárias) e pode preservar a confidencialidade dos dados de entrada e dos parâmetros do modelo.
-
Treinamento com Privacidade e Auditabilidade: Treinar um modelo de ML é ainda mais intensivo em computação, mas se alcançável, permitiria mercados de modelos baseados em blockchain. Vários provedores de dados poderiam contribuir para o treinamento de um modelo sob FHE para que o algoritmo de treinamento seja executado em dados criptografados. O resultado pode ser um modelo criptografado que apenas o comprador pode descriptografar. Durante o treinamento, provas ZK poderiam ser fornecidas periodicamente para provar que o treinamento estava seguindo o protocolo (impedindo que um treinador mal-intencionado insira um backdoor, por exemplo). Embora o treinamento de ML totalmente on-chain esteja longe, dada os custos, uma abordagem híbrida poderia usar computação off-chain com provas ZK para partes críticas. Poder-se-ia imaginar uma competição descentralizada do tipo Kaggle, onde os participantes treinam modelos em conjuntos de dados privados e enviam provas ZK da precisão do modelo em dados de teste criptografados para determinar um vencedor – tudo sem revelar os conjuntos de dados ou os dados de teste.
-
IA Personalizada e Propriedade de Dados: Com essas tecnologias, os usuários poderiam manter a propriedade de seus dados pessoais e ainda se beneficiar da IA. Por exemplo, o dispositivo móvel de um usuário poderia usar FHE para criptografar seus dados de uso e enviá-los para um contrato de análise que computa um modelo de IA personalizado (como um modelo de recomendação) apenas para ele. O modelo é criptografado e apenas o dispositivo do usuário pode descriptografá-lo e usá-lo localmente. A plataforma (talvez uma rede social) nunca vê os dados brutos ou o modelo, mas o usuário obtém o benefício da IA. Se a plataforma quiser insights agregados, ela poderia solicitar provas ZK de certos padrões agregados do contrato sem acessar dados individuais.
Áreas Adicionais
-
Jogos: Jogos on-chain muitas vezes lutam para esconder informações secretas (por exemplo, mãos de cartas ocultas, névoa de guerra em jogos de estratégia). A FHE pode permitir jogos de estado oculto onde a lógica do jogo é executada em estado criptografado. Por exemplo, um contrato de jogo de pôquer poderia embaralhar e distribuir cartas criptografadas; os jogadores recebem as descriptografias de suas próprias cartas, mas o contrato e os outros só veem texto cifrado. A lógica de apostas pode usar provas ZK para garantir que um jogador não esteja blefando sobre uma ação (ou para revelar a mão vencedora no final de forma verificavelmente justa). Da mesma forma, sementes aleatórias para cunhagem de NFT ou resultados de jogos podem ser geradas e provadas justas sem expor a semente (impedindo manipulação). Isso pode aprimorar muito os jogos em blockchain, permitindo que suportem a mesma dinâmica dos jogos tradicionais.
-
Votação e Governança: DAOs poderiam usar tecnologia de privacidade para votações secretas on-chain, eliminando a compra de votos e a pressão. A FHE-VM poderia contar votos que são lançados de forma criptografada, e apenas os totais finais são descriptografados. Provas ZK podem garantir que cada voto foi válido (veio de um eleitor elegível, que não votou duas vezes) sem revelar quem votou em quê. Isso fornece verificabilidade (todos podem verificar as provas e a contagem) enquanto mantém os votos individuais secretos – crucial para uma governança imparcial.
-
Cadeia de Suprimentos Segura e IoT: Em cadeias de suprimentos, os parceiros podem querer compartilhar provas de certas propriedades (origem, métricas de qualidade) sem expor detalhes completos aos concorrentes. Por exemplo, um sensor IoT em uma remessa de alimentos poderia enviar continuamente dados de temperatura criptografados para uma blockchain. Um contrato poderia usar FHE para verificar se a temperatura permaneceu em uma faixa segura durante todo o trânsito. Se um limiar foi excedido, ele pode acionar um alerta ou penalidade, mas não precisa revelar todo o registro de temperatura publicamente – talvez apenas uma prova ou um agregado como “temperatura do 90º percentil”. Isso constrói confiança na automação da cadeia de suprimentos, respeitando a confidencialidade dos dados do processo.
Cada um desses casos de uso aproveita a capacidade central: computar ou verificar dados sem revelar os dados. Essa capacidade pode mudar fundamentalmente como lidamos com informações sensíveis em sistemas descentralizados. Ela reduz o trade-off entre transparência e privacidade que tem limitado a adoção da blockchain em áreas que lidam com dados privados.
Conclusão
A tecnologia blockchain está entrando em uma nova era de privacidade programável, onde a confidencialidade dos dados e a funcionalidade dos contratos inteligentes andam de mãos dadas. Os paradigmas de FHE-VM e coprocessadores ZK, embora tecnicamente distintos, ambos se esforçam para expandir o escopo das aplicações de blockchain, desvinculando o que podemos computar de o que devemos revelar.
As Máquinas Virtuais de Criptografia Totalmente Homomórfica mantêm as computações on-chain e criptografadas, preservando a descentralização e a composabilidade, mas exigindo avanços em eficiência. Os coprocessadores de Conhecimento Zero transferem o trabalho pesado para off-chain, permitindo computação virtualmente ilimitada sob garantias criptográficas, e já estão provando seu valor na escalabilidade e aprimoramento do Ethereum. A escolha entre eles (e seus híbridos) dependerá do caso de uso: se a interação em tempo real com estado privado for necessária, uma abordagem FHE pode ser mais adequada; se uma computação extremamente complexa ou integração com código existente for necessária, um coprocessador ZK pode ser o caminho a seguir. Em muitos casos, eles são complementares – de fato, vemos provas ZK reforçando a integridade da FHE, e a FHE potencialmente ajudando o ZK ao lidar com dados privados para provadores.
Para os desenvolvedores, essas tecnologias introduzirão novos padrões de design. Pensaremos em termos de variáveis criptografadas e verificação de provas como elementos de primeira classe da arquitetura de dApps. As ferramentas estão evoluindo rapidamente: linguagens de alto nível e SDKs estão abstraindo os detalhes criptográficos (por exemplo, as bibliotecas da Zama tornando os tipos FHE tão fáceis quanto os tipos nativos, ou os modelos da RISC Zero para solicitações de prova). Em alguns anos, escrever um contrato inteligente confidencial poderá parecer quase tão simples quanto escrever um regular, apenas com a privacidade "embutida" por padrão.
As implicações para a economia de dados são profundas. Indivíduos e empresas estarão mais dispostos a colocar dados ou lógica on-chain quando puderem controlar sua visibilidade. Isso pode desbloquear colaborações interorganizacionais, novos produtos financeiros e modelos de IA que antes eram inviáveis devido a preocupações com a privacidade. Os reguladores também podem vir a abraçar essas técnicas, pois permitem verificações de conformidade e auditorias por meios criptográficos (por exemplo, provar que os impostos são pagos corretamente on-chain sem expor todas as transações).
Ainda estamos nos primeiros dias – os protótipos atuais de FHE-VM têm limites de desempenho, e as provas ZK, embora muito mais rápidas do que antes, ainda podem ser um gargalo para tarefas extremamente complexas. Mas a pesquisa e os esforços de engenharia contínuos (incluindo hardware especializado, como evidenciado por empresas como a Optalysys impulsionando a aceleração óptica de FHE) estão rapidamente erodindo essas barreiras. O financiamento que está sendo injetado neste espaço (por exemplo, o status de unicórnio da Zama, o investimento da Paradigm na Axiom) ressalta uma forte crença de que os recursos de privacidade serão tão fundamentais para a Web3 quanto a transparência foi para a Web1/2.
Em conclusão, a privacidade programável via FHE-VMs e coprocessadores ZK anuncia uma nova classe de dApps que são trustless, descentralizadas e confidenciais. De negociações DeFi que não revelam detalhes, a pesquisas de saúde que protegem os dados dos pacientes, a modelos de aprendizado de máquina treinados em todo o mundo sem expor dados brutos – as possibilidades são vastas. À medida que essas tecnologias amadurecem, as plataformas de blockchain não mais forçarão o trade-off entre utilidade e privacidade, permitindo uma adoção mais ampla em indústrias que exigem confidencialidade. O futuro da Web3 é um onde usuários e organizações podem transacionar e computar com confiança dados sensíveis on-chain, sabendo que a blockchain verificará a integridade enquanto mantém seus segredos seguros.
Fontes: As informações neste relatório são extraídas da documentação técnica e de blogs de pesquisa recentes de projetos líderes neste espaço, incluindo a documentação da FHEVM da Cypher e da Zama, análises detalhadas da Trail of Bits sobre os circuitos da Axiom, guias de desenvolvedor e postagens de blog da RISC Zero, bem como artigos da indústria destacando casos de uso de tecnologia de blockchain confidencial. Essas e outras fontes foram citadas ao longo do texto para fornecer leitura adicional e evidências para as arquiteturas e aplicações descritas.
