3 posts marcados com "cryptographic proofs"

Sempre que você consulta o ChatGPT, Claude ou Gemini, você está confiando em uma caixa preta invisível. A versão do modelo? Desconhecida. Os pesos exatos? Proprietários. Se a saída foi gerada pelo modelo que você acha que está usando, ou por uma variante atualizada silenciosamente? Impossível de verificar. Para usuários casuais que perguntam sobre receitas ou curiosidades, essa opacidade é meramente irritante. Para a tomada de decisões de IA de alto risco — algoritmos de negociação financeira, diagnósticos médicos, análise de contratos jurídicos — é uma crise fundamental de confiança.

O Judge da Gensyn, lançado no final de 2025 e entrando em produção em 2026, oferece uma alternativa radical: avaliação de IA criptograficamente verificável, onde cada inferência é reprodutível até o bit. Em vez de confiar na OpenAI ou Anthropic para servir o modelo correto, o Judge permite que qualquer pessoa verifique se um modelo de IA específico e previamente acordado foi executado de forma determinística contra entradas do mundo real — com provas criptográficas garantindo que os resultados não possam ser falsificados.

O avanço técnico é o Verde, o sistema de verificação da Gensyn que elimina o não-determinismo de ponto flutuante — o flagelo da reprodutibilidade da IA. Ao impor computação exata por bits entre dispositivos, o Verde garante que a execução do mesmo modelo em uma NVIDIA A100 em Londres e em uma AMD MI250 em Tóquio produza resultados idênticos, comprováveis on-chain. Isso desbloqueia a IA verificável para finanças descentralizadas, agentes autônomos e qualquer aplicação onde a transparência não é opcional — ela é existencial.

O Problema das APIs Opacas: Confiança Sem Verificação​

A indústria de IA funciona com APIs. Desenvolvedores integram o GPT-4 da OpenAI, o Claude da Anthropic ou o Gemini do Google via endpoints REST, enviando prompts e recebendo respostas. Mas essas APIs são fundamentalmente opacas:

Incerteza de versão: Quando você chama o gpt-4, qual versão exata está recebendo? GPT-4-0314? GPT-4-0613? Uma variante atualizada silenciosamente? Os provedores frequentemente implementam correções sem anúncios públicos, alterando o comportamento do modelo da noite para o dia.

Sem trilha de auditoria: As respostas da API não incluem nenhuma prova criptográfica de qual modelo as gerou. Se a OpenAI servir uma variante censurada ou tendenciosa para geografias ou clientes específicos, os usuários não têm como detectá-la.

Degradação silenciosa: Os provedores podem "lobotomizar" modelos para reduzir custos — rebaixando a qualidade da inferência enquanto mantêm o mesmo contrato de API. Usuários relatam que o GPT-4 se tornou "mais burro" com o tempo, mas sem versionamento transparente, tais alegações permanecem anedóticas.

Saídas não-determinísticas: Mesmo consultando o mesmo modelo duas vezes com entradas idênticas, é possível obter resultados diferentes devido a configurações de temperatura, processamento em lote (batching) ou erros de arredondamento de ponto flutuante em nível de hardware. Isso torna a auditoria impossível — como verificar a exatidão quando as saídas não são reprodutíveis?

Para aplicações casuais, esses problemas são inconvenientes. Para tomadas de decisão de alto risco, eles são impedimentos. Considere:

Negociação algorítmica: Um fundo de hedge implanta um agente de IA gerenciando $ 50 milhões em posições DeFi. O agente depende do GPT-4 para analisar o sentimento do mercado a partir de postagens no X. Se o modelo for atualizado silenciosamente no meio da sessão de negociação, as pontuações de sentimento mudam de forma imprevisível — desencadeando liquidações não intencionais. O fundo não tem prova de que o modelo se comportou mal; os logs da OpenAI não são auditáveis publicamente.

Diagnósticos médicos: Um hospital usa um modelo de IA para recomendar tratamentos de câncer. As regulamentações exigem que os médicos documentem os processos de tomada de decisão. Mas se a versão do modelo de IA não puder ser verificada, a trilha de auditoria estará incompleta. Um processo de negligência médica poderia depender da prova de qual modelo gerou a recomendação — o que é impossível com APIs opacas.

Governança de DAO: Uma organização descentralizada usa um agente de IA para votar em propostas de tesouraria. Os membros da comunidade exigem prova de que o agente usou o modelo aprovado — e não uma variante adulterada que favoreça resultados específicos. Sem verificação criptográfica, o voto carece de legitimidade.

Esta é a lacuna de confiança que a Gensyn visa: à medida que a IA se torna incorporada em tomadas de decisão críticas, a incapacidade de verificar a autenticidade e o comportamento do modelo torna-se um "impedimento fundamental para a implantação de IA baseada em agentes em ambientes de alto risco".

Judge: O Protocolo de Avaliação de IA Verificável​

O Judge resolve o problema da opacidade executando modelos de IA determinísticos e previamente acordados contra entradas do mundo real e registrando os resultados em uma blockchain onde qualquer pessoa pode contestá-los. Veja como o protocolo funciona:

1. Compromisso do modelo: Os participantes concordam com um modelo de IA — sua arquitetura, pesos e configuração de inferência. Este modelo é transformado em hash e registrado on-chain. O hash serve como uma impressão digital criptográfica: qualquer desvio do modelo acordado produz um hash diferente.

2. Execução determinística: O Judge executa o modelo usando o Runtime Reprodutível da Gensyn, que garante reprodutibilidade exata por bits entre dispositivos. Isso elimina o não-determinismo de ponto flutuante — uma inovação crítica que exploraremos em breve.

3. Compromisso público: Após a inferência, o Judge publica a saída (ou um hash dela) on-chain. Isso cria um registro permanente e auditável do que o modelo produziu para uma determinada entrada.

4. Período de contestação: Qualquer pessoa pode contestar o resultado executando o modelo de forma independente. Se a sua saída for diferente, eles enviam uma prova de fraude. O mecanismo de delegação arbitrada do Verde identifica o operador exato no grafo computacional onde os resultados divergem.

5. Slashing por fraude: Se um contestador provar que o Judge produziu resultados incorretos, o executor original é penalizado (slashing de tokens em stake). Isso alinha os incentivos econômicos: os executores maximizam o lucro executando os modelos corretamente.

O Judge transforma a avaliação de IA de "confie no provedor de API" para "verifique a prova criptográfica". O comportamento do modelo é público, auditável e executável — não mais escondido atrás de endpoints proprietários.

Verde: Eliminando o Não Determinismo de Ponto Flutuante​

O principal desafio técnico na IA verificável é o determinismo. As redes neurais realizam bilhões de operações de ponto flutuante durante a inferência. Em GPUs modernas, essas operações não são perfeitamente reproduzíveis:

Não associatividade: A adição de ponto flutuante não é associativa. (a + b) + c pode resultar em um valor diferente de a + (b + c) devido a erros de arredondamento. As GPUs paralelizam somas em milhares de núcleos, e a ordem na qual as somas parciais se acumulam varia de acordo com o hardware e a versão do driver.

Variabilidade de agendamento de kernel: Os kernels de GPU (como multiplicação de matrizes ou atenção) podem ser executados em ordens diferentes dependendo da carga de trabalho, otimizações de driver ou arquitetura de hardware. Mesmo executar o mesmo modelo na mesma GPU duas vezes pode gerar resultados diferentes se o agendamento do kernel mudar.

Dependência do tamanho do lote (batch-size): Pesquisas descobriram que a inferência de LLM possui não determinismo em nível de sistema porque a saída depende do tamanho do lote. Muitos kernels (matmul, RMSNorm, atenção) alteram a saída numérica com base em quantas amostras são processadas juntas — uma inferência com tamanho de lote 1 produz valores diferentes da mesma entrada em um lote de 8.

Esses problemas tornam os modelos de IA padrão inadequados para a verificação em blockchain. Se dois validadores reexecutarem a mesma inferência e obtiverem saídas ligeiramente diferentes, quem está correto? Sem determinismo, o consenso é impossível.

O Verde resolve isso com RepOps (Reproducible Operators) — uma biblioteca que elimina o não determinismo de hardware controlando a ordem das operações de ponto flutuante em todos os dispositivos. Veja como funciona:

Ordens de redução canônicas: O RepOps impõe uma ordem determinística para somar resultados parciais em operações como multiplicação de matrizes. Em vez de deixar o agendador da GPU decidir, o RepOps especifica explicitamente: "some a coluna 0, depois a coluna 1, depois a coluna 2..." em todo o hardware. Isso garante que (a + b) + c seja sempre computado na mesma sequência.

Kernels CUDA personalizados: A Gensyn desenvolveu kernels otimizados que priorizam a reprodutibilidade em detrimento da velocidade bruta. As multiplicações de matrizes RepOps incorrem em menos de 30% de sobrecarga em comparação com o cuBLAS padrão — uma troca razoável pelo determinismo.

Fixação de drivers e versões (pinning): O Verde usa drivers de GPU com versões fixas e configurações canônicas, garantindo que o mesmo modelo executado em hardwares diferentes produza saídas idênticas bit a bit. Um modelo rodando em uma NVIDIA A100 em um datacenter corresponde à saída de uma AMD MI250 em outro, bit por bit.

Este é o avanço que permite a verificação do Judge: a reprodutibilidade exata bit a bit significa que os validadores podem confirmar resultados de forma independente sem confiar nos executores. Se o hash coincidir, a inferência está correta — matematicamente comprovável.

Delegação Referenciada: Verificação Eficiente Sem Recomputação Total​

Mesmo com execução determinística, verificar a inferência de IA de forma ingênua é caro. Um modelo de 70 bilhões de parâmetros gerando 1.000 tokens pode exigir 10 horas de GPU. Se os validadores tiverem que reexecutar cada inferência para verificar a correção, o custo da verificação seria igual ao custo de execução — anulando o propósito da descentralização.

O mecanismo de delegação referenciada (refereed delegation) do Verde torna a verificação exponencialmente mais barata:

Múltiplos executores não confiáveis: Em vez de um executor, o Judge atribui tarefas a vários provedores independentes. Cada um executa a mesma inferência e envia os resultados.

Discordância aciona investigação: Se todos os executores concordarem, o resultado é aceito — nenhuma verificação adicional é necessária. Se as saídas divergirem, o Verde inicia um jogo de desafio (challenge game).

Busca binária sobre o gráfico de computação: O Verde não reexecuta toda a inferência. Em vez disso, ele realiza uma busca binária sobre o gráfico computacional do modelo para encontrar o primeiro operador onde os resultados divergem. Isso identifica a camada exata (por exemplo, "camada de atenção 47, cabeça 8") que causou a discrepância.

Computação mínima do árbitro: Um árbitro (que pode ser um contrato inteligente ou um validador com computação limitada) verifica apenas o operador em disputa — não todo o passe para frente (forward pass). Para um modelo de 70B parâmetros com 80 camadas, isso reduz a verificação para checar cerca de 7 camadas (log₂ 80) no pior caso.

Essa abordagem é mais de 1.350% mais eficiente do que a replicação ingênua (onde cada validador reexecuta tudo). A Gensyn combina provas criptográficas, teoria dos jogos e processos otimizados para garantir a execução correta sem computação redundante.

O resultado: O Judge pode verificar cargas de trabalho de IA em escala, permitindo redes de inferência descentralizadas onde milhares de nós não confiáveis contribuem com computação — e executores desonestos são detectados e penalizados.

Tomada de Decisão de IA de Alto Risco: Por que a Transparência Importa​

O mercado-alvo do Judge não são chatbots casuais — são aplicações onde a verificabilidade não é apenas um diferencial, mas um requisito regulatório ou econômico. Aqui estão cenários onde APIs opacas falham catastroficamente:

Finanças descentralizadas (DeFi): Agentes de negociação autônomos gerenciam bilhões em ativos. Se um agente usa um modelo de IA para decidir quando rebalancear portfólios, os usuários precisam de provas de que o modelo não foi adulterado. O Judge permite a verificação on-chain: o agente se compromete com um hash de modelo específico, executa negociações com base em suas saídas e qualquer pessoa pode contestar a lógica de decisão. Essa transparência evita rug pulls onde agentes maliciosos alegam que "a IA me disse para liquidar" sem evidências.

Conformidade regulatória: Instituições financeiras que implantam IA para análise de crédito, detecção de fraude ou combate à lavagem de dinheiro (AML) enfrentam auditorias. Os reguladores exigem explicações: "Por que o modelo sinalizou esta transação?". APIs opacas não fornecem trilha de auditoria. O Judge cria um registro imutável da versão do modelo, entradas e saídas — satisfazendo os requisitos de conformidade.

Governança algorítmica: Organizações autônomas descentralizadas (DAOs) usam agentes de IA para propor ou votar em decisões de governança. Os membros da comunidade devem verificar se o agente usou o modelo aprovado — e não uma variante hackeada. Com o Judge, a DAO codifica o hash do modelo em seu contrato inteligente, e cada decisão inclui uma prova criptográfica de correção.

IA médica e jurídica: Os sistemas de saúde e jurídico exigem responsabilidade. Um médico diagnosticando câncer com auxílio de IA precisa documentar a versão exata do modelo utilizado. Um advogado redigindo contratos com IA deve provar que a saída veio de um modelo verificado e imparcial. A trilha de auditoria on-chain do Judge fornece essa evidência.

Mercados de previsão e oráculos: Projetos como o Polymarket usam IA para resolver resultados de apostas (por exemplo, "Este evento acontecerá?"). Se a resolução depende de um modelo de IA analisando artigos de notícias, os participantes precisam de prova de que o modelo não foi manipulado. O Judge verifica a inferência de IA do oráculo, evitando disputas.

Em cada caso, o ponto comum é que a confiança sem transparência é insuficiente. Como observa a VeritasChain, os sistemas de IA precisam de "gravadores de voo criptográficos" — registros imutáveis que provam o que aconteceu quando surgem disputas.

A Alternativa de Prova de Conhecimento Zero: Comparando Verde e ZKML​

O Judge não é a única abordagem para IA verificável. O Zero-Knowledge Machine Learning (ZKML) alcança objetivos semelhantes usando zk-SNARKs: provas criptográficas de que uma computação foi executada corretamente sem revelar entradas ou pesos.

Como o Verde se compara ao ZKML?

Custo de verificação: O ZKML requer ~1.000× mais computação do que a inferência original para gerar provas (estimativas de pesquisa). Um modelo de 70B de parâmetros que necessita de 10 horas de GPU para inferência pode exigir 10.000 horas de GPU para ser provado. A delegação arbitrada do Verde é logarítmica: verificar ~7 camadas em vez de 80 é uma redução de 10×, não de 1.000×.

Complexidade do provador: O ZKML exige hardware especializado (como ASICs personalizados para circuitos zk-SNARK) para gerar provas de forma eficiente. O Verde funciona em GPUs comuns — qualquer minerador com um PC gamer pode participar.

Trade-offs de privacidade: A força do ZKML é a privacidade — as provas não revelam nada sobre as entradas ou os pesos do modelo. A execução determinística do Verde é transparente: as entradas e saídas são públicas (embora os pesos possam ser criptografados). Para tomadas de decisão de alto risco, a transparência é muitas vezes desejável. Uma DAO votando na alocação do tesouro deseja trilhas de auditoria públicas, não provas ocultas.

Escopo de prova: O ZKML está praticamente limitado à inferência — provar o treinamento é inviável com os custos computacionais atuais. O Verde suporta tanto a verificação de inferência quanto a de treinamento (o protocolo mais amplo da Gensyn verifica o treinamento distribuído).

Adoção no mundo real: Projetos de ZKML como o Modulus Labs alcançaram avanços (verificando modelos de 18M de parâmetros on-chain), mas permanecem limitados a modelos menores. O runtime determinístico do Verde lida com modelos de mais de 70B de parâmetros em produção.

O ZKML se destaca onde a privacidade é primordial — como na verificação de autenticação biométrica (Worldcoin) sem expor varreduras de íris. O Verde se destaca onde a transparência é o objetivo — provar que um modelo público específico foi executado corretamente. Ambas as abordagens são complementares, não concorrentes.

O Ecossistema Gensyn: Do Judge ao Treinamento Descentralizado​

O Judge é um componente da visão mais ampla da Gensyn: uma rede descentralizada para computação de machine learning. O protocolo inclui:

Camada de execução: Execução consistente de ML em hardware heterogêneo (GPUs de consumo, clusters empresariais, dispositivos de borda). A Gensyn padroniza cargas de trabalho de inferência e treinamento, garantindo compatibilidade.

Camada de verificação (Verde): Verificação trustless usando delegação arbitrada. Executores desonestos são detectados e penalizados.

Comunicação peer-to-peer: Distribuição de carga de trabalho entre dispositivos sem coordenação centralizada. Mineradores recebem tarefas, as executam e enviam provas diretamente para a blockchain.

Coordenação descentralizada: Contratos inteligentes em um rollup de Ethereum identificam participantes, alocam tarefas e processam pagamentos sem permissão.

A Testnet Pública da Gensyn foi lançada em março de 2025, com a mainnet planejada para 2026. A venda pública do token $AI ocorreu em dezembro de 2025, estabelecendo incentivos econômicos para mineradores e validadores.

O Judge se encaixa nesse ecossistema como a camada de avaliação: enquanto o protocolo central da Gensyn lida com treinamento e inferência, o Judge garante que essas saídas sejam verificáveis. Isso cria um efeito de volante (flywheel):

Desenvolvedores treinam modelos na rede descentralizada da Gensyn (mais barato que AWS devido às GPUs de consumo subutilizadas que contribuem com computação).

Modelos são implantados com o Judge garantindo a integridade da avaliação. Os aplicativos consomem inferência via APIs da Gensyn, mas, ao contrário da OpenAI, cada saída inclui uma prova criptográfica.

Validadores ganham taxas verificando provas e detectando fraudes, alinhando os incentivos econômicos com a segurança da rede.

A confiança escala à medida que mais aplicativos adotam IA verificável, reduzindo a dependência de provedores centralizados.

O objetivo final: treinamento e inferência de IA que sejam comprovadamente corretos, descentralizados e acessíveis a qualquer pessoa — não apenas à Big Tech.

Desafios e Perguntas em Aberto​

A abordagem do Judge é inovadora, mas vários desafios permanecem:

Sobrecarga de desempenho: A desaceleração de 30% do RepOps é aceitável para verificação, mas se cada inferência tiver que ser executada de forma determinística, aplicativos sensíveis à latência (negociação em tempo real, veículos autônomos) podem preferir alternativas mais rápidas e não verificáveis. O roteiro da Gensyn provavelmente inclui a otimização adicional do RepOps — mas há um trade-off fundamental entre velocidade e determinismo.

Fragmentação da versão do driver: O Verde assume drivers com versões fixas, mas os fabricantes de GPU lançam atualizações constantemente. Se alguns mineradores usarem CUDA 12.4 e outros usarem 12.5, a reprodutibilidade bit a bit quebra. A Gensyn deve impor um gerenciamento rigoroso de versões — complicando a integração de mineradores.

Sigilo dos pesos do modelo: A transparência do Judge é um recurso para modelos públicos, mas um problema para modelos proprietários. Se um fundo de hedge treina um modelo de negociação valioso, implantá-lo no Judge expõe os pesos aos concorrentes (via compromisso on-chain). Alternativas baseadas em ZKML podem ser preferidas para modelos secretos — sugerindo que o Judge foca em aplicações de IA abertas ou semiabertas.

Latência na resolução de disputas: Se um desafiante alegar fraude, resolver a disputa via busca binária requer múltiplas transações on-chain (cada rodada estreita o espaço de busca). Aplicativos de alta frequência não podem esperar horas pela finalidade. A Gensyn pode introduzir a verificação otimista (presumir correção, a menos que seja contestada dentro de uma janela) para reduzir a latência.

Resistência a ataques Sybil na delegação arbitrada: Se vários executores devem concordar, o que impede uma única entidade de controlar todos os executores via identidades Sybil? A Gensyn provavelmente usa seleção ponderada por participação (validadores de alta reputação são escolhidos preferencialmente) além de slashing para desencorajar o conluio — mas os limiares econômicos devem ser cuidadosamente calibrados.

Estes não são impeditivos — são desafios de engenharia. A inovação central (IA determinística + verificação criptográfica) é sólida. Os detalhes de execução amadurecerão à medida que a testnet transitar para a mainnet.

O Caminho para a IA Verificável: Caminhos de Adoção e Market Fit​

O sucesso do Judge depende da adoção. Quais aplicações implementarão a IA verificável primeiro?

Protocolos DeFi com agentes autônomos: DAOs como Aave, Compound ou Uniswap poderiam integrar agentes verificados pelo Judge para a gestão de tesouraria. A comunidade vota para aprovar um hash de modelo, e todas as decisões do agente incluem provas. Essa transparência constrói confiança — algo crítico para a legitimidade do DeFi.

Mercados de previsão e oráculos: Plataformas como Polymarket ou Chainlink poderiam usar o Judge para resolver apostas ou entregar feeds de preços. Modelos de IA analisando sentimentos, notícias ou atividade on-chain produziriam resultados verificáveis — eliminando disputas sobre manipulação de oráculos.

Identidade descentralizada e KYC: Projetos que exigem verificação de identidade baseada em IA (estimativa de idade a partir de selfies, verificações de autenticidade de documentos) beneficiam-se da trilha de auditoria do Judge. Reguladores aceitam provas criptográficas de conformidade sem precisar confiar em provedores de identidade centralizados.

Moderação de conteúdo para redes sociais: Redes sociais descentralizadas (Farcaster, Lens Protocol) poderiam implementar moderadores de IA verificados pelo Judge. Membros da comunidade verificam se o modelo de moderação não é tendencioso ou censurado — garantindo a neutralidade da plataforma.

Plataformas de IA como Serviço (AI-as-a-Service): Desenvolvedores que constroem aplicações de IA podem oferecer "inferência verificável" como um recurso premium. Usuários pagam a mais por provas, diferenciando os serviços de alternativas opacas.

O ponto comum: aplicações onde a confiança é cara (devido à regulamentação, descentralização ou altos riscos) e o custo de verificação é aceitável (comparado ao valor da certeza).

O Judge não substituirá a OpenAI para chatbots de consumo — os usuários não se importam se o GPT-4 é verificável ao pedir ideias de receitas. Mas para algoritmos financeiros, ferramentas médicas e sistemas de governança, a IA verificável é o futuro.

Verificabilidade como o Novo Padrão​

O Judge da Gensyn representa uma mudança de paradigma: a avaliação de IA está mudando de "confie no provedor" para "verifique a prova". A base técnica — reprodutibilidade bitwise-exact via Verde, verificação eficiente através de delegação referenciada (refereed delegation) e trilhas de auditoria on-chain — torna essa transição prática, não apenas aspiracional.

As implicações ecoam muito além da Gensyn. Se a IA verificável se tornar o padrão, provedores centralizados perdem seus fossos competitivos (moats). A proposta de valor da OpenAI não são apenas as capacidades do GPT-4 — é a conveniência de não gerenciar infraestrutura. Mas se a Gensyn provar que a IA descentralizada pode igualar o desempenho centralizado com o valor adicional da verificabilidade, os desenvolvedores não terão motivos para se prenderem a APIs proprietárias.

A corrida começou. Projetos de ZKML (Modulus Labs, sistema biométrico da Worldcoin) estão apostando em provas de conhecimento zero. Runtimes determinísticos (Verde da Gensyn, EigenAI) estão apostando na reprodutibilidade. Abordagens otimistas (oráculos de IA em blockchain) estão apostando em provas de fraude. Cada caminho tem suas compensações — mas o destino é o mesmo: sistemas de IA onde os resultados são comprováveis, não apenas plausíveis.

Para tomadas de decisão de alto risco, isso não é opcional. Reguladores não aceitarão um "confie em nós" de provedores de IA em aplicações financeiras, de saúde ou jurídicas. DAOs não delegarão a gestão de tesouraria a agentes de caixa-preta. E à medida que os sistemas de IA autônomos se tornam mais poderosos, o público exigirá transparência.

O Judge é o primeiro sistema pronto para produção que entrega essa promessa. A testnet está ativa. As bases criptográficas são sólidas. O mercado — $ 27 bilhões em cripto de agentes de IA, bilhões em ativos DeFi gerenciados por algoritmos e a pressão regulatória aumentando — está pronto.

A era das APIs de IA opacas está terminando. A era da inteligência verificável está começando. E o Judge da Gensyn está iluminando o caminho.

---

Fontes:

• Introducing Judge | Gensyn Blog
• Gensyn launches verifiable AI evaluation system Judge | Bitget News
• Verde Verification System In Production | Gensyn
• Verde: a verification system for machine learning over untrusted nodes | Gensyn
• Verde: Verification via Refereed Delegation for Machine Learning Programs | arXiv
• EigenAI: Deterministic Inference, Verifiable Results | arXiv
• Deterministic Verification Architecture for AI Systems | Medium
• The Gensyn Protocol | Gensyn Docs
• Gensyn | the network for machine intelligence
• Gensyn Public Testnet | Gensyn Docs
• ZKML: Verifiable Machine Learning using Zero-Knowledge Proof | Kudelski Security
• The Verification Imperative: Why AI Trading Systems Need Cryptographic Flight Recorders | Medium
• Verifiable AI Agents: A Cryptographic Approach to Creating a Transparent Financial Ecosystem | CoinCentral
• A Framework for Cryptographic Verifiability of End-to-End AI Pipelines | arXiv

Em 2 de fevereiro de 2026, a economia de agentes de IA deu um passo crítico à frente. A Nillion lançou a Blacklight, uma camada de verificação que implementa o padrão ERC-8004 para resolver uma das questões mais urgentes da blockchain: como confiar em um agente de IA que você nunca encontrou?

A resposta não é uma simples pontuação de reputação ou um registro centralizado. É um processo de verificação em cinco etapas apoiado por provas criptográficas, auditorias programáveis e uma rede de nós operados pela comunidade. À medida que agentes autônomos executam cada vez mais negociações, gerenciam tesourarias e coordenam atividades cross-chain, a Blacklight representa a infraestrutura que permite a coordenação de IA sem confiança (trustless) em escala.

O Problema de Confiança que os Agentes de IA Não Podem Resolver Sozinhos​

Os números contam a história. Agentes de IA agora contribuem com 30% do volume de negociação da Polymarket, gerenciam estratégias de rendimento DeFi em múltiplos protocolos e executam fluxos de trabalho complexos de forma autônoma. Mas há um gargalo fundamental: como os agentes verificam a confiabilidade uns dos outros sem relacionamentos pré-existentes?

Os sistemas tradicionais dependem de autoridades centralizadas que emitem credenciais. A promessa da Web3 é diferente — verificação trustless por meio de criptografia e consenso. No entanto, até o ERC-8004, não havia uma maneira padronizada para os agentes provarem sua autenticidade, rastrearem seu comportamento ou validarem sua lógica de tomada de decisão on-chain.

Este não é apenas um problema teórico. Como Davide Crapis explica, "O ERC-8004 permite interações descentralizadas de agentes de IA, estabelece o comércio trustless e aprimora os sistemas de reputação no Ethereum". Sem isso, o comércio entre agentes permanece confinado a jardins murados ou requer supervisão manual — derrotando o propósito da autonomia.

ERC-8004: A Infraestrutura de Confiança de Três Registros​

O padrão ERC-8004, que entrou em operação na mainnet do Ethereum em 29 de janeiro de 2026, estabelece uma camada de confiança modular por meio de três registros on-chain:

Registro de Identidade: Usa o ERC-721 para fornecer identificadores de agentes portáteis. Cada agente recebe um token não fungível representando sua identidade on-chain exclusiva, permitindo o reconhecimento em várias plataformas e evitando a falsificação de identidade.

Registro de Reputação: Coleta feedbacks e avaliações padronizadas. Ao contrário dos sistemas de avaliação centralizados, o feedback é registrado on-chain com assinaturas criptográficas, criando uma trilha de auditoria imutável. Qualquer pessoa pode rastrear esse histórico e construir algoritmos de reputação personalizados.

Registro de Verificação: Oferece suporte à verificação criptográfica e econômica do trabalho do agente. É aqui que as auditorias programáveis acontecem — os validadores podem reexecutar computações, verificar provas de conhecimento zero (zero-knowledge proofs) ou utilizar Ambientes de Execução Confiáveis (TEEs) para confirmar que um agente agiu corretamente.

O brilhantismo do ERC-8004 é seu design agnóstico. Como observa a especificação técnica, o padrão suporta várias técnicas de verificação: "reexecução de tarefas garantida por stake (inspirada em sistemas como EigenLayer), verificação de provas de aprendizado de máquina de conhecimento zero (zkML) e atestados de Ambientes de Execução Confiáveis".

Essa flexibilidade é importante. Um agente de arbitragem DeFi pode usar provas zkML para verificar sua lógica de negociação sem revelar o alpha. Um agente de cadeia de suprimentos pode usar atestados TEE para provar que acessou dados do mundo real corretamente. Um agente de ponte cross-chain pode contar com a validação criptoeconômica com slashing para garantir uma execução honesta.

Processo de Verificação em Cinco Etapas da Blacklight​

A implementação do ERC-8004 pela Nillion na Blacklight adiciona uma camada crucial: nós de verificação operados pela comunidade. Veja como o processo funciona:

1. Registro do Agente: Um agente registra sua identidade no Registro de Identidade, recebendo um NFT ERC-721. Isso cria um identificador on-chain exclusivo vinculado à chave pública do agente.

2. Iniciação da Solicitação de Verificação: Quando um agente realiza uma ação que requer validação (por exemplo, executar uma negociação, transferir fundos ou atualizar o estado), ele envia uma solicitação de verificação para a Blacklight.

3. Atribuição de Comitê: O protocolo da Blacklight atribui aleatoriamente um comitê de nós de verificação para auditar a solicitação. Esses nós são operados por membros da comunidade que fazem stake de 70.000 tokens NIL, alinhando incentivos para a integridade da rede.

4. Verificações dos Nós: Os membros do comitê reexecutam a computação ou validam provas criptográficas. Se os validadores detectarem um comportamento incorreto, eles podem realizar o slashing do stake do agente (em sistemas que usam validação criptoeconômica) ou sinalizar a identidade no Registro de Reputação.

5. Relatórios On-Chain: Os resultados são postados on-chain. O Registro de Verificação registra se o trabalho do agente foi verificado, criando uma prova permanente de execução. O Registro de Reputação é atualizado de acordo.

Esse processo ocorre de forma assíncrona e não bloqueante, o que significa que os agentes não esperam que a verificação seja concluída para tarefas rotineiras — mas ações de alto risco (grandes transferências, operações cross-chain) podem exigir validação prévia.

Auditorias Programáveis: Além da Confiança Binária​

O recurso mais ambicioso do Blacklight é a "verificação programável" — a capacidade de auditar como um agente toma decisões, não apenas o que ele faz.

Considere um agente DeFi gerenciando uma tesouraria. As auditorias tradicionais verificam se os fundos foram movidos corretamente. As auditorias programáveis verificam:

• Consistência da lógica de tomada de decisão: O agente seguiu sua estratégia de investimento declarada ou se desviou dela?
• Execução de workflow multietapa: Se o agente deveria rebalancear portfólios em três chains, ele concluiu todas as etapas?
• Restrições de segurança: O agente respeitou os limites de gas, tolerâncias de slippage e limites de exposição?

Isso é possível porque o Registro de Validação do ERC-8004 suporta sistemas de prova arbitrários. Um agente pode se comprometer com um algoritmo de tomada de decisão on-chain ( por exemplo, um hash de seus pesos de rede neural ou um circuito zk-SNARK representando sua lógica ), e em seguida, provar que cada ação está em conformidade com esse algoritmo sem revelar detalhes proprietários.

O roadmap da Nillion visa explicitamente esses casos de uso: "A Nillion planeja expandir as capacidades do Blacklight para 'verificação programável', permitindo auditorias descentralizadas de comportamentos complexos, como a consistência da lógica de tomada de decisão do agente, a execução de workflow multietapa e restrições de segurança."

Isso muda a verificação de reativa ( detectar erros após o fato ) para proativa ( impor o comportamento correto por design ).

Computação Cega: Privacidade Encontra a Verificação​

A tecnologia subjacente da Nillion — Nil Message Compute ( NMC ) — adiciona uma dimensão de privacidade à verificação do agente. Ao contrário das blockchains tradicionais onde todos os dados são públicos, a "computação cega" da Nillion permite operações em dados criptografados sem descriptografia.

Veja por que isso é importante para os agentes: um agente de IA pode precisar verificar sua estratégia de negociação sem revelar seu alpha aos concorrentes. Ou provar que acessou registros médicos confidenciais corretamente sem expor os dados do paciente. Ou demonstrar conformidade com restrições regulatórias sem divulgar a lógica de negócios proprietária.

O NMC da Nillion alcança isso por meio de computação multipartidária ( MPC ), onde os nós geram colaborativamente "fatores de ofuscamento" — aleatoriedade correlacionada usada para criptografar dados. Como explica a DAIC Capital, "Os nós geram o recurso de rede principal necessário para processar dados — um tipo de aleatoriedade correlacionada referido como um fator de ofuscamento — com cada nó armazenando sua parte do fator de ofuscamento de forma segura, distribuindo a confiança pela rede de uma forma segura contra computação quântica."

Essa arquitetura é resistente à computação quântica por design. Mesmo que um computador quântico quebre a criptografia de curva elíptica atual, os fatores de ofuscamento distribuídos permanecem seguros porque nenhum nó individual possui informações suficientes para descriptografar os dados.

Para agentes de IA, isso significa que a verificação não requer o sacrifício da confidencialidade. Um agente pode provar que executou uma tarefa corretamente enquanto mantém seus métodos, fontes de dados e lógica de tomada de decisão privados.

A Jogada de Infraestrutura da Economia de Agentes de $ 4,3 Bilhões​

O lançamento do Blacklight ocorre no momento em que o setor de blockchain-IA entra em hipercrescimento. O mercado está projetado para crescer de $680 milhões ( 2025 ) para$ 4,3 bilhões ( 2034 ) a um CAGR de 22,9%, enquanto o mercado mais amplo de computação confidencial atinge $ 350 bilhões até 2032.

Mas a Nillion não está apenas apostando na expansão do mercado — ela está se posicionando como uma infraestrutura crítica. O gargalo da economia de agentes não é a computação ou o armazenamento; é a confiança em escala. Como observa a perspectiva para 2026 da KuCoin, três tendências principais estão remodelando a identidade da IA e o fluxo de valor:

Sistemas de Agente-Envolvendo-Agente ( Agent-Wrapping-Agent ): Agentes coordenando com outros agentes para executar tarefas multietapa complexas. Isso requer identidade e verificação padronizadas — exatamente o que o ERC-8004 fornece.

KYA ( Conheça Seu Agente ): Infraestrutura financeira que exige credenciais de agentes. Os reguladores não aprovarão agentes autônomos gerenciando fundos sem prova de comportamento correto. As auditorias programáveis do Blacklight abordam isso diretamente.

Nanopagamentos: Os agentes precisam liquidar micropagamentos de forma eficiente. O protocolo de pagamento x402, que processou mais de 20 milhões de transações em janeiro de 2026, complementa o ERC-8004 lidando com a liquidação, enquanto o Blacklight lida com a confiança.

Juntos, esses padrões atingiram a prontidão para produção com poucas semanas de diferença — um avanço de coordenação que sinaliza a maturação da infraestrutura.

O Futuro da Ethereum Focado em Agentes​

A adoção do ERC-8004 estende-se muito além da Nillion. No início de 2026, vários projetos integraram o padrão:

• Oasis Network: Implementando o ERC-8004 para computação confidencial com validação baseada em TEE
• The Graph: Suportando ERC-8004 e x402 para permitir interações de agentes verificáveis em indexação descentralizada
• MetaMask: Explorando carteiras de agentes com identidade ERC-8004 integrada
• Coinbase: Integrando o ERC-8004 para soluções de custódia institucional de agentes

Essa adoção rápida reflete uma mudança mais ampla no roadmap da Ethereum. Vitalik Buterin enfatizou repetidamente que o papel da blockchain está se tornando "apenas o encanamento" para agentes de IA — não a camada voltada para o consumidor, mas a infraestrutura de confiança que permite a coordenação autônoma.

O Blacklight da Nillion acelera essa visão ao tornar a verificação programável, preservadora de privacidade e descentralizada. Em vez de depender de oráculos centralizados ou revisores humanos, os agentes podem provar sua correção criptograficamente.

O Que Vem a Seguir: Integração com a Mainnet e Expansão do Ecossistema​

O roadmap de 2026 da Nillion prioriza a compatibilidade com a Ethereum e a descentralização sustentável. A bridge da Ethereum entrou em operação em fevereiro de 2026, seguida por contratos inteligentes nativos para staking e computação privada.

Membros da comunidade que realizam o staking de 70.000 tokens NIL podem operar nós de verificação Blacklight, ganhando recompensas enquanto mantêm a integridade da rede. Esse design espelha a economia de validadores da Ethereum, mas adiciona uma função específica de verificação.

Os próximos marcos incluem:

• Suporte expandido a zkML: Integração com projetos como o Modulus Labs para verificar inferência de IA on-chain
• Verificação cross-chain: Permitir que o Blacklight verifique agentes operando na Ethereum, Cosmos e Solana
• Parcerias institucionais: Colaborações com a Coinbase e a Alibaba Cloud para implantação de agentes corporativos
• Ferramentas de conformidade regulatória: Construção de frameworks KYA para adoção em serviços financeiros

Talvez o mais importante, a Nillion está desenvolvendo o nilGPT — um chatbot de IA totalmente privado que demonstra como a computação cega permite interações confidenciais entre agentes. Isso não é apenas uma demonstração; é um modelo para agentes que lidam com dados sensíveis na saúde, finanças e governo.

O Endgame da Coordenação Trustless​

O lançamento do Blacklight marca um ponto de virada para a economia de agentes. Antes do ERC-8004, os agentes operavam em silos — confiáveis dentro de seus próprios ecossistemas, mas incapazes de se coordenar entre plataformas sem intermediários humanos. Após o ERC-8004, os agentes podem verificar a identidade uns dos outros, auditar o comportamento mútuo e liquidar pagamentos de forma autônoma.

Isso desbloqueia categorias inteiramente novas de aplicações:

• Fundos de hedge descentralizados: Agentes gerindo portfólios em várias chains, com estratégias de investimento verificáveis e auditorias de desempenho transparentes
• Cadeias de suprimentos autônomas: Agentes coordenando logística, pagamentos e conformidade sem supervisão centralizada
• DAOs impulsionadas por IA: Organizações governadas por agentes que votam, propõem e executam com base em lógica de tomada de decisão criptograficamente verificada
• Gestão de liquidez cross-protocol: Agentes rebalanceando ativos entre protocolos DeFi com restrições de risco programáveis

O fio condutor? Todos exigem coordenação trustless — a capacidade de os agentes trabalharem juntos sem relacionamentos pré-existentes ou âncoras de confiança centralizadas.

O Blacklight da Nillion fornece exatamente isso. Ao combinar a infraestrutura de identidade e reputação do ERC-8004 com verificação programável e computação cega, ele cria uma camada de confiança escalável o suficiente para a economia de trilhões de agentes no horizonte.

À medida que a blockchain se torna a infraestrutura básica para agentes de IA e finanças globais, a questão não é se precisamos de infraestrutura de verificação — é quem a constrói e se ela é descentralizada ou controlada por alguns guardiões. Os nós operados pela comunidade e o padrão aberto do Blacklight defendem o primeiro caso.

A era dos atores on-chain autônomos chegou. A infraestrutura está ativa. A única questão restante é o que será construído sobre ela.

---

Fontes:

• Nillion lança verificação ERC-8004 no Blacklight | Phemex News
• ERC-8004: Agentes Trustless | Propostas de Melhoria da Ethereum (EIPs)
• ERC-8004: Infraestrutura para Agentes de IA Autônomos | QuillAudits
• Davide Crapis: ERC-8004 permite interações descentralizadas de agentes de IA | Unchained
• O Computador Cego da Nillion Conserta a Internet | Nillion
• Nillion (NIL): A Primeira Rede de Computação Cega da Humanidade | DAIC Capital
• Perspectivas para a Economia de Agentes de IA em 2026 | KuCoin
• The Graph apoia padrões x402 e ERC-8004 para a Economia de Agentes de IA | Blockchain News
• ERC-8004: Um Padrão para Agentes Trustless | Oasis Network
• Nillion 2.0 entra em operação na Ethereum | MEXC News
• Nillion: Computação Cega explodiu em 2025 | Medium
• 2026: Quando a Blockchain se torna apenas a infraestrutura básica para Agentes de IA | Blockmanity

Introdução: A Necessidade de IA Verificável na Blockchain​

À medida que os sistemas de IA crescem em influência, garantir que seus resultados sejam confiáveis torna-se crítico. Os métodos tradicionais dependem de garantias institucionais (essencialmente “apenas confie em nós”), que não oferecem garantias criptográficas. Isso é especialmente problemático em contextos descentralizados como blockchains, onde um contrato inteligente ou um usuário deve confiar em um resultado derivado de IA sem poder reexecutar um modelo pesado on-chain. O Machine Learning de Conhecimento Zero (zkML) aborda isso permitindo a verificação criptográfica de computações de ML. Em essência, o zkML permite que um provador gere uma prova sucinta de que “o resultado $Y$ veio da execução do modelo $M$ na entrada $X$” – sem revelar $X$ ou os detalhes internos de $M$. Essas provas de conhecimento zero (ZKPs) podem ser verificadas por qualquer pessoa (ou qualquer contrato) de forma eficiente, mudando a confiança na IA de “política para prova”.

A verificabilidade on-chain da IA significa que uma blockchain pode incorporar computações avançadas (como inferências de redes neurais) verificando uma prova de execução correta em vez de realizar a computação em si. Isso tem amplas implicações: contratos inteligentes podem tomar decisões com base em previsões de IA, agentes autônomos descentralizados podem provar que seguiram seus algoritmos, e serviços de computação cross-chain ou off-chain podem fornecer resultados verificáveis em vez de oráculos não verificáveis. Em última análise, o zkML oferece um caminho para uma IA sem necessidade de confiança e que preserva a privacidade – por exemplo, provando que as decisões de um modelo de IA são corretas e autorizadas sem expor dados privados ou pesos de modelos proprietários. Isso é fundamental para aplicações que vão desde análises seguras de saúde até jogos em blockchain e oráculos DeFi.

Como o zkML Funciona: Comprimindo a Inferência de ML em Provas Sucintas​

Em alto nível, o zkML combina sistemas de prova criptográfica com a inferência de ML para que uma avaliação de modelo complexa possa ser “comprimida” em uma pequena prova. Internamente, o modelo de ML (por exemplo, uma rede neural) é representado como um circuito ou programa consistindo de muitas operações aritméticas (multiplicações de matrizes, funções de ativação, etc.). Em vez de revelar todos os valores intermediários, um provador realiza a computação completa off-chain e, em seguida, usa um protocolo de prova de conhecimento zero para atestar que cada passo foi feito corretamente. O verificador, recebendo apenas a prova e alguns dados públicos (como o resultado final e um identificador para o modelo), pode ser criptograficamente convencido da correção sem reexecutar o modelo.

Para alcançar isso, as estruturas de zkML normalmente transformam a computação do modelo em um formato adequado para ZKPs:

• Compilação de Circuito: Em abordagens baseadas em SNARK, o grafo de computação do modelo é compilado em um circuito aritmético ou um conjunto de restrições polinomiais. Cada camada da rede neural (convoluções, multiplicações de matrizes, ativações não lineares) torna-se um subcircuito com restrições que garantem que os resultados estejam corretos dadas as entradas. Como as redes neurais envolvem operações não lineares (ReLUs, Sigmoids, etc.) que não são naturalmente adequadas para polinômios, técnicas como tabelas de consulta são usadas para lidar com elas de forma eficiente. Por exemplo, uma ReLU (resultado = max(0, entrada)) pode ser imposta por uma restrição personalizada ou uma consulta que verifica se o resultado é igual à entrada se a entrada ≥ 0, senão zero. O resultado final é um conjunto de restrições criptográficas que o provador deve satisfazer, o que implicitamente prova que o modelo foi executado corretamente.
• Rastro de Execução e Máquinas Virtuais: Uma alternativa é tratar a inferência do modelo como um rastro de programa, como feito em abordagens de zkVM. Por exemplo, a zkVM JOLT visa o conjunto de instruções RISC-V; pode-se compilar o modelo de ML (ou o código que o computa) para RISC-V e, em seguida, provar que cada instrução da CPU foi executada corretamente. A JOLT introduz uma técnica de “singularidade de consulta”, substituindo restrições aritméticas caras por consultas rápidas em tabelas para cada operação válida da CPU. Cada operação (soma, multiplicação, operação bit a bit, etc.) é verificada por meio de uma consulta em uma tabela gigante de resultados válidos pré-computados, usando um argumento especializado (Lasso/SHOUT) para manter isso eficiente. Isso reduz drasticamente a carga de trabalho do provador: até mesmo operações complexas de 64 bits tornam-se uma única consulta de tabela na prova, em vez de muitas restrições aritméticas.
• Protocolos Interativos (GKR Sum-Check): Uma terceira abordagem usa provas interativas como GKR (Goldwasser–Kalai–Rotblum) para verificar uma computação em camadas. Aqui, a computação do modelo é vista como um circuito aritmético em camadas (cada camada da rede neural é uma camada do grafo do circuito). O provador executa o modelo normalmente, mas depois se envolve em um protocolo sum-check para provar que os resultados de cada camada estão corretos dadas as suas entradas. Na abordagem da Lagrange (DeepProve, detalhada a seguir), o provador e o verificador realizam um protocolo polinomial interativo (tornado não interativo via Fiat-Shamir) que verifica a consistência das computações de cada camada sem refazê-las. Este método sum-check evita a geração de um circuito estático monolítico; em vez disso, ele verifica a consistência das computações de forma passo a passo com operações criptográficas mínimas (principalmente hashing ou avaliações polinomiais).

Independentemente da abordagem, o resultado é uma prova sucinta (normalmente de alguns kilobytes a algumas dezenas de kilobytes) que atesta a correção de toda a inferência. A prova é de conhecimento zero, o que significa que quaisquer entradas secretas (dados privados ou parâmetros do modelo) podem ser mantidas ocultas – elas influenciam a prova, mas não são reveladas aos verificadores. Apenas os resultados públicos ou asserções pretendidos são revelados. Isso permite cenários como “provar que o modelo $M$ quando aplicado aos dados do paciente $X$ resulta no diagnóstico $Y$, sem revelar $X$ ou os pesos do modelo.”

Habilitando a verificação on-chain: Uma vez que uma prova é gerada, ela pode ser postada em uma blockchain. Contratos inteligentes podem incluir lógica de verificação para checar a prova, muitas vezes usando primitivas criptográficas pré-compiladas. Por exemplo, o Ethereum possui pré-compilações para operações de emparelhamento BLS12-381 usadas em muitos verificadores de zk-SNARK, tornando a verificação on-chain de provas SNARK eficiente. Os STARKs (provas baseadas em hash) são maiores, mas ainda podem ser verificados on-chain com otimização cuidadosa ou possivelmente com algumas suposições de confiança (a L2 da StarkWare, por exemplo, verifica provas STARK no Ethereum por um contrato verificador on-chain, embora com um custo de gás mais alto que os SNARKs). O ponto principal é que a cadeia não precisa executar o modelo de ML – ela apenas executa uma verificação que é muito mais barata que a computação original. Em resumo, o zkML comprime a dispendiosa inferência de IA numa pequena prova que as blockchains (ou qualquer verificador) podem checar em milissegundos a segundos.

Lagrange DeepProve: Arquitetura e Desempenho de um Avanço em zkML​

DeepProve da Lagrange Labs é uma estrutura de inferência zkML de ponta focada em velocidade e escalabilidade. Lançado em 2025, o DeepProve introduziu um novo sistema de prova que é dramaticamente mais rápido que soluções anteriores como o Ezkl. Seu design se concentra no protocolo de prova interativo GKR com sum-check e otimizações especializadas para circuitos de redes neurais. Veja como o DeepProve funciona e alcança seu desempenho:

• Pré-processamento Único: Os desenvolvedores começam com uma rede neural treinada (os tipos atualmente suportados incluem perceptrons multicamadas e arquiteturas CNN populares). O modelo é exportado para o formato ONNX, uma representação de grafo padrão. A ferramenta do DeepProve então analisa o modelo ONNX e o quantiza (converte os pesos para formato de ponto fixo/inteiro) para uma aritmética de campo eficiente. Nesta fase, ele também gera as chaves de prova e verificação para o protocolo criptográfico. Essa configuração é feita uma vez por modelo e não precisa ser repetida por inferência. O DeepProve enfatiza a facilidade de integração: “Exporte seu modelo para ONNX → configuração única → gere provas → verifique em qualquer lugar”.

• Prova (Inferência + Geração de Prova): Após a configuração, um provador (que pode ser executado por um usuário, um serviço ou a rede de provadores descentralizada da Lagrange) pega uma nova entrada $X$ e executa o modelo $M$ nela, obtendo o resultado $Y$. Durante essa execução, o DeepProve registra um rastro de execução das computações de cada camada. Em vez de traduzir cada multiplicação em um circuito estático antecipadamente (como fazem as abordagens SNARK), o DeepProve usa o protocolo GKR de tempo linear para verificar cada camada em tempo real. Para cada camada da rede, o provador se compromete com as entradas e saídas da camada (por exemplo, via hashes criptográficos ou compromissos polinomiais) e, em seguida, se envolve em um argumento sum-check para provar que as saídas de fato resultam das entradas de acordo com a função da camada. O protocolo sum-check convence iterativamente o verificador da correção de uma soma de avaliações de um polinômio que codifica a computação da camada, sem revelar os valores reais. Operações não lineares (como ReLU, softmax) são tratadas eficientemente por meio de argumentos de consulta no DeepProve – se a saída de uma ativação foi computada, o DeepProve pode provar que cada saída corresponde a um par de entrada-saída válido de uma tabela pré-computada para essa função. Camada por camada, as provas são geradas e, em seguida, agregadas numa única prova sucinta cobrindo todo o passo de avanço do modelo. O trabalho pesado da criptografia é minimizado – o provador do DeepProve realiza principalmente computações numéricas normais (a inferência real) mais alguns compromissos criptográficos leves, em vez de resolver um sistema gigante de restrições.

• Verificação: O verificador usa a prova sucinta final juntamente com alguns valores públicos – tipicamente o identificador comprometido do modelo (um compromisso criptográfico com os pesos de $M$), a entrada $X$ (se não for privada) e o resultado alegado $Y$ – para verificar a correção. A verificação no sistema do DeepProve envolve a verificação da transcrição do protocolo sum-check e dos compromissos polinomiais ou de hash finais. Isso é mais complexo do que verificar um SNARK clássico (que pode ser alguns emparelhamentos), mas é vastamente mais barato do que reexecutar o modelo. Nos benchmarks da Lagrange, a verificação de uma prova do DeepProve para uma CNN média leva da ordem de 0,5 segundos em software. Isso é ~0,5s para confirmar, por exemplo, que uma rede convolucional com centenas de milhares de parâmetros foi executada corretamente – mais de 500× mais rápido do que recomputar ingenuamente essa CNN em uma GPU para verificação. (Na verdade, o DeepProve mediu uma verificação até 521× mais rápida para CNNs e 671× para MLPs em comparação com a reexecução.) O tamanho da prova é pequeno o suficiente para ser transmitido on-chain (dezenas de KB), e a verificação poderia ser realizada em um contrato inteligente se necessário, embora 0,5s de computação possa exigir otimização cuidadosa de gás ou execução em camada 2.

Arquitetura e Ferramentas: O DeepProve é implementado em Rust e fornece um kit de ferramentas (a biblioteca zkml) para desenvolvedores. Ele suporta nativamente grafos de modelo ONNX, tornando-o compatível com modelos do PyTorch ou TensorFlow (após a exportação). O processo de prova atualmente visa modelos de até alguns milhões de parâmetros (testes incluem uma rede densa de 4 milhões de parâmetros). O DeepProve utiliza uma combinação de componentes criptográficos: um compromisso polinomial multilinear (para se comprometer com as saídas da camada), o protocolo sum-check para verificar computações e argumentos de consulta para operações não lineares. Notavelmente, o repositório de código aberto da Lagrange reconhece que se baseia em trabalhos anteriores (a implementação de sum-check e GKR do projeto Ceno da Scroll), indicando uma interseção do zkML com a pesquisa de rollups de conhecimento zero.

Para alcançar escalabilidade em tempo real, a Lagrange combina o DeepProve com sua Rede de Provadores – uma rede descentralizada de provadores ZK especializados. A geração pesada de provas pode ser descarregada para esta rede: quando uma aplicação precisa de uma inferência provada, ela envia o trabalho para a rede da Lagrange, onde muitos operadores (em stake no EigenLayer para segurança) computam as provas e retornam o resultado. Esta rede incentiva economicamente a geração confiável de provas (trabalhos maliciosos ou falhos resultam em slashing do operador). Ao distribuir o trabalho entre os provadores (e potencialmente alavancar GPUs ou ASICs), a Rede de Provadores da Lagrange esconde a complexidade e o custo dos usuários finais. O resultado é um serviço zkML rápido, escalável e descentralizado: “inferências de IA verificáveis de forma rápida e acessível”.

Marcos de Desempenho: As alegações do DeepProve são apoiadas por benchmarks contra o estado da arte anterior, o Ezkl. Para uma CNN com ~264k parâmetros (modelo em escala CIFAR-10), o tempo de prova do DeepProve foi de ~1,24 segundos contra ~196 segundos para o Ezkl – cerca de 158× mais rápido. Para uma rede densa maior com 4 milhões de parâmetros, o DeepProve provou uma inferência em ~2,3 segundos vs ~126,8 segundos para o Ezkl (~54× mais rápido). Os tempos de verificação também caíram: o DeepProve verificou a prova da CNN de 264k em ~0,6s, enquanto a verificação da prova do Ezkl (baseada em Halo2) levou mais de 5 minutos na CPU nesse teste. As acelerações vêm da complexidade quase linear do DeepProve: seu provador escala aproximadamente O(n) com o número de operações, enquanto os provadores SNARK baseados em circuito geralmente têm uma sobrecarga superlinear (FFT e compromissos polinomiais escalando). Na verdade, o throughput do provador do DeepProve pode estar dentro de uma ordem de magnitude do tempo de execução da inferência simples – sistemas GKR recentes podem ser <10× mais lentos que a execução bruta para grandes multiplicações de matrizes, uma conquista impressionante em ZK. Isso torna as provas em tempo real ou sob demanda mais viáveis, abrindo caminho para a IA verificável em aplicações interativas.

Casos de Uso: A Lagrange já está colaborando com projetos Web3 e de IA para aplicar o zkML. Exemplos de casos de uso incluem: características de NFT verificáveis (provar que uma evolução gerada por IA de um personagem de jogo ou colecionável é computada pelo modelo autorizado), proveniência de conteúdo de IA (provar que uma imagem ou texto foi gerado por um modelo específico, para combater deepfakes), modelos de risco DeFi (provar o resultado de um modelo que avalia o risco financeiro sem revelar dados proprietários) e inferência de IA privada em saúde ou finanças (onde um hospital pode obter previsões de IA com uma prova, garantindo a correção sem expor os dados do paciente). Ao tornar os resultados da IA verificáveis e que preservam a privacidade, o DeepProve abre a porta para uma “IA em que você pode confiar” em sistemas descentralizados – passando de uma era de “confiança cega em modelos de caixa-preta” para uma de “garantias objetivas”.

zkML Baseado em SNARK: Ezkl e a Abordagem Halo2​

A abordagem tradicional para zkML usa zk-SNARKs (Argumentos de Conhecimento Sucintos e Não Interativos) para provar a inferência de redes neurais. Ezkl (da ZKonduit/Modulus Labs) é um exemplo líder dessa abordagem. Ele se baseia no sistema de prova Halo2 (um SNARK estilo PLONK com compromissos polinomiais sobre BLS12-381). O Ezkl fornece uma cadeia de ferramentas onde um desenvolvedor pode pegar um modelo PyTorch ou TensorFlow, exportá-lo para ONNX, e fazer com que o Ezkl o compile em um circuito aritmético personalizado automaticamente.

Como funciona: Cada camada da rede neural é convertida em restrições:

• Camadas lineares (densa ou convolução) tornam-se coleções de restrições de multiplicação-adição que impõem os produtos escalares entre entradas, pesos e saídas.
• Camadas não lineares (como ReLU, sigmoide, etc.) são tratadas por meio de consultas ou restrições por partes porque tais funções não são polinomiais. Por exemplo, uma ReLU pode ser implementada por um seletor booleano $b$ com restrições garantindo que $y = x \cdot b$ e $0 \le b \le 1$ e $b=1$ se $x>0$ (uma maneira de fazer isso), ou mais eficientemente por uma tabela de consulta mapeando $x \mapsto \max(0,x)$ para um intervalo de valores de $x$. Os argumentos de consulta do Halo2 permitem mapear pedaços de valores de 16 bits (ou menores), então domínios grandes (como todos os valores de 32 bits) são geralmente “divididos” em várias consultas menores. Essa divisão aumenta o número de restrições.
• Operações com inteiros grandes ou divisões (se houver) são similarmente quebradas em pequenos pedaços. O resultado é um grande conjunto de restrições R1CS/PLONK adaptadas à arquitetura específica do modelo.

O Ezkl então usa o Halo2 para gerar uma prova de que essas restrições são válidas dadas as entradas secretas (pesos do modelo, entradas privadas) e saídas públicas. Ferramentas e integração: Uma vantagem da abordagem SNARK é que ela aproveita primitivas bem conhecidas. O Halo2 já é usado em rollups do Ethereum (por exemplo, Zcash, zkEVMs), então é testado em batalha e tem um verificador on-chain prontamente disponível. As provas do Ezkl usam a curva BLS12-381, que o Ethereum pode verificar via pré-compilações, tornando simples a verificação de uma prova do Ezkl em um contrato inteligente. A equipe também forneceu APIs amigáveis; por exemplo, cientistas de dados podem trabalhar com seus modelos em Python e usar a CLI do Ezkl para produzir provas, sem conhecimento profundo de circuitos.

Pontos Fortes: A abordagem do Ezkl se beneficia da generalidade e do ecossistema dos SNARKs. Ele suporta modelos razoavelmente complexos e já viu “integrações práticas (de modelos de risco DeFi a IA de jogos)”, provando tarefas de ML do mundo real. Como opera no nível do grafo de computação do modelo, ele pode aplicar otimizações específicas de ML: por exemplo, podar pesos insignificantes ou quantizar parâmetros para reduzir o tamanho do circuito. Isso também significa que a confidencialidade do modelo é natural – os pesos podem ser tratados como dados de testemunho privados, então o verificador só vê que algum modelo válido produziu o resultado, ou no máximo um compromisso com o modelo. A verificação de provas SNARK é extremamente rápida (tipicamente alguns milissegundos ou menos on-chain), e os tamanhos das provas são pequenos (alguns kilobytes), o que é ideal para uso em blockchain.

Pontos Fracos: O desempenho é o calcanhar de Aquiles. A prova baseada em circuito impõe grandes sobrecargas, especialmente à medida que os modelos crescem. É notado que, historicamente, os circuitos SNARK poderiam exigir um milhão de vezes mais trabalho para o provador do que apenas executar o modelo em si. O Halo2 e o Ezkl otimizam isso, mas ainda assim, operações como grandes multiplicações de matrizes geram toneladas de restrições. Se um modelo tem milhões de parâmetros, o provador deve lidar com milhões de restrições correspondentes, realizando FFTs pesadas e multiexponenciações no processo. Isso leva a altos tempos de prova (muitas vezes minutos ou horas para modelos não triviais) e alto uso de memória. Por exemplo, provar até mesmo uma CNN relativamente pequena (por exemplo, algumas centenas de milhares de parâmetros) pode levar dezenas de minutos com o Ezkl em uma única máquina. A equipe por trás do DeepProve citou que o Ezkl levou horas para certas provas de modelo que o DeepProve pode fazer em minutos. Modelos grandes podem nem caber na memória ou exigir a divisão em múltiplas provas (que então precisam de agregação recursiva). Embora o Halo2 seja “moderadamente otimizado”, qualquer necessidade de “dividir” consultas ou lidar com operações de bits largos se traduz em sobrecarga extra. Em resumo, a escalabilidade é limitada – o Ezkl funciona bem para modelos de pequeno a médio porte (e de fato superou algumas alternativas anteriores como VMs baseadas em Stark ingênuas em benchmarks), mas tem dificuldades à medida que o tamanho do modelo cresce além de um certo ponto.

Apesar desses desafios, o Ezkl e bibliotecas zkML baseadas em SNARK semelhantes são importantes marcos. Eles provaram que a inferência de ML verificada é possível on-chain e têm uso ativo. Notavelmente, projetos como a Modulus Labs demonstraram a verificação de um modelo de 18 milhões de parâmetros on-chain usando SNARKs (com otimização pesada). O custo não foi trivial, mas mostra a trajetória. Além disso, o Protocolo Mina tem seu próprio kit de ferramentas zkML que usa SNARKs para permitir que contratos inteligentes no Mina (que são baseados em Snark) verifiquem a execução de modelos de ML. Isso indica um crescente suporte multiplataforma para zkML baseado em SNARK.

Abordagens Baseadas em STARK: ZK Transparente e Programável para ML​

Os zk-STARKs (Argumentos de Conhecimento Escaláveis e Transparentes) oferecem outra rota para o zkML. Os STARKs usam criptografia baseada em hash (como FRI para compromissos polinomiais) e evitam qualquer configuração confiável. Eles geralmente operam simulando uma CPU ou VM e provando que o rastro de execução está correto. No contexto de ML, pode-se construir um STARK personalizado para a rede neural ou usar uma VM STARK de propósito geral para executar o código do modelo.

VMs STARK Gerais (RISC Zero, Cairo): Uma abordagem direta é escrever o código de inferência e executá-lo em uma VM STARK. Por exemplo, a Risc0 fornece um ambiente RISC-V onde qualquer código (por exemplo, implementação em C++ ou Rust de uma rede neural) pode ser executado e provado via STARK. Da mesma forma, a linguagem Cairo da StarkWare pode expressar computações arbitrárias (como uma inferência de LSTM ou CNN) que são então provadas pelo provador STARK da StarkNet. A vantagem é a flexibilidade – você não precisa projetar circuitos personalizados para cada modelo. No entanto, benchmarks iniciais mostraram que VMs STARK ingênuas eram mais lentas em comparação com circuitos SNARK otimizados para ML. Em um teste, uma prova baseada em Halo2 (Ezkl) foi cerca de 3× mais rápida que uma abordagem baseada em STARK no Cairo, e até 66× mais rápida que uma VM STARK RISC-V em um certo benchmark em 2024. Essa diferença se deve à sobrecarga de simular cada instrução de baixo nível em um STARK e às constantes maiores nas provas STARK (hashing é rápido, mas você precisa de muito; os tamanhos das provas STARK são maiores, etc.). No entanto, as VMs STARK estão melhorando e têm o benefício da configuração transparente (sem configuração confiável) e segurança pós-quântica. À medida que o hardware e os protocolos amigáveis a STARK avançam, as velocidades de prova melhorarão.

A abordagem do DeepProve vs STARK: Curiosamente, o uso de GKR e sum-check pelo DeepProve produz uma prova mais parecida com um STARK em espírito – é uma prova interativa, baseada em hash, sem a necessidade de uma string de referência estruturada. A desvantagem é que suas provas são maiores e a verificação é mais pesada que a de um SNARK. No entanto, o DeepProve mostra que um design de protocolo cuidadoso (especializado na estrutura em camadas do ML) pode superar vastamente tanto as VMs STARK genéricas quanto os circuitos SNARK em tempo de prova. Podemos considerar o DeepProve como um provador zkML estilo STARK personalizado (embora eles usem o termo zkSNARK por sucinto, ele não tem a verificação de tamanho constante pequena de um SNARK tradicional, já que 0,5s para verificar é maior que a verificação típica de um SNARK). Provas STARK tradicionais (como as da StarkNet) geralmente envolvem dezenas de milhares de operações de campo para verificar, enquanto um SNARK verifica em talvez algumas dezenas. Assim, uma troca é evidente: SNARKs produzem provas menores e verificadores mais rápidos, enquanto STARKs (ou GKR) oferecem escalabilidade mais fácil e nenhuma configuração confiável ao custo do tamanho da prova e da velocidade de verificação.

Melhorias Emergentes: A zkVM JOLT (discutida anteriormente em JOLTx) está na verdade produzindo SNARKs (usando compromissos do tipo PLONK), mas incorpora ideias que poderiam ser aplicadas também no contexto STARK (consultas Lasso poderiam teoricamente ser usadas com compromissos FRI). A StarkWare e outros estão pesquisando maneiras de acelerar a prova de operações comuns (como usar portões personalizados ou dicas no Cairo para operações com inteiros grandes, etc.). Há também a Circomlib-ML da Privacy & Scaling Explorations (PSE), que fornece modelos Circom para camadas de CNN, etc. – isso é orientado para SNARK, mas modelos conceitualmente semelhantes poderiam ser feitos para linguagens STARK.

Na prática, ecossistemas não-Ethereum que utilizam STARKs incluem a StarkNet (que poderia permitir a verificação on-chain de ML se alguém escrevesse um verificador, embora o custo seja alto) e o serviço Bonsai da Risc0 (que é um serviço de prova off-chain que emite provas STARK que podem ser verificadas em várias cadeias). A partir de 2025, a maioria das demonstrações de zkML em blockchain favoreceu os SNARKs (devido à eficiência do verificador), mas as abordagens STARK permanecem atraentes por sua transparência e potencial em cenários de alta segurança ou resistentes à computação quântica. Por exemplo, uma rede de computação descentralizada pode usar STARKs para permitir que qualquer pessoa verifique o trabalho sem uma configuração confiável, útil para a longevidade. Além disso, algumas tarefas de ML especializadas podem explorar estruturas amigáveis a STARK: por exemplo, computações que usam intensivamente operações XOR/bit podem ser mais rápidas em STARKs (já que são baratas em álgebra booleana e hashing) do que na aritmética de campo de SNARKs.

Resumo de SNARK vs STARK para ML:

• Desempenho: SNARKs (como Halo2) têm uma enorme sobrecarga de prova por portão, mas se beneficiam de otimizações poderosas e constantes pequenas para verificação; STARKs (genéricos) têm uma sobrecarga constante maior, mas escalam de forma mais linear e evitam criptografia cara como emparelhamentos. O DeepProve mostra que personalizar a abordagem (sum-check) resulta em tempo de prova quase linear (rápido), mas com uma prova semelhante a um STARK. O JOLT mostra que até mesmo uma VM geral pode ser tornada mais rápida com o uso intensivo de consultas. Empiricamente, para modelos com até milhões de operações: um SNARK bem otimizado (Ezkl) pode lidar com isso, mas pode levar dezenas de minutos, enquanto o DeepProve (GKR) pode fazê-lo em segundos. As VMs STARK em 2024 eram provavelmente intermediárias ou piores que os SNARKs, a menos que especializadas (Risc0 foi mais lento nos testes, Cairo foi mais lento sem dicas personalizadas).
• Verificação: As provas SNARK são verificadas mais rapidamente (milissegundos, e dados mínimos on-chain ~ algumas centenas de bytes a alguns KB). As provas STARK são maiores (dezenas de KB) e levam mais tempo (dezenas de ms a segundos) para verificar devido a muitos passos de hashing. Em termos de blockchain, uma verificação de SNARK pode custar, por exemplo, ~200k de gás, enquanto uma verificação de STARK pode custar milhões de gás – muitas vezes alto demais para L1, aceitável em L2 ou com esquemas de verificação sucintos.
• Configuração e Segurança: SNARKs como Groth16 exigem uma configuração confiável por circuito (pouco amigável para modelos arbitrários), mas SNARKs universais (PLONK, Halo2) têm uma configuração única que pode ser reutilizada para qualquer circuito até um certo tamanho. STARKs não precisam de configuração e usam apenas suposições de hash (além de suposições clássicas de complexidade polinomial), e são seguros pós-quânticos. Isso torna os STARKs atraentes para a longevidade – as provas permanecem seguras mesmo que surjam computadores quânticos, enquanto os SNARKs atuais (baseados em BLS12-381) seriam quebrados por ataques quânticos.

Consolidaremos essas diferenças em uma tabela de comparação em breve.

FHE para ML (FHE-o-ML): Computação Privada vs. Computação Verificável​

A Criptografia Totalmente Homomórfica (FHE) é uma técnica criptográfica que permite que computações sejam realizadas diretamente em dados criptografados. No contexto de ML, a FHE pode permitir uma forma de inferência que preserva a privacidade: por exemplo, um cliente pode enviar uma entrada criptografada para um host de modelo, o host executa a rede neural no texto cifrado sem descriptografá-lo e envia de volta um resultado criptografado que o cliente pode descriptografar. Isso garante a confidencialidade dos dados – o proprietário do modelo não aprende nada sobre a entrada (e potencialmente o cliente aprende apenas o resultado, não os detalhes internos do modelo se receber apenas o resultado). No entanto, a FHE por si só não produz uma prova de correção da mesma forma que as ZKPs. O cliente deve confiar que o proprietário do modelo realmente realizou a computação honestamente (o texto cifrado poderia ter sido manipulado). Geralmente, se o cliente tem o modelo ou espera uma certa distribuição de resultados, trapaças flagrantes podem ser detectadas, mas erros sutis ou o uso de uma versão errada do modelo não seriam evidentes apenas a partir do resultado criptografado.

Compromissos no desempenho: A FHE é notoriamente pesada em computação. Executar inferência de aprendizado profundo sob FHE acarreta uma desaceleração de ordens de magnitude. Experimentos iniciais (por exemplo, CryptoNets em 2016) levaram dezenas de segundos para avaliar uma pequena CNN em dados criptografados. Em 2024, melhorias como CKKS (para aritmética aproximada) e bibliotecas melhores (Microsoft SEAL, Concrete da Zama) reduziram essa sobrecarga, mas ela permanece grande. Por exemplo, um usuário relatou que usar o Concrete-ML da Zama para executar um classificador CIFAR-10 levou 25–30 minutos por inferência em seu hardware. Após otimizações, a equipe da Zama alcançou ~40 segundos para essa inferência em um servidor de 192 núcleos. Mesmo 40s é extremamente lento em comparação com uma inferência em texto plano (que pode ser 0,01s), mostrando uma sobrecarga de ~$10^3–\10^4\times$. Modelos maiores ou maior precisão aumentam ainda mais o custo. Além disso, as operações FHE consomem muita memória e exigem bootstrapping ocasional (um passo de redução de ruído) que é computacionalmente caro. Em resumo, a escalabilidade é um grande problema – a FHE de ponta pode lidar com uma pequena CNN ou uma regressão logística simples, mas escalar para grandes CNNs ou Transformers está além dos limites práticos atuais.

Vantagens de privacidade: O grande apelo da FHE é a privacidade dos dados. A entrada pode permanecer completamente criptografada durante todo o processo. Isso significa que um servidor não confiável pode computar sobre os dados privados de um cliente sem aprender nada sobre eles. Por outro lado, se o modelo for sensível (proprietário), pode-se imaginar criptografar os parâmetros do modelo e fazer com que o cliente realize a inferência FHE do seu lado – mas isso é menos comum porque se o cliente tiver que fazer a computação FHE pesada, isso nega a ideia de descarregar para um servidor poderoso. Tipicamente, o modelo é público ou mantido pelo servidor em texto claro, e os dados são criptografados pela chave do cliente. A privacidade do modelo nesse cenário não é fornecida por padrão (o servidor conhece o modelo; o cliente aprende os resultados, mas não os pesos). Existem configurações mais exóticas (como computação segura de duas partes ou FHE multi-chave) onde tanto o modelo quanto os dados podem ser mantidos privados um do outro, mas isso acarreta ainda mais complexidade. Em contraste, o zkML via ZKPs pode garantir a privacidade do modelo e a privacidade dos dados ao mesmo tempo – o provador pode ter tanto o modelo quanto os dados como testemunho secreto, revelando apenas o que é necessário para o verificador.

Nenhuma verificação on-chain necessária (e nenhuma possível): Com a FHE, o resultado sai criptografado para o cliente. O cliente então o descriptografa para obter a previsão real. Se quisermos usar esse resultado on-chain, o cliente (ou quem quer que detenha a chave de descriptografia) teria que publicar o resultado em texto plano e convencer os outros de que está correto. Mas nesse ponto, a confiança volta a ser um problema – a menos que combinada com uma ZKP. Em princípio, poder-se-ia combinar FHE e ZKP: por exemplo, usar FHE para manter os dados privados durante a computação e, em seguida, gerar uma prova ZK de que o resultado em texto plano corresponde a uma computação correta. No entanto, combiná-los significa que você paga a penalidade de desempenho da FHE e da ZKP – extremamente impraticável com a tecnologia de hoje. Assim, na prática, FHE-de-ML e zkML servem a casos de uso diferentes:

• FHE-de-ML: Ideal quando o objetivo é a confidencialidade entre duas partes (cliente e servidor). Por exemplo, um serviço em nuvem pode hospedar um modelo de ML e os usuários podem consultá-lo com seus dados sensíveis sem revelar os dados para a nuvem (e se o modelo for sensível, talvez implantá-lo via codificações amigáveis à FHE). Isso é ótimo para serviços de ML que preservam a privacidade (previsões médicas, etc.). O usuário ainda tem que confiar no serviço para executar fielmente o modelo (já que não há prova), mas pelo menos qualquer vazamento de dados é evitado. Alguns projetos como a Zama estão até explorando uma “EVM habilitada para FHE (fhEVM)” onde contratos inteligentes poderiam operar em entradas criptografadas, mas verificar essas computações on-chain exigiria que o contrato de alguma forma impusesse a computação correta – um desafio aberto que provavelmente requer provas ZK ou hardware seguro especializado.
• zkML (ZKPs): Ideal quando o objetivo é a verificabilidade e auditabilidade pública. Se você quer que qualquer pessoa (ou qualquer contrato) tenha certeza de que “O modelo $M$ foi avaliado corretamente em $X$ e produziu $Y$”, as ZKPs são a solução. Elas também fornecem privacidade como um bônus (você pode esconder $X$ ou $Y$ ou $M$ se necessário, tratando-os como entradas privadas para a prova), mas sua principal característica é a prova de execução correta.

Uma relação complementar: Vale a pena notar que as ZKPs protegem o verificador (eles não aprendem nada sobre segredos, apenas que a computação foi feita corretamente), enquanto a FHE protege os dados do provador da parte que computa. Em alguns cenários, eles poderiam ser combinados – por exemplo, uma rede de nós não confiáveis poderia usar FHE para computar sobre os dados privados dos usuários e, em seguida, fornecer provas ZK aos usuários (ou à blockchain) de que as computações foram feitas de acordo com o protocolo. Isso cobriria tanto a privacidade quanto a correção, mas o custo de desempenho é enorme com os algoritmos de hoje. Mais viáveis a curto prazo são híbridos como Ambientes de Execução Confiáveis (TEE) mais ZKP ou Criptografia Funcional mais ZKP – estes estão além do nosso escopo, mas visam fornecer algo semelhante (TEEs mantêm dados/modelo secretos durante a computação, então uma ZKP pode atestar que o TEE fez a coisa certa).

Em resumo, FHE-de-ML prioriza a confidencialidade de entradas/saídas, enquanto zkML prioriza a correção verificável (com possível privacidade). A Tabela 1 abaixo contrasta as propriedades-chave:

Abordagem	Desempenho do Provador (Inferência e Prova)	Tamanho da Prova e Verificação	Recursos de Privacidade	Configuração Confiável?	Pós-Quântico?
zk-SNARK (Halo2, Groth16, PLONK, etc)	Sobrecarga pesada para o provador (até 10^6× o tempo de execução normal sem otimizações; na prática 10^3–10^5×). Otimizado para modelo/circuito específico; tempo de prova em minutos para modelos médios, horas para grandes. SNARKs zkML recentes (DeepProve com GKR) melhoram vastamente isso (sobrecarga quase linear, por exemplo, segundos em vez de minutos para modelos de milhões de parâmetros).	Provas muito pequenas (geralmente < 100 KB, às vezes ~alguns KB). A verificação é rápida: alguns emparelhamentos ou avaliações polinomiais (tipicamente < 50 ms on-chain). As provas baseadas em GKR do DeepProve são maiores (dezenas–centenas de KB) e verificam em ~0,5 s (ainda muito mais rápido que reexecutar o modelo).	Confidencialidade dos dados: Sim – as entradas podem ser privadas na prova (não reveladas). Privacidade do modelo: Sim – o provador pode se comprometer com os pesos do modelo e não revelá-los. Ocultação do resultado: Opcional – a prova pode ser de uma declaração sem revelar o resultado (por exemplo, “o resultado tem a propriedade P”). No entanto, se o próprio resultado for necessário on-chain, ele geralmente se torna público. No geral, os SNARKs oferecem flexibilidade total de conhecimento zero (oculte as partes que desejar).	Depende do esquema. Groth16/EZKL exigem uma configuração confiável por circuito; PLONK/Halo2 usam uma configuração universal (uma vez). O sum-check GKR do DeepProve é transparente (sem configuração) – um bônus desse design.	Os SNARKs clássicos (curvas BLS12-381) não são seguros contra PQC (vulneráveis a ataques quânticos ao logaritmo discreto de curva elíptica). Alguns SNARKs mais recentes usam compromissos seguros contra PQC, mas Halo2/PLONK como usados no Ezkl não são seguros contra PQC. O GKR (DeepProve) usa compromissos de hash (por exemplo, Poseidon/Merkle) que são conjecturados como seguros contra PQC (confiando na resistência à pré-imagem de hash).
zk-STARK (FRI, prova baseada em hash)	A sobrecarga do provador é alta, mas com escalonamento mais linear. Tipicamente 10^2–10^4× mais lento que o nativo para tarefas grandes, com espaço para paralelizar. VMs STARK gerais (Risc0, Cairo) tiveram desempenho mais lento vs SNARK para ML em 2024 (por exemplo, 3×–66× mais lento que Halo2 em alguns casos). STARKs especializados (ou GKR) podem se aproximar da sobrecarga linear e superar os SNARKs para circuitos grandes.	As provas são maiores: geralmente dezenas de KB (crescendo com o tamanho do circuito/log(n)). O verificador deve fazer múltiplas verificações de hash e FFT – tempo de verificação ~O(n^ε) para ε pequeno (por exemplo, ~50 ms a 500 ms dependendo do tamanho da prova). On-chain, isso é mais caro (o verificador L1 da StarkWare pode levar milhões de gás por prova). Alguns STARKs suportam provas recursivas para comprimir o tamanho, ao custo do tempo do provador.	Privacidade de dados e modelo: Um STARK pode ser tornado de conhecimento zero randomizando os dados do rastro (adicionando ofuscação às avaliações polinomiais), então ele pode ocultar entradas privadas de forma semelhante ao SNARK. Muitas implementações de STARK focam na integridade, mas variantes zk-STARK permitem privacidade. Então, sim, eles podem ocultar entradas/modelos como os SNARKs. Ocultação do resultado: da mesma forma, possível em teoria (o provador não declara o resultado como público), mas raramente usado, já que geralmente o resultado é o que queremos revelar/verificar.	Sem configuração confiável. A transparência é uma marca registrada dos STARKs – exigem apenas uma string aleatória comum (que o Fiat-Shamir pode derivar). Isso os torna atraentes para uso aberto (qualquer modelo, a qualquer momento, sem cerimônia por modelo).	Sim, os STARKs dependem de suposições de segurança de hash e teóricas da informação (como oráculo aleatório e dificuldade de certas decodificações de palavras-código em FRI). Acredita-se que sejam seguros contra adversários quânticos. As provas STARK são, portanto, resistentes a PQC, uma vantagem para a IA verificável à prova de futuro.
FHE para ML (Criptografia Totalmente Homomórfica aplicada à inferência)	Provador = parte que faz a computação em dados criptografados. O tempo de computação é extremamente alto: 10^3–10^5× mais lento que a inferência em texto plano é comum. Hardware de ponta (servidores com muitos núcleos, FPGA, etc.) pode mitigar isso. Algumas otimizações (inferência de baixa precisão, parâmetros FHE nivelados) podem reduzir a sobrecarga, mas há um impacto fundamental no desempenho. A FHE é atualmente prática para modelos pequenos ou modelos lineares simples; redes profundas permanecem desafiadoras além de tamanhos de brinquedo.	Nenhuma prova gerada. O resultado é uma saída criptografada. A Verificação no sentido de checar a correção não é fornecida apenas pela FHE – confia-se na parte que computa para não trapacear. (Se combinado com hardware seguro, pode-se obter uma atestação; caso contrário, um servidor malicioso poderia retornar um resultado criptografado incorreto que o cliente descriptografaria para a saída errada sem saber a diferença).	Confidencialidade dos dados: Sim – a entrada é criptografada, então a parte que computa não aprende nada sobre ela. Privacidade do modelo: Se o proprietário do modelo está fazendo a computação na entrada criptografada, o modelo está em texto plano do seu lado (não protegido). Se os papéis forem invertidos (cliente detém o modelo criptografado e o servidor computa), o modelo poderia ser mantido criptografado, mas este cenário é menos comum. Existem técnicas como ML seguro de duas partes que combinam FHE/MPC para proteger ambos, mas isso vai além da FHE simples. Ocultação do resultado: Por padrão, o resultado da computação é criptografado (apenas descriptografável pela parte com a chave secreta, geralmente o proprietário da entrada). Portanto, o resultado fica oculto do servidor de computação. Se quisermos o resultado público, o cliente pode descriptografar e revelá-lo.	Nenhuma configuração necessária. Cada usuário gera seu próprio par de chaves para criptografia. A confiança depende de as chaves permanecerem secretas.	A segurança dos esquemas FHE (por exemplo, BFV, CKKS, TFHE) é baseada em problemas de reticulado (Learning With Errors), que se acredita serem resistentes a ataques quânticos (pelo menos nenhum algoritmo quântico eficiente é conhecido). Portanto, a FHE é geralmente considerada segura pós-quântica.

Tabela 1: Comparação das abordagens zk-SNARK, zk-STARK e FHE para inferência de machine learning (compromissos de desempenho e privacidade).

Casos de Uso e Implicações para Aplicações Web3​

A convergência de IA e blockchain via zkML desbloqueia novos e poderosos padrões de aplicação na Web3:

• Agentes Autônomos Descentralizados e Tomada de Decisão On-Chain: Contratos inteligentes ou DAOs podem incorporar decisões impulsionadas por IA com garantias de correção. Por exemplo, imagine uma DAO que usa uma rede neural para analisar as condições de mercado antes de executar negociações. Com o zkML, o contrato inteligente da DAO pode exigir uma prova zkSNARK de que o modelo de ML autorizado (com um compromisso de hash conhecido) foi executado nos dados mais recentes e produziu a ação recomendada, antes que a ação seja aceita. Isso impede que atores maliciosos injetem uma previsão falsa – a cadeia verifica a computação da IA. Com o tempo, poderíamos até ter agentes autônomos totalmente on-chain (contratos que consultam IA off-chain ou contêm modelos simplificados) tomando decisões em DeFi ou jogos, com todos os seus movimentos provados corretos e em conformidade com as políticas via provas ZK. Isso aumenta a confiança em agentes autônomos, já que seu “pensamento” é transparente e verificável, em vez de uma caixa-preta.

• Mercados de Computação Verificável: Projetos como a Lagrange estão efetivamente criando mercados de computação verificável – desenvolvedores podem terceirizar a inferência pesada de ML para uma rede de provadores e receber de volta uma prova com o resultado. Isso é análogo à computação em nuvem descentralizada, mas com confiança embutida: você não precisa confiar no servidor, apenas na prova. É uma mudança de paradigma para oráculos e computação off-chain. Protocolos como o futuro DSC (camada de sequenciamento descentralizada) do Ethereum ou redes de oráculos poderiam usar isso para fornecer feeds de dados ou feeds analíticos com garantias criptográficas. Por exemplo, um oráculo poderia fornecer “o resultado do modelo X na entrada Y” e qualquer pessoa pode verificar a prova anexada on-chain, em vez de confiar na palavra do oráculo. Isso poderia permitir uma IA-como-serviço verificável na blockchain: qualquer contrato pode solicitar uma computação (como “pontue esses riscos de crédito com meu modelo privado”) e aceitar a resposta apenas com uma prova válida. Projetos como a Gensyn estão explorando mercados de treinamento e inferência descentralizados usando essas técnicas de verificação.

• NFTs e Jogos – Proveniência e Evolução: Em jogos de blockchain ou colecionáveis NFT, o zkML pode provar que traços ou movimentos de jogo foram gerados por modelos de IA legítimos. Por exemplo, um jogo pode permitir que uma IA evolua os atributos de um pet NFT. Sem ZK, um usuário esperto poderia modificar a IA ou o resultado para obter um pet superior. Com o zkML, o jogo pode exigir uma prova de que “as novas estatísticas do pet foram computadas pelo modelo de evolução oficial sobre as estatísticas antigas do pet”, prevenindo trapaças. O mesmo vale para NFTs de arte generativa: um artista poderia lançar um modelo generativo como um compromisso; mais tarde, ao cunhar NFTs, provar que cada imagem foi produzida por aquele modelo dado alguma semente, garantindo a autenticidade (e até mesmo fazendo isso sem revelar o modelo exato ao público, preservando a propriedade intelectual do artista). Essa verificação de proveniência garante a autenticidade de uma maneira semelhante à aleatoriedade verificável – exceto que aqui é criatividade verificável.

• IA que Preserva a Privacidade em Domínios Sensíveis: O zkML permite a confirmação de resultados sem expor as entradas. Na área da saúde, os dados de um paciente poderiam ser processados por um modelo de diagnóstico de IA por um provedor de nuvem; o hospital recebe um diagnóstico e uma prova de que o modelo (que poderia ser de propriedade privada de uma empresa farmacêutica) foi executado corretamente nos dados do paciente. Os dados do paciente permanecem privados (apenas uma forma criptografada ou comprometida foi usada na prova), e os pesos do modelo permanecem proprietários – ainda assim, o resultado é confiável. Reguladores ou seguradoras também poderiam verificar que apenas modelos aprovados foram usados. Em finanças, uma empresa poderia provar a um auditor ou regulador que seu modelo de risco foi aplicado aos seus dados internos e produziu certas métricas sem revelar os dados financeiros sensíveis subjacentes. Isso permite conformidade e supervisão com garantias criptográficas em vez de confiança manual.

• Interoperabilidade Cross-Chain e Off-Chain: Como as provas de conhecimento zero são fundamentalmente portáteis, o zkML pode facilitar resultados de IA cross-chain. Uma cadeia pode ter uma aplicação intensiva em IA rodando off-chain; ela pode postar uma prova do resultado em uma blockchain diferente, que o aceitará sem necessidade de confiança. Por exemplo, considere uma DAO multi-chain usando uma IA para agregar o sentimento nas redes sociais (dados off-chain). A análise de IA (PNL complexa em grandes dados) é feita off-chain por um serviço que então posta uma prova em uma pequena blockchain (ou múltiplas cadeias) de que “a análise foi feita corretamente e o resultado do sentimento = 0,85”. Todas as cadeias podem verificar e usar esse resultado em sua lógica de governança, sem que cada uma precise reexecutar a análise. Esse tipo de computação verificável interoperável é o que a rede da Lagrange visa suportar, servindo múltiplos rollups ou L1s simultaneamente. Isso remove a necessidade de pontes confiáveis ou suposições de oráculos ao mover resultados entre cadeias.

• Alinhamento e Governança de IA: Em uma nota mais futurista, o zkML foi destacado como uma ferramenta para a governança e segurança de IA. As declarações de visão da Lagrange, por exemplo, argumentam que à medida que os sistemas de IA se tornam mais poderosos (até mesmo superinteligentes), a verificação criptográfica será essencial para garantir que eles sigam regras acordadas. Ao exigir que os modelos de IA produzam provas de seu raciocínio ou restrições, os humanos mantêm um grau de controle – “você não pode confiar no que não pode verificar”. Embora isso seja especulativo e envolva tanto aspectos sociais quanto técnicos, a tecnologia poderia impor que um agente de IA rodando autonomamente ainda prove que está usando um modelo aprovado e não foi adulterado. Redes de IA descentralizadas podem usar provas on-chain para verificar contribuições (por exemplo, uma rede de nós treinando colaborativamente um modelo pode provar que cada atualização foi computada fielmente). Assim, o zkML poderia desempenhar um papel em garantir que os sistemas de IA permaneçam responsáveis perante protocolos definidos por humanos, mesmo em ambientes descentralizados ou não controlados.

Em conclusão, o zkML e a IA verificável on-chain representam uma convergência de criptografia avançada e machine learning que promete aumentar a confiança, a transparência e a privacidade em aplicações de IA. Ao comparar as principais abordagens – zk-SNARKs, zk-STARKs e FHE – vemos um espectro de compromissos entre desempenho e privacidade, cada um adequado para diferentes cenários. Estruturas baseadas em SNARK como o Ezkl e inovações como o DeepProve da Lagrange tornaram viável provar inferências substanciais de redes neurais com esforço prático, abrindo a porta para implantações de IA verificável no mundo real. Abordagens baseadas em STARK e VM prometem maior flexibilidade e segurança pós-quântica, que se tornarão importantes à medida que o campo amadurece. A FHE, embora não seja uma solução para a verificabilidade, aborda a necessidade complementar de computação de ML confidencial e, em combinação com ZKPs ou em contextos privados específicos, pode capacitar os usuários a alavancar a IA sem sacrificar a privacidade dos dados.

As implicações para a Web3 são significativas: podemos prever contratos inteligentes reagindo a previsões de IA, sabendo que estão corretas; mercados de computação onde os resultados são vendidos sem necessidade de confiança; identidades digitais (como a prova de humanidade da Worldcoin via IA de íris) protegidas por zkML para confirmar que alguém é humano sem vazar sua imagem biométrica; e, em geral, uma nova classe de “inteligência provável” que enriquece as aplicações de blockchain. Muitos desafios permanecem – desempenho para modelos muito grandes, ergonomia do desenvolvedor e a necessidade de hardware especializado – mas a trajetória é clara. Como um relatório observou, “as ZKPs de hoje podem suportar modelos pequenos, mas modelos de moderados a grandes quebram o paradigma”; no entanto, avanços rápidos (acelerações de 50×–150× com o DeepProve sobre a arte anterior) estão empurrando essa fronteira para fora. Com a pesquisa contínua (por exemplo, em aceleração de hardware e prova distribuída), podemos esperar que modelos de IA progressivamente maiores e mais complexos se tornem prováveis. O zkML pode em breve evoluir de demonstrações de nicho para um componente essencial da infraestrutura de IA confiável, garantindo que, à medida que a IA se torna onipresente, o faça de uma maneira que seja auditável, descentralizada e alinhada com a privacidade e segurança do usuário.