Mercados Descentralizados de Inferência de IA: Bittensor, Gensyn e Cuckoo AI

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.