Em que se distingue Brevis dos oráculos e dos restantes co-processadores ZK?

A distinção fundamental entre oracles e ZK coprocessors como Brevis reside na direção dos dados: os oracles servem para trazer dados externos, off-chain, para a blockchain, enquanto ZK coprocessors como Brevis concentram-se em cálculos verificáveis sobre dados históricos já presentes on-chain, devolvendo resultados que podem ser validados matematicamente. Como plataforma de computação verificável orientada para Web3, Brevis (BREV) responde à questão “como calcular dados on-chain e provar a sua correção”, ao passo que os oracles tratam de “como trazer dados off-chain para on-chain”.

Os smart contracts nas blockchains não têm acesso direto a dados externos e enfrentam desafios significativos na reprodução de grandes volumes de transações históricas on-chain. Estas limitações impulsionaram o desenvolvimento de oracles e ZK coprocessors: os oracles permitem a entrada de dados externos na blockchain, enquanto os ZK coprocessors viabilizam cálculos confiáveis sobre dados históricos on-chain. Compreender esta distinção é crucial para decidir que infraestrutura implementar ou como combinar ambas para casos de uso específicos.

Figura 1. Comparação entre Brevis ZK Coprocessor e Oracle em quatro dimensões: direção dos dados, modelo de confiança, cálculo e verificação.

O que é um Oracle e que problemas resolve?

Um oracle funciona como ponte entre blockchains e o mundo externo, com o objetivo principal de entregar dados off-chain ou externos de forma segura aos smart contracts on-chain. Os casos de utilização mais comuns incluem feeds de preços, geração de números aleatórios, reporte de resultados de eventos e sincronização de estados entre sistemas.

Num ambiente fechado e determinístico, os smart contracts não conseguem aceder diretamente a APIs off-chain ou a dados do mundo real. Os oracles utilizam redes de nodos para recolher, agregar e escrever dados on-chain, permitindo que contratos dependentes de condições de mercado externas — como liquidações de empréstimos e liquidação de derivados — funcionem de forma eficaz.

A confiança nos oracles baseia-se em pressupostos sobre a integridade das redes de nodos, arranjos multisig, mecanismos de agregação de dados e incentivos económicos. A precisão dos dados depende, em última instância, da honestidade dos nodos de reporte e da robustez do processo de agregação, e não de provas matemáticas on-chain.

O que são ZK Coprocessors como Brevis?

Os ZK coprocessors como Brevis destinam-se a processar dados históricos e entre cadeias já presentes on-chain, executando cálculos complexos off-chain e devolvendo tanto os resultados como provas de zero-knowledge. Estas provas permitem que os smart contracts verifiquem matematicamente a correção dos cálculos on-chain. ZK data coprocessors acedem a dados autênticos de nodos de arquivo off-chain, realizam cálculos e devolvem resultados e provas on-chain, estabelecendo um fluxo completo de “cálculo off-chain, verificação on-chain”.

Brevis é alimentado por um ZK data coprocessor e pelo Pico zkVM, operando sob dois modelos de segurança: pure-ZK (zero-knowledge puro) ou o modelo coChain (OP) descrito em BREV Token and coChain. O modelo pure-ZK baseia-se em provas criptográficas, enquanto o modelo coChain integra staking e slashing baseados em Ethereum para segurança criptoeconómica adicional.

Ao contrário dos oracles, os ZK coprocessors não dependem de relatórios honestos de dados. Permitem que o próprio processo de cálculo seja verificável: desde que a prova seja válida, o contrato pode confirmar a existência e correção dos dados e cálculos relevantes on-chain, minimizando requisitos de confiança.

Como diferem as fontes de dados e modelos de confiança?

Relativamente às fontes de dados, os oracles ingerem dados externos, off-chain (preços, eventos, dados de API), enquanto os ZK coprocessors utilizam dados já existentes on-chain (transações históricas, saldos, estados entre cadeias).

Quanto aos modelos de confiança, os oracles dependem de nodos de reporte confiáveis ou arranjos multisig, suportados por incentivos económicos — confiança nos reportadores de dados, num modelo social e económico. Os ZK coprocessors, por outro lado, baseiam-se na verificabilidade matemática das provas de zero-knowledge — confiança no próprio cálculo, num modelo criptográfico.

Nenhum modelo é categoricamente superior. Dados externos não podem ser provados verdadeiros apenas por criptografia, e saber se os preços on-chain correspondem aos preços reais de mercado requer uma fonte confiável. No entanto, cálculos sobre dados existentes on-chain podem ser verificados diretamente via provas ZK.

Como diferem as suas capacidades de cálculo?

No que se refere às capacidades de cálculo, os oracles tratam sobretudo de “transporte de dados”: transmitem e agregam dados externos para uso on-chain, sem realizar análise complexa de dados on-chain. Os ZK coprocessors, por outro lado, são capazes de “cálculo intensivo”, realizando estatísticas em larga escala, agregação e até inferência de modelos sobre dados históricos off-chain.

Os smart contracts têm acesso limitado a dados históricos, e reproduzir extensas histórias de transações on-chain tem custos elevados. Os ZK coprocessors deslocam esses cálculos para off-chain e fornecem provas sucintas, permitindo verificação rápida on-chain e ultrapassando limitações de Gas dos blocos na escala computacional.

Tabela: principais diferenças entre Brevis, Oracles e outros ZK Coprocessors

A tabela abaixo compara ZK coprocessors como Brevis, outros ZK coprocessors e oracles em quatro dimensões: direção dos dados, modelo de confiança, capacidade de cálculo e método de verificação.

Pontos-chave: Oracles e ZK coprocessors ocupam extremos opostos do fluxo de dados. “Outros ZK coprocessors”, enquanto infraestruturas semelhantes, fazem diferentes compromissos em acesso a dados, sistemas de prova e modelos de segurança. Brevis destaca-se pelo Pico zkVM generalista e modelos dual pure-ZK/coChain. Esta tabela fornece uma visão categórica e não tira conclusões sobre projetos externos não confirmados.

Que tipo deve ser usado em cada cenário?

A escolha depende se a aplicação precisa de “dados externos on-chain” ou de “cálculo de dados históricos on-chain”. Os oracles são preferidos para preços de ativos em tempo real, resultados de eventos off-chain ou números aleatórios. Os ZK coprocessors são mais adequados para incentivar utilizadores com base em comportamento on-chain de longo prazo, controlo de risco ou agregação entre cadeias.

Cenários de dados-on-chain são geralmente tratados por oracles, como preços de liquidação de empréstimos, liquidação de derivados e ativação de eventos de seguros. Cenários de cálculo de dados históricos servem-se melhor dos ZK coprocessors, como recompensar com base no volume real de negociação, calcular lealdade pela duração de participação ou agregar ativos entre cadeias para controlo de risco. Na prática, ambos são frequentemente usados em conjunto: uma aplicação DeFi pode utilizar oracles para preços externos e ZK coprocessors para avaliar contribuições históricas on-chain — são complementares, não substituíveis.

Figura 2. Seleção de cenários: utilizar oracles para dados externos on-chain, ZK coprocessors como Brevis para cálculo histórico verificável on-chain; ambos podem ser combinados.

Quais são as limitações e considerações nestas comparações?

Os limites da terminologia não são absolutos: “oracle” e “ZK coprocessor” são categorias funcionais, mas produtos reais integram frequentemente várias capacidades e estes limites podem esbater-se à medida que os designs evoluem. “Outros ZK coprocessors” devem ser vistos como uma categoria geral — evitar tirar conclusões definitivas sobre projetos externos sem confirmação pública.

Soluções híbridas são cada vez mais comuns: algumas infraestruturas combinam input de dados externos com cálculo verificável, ou utilizam provas de zero-knowledge para reforçar a integridade dos dados dos oracles. Optar estritamente entre um ou outro pode ignorar estes modelos híbridos.

O custo e a latência são fatores relevantes. Gerar provas ZK requer hardware especializado e tem maior overhead para cálculo generalista em comparação com execução nativa. Os oracles são afetados pela frequência de atualização, cobertura de nodos e latência de agregação. As comparações devem ser específicas ao cenário, não baseadas num único critério.

Resumo

Oracles e ZK coprocessors como Brevis abordam desafios distintos em extremos opostos do fluxo de dados da blockchain: os oracles trazem dados externos on-chain, baseando-se em pressupostos de confiança e incentivos económicos; os ZK coprocessors permitem cálculos verificáveis sobre dados históricos on-chain, baseando-se na integridade matemática das provas de zero-knowledge. Cada um desempenha um papel único em direção dos dados, modelo de confiança e capacidade de cálculo, e os seus limites não são absolutos. Na prática, abordagens híbridas são frequentemente utilizadas para máxima eficácia.

Perguntas Frequentes

Podem os Oracles e os ZK Coprocessors substituir-se mutuamente?

Não, não podem substituir-se diretamente. Os oracles são responsáveis por trazer dados externos, off-chain, para on-chain, enquanto os ZK coprocessors realizam cálculos verificáveis sobre dados históricos já existentes on-chain. Operam em pontos diferentes do fluxo de dados e são frequentemente usados de forma colaborativa ou combinada numa única aplicação.

Qual é a diferença central entre Brevis e Oracles?

A diferença central reside na direção dos dados e no modelo de confiança. Os oracles trazem principalmente dados externos para on-chain, com confiança baseada em nodos/multisig e incentivos económicos. Brevis e ZK coprocessors similares calculam dados históricos on-chain e devolvem provas de zero-knowledge, permitindo verificação matemática dos resultados diretamente on-chain.

Porque são os ZK Coprocessors considerados trust-minimized?

Os ZK coprocessors tornam o processo de cálculo verificável: desde que a prova de zero-knowledge on-chain seja válida, confirma que os dados relevantes existem e que o cálculo foi executado corretamente — não é necessário confiar em terceiros para reporte de dados ou cálculo. Por isso são considerados trust-minimized.

Os Oracles utilizam provas de zero-knowledge?

Algumas soluções de oracle utilizam provas de zero-knowledge para reforçar a integridade ou privacidade dos dados, mas a sua função principal continua a ser trazer dados externos para on-chain. Nos oracles, as provas de zero-knowledge são normalmente um reforço, enquanto nos ZK coprocessors são o mecanismo central para verificar a correção computacional.

Pode uma aplicação utilizar ambos, Oracles e ZK Coprocessors?

Sim. Uma aplicação DeFi pode, por exemplo, utilizar oracles para obter preços de ativos em tempo real e ZK coprocessors para calcular incentivos ou controlo de risco com base no histórico real on-chain dos utilizadores, abordando tanto requisitos de “dados externos on-chain” como de “cálculo de dados históricos on-chain”.