15 postagens marcadas com "IA"

O Protocolo de Pagamentos por Agente (AP2) do Google é um padrão aberto recém-anunciado, projetado para permitir transações seguras e confiáveis iniciadas por agentes de IA em nome dos usuários. Desenvolvido em colaboração com mais de 60 organizações de pagamentos e tecnologia (incluindo grandes redes de pagamento, bancos, fintechs e empresas Web3), o AP2 estabelece uma linguagem comum para pagamentos “agênticos” – ou seja, compras e transações financeiras que um agente autônomo (como um assistente de IA ou um agente baseado em LLM) pode realizar para um usuário. A criação do AP2 é impulsionada por uma mudança fundamental: tradicionalmente, os sistemas de pagamento online assumiam que um humano estava clicando diretamente em “comprar”, mas o surgimento de agentes de IA agindo sob as instruções do usuário quebra essa suposição. O AP2 aborda os desafios resultantes de autorização, autenticidade e responsabilidade no comércio impulsionado por IA, mantendo-se compatível com a infraestrutura de pagamento existente. Este relatório examina a arquitetura técnica do AP2, seu propósito e casos de uso, integrações com agentes de IA e provedores de pagamento, considerações de segurança e conformidade, comparações com protocolos existentes, implicações para sistemas Web3/descentralizados e a adoção/roteiro da indústria.

Arquitetura Técnica: Como o AP2 Funciona​

Em sua essência, o AP2 introduz uma estrutura de transação criptograficamente segura construída sobre credenciais digitais verificáveis (VDCs) – essencialmente objetos de dados assinados e à prova de adulteração que servem como “contratos” digitais do que o usuário autorizou. Na terminologia do AP2, esses contratos são chamados de Mandatos, e eles formam uma cadeia de evidências auditável para cada transação. Existem três tipos principais de mandatos na arquitetura do AP2:

• Mandato de Intenção: Captura as instruções ou condições iniciais do usuário para uma compra, especialmente para cenários “humano-ausente” (onde o agente agirá mais tarde sem o usuário online). Ele define o escopo de autoridade que o usuário concede ao agente – por exemplo, “Comprar ingressos para o show se o preço cair abaixo de $200, até 2 ingressos”. Este mandato é assinado criptograficamente antecipadamente pelo usuário e serve como prova verificável de consentimento dentro de limites específicos.
• Mandato de Carrinho: Representa os detalhes finais da transação que o usuário aprovou, usado em cenários “humano-presente” ou no momento do checkout. Inclui os itens ou serviços exatos, seu preço e outras particularidades da compra. Quando o agente está pronto para concluir a transação (por exemplo, após preencher um carrinho de compras), o comerciante primeiro assina criptograficamente o conteúdo do carrinho (garantindo os detalhes do pedido e o preço), e então o usuário (através de seu dispositivo ou interface do agente) assina para criar um Mandato de Carrinho. Isso garante o que você vê é o que você paga, fixando o pedido final exatamente como apresentado ao usuário.
• Mandato de Pagamento: Uma credencial separada que é enviada à rede de pagamento (por exemplo, rede de cartão ou banco) para sinalizar que um agente de IA está envolvido na transação. O Mandato de Pagamento inclui metadados como se o usuário estava presente ou não durante a autorização e serve como um sinalizador para sistemas de gerenciamento de risco. Ao fornecer aos bancos adquirentes e emissores evidências criptograficamente verificáveis da intenção do usuário, este mandato os ajuda a avaliar o contexto (por exemplo, distinguindo uma compra iniciada por agente de uma fraude típica) e a gerenciar a conformidade ou responsabilidade de acordo.

Todos os mandatos são implementados como credenciais verificáveis assinadas pelas chaves da parte relevante (usuário, comerciante, etc.), gerando uma trilha de auditoria não-repudiável para cada transação liderada por agente. Na prática, o AP2 usa uma arquitetura baseada em funções para proteger informações sensíveis – por exemplo, um agente pode lidar com um Mandato de Intenção sem nunca ver os detalhes brutos de pagamento, que são revelados de forma controlada apenas quando necessário, preservando a privacidade. A cadeia criptográfica de intenção do usuário → compromisso do comerciante → autorização de pagamento estabelece confiança entre todas as partes de que a transação reflete as verdadeiras instruções do usuário e que tanto o agente quanto o comerciante aderiram a essas instruções.

Fluxo de Transação: Para ilustrar como o AP2 funciona de ponta a ponta, considere um cenário de compra simples com um humano no circuito:

1. Solicitação do Usuário: O usuário pede ao seu agente de IA para comprar um item ou serviço específico (por exemplo, “Pedir este par de sapatos no meu tamanho”).
2. Construção do Carrinho: O agente se comunica com os sistemas do comerciante (usando APIs padrão ou através de uma interação agente-para-agente) para montar um carrinho de compras para o item especificado a um determinado preço.
3. Garantia do Comerciante: Antes de apresentar o carrinho ao usuário, o lado do comerciante assina criptograficamente os detalhes do carrinho (item, quantidade, preço, etc.). Esta etapa cria uma oferta assinada pelo comerciante que garante os termos exatos (evitando quaisquer alterações ocultas ou manipulação de preços).
4. Aprovação do Usuário: O agente mostra ao usuário o carrinho finalizado. O usuário confirma a compra, e esta aprovação aciona duas assinaturas criptográficas do lado do usuário: uma no Mandato de Carrinho (para aceitar o carrinho do comerciante como está) e uma no Mandato de Pagamento (para autorizar o pagamento através do provedor de pagamento escolhido). Esses mandatos assinados são então compartilhados com o comerciante e a rede de pagamento, respectivamente.
5. Execução: Munidos do Mandato de Carrinho e do Mandato de Pagamento, o comerciante e o provedor de pagamento prosseguem para executar a transação com segurança. Por exemplo, o comerciante envia a solicitação de pagamento juntamente com a prova de aprovação do usuário para a rede de pagamento (rede de cartão, banco, etc.), que pode verificar o Mandato de Pagamento. O resultado é uma transação de compra concluída com uma trilha de auditoria criptográfica que vincula a intenção do usuário ao pagamento final.

Este fluxo demonstra como o AP2 constrói confiança em cada etapa de uma compra impulsionada por IA. O comerciante tem prova criptográfica do que exatamente o usuário concordou em comprar e a que preço, e o emissor/banco tem prova de que o usuário autorizou esse pagamento, mesmo que um agente de IA tenha facilitado o processo. Em caso de disputas ou erros, os mandatos assinados atuam como evidência clara, ajudando a determinar a responsabilidade (por exemplo, se o agente se desviou das instruções ou se uma cobrança não foi o que o usuário aprovou). Em essência, a arquitetura do AP2 garante que a intenção verificável do usuário – em vez da confiança no comportamento do agente – seja a base da transação, reduzindo grandemente a ambiguidade.

Propósito e Casos de Uso para o AP2​

Por que o AP2 é Necessário: O propósito principal do AP2 é resolver problemas emergentes de confiança e segurança que surgem quando agentes de IA podem gastar dinheiro em nome dos usuários. O Google e seus parceiros identificaram várias questões-chave que a infraestrutura de pagamento atual não consegue responder adequadamente quando um agente autônomo está no circuito:

• Autorização: Como provar que um usuário realmente deu permissão ao agente para fazer uma compra específica? (Em outras palavras, garantir que o agente não está comprando coisas sem o consentimento informado do usuário.)
• Autenticidade: Como um comerciante pode saber que uma solicitação de compra de um agente é genuína e reflete a verdadeira intenção do usuário, em vez de um erro ou alucinação da IA?
• Responsabilidade: Se uma transação fraudulenta ou incorreta ocorrer via um agente, quem é o responsável – o usuário, o comerciante, o provedor de pagamento ou o criador do agente de IA?

Sem uma solução, essas incertezas criam uma “crise de confiança” em torno do comércio liderado por agentes. A missão do AP2 é fornecer essa solução, estabelecendo um protocolo uniforme para transações seguras de agentes. Ao introduzir mandatos padronizados e provas de intenção, o AP2 previne um ecossistema fragmentado, onde cada empresa inventa seus próprios métodos ad-hoc de pagamento por agente. Em vez disso, qualquer agente de IA compatível pode interagir com qualquer comerciante/provedor de pagamento compatível sob um conjunto comum de regras e verificações. Essa consistência não apenas evita a confusão do usuário e do comerciante, mas também oferece às instituições financeiras uma maneira clara de gerenciar o risco para pagamentos iniciados por agentes, em vez de lidar com uma colcha de retalhos de abordagens proprietárias. Em suma, o propósito do AP2 é ser uma camada fundamental de confiança que permite que a “economia de agentes” cresça sem quebrar o ecossistema de pagamentos.

Casos de Uso Pretendidos: Ao resolver os problemas acima, o AP2 abre as portas para novas experiências de comércio e casos de uso que vão além do que é possível com um humano clicando manualmente nas compras. Alguns exemplos de comércio habilitado por agente que o AP2 suporta incluem:

• Compras Mais Inteligentes: Um cliente pode instruir seu agente: “Quero esta jaqueta de inverno em verde, e estou disposto a pagar até 20% acima do preço atual por ela”. Munido de um Mandato de Intenção que codifica essas condições, o agente monitorará continuamente sites de varejistas ou bancos de dados. No momento em que a jaqueta estiver disponível em verde (e dentro do limite de preço), o agente executa automaticamente uma compra com uma transação segura e assinada – capturando uma venda que de outra forma teria sido perdida. Toda a interação, desde a solicitação inicial do usuário até o checkout automatizado, é governada pelos mandatos do AP2, garantindo que o agente compre exatamente o que foi autorizado.
• Ofertas Personalizadas: Um usuário diz ao seu agente que está procurando um produto específico (digamos, uma nova bicicleta) de um determinado comerciante para uma próxima viagem. O agente pode compartilhar esse interesse (dentro dos limites de um Mandato de Intenção) com o agente de IA do próprio comerciante, incluindo contexto relevante como a data da viagem. O agente do comerciante, conhecendo a intenção e o contexto do usuário, poderia responder com um pacote personalizado ou desconto – por exemplo, “bicicleta + capacete + bagageiro com 15% de desconto, disponível pelas próximas 48 horas”. Usando o AP2, o agente do usuário pode aceitar e concluir esta oferta personalizada com segurança, transformando uma simples consulta em uma venda mais valiosa para o comerciante.
• Tarefas Coordenadas: Um usuário planejando uma tarefa complexa (por exemplo, uma viagem de fim de semana) a delega inteiramente: “Reserve-me um voo e hotel para estas datas com um orçamento total de $700”. O agente pode interagir com agentes de vários provedores de serviços – companhias aéreas, hotéis, plataformas de viagem – para encontrar uma combinação que se ajuste ao orçamento. Uma vez identificado um pacote de voo-hotel adequado, o agente usa o AP2 para executar múltiplas reservas de uma só vez, cada uma criptograficamente assinada (por exemplo, emitindo Mandatos de Carrinho separados para a companhia aérea e o hotel, ambos autorizados sob o Mandato de Intenção do usuário). O AP2 garante que todas as partes desta transação coordenada ocorram conforme aprovado, e até permite a execução simultânea para que passagens e reservas sejam feitas juntas sem risco de uma parte falhar no meio do caminho.

Esses cenários ilustram apenas alguns dos casos de uso pretendidos do AP2. De forma mais ampla, o design flexível do AP2 suporta tanto fluxos de e-commerce convencionais quanto modelos de comércio totalmente novos. Por exemplo, o AP2 pode facilitar serviços semelhantes a assinaturas (um agente mantém você abastecido com itens essenciais comprando quando as condições são atendidas), compras orientadas por eventos (comprar ingressos ou itens no instante em que um evento acionador ocorre), negociações de agentes em grupo (agentes de múltiplos usuários agrupando mandatos para negociar um acordo em grupo) e muitos outros padrões emergentes. Em todos os casos, o fio condutor é que o AP2 fornece a estrutura de confiança – autorização clara do usuário e auditabilidade criptográfica – que permite que essas transações impulsionadas por agentes ocorram com segurança. Ao lidar com a camada de confiança e verificação, o AP2 permite que desenvolvedores e empresas se concentrem em inovar novas experiências de comércio de IA sem reinventar a segurança de pagamentos do zero.

Integração com Agentes, LLMs e Provedores de Pagamento​

O AP2 é explicitamente projetado para se integrar perfeitamente com frameworks de agentes de IA e com sistemas de pagamento existentes, atuando como uma ponte entre os dois. O Google posicionou o AP2 como uma extensão de seus padrões de protocolo Agent2Agent (A2A) e Model Context Protocol (MCP). Em outras palavras, se o A2A fornece uma linguagem genérica para agentes se comunicarem tarefas e o MCP padroniza como os modelos de IA incorporam contexto/ferramentas, então o AP2 adiciona uma camada de transações por cima para o comércio. Os protocolos são complementares: o A2A lida com a comunicação agente-para-agente (permitindo, por exemplo, que um agente de compras converse com o agente de um comerciante), enquanto o AP2 lida com a autorização de pagamento agente-para-comerciante dentro dessas interações. Como o AP2 é aberto e não proprietário, ele é destinado a ser agnóstico em relação a frameworks: os desenvolvedores podem usá-lo com o próprio Agent Development Kit (ADK) do Google ou qualquer biblioteca de agentes de IA, e da mesma forma, pode funcionar com vários modelos de IA, incluindo LLMs. Um agente baseado em LLM, por exemplo, poderia usar o AP2 gerando e trocando os payloads de mandato necessários (guiado pela especificação AP2) em vez de apenas texto livre. Ao impor um protocolo estruturado, o AP2 ajuda a transformar a intenção de alto nível de um agente de IA (que pode vir do raciocínio de um LLM) em transações concretas e seguras.

No lado dos pagamentos, o AP2 foi construído em conjunto com provedores de pagamento e padrões tradicionais, em vez de ser um sistema de substituição total. O protocolo é agnóstico em relação ao método de pagamento, o que significa que pode suportar uma variedade de trilhos de pagamento – desde redes de cartão de crédito/débito até transferências bancárias e carteiras digitais – como o método subjacente para movimentar fundos. Em sua versão inicial, o AP2 enfatiza a compatibilidade com pagamentos por cartão, já que são os mais comuns no comércio online. O Mandato de Pagamento do AP2 é projetado para se encaixar no fluxo de processamento de cartão existente: ele fornece dados adicionais à rede de pagamento (por exemplo, Visa, Mastercard, Amex) e ao banco emissor de que um agente de IA está envolvido e se o usuário estava presente, complementando assim as verificações existentes de detecção de fraude e autorização. Essencialmente, o AP2 não processa o pagamento em si; ele aumenta a solicitação de pagamento com prova criptográfica da intenção do usuário. Isso permite que os provedores de pagamento tratem as transações iniciadas por agentes com a cautela ou velocidade apropriadas (por exemplo, um emissor pode aprovar uma compra de aparência incomum se vir um mandato AP2 válido provando que o usuário a pré-aprovou). Notavelmente, o Google e seus parceiros planejam evoluir o AP2 para suportar também métodos de pagamento “push” – como transferências bancárias em tempo real (como os sistemas UPI da Índia ou PIX do Brasil) – e outros tipos emergentes de pagamento digital. Isso indica que a integração do AP2 se expandirá além dos cartões, alinhando-se às tendências de pagamento modernas em todo o mundo.

Para comerciantes e processadores de pagamento, integrar o AP2 significaria suportar as mensagens de protocolo adicionais (mandatos) e verificar assinaturas. Muitas grandes plataformas de pagamento já estão envolvidas na formação do AP2, então podemos esperar que elas construam suporte para ele. Por exemplo, empresas como Adyen, Worldpay, Paypal, Stripe (não explicitamente nomeadas no blog, mas provavelmente interessadas) e outras poderiam incorporar o AP2 em suas APIs de checkout ou SDKs, permitindo que um agente inicie um pagamento de forma padronizada. Como o AP2 é uma especificação aberta no GitHub com implementações de referência, provedores de pagamento e plataformas de tecnologia podem começar a experimentá-lo imediatamente. O Google também mencionou um AI Agent Marketplace onde agentes de terceiros podem ser listados – espera-se que esses agentes suportem o AP2 para quaisquer capacidades transacionais. Na prática, uma empresa que constrói um assistente de vendas de IA ou um agente de compras pode listá-lo neste marketplace, e graças ao AP2, esse agente pode realizar compras ou pedidos de forma confiável.

Finalmente, a história de integração do AP2 se beneficia de seu amplo apoio da indústria. Ao co-desenvolver o protocolo com grandes instituições financeiras e empresas de tecnologia, o Google garantiu que o AP2 se alinha com as regras e requisitos de conformidade existentes na indústria. A colaboração com redes de pagamento (por exemplo, Mastercard, UnionPay), emissores (por exemplo, American Express), fintechs (por exemplo, Revolut, Paypal), players de e-commerce (por exemplo, Etsy) e até provedores de identidade/segurança (por exemplo, Okta, Cloudflare) sugere que o AP2 está sendo projetado para se encaixar em sistemas do mundo real com atrito mínimo. Esses stakeholders trazem experiência em áreas como KYC (regulamentações Conheça Seu Cliente), prevenção de fraude e privacidade de dados, ajudando o AP2 a atender a essas necessidades desde o início. Em resumo, o AP2 é construído para ser amigo do agente e amigo do provedor de pagamento: ele estende os protocolos existentes de agentes de IA para lidar com transações, e se sobrepõe às redes de pagamento existentes para utilizar sua infraestrutura, adicionando as garantias de confiança necessárias.

Considerações de Segurança, Conformidade e Interoperabilidade​

Segurança e confiança estão no cerne do design do AP2. O uso de criptografia pelo protocolo (assinaturas digitais em mandatos) garante que cada ação crítica em uma transação agêntica seja verificável e rastreável. Essa não-repudiação é crucial: nem o usuário nem o comerciante podem negar posteriormente o que foi autorizado e acordado, já que os mandatos servem como registros seguros. Um benefício direto é na prevenção de fraudes e resolução de disputas – com o AP2, se um agente malicioso ou com bugs tentar uma compra não autorizada, a falta de um mandato válido assinado pelo usuário seria evidente, e a transação pode ser recusada ou revertida. Inversamente, se um usuário alegar “Eu nunca aprovei esta compra”, mas um Mandato de Carrinho existir com sua assinatura criptográfica, o comerciante e o emissor têm fortes evidências para apoiar a cobrança. Essa clareza de responsabilidade responde a uma grande preocupação de conformidade para a indústria de pagamentos.

Autorização e Privacidade: O AP2 impõe uma etapa (ou etapas) de autorização explícita do usuário para transações lideradas por agentes, o que se alinha às tendências regulatórias como a autenticação forte do cliente. O princípio de Controle do Usuário incorporado ao AP2 significa que um agente não pode gastar fundos a menos que o usuário (ou alguém delegado pelo usuário) tenha fornecido uma instrução verificável para fazê-lo. Mesmo em cenários totalmente autônomos, o usuário predefine as regras por meio de um Mandato de Intenção. Essa abordagem pode ser vista como análoga a conceder uma procuração ao agente para transações específicas, mas de forma digitalmente assinada e granular. Do ponto de vista da privacidade, o AP2 é cuidadoso com o compartilhamento de dados: o protocolo usa uma arquitetura de dados baseada em funções para garantir que informações sensíveis (como credenciais de pagamento ou detalhes pessoais) sejam compartilhadas apenas com as partes que absolutamente precisam delas. Por exemplo, um agente pode enviar um Mandato de Carrinho a um comerciante contendo informações de item e preço, mas o número real do cartão do usuário pode ser compartilhado apenas através do Mandato de Pagamento com o processador de pagamento, não com o agente ou comerciante. Isso minimiza a exposição desnecessária de dados, auxiliando na conformidade com as leis de privacidade e as regras PCI-DSS para o tratamento de dados de pagamento.

Conformidade e Padrões: Como o AP2 foi desenvolvido com a contribuição de entidades financeiras estabelecidas, ele foi projetado para atender ou complementar os padrões de conformidade existentes em pagamentos. O protocolo não ignora os fluxos usuais de autorização de pagamento – em vez disso, ele os aumenta com evidências e sinalizadores adicionais. Isso significa que as transações AP2 ainda podem aproveitar sistemas de detecção de fraude, verificações 3-D Secure ou quaisquer verificações regulatórias exigidas, com os mandatos do AP2 atuando como fatores de autenticação extras ou pistas de contexto. Por exemplo, um banco poderia tratar um Mandato de Pagamento como a assinatura digital de um cliente em uma transação, potencialmente simplificando a conformidade com os requisitos de consentimento do usuário. Além disso, os designers do AP2 mencionam explicitamente o trabalho “em conjunto com as regras e padrões da indústria”. Podemos inferir que, à medida que o AP2 evolui, ele pode ser levado a órgãos de padronização formais (como W3C, EMVCo ou ISO) para garantir que se alinhe aos padrões financeiros globais. O Google declarou compromisso com uma evolução aberta e colaborativa do AP2, possivelmente através de organizações de padronização. Esse processo aberto ajudará a resolver quaisquer preocupações regulatórias e a alcançar ampla aceitação, semelhante a como os padrões de pagamento anteriores (cartões com chip EMV, 3-D Secure, etc.) passaram por colaboração em toda a indústria.

Interoperabilidade: Evitar a fragmentação é um objetivo chave do AP2. Para isso, o protocolo é publicado abertamente e disponibilizado para qualquer pessoa implementar ou integrar. Não está vinculado aos serviços do Google Cloud – na verdade, o AP2 é código aberto (licença Apache-2) e a especificação, além do código de referência, está em um repositório público do GitHub. Isso incentiva a interoperabilidade porque vários fornecedores podem adotar o AP2 e ainda ter seus sistemas funcionando juntos. Já, o princípio da interoperabilidade é destacado: o AP2 é uma extensão de protocolos abertos existentes (A2A, MCP) e não é proprietário, o que significa que ele promove um ecossistema competitivo de implementações, em vez de uma solução de um único fornecedor. Em termos práticos, um agente de IA construído pela Empresa A poderia iniciar uma transação com um sistema de comerciante da Empresa B se ambos seguirem o AP2 – nenhum dos lados está preso a uma única plataforma.

Uma possível preocupação é garantir a adoção consistente: se alguns grandes players escolhessem um protocolo diferente ou uma abordagem fechada, a fragmentação ainda poderia ocorrer. No entanto, dada a ampla coalizão por trás do AP2, ele parece pronto para se tornar um padrão de fato. A inclusão de muitas empresas focadas em identidade e segurança (por exemplo, Okta, Cloudflare, Ping Identity) no ecossistema do AP2 Figura: Mais de 60 empresas de finanças, tecnologia e cripto estão colaborando no AP2 (lista parcial de parceiros). sugere que a interoperabilidade e a segurança estão sendo abordadas em conjunto. Esses parceiros podem ajudar a integrar o AP2 em fluxos de trabalho de verificação de identidade e ferramentas de prevenção de fraude, garantindo que uma transação AP2 possa ser confiável em todos os sistemas.

Do ponto de vista tecnológico, o uso de técnicas criptográficas amplamente aceitas pelo AP2 (provavelmente credenciais verificáveis baseadas em JSON-LD ou JWT, assinaturas de chave pública, etc.) o torna compatível com a infraestrutura de segurança existente. As organizações podem usar sua PKI (Infraestrutura de Chave Pública) existente para gerenciar chaves para assinar mandatos. O AP2 também parece antecipar a integração com sistemas de identidade descentralizada: o Google menciona que o AP2 cria oportunidades para inovar em áreas como identidade descentralizada para autorização de agentes. Isso significa que, no futuro, o AP2 poderia alavancar padrões DID (Identificador Descentralizado) ou verificação de identificador descentralizado para identificar agentes e usuários de forma confiável. Tal abordagem aprimoraria ainda mais a interoperabilidade, não dependendo de nenhum provedor de identidade único. Em resumo, o AP2 enfatiza a segurança através da criptografia e da responsabilidade clara, visa estar pronto para a conformidade por design e promove a interoperabilidade através de sua natureza de padrão aberto e amplo suporte da indústria.

Comparação com Protocolos Existentes​

O AP2 é um protocolo inovador que aborda uma lacuna que os frameworks de pagamento e agentes existentes não cobriram: permitir que agentes autônomos realizem pagamentos de maneira segura e padronizada. Em termos de protocolos de comunicação de agentes, o AP2 se baseia em trabalhos anteriores como o protocolo Agent2Agent (A2A). O A2A (código aberto no início de 2025) permite que diferentes agentes de IA conversem entre si, independentemente de seus frameworks subjacentes. No entanto, o A2A por si só não define como os agentes devem conduzir transações ou pagamentos – é mais sobre negociação de tarefas e troca de dados. O AP2 estende esse cenário adicionando uma camada de transação que qualquer agente pode usar quando uma conversa leva a uma compra. Em essência, o AP2 pode ser visto como complementar ao A2A e ao MCP, em vez de sobreposto: o A2A cobre os aspectos de comunicação e colaboração, o MCP cobre o uso de ferramentas/APIs externas, e o AP2 cobre pagamentos e comércio. Juntos, eles formam uma pilha de padrões para uma futura “economia de agentes”. Essa abordagem modular é um tanto análoga aos protocolos de internet: por exemplo, HTTP para comunicação de dados e SSL/TLS para segurança – aqui o A2A pode ser como o HTTP dos agentes, e o AP2 a camada transacional segura por cima para o comércio.

Ao comparar o AP2 com protocolos e padrões de pagamento tradicionais, existem paralelos e diferenças. Pagamentos online tradicionais (checkouts de cartão de crédito, transações PayPal, etc.) tipicamente envolvem protocolos como HTTPS para transmissão segura, e padrões como PCI DSS para lidar com dados de cartão, além de possivelmente 3-D Secure para autenticação adicional do usuário. Estes assumem um fluxo impulsionado pelo usuário (o usuário clica e talvez insere um código único). O AP2, por outro lado, introduz uma maneira para um terceiro (o agente) participar do fluxo sem comprometer a segurança. Poderíamos comparar o conceito de mandato do AP2 a uma extensão da autoridade delegada no estilo OAuth, mas aplicada a pagamentos. No OAuth, um usuário pode conceder a um aplicativo acesso limitado a uma conta via tokens; similarmente no AP2, um usuário concede a um agente autoridade para gastar sob certas condições via mandatos. A principal diferença é que os “tokens” do AP2 (mandatos) são instruções específicas e assinadas para transações financeiras, o que é mais granular do que as autorizações de pagamento existentes.

Outro ponto de comparação é como o AP2 se relaciona com os fluxos de checkout de e-commerce existentes. Por exemplo, muitos sites de e-commerce usam protocolos como a API Payment Request do W3C ou SDKs específicos de plataforma para agilizar pagamentos. Estes padronizam principalmente como navegadores ou aplicativos coletam informações de pagamento de um usuário, enquanto o AP2 padroniza como um agente provaria a intenção do usuário a um comerciante e processador de pagamento. O foco do AP2 na intenção verificável e na não-repudiação o diferencia de APIs de pagamento mais simples. Ele está adicionando uma camada adicional de confiança sobre as redes de pagamento. Poderíamos dizer que o AP2 não está substituindo as redes de pagamento (Visa, ACH, blockchain, etc.), mas sim as aumentando. O protocolo suporta explicitamente todos os tipos de métodos de pagamento (até cripto), então trata-se mais de padronizar a interação do agente com esses sistemas, não de criar um novo trilho de pagamento do zero.

No domínio dos protocolos de segurança e autenticação, o AP2 compartilha algum espírito com coisas como assinaturas digitais em cartões com chip EMV ou a notarização em contratos digitais. Por exemplo, transações com cartão com chip EMV geram criptogramas para provar que o cartão estava presente; o AP2 gera prova criptográfica de que o agente do usuário foi autorizado. Ambos visam prevenir fraudes, mas o escopo do AP2 é o relacionamento agente-usuário e a comunicação agente-comerciante, o que nenhum padrão de pagamento existente aborda. Outra comparação emergente é com a abstração de contas em cripto (por exemplo, ERC-4337) onde os usuários podem autorizar ações de carteira pré-programadas. Carteiras de cripto podem ser configuradas para permitir certas transações automatizadas (como pagar automaticamente uma assinatura via um contrato inteligente), mas essas são tipicamente confinadas a um ambiente de blockchain. O AP2, por outro lado, visa ser multiplataforma – ele pode alavancar blockchain para alguns pagamentos (através de suas extensões), mas também funciona com bancos tradicionais.

Não há um protocolo “concorrente” direto ao AP2 na indústria de pagamentos mainstream ainda – parece ser o primeiro esforço concertado em um padrão aberto para pagamentos por agentes de IA. Tentativas proprietárias podem surgir (ou já podem estar em andamento dentro de empresas individuais), mas o amplo suporte do AP2 lhe dá uma vantagem para se tornar o padrão. Vale a pena notar que a IBM e outros têm um Protocolo de Comunicação de Agentes (ACP) e iniciativas semelhantes para interoperabilidade de agentes, mas estas não abrangem o aspecto de pagamento de forma tão abrangente quanto o AP2. Se houver, o AP2 pode se integrar ou alavancar esses esforços (por exemplo, os frameworks de agentes da IBM poderiam implementar o AP2 para quaisquer tarefas de comércio).

Em resumo, o AP2 se distingue por visar a intersecção única de IA e pagamentos: onde protocolos de pagamento mais antigos assumiam um usuário humano, o AP2 assume um intermediário de IA e preenche a lacuna de confiança resultante. Ele estende, em vez de conflitar, os processos de pagamento existentes e complementa os protocolos de agentes existentes como o A2A. No futuro, pode-se ver o AP2 sendo usado juntamente com padrões estabelecidos – por exemplo, um Mandato de Carrinho AP2 pode funcionar em conjunto com uma chamada de API de gateway de pagamento tradicional, ou um Mandato de Pagamento AP2 pode ser anexado a uma mensagem ISO 8583 em bancos. A natureza aberta do AP2 também significa que, se surgirem abordagens alternativas, o AP2 poderia potencialmente absorvê-las ou se alinhar a elas através da colaboração da comunidade. Nesta fase, o AP2 está estabelecendo uma base que não existia antes, efetivamente pioneirando uma nova camada de protocolo na pilha de IA e pagamentos.

Implicações para Web3 e Sistemas Descentralizados​

Desde o início, o AP2 foi projetado para ser inclusivo de pagamentos baseados em Web3 e criptomoedas. O protocolo reconhece que o comércio futuro abrangerá tanto os canais fiduciários tradicionais quanto as redes blockchain descentralizadas. Como observado anteriormente, o AP2 suporta tipos de pagamento que vão desde cartões de crédito e transferências bancárias até stablecoins e criptomoedas. Na verdade, juntamente com o lançamento do AP2, o Google anunciou uma extensão específica para pagamentos cripto chamada A2A x402. Esta extensão, desenvolvida em colaboração com players da indústria cripto como Coinbase, Ethereum Foundation e MetaMask, é uma “solução pronta para produção para pagamentos cripto baseados em agentes”. O nome “x402” é uma homenagem ao código de status HTTP 402 “Payment Required”, que nunca foi amplamente utilizado na Web – a extensão cripto do AP2 efetivamente revive o espírito do HTTP 402 para agentes descentralizados que desejam cobrar ou pagar uns aos outros on-chain. Em termos práticos, a extensão x402 adapta o conceito de mandato do AP2 para transações blockchain. Por exemplo, um agente poderia manter um Mandato de Intenção assinado de um usuário e então executar um pagamento on-chain (digamos, enviar uma stablecoin) uma vez que as condições sejam atendidas, anexando a prova do mandato a essa transação on-chain. Isso une a estrutura de confiança off-chain do AP2 com a natureza sem confiança da blockchain, oferecendo o melhor dos dois mundos: um pagamento on-chain que partes off-chain (usuários, comerciantes) podem confiar que foi autorizado pelo usuário.

A sinergia entre AP2 e Web3 é evidente na lista de colaboradores. Exchanges de cripto (Coinbase), fundações blockchain (Ethereum Foundation), carteiras cripto (MetaMask) e startups Web3 (por exemplo, Mysten Labs da Sui, Lightspark para Lightning Network) estão envolvidas no desenvolvimento do AP2. Sua participação sugere que o AP2 é visto como complementar às finanças descentralizadas, em vez de competitivo. Ao criar uma maneira padrão para agentes de IA interagirem com pagamentos cripto, o AP2 pode impulsionar mais o uso de cripto em aplicações impulsionadas por IA. Por exemplo, um agente de IA pode usar o AP2 para alternar perfeitamente entre pagar com cartão de crédito ou pagar com uma stablecoin, dependendo da preferência do usuário ou da aceitação do comerciante. A extensão A2A x402 permite especificamente que os agentes monetizem ou paguem por serviços por meios on-chain, o que pode ser crucial em mercados descentralizados do futuro. Isso sugere que agentes possivelmente operando como atores econômicos autônomos em blockchain (um conceito que alguns se referem como DACs ou DAOs) serão capazes de lidar com pagamentos necessários para serviços (como pagar uma pequena taxa a outro agente por informações). O AP2 poderia fornecer a língua franca para tais transações, garantindo que, mesmo em uma rede descentralizada, o agente tenha um mandato comprovável para o que está fazendo.

Em termos de concorrência, poderíamos perguntar: soluções puramente descentralizadas tornam o AP2 desnecessário, ou vice-versa? É provável que o AP2 coexistirá com soluções Web3 em uma abordagem em camadas. As finanças descentralizadas oferecem execução sem confiança (contratos inteligentes, etc.), mas não resolvem inerentemente o problema de “Um IA teve permissão de um humano para fazer isso?”. O AP2 aborda exatamente esse elo de confiança humano-para-IA, que continua sendo importante mesmo que o pagamento em si seja on-chain. Em vez de competir com protocolos blockchain, o AP2 pode ser visto como uma ponte entre eles e o mundo off-chain. Por exemplo, um contrato inteligente pode aceitar uma determinada transação apenas se ela incluir uma referência a uma assinatura de mandato AP2 válida – algo que poderia ser implementado para combinar a prova de intenção off-chain com a execução on-chain. Inversamente, se houver frameworks de agentes cripto-nativos (alguns projetos blockchain exploram agentes autônomos que operam com fundos cripto), eles podem desenvolver seus próprios métodos de autorização. O amplo suporte da indústria ao AP2, no entanto, pode levar até mesmo esses projetos a adotar ou integrar-se ao AP2 para consistência.

Outro ângulo é a identidade e credenciais descentralizadas. O uso de credenciais verificáveis pelo AP2 está muito alinhado com a abordagem da Web3 para a identidade (por exemplo, DIDs e VCs padronizados pelo W3C). Isso significa que o AP2 poderia se conectar a sistemas de identidade descentralizada – por exemplo, o DID de um usuário poderia ser usado para assinar um mandato AP2, que um comerciante poderia verificar contra uma blockchain ou um hub de identidade. A menção de explorar a identidade descentralizada para autorização de agentes reforça que o AP2 pode alavancar inovações de identidade Web3 para verificar identidades de agentes e usuários de forma descentralizada, em vez de depender apenas de autoridades centralizadas. Este é um ponto de sinergia, pois tanto o AP2 quanto a Web3 visam dar aos usuários mais controle e prova criptográfica de suas ações.

Potenciais conflitos podem surgir apenas se alguém imaginar um ecossistema de comércio totalmente descentralizado sem papel para grandes intermediários – nesse cenário, o AP2 (inicialmente impulsionado pelo Google e parceiros) poderia ser muito centralizado ou governado por players tradicionais? É importante notar que o AP2 é de código aberto e destinado a ser padronizável, portanto, não é proprietário do Google. Isso o torna mais palatável para a comunidade Web3, que valoriza protocolos abertos. Se o AP2 for amplamente adotado, ele pode reduzir a necessidade de protocolos de pagamento específicos da Web3 separados para agentes, unificando assim os esforços. Por outro lado, alguns projetos blockchain podem preferir mecanismos de autorização puramente on-chain (como carteiras multi-assinatura ou lógica de custódia on-chain) para transações de agentes, especialmente em ambientes sem confiança e sem autoridades centralizadas. Essas poderiam ser vistas como abordagens alternativas, mas provavelmente permaneceriam nichadas, a menos que possam interagir com sistemas off-chain. O AP2, ao cobrir ambos os mundos, pode realmente acelerar a adoção da Web3 ao tornar a cripto apenas mais um método de pagamento que um agente de IA pode usar perfeitamente. De fato, um parceiro observou que “stablecoins fornecem uma solução óbvia para desafios de escalabilidade [para] sistemas agênticos com infraestrutura legada”, destacando que a cripto pode complementar o AP2 no tratamento de escala ou cenários transfronteiriços. Enquanto isso, o líder de engenharia da Coinbase observou que trazer a extensão cripto x402 para o AP2 “fez sentido – é um playground natural para agentes... emocionante ver agentes pagando uns aos outros ressoar com a comunidade de IA”. Isso implica uma visão onde agentes de IA transacionando via redes cripto não é apenas uma ideia teórica, mas um resultado esperado, com o AP2 atuando como um catalisador.

Em resumo, o AP2 é altamente relevante para a Web3: ele incorpora pagamentos cripto como um cidadão de primeira classe e está se alinhando com padrões de identidade e credenciais descentralizadas. Em vez de competir diretamente com protocolos de pagamento descentralizados, o AP2 provavelmente interoperará com eles – fornecendo a camada de autorização enquanto os sistemas descentralizados lidam com a transferência de valor. À medida que a linha entre finanças tradicionais e cripto se confunde (com stablecoins, CBDCs, etc.), um protocolo unificado como o AP2 poderia servir como um adaptador universal entre agentes de IA e qualquer forma de dinheiro, centralizada ou descentralizada.

Adoção da Indústria, Parcerias e Roteiro​

Uma das maiores forças do AP2 é o extenso apoio da indústria por trás dele, mesmo nesta fase inicial. O Google Cloud anunciou que está “colaborando com um grupo diversificado de mais de 60 organizações” no AP2. Isso inclui grandes redes de cartão de crédito (por exemplo, Mastercard, American Express, JCB, UnionPay), líderes em fintech e processadores de pagamento (PayPal, Worldpay, Adyen, Checkout.com, concorrentes da Stripe), e-commerce e mercados online (Etsy, Shopify (via parceiros como Stripe ou outros), Lazada, Zalora), empresas de tecnologia empresarial (Salesforce, ServiceNow, Oracle possivelmente via parceiros, Dell, Red Hat), empresas de identidade e segurança (Okta, Ping Identity, Cloudflare), empresas de consultoria (Deloitte, Accenture), e organizações de cripto/Web3 (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark), entre outras. Uma gama tão ampla de participantes é um forte indicador do interesse da indústria e da provável adoção. Muitos desses parceiros expressaram publicamente seu apoio. Por exemplo, o Co-CEO da Adyen destacou a necessidade de um “livro de regras comum” para o comércio agêntico e vê o AP2 como uma extensão natural de sua missão de apoiar os comerciantes com novos blocos de construção de pagamento. O EVP da American Express afirmou que o AP2 é importante para “a próxima geração de pagamentos digitais” onde a confiança e a responsabilidade são primordiais. A equipe da Coinbase, como observado, está animada com a integração de pagamentos cripto no AP2. Esse coro de apoio mostra que muitos na indústria veem o AP2 como o provável padrão para pagamentos impulsionados por IA, e estão ansiosos para moldá-lo para garantir que atenda aos seus requisitos.

Do ponto de vista da adoção, o AP2 está atualmente na fase de especificação e implementação inicial (anunciado em setembro de 2025). A especificação técnica completa, a documentação e algumas implementações de referência (em linguagens como Python) estão disponíveis no GitHub do projeto para os desenvolvedores experimentarem. O Google também indicou que o AP2 será incorporado em seus produtos e serviços para agentes. Um exemplo notável é o AI Agent Marketplace mencionado anteriormente: esta é uma plataforma onde agentes de IA de terceiros podem ser oferecidos aos usuários (provavelmente parte do ecossistema de IA generativa do Google). O Google diz que muitos parceiros que constroem agentes os disponibilizarão no marketplace com “novas experiências transacionáveis habilitadas pelo AP2”. Isso implica que, à medida que o marketplace for lançado ou crescer, o AP2 será a espinha dorsal para qualquer agente que precise realizar uma transação, seja comprando software do Google Cloud Marketplace autonomamente ou um agente comprando bens/serviços para um usuário. Casos de uso empresariais como aquisição autônoma (um agente comprando de outro em nome de uma empresa) e escalonamento automático de licenças foram especificamente mencionados como áreas que o AP2 poderia facilitar em breve.

Em termos de roteiro, a documentação do AP2 e o anúncio do Google fornecem algumas indicações claras:

• Curto prazo: Continuar o desenvolvimento aberto do protocolo com a contribuição da comunidade. O repositório do GitHub será atualizado com implementações de referência adicionais e melhorias à medida que os testes no mundo real ocorrerem. Podemos esperar o surgimento de bibliotecas/SDKs, tornando mais fácil integrar o AP2 em aplicações de agentes. Além disso, programas piloto iniciais ou provas de conceito podem ser conduzidos pelas empresas parceiras. Dado que muitas grandes empresas de pagamento estão envolvidas, elas podem testar o AP2 em ambientes controlados (por exemplo, uma opção de checkout habilitada para AP2 em uma pequena versão beta para usuários).
• Padrões e Governança: O Google expressou o compromisso de mover o AP2 para um modelo de governança aberta, possivelmente através de órgãos de padronização. Isso pode significar submeter o AP2 a organizações como a Linux Foundation (como foi feito com o protocolo A2A) ou formar um consórcio para mantê-lo. A Linux Foundation, W3C ou até mesmo órgãos como ISO/TC68 (serviços financeiros) podem estar nos planos para formalizar o AP2. Uma governança aberta tranquilizaria a indústria de que o AP2 não está sob o controle de uma única empresa e permanecerá neutro e inclusivo.
• Expansão de Recursos: Tecnicamente, o roteiro inclui a expansão do suporte para mais tipos de pagamento e casos de uso. Como observado na especificação, após os cartões, o foco mudará para pagamentos “push” como transferências bancárias e esquemas de pagamento locais em tempo real, e moedas digitais. Isso significa que o AP2 delineará como um Mandato de Intenção/Carrinho/Pagamento funciona para, digamos, uma transferência bancária direta ou uma transferência de carteira cripto, onde o fluxo é um pouco diferente das retiradas de cartão. A extensão A2A x402 é uma dessas expansões para cripto; da mesma forma, podemos ver uma extensão para APIs de open banking ou uma para cenários de faturamento B2B.
• Aprimoramentos de Segurança e Conformidade: À medida que as transações reais começarem a fluir através do AP2, haverá escrutínio de reguladores e pesquisadores de segurança. O processo aberto provavelmente iterará para tornar os mandatos ainda mais robustos (por exemplo, garantindo que os formatos de mandato sejam padronizados, possivelmente usando o formato W3C Verifiable Credentials, etc.). A integração com soluções de identidade (talvez alavancando biometria para a assinatura de mandatos pelo usuário, ou vinculando mandatos a carteiras de identidade digital) pode fazer parte do roteiro para aumentar a confiança.
• Ferramentas do Ecossistema: Um ecossistema emergente é provável. Já, startups estão percebendo lacunas – por exemplo, a análise da Vellum.ai menciona uma startup chamada Autumn construindo “infraestrutura de faturamento para IA”, essencialmente ferramentas sobre o Stripe para lidar com preços complexos para serviços de IA. À medida que o AP2 ganhar tração, podemos esperar mais ferramentas como gateways de pagamento focados em agentes, painéis de gerenciamento de mandatos, serviços de verificação de identidade de agentes, etc., aparecerem. O envolvimento do Google significa que o AP2 também pode ser integrado em seus produtos Cloud – imagine o suporte AP2 em ferramentas Dialogflow ou Vertex AI Agents, tornando-o um clique para permitir que um agente lide com transações (com todas as chaves e certificados necessários gerenciados no Google Cloud).

No geral, a trajetória do AP2 lembra outros grandes padrões da indústria: um lançamento inicial com um forte patrocinador (Google), ampla coalizão da indústria, código de referência de código aberto, seguido por melhorias iterativas e adoção gradual em produtos reais. O fato de o AP2 convidar todos os players “a construir este futuro conosco” ressalta que o roteiro é sobre colaboração. Se o impulso continuar, o AP2 poderá se tornar tão comum em alguns anos quanto protocolos como OAuth ou OpenID Connect são hoje em seus domínios – uma camada invisível, mas crítica, que permite a funcionalidade entre serviços.

Conclusão​

O AP2 (Protocolo de Pagamentos por Agente) representa um passo significativo em direção a um futuro onde agentes de IA podem transacionar de forma tão confiável e segura quanto os humanos. Tecnicamente, ele introduz um mecanismo inteligente de mandatos e credenciais verificáveis que instilam confiança em transações lideradas por agentes, garantindo que a intenção do usuário seja explícita e aplicável. Sua arquitetura aberta e extensível permite que ele se integre tanto aos crescentes frameworks de agentes de IA quanto à infraestrutura financeira estabelecida. Ao abordar as principais preocupações de autorização, autenticidade e responsabilidade, o AP2 estabelece as bases para que o comércio impulsionado por IA floresça sem sacrificar a segurança ou o controle do usuário.

A introdução do AP2 pode ser vista como o estabelecimento de uma nova fundação – muito parecido com os primeiros protocolos da internet que habilitaram a web – para o que alguns chamam de “economia de agentes”. Ele abre caminho para inúmeras inovações: agentes de compras pessoais, bots de busca automática de ofertas, agentes autônomos de cadeia de suprimentos e muito mais, todos operando sob uma estrutura de confiança comum. Importante, o design inclusivo do AP2 (abrangendo tudo, desde cartões de crédito até cripto) o posiciona na interseção das finanças tradicionais e da Web3, potencialmente unindo esses mundos através de um protocolo comum mediado por agentes.

A resposta da indústria até agora tem sido muito positiva, com uma ampla coalizão sinalizando que o AP2 provavelmente se tornará um padrão amplamente adotado. O sucesso do AP2 dependerá da colaboração contínua e de testes no mundo real, mas suas perspectivas são fortes dada a clara necessidade que ele aborda. Em um sentido mais amplo, o AP2 exemplifica como a tecnologia evolui: uma nova capacidade (agentes de IA) surgiu que quebrou velhas suposições, e a solução foi desenvolver um novo padrão aberto para acomodar essa capacidade. Ao investir em um protocolo aberto e com segurança em primeiro lugar agora, o Google e seus parceiros estão efetivamente construindo a arquitetura de confiança necessária para a próxima era do comércio. Como diz o ditado, “a melhor maneira de prever o futuro é construí-lo” – o AP2 é uma aposta em um futuro onde agentes de IA lidam perfeitamente com transações para nós, e está ativamente construindo a confiança e as regras necessárias para tornar esse futuro viável.

Fontes:

• Blog do Google Cloud – “Impulsionando o comércio de IA com o novo Protocolo de Pagamentos por Agente (AP2)” (16 de setembro de 2025)
• Documentação do AP2 no GitHub – “Especificação e Visão Geral do Protocolo de Pagamentos por Agente”
• Blog da Vellum AI – “AP2 do Google: Um novo protocolo para pagamentos de agentes de IA” (Análise)
• Artigo do Medium – “Protocolo de Pagamentos por Agente (AP2) do Google” (Resumo por Tahir, setembro de 2025)
• Citações de Parceiros sobre o AP2 (Blog do Google Cloud)
• Extensão A2A x402 (extensão de pagamentos cripto do AP2) – README do GitHub

O Blockchain Application Stanford Summit (BASS) iniciou a semana da Science of Blockchain Conference (SBC), reunindo inovadores, pesquisadores e construtores para explorar o que há de mais avançado no ecossistema. Os organizadores Gil, Kung e Stephen receberam os participantes, destacando o foco do evento em empreendedorismo e aplicações reais, um espírito nascido da estreita colaboração com a SBC. Com apoio de organizações como Blockchain Builders e o Alumni de Criptografia e Blockchain de Stanford, o dia foi repleto de imersões em blockchains celestiais, o futuro da Ethereum, DeFi institucional e a crescente interseção entre IA e cripto.

Dalia Maliki: Construindo uma Raiz Orbital de Confiança com Space Computer​

Dalia Maliki, professora da UC Santa Barbara e conselheira da Space Computer, começou com uma visão de uma aplicação verdadeiramente fora deste mundo: construir uma plataforma de computação segura em órbita.

O que é Space Computer?
Em poucas palavras, Space Computer é uma “raiz orbital de confiança”, oferecendo uma plataforma para executar cálculos seguros e confidenciais em satélites. O valor central está nas garantias de segurança únicas do espaço. “Uma vez que uma caixa é lançada de forma segura e implantada no espaço, ninguém pode chegar depois e hackeá‑la”, explicou Maliki. “É puramente, perfeitamente à prova de violação neste ponto.” Esse ambiente a torna à prova de vazamentos, garante que as comunicações não sejam facilmente bloqueadas e fornece geolocalização verificável, oferecendo poderosas propriedades de descentralização.

Arquitetura e Casos de Uso
O sistema foi projetado com uma arquitetura de duas camadas:

• Camada 1 (Celestial): A raiz autoritária de confiança roda em uma rede de satélites em órbita, otimizada para comunicação limitada e intermitente.
• Camada 2 (Terrestre): Soluções de escalabilidade padrão, como rollups e state channels, rodam na Terra, ancorando na Camada 1 celestial para finalização e segurança.

Os primeiros casos de uso incluem execução de validadores de blockchain altamente seguros e um gerador verdadeiro de números aleatórios que captura radiação cósmica. Contudo, Maliki enfatizou o potencial da plataforma para inovações inesperadas. “A coisa mais legal de construir uma plataforma é que você cria a base e outras pessoas vêm construir casos de uso que você nunca imaginou.”

Traçando um paralelo ao ambicioso Projeto Corona dos anos 1950, que literalmente deixava baldes de filme cair de satélites espiões para serem capturados no ar por aeronaves, Maliki incentivou a plateia a pensar grande. “Em comparação, o que trabalhamos hoje com computação espacial é um luxo, e estamos muito empolgados com o futuro.”

Tomasz Stanczak: O Roteiro da Ethereum – Escalabilidade, Privacidade e IA​

Tomasz Stanczak, Diretor Executivo da Ethereum Foundation, apresentou uma visão abrangente do roteiro evolutivo da Ethereum, fortemente focado em escalabilidade, aprimoramento da privacidade e integração com o mundo da IA.

Foco de Curto Prazo: Suporte a L2s
A prioridade imediata da Ethereum é consolidar seu papel como a melhor plataforma para que as Layer 2s sejam construídas. Forks futuros, Fusaka e Glumpsterdom, giram em torno desse objetivo. “Queremos fazer declarações muito mais fortes de que sim, as L2s inovam, elas estendem a Ethereum e terão um compromisso dos construtores de protocolo de que a Layer 1 apoiará as L2s da melhor forma possível”, afirmou Stanczak.

Visão de Longo Prazo: Lean Ethereum e Provas em Tempo Real
Olhando mais adiante, a visão “Lean Ethereum” almeja escalabilidade massiva e reforço de segurança. Um componente chave é o roteiro do ZK‑EVM, que visa provas em tempo real com latências abaixo de 10 segundos para 99 % dos blocos, alcançáveis por stakers solo. Isso, combinado com melhorias de disponibilidade de dados, poderia levar as L2s a um “10 milhões de TPS” teórico. O plano de longo prazo também inclui foco em criptografia pós‑quântica por meio de assinaturas baseadas em hash e ZK‑EVMs.

Privacidade e a Interseção com IA
Privacidade é outro pilar crítico. A Ethereum Foundation criou a equipe Privacy and Scaling Explorations (PSC) para coordenar esforços, apoiar ferramentas e explorar integrações de privacidade ao nível de protocolo. Stanczak vê isso como essencial para a interação da Ethereum com IA, possibilitando casos de uso como mercados financeiros resistentes à censura, IA que preserva privacidade e sistemas agentes de código aberto. Ele enfatizou que a cultura da Ethereum de conectar múltiplas disciplinas — de finanças e arte a robótica e IA — é fundamental para navegar os desafios e oportunidades da próxima década.

Sreeram Kannan: O Framework de Confiança para Apps Cripto Ambiciosos com EigenCloud​

Sreeram Kannan, fundador da Eigen Labs, desafiou a plateia a pensar além do escopo atual das aplicações cripto, apresentando um framework para entender o valor central do cripto e introduzindo o EigenCloud como plataforma para materializar essa visão.

Tese Central do Cripto: Uma Camada de Verificabilidade
“Por trás de tudo isso há uma tese central de que o cripto é a camada de confiança ou verificabilidade sobre a qual você pode construir aplicações muito poderosas”, explicou Kannan. Ele apresentou um framework “TAM vs. Trust”, ilustrando que o mercado endereçável total (TAM) de uma aplicação cripto cresce exponencialmente à medida que a confiança que ela oferece aumenta. O mercado do Bitcoin cresce à medida que ele se torna mais confiável que moedas fiduciárias; o mercado de uma plataforma de empréstimos cresce à medida que sua garantia de solvência do tomador se torna mais credível.

EigenCloud: Liberando a Programabilidade
Kannan argumentou que o gargalo principal para construir apps mais ambiciosos — como um Uber descentralizado ou plataformas de IA confiáveis — não é desempenho, mas programabilidade. Para resolver isso, o EigenCloud introduz uma nova arquitetura que separa a lógica da aplicação da lógica do token.

“Vamos manter a lógica do token on‑chain na Ethereum”, propôs, “mas a lógica da aplicação é movida para fora. Você pode agora escrever sua lógica central em contêineres arbitrários… executá‑los em qualquer dispositivo de sua escolha, seja CPU ou GPU… e então trazer esses resultados de volta on‑chain de forma verificável.”

Essa abordagem, segundo ele, expande o cripto de “escala de laptop ou servidor para escala de nuvem”, permitindo que desenvolvedores criem as aplicações verdadeiramente disruptivas que foram imaginadas nos primeiros dias do cripto.

Painel: Um Mergulho Profundo na Arquitetura de Blockchain​

Um painel com Leiyang da MegaETH, Adi da Realo e Solomon da Solana Foundation explorou as compensações entre arquiteturas monolíticas, modulares e “super modulares”.

• MegaETH (L2 Modular): Leiyang descreveu a abordagem da MegaETH de usar um sequenciador centralizado para velocidade extrema enquanto delega a segurança à Ethereum. Esse design visa entregar uma experiência em tempo real ao nível do Web2 para aplicações, revivendo as ambiciosas ideias da era ICO que antes eram limitadas por desempenho.
• Solana (L1 Monolítica): Solomon explicou que a arquitetura da Solana, com seus altos requisitos de nós, foi deliberadamente projetada para máxima taxa de transferência a fim de apoiar sua visão de colocar toda a atividade financeira global on‑chain. O foco atual está em emissão de ativos e pagamentos. Sobre interoperabilidade, Solomon foi franco: “De modo geral, não nos importamos muito com interoperabilidade… É sobre colocar o máximo de liquidez e uso de ativos on‑chain possível.”
• Realo (L1 “Super Modular”): Adi apresentou o conceito “super modular” da Realo, que consolida serviços essenciais como oráculos diretamente na camada base para reduzir atritos para desenvolvedores. Esse design visa conectar nativamente a blockchain ao mundo real, com foco de go‑to‑market em RWAs e tornar a blockchain invisível para os usuários finais.

Painel: A Interseção Real entre IA e Blockchain​

Moderado por Ed Roman da HackVC, este painel mostrou três abordagens distintas para fundir IA e cripto.

• Ping AI (Bill): Ping AI está construindo uma “IA pessoal” onde os usuários mantêm a autocustódia de seus dados. A visão é substituir o modelo tradicional de ad‑exchange. Em vez de empresas monetizarem os dados dos usuários, o sistema da Ping AI recompensará diretamente os usuários quando seus dados gerarem uma conversão, permitindo que capturem o valor econômico de sua pegada digital.
• Public AI (Jordan): Descrita como a “camada humana da IA”, Public AI é um marketplace para obtenção de dados de alta qualidade, sob demanda, que não podem ser raspados ou gerados sinteticamente. Usa um sistema de reputação on‑chain e mecanismos de staking para garantir que os contribuidores forneçam sinal, não ruído, recompensando‑os por seu trabalho na construção de modelos de IA melhores.
• Gradient (Eric): Gradient está criando um runtime descentralizado para IA, permitindo inferência e treinamento distribuídos em uma rede de hardware de consumo subutilizado. O objetivo é oferecer um contrapeso ao poder centralizador das grandes empresas de IA, permitindo que uma comunidade global treine e sirva modelos colaborativamente, mantendo a “soberania inteligente”.

Mais Destaques da Cúpula​

• Orin Katz (Starkware) apresentou blocos de construção para “privacidade on‑chain compatível”, detalhando como provas ZK podem ser usadas para criar pools de privacidade e tokens privados (ZRC20s) que incluem mecanismos como “chaves de visualização” para supervisão regulatória.
• Sam Green (Cambrian) deu uma visão geral do panorama “Finanças Agentes”, categorizando agentes cripto em trading, provisionamento de liquidez, empréstimos, previsão e informação, e destacou a necessidade de dados rápidos, abrangentes e verificáveis para alimentá‑los.
• Max Siegel (Privy) compartilhou lições de onboarding de mais de 75 milhões de usuários, enfatizando a necessidade de encontrar os usuários onde eles estão, simplificar experiências de produto e deixar as necessidades de produto guiarem as escolhas de infraestrutura, não o contrário.
• Nil Dalal (Coinbase) introduziu o “Onchain Agentic Commerce Stack” e o padrão aberto X42, um protocolo nativo cripto projetado para criar uma “web pagável por máquinas” onde agentes de IA podem transacionar suavemente usando stablecoins para dados, APIs e serviços.
• Gordon Liao & Austin Adams (Circle) revelaram Circle Gateway, um novo primitivo para criar um saldo USDC unificado que é abstraído por cadeia. Isso permite implantação quase instantânea (< 500 ms) de liquidez em múltiplas cadeias, melhorando drasticamente a eficiência de capital para empresas e solucionadores.

O dia terminou com uma mensagem clara: as camadas fundamentais do cripto estão amadurecendo, e o foco está mudando decisivamente para a construção de aplicações robustas, amigáveis ao usuário e economicamente sustentáveis que possam fechar a lacuna entre o mundo on‑chain e a economia global.

Introdução​

Os mercados descentralizados de inferência/treinamento de IA visam aproveitar recursos computacionais globais e modelos comunitários de uma forma que não exige confiança (trustless). Projetos como Bittensor, Gensyn e Cuckoo Network (Cuckoo AI) ilustram como a tecnologia blockchain pode impulsionar mercados abertos de IA. Cada plataforma tokeniza ativos-chave de IA – poder computacional, modelos de machine learning e, por vezes, dados – em unidades económicas on-chain. A seguir, aprofundamos as arquiteturas técnicas que sustentam estas redes, como elas tokenizam recursos, as suas estruturas de governança e incentivos, métodos para rastrear a propriedade de modelos, mecanismos de partilha de receitas e as superfícies de ataque (por exemplo, ataques sybil, conluio, parasitismo, envenenamento) que surgem. Uma tabela comparativa no final resume todas as dimensões-chave entre Bittensor, Gensyn e Cuckoo AI.

Arquiteturas Técnicas​

Bittensor: “Internet Neural” Descentralizada em Sub-redes​

O Bittensor é construído sobre uma blockchain de Camada 1 (Layer-1) personalizada (a cadeia Subtensor, baseada no Substrate) que coordena uma rede de nós de modelos de IA através de muitas sub-redes especializadas. Cada sub-rede é uma mini-rede independente focada numa tarefa de IA específica (por exemplo, uma sub-rede para geração de linguagem, outra para geração de imagens, etc.). Os participantes no Bittensor assumem papéis distintos:

• Mineradores – executam modelos de machine learning no seu hardware e fornecem respostas de inferência (ou até realizam treinamento) para a tarefa da sub-rede. Em essência, um minerador é um nó que aloja um modelo de IA que responderá a consultas.
• Validadores – consultam os modelos dos mineradores com prompts e avaliam a qualidade das respostas, formando uma opinião sobre quais mineradores estão a contribuir com resultados valiosos. Os validadores efetivamente pontuam o desempenho dos mineradores.
• Proprietários de Sub-redes – criam e definem sub-redes, estabelecendo as regras para as tarefas a serem realizadas e como a validação é feita nessa sub-rede. Um proprietário de sub-rede poderia, por exemplo, especificar que uma sub-rede é para um determinado conjunto de dados ou modalidade e definir o procedimento de validação.
• Delegadores – detentores de tokens que não executam nós podem delegar (fazer stake) os seus tokens Bittensor (TAO) a mineradores ou validadores para apoiar os melhores desempenhos e ganhar uma parte das recompensas (semelhante ao staking em redes de prova de participação).

O mecanismo de consenso do Bittensor é inovador: em vez da validação de blocos tradicional, o Bittensor usa o consenso Yuma, que é uma forma de “prova de inteligência”. No consenso Yuma, as avaliações dos mineradores pelos validadores são agregadas on-chain para determinar a distribuição de recompensas. A cada bloco de 12 segundos, a rede cria novos tokens TAO e distribui-os de acordo com o consenso dos validadores sobre quais mineradores forneceram trabalho útil. As pontuações dos validadores são combinadas num esquema de mediana ponderada por stake: opiniões discrepantes são cortadas e a opinião da maioria honesta prevalece. Isto significa que se a maioria dos validadores concordar que um minerador foi de alta qualidade, esse minerador receberá uma forte recompensa; se um validador se desviar muito dos outros (possivelmente devido a conluio ou erro), esse validador é penalizado por ganhar menos. Desta forma, a blockchain do Bittensor coordena um ciclo de feedback minerador-validador: os mineradores competem para produzir os melhores resultados de IA, e os validadores curam e classificam esses resultados, com ambos os lados a ganhar tokens proporcionais ao valor que adicionam. Esta arquitetura é frequentemente descrita como uma “rede neural descentralizada” ou “cérebro global”, onde os modelos aprendem com os sinais uns dos outros e evoluem coletivamente. Notavelmente, o Bittensor atualizou recentemente a sua cadeia para suportar compatibilidade com EVM (para contratos inteligentes) e introduziu o dTAO, um sistema de tokens e staking específicos de sub-rede (explicado mais tarde) para descentralizar ainda mais o controlo da alocação de recursos.

Gensyn: Protocolo de Computação Distribuída Trustless​

A Gensyn aborda a IA descentralizada do ponto de vista de um protocolo de computação distribuída para machine learning. A sua arquitetura conecta desenvolvedores (submitters) que têm tarefas de IA (como treinar um modelo ou executar um trabalho de inferência) com fornecedores de computação (solvers) em todo o mundo que têm recursos de GPU/TPU sobressalentes. Originalmente, a Gensyn planeava uma cadeia L1 Substrate, mas mudou para construir no Ethereum como um rollup para maior segurança e liquidez. A rede Gensyn é, portanto, uma Camada 2 (Layer-2) do Ethereum (um rollup do Ethereum) que coordena a publicação de trabalhos e pagamentos, enquanto a computação ocorre off-chain no hardware dos fornecedores.

Uma inovação central do design da Gensyn é o seu sistema de verificação para trabalho off-chain. A Gensyn usa uma combinação de verificação otimista (provas de fraude) e técnicas criptográficas para garantir que, quando um solver afirma ter executado uma tarefa de treinamento/inferência, o resultado está correto. Na prática, o protocolo envolve múltiplos papéis de participantes:

• Submitter – a parte que solicita um trabalho (por exemplo, alguém que precisa de treinar um modelo). Eles pagam a taxa da rede e fornecem o modelo/dados ou a especificação da tarefa.
• Solver – um nó que licita e executa a tarefa de ML no seu hardware. Eles treinarão o modelo ou executarão a inferência conforme solicitado, e depois submeterão os resultados e uma prova de computação.
• Verifier/Challenger – nós que podem auditar ou verificar aleatoriamente o trabalho do solver. A Gensyn implementa um esquema ao estilo Truebit, onde, por padrão, o resultado de um solver é aceite, mas um verificador pode desafiá-lo dentro de uma janela de tempo se suspeitar de um cálculo incorreto. Num desafio, uma “pesquisa binária” interativa através dos passos de computação (um protocolo de prova de fraude) é usada para identificar qualquer discrepância. Isto permite que a cadeia resolva disputas realizando apenas uma parte crítica mínima da computação on-chain, em vez de refazer toda a tarefa dispendiosa.

Crucialmente, a Gensyn foi projetada para evitar a redundância massiva de abordagens ingénuas. Em vez de ter muitos nós a repetir o mesmo trabalho de ML (o que destruiria a economia de custos), a abordagem de “prova de aprendizagem” da Gensyn usa metadados de treinamento para verificar se o progresso da aprendizagem foi feito. Por exemplo, um solver pode fornecer hashes criptográficos ou checkpoints de pesos intermédios do modelo e uma prova sucinta de que estes progrediram de acordo com as atualizações de treinamento. Esta prova probabilística de aprendizagem pode ser verificada de forma muito mais barata do que reexecutar todo o treinamento, permitindo a verificação trustless sem replicação completa. Apenas se um verificador detetar uma anomalia é que uma computação on-chain mais pesada seria acionada como último recurso. Esta abordagem reduz drasticamente a sobrecarga em comparação com a verificação por força bruta, tornando o treinamento de ML descentralizado mais viável. A arquitetura da Gensyn, portanto, enfatiza fortemente o design de jogo criptoeconómico: os solvers colocam um stake ou um depósito, e se eles trapacearem (submetendo resultados errados), perdem esse stake para os verificadores honestos que os apanham. Ao combinar a coordenação da blockchain (para pagamentos e resolução de disputas) com computação off-chain e verificação inteligente, a Gensyn cria um mercado para computação de ML que pode explorar GPUs ociosas em qualquer lugar, mantendo a ausência de confiança. O resultado é um “protocolo de computação” em hiperescala, onde qualquer desenvolvedor pode aceder a poder de treinamento acessível e distribuído globalmente sob demanda.

Cuckoo AI: Plataforma de Serviço de IA Descentralizada Full-Stack​

A Cuckoo Network (ou Cuckoo AI) adota uma abordagem mais integrada verticalmente, com o objetivo de fornecer serviços de IA descentralizados de ponta a ponta, em vez de apenas computação bruta. A Cuckoo construiu a sua própria blockchain (inicialmente uma Camada 1 chamada Cuckoo Chain no Arbitrum Orbit, um framework de rollup compatível com Ethereum) para orquestrar tudo: não só combina trabalhos com GPUs, mas também aloja aplicações de IA e lida com pagamentos num único sistema. O design é full-stack: combina uma blockchain para transações e governança, uma camada de recursos descentralizados de GPU/CPU e aplicações de IA e APIs voltadas para o utilizador no topo. Por outras palavras, a Cuckoo integra todas as três camadas – blockchain, computação e aplicação de IA – dentro de uma única plataforma.

Os participantes na Cuckoo dividem-se em quatro grupos:

• Construtores de Aplicações de IA (Coordenadores) – são desenvolvedores que implementam modelos ou serviços de IA na Cuckoo. Por exemplo, um desenvolvedor pode alojar um gerador de imagens Stable Diffusion ou um chatbot LLM como um serviço. Eles executam Nós Coordenadores, que são responsáveis por gerir o seu serviço: aceitar pedidos de utilizadores, dividi-los em tarefas e atribuir essas tarefas aos mineradores. Os coordenadores fazem stake do token nativo ($CAI) para se juntarem à rede e ganharem o direito de utilizar os mineradores. Eles essencialmente atuam como orquestradores de camada 2 que fazem a interface entre os utilizadores e os fornecedores de GPU.
• Mineradores de GPU/CPU (Nós de Tarefa) – são os fornecedores de recursos. Os mineradores executam o cliente de tarefas da Cuckoo e contribuem com o seu hardware para realizar tarefas de inferência para as aplicações de IA. Por exemplo, um minerador pode receber um pedido de geração de imagem (com um determinado modelo e prompt) de um coordenador e usar a sua GPU para calcular o resultado. Os mineradores também devem fazer stake de $CAI para garantir o compromisso e o bom comportamento. Eles ganham recompensas em tokens por cada tarefa que completam corretamente.
• Utilizadores Finais – os consumidores das aplicações de IA. Eles interagem através do portal web ou APIs da Cuckoo (por exemplo, gerando arte via CooVerse ou conversando com personalidades de IA). Os utilizadores podem pagar com criptomoedas por cada uso ou, possivelmente, contribuir com a sua própria computação (ou stake) para compensar os custos de uso. Um aspeto importante é a resistência à censura: se um coordenador (fornecedor de serviço) for bloqueado ou ficar offline, os utilizadores podem mudar para outro que sirva a mesma aplicação, uma vez que múltiplos coordenadores podem alojar modelos semelhantes na rede descentralizada.
• Stakers (Delegadores) – membros da comunidade que não executam serviços de IA ou hardware de mineração ainda podem participar fazendo stake de $CAI naqueles que o fazem. Ao votar com o seu stake em coordenadores ou mineradores de confiança, eles ajudam a sinalizar a reputação e, em troca, ganham uma parte das recompensas da rede. Este design constrói uma camada de reputação Web3: bons atores atraem mais stake (e, portanto, confiança e recompensas), enquanto maus atores perdem stake e reputação. Mesmo os utilizadores finais podem fazer stake em alguns casos, alinhando-os com o sucesso da rede.

A cadeia Cuckoo (agora em processo de transição de uma cadeia autónoma para um rollup de segurança partilhada) rastreia todas estas interações. Quando um utilizador invoca um serviço de IA, o nó coordenador cria atribuições de tarefas on-chain para os mineradores. Os mineradores executam as tarefas off-chain e devolvem os resultados ao coordenador, que os valida (por exemplo, verificando se a imagem ou texto de saída não é um disparate) e entrega o resultado final ao utilizador. A blockchain lida com a liquidação de pagamentos: para cada tarefa, o contrato inteligente do coordenador paga ao minerador em $CAI (muitas vezes agregando micropagamentos em pagamentos diários). A Cuckoo enfatiza a ausência de confiança e a transparência – todos os participantes fazem stake de tokens e todas as atribuições e conclusões de tarefas são registadas, de modo que a fraude é desencorajada pela ameaça de perder o stake e pela visibilidade pública do desempenho. O design modular da rede significa que novos modelos de IA ou casos de uso podem ser adicionados facilmente: embora tenha começado com a geração de texto para imagem como prova de conceito, a sua arquitetura é geral o suficiente para suportar outras cargas de trabalho de IA (por exemplo, inferência de modelos de linguagem, transcrição de áudio, etc.).

Um aspeto notável da arquitetura da Cuckoo é que ela lançou inicialmente a sua própria blockchain de Camada 1 para maximizar o débito para transações de IA (atingindo um pico de 300k transações diárias durante os testes). Isto permitiu otimizações personalizadas para o agendamento de tarefas de IA. No entanto, a equipa descobriu que manter uma L1 autónoma era dispendioso e complexo, e em meados de 2025 decidiram descontinuar a cadeia personalizada e migrar para um modelo de rollup/AVS (Active Validated Service) no Ethereum. Isto significa que a Cuckoo herdará a segurança do Ethereum ou de uma L2 como o Arbitrum, em vez de executar o seu próprio consenso, mas continuará a operar o seu mercado de IA descentralizado nessa camada de segurança partilhada. A mudança destina-se a melhorar a segurança económica (aproveitando a robustez do Ethereum) e a permitir que a equipa da Cuckoo se concentre no produto em vez da manutenção da cadeia de baixo nível. Em resumo, a arquitetura da Cuckoo cria uma plataforma de serviço de IA descentralizada onde qualquer pessoa pode ligar hardware ou implementar um serviço de modelo de IA, e utilizadores globalmente podem aceder a aplicações de IA com menor custo e menos dependência da infraestrutura das grandes empresas de tecnologia.

Mecanismos de Tokenização de Ativos​

Um tema comum destas redes é a conversão de computação, modelos e dados em ativos on-chain ou unidades económicas que podem ser negociadas ou monetizadas. No entanto, cada projeto foca-se em tokenizar estes recursos de maneiras diferentes:

• Poder Computacional: Todas as três plataformas transformam o trabalho computacional em tokens de recompensa. No Bittensor, a computação útil (inferência ou treinamento feito por um minerador) é quantificada através das pontuações dos validadores e recompensada com tokens TAO a cada bloco. Essencialmente, o Bittensor “mede” a inteligência contribuída e cria TAO como uma mercadoria que representa essa contribuição. A Gensyn trata explicitamente a computação como uma mercadoria – o seu protocolo cria um mercado onde o tempo de GPU é o produto, e o preço é definido pela oferta e procura em termos de tokens. Os desenvolvedores compram computação usando o token, e os fornecedores ganham tokens vendendo os seus ciclos de hardware. A equipa da Gensyn observa que qualquer recurso digital (computação, dados, algoritmos) pode ser representado e negociado num mercado trustless semelhante. A Cuckoo tokeniza a computação através de um token ERC-20 $CAI emitido como pagamento por tarefas concluídas. Os fornecedores de GPU essencialmente “mineram” CAI ao fazerem trabalho de inferência de IA. O sistema da Cuckoo cria registos on-chain de tarefas, então pode-se pensar em cada tarefa de GPU concluída como uma unidade atómica de trabalho que é paga em tokens. A premissa em todos os três é que o poder computacional, de outra forma ocioso ou inacessível, se torna um ativo tokenizado e líquido – seja através de emissões de tokens ao nível do protocolo (como no Bittensor e na Cuckoo inicial) ou através de um mercado aberto de ordens de compra/venda para trabalhos de computação (como na Gensyn).

• Modelos de IA: Representar modelos de IA como ativos on-chain (por exemplo, NFTs ou tokens) ainda é incipiente. O Bittensor não tokeniza os modelos em si – os modelos permanecem off-chain sob a propriedade dos mineradores. Em vez disso, o Bittensor atribui indiretamente um valor aos modelos, recompensando aqueles que têm um bom desempenho. Na prática, a “inteligência” de um modelo é transformada em ganhos de TAO, mas não há um NFT que represente os pesos do modelo ou permita que outros o usem. O foco da Gensyn está nas transações de computação, não explicitamente na criação de tokens para modelos. Um modelo na Gensyn é tipicamente fornecido por um desenvolvedor off-chain (talvez de código aberto ou proprietário), treinado por solvers e devolvido – não há um mecanismo integrado para criar um token que possua o modelo ou a sua propriedade intelectual. (Dito isto, o mercado da Gensyn poderia potencialmente facilitar a negociação de artefactos ou checkpoints de modelos se as partes assim o desejarem, mas o protocolo em si vê os modelos como o conteúdo da computação, em vez de um ativo tokenizado.) A Cuckoo situa-se algures no meio: fala de “agentes de IA” e modelos integrados na rede, mas atualmente não há um token não fungível que represente cada modelo. Em vez disso, um modelo é implementado por um construtor de aplicações e depois servido através da rede. Os direitos de uso desse modelo são implicitamente tokenizados, na medida em que o modelo pode ganhar $CAI quando é usado (através do coordenador que o implementa). Todas as três plataformas reconhecem o conceito de tokenização de modelos – por exemplo, dar às comunidades a propriedade de modelos através de tokens – mas as implementações práticas são limitadas. Como indústria, a tokenização de modelos de IA (por exemplo, como NFTs com direitos de propriedade e partilha de lucros) ainda está a ser explorada. A abordagem do Bittensor de modelos a trocarem valor entre si é uma forma de “mercado de modelos” sem um token explícito por modelo. A equipa da Cuckoo observa que a propriedade descentralizada de modelos é promissora para reduzir as barreiras em comparação com a IA centralizada, mas requer métodos eficazes para verificar os resultados e o uso dos modelos on-chain. Em resumo, o poder computacional é imediatamente tokenizado (é simples pagar tokens por trabalho feito), enquanto os modelos são indireta ou aspiracionalmente tokenizados (recompensados pelos seus resultados, possivelmente representados por stake ou reputação, mas ainda não tratados como NFTs transferíveis nestas plataformas).

• Dados: A tokenização de dados continua a ser a mais difícil. Nenhum dos projetos Bittensor, Gensyn ou Cuckoo tem mercados de dados on-chain totalmente generalizados e integrados (onde conjuntos de dados são negociados com direitos de uso aplicáveis). Os nós do Bittensor podem treinar em vários conjuntos de dados, mas esses conjuntos de dados não fazem parte do sistema on-chain. A Gensyn pode permitir que um desenvolvedor forneça um conjunto de dados para treinamento, mas o protocolo não tokeniza esses dados – são simplesmente fornecidos off-chain para o solver usar. A Cuckoo, da mesma forma, não tokeniza os dados do utilizador; lida principalmente com dados (como prompts ou resultados de utilizadores) de forma transitória para tarefas de inferência. O blog da Cuckoo afirma explicitamente que “os dados descentralizados continuam a ser um desafio para tokenizar” apesar de serem um recurso crítico. Os dados são sensíveis (questões de privacidade e propriedade) e difíceis de manusear com a tecnologia blockchain atual. Assim, enquanto a computação está a ser comoditizada e os modelos começam a sê-lo, os dados permanecem em grande parte off-chain, exceto em casos especiais (alguns projetos fora destes três estão a experimentar uniões de dados e recompensas em tokens por contribuições de dados, mas isso está fora do nosso âmbito atual). Em resumo, o poder computacional é agora uma mercadoria on-chain nestas redes, os modelos são valorizados através de tokens, mas ainda não tokenizados individualmente como ativos, e a tokenização de dados ainda é um problema em aberto (além de reconhecer a sua importância).

Governança e Incentivos​

Um design robusto de governança e incentivos é crucial para que estas redes de IA descentralizadas funcionem de forma autónoma e justa. Aqui, examinamos como cada plataforma se governa (quem toma as decisões, como ocorrem as atualizações ou alterações de parâmetros) e como alinham os incentivos dos participantes através da economia de tokens.

• Governança do Bittensor: Nas suas fases iniciais, o desenvolvimento e os parâmetros das sub-redes do Bittensor eram em grande parte controlados pela equipa principal e por um conjunto de 64 validadores “raiz” na sub-rede principal. Este era um ponto de centralização – alguns validadores poderosos tinham uma influência desproporcional na alocação de recompensas, levando ao que alguns chamaram de “sistema de votação oligárquico”. Para resolver isto, o Bittensor introduziu a governança dTAO (TAO descentralizado) em 2025. O sistema dTAO mudou a alocação de recursos para ser impulsionada pelo mercado e controlada pela comunidade. Concretamente, os detentores de TAO podem fazer stake dos seus tokens em pools de liquidez específicos de sub-redes (essencialmente, eles “votam” em quais sub-redes devem receber mais emissões da rede) e recebem tokens alfa que representam a propriedade nesses pools de sub-redes. As sub-redes que atraem mais stake terão um preço de token alfa mais alto e receberão uma fatia maior da emissão diária de TAO, enquanto as sub-redes impopulares ou com baixo desempenho verão o capital (e, portanto, as emissões) a afastar-se. Isto cria um ciclo de feedback: se uma sub-rede produz serviços de IA valiosos, mais pessoas fazem stake de TAO nela (procurando recompensas), o que dá a essa sub-rede mais TAO para recompensar os seus participantes, fomentando o crescimento. Se uma sub-rede estagnar, os stakers retiram-se para sub-redes mais lucrativas. Na prática, os detentores de TAO governam coletivamente o foco da rede ao sinalizarem financeiramente quais domínios de IA merecem mais recursos. Esta é uma forma de governança on-chain por peso de token, alinhada com os resultados económicos. Além da alocação de recursos, grandes atualizações de protocolo ou alterações de parâmetros provavelmente ainda passam por propostas de governança onde os detentores de TAO votam (o Bittensor tem um mecanismo para propostas e referendos on-chain geridos pela Fundação Bittensor e um conselho eleito, semelhante à governança do Polkadot). Com o tempo, pode-se esperar que a governança do Bittensor se torne cada vez mais descentralizada, com a fundação a recuar à medida que a comunidade (através do stake de TAO) orienta coisas como a taxa de inflação, a aprovação de novas sub-redes, etc. A transição para o dTAO é um grande passo nessa direção, substituindo os decisores centralizados por um mercado de detentores de tokens alinhado por incentivos.

• Incentivos do Bittensor: A estrutura de incentivos do Bittensor está intimamente ligada ao seu consenso. A cada bloco (12 segundos), exatamente 1 TAO é recém-criado e dividido entre os contribuidores de cada sub-rede com base no desempenho. A divisão padrão para a recompensa de bloco de cada sub-rede é 41% para os mineradores, 41% para os validadores e 18% para o proprietário da sub-rede. Isto garante que todos os papéis são recompensados: os mineradores ganham por fazer o trabalho de inferência, os validadores ganham pelo seu esforço de avaliação, e os proprietários de sub-redes (que podem ter iniciado os dados/tarefa para essa sub-rede) ganham um resíduo por fornecerem o “mercado” ou o design da tarefa. Essas percentagens são fixas no protocolo e visam alinhar os incentivos de todos para uma produção de IA de alta qualidade. O mecanismo de consenso Yuma refina ainda mais os incentivos ao ponderar as recompensas de acordo com as pontuações de qualidade – um minerador que fornece melhores respostas (conforme o consenso dos validadores) obtém uma porção maior desses 41%, e um validador que segue de perto o consenso honesto obtém mais da porção do validador. Os maus desempenhos são eliminados economicamente. Além disso, os delegadores (stakers) que apoiam um minerador ou validador normalmente recebem uma parte dos ganhos desse nó (os nós geralmente definem uma comissão e dão o resto aos seus delegadores, semelhante ao staking em redes PoS). Isto permite que os detentores passivos de TAO apoiem os melhores contribuidores e ganhem rendimento, reforçando ainda mais a meritocracia. O token do Bittensor (TAO) é, portanto, um token de utilidade: é necessário para o registo de novos mineradores (os mineradores devem gastar uma pequena quantidade de TAO para se juntarem, o que combate o spam sybil) e pode ser colocado em stake para aumentar a influência ou ganhar através da delegação. Também é previsto como um token de pagamento se utilizadores externos quiserem consumir serviços da rede do Bittensor (por exemplo, pagar TAO para consultar um modelo de linguagem no Bittensor), embora o mecanismo de recompensa interno tenha sido a principal “economia” até agora. A filosofia geral de incentivos é recompensar a “inteligência valiosa” – ou seja, modelos que ajudam a produzir bons resultados de IA – e criar uma competição que melhora continuamente a qualidade dos modelos na rede.

• Governança da Gensyn: O modelo de governança da Gensyn está estruturado para evoluir do controlo da equipa principal para o controlo da comunidade à medida que a rede amadurece. Inicialmente, a Gensyn terá uma Fundação Gensyn e um conselho eleito que supervisionarão as atualizações do protocolo e as decisões do tesouro. Espera-se que este conselho seja composto por membros da equipa principal e líderes comunitários iniciais. A Gensyn planeia um Evento de Geração de Tokens (TGE) para o seu token nativo (frequentemente referido como GENS), após o qual o poder de governança passaria cada vez mais para as mãos dos detentores de tokens através de votação on-chain. O papel da fundação é representar os interesses do protocolo e garantir uma transição suave para a descentralização total. Na prática, a Gensyn provavelmente terá mecanismos de proposta on-chain onde alterações de parâmetros (por exemplo, duração do jogo de verificação, taxas) ou atualizações são votadas pela comunidade. Como a Gensyn está a ser implementada como um rollup do Ethereum, a governança também pode estar ligada à segurança do Ethereum (por exemplo, usando chaves de atualização para o contrato do rollup que eventualmente são entregues a uma DAO de detentores de tokens). A secção de descentralização e governança do litepaper da Gensyn enfatiza que o protocolo deve, em última análise, ser de propriedade global, alinhando-se com o ethos de que a “rede para inteligência de máquina” deve pertencer aos seus utilizadores e contribuidores. Em resumo, a governança da Gensyn começa semi-centralizada, mas está arquitetada para se tornar uma DAO onde os detentores de tokens GENS (potencialmente ponderados por stake ou participação) tomam decisões coletivamente.

• Incentivos da Gensyn: Os incentivos económicos na Gensyn são dinâmicas de mercado diretas, complementadas por segurança criptoeconómica. Os desenvolvedores (clientes) pagam por tarefas de ML no token Gensyn, e os Solvers ganham tokens ao completar essas tarefas corretamente. O preço dos ciclos de computação é determinado por um mercado aberto – presumivelmente, os desenvolvedores podem colocar tarefas com uma recompensa e os solvers podem licitar ou simplesmente aceitá-la se o preço corresponder às suas expectativas. Isto garante que, enquanto houver oferta de GPUs ociosas, a competição levará o custo a uma taxa justa (a equipa da Gensyn projeta uma redução de custos de até 80% em comparação com os preços da nuvem, pois a rede encontra o hardware disponível mais barato globalmente). Por outro lado, os solvers têm o incentivo de ganhar tokens por trabalho; o seu hardware que, de outra forma, estaria ocioso, agora gera receita. Para garantir a qualidade, a Gensyn exige que os solvers coloquem colateral em stake quando assumem um trabalho – se eles trapacearem ou produzirem um resultado incorreto e forem apanhados, perdem esse stake (pode ser cortado e atribuído ao verificador honesto). Os verificadores são incentivados pela chance de ganhar uma recompensa “jackpot” se apanharem um solver fraudulento, semelhante ao design do Truebit de recompensar periodicamente os verificadores que identificam com sucesso computações incorretas. Isto mantém os solvers honestos e motiva alguns nós a agirem como vigilantes. Num cenário ótimo (sem trapaça), os solvers simplesmente ganham a taxa da tarefa e o papel do verificador fica maioritariamente ocioso (ou um dos solvers participantes pode também atuar como verificador de outros). O token da Gensyn serve, portanto, como moeda de gás para comprar computação e como colateral de stake que protege o protocolo. O litepaper menciona uma testnet com tokens não permanentes e que os participantes iniciais da testnet serão recompensados no TGE com tokens reais. Isto indica que a Gensyn alocou alguma oferta de tokens para bootstrapping – recompensando os primeiros adotantes, solvers de teste e membros da comunidade. A longo prazo, as taxas de trabalhos reais devem sustentar a rede. Pode também haver uma pequena taxa de protocolo (uma percentagem de cada pagamento de tarefa) que vai para um tesouro ou é queimada; este detalhe ainda não está confirmado, mas muitos protocolos de mercado incluem uma taxa para financiar o desenvolvimento ou a compra e queima de tokens. Em resumo, os incentivos da Gensyn alinham-se em torno da conclusão honesta de trabalhos de ML: faça o trabalho, seja pago; tente trapacear, perca o stake; verifique os outros, ganhe se apanhar trapaças. Isto cria um sistema económico auto-policiado, destinado a alcançar uma computação distribuída fiável.

• Governança da Cuckoo: A Cuckoo Network integrou a governança no seu ecossistema desde o primeiro dia, embora ainda esteja em fase de desenvolvimento. O token $CAI é explicitamente um token de governança, além dos seus papéis de utilidade. A filosofia da Cuckoo é que os operadores de nós de GPU, os desenvolvedores de aplicações e até os utilizadores finais devem ter uma palavra a dizer na evolução da rede – refletindo a sua visão impulsionada pela comunidade. Na prática, decisões importantes (como atualizações de protocolo ou alterações económicas) seriam decididas por votos ponderados por tokens, presumivelmente através de um mecanismo de DAO. Por exemplo, a Cuckoo poderia realizar votações on-chain para alterar a distribuição de recompensas ou adotar uma nova funcionalidade, e os detentores de $CAI (incluindo mineradores, desenvolvedores e utilizadores) votariam. A votação on-chain já é usada como um sistema de reputação: a Cuckoo exige que cada papel faça stake de tokens, e depois os membros da comunidade podem votar (talvez delegando stake ou através de módulos de governança) em quais coordenadores ou mineradores são confiáveis. Isto afeta as pontuações de reputação e pode influenciar o agendamento de tarefas (por exemplo, um coordenador com mais votos pode atrair mais utilizadores, ou um minerador com mais votos pode receber mais tarefas). É uma mistura de governança e incentivo – usar tokens de governança para estabelecer confiança. A Fundação Cuckoo ou a equipa principal tem guiado a direção do projeto até agora (por exemplo, tomando a recente decisão de descontinuar a cadeia L1), mas o seu blog indica um compromisso em avançar para a propriedade descentralizada. Eles identificaram que executar a sua própria cadeia incorria em altos custos e que a mudança para um rollup permitirá um desenvolvimento mais aberto e integração com ecossistemas existentes. É provável que, uma vez numa camada partilhada (como o Ethereum), a Cuckoo implemente uma DAO mais tradicional para atualizações, com a comunidade a votar usando CAI.

• Incentivos da Cuckoo: O design de incentivos para a Cuckoo tem duas fases: a fase inicial de bootstrapping com alocações fixas de tokens, e um estado futuro com partilha de receitas impulsionada pelo uso. No lançamento, a Cuckoo realizou uma distribuição de “lançamento justo” de 1 bilião de tokens CAI. 51% da oferta foi reservada para a comunidade, alocada como:

  • Recompensas de Mineração: 30% da oferta total reservada para pagar aos mineradores de GPU por realizarem tarefas de IA.
  • Recompensas de Staking: 11% da oferta para aqueles que fazem stake e ajudam a proteger a rede.
  • Airdrops: 5% para os primeiros utilizadores e membros da comunidade como um incentivo à adoção.
  • (Outros 5% foram para subsídios a desenvolvedores para encorajar a construção na Cuckoo.)

  Esta grande alocação significa que, na rede inicial, os mineradores e stakers foram recompensados de um pool de emissão, mesmo que a procura real dos utilizadores fosse baixa. De facto, a fase inicial da Cuckoo apresentou altos rendimentos APY para staking e mineração, o que atraiu com sucesso participantes, mas também “yield farmers” que estavam lá apenas pelos tokens. A equipa notou que muitos utilizadores saíram assim que as taxas de recompensa caíram, indicando que esses incentivos não estavam ligados ao uso genuíno. Tendo aprendido com isso, a Cuckoo está a mudar para um modelo onde as recompensas se correlacionam diretamente com a carga de trabalho real de IA. No futuro (e parcialmente já), quando um utilizador final paga por uma inferência de IA, esse pagamento (em CAI ou possivelmente outro token aceite convertido para CAI) será dividido entre os contribuidores:

  • Mineradores de GPU receberão a maior parte pela computação que forneceram.
  • Coordenador (desenvolvedor da aplicação) ficará com uma porção como o fornecedor de serviço que forneceu o modelo e lidou com o pedido.
  • Stakers que delegaram nesses mineradores ou coordenadores podem receber uma pequena parte ou uma recompensa inflacionária, para continuar a incentivar o apoio a nós fiáveis.
  • Rede/Tesouro pode reter uma taxa para o desenvolvimento contínuo ou para financiar incentivos futuros (ou a taxa pode ser zero/nominal para maximizar a acessibilidade para o utilizador).

  Essencialmente, a Cuckoo está a mover-se para um modelo de partilha de receitas: se uma aplicação de IA na Cuckoo gera ganhos, esses ganhos são distribuídos a todos os contribuidores desse serviço de forma justa. Isto alinha os incentivos para que os participantes beneficiem do uso real em vez de apenas da inflação. A rede já exigia que todas as partes fizessem stake de CAI – isto significa que os mineradores e coordenadores não ganham apenas uma recompensa fixa, mas também possivelmente recompensas baseadas em stake (por exemplo, um coordenador pode ganhar recompensas mais altas se muitos utilizadores fizerem stake nele ou se ele próprio fizer mais stake, semelhante a como os validadores de prova de participação ganham). Em termos de incentivos para os utilizadores, a Cuckoo também introduziu coisas como um portal de airdrop e faucets (que alguns utilizadores exploraram) para semear a atividade inicial. No futuro, os utilizadores podem ser incentivados através de reembolsos em tokens por usarem os serviços ou através de recompensas de governança por participarem na curadoria (por exemplo, talvez ganhando pequenos tokens por avaliarem resultados ou contribuírem com dados). A linha de fundo é que o token da Cuckoo ($CAI) é multifuncional: é o token de gás/taxa na cadeia (todas as transações e pagamentos o usam), é usado para staking e votação, e é a unidade de recompensa pelo trabalho feito. A Cuckoo menciona explicitamente que quer ligar as recompensas de tokens a KPIs de nível de serviço (indicadores-chave de desempenho) – por exemplo, tempo de atividade, débito de consultas, satisfação do utilizador – para evitar incentivos puramente especulativos. Isto reflete um amadurecimento da economia de tokens, de uma simples mineração de liquidez para um modelo mais sustentável e impulsionado pela utilidade.

Propriedade de Modelos e Atribuição de PI​

Lidar com a propriedade intelectual (PI) e os direitos de propriedade de modelos de IA é um aspeto complexo das redes de IA descentralizadas. Cada plataforma adotou uma postura ligeiramente diferente, e geralmente esta é uma área em evolução sem uma solução completa ainda:

• Bittensor: Os modelos no Bittensor são fornecidos pelos nós mineradores, e esses mineradores mantêm o controlo total sobre os pesos dos seus modelos (que nunca são publicados on-chain). O Bittensor não rastreia explicitamente quem “possui” um modelo, além do facto de que ele está a ser executado num determinado endereço de carteira. Se um minerador sair, o seu modelo sai com ele. Assim, a atribuição de PI no Bittensor é off-chain: se um minerador usa um modelo proprietário, não há nada on-chain que imponha ou sequer saiba disso. A filosofia do Bittensor incentiva contribuições abertas (muitos mineradores podem usar modelos de código aberto como GPT-J ou outros) e a rede recompensa o desempenho desses modelos. Poder-se-ia dizer que o Bittensor cria uma pontuação de reputação para os modelos (através das classificações dos validadores), e isso é uma forma de reconhecer o valor do modelo, mas os direitos sobre o modelo em si não são tokenizados ou distribuídos. Notavelmente, os proprietários de sub-redes no Bittensor podem ser vistos como possuidores de uma parte da PI: eles definem uma tarefa (que pode incluir um conjunto de dados ou método). O proprietário da sub-rede cria um NFT (chamado de UID de sub-rede) ao criar uma sub-rede, e esse NFT dá-lhes direito a 18% das recompensas nessa sub-rede. Isto efetivamente tokeniza a criação de um mercado de modelos (a sub-rede), se não as instâncias do modelo. Se considerarmos a definição da sub-rede (digamos, uma tarefa de reconhecimento de fala com um conjunto de dados específico) como PI, isso é pelo menos registado e recompensado. Mas os pesos individuais dos modelos que os mineradores treinam – não há um registo de propriedade on-chain deles. A atribuição vem na forma de recompensas pagas ao endereço desse minerador. O Bittensor atualmente não implementa um sistema onde, por exemplo, várias pessoas possam possuir conjuntamente um modelo e obter uma partilha de receitas automática – a pessoa que executa o modelo (minerador) recebe a recompensa e cabe a ela, off-chain, honrar quaisquer licenças de PI do modelo que usou.

• Gensyn: Na Gensyn, a propriedade do modelo é direta, na medida em que o submitter (aquele que quer um modelo treinado) fornece a arquitetura do modelo e os dados, e após o treinamento, ele recebe o artefacto do modelo resultante. Os solvers que realizam o trabalho não têm direitos sobre o modelo; são como contratados a serem pagos por um serviço. O protocolo da Gensyn assume, portanto, o modelo de PI tradicional: se você tinha direitos legais sobre o modelo e os dados que submeteu, ainda os tem depois de treinado – a rede de computação não reivindica qualquer propriedade. A Gensyn menciona que o mercado também poderia negociar algoritmos e dados como qualquer outro recurso. Isto sugere um cenário onde alguém poderia oferecer um modelo ou algoritmo para uso na rede, possivelmente por uma taxa, tokenizando assim o acesso a esse modelo. Por exemplo, um criador de modelos poderia colocar o seu modelo pré-treinado na Gensyn e permitir que outros o ajustassem através da rede por uma taxa (isto monetizaria efetivamente a PI do modelo). Embora o protocolo não imponha termos de licença, poder-se-ia codificar requisitos de pagamento: um contrato inteligente poderia exigir uma taxa para desbloquear os pesos do modelo para um solver. No entanto, estes são casos de uso especulativos – o design principal da Gensyn é sobre permitir trabalhos de treinamento. Quanto à atribuição, se várias partes contribuírem para um modelo (digamos, uma fornece dados, outra fornece computação), isso provavelmente seria tratado por qualquer contrato ou acordo que eles estabelecessem antes de usar a Gensyn (por exemplo, um contrato inteligente poderia dividir o pagamento entre o fornecedor de dados e o fornecedor de computação). A Gensyn em si não rastreia “este modelo foi construído por X, Y, Z” on-chain, além do registo de quais endereços foram pagos pelo trabalho. Em suma, a PI do modelo na Gensyn permanece com o submitter, e qualquer atribuição ou licenciamento deve ser tratado através de acordos legais fora do protocolo ou através de contratos inteligentes personalizados construídos sobre ele.

• Cuckoo: No ecossistema da Cuckoo, os criadores de modelos (construtores de aplicações de IA) são participantes de primeira classe – eles implementam o serviço de IA. Se um construtor de aplicações ajusta um modelo de linguagem ou desenvolve um modelo personalizado e o aloja na Cuckoo, esse modelo é essencialmente sua propriedade e eles atuam como o proprietário do serviço. A Cuckoo não se apropria de nenhuma propriedade; em vez disso, fornece a infraestrutura para que eles monetizem o uso. Por exemplo, se um desenvolvedor implementa uma IA de chatbot, os utilizadores podem interagir com ela e o desenvolvedor (mais os mineradores) ganham CAI de cada interação. A plataforma atribui, assim, a receita de uso ao criador do modelo, mas não publica explicitamente os pesos do modelo nem os transforma num NFT. Na verdade, para executar o modelo nas GPUs dos mineradores, o nó coordenador provavelmente tem de enviar o modelo (ou o tempo de execução) ao minerador de alguma forma. Isto levanta questões de PI: poderia um minerador malicioso copiar os pesos do modelo e distribuí-los? Numa rede descentralizada, esse risco existe se forem usados modelos proprietários. O foco atual da Cuckoo tem sido em modelos razoavelmente abertos (Stable Diffusion, modelos derivados do LLaMA, etc.) e na construção de uma comunidade, por isso ainda não vimos uma aplicação de direitos de PI através de contratos inteligentes. A plataforma poderia potencialmente integrar ferramentas como execução de modelos encriptados ou enclaves seguros no futuro para proteção de PI, mas nada específico é mencionado na documentação. O que ela rastreia é quem forneceu o serviço de modelo para cada tarefa – como o coordenador é uma identidade on-chain, todo o uso do seu modelo é contabilizado para ele, e ele recebe automaticamente a sua parte das recompensas. Se alguém fosse entregar ou vender um modelo a outra pessoa, efetivamente transferiria o controlo do nó coordenador (talvez até mesmo dando-lhe a chave privada ou o NFT se o papel de coordenador fosse tokenizado). Atualmente, a propriedade comunitária de modelos (através de participações em tokens) não está implementada, mas a visão da Cuckoo aponta para uma IA descentralizada impulsionada pela comunidade, então eles podem explorar a possibilidade de permitir que as pessoas financiem ou governem coletivamente um modelo de IA. A tokenização de modelos para além da propriedade individual ainda é uma área em aberto nestas redes – é reconhecida como um objetivo (permitir que as comunidades possuam modelos de IA em vez de corporações), mas na prática requer soluções para os desafios de PI e verificação acima mencionados.

Em resumo, a propriedade de modelos no Bittensor, Gensyn e Cuckoo é tratada off-chain por meios tradicionais: a pessoa ou entidade que executa ou submete o modelo é efetivamente o proprietário. As redes fornecem atribuição na forma de recompensas económicas (pagando ao contribuidor do modelo pela sua PI ou esforço). Nenhuma das três tem uma licença ou aplicação de royalties integrada no uso de modelos ao nível do contrato inteligente ainda. A atribuição vem através da reputação e da recompensa: por exemplo, os melhores modelos do Bittensor ganham altas pontuações de reputação (que é um registo público) e mais TAO, o que é um crédito implícito aos seus criadores. Com o tempo, podemos ver funcionalidades como pesos de modelo vinculados a NFTs ou licenças descentralizadas para melhor rastrear a PI, mas atualmente a prioridade tem sido fazer as redes funcionarem e incentivarem as contribuições. Todos concordam que verificar a proveniência e os resultados dos modelos é fundamental para permitir verdadeiros mercados de ativos de modelos, e a pesquisa está em andamento nessa direção.

Estruturas de Partilha de Receitas​

Todas as três plataformas devem decidir como dividir o bolo económico quando várias partes colaboram para produzir um resultado de IA valioso. Quem é pago, e quanto, quando um serviço de IA é usado ou quando os tokens são emitidos? Cada uma tem um modelo de partilha de receitas distinto:

• Bittensor: Como mencionado em incentivos, a distribuição de receitas do Bittensor é definida pelo protocolo ao nível do bloco: 41% para os mineradores, 41% para os validadores, 18% para o proprietário da sub-rede para cada emissão de TAO do bloco. Isto é efetivamente uma divisão de receitas integrada para o valor gerado em cada sub-rede. A parte do proprietário da sub-rede (18%) funciona como um royalty pelo “design do modelo/tarefa” ou por iniciar o ecossistema dessa sub-rede. Mineradores e validadores a receberem partes iguais garante que, sem validação, os mineradores não são recompensados (e vice-versa) – eles são simbióticos e cada um recebe uma porção igual das recompensas criadas. Se considerarmos um utilizador externo a pagar TAO para consultar um modelo, o whitepaper do Bittensor prevê que esse pagamento também seja dividido de forma semelhante entre o minerador que responde e os validadores que ajudaram a verificar a resposta (a divisão exata poderia ser determinada pelo protocolo ou pelas forças de mercado). Além disso, os delegadores que fazem stake em mineradores/validadores são efetivamente parceiros – tipicamente, um minerador/validador partilhará uma percentagem do seu TAO ganho com os seus delegadores (isto é configurável, mas muitas vezes a maioria vai para os delegadores). Assim, se um minerador ganhasse 1 TAO de um bloco, isso poderia ser dividido 80/20 entre os seus delegadores e ele próprio, por exemplo, com base no stake. Isto significa que mesmo os não operadores recebem uma parte da receita da rede proporcional ao seu apoio. Com a introdução do dTAO, outra camada de partilha foi adicionada: aqueles que fazem stake no pool de uma sub-rede recebem tokens alfa, que lhes dão direito a algumas das emissões dessa sub-rede (como yield farming). Na prática, qualquer pessoa pode ter uma participação no sucesso de uma sub-rede específica e receber uma fração das recompensas de minerador/validador ao deter tokens alfa (os tokens alfa valorizam à medida que a sub-rede atrai mais uso e emissões). Em suma, a partilha de receitas do Bittensor é fixada por código para os papéis principais, e partilhada adicionalmente por arranjos sociais/de staking. É uma divisão relativamente transparente e baseada em regras – a cada bloco, os participantes sabem exatamente como o 1 TAO é alocado, e assim conhecem os seus “ganhos” por contribuição. Esta clareza é uma das razões pelas quais o Bittensor é por vezes comparado ao Bitcoin para IA – uma emissão monetária determinística onde a recompensa dos participantes é definida matematicamente.

• Gensyn: A partilha de receitas na Gensyn é mais dinâmica e impulsionada pelo mercado, uma vez que as tarefas são precificadas individualmente. Quando um submitter cria um trabalho, ele anexa uma recompensa (digamos, X tokens) que está disposto a pagar. Um solver que completa o trabalho recebe esse X (menos qualquer taxa de rede). Se um verifier estiver envolvido, tipicamente há uma regra como: se nenhuma fraude for detetada, o solver mantém o pagamento total; se a fraude for detetada, o solver é penalizado – perdendo parte ou todo o seu stake – e esse montante penalizado é dado ao verifier como recompensa. Portanto, os verificadores não ganham de todas as tarefas, apenas quando apanham um mau resultado (mais possivelmente uma pequena taxa base por participarem, dependendo da implementação). Não há um conceito integrado de pagar a um proprietário de modelo aqui, porque a suposição é que o submitter ou é o proprietário do modelo ou tem direitos para usá-lo. Poder-se-ia imaginar um cenário onde um submitter está a ajustar o modelo pré-treinado de outra pessoa e uma porção do pagamento vai para o criador original do modelo – mas isso teria de ser tratado fora do protocolo (por exemplo, por um acordo ou um contrato inteligente separado que divide o pagamento do token em conformidade). A partilha ao nível do protocolo da Gensyn é essencialmente cliente -> solver (-> verifier). O modelo de token provavelmente inclui alguma alocação para o tesouro ou fundação do protocolo; por exemplo, uma pequena percentagem do pagamento de cada tarefa pode ir para um tesouro que poderia ser usado para financiar o desenvolvimento ou pools de seguro (isto não é explicitamente declarado nos documentos disponíveis, mas muitos protocolos fazem-no). Além disso, no início, a Gensyn pode subsidiar os solvers através da inflação: os utilizadores da testnet têm prometidas recompensas no TGE, o que é efetivamente uma partilha de receitas da distribuição inicial de tokens (os primeiros solvers e apoiantes recebem uma parte dos tokens por ajudarem a iniciar, semelhante a um airdrop ou recompensa de mineração). Com o tempo, à medida que os trabalhos reais dominam, as recompensas inflacionárias diminuiriam, e o rendimento dos solvers viria principalmente dos pagamentos dos utilizadores. A abordagem da Gensyn pode ser resumida como um modelo de receita de taxa por serviço: a rede facilita um pagamento direto daqueles que precisam de trabalho feito para aqueles que fazem o trabalho, com os verificadores e possivelmente os stakers de tokens a receberem uma parte apenas quando desempenham um papel na segurança desse serviço.

• Cuckoo: A partilha de receitas da Cuckoo evoluiu. Inicialmente, como não havia muitos utilizadores finais pagantes, a partilha de receitas era essencialmente uma partilha de inflação: as alocações de 30% para mineração e 11% para staking da oferta de tokens significavam que os mineradores e stakers estavam a partilhar os tokens emitidos pelo pool de lançamento justo da rede. Na prática, a Cuckoo realizava coisas como pagamentos diários de CAI aos mineradores proporcionais às tarefas concluídas. Esses pagamentos vinham em grande parte da alocação de recompensa de mineração (que faz parte da oferta fixa reservada). Isto é semelhante a como muitas blockchains de Camada 1 distribuem recompensas de bloco aos mineradores/validadores – não estava ligado ao uso real por utilizadores externos, era mais para incentivar a participação e o crescimento. No entanto, como destacado no seu blog de julho de 2025, isto levou a um uso que era incentivado pela agricultura de tokens em vez de uma procura real. A próxima fase para a Cuckoo é um verdadeiro modelo de partilha de receitas baseado em taxas de serviço. Neste modelo, quando um utilizador final usa, digamos, o serviço de geração de imagens e paga $1 (em termos de cripto), esse $1 em tokens seria dividido talvez assim: 0,70 para o minerador que fez o trabalho de GPU, 0,20 para o desenvolvedor da aplicação (coordenador) que forneceu o modelo e a interface, e 0,10 para os stakers ou o tesouro da rede. (Nota: as proporções exatas são hipotéticas; a Cuckoo ainda não as especificou publicamente, mas isto ilustra o conceito.) Desta forma, todos os contribuidores para a entrega do serviço recebem uma parte da receita. Isto é análogo, por exemplo, a uma economia de partilha de viagens mas para IA: o veículo (minerador de GPU) recebe a maioria, o motorista ou plataforma (coordenador que construiu o serviço de modelo) recebe uma parte, e talvez a governança/stakers da plataforma recebam uma pequena taxa. A menção da Cuckoo a “modelos de partilha de receitas e recompensas de tokens diretamente ligadas a métricas de uso” sugere que se um serviço ou nó específico lidar com um grande volume, os seus operadores e apoiantes ganharão mais. Eles estão a afastar-se dos rendimentos fixos apenas por bloquear tokens (que era o caso com o seu APY de staking inicialmente). Em termos concretos: se você fizer stake num coordenador que acaba por alimentar uma aplicação de IA muito popular, poderá ganhar uma porção das taxas dessa aplicação – um verdadeiro cenário de staking como investimento em utilidade, em vez de staking apenas por inflação. Isto alinha os incentivos de todos para atrair utilizadores reais que pagam por serviços de IA, o que por sua vez devolve valor aos detentores de tokens. Vale a pena notar que a cadeia da Cuckoo também tinha taxas para transações (gás), então os mineradores que produziam blocos (inicialmente os mineradores de GPU também contribuíam para a produção de blocos na cadeia Cuckoo) também recebiam taxas de gás. Com o encerramento da cadeia e a migração para um rollup, as taxas de gás provavelmente serão mínimas (ou no Ethereum), então a principal receita torna-se as próprias taxas de serviço de IA. Em resumo, a Cuckoo está a transitar de um modelo impulsionado por subsídios (a rede paga aos participantes do seu pool de tokens) para um modelo impulsionado pela procura (os participantes ganham de pagamentos reais de utilizadores). O token ainda desempenhará um papel no staking e na governança, mas os ganhos diários dos mineradores e desenvolvedores de aplicações devem vir cada vez mais de utilizadores que compram serviços de IA. Este modelo é mais sustentável a longo prazo e espelha de perto a partilha de receitas SaaS da Web2, mas implementado através de contratos inteligentes e tokens para transparência.

Superfícies de Ataque e Vulnerabilidades​

A descentralização da IA introduz vários desafios de incentivo e segurança. Analisamos agora os principais vetores de ataque – ataques sybil, conluio, parasitismo e envenenamento de dados/modelos – e como cada plataforma os mitiga ou permanece vulnerável a eles:

• Ataques Sybil (identidades falsas): Numa rede aberta, um atacante pode criar muitas identidades (nós) para obter recompensas ou influência desproporcionais.

  • Bittensor: A resistência a ataques sybil é fornecida principalmente pelo custo de entrada. Para registar um novo minerador ou validador no Bittensor, é necessário gastar ou fazer stake de TAO – isto pode ser um requisito de queima ou de depósito. Isto significa que criar N nós falsos incorre em N vezes o custo, tornando grandes enxames sybil caros. Além disso, o consenso do Bittensor liga a influência ao stake e ao desempenho; um sybil sem stake ou com mau desempenho ganha pouco. Um atacante teria de investir pesadamente e também fazer com que os seus nós sybil contribuíssem com trabalho útil para obter qualquer recompensa significativa (o que não é uma estratégia sybil típica). Dito isto, se um atacante tiver muito capital, ele poderia adquirir a maioria do TAO e registar muitos validadores ou mineradores – efetivamente um sybil por riqueza. Isto sobrepõe-se ao cenário de ataque de 51%: se uma única entidade controlar >50% do TAO em stake numa sub-rede, eles podem influenciar fortemente o consenso. A introdução do dTAO pelo Bittensor ajuda um pouco aqui: espalha a influência por sub-redes e requer o apoio de staking da comunidade para que as sub-redes prosperem, tornando mais difícil para uma entidade controlar tudo. Ainda assim, ataques sybil por um adversário bem financiado continuam a ser uma preocupação – a análise do Arxiv nota explicitamente que o stake está bastante concentrado agora, então a barreira para um ataque de maioria não é tão alta quanto desejado. Para mitigar isto, foram sugeridas propostas como limites de stake por carteira (por exemplo, limitar o stake efetivo no 88º percentil para evitar que uma carteira domine). Em resumo, o Bittensor depende da identidade ponderada por stake (não se pode criar identidades baratas sem stake proporcional) para lidar com sybils; é razoavelmente eficaz, exceto sob um atacante muito engenhoso.
  • Gensyn: Ataques sybil na Gensyn manifestar-se-iam como um atacante a criar muitos nós solver ou verifier para manipular o sistema. A defesa da Gensyn é puramente económica e criptográfica – as identidades em si não importam, mas fazer trabalho ou colocar colateral sim. Se um atacante criar 100 nós solver falsos, mas eles não tiverem trabalhos ou stake, não conseguem nada. Para ganhar tarefas, um nó sybil teria de licitar competitivamente e ter o hardware para fazer o trabalho. Se eles licitarem abaixo do preço sem capacidade, falharão e perderão o stake. Da mesma forma, um atacante poderia criar muitas identidades de verificador na esperança de ser escolhido para verificar (se o protocolo selecionar verificadores aleatoriamente). Mas se houver muitos, a rede ou o publicador do trabalho pode limitar o número de verificadores ativos. Além disso, os verificadores precisam potencialmente de realizar a computação para verificá-la, o que é dispendioso; ter muitos verificadores falsos não ajuda, a menos que se possa realmente verificar os resultados. Um ângulo sybil mais pertinente na Gensyn é se um atacante tentar encher a rede com trabalhos ou respostas falsas para desperdiçar o tempo dos outros. Isso é mitigado exigindo também um depósito dos submitters (um submitter malicioso que publica trabalhos falsos perde o seu pagamento ou depósito). No geral, o uso de stakes/depósitos obrigatórios e a seleção aleatória para verificação pela Gensyn significa que um atacante ganha pouco ao ter múltiplas identidades, a menos que também traga recursos proporcionais. Torna-se um ataque mais caro em vez de um barato. O modelo de segurança otimista assume pelo menos um verificador honesto – os sybils teriam de sobrecarregar e ser todos os verificadores para trapacear consistentemente, o que novamente volta a possuir a maioria do stake ou do poder computacional. A resistência sybil da Gensyn é, portanto, comparável à de um rollup otimista: enquanto houver um ator honesto, os sybils não podem causar danos sistémicos facilmente.
  • Cuckoo: A prevenção de ataques sybil na Cuckoo depende do staking e da avaliação da comunidade. Cada papel na Cuckoo (minerador, coordenador, até mesmo utilizador em alguns casos) requer o staking de $CAI. Isto aumenta imediatamente o custo das identidades sybil – um atacante que crie 100 mineradores falsos precisaria de adquirir e bloquear stake para cada um. Além disso, o design da Cuckoo tem um elemento humano/comunitário: novos nós precisam de ganhar reputação através de votação on-chain. Um exército sybil de nós novos sem reputação é improvável que receba muitas tarefas ou a confiança dos utilizadores. Os coordenadores, em particular, têm de atrair utilizadores; um coordenador falso sem historial não obteria uso. Para os mineradores, os coordenadores podem ver as suas estatísticas de desempenho (tarefas bem-sucedidas, etc.) no Cuckoo Scan e preferirão mineradores fiáveis. A Cuckoo também tinha um número relativamente pequeno de mineradores (40 GPUs num ponto da beta), então qualquer influxo estranho de muitos nós seria notável. O ponto fraco potencial é se o atacante também explorar o sistema de reputação – por exemplo, eles fazem stake de muito CAI nos seus nós sybil para fazê-los parecer respeitáveis ou criam contas de “utilizador” falsas para se votarem a si mesmos. Isto é teoricamente possível, mas como tudo é curado por tokens, custa tokens fazê-lo (estaria essencialmente a votar com o seu próprio stake nos seus próprios nós). A equipa da Cuckoo também pode ajustar os parâmetros de staking e recompensa se for observado comportamento sybil (especialmente agora que se está a tornar um serviço de rollup mais centralizado; eles podem pausar ou penalizar maus atores). Em suma, os sybils são mantidos à distância ao exigir "pele em jogo" (stake) e precisar de aprovação da comunidade. Ninguém pode simplesmente entrar com centenas de GPUs falsas e colher recompensas sem um investimento significativo que os participantes honestos poderiam gastar melhor em hardware real e stake.

• Conluio: Aqui consideramos múltiplos participantes a conspirarem para manipular o sistema – por exemplo, validadores e mineradores em conluio no Bittensor, ou solvers e verifiers em conluio na Gensyn, etc.

  • Bittensor: O conluio foi identificado como uma preocupação real. No design original, um punhado de validadores poderia conspirar para sempre votar a favor de certos mineradores ou de si mesmos, distorcendo a distribuição de recompensas injustamente (isto foi observado como concentração de poder na sub-rede raiz). O consenso Yuma oferece alguma defesa: ao tomar uma mediana das pontuações dos validadores e penalizar aqueles que se desviam, impede que um pequeno grupo em conluio impulsione dramaticamente um alvo, a menos que sejam a maioria. Por outras palavras, se 3 de 10 validadores conspirarem para dar a um minerador uma pontuação super alta, mas os outros 7 não, as pontuações discrepantes dos conspiradores são cortadas e a recompensa do minerador é baseada na pontuação mediana (portanto, o conluio não ajuda significativamente). No entanto, se os conspiradores formarem >50% dos validadores (ou >50% do stake entre os validadores), eles efetivamente são o consenso – eles podem concordar em pontuações altas falsas e a mediana refletirá a sua visão. Este é o cenário clássico de ataque de 51%. Infelizmente, o estudo do Arxiv descobriu que algumas sub-redes do Bittensor, onde uma coligação de apenas 1-2% dos participantes (em termos de contagem) controlava a maioria do stake, devido à forte concentração de tokens. Isto significa que o conluio por alguns grandes detentores era uma ameaça credível. A mitigação que o Bittensor está a seguir através do dTAO é democratizar a influência: ao permitir que qualquer detentor de TAO direcione o stake para as sub-redes, dilui o poder de grupos fechados de validadores. Além disso, propostas como staking côncavo (retornos decrescentes para stake excessivo) e limites de stake visam quebrar a capacidade de uma entidade em conluio de acumular demasiado poder de voto. A suposição de segurança do Bittensor agora é semelhante à prova de participação: nenhuma entidade única (ou cartel) a controlar >50% do stake ativo. Enquanto isso se mantiver, o conluio é limitado porque os validadores honestos anularão as pontuações más e os proprietários de sub-redes em conluio não podem aumentar arbitrariamente as suas próprias recompensas. Finalmente, sobre o conluio entre proprietários de sub-redes e validadores (por exemplo, um proprietário de sub-rede a subornar validadores para classificarem bem os mineradores da sua sub-rede), o dTAO remove o controlo direto dos validadores, substituindo-o por decisões dos detentores de tokens. É mais difícil conspirar com “o mercado”, a menos que se compre a oferta de tokens – nesse caso, não é realmente conluio, é uma aquisição. Portanto, a principal técnica anti-conluio do Bittensor é o consenso algorítmico (corte da mediana) e a ampla distribuição de tokens.

  • Gensyn: O conluio na Gensyn provavelmente envolveria um solver e um verifier (ou múltiplos verifiers) a conspirarem para enganar o sistema. Por exemplo, um solver poderia produzir um resultado falso e um verifier em conluio poderia intencionalmente não o desafiar (ou até mesmo atestar que está correto se o protocolo pedisse aos verifiers para assinarem). Para mitigar isto, o modelo de segurança da Gensyn requer pelo menos um verifier honesto. Se todos os verifiers estiverem em conluio com o solver, então um resultado mau passa sem ser desafiado. A Gensyn aborda isto incentivando muitos verifiers independentes (qualquer um pode verificar) e pela teoria dos jogos de que um verifier poderia ganhar uma grande recompensa ao quebrar o conluio e desafiar (porque receberia o stake do solver). Essencialmente, mesmo que haja um grupo a concordar em conspirar, cada membro tem um incentivo para desertar e reivindicar a recompensa para si – esta é uma configuração clássica do Dilema do Prisioneiro. A esperança é que isso mantenha os grupos de conluio pequenos ou ineficazes. Outro conluio potencial é entre múltiplos solvers para aumentar os preços ou monopolizar tarefas. No entanto, como os desenvolvedores podem escolher onde publicar as tarefas (e as tarefas não são unidades idênticas que podem ser facilmente monopolizadas), o conluio de solvers no preço seria difícil de coordenar globalmente – qualquer solver que não estivesse em conluio poderia licitar mais baixo para ganhar o trabalho. A dinâmica de mercado aberto contraria o conluio de preços, assumindo pelo menos alguns participantes competitivos. Mais um ângulo: conluio de verifiers para prejudicar solvers – por exemplo, verifiers a acusarem falsamente solvers honestos para roubar o seu stake. A prova de fraude da Gensyn é binária e on-chain; uma acusação falsa falharia quando a recomputação on-chain não encontrasse erro, e presumivelmente o verifier malicioso perderia então algo (talvez um depósito ou reputação). Portanto, um conluio de verifiers a tentar sabotar solvers seria apanhado pelo processo de verificação do protocolo. Em resumo, a arquitetura da Gensyn é robusta enquanto pelo menos uma parte em qualquer conjunto em conluio tiver um incentivo para ser honesta – uma propriedade da verificação otimista semelhante a exigir um minerador honesto no Bitcoin para eventualmente expor uma fraude. O conluio é teoricamente possível se um atacante puder controlar todos os verifiers e solvers numa tarefa (como a maioria da rede), mas então eles poderiam simplesmente trapacear sem precisar de conluio per se. Os incentivos criptoeconómicos são organizados para tornar a sustentação do conluio irracional.

  • Cuckoo: O conluio na Cuckoo poderia acontecer de algumas maneiras:

    1. Um coordenador em conluio com mineradores – por exemplo, um coordenador poderia sempre atribuir tarefas a um conjunto de mineradores amigos e dividir as recompensas, ignorando outros mineradores honestos. Como os coordenadores têm discrição no agendamento de tarefas, isto pode acontecer. No entanto, se os mineradores amigos forem de qualidade inferior, os utilizadores finais podem notar um serviço lento ou mau e sair, então o coordenador é desincentivado de um favoritismo puro que prejudica a qualidade. Se o conluio for para manipular recompensas (digamos, submeter tarefas falsas para dar tokens aos mineradores), isso seria detetado on-chain (muitas tarefas com talvez entradas idênticas ou nenhum utilizador real) e pode ser penalizado. A transparência on-chain da Cuckoo significa que quaisquer padrões incomuns poderiam ser sinalizados pela comunidade ou pela equipa principal. Além disso, como todos os participantes fazem stake, um anel de coordenador-minerador em conluio corre o risco de perder o seu stake se for apanhado a abusar do sistema (por exemplo, se a governança decidir penalizá-los por fraude).
    2. Mineradores em conluio entre si – eles podem partilhar informações ou formar um cartel para, digamos, todos votarem uns nos outros na reputação ou todos se recusarem a servir um coordenador específico para extrair taxas mais altas. Estes cenários são menos prováveis: a votação de reputação é feita por stakers (incluindo utilizadores), não pelos próprios mineradores a votarem uns nos outros. E recusar serviço apenas levaria os coordenadores a encontrar outros mineradores ou a levantar alarmes. Dada a escala relativamente pequena atualmente, qualquer conluio seria difícil de esconder.
    3. Conluio para manipular a governança – grandes detentores de CAI poderiam conspirar para aprovar propostas a seu favor (como definir uma taxa exorbitante ou redirecionar o tesouro). Este é um risco em qualquer governança de tokens. A melhor mitigação é distribuir amplamente o token (o lançamento justo da Cuckoo deu 51% à comunidade) e ter uma supervisão comunitária ativa. Além disso, como a Cuckoo se afastou da L1, a governança on-chain imediata pode ser limitada até que se estabeleçam numa nova cadeia; a equipa provavelmente mantém um controlo multisig no entretanto, o que ironicamente impede o conluio por estranhos maliciosos à custa de ser temporariamente centralizado. No geral, a Cuckoo apoia-se na transparência e no staking para lidar com o conluio. Há um elemento de confiança nos coordenadores para se comportarem porque querem atrair utilizadores num ambiente competitivo. Se o conluio levar a um serviço de pior qualidade ou a uma manipulação óbvia de recompensas, os stakeholders podem votar para os remover ou parar de fazer stake em maus atores, e a rede pode penalizá-los ou bloqueá-los. A natureza razoavelmente aberta (qualquer um pode tornar-se um coordenador ou minerador se fizer stake) significa que o conluio exigiria um grande esforço coordenado que seria evidente. Não é tão matematicamente prevenido como no Bittensor ou na Gensyn, mas a combinação de stake económico e governança comunitária fornece um controlo.

• Parasitismo (Problemas de Free-rider): Refere-se a participantes que tentam colher recompensas sem contribuir com valor equivalente – por exemplo, um validador que não avalia realmente, mas ainda assim ganha, ou um minerador que copia as respostas de outros em vez de computar, ou utilizadores a cultivar recompensas sem fornecerem entradas úteis.

  • Bittensor: Um problema conhecido de free-rider no Bittensor é a “cópia de pesos” por validadores preguiçosos. Um validador poderia simplesmente copiar a opinião da maioria (ou as pontuações de outro validador) em vez de avaliar independentemente os mineradores. Ao fazer isso, eles evitam o custo de executar consultas de IA, mas ainda recebem recompensas se as suas pontuações submetidas parecerem alinhadas com o consenso. O Bittensor combate isto medindo o alinhamento de consenso e a contribuição informacional de cada validador. Se um validador sempre apenas copia os outros, ele pode alinhar-se bem (para não ser penalizado pesadamente), mas não adiciona valor único. Os desenvolvedores do protocolo discutiram dar recompensas mais altas a validadores que fornecem avaliações precisas, mas não puramente redundantes. Técnicas como a infusão de ruído (dar deliberadamente aos validadores consultas ligeiramente diferentes) poderiam forçá-los a trabalhar de verdade em vez de copiar – embora não esteja claro se isso está implementado. O Arxiv sugere emissão ponderada pelo desempenho e métodos de pontuação composta para ligar melhor o esforço do validador à recompensa. Quanto aos mineradores, um possível comportamento de free-rider seria se um minerador consultasse outros mineradores e retransmitisse a resposta (uma forma de plágio). O design do Bittensor (com consultas descentralizadas) pode permitir que o modelo de um minerador chame outros através do seu próprio dendrite. Se um minerador apenas retransmite a resposta de outro, um bom validador pode detetar isso porque a resposta pode não corresponder consistentemente às capacidades do modelo reivindicadas pelo minerador. É difícil de detetar algoritmicamente, mas um minerador que nunca computa resultados originais deve eventualmente pontuar mal em algumas consultas e perder reputação. Outro cenário de free-rider eram os delegadores a ganharem recompensas sem fazerem trabalho de IA. Isso é intencional (para envolver os detentores de tokens), então não é um ataque – mas significa que algumas emissões de tokens vão para pessoas que apenas fizeram stake. O Bittensor justifica isto como alinhamento de incentivos, não recompensas desperdiçadas. Em suma, o Bittensor reconhece o problema do free-rider do validador e está a ajustar os incentivos (como dar pontuações de confiança do validador que impulsionam aqueles que não se desviam ou copiam). A sua solução é essencialmente recompensar o esforço e a correção de forma mais explícita, para que não fazer nada ou copiar cegamente renda menos TAO ao longo do tempo.
  • Gensyn: Na Gensyn, os free-riders teriam dificuldade em ganhar, porque é preciso fornecer computação ou apanhar alguém a trapacear para obter tokens. Um solver não pode “fingir” trabalho – ele tem de submeter uma prova válida ou arriscar-se a ser penalizado. Não há mecanismo para ser pago sem fazer a tarefa. Um verifier poderia teoricamente ficar ocioso e esperar que outros apanhassem fraudes – mas então não ganha nada (porque apenas aquele que levanta a prova de fraude recebe a recompensa). Se demasiados verifiers tentarem ser free-riders (não recomputando realmente as tarefas), então um solver fraudulento pode passar despercebido porque ninguém está a verificar. O design de incentivos da Gensyn aborda isto com a recompensa jackpot: basta um verifier ativo para apanhar um trapaceiro e obter um grande pagamento, então é racional que pelo menos um faça sempre o trabalho. Outros que não fazem o trabalho não prejudicam a rede, exceto por serem inúteis; eles também não recebem recompensa. Assim, o sistema filtra naturalmente os free-riders: apenas os verifiers que realmente verificam terão lucro a longo prazo (outros gastam recursos em nós para nada ou muito raramente conseguem uma recompensa por acaso). O protocolo também pode randomizar qual verifier tem a oportunidade de desafiar para desencorajar todos os verifiers de assumirem que “alguém fará isso”. Como as tarefas são pagas individualmente, não há um análogo de “recompensas de staking sem trabalho”, além dos incentivos da testnet que são temporários. Uma área a observar é a otimização multitarefa: um solver pode tentar reutilizar o trabalho entre tarefas ou terceirizá-lo secretamente para alguém mais barato (como usar uma nuvem centralizada) – mas isso não é realmente um parasitismo prejudicial; se eles entregarem resultados corretos a tempo, não importa como o fizeram. Isso é mais como arbitragem do que um ataque. Em resumo, o design do mecanismo da Gensyn deixa pouco espaço para os free-riders ganharem, porque cada token distribuído corresponde a um trabalho feito ou a uma trapaça punida.
  • Cuckoo: A fase inicial da Cuckoo criou inadvertidamente um problema de free-rider: o airdrop e o staking de alto rendimento atraíram utilizadores que estavam lá apenas para cultivar tokens. Estes utilizadores circulavam tokens através de faucets ou manipulavam as tarefas do airdrop (por exemplo, usando continuamente prompts de teste gratuitos ou criando muitas contas para reivindicar recompensas) sem contribuírem para o valor da rede a longo prazo. A Cuckoo reconheceu isto como um problema – essencialmente, as pessoas estavam a “usar” a rede não pela saída de IA, mas pelo ganho de recompensa especulativa. A decisão de encerrar a cadeia L1 e reorientar foi em parte para se livrar destes desalinhamentos de incentivos. Ao ligar as futuras recompensas de tokens ao uso real (ou seja, você ganha porque o serviço está realmente a ser usado por clientes pagantes), o apelo do free-rider diminui. Há também um cenário de parasitismo do lado do minerador: um minerador poderia juntar-se, receber tarefas e de alguma forma não as executar, mas ainda assim reivindicar a recompensa. No entanto, o coordenador está a verificar os resultados – se um minerador não devolver nenhuma saída ou uma saída má, o coordenador não a contará como uma tarefa concluída, então o minerador não seria pago. Os mineradores também podem tentar escolher as tarefas fáceis e abandonar as difíceis (por exemplo, se alguns prompts forem mais lentos, um minerador pode desconectar-se para evitá-los). Isto poderia ser um problema, mas os coordenadores podem notar a fiabilidade de um minerador. Se um minerador abandona frequentemente, o coordenador pode parar de lhe atribuir tarefas ou penalizar o seu stake (se tal mecanismo existir ou simplesmente não o recompensar). Parasitismo do utilizador – como muitos serviços de IA têm testes gratuitos, um utilizador poderia enviar spam de pedidos para obter resultados sem pagar (se houver um modelo subsidiado). Isso não é tanto um problema ao nível do protocolo, mas sim ao nível do serviço; cada coordenador pode decidir como lidar com o uso gratuito (por exemplo, exigindo um pequeno pagamento ou limitando). Como a Cuckoo inicialmente ofereceu brindes (como gerações de imagens de IA gratuitas para atrair utilizadores), alguns aproveitaram-se, mas isso fazia parte do marketing de crescimento esperado. À medida que essas promoções terminam, os utilizadores terão de pagar, portanto, não há almoço grátis para explorar. No geral, a nova estratégia da Cuckoo de mapear a distribuição de tokens para a utilidade real visa explicitamente eliminar o problema do free-rider de “minerar tokens por fazer loops sem sentido”.

• Envenenamento de Dados ou Modelos: Refere-se à introdução maliciosa de dados ou comportamentos maus de modo que os modelos de IA se degradem ou os resultados sejam manipulados, bem como questões de conteúdo prejudicial ou tendencioso a ser contribuído.

  • Bittensor: O envenenamento de dados no Bittensor significaria um minerador a dar intencionalmente respostas incorretas ou prejudiciais, ou validadores a avaliar propositadamente respostas boas como más. Se um minerador produzir lixo ou conteúdo malicioso consistentemente, os validadores darão pontuações baixas, e esse minerador ganhará pouco e eventualmente sairá – o incentivo económico é fornecer qualidade, então “envenenar” os outros não traz benefício para o atacante (a menos que o seu objetivo seja puramente sabotagem às suas próprias custas). Poderia um minerador malicioso envenenar outros? No Bittensor, os mineradores não se treinam diretamente uns aos outros (pelo menos não por design – não há um modelo global a ser atualizado que possa ser envenenado). O modelo de cada minerador é separado. Eles aprendem no sentido de que um minerador poderia pegar amostras interessantes de outros para se ajustar, mas isso é totalmente opcional e depende de cada um. Se um ator malicioso enviasse spam de respostas sem sentido, os validadores honestos filtrariam isso (eles pontuariam baixo), então não influenciaria significativamente o processo de treinamento de nenhum minerador honesto (além disso, um minerador provavelmente usaria o conhecimento de pares com alta pontuação, não de baixa pontuação). Portanto, o envenenamento de dados clássico (injetar dados de treinamento maus para corromper um modelo) é mínimo na configuração atual do Bittensor. O risco mais relevante é a manipulação da resposta do modelo: por exemplo, um minerador que produz conteúdo subtilmente tendencioso ou perigoso que não é óbvio para os validadores. No entanto, como os validadores também são projetados por humanos ou pelo menos agentes algorítmicos, a toxicidade ou erro flagrante é provavelmente detetado (algumas sub-redes podem até ter validadores de IA a verificar conteúdo inseguro). Um cenário de pior caso é se um atacante de alguma forma tivesse a maioria dos validadores e mineradores em conluio para empurrar uma certa saída incorreta como “correta” – eles poderiam então enviesar o consenso da rede sobre as respostas (como todos os validadores em conluio a votarem a favor de uma resposta maliciosa). Mas para um utilizador externo ser prejudicado por isso, ele teria de realmente consultar a rede e confiar na saída. O Bittensor ainda está numa fase em que está a construir capacidade, não sendo amplamente usado para consultas críticas por utilizadores finais. Quando o for, espera-se que tenha filtragem de conteúdo e diversidade de validadores para mitigar tais riscos. Do lado do validador, um validador malicioso poderia fornecer avaliações envenenadas – por exemplo, consistentemente votar contra um certo minerador honesto para eliminar a concorrência. Com stake suficiente, eles podem conseguir empurrar esse minerador para fora (se as recompensas do minerador caírem tanto que ele saia). Este é um ataque ao mecanismo de incentivo. Novamente, se eles não forem a maioria, o corte da mediana frustrará um validador discrepante. Se eles forem a maioria, funde-se com o cenário de conluio/51% – qualquer maioria pode reescrever as regras. A solução volta à descentralização: impedir que qualquer entidade domine. Em resumo, o design do Bittensor inerentemente penaliza contribuições de dados/modelos envenenados através do seu sistema de pontuação – contribuições más recebem baixo peso e, portanto, baixa recompensa. Não há um repositório de modelos permanente para envenenar; tudo é dinâmico e continuamente avaliado. Isto proporciona resiliência: a rede pode gradualmente “esquecer” ou ignorar maus atores à medida que as suas contribuições são filtradas pelos validadores.
  • Gensyn: Se um solver quisesse envenenar um modelo a ser treinado (como introduzir uma backdoor ou viés durante o treinamento), ele poderia tentar fazê-lo secretamente. O protocolo Gensyn verificaria se o treinamento prosseguiu de acordo com o algoritmo especificado (passos de descida de gradiente estocástico, etc.), mas não detetaria necessariamente se o solver introduziu um gatilho de backdoor subtil que não aparece nas métricas de validação normais. Este é um problema mais insidioso – não é uma falha da computação, é uma manipulação dentro dos graus de liberdade permitidos do treinamento (como ajustar os pesos para uma frase gatilho). Detetar isso é um problema de pesquisa ativo em segurança de ML. A Gensyn não tem um mecanismo especial para envenenamento de modelos além do facto de que o submitter poderia avaliar o modelo final num conjunto de teste à sua escolha. Um submitter experiente deve sempre testar o modelo devolvido; se descobrir que ele falha em algumas entradas ou tem um comportamento estranho, pode disputar o resultado ou recusar o pagamento. Talvez o protocolo pudesse permitir que um submitter especificasse certos critérios de aceitação (como “o modelo deve atingir pelo menos X de precisão neste conjunto de teste secreto”) e se o resultado do solver falhar, o solver não é pago na totalidade. Isto dissuadiria o envenenamento porque o atacante não cumpriria os critérios de avaliação. No entanto, se o veneno não impactar a precisão em testes normais, poderia passar despercebido. Os verifiers na Gensyn apenas verificam a integridade da computação, não a qualidade do modelo, então não detetariam overfitting intencional ou trojans, desde que os registos de treinamento pareçam válidos. Portanto, isto permanece uma questão de confiança ao nível da tarefa: o submitter tem de confiar que o solver não envenenará o modelo ou usar métodos como ensembling de múltiplos resultados de treinamento de diferentes solvers para diluir a influência de qualquer solver único. Outro ângulo é o envenenamento de dados: se o submitter fornecer dados de treinamento, um solver malicioso poderia ignorar esses dados e treinar em outra coisa ou adicionar dados lixo. Mas isso provavelmente reduziria a precisão, o que o submitter notaria no desempenho do modelo de saída. O solver então não receberia o pagamento total (já que presumivelmente eles querem atingir uma meta de desempenho). Portanto, o envenenamento que degrada o desempenho é autodestrutivo para a recompensa do solver. Apenas um veneno que é neutro em desempenho, mas malicioso (uma backdoor) é um perigo real, e isso está fora do âmbito da verificação típica de blockchain – é um desafio de segurança de machine learning. A melhor mitigação da Gensyn é provavelmente social: usar modelos conhecidos e respeitáveis, ter várias execuções de treinamento, usar ferramentas de código aberto. Em tarefas de inferência (se a Gensyn também for usada para trabalhos de inferência), um solver em conluio poderia retornar saídas incorretas que enviesam uma certa resposta. Mas os verifiers detetariam saídas erradas se executassem o mesmo modelo, então isso é menos um envenenamento e mais apenas trapaça, que as provas de fraude abordam. Em suma, a Gensyn protege o processo, não a intenção. Garante que o treinamento/inferência foi feito corretamente, mas não que o resultado é bom ou livre de malícias ocultas. Isso permanece um problema em aberto, e o whitepaper da Gensyn provavelmente não o resolve totalmente ainda (poucos o fazem).
  • Cuckoo: Como a Cuckoo atualmente se foca na inferência (servindo modelos existentes), o risco de envenenamento de dados/modelos é relativamente limitado à manipulação de saída ou envenenamento de conteúdo. Um minerador malicioso pode tentar adulterar o modelo que lhe é dado para executar – por exemplo, se for fornecido um checkpoint do Stable Diffusion, ele poderia trocá-lo por um modelo diferente que talvez insira alguma marca d'água subtil ou anúncio em cada imagem. No entanto, o coordenador (que é o proprietário do modelo) normalmente envia tarefas com uma expectativa do formato de saída; se um minerador retornar saídas fora da especificação consistentemente, o coordenador sinalizará e banirá esse minerador. Além disso, os mineradores não podem modificar facilmente um modelo sem afetar notavelmente as suas saídas. Outro cenário é se a Cuckoo introduzir modelos treinados pela comunidade: então os mineradores ou fornecedores de dados podem tentar envenenar os dados de treinamento (por exemplo, alimentar muitos rótulos errados ou texto tendencioso). A Cuckoo precisaria de implementar a validação de dados de crowdsourcing ou a ponderação de contribuidores. Isto ainda não é uma funcionalidade, mas o interesse da equipa em IA personalizada (como a menção a um coach de vida de IA ou aplicações de aprendizagem) significa que eles podem eventualmente lidar com dados de treinamento fornecidos pelo utilizador, o que exigirá verificações cuidadosas. Sobre a segurança do conteúdo, como os mineradores da Cuckoo realizam inferência, pode-se preocupar com eles a produzirem conteúdo prejudicial, mesmo que o modelo normalmente não o fizesse. Mas os mineradores não têm incentivo para alterar as saídas arbitrariamente – eles são pagos pela computação correta, não pela criatividade. Se alguma coisa, um minerador malicioso pode saltar a computação completa para economizar tempo (por exemplo, retornar uma imagem desfocada ou uma resposta genérica). O coordenador ou o utilizador veria isso e classificaria mal esse minerador (e provavelmente não pagaria por essa tarefa). A privacidade é outra faceta: um minerador malicioso pode vazar ou registar dados do utilizador (como se um utilizador inserisse texto ou imagens sensíveis). Isto não é envenenamento, mas é um ataque à confidencialidade. A postura de privacidade da Cuckoo é que está a explorar métodos de preservação da privacidade (a menção a uma VPN que preserva a privacidade no ecossistema sugere um foco futuro). Eles poderiam incorporar técnicas como enclaves seguros ou inferência dividida para manter os dados privados dos mineradores. Ainda não implementado, mas uma consideração conhecida. Finalmente, o blog da Cuckoo enfatiza a verificação eficaz das saídas do modelo e a garantia de uma operação de modelo descentralizada segura como chave para tornar a tokenização de modelos viável. Isto indica que eles estão cientes de que para descentralizar verdadeiramente a IA, é preciso proteger-se contra coisas como saídas envenenadas ou modelos com mau funcionamento. Possivelmente, eles pretendem usar uma combinação de incentivos criptoeconómicos (penalização de stake para maus atores) e sistemas de classificação de utilizadores (os utilizadores podem sinalizar saídas más, e esses mineradores perdem reputação). O sistema de reputação pode ajudar aqui: se um minerador retornar mesmo um resultado obviamente malicioso ou incorreto, os utilizadores/coordenadores podem votar negativamente, impactando fortemente a sua capacidade de ganho futuro. Sabendo disso, os mineradores são incentivados a serem consistentemente corretos e a não introduzirem nenhum veneno. Em essência, a Cuckoo confia, mas verifica: é mais tradicional no sentido de que se alguém se comportar mal, você identifica e remove-o (com a perda de stake como punição). Ainda não tem defesas especializadas para envenenamento subtil de modelos, mas a estrutura de ter proprietários de aplicações específicos (coordenadores) no comando adiciona uma camada de supervisão – esses proprietários serão motivados a garantir que nada comprometa a integridade do seu modelo, pois a sua própria receita e reputação dependem disso.

Em conclusão, embora as redes de IA descentralizadas introduzam novas superfícies de ataque, elas também implementam uma mistura de defesas criptográficas, de teoria dos jogos e de governança comunitária: A resistência a ataques sybil é em grande parte tratada pela exigência de stake económico para participação. A resistência ao conluio vem do alinhamento de incentivos (o comportamento honesto é mais lucrativo) e de mecanismos de consenso que limitam o impacto de pequenos grupos em conluio. A prevenção de free-riders é alcançada ao ligar estreitamente as recompensas ao trabalho útil real e penalizar ou eliminar aqueles que não contribuem com nada. O envenenamento e ataques relacionados continuam a ser desafiadores, mas os sistemas mitigam os casos flagrantes através de avaliação contínua e da capacidade de penalizar ou ejetar atores maliciosos. Estas plataformas estão ativamente a pesquisar e a iterar nestes designs – como evidenciado pelos ajustes contínuos do Bittensor ao Yuma e ao dTAO, e pela mudança na tokenomics da Cuckoo – para garantir um ecossistema de IA descentralizado, seguro e autossustentável.

Avaliação Comparativa​

Para destacar as diferenças e semelhanças entre Bittensor, Gensyn e Cuckoo AI, a tabela seguinte fornece uma comparação lado a lado através de dimensões-chave:

Dimensão	Bittensor (TAO)	Gensyn	Cuckoo AI (CAI)
Pilha Técnica	L1 personalizada (cadeia Subtensor baseada em Substrate) com mais de 93 sub-redes de IA especializadas. Compatível com EVM (após atualização recente) na sua própria cadeia.	Rollup baseado em Ethereum (originalmente planeado como L1, agora um rollup ETH). Computação off-chain com verificação on-chain.	Lançada como uma cadeia Layer-2 Arbitrum Orbit (rollup EVM). Plataforma full-stack (cadeia própria + computação + UI de aplicação). A migrar de L1 personalizada para segurança partilhada do Ethereum (rollup/AVS).
Foco Principal	Rede de IA descentralizada de modelos (“internet neural”). Os nós contribuem para a inferência e treinamento de modelos coletivos em várias tarefas (LLM, visão, etc.).	Mercado de computação descentralizado para ML. Ênfase no treinamento de modelos off-chain e inferência por GPUs globais, verificando o trabalho através da blockchain.	Plataforma de serviço de IA descentralizada. Foco no serviço/inferência de modelos (por exemplo, arte generativa, APIs de LLM) usando mineradores de GPU distribuídos. Integra aplicações de utilizador final com o mercado de GPU de backend.
Papéis Chave	Proprietário de Sub-rede: define a tarefa e a validação numa sub-rede (ganha 18% das recompensas). Mineradores: executam modelos de IA (inferência/treinamento), fornecem respostas. Validadores: fazem consultas e pontuam as saídas dos mineradores (curam a qualidade). Delegadores: fazem stake de TAO em mineradores/validadores para amplificar e ganhar uma parte.	Submitter (Desenvolvedor): publica um trabalho de ML (com modelo/dados) e pagamento. Solver: computa a tarefa no seu hardware, submete o resultado. Verifier (Vigilante): verifica o resultado do solver; pode desafiar através de prova de fraude se estiver errado. (Nenhum papel distinto de “proprietário”, uma vez que o submitter fornece o modelo; papéis de governança através dos detentores de tokens).	Construtor de Aplicação de IA (Coordenador): implementa o serviço de modelo de IA, faz stake de CAI, gere tarefas para os mineradores. Minerador (Fornecedor de GPU/CPU): faz stake de CAI, realiza tarefas de inferência atribuídas, retorna resultados. Utilizador Final: usa aplicações de IA (paga em cripto ou contribui com recursos). Staker (Delegador): faz stake em coordenadores/mineradores, vota na governança, ganha uma parte das recompensas.
Consenso e Verificação	Consenso Yuma: “prova de inteligência” personalizada – as pontuações dos validadores sobre a saída de IA são agregadas (mediana ponderada por stake) para determinar as recompensas dos mineradores. O consenso da cadeia subjacente é do tipo PoS (Substrate) para blocos, mas a validade do bloco depende do consenso de IA a cada época. Resistente a pontuações discrepantes e conluio até 50%.	Verificação otimista (estilo Truebit): assume que o resultado do solver está correto, a menos que um verificador o desafie. Usa provas de fraude interativas on-chain para identificar qualquer passo incorreto. Também a implementar provas criptográficas de computação (prova de aprendizagem) para validar o progresso do treinamento sem reexecução. O Ethereum fornece o consenso base para as transações.	Cadeia Proof-of-Stake + validação de tarefas por coordenadores: A Cuckoo Chain usava validadores PoS para a produção de blocos (inicialmente, os mineradores também ajudavam a proteger os blocos). Os resultados das tarefas de IA são verificados pelos nós coordenadores (que verificam as saídas dos mineradores em relação ao comportamento esperado do modelo). Ainda não há provas criptográficas especializadas – depende do stake e da reputação (trustless na medida em que o mau comportamento leva a penalizações ou votos negativos, em vez de deteção automática por prova matemática). A transitar para o consenso do Ethereum (rollup) para a segurança do livro-razão.
Token e Utilidade	Token TAO: moeda nativa no Subtensor. Usado para staking (necessário para registar e influenciar o consenso), taxas de transação/pagamentos (por exemplo, pagar por consultas de IA) e como recompensa por contribuições (mineração/validação). O TAO tem inflação contínua (1 TAO por bloco de 12s) que impulsiona o mecanismo de recompensa. Também usado na governança (staking de dTAO em sub-redes).	Token Gensyn (ERC-20, nome a ser anunciado): a unidade do protocolo para pagamentos (os desenvolvedores pagam aos solvers com ele). Funciona como colateral de stake (solvers/verifiers depositam tokens e são penalizados por falhas). Será usado na governança (votação em atualizações do protocolo através da DAO da Fundação Gensyn). Sem detalhes sobre a oferta ainda; provavelmente uma porção alocada para incentivar a adoção inicial (testnet, etc.).	Token CAI (ERC-20): token nativo da Cuckoo Chain (1 bilião de oferta fixa). Multifuncional: taxa de gás para transações na Cuckoo Chain, staking para papéis na rede (mineradores, coordenadores devem bloquear CAI), votação de governança em decisões do protocolo e recompensas por contribuições (recompensas de mineração/staking vieram da alocação inicial). Também tem apelo de meme (aspeto de token comunitário).
Tokenização de Ativos	Computação: sim – o trabalho de computação de IA é tokenizado através de recompensas TAO (pense no TAO como “gás” para inteligência). Modelos: indiretamente – os modelos ganham TAO com base no desempenho, mas os modelos/pesos em si não são ativos on-chain (não há NFTs para modelos). A propriedade da sub-rede é tokenizada (NFT de proprietário de sub-rede + tokens alfa) para representar uma participação num mercado de modelos. Dados: não tokenizados (os dados são off-chain; o Bittensor foca-se nas saídas dos modelos em vez de conjuntos de dados).	Computação: sim – a computação ociosa torna-se uma mercadoria on-chain, negociada num mercado de trabalhos por tokens. Modelos: não explicitamente – os modelos são fornecidos off-chain pelos desenvolvedores, e os resultados são devolvidos; não há tokens de modelo integrados (embora o protocolo possa facilitar o licenciamento se as partes o configurarem). Dados: não – os conjuntos de dados são tratados off-chain entre o submitter e o solver (podem ser encriptados ou protegidos, mas não representados como ativos on-chain). A visão da Gensyn inclui possivelmente a negociação de algoritmos ou dados como computação, mas a implementação principal é centrada na computação.	Computação: sim – o tempo de GPU é tokenizado através de pagamentos diários de CAI e recompensas de tarefas. A rede trata o poder computacional como um recurso que os mineradores “vendem” por CAI. Modelos: parcialmente – a plataforma integra modelos como serviços; no entanto, os modelos em si não são criados como NFTs. O valor de um modelo é capturado na capacidade do coordenador de ganhar CAI dos utilizadores que o usam. Planos futuros sugerem modelos de propriedade comunitária, mas atualmente a PI do modelo é off-chain (propriedade de quem executa o coordenador). Dados: sem tokenização geral de dados. As entradas/saídas dos utilizadores são transitórias. (A Cuckoo tem parcerias com aplicações como Beancount, etc., mas os dados não são representados por tokens na cadeia.)
Governança	Descentralizada, impulsionada pelos detentores de tokens (dTAO): Inicialmente tinha 64 validadores eleitos a executar o consenso raiz; agora a governança é aberta – os detentores de TAO fazem stake em sub-redes para direcionar as emissões (alocação de recursos baseada no mercado). As atualizações e alterações do protocolo são decididas através de propostas on-chain (votação de TAO, com a Fundação/conselho Bittensor a facilitar). O objetivo é ser totalmente governado pela comunidade, com a fundação a ceder gradualmente o controlo.	Descentralização progressiva: Fundação Gensyn + conselho eleito gerem as decisões iniciais. Após o lançamento do token, a governança transitará para uma DAO onde os detentores de tokens votam em propostas (semelhante a muitos projetos DeFi). O ambiente de segurança partilhada do Ethereum significa que grandes mudanças envolvem a comunidade e potencialmente a governança da Camada 1. O âmbito da governança inclui parâmetros económicos, atualizações de contratos (sujeitas a auditorias de segurança). Ainda não está ativa, mas delineada no litepaper para pós-mainnet.	Mista, comunidade e fundação: A Cuckoo foi lançada com um ethos de “lançamento justo” (sem pré-mineração para insiders). Pretende-se uma DAO comunitária, com votação de CAI em decisões-chave e atualizações do protocolo. Na prática, a equipa principal (desenvolvedores da Cuckoo Network) liderou as principais decisões (como o encerramento da cadeia), mas partilham a lógica de forma transparente e posicionam-na como uma evolução para o benefício da comunidade. Funcionalidades de governança on-chain (propostas, votação) provavelmente surgirão quando o novo rollup estiver implementado. O staking também dá influência informal na governança através do sistema de reputação (votos ponderados por stake para nós de confiança).
Modelo de Incentivo	Recompensas inflacionárias ligadas à contribuição: ~1 TAO por bloco distribuído aos participantes com base no desempenho. Qualidade = mais recompensa. Mineradores e validadores ganham continuamente (bloco a bloco), mais os delegadores ganham uma parte. O TAO também é usado por utilizadores finais para pagar por serviços (criando um lado de procura para o token). A economia do token é projetada para encorajar a participação a longo prazo (staking) e a melhoria constante dos modelos, semelhante aos mineradores do Bitcoin, mas “minerando IA”. Problemas potenciais (centralização de stake levando a recompensas desalinhadas) estão a ser abordados através de ajustes de incentivos.	Impulsionado pelo mercado, pagamento por resultados: Sem rendimento inflacionário contínuo (além de possíveis incentivos iniciais); os solvers são pagos apenas quando fazem o trabalho com sucesso. Os verifiers só são pagos ao apanharem uma fraude (incentivo jackpot). Isto cria uma economia direta: o gasto dos desenvolvedores = o ganho dos fornecedores. O valor do token está ligado à procura real por computação. Para iniciar, a Gensyn provavelmente recompensará os utilizadores da testnet no lançamento (distribuição única), mas em estado estacionário, é baseado no uso. Isto alinha os incentivos firmemente com a utilidade da rede (se os trabalhos de IA aumentarem, o uso do token aumenta, beneficiando todos os detentores).	Híbrido (a mover-se de inflação para taxas de uso): Inicialmente, alocações de Mineração e staking do pool comunitário de 51% recompensavam os mineradores de GPU (30% da oferta) e stakers (11%) independentemente do uso externo – isto era para iniciar os efeitos de rede. Com o tempo, e especialmente após o encerramento da L1, a ênfase está na partilha de receitas: mineradores e desenvolvedores de aplicações ganham de pagamentos reais de utilizadores (por exemplo, dividindo taxas por uma geração de imagem). O rendimento dos stakers derivará de uma porção do uso real ou será ajustado para encorajar o apoio apenas a nós produtivos. Portanto, o incentivo inicial era “crescer a rede” (alto APY, airdrops) e mais tarde é “a rede cresce se for realmente útil” (ganhos de clientes). Esta transição é projetada para eliminar os free-riders e garantir a sustentabilidade.
Segurança e Mitigações de Ataques	Sybil: O registo dispendioso (stake de TAO) dissuade os sybils. Conluio: O consenso mediano resiste ao conluio até 50% do stake; o dTAO quebrou uma oligarquia de validadores ao capacitar a votação dos detentores de tokens. Desonestidade: Validadores que se desviam do consenso perdem parte da recompensa (incentiva a pontuação honesta). O ataque de 51% é possível se o stake for altamente concentrado – a pesquisa sugere adicionar limites de stake e penalizações por desempenho para mitigar isto. Ataques a modelos: Saídas de modelos más ou maliciosas são penalizadas com pontuações baixas. Nenhum ponto único de falha – a rede é descentralizada globalmente (existem mineradores de TAO em todo o mundo, pseudo-anónimos).	Sybil: Requer stake económico para participação; nós falsos sem stake/trabalho não ganham nada. Verificação: Pelo menos um verificador honesto é necessário – se assim for, qualquer resultado errado é apanhado e penalizado. Usa incentivos criptoeconómicos para que a trapaça não compense (o solver perde o depósito, o verificador ganha). Conluio: Seguro enquanto nem todas as partes conspirarem – um honesto quebra o esquema ao revelar a fraude. Confiança: Não depende da confiança em hardware ou empresas, apenas na teoria dos jogos económicos e na criptografia. Ataques: Difícil de censurar ou fazer DoS, pois as tarefas são distribuídas; um atacante precisaria de superar as licitações de nós honestos ou vencer consistentemente a prova de fraude (improvável sem controlo maioritário). No entanto, backdoors subtis em modelos podem escapar à deteção, o que é um desafio conhecido (mitigado por testes de utilizador e possivelmente futuras auditorias além da execução correta). A segurança geral é análoga a um rollup otimista para computação.	Sybil: Todos os atores devem fazer stake de CAI, elevando a fasquia para os sybils. Além disso, um sistema de reputação (staking + votação) significa que identidades sybil sem reputação não receberão tarefas. Mau comportamento de nós: Os coordenadores podem descartar mineradores com mau desempenho ou suspeitos; os stakers podem retirar o apoio. O protocolo pode penalizar o stake por fraude comprovada (a L1 tinha condições de penalização para o consenso; o mesmo poderia aplicar-se à fraude em tarefas). Conluio: Parcialmente baseado na confiança – depende da competição aberta e da supervisão da comunidade para evitar que o conluio domine. Como as tarefas e os pagamentos são públicos on-chain, o conluio flagrante pode ser identificado e punido socialmente ou através da governança. Proteção do utilizador: Os utilizadores podem mudar de fornecedor se um for censurado ou corrompido, garantindo que não há um ponto único de controlo. Envenenamento/conteúdo: Por design, os mineradores executam os modelos fornecidos como estão; se alterarem as saídas maliciosamente, perdem reputação e recompensas. O sistema aposta em atores racionais: como todos têm valor em stake e potencial de ganho futuro, são desincentivados de ataques que minariam a confiança na rede (reforçado pelas duras lições da sua experiência com a L1 sobre o alinhamento de incentivos com a utilidade).

Tabela: Comparação de funcionalidades de Bittensor, Gensyn e Cuckoo AI em arquitetura, foco, papéis, consenso, tokens, tokenização de ativos, governança, incentivos e segurança.

No mundo cada vez mais convergente da inteligência artificial e do blockchain, a demanda por confiança e transparência nunca foi tão alta. Como podemos ter certeza de que a saída de um modelo de IA é precisa e não foi adulterada? Como podemos executar cálculos complexos em vastos conjuntos de dados on‑chain sem comprometer segurança ou escalabilidade? A Lagrange Labs está enfrentando essas questões de frente com sua suíte de infraestrutura de conhecimento zero (ZK), visando construir um futuro de “IA que Você Pode Provar”. Este post oferece uma visão objetiva de sua missão, tecnologia e avanços recentes, culminando em seu último paper sobre zk‑SNARKs Dinâmicos.

1. A Equipe e Sua Missão​

A Lagrange Labs está construindo a infraestrutura fundamental para gerar provas criptográficas para qualquer inferência de IA ou aplicação on‑chain. Seu objetivo é tornar a computação verificável, trazendo uma nova camada de confiança ao mundo digital. Seu ecossistema está estruturado em três linhas de produto principais:

• ZK Prover Network: Uma rede descentralizada de mais de 85 nós de prova que fornece o poder computacional necessário para uma ampla gama de tarefas de prova, de IA e rollups a aplicações descentralizadas (dApps).
• DeepProve (zkML): Um sistema especializado para gerar provas ZK de inferências de redes neurais. A Lagrange afirma ser até 158 vezes mais rápido que soluções concorrentes, tornando a IA verificável uma realidade prática.
• ZK Coprocessor 1.0: O primeiro ZK Coprocessor baseado em SQL, permitindo que desenvolvedores executem consultas personalizadas em massivos conjuntos de dados on‑chain e recebam resultados verificavelmente precisos.

2. Um Roadmap para IA Verificável​

A Lagrange tem executado metodicamente um roadmap projetado para resolver os desafios da verificabilidade de IA passo a passo.

• Q3 2024: Lançamento do ZK Coprocessor 1.0: Esta versão introduziu circuitos recursivos hiper‑paralelos, que entregaram um aumento médio de velocidade de aproximadamente 2×. Projetos como Azuki e Gearbox já estão utilizando o coprocessor para suas necessidades de dados on‑chain.
• Q1 2025: DeepProve Revelado: A Lagrange anunciou o DeepProve, sua solução para Zero‑Knowledge Machine Learning (zkML). Ele suporta arquiteturas populares de redes neurais como Perceptrons de Múltiplas Camadas (MLPs) e Redes Neurais Convolucionais (CNNs). O sistema alcança acelerações de ordem de magnitude em todas as três etapas críticas: configuração única, geração de prova e verificação, com ganhos de até 158×.
• Q2 2025: Paper sobre zk‑SNARKs Dinâmicos (Último Marco): Este paper apresenta um algoritmo inovador de “atualização”. Em vez de gerar uma prova do zero sempre que os dados ou a computação subjacentes mudam, este método pode “patchar” uma prova antiga (π) em uma nova prova (π'). Essa atualização pode ser feita com complexidade de apenas O(√n log³n), uma melhoria drástica em relação à recomputação completa. Essa inovação é particularmente adequada para sistemas dinâmicos como modelos de IA que aprendem continuamente, lógica de jogos em tempo real e contratos inteligentes evolutivos.

3. Por Que os zk‑SNARKs Dinâmicos Importam​

A introdução de provas atualizáveis representa uma mudança fundamental no modelo de custos da tecnologia de conhecimento zero.

• Um Novo Paradigma de Custos: A indústria passa de um modelo de “recomputação total para cada prova” para “prova incremental baseada no tamanho da mudança”. Isso reduz drasticamente o custo computacional e financeiro para aplicações que sofrem atualizações frequentes e menores.
• Implicações para IA:
  • Fine‑Tuning Contínuo: Quando se faz fine‑tuning em menos de 1 % dos parâmetros de um modelo, o tempo de geração da prova cresce quase linearmente com o número de parâmetros alterados (Δ parâmetros), e não com o tamanho total do modelo.
  • Inferência em Streaming: Isso permite gerar provas simultaneamente ao processo de inferência. Reduz drasticamente a latência entre a decisão de uma IA e a sua liquidação e verificação on‑chain, desbloqueando casos de uso como serviços de IA on‑chain e provas comprimidas para rollups.
• Implicações para Aplicações On‑Chain:
  • zk‑SNARKs Dinâmicos oferecem otimizações massivas de gás e tempo para aplicações caracterizadas por mudanças frequentes e de pequeno porte. Isso inclui livros de ordens de exchanges descentralizadas (DEX), estados de jogos em evolução e atualizações de ledger que envolvem adições ou remoções frequentes.

4. Um Vislumbre da Pilha Tecnológica​

A poderosa infraestrutura da Lagrange é construída sobre uma pilha tecnológica sofisticada e integrada:

• Design de Circuitos: O sistema é flexível, suportando a incorporação de modelos ONNX (Open Neural Network Exchange), parsers SQL e operadores customizados diretamente em seus circuitos.
• Recursão & Paralelismo: A ZK Prover Network facilita provas recursivas distribuídas, enquanto o ZK Coprocessor aproveita o sharding de “micro‑circuitos” para executar tarefas em paralelo, maximizando a eficiência.
• Incentivos Econômicos: A Lagrange está planejando lançar um token nativo, LA, que será integrado a um sistema Double‑Auction‑for‑Recursive‑Auction (DARA). Isso criará um mercado robusto para leilões de computação de provadores, completo com incentivos e penalidades para garantir a integridade da rede.

5. Ecossistema e Adoção no Mundo Real​

A Lagrange não está construindo em um vácuo; sua tecnologia já está sendo integrada por um número crescente de projetos em diferentes setores:

• IA & ML: Projetos como 0G Labs e Story Protocol estão usando o DeepProve para verificar as saídas de seus modelos de IA, garantindo procedência e confiança.
• Rollups & Infraestrutura: Players chave como EigenLayer, Base e Arbitrum participam da ZK Prover Network como nós validadores ou parceiros de integração, contribuindo para sua segurança e poder computacional.
• Aplicações NFT & DeFi: Marcas como Azuki e protocolos DeFi como Gearbox utilizam o ZK Coprocessor para aprimorar a credibilidade de suas consultas de dados e mecanismos de distribuição de recompensas.

6. Desafios e o Caminho à Frente​

Apesar do progresso impressionante, a Lagrange Labs e o campo mais amplo de ZK enfrentam vários obstáculos:

• Gargalos de Hardware: Mesmo com uma rede distribuída, os SNARKs atualizáveis ainda exigem alta largura de banda e dependem de curvas criptográficas otimizadas para GPU para operar eficientemente.
• Falta de Padronização: O processo de mapear frameworks de IA como ONNX e PyTorch para circuitos ZK ainda carece de uma interface universal e padronizada, gerando atrito para desenvolvedores.
• Um Landscape Competitivo: A corrida para construir zkVMs e plataformas de zkCompute generalizadas está se intensificando. Competidores como Risc‑Zero e Succinct também estão avançando significativamente. O vencedor final pode ser quem primeiro comercializar uma toolchain amigável ao desenvolvedor e impulsionada pela comunidade.

7. Conclusão​

A Lagrange Labs está remodelando metodicamente a interseção entre IA e blockchain através da lente da verificabilidade. Sua abordagem oferece uma solução abrangente:

• DeepProve resolve o desafio da inferência confiável.
• O ZK Coprocessor resolve o problema dos dados confiáveis.
• zk‑SNARKs Dinâmicos incorporam a necessidade do mundo real de atualizações contínuas diretamente ao sistema de prova.

Se a Lagrange mantiver sua vantagem de desempenho, resolver o desafio crítico da padronização e continuar a expandir sua rede robusta, estará bem posicionada para se tornar um player fundamental no emergente setor de “IA + Infraestrutura ZK”.

O surgimento da IA generativa tem sido nada menos que explosivo. De arte digital impressionante a textos que parecem humanos, a IA está criando conteúdo em uma escala sem precedentes. Mas esse boom tem um lado sombrio: de onde a IA obtém seus dados de treinamento? Frequentemente, vem da vasta extensão da internet — de arte, música e textos criados por humanos que não recebem crédito nem compensação.

Surge então o Camp Network, um novo projeto de blockchain que pretende resolver esse problema fundamental. Não é apenas mais uma plataforma cripto; é uma “Camada de IP Autônoma” criada para dar aos criadores propriedade e controle sobre seu trabalho na era da IA. Vamos mergulhar no que torna o Camp Network um projeto a ser observado.

---

Qual é a Grande Ideia?​

Em sua essência, o Camp Network é um blockchain que funciona como um registro global e verificável de propriedade intelectual (IP). A missão é permitir que qualquer pessoa — de um artista independente a um usuário de redes sociais — registre seu conteúdo on‑chain. Isso cria um registro permanente e à prova de adulteração de propriedade e proveniência.

Por que isso importa? Quando um modelo de IA utiliza conteúdo registrado no Camp, os contratos inteligentes da rede podem aplicar automaticamente os termos de licenciamento. Isso significa que o criador original pode receber atribuição e até pagamentos de royalties instantaneamente. A visão do Camp é construir uma nova economia criadora onde a compensação não é um detalhe posterior; está incorporada diretamente ao protocolo.

---

Por Dentro da Tecnologia: A Pilha Tecnológica​

O Camp não é apenas um conceito; é sustentado por tecnologia séria projetada para alto desempenho e facilidade para desenvolvedores.

• Arquitetura Modular: O Camp é construído como um rollup soberano usando Celestia para disponibilidade de dados. Esse design permite que seja incrivelmente rápido (alvo de 50.000 transações por segundo) e barato, mantendo total compatibilidade com as ferramentas do Ethereum (EVM).
• Proof of Provenance (PoP): Este é o mecanismo de consenso exclusivo do Camp. Em vez de depender de mineração intensiva em energia, a segurança da rede está atrelada à verificação da origem do conteúdo. Cada transação reforça a proveniência da IP na rede, tornando a propriedade “exigível por design”.
• Estratégia Dual‑VM: Para maximizar o desempenho, o Camp está integrando a Solana Virtual Machine (SVM) ao lado da compatibilidade com EVM. Isso permite que desenvolvedores escolham o ambiente mais adequado para seu aplicativo, especialmente para casos de uso de alta taxa de transferência, como interações de IA em tempo real.
• Kit de Ferramentas para Criadores e IA: O Camp oferece duas estruturas principais:
  • Origin Framework: Um sistema amigável para criadores registrarem sua IP, tokenizá‑la (como NFT) e incorporar regras de licenciamento.
  • mAItrix Framework: Um kit para desenvolvedores criarem e implantarem agentes de IA que podem interagir com a IP on‑chain de forma segura e permissionada.

---

Pessoas, Parcerias e Progresso​

Uma ideia só é tão boa quanto sua execução, e o Camp parece estar executando bem.

A Equipe e o Financiamento​

O projeto é liderado por uma equipe com uma mistura potente de experiência proveniente da The Raine Group (media e acordos de IP), Goldman Sachs, Figma e CoinList. Essa combinação de finanças, produto tecnológico e engenharia cripto ajudou a garantir US$ 30 milhões em financiamento de VCs de destaque como 1kx, Blockchain Capital e Maven 11.

Um Ecossistema em Expansão​

O Camp tem sido agressivo na construção de parcerias. A mais significativa é uma participação estratégica no KOR Protocol, uma plataforma para tokenizar IP musical que trabalha com artistas de grande porte como Deadmau5 e franquias como Black Mirror. Essa única parceria fornece ao Camp uma biblioteca massiva de conteúdo de alto perfil, já com direitos claros. Outros colaboradores chave incluem:

• RewardedTV: Plataforma descentralizada de streaming de vídeo que usa o Camp para direitos de conteúdo on‑chain.
• Rarible: Marketplace de NFT integrado para negociação de ativos de IP.
• LayerZero: Protocolo cross‑chain que garante interoperabilidade com outras blockchains.

Roteiro e Comunidade​

Após campanhas de testnet incentivadas que atraíram dezenas de milhares de usuários (recompensando‑os com pontos que se convertem em tokens), o Camp mira um lançamento de mainnet no terceiro trimestre de 2025. Isso será acompanhado por um Evento de Geração de Token para seu token nativo, $CAMP, que será usado para taxas de gas, staking e governança. O projeto já cultivou uma comunidade apaixonada, pronta para construir e usar a plataforma desde o primeiro dia.

---

Como Ela se Compara?​

O Camp Network não está sozinho nesse espaço. Enfrenta concorrência forte de projetos como o Story Protocol, apoiado pela a16z, e o Soneium, ligado à Sony. Contudo, o Camp se diferencia em vários aspectos chave:

1. Abordagem Bottom‑Up: Enquanto concorrentes parecem mirar grandes detentores corporativos de IP, o Camp foca em capacitar criadores independentes e comunidades cripto por meio de incentivos tokenizados.
2. Solução Abrangente: Oferece um conjunto completo de ferramentas, desde um registro de IP até um framework de agentes de IA, posicionando‑se como um “one‑stop shop”.
3. Desempenho e Escalabilidade: Sua arquitetura modular e suporte dual‑VM são projetados para atender às demandas de alta taxa de transferência de IA e mídia.

Conclusão​

O Camp Network apresenta um caso convincente para se tornar a camada fundamental de propriedade intelectual na era Web3. Ao combinar tecnologia inovadora, equipe forte, parcerias estratégicas e uma ética centrada na comunidade, está construindo uma solução prática para um dos problemas mais urgentes criados pela IA generativa.

O verdadeiro teste virá com o lançamento da mainnet e a adoção no mundo real. Mas, com uma visão clara e execução sólida até agora, o Camp Network é, sem dúvida, um projeto chave a ser observado enquanto tenta construir um futuro mais equitativo para criadores digitais.

Por que o BlockEden.xyz se importa​

No mundo acelerado do Web3, velocidade é tudo. Entregar infraestrutura de RPC e staking de nível de produção exige que nossa equipe e nossa comunidade estejam constantemente na vanguarda da inovação. Isso significa estar por dentro de protocolos densos, artigos revolucionários de criptografia e discussões de governança que evoluem rapidamente. Quanto mais rápido nossa comunidade absorve e compreende novas ideias, mais rápido pode construir a próxima geração de aplicações descentralizadas. É aqui que BeFreed.ai entra.

O que é o BeFreed.ai​

BeFreed.ai é uma startup de São Francisco com uma missão simples, porém poderosa: tornar o aprendizado alegre e pessoal na era da IA. Eles criaram um companheiro inteligente de micro‑aprendizado projetado para se adaptar ao estilo de vida exigente de construtores e criadores.

Ingredientes principais:​

• Múltiplos formatos → um clique: BeFreed.ai pode pegar uma ampla variedade de conteúdo — de livros extensos e vídeos detalhados a documentos técnicos complexos — e transformá‑los instantaneamente em resumos rápidos, flashcards, notas aprofundadas e até áudio no estilo de podcast.
• Motor adaptativo: A plataforma foi projetada para aprender ao seu lado. Ela observa seu ritmo e interesses de aprendizado, trazendo as informações mais relevantes a seguir, em vez de forçá‑lo a seguir um currículo rígido e único para todos.
• Chat integrado e explicações “Por que isso?”: Tem uma dúvida? Basta perguntar. BeFreed.ai permite consultas instantâneas para esclarecer tópicos complexos. Também oferece explicações que conectam novos insights aos seus objetivos maiores, tornando o processo de aprendizado mais significativo.
• Comunidade de aprendizado de 43 mil pessoas: Aprender costuma ser uma atividade coletiva. BeFreed.ai fomenta uma comunidade vibrante de mais de 43 000 aprendizes que compartilham seu progresso, reagem a conteúdos perspicazes e destacam os principais aprendizados, mantendo alta motivação e impulso.

Por que isso importa para os construtores do BlockEden.xyz​

Para os construtores dedicados ao ecossistema BlockEden.xyz, o BeFreed.ai é mais do que uma ferramenta de aprendizado; é uma vantagem estratégica. Veja como ele pode afiar seu diferencial:

• Alavancagem de tempo: Transforme um whitepaper de 300 páginas em um resumo de áudio de 10 minutos para ouvir antes de uma votação crucial de governança.
• Retenção de contexto: Use flashcards e mapas mentais para solidificar seu entendimento dos detalhes de protocolos que você precisará ao escrever índices de smart contracts.
• Crescimento multidisciplinar: Expanda seu conjunto de habilidades sem sair do seu ambiente de desenvolvimento. Aprenda o básico de design thinking, entenda loops de crescimento ou obtenha dicas sobre concorrência em Go nos momentos de pausa.
• Vocabulário compartilhado: Crie playlists a nível de equipe para garantir que todos os colaboradores aprendam a partir da mesma fonte destilada e consistente de informação, promovendo melhor colaboração e alinhamento.

Usando o BeFreed nos fluxos de trabalho do BlockEden.xyz​

Integrar o BeFreed.ai ao seu processo de desenvolvimento existente é simples e traz benefícios imediatos:

1. Solte uma especificação: Cole a URL do PDF mais recente de tokenomics ou de uma chamada de desenvolvedor no YouTube no BeFreed para obter um resumo instantâneo e digerível.
2. Exporte flashcards: Revise conceitos chave durante execuções de CI. Essa forma de repetição é muito mais eficaz do que a fadiga mental causada por constantes trocas de contexto.
3. Link nos docs: Incorpore a URL de resumo do BeFreed ao lado de cada referência de API na sua documentação para ajudar novos membros da equipe a se atualizarem mais rápido.
4. Mantenha‑se atualizado: Configure digests semanais no BeFreed sobre L2s emergentes e coloque esse conhecimento em prática imediatamente ao prototipar com os serviços RPC multichain do BlockEden.xyz.

Comece agora​

BeFreed.ai já está disponível para iOS, Android e web. Incentivamos você a testá‑lo no próximo sprint de projeto do BlockEden.xyz e experimentar como ele pode melhorar sua velocidade de aprendizado e construção. Nossa equipe já está explorando integrações mais estreitas — imagine um futuro onde um webhook transforma automaticamente cada descrição de PR mesclado em um conjunto de estudo abrangente.

Introdução​

A IA e a Web3 estão a convergir de formas poderosas, com as interfaces gerais de IA a serem agora vistas como um tecido conjuntivo para a web descentralizada. Um conceito-chave que emerge desta convergência é o MCP, que tanto pode significar “Model Context Protocol” (conforme introduzido pela Anthropic) como ser vagamente descrito como um Metaverse Connection Protocol em discussões mais amplas. Em essência, o MCP é uma estrutura padronizada que permite que sistemas de IA interajam com ferramentas e redes externas de uma forma natural e segura – potencialmente “ligando” agentes de IA a todos os cantos do ecossistema Web3. Este relatório fornece uma análise abrangente de como as interfaces gerais de IA (como agentes de grandes modelos de linguagem e sistemas neuro-simbólicos) poderiam conectar tudo no mundo Web3 através do MCP, cobrindo o contexto histórico, a arquitetura técnica, o cenário da indústria, os riscos e o potencial futuro.

1. Contexto de Desenvolvimento​

1.1 A Evolução da Web3 e as Promessas Não Cumpridas​

O termo “Web3” foi cunhado por volta de 2014 para descrever uma web descentralizada alimentada por blockchain. A visão era ambiciosa: uma internet sem permissões centrada na propriedade do utilizador. Os entusiastas imaginaram substituir a infraestrutura centralizada da Web2 por alternativas baseadas em blockchain – por exemplo, o Ethereum Name Service (para DNS), Filecoin ou IPFS (para armazenamento) e DeFi para os trilhos financeiros. Em teoria, isto retiraria o controlo das plataformas das Big Tech e daria aos indivíduos auto-soberania sobre dados, identidade e ativos.

A realidade ficou aquém. Apesar de anos de desenvolvimento e hype, o impacto mainstream da Web3 permaneceu marginal. Os utilizadores médios da internet não migraram em massa para as redes sociais descentralizadas nem começaram a gerir chaves privadas. As principais razões incluíram uma má experiência do utilizador, transações lentas e caras, fraudes de alto perfil e incerteza regulatória. A “web da propriedade” descentralizada, em grande parte, “não se materializou” para além de uma comunidade de nicho. Em meados da década de 2020, até os proponentes de cripto admitiram que a Web3 não tinha proporcionado uma mudança de paradigma para o utilizador médio.

Entretanto, a IA estava a passar por uma revolução. À medida que o capital e o talento dos programadores se deslocavam de cripto para IA, avanços transformadores em deep learning e modelos de fundação (GPT-3, GPT-4, etc.) capturaram a imaginação do público. A IA Generativa demonstrou uma utilidade clara – produzindo conteúdo, código e decisões – de uma forma que as aplicações de cripto tinham tido dificuldade em fazer. De facto, o impacto dos grandes modelos de linguagem em apenas alguns anos superou drasticamente uma década de adoção de blockchain por parte dos utilizadores. Este contraste levou alguns a gracejar que “a Web3 foi desperdiçada em cripto” e que a verdadeira Web 3.0 está a emergir da onda da IA.

1.2 A Ascensão das Interfaces Gerais de IA​

Ao longo de décadas, as interfaces de utilizador evoluíram de páginas web estáticas (Web1.0) para aplicações interativas (Web2.0) – mas sempre dentro dos limites de clicar em botões e preencher formulários. Com a IA moderna, especialmente os grandes modelos de linguagem (LLMs), um novo paradigma de interface está aqui: a linguagem natural. Os utilizadores podem simplesmente expressar a sua intenção em linguagem simples e ter sistemas de IA a executar ações complexas em muitos domínios. Esta mudança é tão profunda que alguns sugerem redefinir a “Web 3.0” como a era dos agentes impulsionados por IA (“a Web Agêntica”) em vez da definição anterior centrada em blockchain.

No entanto, as primeiras experiências com agentes de IA autónomos expuseram um estrangulamento crítico. Estes agentes – por exemplo, protótipos como o AutoGPT – podiam gerar texto ou código, mas faltava-lhes uma forma robusta de comunicar com sistemas externos e entre si. Não havia “nenhuma linguagem comum nativa de IA” para a interoperabilidade. Cada integração com uma ferramenta ou fonte de dados era um hack personalizado, e a interação de IA para IA não tinha um protocolo padrão. Em termos práticos, um agente de IA podia ter uma grande capacidade de raciocínio, mas falhar na execução de tarefas que exigiam o uso de aplicações web ou serviços on-chain, simplesmente porque não sabia como falar com esses sistemas. Este desajuste – cérebros poderosos, E/S primitivas – era semelhante a ter um software super-inteligente preso atrás de uma GUI desajeitada.

1.3 Convergência e o Surgimento do MCP​

Em 2024, tornou-se evidente que, para a IA atingir o seu pleno potencial (e para a Web3 cumprir a sua promessa), era necessária uma convergência: os agentes de IA requerem acesso contínuo às capacidades da Web3 (aplicações descentralizadas, contratos, dados), e a Web3 precisa de mais inteligência e usabilidade, que a IA pode fornecer. É neste contexto que nasceu o MCP (Model Context Protocol). Introduzido pela Anthropic no final de 2024, o MCP é um padrão aberto para comunicação entre IA e ferramentas que parece natural para os LLMs. Ele fornece uma forma estruturada e detetável para os “hospedeiros de IA” (como o ChatGPT, Claude, etc.) encontrarem e usarem uma variedade de ferramentas e recursos externos através de servidores MCP. Por outras palavras, o MCP é uma camada de interface comum que permite que agentes de IA se liguem a serviços web, APIs e até funções de blockchain, sem codificar cada integração de forma personalizada.

Pense no MCP como “o USB-C das interfaces de IA”. Assim como o USB-C padronizou a forma como os dispositivos se conectam (para que não precise de cabos diferentes para cada dispositivo), o MCP padroniza a forma como os agentes de IA se conectam a ferramentas e dados. Em vez de codificar diferentes chamadas de API para cada serviço (Slack vs. Gmail vs. nó Ethereum), um programador pode implementar a especificação MCP uma vez, e qualquer IA compatível com MCP pode entender como usar esse serviço. Os principais players de IA rapidamente viram a importância: a Anthropic tornou o MCP open-source, e empresas como a OpenAI e a Google estão a construir suporte para ele nos seus modelos. Este impulso sugere que o MCP (ou “Meta Connectivity Protocols” semelhantes) poderia tornar-se a espinha dorsal que finalmente conecta a IA e a Web3 de uma forma escalável.

Notavelmente, alguns tecnólogos argumentam que esta conectividade centrada em IA é a verdadeira realização da Web3.0. Nas palavras de Simba Khadder, “o MCP visa padronizar uma API entre LLMs e aplicações,” semelhante a como as APIs REST permitiram a Web 2.0 – o que significa que a próxima era da Web3 pode ser definida por interfaces de agentes inteligentes em vez de apenas blockchains. Em vez da descentralização por si só, a convergência com a IA poderia tornar a descentralização útil, escondendo a complexidade por trás da linguagem natural e dos agentes autónomos. O restante deste relatório aprofunda como, técnica e praticamente, as interfaces gerais de IA (através de protocolos como o MCP) podem conectar tudo no mundo Web3.

2. Arquitetura Técnica: Interfaces de IA a Fazer a Ponte com as Tecnologias Web3​

Incorporar agentes de IA na stack Web3 requer integração em múltiplos níveis: redes de blockchain e contratos inteligentes, armazenamento descentralizado, sistemas de identidade e economias baseadas em tokens. As interfaces gerais de IA – desde grandes modelos de fundação a sistemas neuro-simbólicos híbridos – podem servir como um “adaptador universal” que conecta estes componentes. Abaixo, analisamos a arquitetura de tal integração:

Figura: Um diagrama conceptual da arquitetura do MCP, mostrando como os hospedeiros de IA (aplicações baseadas em LLM como Claude ou ChatGPT) usam um cliente MCP para se conectarem a vários servidores MCP. Cada servidor fornece uma ponte para alguma ferramenta ou serviço externo (por exemplo, Slack, Gmail, calendários ou dados locais), análogo a periféricos que se conectam através de um hub universal. Esta interface MCP padronizada permite que agentes de IA acedam a serviços remotos e recursos on-chain através de um protocolo comum.

2.1 Agentes de IA como Clientes Web3 (Integrando com Blockchains)​

No cerne da Web3 estão as blockchains e os contratos inteligentes – máquinas de estado descentralizadas que podem impor lógica de uma maneira sem confiança. Como pode uma interface de IA interagir com estes? Existem duas direções a considerar:

• IA a ler da blockchain: Um agente de IA pode precisar de dados on-chain (por exemplo, preços de tokens, saldo de ativos do utilizador, propostas de DAO) como contexto para as suas decisões. Tradicionalmente, a recuperação de dados de blockchain requer a interação com APIs RPC de nós ou bases de dados de subgrafos. Com uma estrutura como o MCP, uma IA pode consultar um servidor MCP padronizado de “dados de blockchain” para obter informações on-chain em tempo real. Por exemplo, um agente habilitado para MCP poderia pedir o volume de transações mais recente de um determinado token, ou o estado de um contrato inteligente, e o servidor MCP lidaria com os detalhes de baixo nível de conexão à blockchain e devolveria os dados num formato que a IA pode usar. Isto aumenta a interoperabilidade ao desacoplar a IA do formato de API de qualquer blockchain específica.

• IA a escrever na blockchain: De forma mais poderosa, os agentes de IA podem executar chamadas de contratos inteligentes ou transações através de integrações Web3. Uma IA poderia, por exemplo, executar autonomamente uma troca numa exchange descentralizada ou ajustar parâmetros num contrato inteligente se certas condições forem cumpridas. Isto é alcançado pela IA a invocar um servidor MCP que encapsula a funcionalidade de transação de blockchain. Um exemplo concreto é o servidor MCP da thirdweb para cadeias EVM, que permite que qualquer cliente de IA compatível com MCP interaja com Ethereum, Polygon, BSC, etc., abstraindo a mecânica específica da cadeia. Usando tal ferramenta, um agente de IA poderia desencadear ações on-chain “sem intervenção humana”, permitindo dApps autónomas – por exemplo, um cofre DeFi gerido por IA que se reequilibra ao assinar transações quando as condições de mercado mudam.

Nos bastidores, estas interações ainda dependem de carteiras, chaves e taxas de gás, mas a interface de IA pode receber acesso controlado a uma carteira (com sandboxes de segurança adequadas) para realizar as transações. Oráculos e pontes cross-chain também entram em jogo: Redes de oráculos como a Chainlink servem como uma ponte entre a IA e as blockchains, permitindo que os outputs da IA sejam alimentados on-chain de uma forma confiável. O Cross-Chain Interoperability Protocol (CCIP) da Chainlink, por exemplo, poderia permitir que um modelo de IA considerado fiável desencadeasse múltiplos contratos em diferentes cadeias simultaneamente em nome de um utilizador. Em resumo, as interfaces gerais de IA podem atuar como um novo tipo de cliente Web3 – um que pode tanto consumir dados de blockchain como produzir transações de blockchain através de protocolos padronizados.

2.2 Sinergia Neuro-Simbólica: Combinando o Raciocínio da IA com Contratos Inteligentes​

Um aspeto intrigante da integração IA-Web3 é o potencial para arquiteturas neuro-simbólicas que combinam a capacidade de aprendizagem da IA (redes neuronais) com a lógica rigorosa dos contratos inteligentes (regras simbólicas). Na prática, isto poderia significar que os agentes de IA lidam com a tomada de decisões não estruturadas e passam certas tarefas para contratos inteligentes para execução verificável. Por exemplo, uma IA pode analisar o sentimento do mercado (uma tarefa imprecisa), mas depois executar trocas através de um contrato inteligente determinístico que segue regras de risco pré-estabelecidas. A estrutura MCP e padrões relacionados tornam tais transferências viáveis, dando à IA uma interface comum para chamar funções de contrato ou para consultar as regras de uma DAO antes de agir.

Um exemplo concreto é a AI-DSL (Linguagem Específica de Domínio de IA) da SingularityNET, que visa padronizar a comunicação entre agentes de IA na sua rede descentralizada. Isto pode ser visto como um passo em direção à integração neuro-simbólica: uma linguagem formal (simbólica) para os agentes solicitarem serviços de IA ou dados uns dos outros. Da mesma forma, projetos como o AlphaCode da DeepMind ou outros poderiam eventualmente ser conectados para que os contratos inteligentes chamassem modelos de IA para a resolução de problemas on-chain. Embora executar grandes modelos de IA diretamente on-chain seja impraticável hoje, abordagens híbridas estão a surgir: por exemplo, certas blockchains permitem a verificação de computações de ML através de provas de conhecimento zero ou execução confiável, permitindo a verificação on-chain de resultados de IA off-chain. Em resumo, a arquitetura técnica prevê os sistemas de IA e os contratos inteligentes de blockchain como componentes complementares, orquestrados através de protocolos comuns: a IA lida com a

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.

A ETHDenver 2025, com a marca do “Ano dos Regenerados”, consolidou seu status como uma das maiores reuniões Web3 do mundo. Abrangendo a BUIDLWeek (23 a 26 de fevereiro), o Evento Principal (27 de fevereiro a 2 de março) e um Retiro na Montanha pós-conferência, o festival atraiu uma expectativa de mais de 25.000 participantes. Construtores, desenvolvedores, investidores e criativos de mais de 125 países convergiram em Denver para celebrar o ethos de descentralização e inovação do Ethereum. Fiel às suas raízes comunitárias, a ETHDenver permaneceu gratuita, financiada pela comunidade e repleta de conteúdo – de hackathons e workshops a painéis, eventos de pitch e festas. A tradição do evento dos “Regenerados” defendendo a descentralização estabeleceu um tom que enfatizou os bens públicos e a construção colaborativa, mesmo em meio a um cenário tecnológico competitivo. O resultado foi uma semana de atividade de construtores de alta energia e discussões voltadas para o futuro, oferecendo um panorama das tendências emergentes da Web3 e insights acionáveis para profissionais da indústria.

Tendências Emergentes da Web3 Destacadas pelos Palestrantes​

Nenhuma narrativa única dominou a ETHDenver 2025 – em vez disso, um amplo espectro de tendências da Web3 tomou o centro do palco. Ao contrário do ano passado (quando o restaking via EigenLayer roubou a cena), a agenda de 2025 foi uma mistura de tudo: desde redes de infraestrutura física descentralizada (DePIN) a agentes de IA, da conformidade regulatória à tokenização de ativos do mundo real (RWA), além de privacidade, interoperabilidade e muito mais. De fato, o fundador da ETHDenver, John Paller, abordou as preocupações sobre o conteúdo multi-chain, observando que “95%+ dos nossos patrocinadores e 90% do conteúdo é alinhado com ETH/EVM” – ainda assim, a presença de ecossistemas não-Ethereum ressaltou a interoperabilidade como um tema chave. Palestrantes importantes refletiram essas áreas de tendência: por exemplo, zk-rollup e escalabilidade de Camada 2 foi destacado por Alex Gluchowski (CEO da Matter Labs/zkSync), enquanto a inovação multi-chain veio de Adeniyi Abiodun da Mysten Labs (Sui) e Albert Chon da Injective.

A convergência de IA e Web3 emergiu como uma forte corrente subjacente. Inúmeras palestras e eventos paralelos focaram em agentes de IA descentralizados e cruzamentos “DeFi+IA”. Um AI Agent Day dedicado exibiu demos de IA on-chain, e um coletivo de 14 equipes (incluindo o kit de desenvolvedor da Coinbase e a unidade de IA da NEAR) anunciou a Open Agents Alliance (OAA) – uma iniciativa para fornecer acesso a IA livre e sem permissão, agrupando a infraestrutura Web3. Isso indica um interesse crescente em agentes autônomos e dApps impulsionados por IA como uma fronteira para os construtores. De mãos dadas com a IA, DePIN (infraestrutura física descentralizada) foi outro termo em voga: múltiplos painéis (por exemplo, Day of DePIN, DePIN Summit) exploraram projetos que conectam a blockchain com redes físicas (de telecomunicações a mobilidade).

A Cuckoo AI Network fez sucesso na ETHDenver 2025, apresentando seu inovador marketplace descentralizado de modelos de IA projetado para criadores e desenvolvedores. Com uma presença marcante tanto no hackathon quanto nos eventos paralelos liderados pela comunidade, a Cuckoo AI atraiu atenção significativa de desenvolvedores intrigados por sua capacidade de monetizar recursos de GPU/CPU e integrar facilmente APIs de IA on-chain. Durante seu workshop dedicado e sessão de networking, a Cuckoo AI destacou como a infraestrutura descentralizada poderia democratizar eficientemente o acesso a serviços avançados de IA. Isso se alinha diretamente com as tendências mais amplas do evento — particularmente a interseção da blockchain com IA, DePIN e financiamento de bens públicos. Para investidores e desenvolvedores na ETHDenver, a Cuckoo AI emergiu como um exemplo claro de como abordagens descentralizadas podem impulsionar a próxima geração de dApps e infraestrutura movidos a IA, posicionando-se como uma oportunidade de investimento atraente dentro do ecossistema Web3.

Privacidade, identidade e segurança permaneceram como prioridades. Palestrantes e workshops abordaram tópicos como provas de conhecimento zero (presença da zkSync), gerenciamento de identidade e credenciais verificáveis (uma trilha dedicada de Privacidade & Segurança estava no hackathon), e questões legais/regulatórias (uma cúpula jurídica on-chain fez parte das trilhas do festival). Outra discussão notável foi o futuro do levantamento de fundos e a descentralização do financiamento: um debate no Palco Principal entre Haseeb Qureshi da Dragonfly Capital e Matt O’Connor da Legion (uma plataforma “semelhante a ICO”) sobre ICOs vs. financiamento de VC cativou os participantes. Este debate destacou modelos emergentes, como vendas de tokens comunitários, desafiando as rotas tradicionais de VC – uma tendência importante para startups Web3 que navegam na captação de capital. A lição para os profissionais é clara: a Web3 em 2025 é multidisciplinar – abrangendo finanças, IA, ativos reais e cultura – e manter-se informado significa olhar além de qualquer ciclo de hype para o espectro completo da inovação.

Patrocinadores e Suas Áreas de Foco Estratégico​

A lista de patrocinadores da ETHDenver em 2025 parece um quem é quem das camadas-1, camadas-2 e projetos de infraestrutura Web3 – cada um aproveitando o evento para avançar em seus objetivos estratégicos. Protocolos cross-chain e multi-chain tiveram uma forte presença. Por exemplo, a Polkadot foi um dos principais patrocinadores com um robusto pool de recompensas de US$80 mil, incentivando construtores a criar DApps e appchains cross-chain. Da mesma forma, **BNB Chain, Flow, Hedera e Base (a L2 da Coinbase)** ofereceram cada um até US$ 50 mil para projetos que se integrassem com seus ecossistemas, sinalizando seu esforço para atrair desenvolvedores Ethereum. Até mesmo ecossistemas tradicionalmente separados como Solana e Internet Computer participaram com desafios patrocinados (por exemplo, Solana co-organizou um evento DePIN, e a Internet Computer ofereceu uma recompensa “Só é possível na ICP”). Essa presença entre ecossistemas gerou algum escrutínio da comunidade, mas a equipe da ETHDenver observou que a grande maioria do conteúdo permaneceu alinhada ao Ethereum. O efeito líquido foi que a interoperabilidade se tornou um tema central – os patrocinadores visavam posicionar suas plataformas como extensões complementares do universo Ethereum.

Soluções de escalabilidade e provedores de infraestrutura também estiveram em destaque. As principais L2s do Ethereum, como Optimism e Arbitrum, tinham grandes estandes e desafios patrocinados (as recompensas da Optimism chegavam a US$40 mil), reforçando seu foco em integrar desenvolvedores aos rollups. Novos participantes como **ZkSync e Zircuit** (um projeto que exibe uma abordagem de rollup L2) enfatizaram a tecnologia de conhecimento zero e até contribuíram com SDKs (a ZkSync promoveu seu Smart Sign-On SDK para login amigável, que as equipes do hackathon usaram com entusiasmo). **Restaking e infraestrutura de blockchain modular** foi outro interesse dos patrocinadores – a **EigenLayer** (pioneira em restaking) teve sua própria trilha de US$ 50 mil e até co-organizou um evento sobre “Restaking & DeFAI (IA Descentralizada)”, unindo seu modelo de segurança com tópicos de IA. Oráculos e middleware de interoperabilidade foram representados por nomes como Chainlink e Wormhole, cada um emitindo recompensas pelo uso de seus protocolos.

Notavelmente, aplicações de consumo e ferramentas Web3 tiveram apoio de patrocinadores para melhorar a experiência do usuário. A presença da Uniswap – completa com um dos maiores estandes – não foi apenas para exibição: a gigante de DeFi usou o evento para anunciar novos recursos de carteira, como rampas de saída de fiat integradas, alinhando-se com seu foco de patrocínio na usabilidade de DeFi. Plataformas focadas em identidade e comunidade como Galxe (Gravity) e Lens Protocol patrocinaram desafios em torno de credenciais e redes sociais on-chain. Até mesmo empresas de tecnologia tradicionais sinalizaram interesse: PayPal e Google Cloud organizaram um happy hour sobre stablecoins/pagamentos para discutir o futuro dos pagamentos em cripto. Essa mistura de patrocinadores mostra que os interesses estratégicos variaram da infraestrutura principal às aplicações para o usuário final – todos convergindo na ETHDenver para fornecer recursos (APIs, SDKs, subsídios) aos desenvolvedores. Para os profissionais da Web3, o forte patrocínio de camadas-1, camadas-2 e até mesmo de fintechs da Web2 destaca onde a indústria está investindo: interoperabilidade, escalabilidade, segurança e em tornar a cripto útil para a próxima onda de usuários.

Destaques do Hackathon: Projetos Inovadores e Vencedores​

No coração da ETHDenver está seu lendário #BUIDLathon – um hackathon que se tornou o maior hackfest de blockchain do mundo, com milhares de desenvolvedores. Em 2025, o hackathon ofereceu um prêmio recorde de mais de US$ 1.043.333 para estimular a inovação. Recompensas de mais de 60 patrocinadores visaram domínios chave da Web3, dividindo a competição em trilhas como: DeFi & IA, NFTs & Jogos, Infraestrutura & Escalabilidade, Privacidade & Segurança e DAOs & Bens Públicos. O próprio design dessas trilhas é revelador – por exemplo, parear DeFi com IA sugere o surgimento de aplicações financeiras impulsionadas por IA, enquanto uma trilha dedicada de Bens Públicos reafirma o foco da comunidade em finanças regenerativas e desenvolvimento de código aberto. Cada trilha foi apoiada por patrocinadores que ofereciam prêmios pelo melhor uso de sua tecnologia (por exemplo, Polkadot e Uniswap para DeFi, Chainlink para interoperabilidade, Optimism para soluções de escalabilidade). Os organizadores até implementaram a votação quadrática para o julgamento, permitindo que a comunidade ajudasse a destacar os melhores projetos, com os vencedores finais escolhidos por juízes especialistas.

O resultado foi uma enxurrada de projetos de ponta, muitos dos quais oferecem um vislumbre do futuro da Web3. Vencedores notáveis incluíram um jogo multiplayer on-chain chamado “0xCaliber”, um jogo de tiro em primeira pessoa que executa interações de blockchain em tempo real dentro de um jogo FPS clássico. O 0xCaliber impressionou os juízes ao demonstrar jogos verdadeiramente on-chain – os jogadores compram a entrada com cripto, “atiram” balas on-chain e usam truques cross-chain para coletar e sacar saques, tudo em tempo real. Esse tipo de projeto mostra a crescente maturidade dos jogos Web3 (integrando motores de jogo Unity com contratos inteligentes) e a criatividade na fusão de entretenimento com economia cripto. Outra categoria de hacks de destaque foram aqueles que uniram IA com Ethereum: equipes construíram plataformas de “agentes” que usam contratos inteligentes para coordenar serviços de IA, inspirados pelo anúncio da Open Agents Alliance. Por exemplo, um projeto do hackathon integrou auditores de contratos inteligentes impulsionados por IA (gerando automaticamente casos de teste de segurança para contratos) – alinhando-se com a tendência de IA descentralizada observada na conferência.

Projetos de infraestrutura e ferramentas também foram proeminentes. Algumas equipes abordaram a abstração de contas e a experiência do usuário, usando kits de ferramentas de patrocinadores como o Smart Sign-On da zkSync para criar fluxos de login sem carteira para dApps. Outros trabalharam em pontes cross-chain e integrações de Camada 2, refletindo o contínuo interesse dos desenvolvedores em interoperabilidade. Na trilha de Bens Públicos & DAO, alguns projetos abordaram o impacto social no mundo real, como um dApp para identidade descentralizada e ajuda a pessoas em situação de rua (aproveitando NFTs e fundos comunitários, uma ideia que lembra hacks de ReFi anteriores). Conceitos de finanças regenerativas (ReFi) – como financiar bens públicos por meio de mecanismos inovadores – continuaram a aparecer, ecoando o tema regenerativo da ETHDenver.

Enquanto os vencedores finais eram celebrados ao final do evento principal, o verdadeiro valor estava no pipeline de inovação: mais de 400 submissões de projetos foram recebidas, muitas das quais continuarão a existir além do evento. O hackathon da ETHDenver tem um histórico de semear futuras startups (de fato, alguns projetos passados do BUIDLathon se tornaram patrocinadores). Para investidores e tecnólogos, o hackathon forneceu uma janela para ideias de vanguarda – sinalizando que a próxima onda de startups Web3 pode surgir em áreas como jogos on-chain, dApps com infusão de IA, infraestrutura cross-chain e soluções voltadas para o impacto social. Com quase US$ 1 milhão em recompensas distribuídas aos desenvolvedores, os patrocinadores efetivamente colocaram seu dinheiro onde sua boca está para cultivar essas inovações.

Eventos de Networking e Interações com Investidores​

A ETHDenver não é apenas sobre escrever código – é igualmente sobre fazer conexões. Em 2025, o festival potencializou o networking com eventos formais e informais adaptados para startups, investidores e construtores de comunidades. Um evento de destaque foi o Bufficorn Ventures (BV) Startup Rodeo, uma vitrine de alta energia onde 20 startups selecionadas a dedo demonstraram seus projetos para investidores em um estilo de feira de ciências. Realizado em 1º de março no salão principal, o Startup Rodeo foi descrito mais como um “speed dating” do que um concurso de pitches: os fundadores ficavam em mesas para apresentar seus projetos individualmente enquanto todos os investidores presentes circulavam pela arena. Esse formato garantiu que até mesmo equipes em estágio inicial pudessem ter um tempo de qualidade com VCs, parceiros estratégicos ou outros. Muitas startups usaram isso como uma plataforma de lançamento para encontrar clientes e financiamento, aproveitando a presença concentrada de fundos Web3 na ETHDenver.

No último dia da conferência, o BV BuffiTank Pitchfest tomou o centro das atenções no palco principal – uma competição de pitches mais tradicional com 10 das startups em estágio inicial “mais inovadoras” da comunidade ETHDenver. Essas equipes (separadas dos vencedores do hackathon) apresentaram seus modelos de negócios a um painel de VCs de ponta e líderes da indústria, competindo por reconhecimento e potenciais ofertas de investimento. O Pitchfest ilustrou o papel da ETHDenver como um gerador de fluxo de negócios: era explicitamente voltado para equipes “já organizadas... em busca de investimento, clientes e exposição”, especialmente aquelas conectadas à comunidade SporkDAO. A recompensa para os vencedores não era um simples prêmio em dinheiro, mas sim a promessa de se juntar ao portfólio da Bufficorn Ventures ou a outras turmas de aceleradoras. Em essência, a ETHDenver criou seu próprio mini “Shark Tank” para a Web3, catalisando a atenção dos investidores para os melhores projetos da comunidade.

Além dessas vitrines oficiais, a semana foi repleta de encontros entre investidores e fundadores. De acordo com um guia curado pela Belong, eventos paralelos notáveis incluíram um “Meet the VCs” Happy Hour organizado pela CertiK Ventures em 27 de fevereiro, um StarkNet VC & Founders Lounge em 1º de março, e até mesmo eventos casuais como um evento de pitch com tema de golfe “Pitch & Putt”. Esses encontros proporcionaram ambientes descontraídos para os fundadores interagirem com capitalistas de risco, muitas vezes levando a reuniões de acompanhamento após a conferência. A presença de muitas firmas de VC emergentes também foi sentida nos painéis – por exemplo, uma sessão no EtherKnight Stage destacou novos fundos como Reflexive Capital, Reforge VC, Topology, Metalayer e Hash3 e quais tendências eles estão mais animados. As primeiras indicações sugerem que esses VCs estavam interessados em áreas como mídias sociais descentralizadas, IA e infraestrutura inovadora de Camada 1 (cada fundo criando um nicho para se diferenciar em um cenário de VC competitivo).

Para profissionais que buscam capitalizar o networking da ETHDenver: a principal lição é o valor dos eventos paralelos e encontros direcionados. Negócios e parcerias muitas vezes germinam durante um café ou coquetéis, em vez de no palco. A miríade de eventos para investidores da ETHDenver 2025 demonstra que a comunidade de financiamento da Web3 está ativamente em busca de talentos e ideias, mesmo em um mercado enxuto. Startups que vieram preparadas com demos polidas e uma proposta de valor clara (muitas vezes aproveitando o ímpeto do hackathon do evento) encontraram audiências receptivas. Enquanto isso, os investidores usaram essas interações para medir o pulso da comunidade de desenvolvedores – quais problemas os construtores mais brilhantes estão resolvendo este ano? Em resumo, a ETHDenver reforçou que o networking é tão importante quanto o BUIDLing: é um lugar onde um encontro casual pode levar a um investimento semente ou onde uma conversa perspicaz pode desencadear a próxima grande colaboração.

Tendências de Capital de Risco e Oportunidades de Investimento na Web3​

Uma narrativa sutil, mas importante, ao longo da ETHDenver 2025 foi a evolução do próprio cenário de capital de risco da Web3. Apesar dos altos e baixos do mercado de cripto em geral, os investidores na ETHDenver sinalizaram um forte apetite por projetos promissores da Web3. Repórteres da Blockworks no local notaram “o quanto de capital privado ainda está fluindo para a cripto, sem se abalar com os ventos contrários macroeconômicos”, com as avaliações em estágio inicial muitas vezes altíssimas para as ideias mais quentes. De fato, o grande número de VCs presentes – de fundos nativos de cripto a investidores de tecnologia tradicional se aventurando na Web3 – deixou claro que a ETHDenver continua sendo um centro de negociações.

Focos temáticos emergentes puderam ser discernidos a partir do que os VCs estavam discutindo e patrocinando. A prevalência de conteúdo IA x Cripto (trilhas de hackathon, painéis, etc.) não foi apenas uma tendência de desenvolvedores; reflete o interesse de risco no nexo “DeFi encontra IA”. Muitos investidores estão de olho em startups que utilizam aprendizado de máquina ou agentes autônomos na blockchain, como evidenciado por hackhouses e cúpulas de IA patrocinadas por capital de risco. Da mesma forma, o forte foco em DePIN e tokenização de ativos do mundo real (RWA) indica que os fundos veem oportunidades em projetos que conectam a blockchain a ativos da economia real e dispositivos físicos. O RWA Day dedicado (26 de fevereiro) – um evento B2B sobre o futuro dos ativos tokenizados – sugere que os caçadores de talentos de risco estão ativamente procurando nessa arena pela próxima Goldfinch ou Centrifuge (ou seja, plataformas que trazem finanças do mundo real para a on-chain).

Outra tendência observável foi uma crescente experimentação com modelos de financiamento. O debate mencionado sobre ICOs vs. VCs não foi apenas teatro de conferência; reflete um movimento real de risco em direção a um financiamento mais centrado na comunidade. Alguns VCs na ETHDenver indicaram abertura a modelos híbridos (por exemplo, lançamentos de tokens apoiados por capital de risco que envolvem a comunidade nas rodadas iniciais). Além disso, o financiamento de bens públicos e o investimento de impacto tiveram um lugar à mesa. Com o ethos de regeneração da ETHDenver, até mesmo os investidores discutiram como apoiar a infraestrutura de código aberto e os desenvolvedores a longo prazo, além de apenas perseguir o próximo boom de DeFi ou NFT. Painéis como “Financiando o Futuro: Modelos em Evolução para Startups Onchain” exploraram alternativas como subsídios, investimentos de tesouraria de DAO e financiamento quadrático para complementar o dinheiro de VC tradicional. Isso aponta para uma indústria amadurecendo na forma como os projetos são capitalizados – uma mistura de capital de risco, fundos de ecossistema e financiamento comunitário trabalhando em conjunto.

Do ponto de vista de oportunidade, profissionais e investidores da Web3 podem extrair alguns insights acionáveis da dinâmica de risco da ETHDenver: (1) A infraestrutura ainda é rei – muitos VCs expressaram que as “pás e picaretas” (escalabilidade L2, segurança, ferramentas de desenvolvimento) continuam sendo investimentos de alto valor como a espinha dorsal da indústria. (2) Novas verticais como a convergência IA/blockchain e DePIN são fronteiras de investimento emergentes – atualizar-se nessas áreas ou encontrar startups lá pode ser recompensador. (3) Projetos impulsionados pela comunidade e bens públicos podem ver financiamentos inovadores – investidores experientes estão descobrindo como apoiar esses projetos de forma sustentável (por exemplo, investindo em protocolos que permitem governança descentralizada ou propriedade compartilhada). No geral, a ETHDenver 2025 mostrou que, embora o cenário de risco da Web3 seja competitivo, ele está repleto de convicção: o capital está disponível para aqueles que estão construindo o futuro de DeFi, NFTs, jogos e além, e até mesmo ideias nascidas em mercado de baixa podem encontrar apoio se mirarem na tendência certa.

Recursos para Desenvolvedores, Kits de Ferramentas e Sistemas de Suporte​

A ETHDenver sempre foi focada nos construtores, e 2025 não foi exceção – ela funcionou como uma conferência de desenvolvedores de código aberto com uma infinidade de recursos e suporte para desenvolvedores Web3. Durante a BUIDLWeek, os participantes tiveram acesso a workshops ao vivo, bootcamps técnicos e mini-cúpulas abrangendo vários domínios. Por exemplo, os desenvolvedores podiam participar de uma Bleeding Edge Tech Summit para experimentar os protocolos mais recentes, ou participar de uma On-Chain Legal Summit para aprender sobre o desenvolvimento de contratos inteligentes em conformidade. Grandes patrocinadores e equipes de blockchain realizaram sessões práticas: a equipe da Polkadot organizou hack houses e workshops sobre como lançar parachains; a EigenLayer liderou um “bootcamp de restaking” para ensinar os desenvolvedores a aproveitar sua camada de segurança; Polygon e zkSync deram tutoriais sobre a construção de dApps escaláveis com tecnologia de conhecimento zero. Essas sessões forneceram um tempo valioso com engenheiros principais, permitindo que os desenvolvedores obtivessem ajuda com a integração e aprendessem novos kits de ferramentas em primeira mão.

Durante todo o evento principal, o local contou com um #BUIDLHub e Makerspace dedicados, onde os construtores podiam codificar em um ambiente colaborativo e ter acesso a mentores. Os organizadores da ETHDenver publicaram um Guia do BUIDLer detalhado e facilitaram um programa de mentoria no local (especialistas dos patrocinadores estavam disponíveis para desbloquear equipes em questões técnicas). Empresas de ferramentas para desenvolvedores também estiveram presentes em massa – desde Alchemy e Infura (para APIs de blockchain) até Hardhat e Foundry (para desenvolvimento de contratos inteligentes). Muitas revelaram novos lançamentos ou ferramentas beta no evento. Por exemplo, a equipe do MetaMask pré-visualizou uma grande atualização de carteira com abstração de gás e um SDK aprimorado para desenvolvedores de dApps, visando simplificar como os aplicativos cobrem as taxas de gás para os usuários. Vários projetos lançaram SDKs ou bibliotecas de código aberto: o “Agent Kit” da Coinbase para agentes de IA e o kit de ferramentas colaborativo da Open Agents Alliance foram introduzidos, e a Story.xyz promoveu seu Story SDK para licenciamento de propriedade intelectual on-chain durante seu próprio evento de hackathon.

Recompensas e suporte a hackers aumentaram ainda mais a experiência do desenvolvedor. Com mais de 180 recompensas oferecidas por 62 patrocinadores, os hackers tinham efetivamente um menu de desafios específicos para escolher, cada um vindo com documentação, horários de atendimento e, às vezes, sandboxes personalizadas. Por exemplo, a recompensa da Optimism desafiou os desenvolvedores a usar os mais recentes opcodes da Bedrock (com seus engenheiros de prontidão para ajudar), e o desafio da Uniswap forneceu acesso à sua nova API para integração de rampas de saída. Ferramentas para coordenação e aprendizado – como o aplicativo móvel oficial da ETHDenver e os canais do Discord – mantiveram os desenvolvedores informados sobre mudanças de horário, missões secundárias e até oportunidades de emprego através do quadro de empregos da ETHDenver.

Um recurso notável foi a ênfase em experimentos de financiamento quadrático e votação on-chain. A ETHDenver integrou um sistema de votação quadrática para o julgamento do hackathon, expondo muitos desenvolvedores ao conceito. Além disso, a presença da Gitcoin e de outros grupos de bens públicos significava que os desenvolvedores poderiam aprender sobre o financiamento de subsídios para seus projetos após o evento. Em suma, a ETHDenver 2025 equipou os desenvolvedores com ferramentas de ponta (SDKs, APIs), orientação especializada e suporte contínuo para continuar seus projetos. Para os profissionais da indústria, é um lembrete de que nutrir a comunidade de desenvolvedores – através da educação, ferramentas e financiamento – é fundamental. Muitos dos recursos destacados (como novos SDKs ou ambientes de desenvolvimento aprimorados) estão agora disponíveis publicamente, oferecendo a equipes de todos os lugares a chance de construir sobre os ombros do que foi compartilhado na ETHDenver.

Eventos Paralelos e Encontros Comunitários Enriquecendo a Experiência da ETHDenver​

O que realmente diferencia a ETHDenver é sua atmosfera de festival – dezenas de eventos paralelos, tanto oficiais quanto não oficiais, criaram uma rica tapeçaria de experiências em torno da conferência principal. Em 2025, além do National Western Complex, onde o conteúdo oficial acontecia, a cidade inteira fervilhava com encontros, festas, hackathons e reuniões comunitárias. Esses eventos paralelos, muitas vezes organizados por patrocinadores ou grupos locais de Web3, contribuíram significativamente para a experiência mais ampla da ETHDenver.

No front oficial, a própria programação da ETHDenver incluía mini-eventos temáticos: o local tinha zonas como uma Galeria de Arte NFT, um Arcade de Blockchain, uma Cúpula de DJ para Relaxar e até uma Zona Zen para descomprimir. Os organizadores também realizaram eventos noturnos, como festas de abertura e encerramento – por exemplo, a festa de abertura não oficial “Crack’d House” em 26 de fevereiro pela Story Protocol, que misturou uma performance artística com anúncios de prêmios do hackathon. Mas foram os eventos paralelos liderados pela comunidade que realmente proliferaram: de acordo com um guia de eventos, mais de 100 acontecimentos paralelos foram rastreados no calendário Luma da ETHDenver.

Alguns exemplos ilustram a diversidade desses encontros:

• Cúpulas Técnicas & Hacker Houses: A ElizaOS e a EigenLayer realizaram uma residência de 9 dias, a Vault AI Agent Hacker House, para entusiastas de IA+Web3. A equipe da StarkNet organizou uma hacker house de vários dias que culminou em uma noite de demonstração para projetos em seu ZK-rollup. Isso proporcionou ambientes focados para os desenvolvedores colaborarem em pilhas de tecnologia específicas fora do hackathon principal.
• Encontros de Networking & Festas: Todas as noites ofereciam uma série de opções. A Builder Nights Denver em 27 de fevereiro, patrocinada por MetaMask, Linea, EigenLayer, Wormhole e outros, reuniu inovadores para conversas casuais com comida e bebida. O 3VO’s Mischief Minded Club Takeover, apoiado pela Belong, foi uma festa de networking de alto nível para líderes de tokenização comunitária. Para aqueles que gostam de pura diversão, a BEMO Rave (com Berachain e outros) e a rAIve the Night (uma rave com tema de IA) mantiveram a multidão cripto dançando até tarde da noite – misturando música, arte e cultura cripto.
• Encontros de Interesses Específicos: Comunidades de nicho também encontraram seu espaço. O Meme Combat foi um evento puramente para entusiastas de memes celebrarem o papel dos memes na cripto. A House of Ink atendeu a artistas e colecionadores de NFT, transformando um local de arte imersiva (Meow Wolf Denver) em uma vitrine para arte digital. A SheFi Summit em 26 de fevereiro reuniu mulheres na Web3 para palestras e networking, apoiada por grupos como World of Women e Celo – destacando um compromisso com a diversidade e inclusão.
• Encontros de Investidores & Criadores de Conteúdo: Já mencionamos os eventos de VC; adicionalmente, um Encontro de KOL (Líderes de Opinião Chave) em 28 de fevereiro permitiu que influenciadores de cripto e criadores de conteúdo discutissem estratégias de engajamento, mostrando a interseção das mídias sociais e das comunidades cripto.

Crucialmente, esses eventos paralelos não eram apenas entretenimento – eles muitas vezes serviam como incubadoras de ideias e relacionamentos por si só. Por exemplo, a Tokenized Capital Summit 2025 aprofundou-se no futuro dos mercados de capitais on-chain, provavelmente gerando colaborações entre empreendedores de fintech e desenvolvedores de blockchain presentes. A On-Chain Gaming Hacker House proporcionou um espaço para desenvolvedores de jogos compartilharem as melhores práticas, o que pode levar à polinização cruzada entre projetos de jogos em blockchain.

Para profissionais que participam de grandes conferências, o modelo da ETHDenver ressalta que o valor é encontrado tanto fora do palco principal quanto nele. A amplitude da programação não oficial permitiu que os participantes personalizassem sua experiência – se o objetivo de alguém era conhecer investidores, aprender uma nova habilidade, encontrar um cofundador ou apenas relaxar e construir camaradagem, havia um evento para isso. Muitos veteranos aconselham os novatos: “Não assista apenas às palestras – vá aos encontros e diga oi.” Em um espaço tão impulsionado pela comunidade como a Web3, essas conexões humanas muitas vezes se traduzem em colaborações de DAO, acordos de investimento ou, no mínimo, amizades duradouras que atravessam continentes. A vibrante cena paralela da ETHDenver 2025 amplificou a conferência principal, transformando uma semana em Denver em um festival multidimensional de inovação.

Principais Lições e Insights Acionáveis​

A ETHDenver 2025 demonstrou uma indústria Web3 em pleno florescimento de inovação e colaboração. Para os profissionais do setor, várias lições claras e itens de ação emergem desta análise aprofundada:

• Diversificação de Tendências: O evento deixou evidente que a Web3 não é mais monolítica. Domínios emergentes como integração de IA, DePIN e tokenização de RWA são tão proeminentes quanto DeFi e NFTs. Insight acionável: Mantenha-se informado e adaptável. Os líderes devem alocar P&D ou investimento nessas verticais em ascensão (por exemplo, explorando como a IA poderia aprimorar seu dApp, ou como ativos do mundo real poderiam ser integrados em plataformas DeFi) para surfar na próxima onda de crescimento.
• Cross-Chain é o Futuro: Com grandes protocolos não-Ethereum participando ativamente, as barreiras entre os ecossistemas estão diminuindo. Interoperabilidade e experiências de usuário multi-chain ganharam enorme atenção, desde o MetaMask adicionando suporte a Bitcoin/Solana até cadeias baseadas em Polkadot e Cosmos cortejando desenvolvedores Ethereum. Insight acionável: Projete para um mundo multi-chain. Os projetos devem considerar integrações ou pontes que acessem liquidez e usuários em outras cadeias, e os profissionais podem buscar parcerias entre comunidades em vez de permanecerem isolados.
• Comunidade & Bens Públicos Importam: O tema “Ano dos Regenerados” não foi apenas retórica – ele permeou o conteúdo através de discussões sobre financiamento de bens públicos, votação quadrática para hacks e eventos como a SheFi Summit. Desenvolvimento ético e sustentável e propriedade comunitária são valores-chave no ethos do Ethereum. Insight acionável: Incorpore princípios regenerativos. Seja apoiando iniciativas de código aberto, usando mecanismos de lançamento justo ou alinhando modelos de negócios com o crescimento da comunidade, as empresas Web3 podem ganhar boa vontade e longevidade ao não serem puramente extrativistas.
• Sentimento do Investidor – Cauteloso, mas Ousado: Apesar dos rumores de mercado de baixa, a ETHDenver mostrou que os VCs estão ativamente procurando e dispostos a apostar alto nos próximos capítulos da Web3. No entanto, eles também estão repensando como investir (por exemplo, de forma mais estratégica, talvez com mais supervisão sobre o ajuste produto-mercado e abertura para financiamento comunitário). Insight acionável: Se você é uma startup, foque nos fundamentos e na narrativa. Os projetos que se destacaram tinham casos de uso claros e, muitas vezes, protótipos funcionais (alguns construídos em um fim de semana!). Se você é um investidor, a conferência afirmou que a infraestrutura (L2s, segurança, ferramentas de desenvolvimento) continua sendo de alta prioridade, mas diferenciar-se por meio de teses em IA, jogos ou social pode posicionar um fundo na vanguarda.
• A Experiência do Desenvolvedor está Melhorando: A ETHDenver destacou muitos novos kits de ferramentas, SDKs e frameworks que diminuem a barreira para o desenvolvimento Web3 – desde ferramentas de abstração de contas até bibliotecas de IA on-chain. Insight acionável: Aproveite esses recursos. As equipes devem experimentar as ferramentas de desenvolvimento mais recentes reveladas (por exemplo, experimentar o zkSync Smart SSO para logins mais fáceis, ou usar os recursos da Open Agents Alliance para um projeto de IA) para acelerar seu desenvolvimento e se manter à frente da concorrência. Além disso, as empresas devem continuar a se envolver com hackathons e fóruns de desenvolvedores abertos como uma forma de encontrar talentos e ideias; o sucesso da ETHDenver em transformar hackers em fundadores é a prova desse modelo.
• O Poder dos Eventos Paralelos: Por fim, a explosão de eventos paralelos ensinou uma lição importante sobre networking – as oportunidades muitas vezes aparecem em ambientes casuais. Um encontro casual em um happy hour ou um interesse compartilhado em um pequeno encontro pode criar conexões que definem carreiras. Insight acionável: Para aqueles que participam de conferências da indústria, planeje além da agenda oficial. Identifique eventos paralelos alinhados com seus objetivos (seja conhecer investidores, aprender uma habilidade de nicho ou recrutar talentos) e seja proativo no engajamento. Como visto em Denver, aqueles que se imergiram totalmente no ecossistema da semana saíram não apenas com conhecimento, mas com novos parceiros, contratações e amigos.

Em conclusão, a ETHDenver 2025 foi um microcosmo do ímpeto da indústria Web3 – uma mistura de discurso tecnológico de ponta, energia comunitária apaixonada, movimentos de investimento estratégico e uma cultura que mistura inovação séria com diversão. Os profissionais devem ver as tendências e insights do evento como um roteiro para onde a Web3 está se dirigindo. O próximo passo acionável é pegar esses aprendizados – seja um novo foco em IA, uma conexão feita com uma equipe de L2 ou a inspiração de um projeto de hackathon – e traduzi-los em estratégia. No espírito do lema favorito da ETHDenver, é hora de #BUIDL com base nesses insights e ajudar a moldar o futuro descentralizado que tantos em Denver se reuniram para imaginar.