Quando os Agentes de IA Obtêm Execução On-Chain: Quem Verifica as Informações que Veem e as Instruções que Emitem?

Cada vez mais Agentes de IA estão a obter capacidades de execução on-chain através de contas inteligentes, carteiras de estratégia ou serviços de assinatura restrita

I. O que o incidente da KelpDAO expôs

Em 18 de abril de 2026, a ponte cross-chain de rsETH da KelpDAO foi atacada, resultando na libertação anómala de 116.500 rsETH, no valor de aproximadamente 292 milhões de dólares na altura. O relatório de incidente da LayerZero mostrou que o atacante obteve chaves de sessão de programador através de engenharia social, contaminou o RPC interno do qual o DVN da LayerZero Labs dependia e suprimiu RPCs externos com ataques de negação de serviço, fazendo com que o serviço de assinatura emitisse provas para mensagens falsas com base em dados errados. A KelpDAO tinha alterado o caminho de verificação de 2-de-2 para 1-de-1 DVN. Uma vez que o único DVN designado emitisse uma prova errada, o sistema já não exigia um segundo DVN independente para verificação cruzada da mesma mensagem. A CrowdStrike e a Mandiant atribuíram o incidente com elevada confiança ao TraderTraitor (UNC4899), associado à Coreia do Norte.

Este tipo de incidente não é isolado. Em muitos grandes incidentes de segurança on-chain, o problema muitas vezes não está na quebra dos pressupostos criptográficos em si, mas sim no controlo de chaves, fontes de dados, configuração de validadores, implementação de protocolos e permissões operacionais — o sistema não só precisa de responder "esta assinatura é válida?", mas também "quem tem autoridade para assinar, com base em que informação, e se o estado correspondente à assinatura realmente ocorreu".

Cada vez mais Agentes de IA estão a obter capacidades de execução on-chain através de contas inteligentes, carteiras de estratégia ou serviços de assinatura restrita. Uma assinatura válida apenas prova que um determinado caminho de autorização foi invocado; não prova que os dados em que o Agente se baseia são fiáveis, que a decisão está em conformidade com a estratégia estabelecida, ou que esta transação deveria mesmo ocorrer neste momento. O objeto de verificação está a expandir-se da "autenticidade da assinatura" para a "consistência entre entrada, decisão e execução".

II. O que as soluções existentes resolvem e o que deixam por resolver

As várias soluções existentes resolvem parte do problema de confiança, mas cada uma deposita a confiança restante em diferentes intervenientes:

Oráculos e arbitragem de disputas: Os resultados de mercado da Polymarket são inicialmente propostos pelos participantes, e só entram na votação de detentores de tokens da UMA se forem contestados durante o período de desafio. O problema não é a "falta de verificação", mas sim a fiabilidade da verificação — quando as regras são ambíguas, os eventos reais têm múltiplas interpretações, ou o poder de voto está concentrado em poucos endereços, o sistema está na prática a transferir a questão de "quem define os factos" para outra estrutura de governação.

Multisig de pontes cross-chain e DVNs: Ambos têm implementações diferentes, mas exigem que a aplicação configure explicitamente o conjunto de validadores e o limiar. Depois de a KelpDAO configurar o caminho como 1-de-1 DVN, todo o caminho de verificação passou a depender de um único serviço de verificação; e as fontes de dados e mecanismos de resposta a falhas dos quais esse serviço depende podem formar outro ponto único de falha na camada seguinte.

Custódia MPC: O ponto de venda das assinaturas de limiar é que a chave nunca existe completa num único local, mas a fragmentação criptográfica não traz automaticamente a descentralização do poder a nível organizacional. De acordo com o que a equipa da Multichain divulgou na altura, depois de o fundador ter sido detido pela polícia chinesa, a equipa perdeu imediatamente o acesso aos servidores dos nós MPC relevantes, que estavam a correr na conta pessoal de nuvem do fundador. Quando a conta de nuvem, as permissões operacionais e a resposta a emergências estão concentradas numa única pessoa, o design de limiar do MPC ainda pode deixar um ponto único de falha a nível organizacional.

TEE: Os ambientes de execução confiáveis podem isolar código e dados sensíveis, mas não eliminam a confiança, apenas mudam onde ela é depositada. A raiz de confiança de hardware e as atualizações de microcódigo geralmente dependem do fabricante do chip, enquanto o código do enclave, as permissões de atualização e as políticas de atestação podem ser controlados pela equipa do projeto ou pelo operador. O TEE pode proteger o processo de computação, mas não pode distribuir automaticamente essas permissões de governação.

Os modos de falha destas soluções são diferentes, mas apontam para o mesmo tipo de problema: os limiares e a descentralização escritos nos whitepapers só constituem uma verdadeira fronteira de segurança quando são realmente implementados nas fontes de dados, permissões de conta, chaves de atualização e processos de governação.

III. CRVA: Redesenhar a distribuição do poder de verificação

A DeepSafe foi renomeada a partir da Bool Network em 2025. O CRVA dá continuidade às ideias técnicas propostas pelos investigadores associados à Bool Network em 2022. O artigo relevante foi publicado no IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072), propondo uma plataforma de notarização cross-chain baseada num "comité oculto em evolução" (evolving hidden committee).

A abordagem concreta é a seguinte: os nós participam numa seleção aleatória através de Ring-VRF; os selecionados submetem provas e chaves públicas temporárias; observadores externos podem verificar a sua elegibilidade, mas têm dificuldade em identificar a sua identidade de longo prazo. O comité temporário selecionado assina então coletivamente através de MPC de limiar, e nenhum nó individual pode produzir o resultado de forma independente. Processos críticos como a gestão de chaves são executados em TEE (com o Intel SGX como exemplo) de acordo com o design do artigo, com o objetivo de reduzir a possibilidade de o operador do host ler ou adulterar as partes da chave. O comité também é rotacionado por época; a nova geração obtém novas partes através de uma transferência de chave verificável, e as partes antigas tornam-se inválidas. O período de rotação específico é determinado pelos parâmetros reais da rede.

A equipa do projeto também espera usar o TEE para ocultar o estado de funcionamento do comité, dificultando que os operadores de nós determinem se os seus nós participaram numa determinada verificação. Até que ponto este objetivo pode ser alcançado depende do código da rede atual, da atestação remota, dos metadados do lado do host e das proteções contra canais laterais; não é uma conclusão que decorra automaticamente do "uso de TEE".

Mas estes mecanismos resolvem "quem verifica e como produzir resultados de forma segura e coletiva", e não definem automaticamente "que resultado é correto". No cenário de Agentes de IA, o comité ainda precisa de chegar a conclusões com base em estratégias predefinidas, fontes de dados e regras de julgamento executáveis — se essas regras tiverem problemas, se as fontes de dados forem pouco fiáveis, ou se o objeto de verificação não tiver uma resposta objetivamente determinável, mesmo um comité muito seguro pode confirmar coletivamente uma conclusão errada.

O CRVA tenta reduzir os riscos decorrentes da exposição prolongada de validadores fixos e da concentração de autoridade de assinatura, mas não pode eliminar completamente os pontos únicos de falha a nível de governação e implementação. A admissão de nós, as atualizações de protocolo, a atestação TEE e a segurança do software ainda precisam de auditoria contínua. Partindo do princípio de que as partes antigas são invalidadas de forma fiável e o novo comité mantém independência suficiente, a rotação pode encurtar a janela de ataque contra um grupo de assinatura fixo, mas não pode cobrir riscos sistémicos como a cadeia de fornecimento de software ou as permissões de atualização.

IV. Base técnica e progresso de implementação

A linhagem técnica do CRVA remonta ao artigo da Bool Network publicado no volume 17 do IEEE TIFS (2022), com DOI 10.1109/TIFS.2022.3209546. O modelo de protocolo, as provas de segurança e a avaliação do protótipo no artigo foram sujeitos a revisão por pares, fornecendo uma base académica para designs como comités ocultos dinâmicos, Ring-VRF, gestão de chaves de limiar e proteção TEE. É necessário distinguir que a revisão por pares se aplica ao modelo e à implementação descritos no artigo; a forma como o CRVA atualmente implementado pela DeepSafe corresponde ao esquema do artigo ainda precisa de ser avaliada em conjunto com as especificações técnicas atuais, auditorias de código e parâmetros de rede.

De acordo com a divulgação da DeepSafe em outubro de 2025, a rede tinha processado cumulativamente quase 120 milhões de verificações, com mais de 2,65 milhões de contas ativas. A equipa do projeto também afirmou que as suas relações de ecossistema ultrapassavam 70, envolvendo diferentes tipos, como compatibilidade de carteiras, integração técnica, investimento e cooperação de mercado.

Em outubro de 2025, a DeepSafe anunciou a conclusão de uma ronda seed de 3 milhões de dólares, com investidores incluindo Antalpha Global, ViaBTC Capital e Gate 1. Pela linha temporal, esta ronda de financiamento corresponde principalmente à investigação e desenvolvimento técnico e à expansão do ecossistema após a mudança de marca.

V. De solução de verificação a infraestrutura genérica

À medida que a infraestrutura de blockchain se torna gradualmente modular, o consenso, a execução, a disponibilidade de dados, a interoperabilidade e os sistemas de contas passam a ser assumidos por diferentes componentes. A modularidade não faz desaparecer o problema da confiança, mas torna as fronteiras de segurança de cada camada mais claras — os programadores não só precisam de escolher que tecnologia usar, como também de avaliar quem fornece a garantia de segurança dessa camada e quem é responsável quando algo corre mal. Depois de os Agentes de IA obterem capacidades de execução on-chain, surgem novas questões: quem confirma que os dados que leem são fiáveis, que as decisões não excedem a autorização e que a transação final é consistente com a autorização do utilizador? Estas questões não são automaticamente respondidas por uma assinatura válida.

A DeepSafe espera abstrair a capacidade de verificação de um módulo acessório interno de uma única aplicação para uma infraestrutura que possa ser invocada por diferentes protocolos e Agentes de IA — "Proof, Not Promises", substituindo as promessas do executor por provas verificáveis. O CRVA já combinou seleção aleatória anónima, colaboração de limiar e TEE num caminho técnico; se conseguirá cobrir ainda mais cenários como oráculos, cross-chain e Agentes de IA, e evoluir para uma infraestrutura de verificação genérica, dependerá da capacidade da rede atual, de auditorias independentes e da acumulação contínua de integrações reais.