O que é um coprocessador ZK e porque importa para DeFi

O que é um coprocessador ZK?

Um coprocessador ZK é um sistema que realiza computação fora de uma blockchain e depois produz uma prova de que a computação foi realizada corretamente. ZK significa zero-knowledge, uma família de técnicas criptográficas que consegue provar uma afirmação sem revelar todas as informações usadas para a estabelecer. Em muitos desenhos de coprocessadores, a propriedade útil não é apenas o sigilo. É a verificabilidade.

Imagine um contrato inteligente a perguntar: esta carteira estava entre os principais utilizadores de um protocolo no bloco N? Uma conta manteve pelo menos um determinado saldo durante um período passado? Um pool permaneceu abaixo de um limiar de risco ao longo de milhares de blocos? Um contrato convencional pode não conseguir responder a estas perguntas de forma barata, porque as blockchains são concebidas para executar transições de estado atuais, não para analisar repetidamente todo o seu histórico.

Um coprocessador ZK lê ou recebe dados históricos de blockchain, realiza a computação solicitada off-chain e devolve um resultado com uma prova. Um contrato verificador verifica essa prova usando regras criptográficas. Se a prova for válida, o contrato pode agir com base no resultado sem aceitar uma simples afirmação de um operador de servidor.

A melhor forma de o entender é como um computador externalizado e verificável para dados de blockchain. Não torna um contrato omnisciente e não torna automaticamente uma aplicação privada, descentralizada ou barata. Essas propriedades dependem da fonte de dados, do circuito ou da máquina virtual, do sistema de prova, do verificador e do desenho económico em torno do serviço.

Os principais riscos e modos de falha

A palavra prova pode soar mais absoluta do que realmente é. Uma prova válida geralmente estabelece que uma computação definida foi realizada corretamente sobre entradas definidas, sob um sistema de prova definido. Não prova que o programador escolheu a pergunta certa, foi buscar a cadeia certa, interpretou corretamente um contrato ou construiu uma aplicação segura em torno da resposta.

O pressuposto técnico central é a solidez do sistema de prova. A solidez é a propriedade que torna inviável criar uma prova com aparência válida para uma afirmação falsa. Se a criptografia, a implementação, o circuito, o contrato verificador ou a configuração de confiança tiverem uma falha grave, um atacante poderá conseguir submeter um resultado incorreto que o contrato aceita. Um rótulo zero-knowledge não substitui a auditoria destes componentes.

Também existem riscos comuns de infraestrutura. Um provador pode ficar indisponível, um fornecedor de dados pode devolver um histórico incompleto, um serviço pode suportar apenas cadeias selecionadas ou um contrato pode depender de um coordenador para submeter provas. Alguns sistemas reduzem a confiança numa multisig, mas continuam a depender de operadores para disponibilidade, disponibilidade de dados, pagamento de taxas ou atualizações de software. As chaves de governação e as permissões de atualização merecem o mesmo escrutínio que o sistema de prova.

O modo de falha financeira é especialmente importante em DeFi. Um cálculo histórico incorreto poderia avaliar mal garantias, distribuir recompensas às contas erradas, desencadear liquidações ou aprovar um empréstimo mau. Uma prova pode mostrar que o código correu como escrito, enquanto o próprio código contém um erro económico. Por isso, os utilizadores devem analisar auditorias, endereços de verificadores, controlos de atualização, fontes de dados suportadas e procedimentos de emergência antes de tratarem uma aplicação apoiada por coprocessador como mais segura do que uma convencional.

Como prova dados históricos da cadeia

O fluxo básico tem várias etapas. Primeiro, uma aplicação define uma consulta e os dados de que precisa. A consulta pode envolver saldos, swaps, posições de liquidez, atividade de empréstimos ou compromissos de estado registados em blocos Ethereum anteriores. Em seguida, o sistema obtém os cabeçalhos de bloco, dados de transações, recibos e informações de estado relevantes, consoante o que o cálculo exige.

Depois, um trabalhador off-chain executa o programa solicitado. Esse programa pode ser um circuito especializado ou uma máquina virtual de conhecimento zero de uso geral, muitas vezes chamada zkVM. Uma zkVM permite aos programadores expressar lógica num ambiente de programação mais familiar, enquanto o sistema converte a execução para uma forma que pode ser provada. O resultado inclui tanto uma resposta como uma prova associada aos dados de entrada e ao programa.

O verificador on-chain normalmente não reproduz todas as transações históricas. Verifica uma prova compacta usando uma chave de verificação e entradas públicas, como um identificador de bloco, um compromisso de dados, os parâmetros da consulta e o resultado declarado. Se a prova for aprovada, um contrato pode armazenar o resultado ou usá-lo imediatamente. O contrato ainda tem de validar que o bloco e o compromisso de estado significam o que a aplicação espera.

O acesso a dados históricos é mais complicado do que simplesmente pedir um número a um nó. Um saldo pode depender do armazenamento de um contrato num bloco específico. Uma métrica ponderada pelo tempo pode exigir muitos instantâneos de estado. Um resultado baseado em logs pode não incluir informação que não tenha sido emitida como evento. O sistema tem de definir se prova dados de um nó de arquivo, uma representação indexada, um compromisso de bloco ou outra fonte. Essas escolhas afetam tanto a correção como a confiança.

O que uma prova realmente afirma

Suponha que um contrato recebe uma alegação de que um endereço forneceu liquidez durante pelo menos 100 dias antes de um bloco escolhido. A prova pode estabelecer que um programa especificado examinou entradas especificadas e chegou a esse resultado. Não estabelece de forma independente que a pergunta seja uma medida útil de lealdade, que o endereço seja controlado por uma só pessoa ou que a aplicação deva pagar uma recompensa.

Esta distinção explica por que razão consultas reproduzíveis e compromissos de entrada transparentes são importantes. Os programadores devem conseguir identificar a cadeia, o intervalo de blocos, os endereços de contratos, a versão do programa e os pressupostos por trás de um resultado. Sem esse contexto, uma prova pode ser matematicamente válida, mas difícil de interpretar pelos utilizadores.

Coprocessador versus rollup

Um rollup é um sistema de escalabilidade que executa lotes de transações fora da cadeia principal e publica dados ou compromissos suficientes para a cadeia base verificar ou reconstruir o estado resultante. A sua função principal é disponibilizar um local onde os utilizadores possam transacionar, mantendo o rollup um estado próprio de contas e aplicações. Um ZK rollup usa provas de validade para demonstrar que a sua transição de estado foi executada de acordo com as suas regras.

Um coprocessador tem uma função diferente. Normalmente, não mantém o estado canónico das contas para um novo ambiente de transações, e não é sobretudo um local onde os utilizadores depositam ativos e executam chamadas comuns de aplicações. Realiza cálculos selecionados sobre dados que já existem numa blockchain, depois envia um resultado e uma prova de volta para um contrato nessa cadeia.

A fronteira pode esbater-se. Um rollup pode usar um serviço semelhante a um coprocessador para análises, e um coprocessador pode usar infraestrutura de provas ao estilo de rollup ou uma zkVM. A questão prática não é qual o rótulo que aparece numa apresentação comercial. Pergunte se o sistema é responsável por ordenar e liquidar transações de utilizadores no seu próprio ambiente de execução, ou se está a responder a consultas verificáveis sobre o histórico de outra cadeia.

Para os utilizadores, esta diferença altera a superfície de risco. Um rollup levanta questões sobre custódia de bridges, disponibilidade de dados, comportamento do sequenciador, levantamentos e correção do estado. Um coprocessador levanta questões sobre entradas de consulta, solidez da prova, cobertura de dados históricos, disponibilidade do provador e se o contrato de destino trata o resultado em segurança. Nenhuma das categorias elimina toda a confiança ou risco operacional.

Em que difere de um oracle

Um oracle fornece informação a um smart contract que o contrato não consegue obter diretamente. Os feeds de preços são o exemplo familiar. Uma rede de oracles pode agregar preços de ETH de exchanges e publicar um valor para mercados de crédito. O contrato confia na conceção do oracle, nos relatores participantes, no método de agregação e nas salvaguardas contra manipulação.

Um coprocessador ZK normalmente prova um cálculo a partir de dados de blockchain especificados. Pode provar que um endereço interagiu com um protocolo, que a exposição histórica de um cofre ultrapassou um limiar, ou que um conjunto de transações cumpre uma regra. A prova responde se um cálculo seguiu corretamente as suas entradas. Não prova automaticamente que um preço de mercado externo, uma identidade do mundo real ou um facto jurídico é verdadeiro.

Os dois sistemas podem trabalhar em conjunto. Um oracle pode fornecer uma entrada de preço assinada ou autenticada de outra forma, e um coprocessador pode provar um cálculo de risco que usa essa entrada juntamente com posições históricas on-chain. Nesse desenho, a prova pode proteger o cálculo, enquanto o oracle continua a ser um ponto de confiança para os dados do mundo exterior.

Há também um aviso útil sobre a expressão trustless. Uma prova pode reduzir a dependência de uma multisig ou de um único servidor para o cálculo, mas não pode provar factos que nunca estiveram representados nas suas entradas. Se uma aplicação precisar de uma credencial do mundo real, de um preço atual de exchange ou de uma alegação jurídica, continua a precisar de uma atestação adequada ou de um mecanismo de oracle.

O que podem os programadores construir com um?

O benefício mais imediato é computação mais barata ou mais expressiva. Os contratos Ethereum pagam a execução com gas, e analisar históricos longos ou processar grandes conjuntos de dados diretamente on-chain pode ser impraticável. Um coprocessador desloca o trabalho pesado para fora da cadeia, deixando on-chain uma etapa de verificação compacta. O custo total continua a incluir a geração da prova, a obtenção de dados, a submissão da prova e, por vezes, uma taxa de serviço, pelo que mais barato não significa gratuito.

Motores de risco DeFi

Um protocolo de crédito poderia usar posições históricas para estimar concentração, comportamento de liquidação ou a relação de um mutuário com outros mercados. Um cofre poderia verificar uma janela de risco mais longa do que o seu código on-chain consegue processar eficientemente. Um sistema de recompensas poderia calcular a participação ao longo de muitos blocos sem armazenar todos os valores intermédios on-chain.

Estes usos são valiosos porque as aplicações DeFi precisam frequentemente de contexto em vez de apenas um número atual. Mas os modelos de risco não se tornam corretos por serem provados. Os programadores continuam a ter de escolher pressupostos robustos, ter em conta dados em falta e comportamento de flash-loan, e definir como o protocolo responde quando uma prova se atrasa ou fica indisponível.

Identidade privada e elegibilidade

Um utilizador poderia provar uma alegação restrita sobre uma credencial mais ampla sem revelar a própria credencial. Por exemplo, uma aplicação poderia verificar que uma pessoa cumpre um requisito de idade ou jurisdição, ou que uma carteira satisfaz uma regra de participação, limitando ao mesmo tempo a informação exposta ao contrato. Se isto é genuinamente privado depende do emissor da credencial, da carteira, dos metadados, do processo de revogação e do que a aplicação regista publicamente.

A atividade on-chain é muitas vezes associável, mesmo quando uma prova oculta algumas entradas. Uma prova privada não garante transações privadas, rede anónima ou proteção contra todas as formas de análise. Os sistemas de identidade também enfrentam o problema de provar que uma pessoa controla apenas uma identidade elegível, algo que a criptografia por si só não resolve.

Computação barata e consultas complexas

A computação geral é outro objetivo. Um programador pode querer executar lógica de reputação, análise de portefólios, cálculos de governação ou regras de jogos sobre o histórico da blockchain. Um sistema de uso geral pode reduzir a barreira para expressar estas tarefas, em comparação com escrever cada operação como um contrato on-chain.

Axiom centra-se em consultas verificáveis sobre dados de blockchain. RISC Zero fornece uma abordagem zkVM de uso geral que consegue provar programas executados num ambiente RISC-V. Succinct desenvolve infraestrutura e ferramentas de provas, incluindo a sua zkVM SP1. Estes projetos ilustram um amplo espaço de desenho, em vez de um único produto normalizado. O seu desempenho, entradas suportadas, modelos de implementação e garantias de produção podem diferir substancialmente, por isso o nome de um projeto, por si só, não é prova de que uma integração específica seja segura ou madura.

Limites atuais: custo de prova, latência e adoção

A computação de provas exige muitos recursos. Uma consulta que é barata para um servidor normal pode exigir hardware, memória e trabalho de engenharia significativos quando cada passo relevante tem de ser representado numa prova. Intervalos históricos maiores, programas complexos, operações criptográficas e muitos utilizadores em simultâneo podem aumentar o tempo de geração de provas e o custo operacional.

A latência também é importante. Uma chamada de contrato que precisa de uma resposta imediata pode não ser compatível com uma prova que demora minutos ou mais a gerar. Algumas aplicações conseguem tolerar atualizações assíncronas. Outras precisam de uma alternativa, de um resultado em cache, de um período otimista ou de uma ação conservadora enquanto uma prova está pendente. Essas soluções de contorno introduzem novas escolhas de design e, por vezes, novos pressupostos de confiança.

A disponibilidade de dados e a indexação continuam a ser estrangulamentos práticos. Um provador pode precisar de acesso de arquivo, índices especializados ou compromissos pré-processados. Se uma chain se reorganizar, alterar um formato de dados ou tiver cobertura histórica incompleta, a aplicação precisa de uma política clara. A prova só é tão útil quanto os dados que o programa conseguiu efetivamente consumir.

A experiência de desenvolvimento está a melhorar, mas escrever circuitos ou programas zkVM ainda exige conhecimento especializado. Podem surgir erros no código da aplicação, na tradução para uma forma demonstrável, no tratamento de entradas públicas e privadas ou na integração do verificador. As auditorias ajudam, mas não são garantias. Código open-source, compilações reprodutíveis, verificação independente, programas de recompensas por bugs e limites conservadores são sinais relevantes a analisar.

O que isto significa para utilizadores e construtores

Para construtores, comece pela alegação exata que o contrato precisa de verificar. Defina o bloco, a chain, os compromissos de dados, a versão do programa, o desfasamento aceitável e o comportamento caso a prova não possa ser produzida. Depois compare um coprocessador com opções mais simples, como armazenar um agregado contínuo, usar um oracle estabelecido ou fazer a computação diretamente on-chain. A arquitetura mais avançada não é automaticamente a melhor.

Para utilizadores, olhe para além da expressão com tecnologia ZK. Descubra se o produto tem utilização real em mainnet ou se é sobretudo uma demonstração. Verifique que partes são open-source, quem pode atualizar o verificador, se um coordenador pode censurar ou atrasar provas, como os dados históricos são obtidos e o que acontece após um resultado incorreto. Se um protocolo aceitar depósitos elevados, analise auditorias e o histórico de incidentes em vez de confiar na marca criptográfica.

Também é útil separar três perguntas. O sistema consegue calcular o resultado pedido? Consegue provar o resultado de forma sólida? A aplicação usará esse resultado em segurança sob condições adversariais? Uma resposta convincente à primeira pergunta não resolve as outras duas.

Como leitor avançado, poderá também querer comparar este tema com como funciona a escalabilidade do Ethereum e o que são provas de conhecimento zero. Esses conceitos explicam porque a geração de provas pode reduzir o trabalho de verificação on-chain, embora continue a exigir escolhas cuidadosas sobre dados, computação e confiança.

Leia criticamente as alegações sobre coprocessadores ZK

Os coprocessadores ZK evoluem depressa, e as alegações em torno deles muitas vezes evoluem ainda mais depressa. Acompanhar manualmente lançamentos técnicos, integrações e notícias de segurança é difícil. O Zippfeed destaca manchetes relevantes com pontuação de sentimento bullish, neutral ou bearish e uma classificação de importância, ajudando-o a distinguir uma implementação significativa em produção de um protótipo, anúncio de parceria ou risco por resolver. Use esse contexto para acompanhar a tecnologia sem tratar a cobertura como uma recomendação para comprar ou usar qualquer projeto.