59 postagens marcadas com "Blockchain"

1. Definição e origem do MCP no contexto Web3​

O ** Model Context Protocol (MCP) ** é um padrão aberto que conecta assistentes de IA (como modelos de idiomas grandes) a fontes, ferramentas e ambientes externos de dados. Freqüentemente descrito como uma "porta USB-C para a IA" devido à sua natureza plug-and-play universal, o MCP foi desenvolvido por antropia e introduzido pela primeira vez no final de novembro de 2024. Emergiu como uma solução para quebrar os modelos de IA de isolamento, com preenchimento com segurança com os bloqueios com segurança.

Originalmente, um projeto lateral experimental na Antrópico, o MCP ganhou tração rapidamente. Em meados de 2024, as implementações de referência de código aberto apareceram e, no início de 2025, tornou-se o padrão ** de fato para a integração da IA ​​Agentic **, com os principais laboratórios de IA (Openai, Google DeepMind, Meta AI) adotando-o nativamente. Essa rápida captação foi especialmente notável na comunidade ** Web3 **. Os desenvolvedores de blockchain consideraram o MCP como uma maneira de infundir recursos de IA em aplicações descentralizadas, levando a uma proliferação de conectores MCP construídos na comunidade para dados e serviços na cadeia. De fato, alguns analistas argumentam que o MCP pode cumprir a visão original do Web3 de uma Internet descentralizada e centrada no usuário de uma maneira mais prática do que apenas a blockchain, usando interfaces de linguagem natural para capacitar os usuários.

Em resumo, o MCP não é ** uma blockchain ou token **, mas um protocolo aberto nascido no mundo da IA ​​que foi rapidamente adotado no ecossistema Web3 como uma ponte entre agentes de IA e fontes de dados descentralizadas. Antrópica de origem aberta O padrão (com uma especificação inicial do GitHub e SDKs) e cultivou uma comunidade aberta em torno dela. Essa abordagem orientada à comunidade preparou o terreno para a integração do MCP no Web3, onde agora é visto como infraestrutura fundamental para aplicativos descentralizados com AI-I-iabled.

2. Arquitetura técnica e protocolos principais​

MCP opera em uma arquitetura leve ** cliente -server ** com três funções principais:

• ** Host MCP: ** O aplicativo ou agente da AI, que orquestra solicitações. Pode ser um chatbot (Claude, ChatGPT) ou um aplicativo movido a IA que precisa de dados externos. O host inicia interações, solicitando ferramentas ou informações via MCP.
• ** Cliente MCP: ** Um componente do conector que o host usa para se comunicar com os servidores. O cliente mantém a conexão, gerencia mensagens de solicitação/resposta e pode lidar com vários servidores em paralelo. Por exemplo, uma ferramenta de desenvolvedor como o Cursor ou o VS Code do modo do Code pode atuar como um cliente MCP que preenche o ambiente local de IA com vários servidores MCP.
• ** Servidor MCP: ** Um serviço que expõe alguns dados ou funcionalidades contextuais à IA. Os servidores fornecem ** ferramentas **, ** Recursos ** ou ** Slots ** que a IA pode usar. Na prática, um servidor MCP pode interagir com um banco de dados, um aplicativo em nuvem ou um nó blockchain e apresentar um conjunto padronizado de operações na IA. Cada par cliente-servidor se comunica em seu próprio canal, para que um agente de IA possa tocar em vários servidores simultaneamente para necessidades diferentes.

** Primitivos principais: ** MCP define um conjunto de tipos de mensagens e primitivos padrão que estruturam a interação da ferramenta da AI. Os três primitivos fundamentais são:

• ** Ferramentas: ** Operações ou funções discretas A IA pode invocar em um servidor. Por exemplo, uma ferramenta "SearchDocuments" ou uma ferramenta "eth_call". As ferramentas encapsulam ações como a consulta de uma API, a execução de um cálculo ou chamando uma função de contrato inteligente. O cliente MCP pode solicitar uma lista de ferramentas disponíveis de um servidor e ligue para as necessárias.
• ** RECURSOS: ** De extremidades de dados que a IA pode ler (ou às vezes gravar para) através do servidor. Estes podem ser arquivos, entradas de banco de dados, estado de blockchain (blocos, transações) ou quaisquer dados contextuais. A IA pode listar os recursos e recuperar seu conteúdo por meio de mensagens MCP padrão (por exemplo, Listresources e` ReadResource ', solicitações).
• ** Prompts: ** Modelos de prompt estruturados ou instruções que os servidores podem fornecer para orientar o raciocínio da IA. Por exemplo, um servidor pode fornecer um modelo de formatação ou um prompt de consulta predefinido. A IA pode solicitar uma lista de modelos de prompt e usá -los para manter a consistência na forma como interage com esse servidor.

Sob o capô, as comunicações do MCP são tipicamente baseadas em JSON e seguem um padrão de resposta-resposta semelhante ao RPC (chamada de procedimento remoto). A especificação do protocolo define mensagens como inicializerequest, listTools, calltool, listresources etc., que garantem que qualquer cliente compatível com MCP possa conversar com qualquer servidor MCP de uma maneira uniforme. Essa padronização é o que permite que um agente de IA * descubra * o que pode fazer: Ao se conectar a um novo servidor, ele pode perguntar "Quais ferramentas e dados você oferece?" E então decida dinamicamente como usá -los.

** Modelo de segurança e execução: ** MCP foi projetado com interações seguras e controladas em mente. O modelo de IA em si não executa o código arbitrário; Ele envia intenções de alto nível (através do cliente) para o servidor, que executa a operação real (por exemplo, buscando dados ou chamando uma API) e retorna resultados. Essa separação significa ações sensíveis (como transações de blockchain ou gravações de banco de dados) podem ser sandboxed ou exigir aprovação explícita do usuário. Por exemplo, existem mensagens como ping (para manter as conexões vivas) e até mesmo um` createMessagerequest ', que permite que um servidor MCP solicite à IA do cliente que gere uma sub-resposta, normalmente bloqueada pela confirmação do usuário. Recursos como autenticação, controle de acesso e registro de auditoria estão sendo desenvolvidos ativamente para garantir que o MCP possa ser usado com segurança em ambientes corporativos e descentralizados (mais sobre isso na seção de roteiro).

Em resumo, a arquitetura do MCP depende de um protocolo de mensagem ** padronizado ** (com chamadas de estilo JSON-RPC) que conecta agentes de IA (hosts) a uma matriz flexível de servidores que fornecem ferramentas, dados e ações. Essa arquitetura aberta é ** modelo-agnóstico ** e ** plataforma-agnóstico **-Qualquer agente de IA pode usar o MCP para conversar com qualquer recurso, e qualquer desenvolvedor pode criar um novo servidor MCP para uma fonte de dados sem precisar modificar o código principal da IA. Essa extensibilidade plug-and-play é o que torna o MCP poderoso no Web3: pode-se criar servidores para nós de blockchain, contratos inteligentes, carteiras ou oráculos e que os agentes de IA integrem perfeitamente esses recursos ao lado das APIs do Web2.

3. Use casos e aplicações do MCP no Web3​

O MCP desbloqueia uma ampla gama de casos de uso **, permitindo que aplicativos acionados por IA acessem dados de blockchain e executem ações na cadeia ou fora da cadeia de uma maneira segura e de alto nível. Aqui estão alguns aplicativos e problemas importantes que isso ajuda a resolver no domínio Web3:

-** Análise e consulta de dados na cadeia: ** Os agentes da IA ​​podem consultar o estado de blockchain ao vivo em tempo real para fornecer informações ou acionar ações. Por exemplo, um servidor MCP conectado a um nó Ethereum permite que um IA busque saldos de conta, leia o armazenamento de contratos inteligentes, rastreia transações ou recupere registros de eventos sob demanda. Isso transforma um chatbot ou assistente de codificação em um explorador de blockchain. Os desenvolvedores podem fazer perguntas de assistente de IA como "Qual é a liquidez atual no Pool X Uniswap X?" ou "simular o custo do gás da transação Ethereum" e a IA usará as ferramentas MCP para chamar um nó RPC e obter a resposta da cadeia ao vivo. Isso é muito mais poderoso do que depender dos dados de treinamento da IA ​​ou dos instantâneos estáticos.

• ** Gerenciamento automatizado de portfólio DEFI: ** Combinando ferramentas de acesso e ação de dados, os agentes da IA ​​podem gerenciar portfólios de criptografia ou posições defi. Por exemplo, um ** "AI Vault Optimizer" ** poderia monitorar as posições de um usuário nas fazendas de rendimento e sugerir ou executar automaticamente estratégias de reequilíbrio com base em condições de mercado em tempo real. Da mesma forma, uma IA poderia atuar como um gerente de portfólio ** **, ajustando as alocações entre protocolos quando o risco ou as taxas mudam. O MCP fornece a interface padrão para a IA ler métricas na cadeia (preços, liquidez, índices colaterais) e, em seguida, invocar ferramentas para executar transações (como mover fundos ou trocar ativos), se permitido. Isso pode ajudar os usuários a maximizar o rendimento ou gerenciar riscos 24 horas por dia, 7 dias por semana, de uma maneira que seria difícil de fazer manualmente.
• ** Agentes de usuários movidos a IA para transações: ** Pense em um assistente pessoal de IA que possa lidar com interações blockchain para um usuário. Com o MCP, esse agente pode se integrar às carteiras e DAPPs para executar tarefas por meio de comandos de linguagem natural. Por exemplo, um usuário poderia dizer: "Ai, enviar 0,5 ETH da minha carteira para Alice" ou "Apoie meus tokens no pool de maior tostura". A IA, através do MCP, usaria um servidor de carteira ** ** (segurando a chave privada do usuário) para criar e assinar a transação e um servidor MCP de blockchain para transmiti -lo. Esse cenário transforma interações complexas de linha de comando ou metamask em uma experiência de conversação. É crucial que os servidores Secure Wallet MCP sejam usados ​​aqui, aplicando permissões e confirmações, mas o resultado final está simplificando as transações na cadeia por meio da assistência da IA. -** Assistentes de desenvolvedores e depuração de contratos inteligentes: ** Os desenvolvedores da Web3 podem aproveitar os assistentes de AI baseados em MCP com muito conhecimento de infraestrutura de blockchain. Por exemplo, ** Servidores MCP do ChainStack para EVM e Solana ** Dê uma visibilidade profunda da codificação da AI no ambiente de blockchain do desenvolvedor. Um engenheiro de contrato inteligente usando um assistente de IA (no código VS ou um IDE) pode fazer com que a IA busque o estado atual de um contrato em um Testnet, execute uma simulação de uma transação ou verifique os logs - tudo via MCP chamadas para nós de blockchain local. Isso ajuda a depurar e testar contratos. A IA não está mais codificando "cegamente"; Na verdade, pode verificar como o código se comporta na cadeia em tempo real. Este caso de uso resolve um importante ponto de dor, permitindo que a IA ingerisse continuamente os documentos atualizados (através de um servidor MCP de documentação) e consulte a blockchain diretamente, reduzindo alucinações e tornando as sugestões muito mais precisas.
• ** Coordenação cruzada de protocolo: ** Como o MCP é uma interface unificada, um único agente de IA pode coordenar em vários protocolos e serviços simultaneamente- algo extremamente poderoso na paisagem interconectada do Web3. Imagine um agente comercial autônomo ** que monitora várias plataformas defi de arbitragem. Através do MCP, um agente poderia fazer interface simultaneamente com os mercados de empréstimos da AAVE, uma ponte de cadeia transversal de camada e um serviço de análise MEV (Miner Extrable Value), em toda a interface coerente. A IA poderia, em um "processo de pensamento", reunir dados de liquidez do Ethereum (por meio de um servidor MCP em um nó Ethereum), obter informações sobre preços ou dados do Oracle (através de outro servidor) e até chamar operações de ponte ou troca. Anteriormente, essa coordenação de várias plataformas exigiria bots complexos com código personalizado, mas o MCP fornece uma maneira generalizável de uma IA navegar em todo o ecossistema Web3 como se fosse um big data/pool de recursos. Isso pode permitir casos de uso avançado, como otimização de rendimento de cadeia cruzada ou proteção de liquidação automatizada, onde uma IA move ativos ou garantias entre as cadeias proativamente.
• ** BOTS ADVISORES E APOIO AI: ** Outra categoria são os consultores voltados para o usuário em aplicativos de criptografia. Por exemplo, um ** defi ajuda chatbot ** integrado a uma plataforma como o Uniswap ou o composto poderia usar o MCP para obter informações em tempo real para o usuário. Se um usuário perguntar: "Qual é a melhor maneira de proteger minha posição?", A IA pode buscar taxas atuais, dados de volatilidade e detalhes do portfólio do usuário via MCP e, em seguida, dê uma resposta com reconhecimento de contexto. As plataformas estão explorando ** Assistentes movidos a IA ** embutidos em carteiras ou DAPPs que podem orientar os usuários por meio de transações complexas, explicar riscos e até executar sequências de etapas com aprovação. Esses agentes de IA estão efetivamente sentados no topo de vários serviços da Web3 (Dexes, Pools de Empréstimos, Protocolos de Seguros), usando o MCP para consultar e comandá -los conforme necessário, simplificando assim a experiência do usuário.
• ** Além do Web3- Fluxos de trabalho com vários domínios: ** Embora nosso foco seja Web3, vale a pena observar os casos de uso do MCP se estendem a qualquer domínio em que a IA precise de dados externos. Ele já está sendo usado para conectar IA a coisas como Google Drive, Slack, Github, Figma e muito mais. Na prática, um único agente de IA pode atravessar o Web3 e o Web2: por exemplo, analisar um modelo financeiro do Excel do Google Drive, sugerindo negociações na cadeia com base nessa análise, tudo em um fluxo de trabalho. A flexibilidade do MCP permite a automação de domínios cruzados (por exemplo, "Programe minha reunião se meu voto da DAO for aprovado e envie um e-mail para os resultados") que combina ações blockchain com as ferramentas do dia a dia.

** Problemas resolvidos: ** O problema abrangente do MCP é a ** falta de uma interface unificada para a IA interagir com dados e serviços ao vivo **. Antes do MCP, se você quisesse uma IA para usar um novo serviço, precisava codificar manualmente um plug-in ou integração para a API desse serviço específico, geralmente de maneira ad-hoc. No Web3, isso era especialmente pesado - todo blockchain ou protocolo possui suas próprias interfaces, e nenhuma IA poderia esperar apoiar todos eles. O MCP resolve isso padronizando como a IA descreve o que deseja (o idioma natural mapeado para as chamadas de ferramentas) e como os serviços descrevem o que eles oferecem. Isso reduz drasticamente o trabalho de integração. Por exemplo, em vez de escrever um plug -in personalizado para cada protocolo DEFI, um desenvolvedor pode escrever um servidor MCP para esse protocolo (anotando essencialmente suas funções no idioma natural). Qualquer IA habilitada para MCP (modelos Claude, ChatGPT ou de código aberto) pode utilizá-lo imediatamente. Isso torna a AI ** extensível ** de maneira plug-and-play, como adicionar um novo dispositivo por meio de uma porta universal é mais fácil do que instalar uma nova placa de interface.

Em suma, o MCP no Web3 permite que ** agentes da IA ​​se tornem cidadãos de primeira classe do mundo da blockchain **-consultando, analisando e até transacionando em sistemas descentralizados, todos através de canais seguros e padronizados. Isso abre a porta para Dapps mais autônomos, agentes de usuários mais inteligentes e integração perfeita da inteligência na cadeia e fora da cadeia.

4. Modelo de tokenômica e governança​

Ao contrário dos protocolos típicos do Web3, ** MCP não possui um token ou criptomoeda nativo. Assim, não há tokenômica interna-não é um modelo de emissão de token, staking ou taxa inerente ao uso do MCP. Aplicativos e servidores de IA se comunicam via MCP sem qualquer criptomoeda envolvida; Por exemplo, uma IA chamando uma blockchain via MCP pode pagar taxas de gás pela transação de blockchain, mas o próprio MCP não adiciona taxa de token extra. Esse design reflete a origem do MCP na comunidade de IA: foi introduzido como um padrão técnico para melhorar as interações da AI-Tool, não como um projeto tokenizado.

** Governança ** do MCP é realizado de maneira aberta e orientada pela comunidade. Depois de liberar o MCP como padrão aberto, o antropia sinalizou um compromisso com o desenvolvimento colaborativo. Um amplo comitê de direção ** e grupos de trabalho se formaram para pastorear a evolução do protocolo. Notavelmente, em meados de 2025, grandes partes interessadas como a Microsoft e o Github ingressaram no comitê de direção do MCP ao lado do Antrópico. Isso foi anunciado na Microsoft Build 2025, indicando uma coalizão de players do setor que orientam as decisões de roteiro e padrões do MCP. O comitê e os mantenedores trabalham por meio de um processo de governança aberta: as propostas para alterar ou estender o MCP são normalmente discutidas publicamente (por exemplo, por meio de questões do GitHub e "Sep" - proposta de aprimoramento padrão - diretrizes). Há também um Grupo de Trabalho de Registro MCP ** (com mantenedores de empresas como Block, PulseMCP, Github e Antrópico) que exemplifica a governança multipartidária. No início de 2025, os colaboradores de pelo menos 9 organizações diferentes colaboraram para criar um registro unificado de servidor MCP para descoberta, demonstrando como o desenvolvimento é descentralizado entre os membros da comunidade, em vez de controlado por uma entidade.

Como não há token, ** Incentivos de governança ** confiam nos interesses comuns das partes interessadas (empresas de IA, fornecedores de nuvem, desenvolvedores de blockchain etc.) para melhorar o protocolo para todos. Isso é um tanto análogo à forma como os padrões W3C ou IETF são governados, mas com um processo mais rápido do Github Centric. Por exemplo, a Microsoft e a Antrópica trabalharam juntos para projetar uma especificação de autorização aprimorada para MCP (integrando coisas como OAuth e Single Sign-On), e o GitHub colaborou no Serviço Oficial de Registro MCP para listar servidores disponíveis. Esses aprimoramentos foram contribuídos de volta para a especificação do MCP para benefício de todos.

Vale a pena notar que, embora o próprio MCP não esteja em Alguns pesquisadores e líderes de pensamento no Web3 prevêem o surgimento de ** “MCP Networks” **-Redes essencialmente descentralizadas de servidores e agentes MCP que usam mecanismos de blockchain para descoberta, confiança e recompensas. Nesse cenário, pode-se imaginar um token sendo usado para recompensar aqueles que executam servidores MCP de alta qualidade (semelhantes aos mineiros ou operadores de nó são incentivados). Recursos como ** Classificações de reputação, computação verificável e descoberta de nós ** podem ser facilitados por contratos inteligentes ou uma blockchain, com um comportamento honesto ao token. Isso ainda é conceitual, mas projetos como o NAMDA do MIT (discutidos mais adiante) estão experimentando mecanismos de incentivo baseados em token para redes de agentes de IA usando MCP. Se essas idéias amadurecem, o MCP poderá se cruzar com a tokenômica na cadeia mais diretamente, mas a partir de 2025 ** o padrão MCP do núcleo permanece sem token **.

Em resumo, o "modelo de governança" do MCP é o de um padrão de tecnologia aberta: mantida colaborativamente por uma comunidade e um comitê diretor de especialistas, sem token de governança na cadeia. As decisões são guiadas por mérito técnico e amplo consenso, em vez de votação ponderada por moedas. Isso distingue o MCP de muitos protocolos Web3 - pretende cumprir os ideais da Web3 (descentralização, interoperabilidade, empoderamento do usuário) por meio de software e padrões abertos, ** não através de uma blockchain ou token proprietário **. Nas palavras de uma análise, *“A promessa do Web3 ... pode finalmente ser realizada não através de blockchain e criptomoeda, mas através da linguagem natural e dos agentes da IA” *, posicionando o MCP como um facilitador chave dessa visão. Dito isto, à medida que as redes do MCP crescem, podemos ver modelos híbridos em que os mecanismos de governança ou incentivo baseados em blockchain aumentam o ecossistema-um espaço para observar atentamente.

5. Comunidade e ecossistema​

O ecossistema MCP cresceu explosivamente em pouco tempo, abrangendo desenvolvedores de IA, colaboradores de código aberto, engenheiros da Web3 e grandes empresas de tecnologia. É um esforço vibrante da comunidade, com os principais colaboradores e parcerias **, incluindo:

• ** Antrópico: ** Como criador, o antropal semeou o ecossistema, de origem aberta da especificação MCP e vários servidores de referência (para o Google Drive, Slack, Github, etc.). O Antrópico continua a liderar o desenvolvimento (por exemplo, funcionários como Theodora Chu servem como gerentes de produto do MCP, e a equipe da Anthropic contribui fortemente para especificar atualizações e suporte da comunidade). A abertura da Anthrópica atraiu outros para construir o MCP, em vez de vê-lo como uma ferramenta única.

• ** Os primeiros adotantes (bloco, Apollo, Zed, Replit, Codeium, SourceGraph): ** Nos primeiros meses após a liberação, uma onda de adotantes iniciais implementou o MCP em seus produtos. ** Bloco (anteriormente Square) ** MCP integrado para explorar os sistemas Agentic AI em Fintech-o CTO do Block elogiou o MCP como uma ponte aberta que conecta a IA a aplicativos do mundo real. ** Apollo ** (provavelmente Apollo GraphQL) também integrou o MCP para permitir o acesso da IA ​​aos dados internos. Empresas de ferramentas de desenvolvedor como ** Zed (editor de código) **, ** Replit (nuvem IDE) **, ** Codeium (AI Coding Assistant) ** e ** SourceGraph (pesquisa de código) ** Cada um trabalhou para adicionar suporte ao MCP. Por exemplo, o SourceGraph usa o MCP para que um assistente de codificação de IA possa recuperar o código relevante de um repositório em resposta a uma pergunta, e os agentes do IDE da Replit podem atrair o contexto específico do projeto. Esses primeiros adotantes deram credibilidade e visibilidade do MCP.

• ** Big Tech endosso - OpenAI, Microsoft, Google: ** Em uma virada notável, empresas que, de outra forma, são concorrentes alinhados no MCP. ** O CEO da Openai, Sam Altman, anunciou publicamente ** em março de 2025, que o OpenAI adicionaria o suporte ao MCP em seus produtos (incluindo o aplicativo de desktop da ChatGPT), dizendo*"As pessoas adoram o MCP e estamos entusiasmados em adicionar suporte em nossos produtos"*. Isso significava que os plug -ins de agente do OpenAI e ChatGPT falavam MCP, garantindo a interoperabilidade. Apenas algumas semanas depois, ** CEO do Google Deepmind, Demis Hassabis **, revelou que os próximos modelos e ferramentas de Gemini do Google suportariam o MCP, chamando -o de um bom protocolo e um padrão aberto para a "Era Agentic AI". ** Microsoft ** Não apenas se juntou ao comitê de direção, mas fez uma parceria com a Anthropic para construir um C# SDK oficial para o MCP servir a comunidade de desenvolvedores corporativos. A Unidade Github da Microsoft integrou o MCP no modo ** Github COOPILOT (modo de "copilot laboratórios/agentes" do vs Código) **, permitindo que o Copilot use servidores MCP para coisas como pesquisas de repositório e execução de casos de teste. Além disso, a Microsoft anunciou que o Windows 11 exporia determinadas funções do sistema operacional (como o acesso ao sistema de arquivos) como servidores MCP para que os agentes da IA ​​possam interagir com o sistema operacional com segurança. A colaboração entre o OpenAi, Microsoft, Google e Antrópica-todos reunidos em torno do MCP-é extraordinária e ressalta o ethos da Comunidade-Over-Competition deste padrão.

• ** Comunidade de desenvolvedores da Web3: ** Vários desenvolvedores e startups blockchain adotaram o MCP. Vários servidores MCP orientados pela comunidade ** foram criados para servir casos de uso de blockchain:

• A equipe da ** Alchemy ** (um provedor de infraestrutura de blockchain líder) construiu um servidor ** de alquimia MCP ** que oferece ferramentas de análise de blockchain sob demanda via MCP. Provavelmente, isso permite que uma IA obtenha estatísticas de blockchain (como transações históricas, atividade de endereçamento) através das APIs da Alquimia usando a linguagem natural.

  • Os colaboradores desenvolveram um servidor MCP ** Bitcoin & Lightning Network ** para interagir com os nós do Bitcoin e a rede de pagamento de raios, permitindo que os agentes da IA ​​leiam dados do Bitcoin Block ou até criem faturas de raios por meio de ferramentas padrão.
  • O grupo de mídia e educação criptográfico ** Bankless ** criou um servidor ** Onchain MCP ** focado nas interações financeiras do Web3, possivelmente fornecendo uma interface aos protocolos de defi (enviando transações, consultando posições de defi, etc.) para assistentes de IA.
  • Projetos como ** rollup.codes ** (uma base de conhecimento para a camada Ethereum 2s) fizeram um servidor ** MCP para informações do ecossistema de rollup **, para que uma IA possa responder a perguntas técnicas sobre rollups, consultando este servidor.
  • ** ChainStack **, um provedor de nós blockchain, lançou um conjunto de servidores MCP (cobertos anteriormente) para documentação, dados da cadeia EVM e Solana, comercializando explicitamente como "colocando sua IA em esteróides de blockchain" para construtores Web3.

Além disso, as comunidades focadas no Web3 surgiram em torno do MCP. Por exemplo, ** PulseMCP ** e ** Goose ** são iniciativas comunitárias referenciadas como ajudando a construir o registro do MCP. Também estamos vendo polinização cruzada com estruturas de agentes de IA: os adaptadores integrados da comunidade de Langchain, para que todos os servidores MCP possam ser usados ​​como ferramentas em agentes movidos a Langchain, e as plataformas de IA de código aberto, como abraçar o TGI FACE (Inferência de Geração de Texto), estão explorando a compatibilidade do MCP. O resultado é um rico ecossistema, onde novos servidores MCP são anunciados quase diariamente, servindo de tudo, desde bancos de dados a dispositivos IoT.

• ** Escala de adoção: ** A tração pode ser quantificada até certo ponto. Até fevereiro de 2025 - apenas três meses após o lançamento - mais de 1.000 servidores/conectores MCP ** haviam sido construídos pela comunidade. Esse número só cresceu, indicando milhares de integrações entre os setores. Mike Krieger (diretor de produtos do Antrópico) observou na primavera de 2025 que o MCP havia se tornado um "padrão aberto prosperando com milhares de integrações e crescimento" **. O registro oficial do MCP (lançado em pré -visualização em setembro de 2025) está catalogando servidores disponíveis ao público, facilitando a descoberta de ferramentas; A API aberta do registro permite que qualquer pessoa pesquise, digamos, "Ethereum" ou "noção" e encontre conectores MCP relevantes. Isso reduz a barreira para novos participantes e ainda mais o crescimento de combustíveis.

• ** Parcerias: ** Tocamos em muitas parcerias implícitas (antropia com a Microsoft, etc.). Para destacar mais alguns:

• ** Anthropic & Slack **: Anthropic fez parceria com o Slack para integrar Claude aos dados do Slack via MCP (o Slack possui um servidor MCP oficial, permitindo que a IA recupere mensagens Slack ou Post Alerts).

  • ** Provedores de nuvem **: Amazon (AWS) e Google Cloud trabalharam com antropia para hospedar Claude, e é provável que eles suportem o MCP nesses ambientes (por exemplo, a AWS Bedrock pode permitir que os conectores MCP para dados corporativos). Embora não estejam explicitamente nas citações, essas parcerias em nuvem são importantes para a adoção da empresa.
  • ** Colaborações acadêmicas **: O projeto de pesquisa do MIT e IBM Namda (discutido a seguir) representa uma parceria entre a academia e a indústria para impulsionar os limites do MCP em ambientes descentralizados.
  • ** Github & vs Code **: Parceria para aprimorar a experiência do desenvolvedor - por exemplo, a equipe do VS Code contribuiu ativamente para o MCP (um dos mantenedores do registro é da equipe do Code).
  • ** Inúmeras startups **: Muitas startups de IA (startups de agentes, startups de automação de fluxo de trabalho) estão construindo no MCP em vez de reinventar a roda. Isso inclui as startups emergentes da AI da Web3 que procuram oferecer "IA como DAO" ou agentes econômicos autônomos.

No geral, a comunidade ** MCP está diversificada e em rápida expansão **. Inclui empresas principais de tecnologia (para padrões e ferramentas básicas), especialistas em Web3 (trazendo conhecimentos de blockchain e casos de uso) e desenvolvedores independentes (que frequentemente contribuem com conectores para seus aplicativos ou protocolos favoritos). O ethos é colaborativo. Por exemplo, as preocupações de segurança sobre os servidores MCP de terceiros levaram a discussões e contribuições da comunidade das melhores práticas (por exemplo, contribuintes do StackLok que trabalham em ferramentas de segurança para servidores MCP). A capacidade da comunidade de iterar rapidamente (o MCP viu várias atualizações de especificações em meses, adicionando recursos como respostas de streaming e melhor autenticação) é um testemunho de amplo envolvimento.

No ecossistema Web3 especificamente, o MCP promoveu um mini-ecossistema de projetos ** "AI + Web3" **. Não é apenas um protocolo para usar; Está catalisando novas idéias, como DAOs orientados a IA, governança na cadeia auxiliada pela análise da IA ​​e automação de domínio cruzado (como vincular eventos na cadeia a ações fora da cadeia através da IA). A presença das principais figuras da Web3 - por exemplo, ** Zhivko Todorov, da Limechain , declarando“MCP representa a inevitável integração de IA e blockchain” - mostra que os veteranos da blockchain estão defendendo ativamente. Parcerias entre as empresas de IA e blockchain (como as entre antropia e bloco, ou o Azure Cloud da Microsoft, tornando o MCP fácil de implantar ao lado de seus serviços de blockchain) sugerem um futuro onde ** agentes da IA ​​e contratos inteligentes trabalham de mãos dadas **.

Pode -se dizer que o MCP acendeu a primeira convergência genuína da comunidade de desenvolvedores de IA com a comunidade de desenvolvedores da Web3. Hackathons e Meetups agora apresentam faixas do MCP. Como uma medida concreta da adoção do ecossistema: em meados de 2025, ** OpenAI, Google e antropia-representando coletivamente a maioria dos modelos avançados de IA-todos suportam MCP ** e, por outro lado, as empresas de bloqueio líder*Blockchain. Esse efeito de rede em dois lados é um bom presságio para o MCP se tornar um padrão duradouro.

6. Roteiro e marcos de desenvolvimento​

O desenvolvimento do MCP tem sido acelerado. Aqui, descrevemos os principais marcos principais até agora e o roteiro à frente ** como obtido de fontes oficiais e atualizações da comunidade:

• ** Tarde de 2024- Lançamento inicial: ** ON ** 25 de novembro de 2024 **, Antrópico anunciou oficialmente o MCP e de origem aberta das especificações e SDKs iniciais. Juntamente com a especificação, eles lançaram um punhado de implementações do MCP Server para ferramentas comuns (Google Drive, Slack, Github etc.) e adicionaram suporte no assistente de Claude AI (Claude Desktop App) para se conectar aos servidores MCP locais. Isso marcou o lançamento 1.0 do MCP. As integrações antecipadas de prova de conceito na Anthropic mostraram como Claude poderia usar o MCP para ler arquivos ou consultar um banco de dados SQL na linguagem natural, validando o conceito.
• ** Q1 2025 - Adoção rápida e iteração: ** Nos primeiros meses de 2025, o MCP viu ** adoção generalizada da indústria **. Em ** março de 2025 **, o OpenAI e outros provedores de IA anunciaram suporte (conforme descrito acima). Esse período também viu ** Evolução de especificações **: MCP atualizado antrópico para incluir ** recursos de streaming ** (permitindo que grandes resultados ou fluxos de dados contínuos sejam enviados de forma incremental). Esta atualização foi observada em abril de 2025 com o C# SDK News, indicando que o MCP agora suportava recursos como respostas em tempo real ou integração de feeds em tempo real. A comunidade também criou implementações de referência ** em vários idiomas (Python, JavaScript, etc.) além do SDK do Anthrópico, garantindo suporte à poliglota.
• ** Q2 2025 - Tooling e governança do ecossistema: ** Em ** maio de 2025 **, com a Microsoft e o Github se unindo ao esforço, houve um esforço para formalizar a governança e aumentar a segurança. Na Build 2025, a Microsoft revelou planos para ** Integração do Windows 11 MCP ** e detalhou uma colaboração para melhorar os fluxos de autorização ** no MCP **. Na mesma época, a idéia de um registro ** MCP ** foi apresentada aos servidores Index Disponível (o brainstorming inicial começou em março de 2025, de acordo com o blog de registro). O processo ** "Standards Track" ** (SEP - propostas de aprimoramento padrão) foi estabelecido no GitHub, semelhante ao EIPS do Ethereum ou ao Python's Peps, para gerenciar contribuições de uma maneira ordenada. As chamadas da comunidade e os grupos de trabalho (para segurança, registro, SDKs) começaram a se reunir.
• ** Mid 2025- Expansão de recursos: ** Até meados de 2025, o roteiro priorizou várias melhorias importantes:
  • ** Suporte de tarefas assíncronas e de longa duração: ** Planeja permitir que o MCP lide com operações longas sem bloquear a conexão. Por exemplo, se uma IA acionar um trabalho em nuvem que leva minutos, o protocolo MCP suportaria respostas assíncronas ou reconexão para obter resultados. -** Autenticação e segurança fina: ** Desenvolvendo ** Autorização de grãos finos ** Mecanismos para ações sensíveis. Isso inclui os fluxos OAuth possivelmente integrando, as chaves da API e o Enterprise SSO nos servidores MCP para que o acesso da IA ​​possa ser gerenciado com segurança. Em meados de 2025, os guias e as melhores práticas para a segurança do MCP estavam em andamento, dados os riscos de segurança de permitir que a IA invocasse ferramentas poderosas. O objetivo é que, por exemplo, se uma IA for acessar o banco de dados privado de um usuário via MCP, ele deve seguir um fluxo de autorização seguro (com consentimento do usuário) em vez de apenas um terminal aberto.
• ** Teste de validação e conformidade: ** Reconhecendo a necessidade de confiabilidade, a comunidade priorizou o edifício ** Suites de teste de conformidade ** e ** implementações de referência **. Ao garantir que todos os clientes/servidores do MCP aderem às especificações (através de testes automatizados), eles visavam impedir a fragmentação. Um servidor de referência (provavelmente um exemplo com as melhores práticas para implantação remota e auth) estava no roteiro, assim como um aplicativo de cliente de referência demonstrando o uso completo do MCP com uma IA.
  • ** Suporte de multimodalidade: ** Estendendo o MCP além do texto para suportar modalidades como ** imagem, áudio, dados de vídeo ** no contexto. Por exemplo, uma IA pode solicitar uma imagem de um servidor MCP (digamos, um ativo de design ou um diagrama) ou produzir uma imagem. A discussão da especificação incluiu a adição de suporte para * transmissão e mensagens fundidas * para lidar com grande conteúdo multimídia interativamente. O trabalho inicial no “MCP Streaming” já estava em andamento (para apoiar coisas como feeds de áudio ao vivo ou dados de sensores contínuos para a IA).
  • ** Registro e descoberta central: ** O plano de implementar um serviço central ** MCP ** para a descoberta do servidor foi executado em meados de 2025. Em ** setembro de 2025 **, o registro oficial do MCP foi lançado em pré -visualização. Este registro fornece uma única fonte de verdade ** para servidores MCP disponíveis ao público, permitindo que os clientes encontrem servidores por nome, categoria ou recursos. É essencialmente como uma loja de aplicativos (mas aberta) para ferramentas de IA. O design permite registros públicos (um índice global) e os privados (específicos da empresa), todos interoperáveis ​​por meio de uma API compartilhada. O registro também introduziu um mecanismo de moderação ** para sinalizar ou excluir servidores maliciosos, com um modelo de moderação da comunidade para manter a qualidade.
• ** Tarde de 2025 e além - em direção a redes MCP descentralizadas: ** Embora ainda não sejam itens de roteiro "oficiais", a trajetória aponta para mais ** descentralização e sinergia Web3 **:
• Os pesquisadores estão explorando ativamente como adicionar ** Descoberta descentralizada, reputação e camadas de incentivo ** ao MCP. O conceito de uma rede ** MCP ** (ou "Marketplace of MCP Endpoints") está sendo incubada. Isso pode envolver registros baseados em contratos inteligentes (portanto, nenhum ponto de falha único para listagens de servidores), sistemas de reputação em que servidores/clientes têm identidades na cadeia e participam de bom comportamento e, possivelmente, ** recompensas de token por executar nós MCP confiáveis ​​**.
  • ** Projeto Namda ** no MIT, iniciado em 2024, é uma etapa concreta nessa direção. Até 2025, a NAMDA havia construído uma estrutura de agente distribuída protótipo nas fundações do MCP, incluindo recursos como descoberta dinâmica de nós, balanceamento de carga entre agrupamentos de agentes e um registro descentralizado usando técnicas de blockchain. Eles até têm incentivos experimentais baseados em token e rastreamento de proveniência para colaborações multi-agentes. Os marcos da NAMDA mostram que é viável ter uma rede de agentes MCP atravessando muitas máquinas com coordenação sem confiança. Se os conceitos da NAMDA forem adotados, podemos ver o MCP evoluir para incorporar algumas dessas idéias (possivelmente por meio de extensões opcionais ou protocolos separados em camadas no topo).
  • ** Enterprise Hardening: ** No lado da empresa, no final de 2025, esperamos que o MCP seja integrado às principais ofertas de software corporativo (a inclusão da Microsoft no Windows e o Azure é um exemplo). O roteiro inclui recursos para empresas, como ** Integração SSO para servidores MCP ** e controles de acesso robustos. A disponibilidade geral do registro e dos kits de ferramentas do MCP para implantar o MCP em escala (por exemplo, dentro de uma rede corporativa) é provável até o final de 2025.

Para recapitular alguns teclas ** Marcos de desenvolvimento até agora ** (formato da linha do tempo para maior clareza):

• ** NOV 2024: ** MCP 1.0 Lançado (antropic).
• ** De dezembro de 2024 - janeiro de 2025: ** Comunidade constrói a primeira onda de servidores MCP; Antrópicos libera o Claude Desktop com suporte ao MCP; Pilotos de pequena escala por bloco, Apollo, etc.
• ** Fev 2025: ** mais de 1000 conectores da comunidade MCP alcançados; Workshops antropia de hosts (por exemplo, em uma cúpula de IA, Educação para dirigir).
• ** Mar 2025: ** OpenAI anuncia suporte (ChatGPT Agents SDK).
• ** abril de 2025: ** Google Deepmind anuncia suporte (Gemini apoiará o MCP); A Microsoft libera visualização do C# SDK.
• ** Maio de 2025: ** Comitê de direção expandido (Microsoft/Github); Construa 2025 demos (integração do Windows MCP).
• ** Jun 2025: ** O ChainStack lança servidores Web3 MCP (EVM/Solana) para uso público.
• ** JUL 2025: ** Atualizações da versão do MCP Spec (streaming, melhorias de autenticação); Roteiro oficial publicado no site do MCP.
• ** Set 2025: ** Registro MCP (visualização) lançado; Provavelmente o MCP atinge a disponibilidade geral em mais produtos (Claude para o trabalho, etc.).
• ** final de 2025 (projetado): ** Registry v1.0 Live; guias de melhor prática de segurança liberados; Possivelmente experimentos iniciais com descoberta descentralizada (resultados da NAMDA).

A visão ** adiante ** é que o MCP se torna tão onipresente e invisível quanto HTTP ou JSON - uma camada comum que muitos aplicativos usam sob o capô. Para o Web3, o roteiro sugere uma fusão mais profunda: onde os agentes de IA não apenas usarão o Web3 (blockchains) como fontes ou sumidouros de informação, mas a infraestrutura do Web3 em si pode começar a incorporar agentes de IA (via MCP) como parte de sua operação (por exemplo, um DAO pode executar um MCP-Compatível AI para gerenciar determinados. A ênfase do roteiro em coisas como verificabilidade e autenticação sugere que as interações MCP minimizadas na linha ** ** podem ser uma realidade-imagine os resultados da IA ​​que acompanham provas criptográficas ou um registro na cadeia de quais ferramentas uma IA invocou para propósitos de auditoria. Essas possibilidades embaçam a linha entre as redes de IA e blockchain, e o MCP está no coração dessa convergência.

Em conclusão, o desenvolvimento do MCP é altamente dinâmico. Ele atingiu grandes marcos iniciais (ampla adoção e padronização dentro de um ano de lançamento) e continua a evoluir rapidamente com um roteiro claro enfatizando ** Segurança, Escalabilidade e Descoberta **. Os marcos alcançados e planejados garantem que o MCP permaneça robusto à medida que escala: abordar desafios como tarefas de longa duração, permissões seguras e a pura descoberta de milhares de ferramentas. Esse momento a termo indica que o MCP não é uma especificação estática, mas um padrão em crescimento, provavelmente incorporar mais recursos com sabor Web3 (governança descentralizada de servidores, alinhamento de incentivo) à medida que essas necessidades surgem. A comunidade está pronta para adaptar o MCP a novos casos de uso (IA multimodal, IoT, etc.), enquanto mantém um olho na promessa central: tornar a AI ** mais conectada, com reconhecimento de contexto e capacitação de usuário ** na era da Web3.

7. Comparação com projetos ou protocolos similares Web3​

A mistura exclusiva de IA e conectividade do MCP significa que não há muitos equivalentes diretos de maçãs para maçãs, mas é esclarecedor compará-lo com outros projetos no cruzamento de Web3 e IA ou com objetivos análogos:

• ** SingularityNet (AGI/X) **-*Marketplace de IA descentralizado:*Singularitynet, lançado em 2017 pelo Dr. Ben Goertzel e outros, é um mercado baseado em blockchain para serviços de IA. Ele permite que os desenvolvedores monetizem os algoritmos de IA como serviços e usuários para consumir esses serviços, todos facilitados por um token (Agix) que é usado para pagamentos e governança. Em essência, a SingularityNet está tentando descentralizar o abastecimento de modelos de IA **, hospedando -os em uma rede onde qualquer pessoa pode chamar um serviço de IA em troca de tokens. Isso difere do MCP fundamentalmente. O MCP não hospeda ou monetiza os modelos de IA; Em vez disso, ele fornece uma interface padrão ** para AI (onde quer que esteja em execução) para acessar dados/ferramentas **. Pode -se imaginar usar o MCP para conectar uma IA aos serviços listados no Singularitynet, mas a própria singularitynet se concentra na camada econômica (que fornece um serviço de IA e como eles são pagos). Outra diferença-chave: ** Governança **-SingularityNet tem governança na cadeia (via ** propostas de aprimoramento de singularitynet (SNEPS) ** e votação do Agix Token) para evoluir sua plataforma. A governança do MCP, por outro lado, é fora da cadeia e colaborativa sem um token. Em resumo, o SingularityNet e o MCP se esforçam para um ecossistema de IA mais aberto, mas o SingularityNet é sobre uma rede tokenizada de algoritmos de AI **, enquanto o MCP é sobre um padrão de protocolo ** para a interoperabilidade da AI-tool **. Eles poderiam complementar: por exemplo, uma IA no Singularitynet poderia usar o MCP para buscar dados externos de que precisa. Mas o SingularityNet não tenta padronizar o uso da ferramenta; Ele usa o Blockchain para coordenar os serviços de IA, enquanto o MCP usa padrões de software para permitir que a IA trabalhe com qualquer serviço.
• ** Fetch.ai (FET) **-Plataforma descentralizada baseada em agente:fetch.ai é outro projeto que mistura a IA e o blockchain. Ele lançou seu próprio blockchain de prova de participação e estrutura para a criação de agentes autônomos ** que executam tarefas e interagem em uma rede descentralizada. Na visão de Fetch, milhões de "agentes de software" (representando pessoas, dispositivos ou organizações) podem negociar e trocar valor, usando tokens FET para transações. O Fetch.ai fornece uma estrutura de agente (UAGENTs) e infraestrutura para descoberta e comunicação entre agentes em seu livro. Por exemplo, um agente de busca pode ajudar a otimizar o tráfego em uma cidade interagindo com outros agentes para estacionamento e transporte ou gerenciar um fluxo de trabalho da cadeia de suprimentos autonomamente. Como isso se compara ao MCP? Ambos lidam com o conceito de agentes, mas os agentes da busca. Os agentes do MCP (hosts de IA) são orientados para o modelo (como um LLM) e não estão vinculados a nenhuma rede única; O MCP está contente em operar pela Internet ou dentro de uma configuração de nuvem, sem exigir uma blockchain. O Fetch.ai tenta construir uma nova economia descentralizada de IA desde o início ** (com seu próprio livro para confiança e transações), enquanto o MCP é ** camada-agnóstico **-ele se levanta em redes existentes (pode ser usado sobre interações HTTPs ou até em cima de um blockchin), se necessário), para inabilizar as interações. Pode-se dizer que buscar mais sobre ** agentes econômicos autônomos ** e MCP sobre ** agentes de uso inteligente de ferramentas **. Curiosamente, eles podem se cruzar: um agente autônomo no busca.ai pode usar o MCP para interagir com recursos fora da cadeia ou outras blockchains. Por outro lado, pode-se usar o MCP para criar sistemas multi-agentes que aproveitam diferentes blockchains (não apenas um). Na prática, o MCP teve uma adoção mais rápida porque não exigia sua própria rede - funciona com o Ethereum, Solana, Web2 APIs etc., fora da caixa. A abordagem do Fetch.ai é mais pesada, criando um ecossistema inteiro que os participantes devem ingressar (e adquirir tokens) para usar. Em suma, ** Fetch.ai vs MCP **: Fetch é uma plataformacom seu próprio token/blockchain para agentes de IA, concentrando -se em interoperabilidade e trocas econômicas entre agentes, enquanto o MCP é um protocoloque os agentes da IA ​​(em qualquer ambiente) podem usar para conectar e ferramentas. Seus objetivos se sobrepõem a permitir a automação orientada pela IA, mas lidam com diferentes camadas da pilha e têm filosofias arquitetônicas muito diferentes (ecossistema fechado vs aberto).
• ** ChainLink e oráculos descentralizados **-Conectando blockchains a dados fora da cadeia:ChainLink não é um projeto de IA, mas é altamente relevante como um protocolo Web3 resolvendo um problema complementar: como conectar ** Blockchains ** com dados e computação externos. O ChainLink é uma rede descentralizada de nós (oráculos) que buscam, verificam e fornecem dados fora da cadeia para contratos inteligentes de maneira minimizada. Por exemplo, o ChainLink Oracles fornece feeds de preços aos protocolos de define ou chamam APIs externas em nome de contratos inteligentes por meio de funções do ChainLink. Comparativamente, o MCP conecta os modelos ** AI ** a dados/ferramentas externas (alguns dos quais podem ser blockchains). Pode -se dizer que ** ChainLink traz dados para blockchains, enquanto o MCP traz dados para ai **. Existe um paralelo conceitual: ambos estabelecem uma ponte entre sistemas isolados. O ChainLink se concentra na confiabilidade, descentralização e segurança dos dados alimentados na cadeia (resolvendo o "problema do Oracle" do ponto único de falha). O MCP se concentra na flexibilidade e padronização de como a IA pode acessar dados (resolvendo o "problema de integração" para os agentes da IA). Eles operam em diferentes domínios (contratos inteligentes versus assistentes de IA), mas pode -se comparar servidores MCP com oracles: um servidor MCP para dados de preços pode chamar a mesma APIs de um nó ChainLink. A diferença é o ** consumidor **-No caso do MCP, o consumidor é um assistente de IA ou usuário, não um contrato inteligente determinístico. Além disso, o MCP não fornece inerentemente a confiança que o ChainLink (MCP Servers pode ser centralizado ou administrado pela comunidade, com a confiança gerenciada no nível do aplicativo). No entanto, como mencionado anteriormente, as idéias para descentralizar redes MCP podem emprestar da Oracle Networks-por exemplo, vários servidores MCP podem ser consultados e os resultados foram verificados para garantir que uma IA não seja alimentada com dados ruins, semelhante a como vários nós do ChainLink agregam um preço. Em resumo, ** ChainLink vs MCP **: ChainLink éMiddleware Web3 para blockchains consumirem dados externos, o MCP éMiddleware AI para os modelos consumirem dados externos (que podem incluir dados de blockchain). Eles atendem às necessidades análogas em diferentes reinos e podem até complementar: uma IA usando o MCP pode buscar um feed de dados fornecido pelo ChainLink como um recurso confiável e, inversamente, uma IA poderia servir como fonte de análise que um Oracle do ChainLink traz na cadeia (embora esse último cenário levantasse questões de verificação).
• ** Funções plugins / openiAI chatgpt vs MCP ** -*ABRIGENÇÕES DE INTEGRAÇÃO DE FERRAMENTAS AI:*Embora não sejam projetos Web3, uma comparação rápida é garantida porque os plugins chatGPT e o recurso de chamada de função do OpenAI também conectam a IA a ferramentas externas. Os plug -ins ChatGPT usam uma especificação OpenAPI fornecida por um serviço, e o modelo pode chamar essas APIs seguindo a especificação. As limitações são que é um ecossistema fechado (plugins aprovados pelo OpenAI, executando os servidores do OpenAI) e cada plug-in é uma integração silenciada. O mais recente * "Agents" * do Openai está mais próximo do MCP no conceito, permitindo que os desenvolvedores defina ferramentas/funções que uma IA pode usar, mas inicialmente era específico para o ecossistema do OpenAI. ** Langchain ** também forneceu uma estrutura para fornecer ferramentas LLMS no código. O MCP difere oferecendo um padrão ** aberto, modelo-agnóstico ** para isso. Como uma análise colocou, Langchain criou um padrão voltado para o desenvolvedor (uma interface Python) para ferramentas, enquanto o MCP cria um * padrão * voltado para o modelo *-um agente de IA pode descobrir e usar qualquer ferramenta definida pelo MCP no tempo de execução sem código personalizado. Em termos práticos, o ecossistema de servidores da MCP se tornou maior e mais diversificado do que a loja de plug -in do ChatGPT dentro de meses. E, em vez de cada modelo ter seu próprio formato de plug -in (o OpenAi tinha o deles, outros tinham diferentes), muitos estão coalescendo em torno do MCP. O próprio OpenAI sinalizou o suporte ao MCP, alinhando essencialmente sua abordagem de função com o padrão mais amplo. Portanto, comparando ** plugins OpenAI com MCP **: Os plugins são uma abordagem centralizada e com curadoria, enquanto o MCP é uma abordagem descentralizada e orientada pela comunidade. Em uma mentalidade do Web3, o MCP é mais "código aberto e sem permissão", enquanto os ecossistemas proprietários de plug -in estão mais fechados. Isso torna o MCP análogo ao ethos do Web3, embora não seja um blockchain - ele permite a interoperabilidade e o controle do usuário (você pode executar seu próprio servidor MCP para obter seus dados, em vez de fornecer tudo a um provedor de IA). Essa comparação mostra por que muitos consideram o MCP como tendo mais potencial de longo prazo: não está bloqueado em um fornecedor ou um modelo.
• ** Projeto NAMDA e estruturas de agentes descentralizadas: ** Namda merece uma nota separada porque combina explicitamente o MCP com os conceitos da Web3. Conforme descrito anteriormente, a NAMDA (arquitetura distribuída modular do agente em rede) é uma iniciativa MIT/IBM iniciada em 2024 para criar uma rede escalável e distribuída de agentes de IA ** usando o MCP como camada de comunicação. Ele trata o MCP como o backbone das mensagens (como o MCP usa mensagens do tipo JSON-RPC padrão, se encaixa bem para comunicações inter-agentes) e, em seguida, adiciona camadas para ** descoberta dinâmica, tolerância a falhas e identidades verificáveis ​​** usando técnicas de bloqueio-inspiração. Os agentes da NAMDA podem estar em qualquer lugar (nuvem, dispositivos de borda, etc.), mas um registro descentralizado (um pouco como um DHT ou blockchain) mantém o controle deles e suas capacidades de uma maneira à prova de adulteração. Eles até exploram os agentes para incentivar a cooperação ou o compartilhamento de recursos. Em essência, o NAMDA é um experimento na aparência de um ** "Web3 do MCP" **. Ainda não é um projeto amplamente implantado, mas é um dos "protocolos semelhantes" mais próximos em espírito. Se visualizarmos Namda vs MCP: Namda usa o MCP (por isso não é padrões concorrentes), mas o estende com um protocolo para redes e coordenar vários agentes de maneira minimizada. Pode-se comparar o NAMDA com estruturas como ** Autonolas ou sistemas multi-agentes (MAS) ** que a comunidade criptográfica viu, mas aqueles geralmente não possuíam um componente de IA poderoso ou um protocolo comum. NAMDA + MCP Juntos mostrar como uma rede de agente descentralizada pode funcionar, com o blockchain fornecendo ** Identidade, reputação e possivelmente incentivos de token ** e MCP fornecendo a comunicação e o uso de ferramentas ** **.

Em resumo, ** MCP se destaca ** da maioria dos projetos anteriores do Web3: ele não começou como um projeto de criptografia, mas rapidamente se cruza com o Web3 porque resolve problemas complementares. Projetos como SingularityNet e Fetch.ai pretendiam * descentralizar a computação ou serviços de IA * usando o blockchain; O MCP *padroniza a integração da IA ​​com os Serviços *, que pode melhorar a descentralização, evitando o bloqueio da plataforma. Redes Oracle como o ChainLink resolveu a entrega de dados no blockchain; O MCP resolve a entrega de dados à IA (incluindo dados de blockchain). Se os principais ideais do Web3 forem descentralização, interoperabilidade e empoderamento do usuário, o MCP está atacando a peça de interoperabilidade no reino da IA. Ele está até influenciando esses projetos mais antigos - por exemplo, não há nada que impeça a SingularityNet de disponibilizar seus serviços de IA via servidores MCP ou buscar agentes de usar o MCP para conversar com sistemas externos. Podemos muito bem ver uma convergência em que as redes de IA controladas por token usam o MCP como sua língua franca *, casando-se com a estrutura de incentivo do Web3 com a flexibilidade do MCP.

Finalmente, se considerarmos ** Percepção do mercado **: O MCP é frequentemente apontado como para a IA, o que o Web3 esperava fazer pela Internet - quebre os silos e capacite os usuários. Isso levou alguns ao apelido do MCP informalmente como "Web3 para IA" (mesmo quando nenhum blockchain está envolvido). No entanto, é importante reconhecer que o MCP é um padrão de protocolo, enquanto a maioria dos projetos da Web3 são plataformas de pilha completa com camadas econômicas. Em comparações, o MCP geralmente é uma solução universal mais leve, enquanto os projetos de blockchain são soluções mais pesadas e especializadas. Dependendo do caso de uso, eles podem complementar, em vez de competir estritamente. À medida que o ecossistema amadurece, podemos ver o MCP integrado a muitos projetos da Web3 como um módulo (como o HTTP ou o JSON são onipresentes), e não como um projeto rival.

8. Percepção pública, tração do mercado e cobertura da mídia​

O sentimento público em relação ao MCP tem sido extremamente positivo nas comunidades de IA e Web3, muitas vezes na fronteira com entusiasmado. Muitos vêem isso como um ** divisor de águas ** que chegou em silêncio, mas depois levou a indústria pela tempestade. Vamos quebrar a percepção, tração e narrativas notáveis ​​da mídia:

** Métricas de tração e adoção do mercado: ** Em meados de 2025, o MCP alcançou um nível de adoção raro para um novo protocolo. É apoiado em praticamente todos os principais provedores de modelos de IA (Antrópico, Openai, Google, Meta) e suportado pela Big Tech Infrastructure (Microsoft, Github, AWS etc.), conforme detalhado anteriormente. Somente isso sinaliza para o mercado que o MCP provavelmente está aqui para ficar (semelhante a como o apoio amplo impulsionou o TCP/IP ou HTTP nos primeiros dias da Internet). No lado Web3, a tração *é evidente no comportamento do desenvolvedor *: Hackathons começou a apresentar projetos MCP, e muitas ferramentas de dev blockchain agora mencionam a integração do MCP como um ponto de venda. A estatística de "mais de 1000 conectores em alguns meses" e a citação de "milhares de integrações" de Mike Krieger são frequentemente citadas para ilustrar a rapidez com que o MCP foi pego. Isso sugere fortes efeitos de rede - quanto mais ferramentas disponíveis via MCP, mais útil é, provocando mais adoção (um ciclo de feedback positivo). VCs e analistas observaram que o MCP alcançou em menos de um ano o que as tentativas anteriores de "interoperabilidade da IA" não fizeram ao longo de vários anos, em grande parte devido ao tempo (montando a onda de interesse em agentes da IA) e de código aberto. Na mídia Web3, a tração às vezes é medida em termos de desenvolvedor Mindshare e integração em projetos, e o MCP pontua agora em ambos.

** Percepção pública nas comunidades de IA e Web3: ** Inicialmente, o MCP voou sob o radar quando anunciado pela primeira vez (final de 2024). Mas no início de 2025, à medida que surgiram histórias de sucesso, a percepção mudou para a emoção. Os profissionais da IA ​​viam o MCP como a "peça de quebra -cabeça ausente" para tornar os agentes de IA verdadeiramente úteis além dos exemplos de brinquedos. Os construtores do Web3, por outro lado, o viram como uma ponte para finalmente incorporar a IA em Dapps sem jogar fora a descentralização-uma IA pode usar dados na cadeia sem precisar de um oráculo centralizado, por exemplo. ** Líderes de pensamento ** estão cantando louvores: por exemplo, Jesus Rodriguez (um importante escritor da AI da Web3) escreveu em Coindesk que o MCP pode ser*“Um dos protocolos mais transformadores da era da IA ​​e um ótimo ajuste para as arquiteturas Web3”*. Rares Crisan em um notável blog de capital argumentou que o MCP poderia cumprir a promessa da Web3, onde apenas o blockchain lutou, tornando a Internet mais centrada no usuário e natural para interagir. Essas narrativas enquadram o MCP como revolucionário, mas prático - não apenas hype.

Para ser justo, ** Nem todos os comentários não são críticos **. Alguns desenvolvedores de IA em fóruns como o Reddit apontaram que o MCP "não faz tudo"-é um protocolo de comunicação, não um agente pronta para uso ou um mecanismo de raciocínio. Por exemplo, uma discussão do Reddit intitulada "MCP é uma armadilha sem saída" argumentou que o MCP por si só não gerencia a cognição do agente ou garante a qualidade; Ainda requer um bom design de agentes e controles de segurança. Essa visão sugere que o MCP pode ser exagerado como uma bala de prata. No entanto, essas críticas são mais sobre as expectativas de temperamento do que rejeitar a utilidade do MCP. Eles enfatizam que o MCP resolve a conectividade da ferramenta, mas ainda é necessário criar lógica robusta do agente (ou seja, o MCP não cria magicamente um agente inteligente, ele equipa um com ferramentas). O consenso **, porém, é que o MCP é um grande passo à frente **, mesmo entre vozes cautelosas. Abraçar o blog da comunidade do rosto observou que, embora o MCP não seja um resolver, é um grande facilitador para a IA integrada e com reconhecimento de contexto, e os desenvolvedores estão se unindo por esse motivo.

** Cobertura da mídia: ** MCP recebeu cobertura significativa em toda a mídia tecnológica e mídia de nicho Blockchain:

• ** TechCrunch ** Runou várias histórias. Eles cobriram o conceito inicial ("Antrópico propõe uma nova maneira de conectar dados aos chatbots da IA") em torno do lançamento em 2024. Em 2025, o TechCrunch destacou cada grande momento de adoção: o suporte do OpenAI, o envolvimento do Google, do Microsoft/Github. Esses artigos geralmente enfatizam a unidade da indústria em torno do MCP. Por exemplo, o TechCrunch citou o endosso de Sam Altman e observou a rápida mudança dos padrões rivais para o MCP. Ao fazer isso, eles retrataram o MCP como o padrão emergente semelhante ao que ninguém queria ficar de fora dos protocolos da Internet nos anos 90. Essa cobertura em uma saída de destaque sinalizou para o mundo da tecnologia mais amplo que o MCP é importante e real, não apenas um projeto de código aberto.
• ** Condesk ** e outras publicações criptográficas agarraram -se ao ângulo ** da Web3 **. O artigo de opinião de Coindesk, de Rodriguez (julho de 2025), é frequentemente citado; Ele pintou uma imagem futurista, onde cada blockchain poderia ser um servidor MCP e novas redes MCP podem ser executadas em blockchains. Ele conectou o MCP a conceitos como identidade descentralizada, autenticação e verificabilidade - falando o idioma do público da blockchain e sugerindo que o MCP poderia ser o protocolo que realmente combina com estruturas descentralizadas. O CointeleGraph, Bankless e outros também discutiram o MCP no contexto de “Agentes e Defi da IA” e tópicos semelhantes, geralmente otimistas sobre as possibilidades (por exemplo, Bankless tinham um artigo sobre o uso do MCP para permitir que uma IA gerencie negociações na cadeia e incluiu um instruções para o seu próprio servidor MCP).
• ** Relatórios notáveis ​​de blogs / analistas de VC: ** A notável postagem no blog de capital (julho de 2025) é um exemplo de análise de risco que atrai paralelos entre o MCP e a evolução dos protocolos da Web. Ele essencialmente argumenta que o MCP poderia fazer pelo Web3 o que o HTTP fez pelo Web1 - fornecendo uma nova camada de interface (interface de linguagem natural) que não substitui a infraestrutura subjacente, mas a torna utilizável. Esse tipo de narrativa é atraente e ecoado em painéis e podcasts. Ele posiciona o MCP não como competindo com o Blockchain, mas como a próxima camada de abstração que finalmente permite que os usuários normais (via IA) aproveitem facilmente o blockchain e os serviços da Web.
• ** Comunidade de desenvolvedores Buzz: ** fora dos artigos formais, a ascensão do MCP pode ser avaliada por sua presença no discurso do desenvolvedor - negociações de conferência, canais do YouTube, boletins informativos. Por exemplo, houve posts populares como "MCP: o link que falta para a AI Agentic?" Em sites como Runtime.News e Newsletters (por exemplo, um do pesquisador da IA ​​Nathan Lambert) discutindo experimentos práticos com o MCP e como ele se compara a outras estruturas de uso de ferramentas. O tom geral é a curiosidade e a emoção: os desenvolvedores compartilham demos de conectar a IA à sua automação residencial ou carteira de criptografia com apenas algumas linhas usando servidores MCP, algo que parecia ficção científica há pouco tempo. Essa emoção de base é importante porque mostra que o MCP tem Mindshare além de apenas endossos corporativos.
• ** Perspectiva corporativa: ** Mídia e analistas focados na IA corporativa também observam o MCP como um desenvolvimento importante. Por exemplo, * a nova pilha * cobriu como o suporte antrópico adicionado para servidores MCP remotos em Claude para uso corporativo. O ângulo aqui é que as empresas podem usar o MCP para conectar suas bases e sistemas de conhecimento interno à IA com segurança. Isso também importa para o Web3, pois muitas empresas de blockchain são as próprias empresas e podem aproveitar o MCP internamente (por exemplo, uma troca de criptografia pode usar o MCP para permitir que um IA analise os registros de transações internas para detecção de fraude).

** Citações e reações notáveis: ** Alguns valem a pena destacar como encapsulando a percepção pública:

• • “Assim como o HTTP revolucionou as comunicações da Web, o MCP fornece uma estrutura universal ... substituindo integrações fragmentadas por um único protocolo.” * - CoinCoindesk. Essa comparação com HTTP é poderosa; Ele enquadra o MCP como inovação em nível de infraestrutura.
• • “O MCP se tornou um padrão aberto próspero, com milhares de integrações e crescimento. Os LLMs são mais úteis ao se conectar aos dados que você já tem ...” * - Mike Krieger (Antrópico). Esta é uma confirmação oficial da tração e da proposta de valor central, que tem sido amplamente compartilhada nas mídias sociais.
• • “A promessa do Web3 ... pode finalmente ser realizada ... através da linguagem natural e dos agentes da IA. ... MCP é a coisa mais próxima que vimos de um Web3 real para as massas.” * - Capital notável. Esta declaração ousada ressoa com aqueles frustrados com as lentas melhorias de UX em criptografia; Ele sugere que a IA pode quebrar o código de adoção convencional, abstraindo a complexidade.

** Desafios e ceticismo: ** Embora o entusiasmo seja alto, a mídia também discutiu desafios:

• ** Preocupações de segurança: ** As tomadas como a nova pilha ou os blogs de segurança levantaram que permitir que a IA execute ferramentas pode ser perigosa se não for uma caixa de areia. E se um servidor MCP malicioso tentasse obter uma IA para executar uma ação prejudicial? O blog Limechain alerta explicitamente de * riscos significativos de segurança " * com servidores MCP desenvolvidos pela comunidade (por exemplo, um servidor que lida com as chaves privados deve ser extremamente seguro). Essas preocupações foram ecoadas nas discussões: essencialmente, o MCP expande as capacidades da IA, mas com o poder vem o risco. A resposta da comunidade (guias, mecanismos de autenticação) também foi abordada, geralmente tranquilizando que as mitigações estão sendo construídas. Ainda assim, qualquer uso indevido de destaque do MCP (digamos que uma IA desencadeou uma transferência de criptografia não intencional) afetaria a percepção, então a mídia está atento a essa frente. -** Desempenho e custo: ** Alguns analistas observam que o uso de agentes de IA com ferramentas pode ser mais lento ou mais caro do que chamar uma API diretamente (porque a IA pode precisar de várias etapas de entrada e saída para obter o que precisa). Em contextos de negociação de alta frequência ou execução na cadeia, essa latência pode ser problemática. Por enquanto, eles são vistos como obstáculos técnicos para otimizar (através de um melhor design ou streaming de agentes), em vez de quebradores de negócios.
• ** Gerenciamento de hype: ** Como em qualquer tecnologia de tendência, há um pouco de hype. Algumas vozes alertam para não declarar MCP a solução para tudo. Por exemplo, o artigo do Hugging Face pergunta: "O MCP é uma bala de prata?" e respostas Não - os desenvolvedores ainda precisam lidar com o gerenciamento de contexto, e o MCP funciona melhor em combinação com boas estratégias de solicitação e memória. Tais tomadas equilibradas são saudáveis ​​no discurso.

** Sentimento geral da mídia: ** A narrativa que emerge é em grande parte esperançosa e prospectiva:

• O MCP é visto como uma ferramenta prática que oferece melhorias reais agora (portanto, não vaporware), qual a mídia ressalta citando exemplos de trabalho: Claude Reading Arquivos, copilot usando o MCP no VSCode, uma IA completando uma transação de solana em uma demonstração, etc ..
• Também é retratado como um ponto de partida estratégico para o futuro da IA ​​e da Web3. A mídia geralmente conclui que o MCP ou coisas como será essencial para "IA descentralizada" ou "Web4" ou qualquer termo que se use para a Web da próxima geração. Há uma sensação de que o MCP abriu uma porta e agora a inovação está fluindo - seja os agentes descentralizados ou empresas descentralizados da NAMDA que conectam sistemas herdados à IA, muitas histórias futuras remontam à introdução do MCP.

No mercado, pode -se avaliar a tração pela formação de startups e financiamento em torno do ecossistema MCP. De fato, existem rumores/relatórios de startups com foco em "mercados MCP" ou plataformas MCP gerenciadas recebendo financiamento (escrita notável de capital sobre isso sugere juros de VC). Podemos esperar que a mídia comece a cobri -las tangencialmente - por exemplo, “O startup X usa o MCP para permitir que sua IA gerencie seu portfólio de criptografia - eleva US $ y milhões”.

** Conclusão da percepção: ** No final de 2025, o MCP desfruta de uma reputação como uma tecnologia que habilita a tecnologia. Tem forte defesa de figuras influentes na IA e na criptografia. A narrativa pública evoluiu de *"Aqui está uma ferramenta interessante" *para *"Isso pode ser fundamental para a próxima web" *. Enquanto isso, a cobertura prática confirma que está funcionando e sendo adotada, emprestando credibilidade. Desde que a comunidade continue enfrentando desafios (segurança, governança em escala) e nenhum desastre importante ocorre, é provável que a imagem pública do MCP permaneça positiva ou até se torne icônica como "o protocolo que fez a IA e a Web3 serem agradáveis ​​juntos".

A mídia provavelmente ficará de olho em:

• Histórias de sucesso (por exemplo, se um grande DAO implementa um tesoureiro de IA via MCP ou um governo usa o MCP para sistemas de IA de dados abertos).
• Quaisquer incidentes de segurança (para avaliar o risco).
• A evolução das redes MCP e se algum componente de token ou blockchain entra oficialmente em cena (que seria uma grande notícia em ponte a IA e a criptografia com mais força).

A partir de agora, no entanto, a cobertura pode ser resumida por uma linha de Coindesk: * “A combinação de Web3 e MCP pode ser apenas uma nova base para a IA descentralizada”.

** Referências: **

• Notícias antrópicas: * "Introdução ao protocolo de contexto do modelo", * novembro de 2024
• Blog Limechain: * "O que é MCP e como ele se aplica a blockchains?" * Maio de 2025
• Blog do ChainStack: * "MCP for Web3 Builders: Solana, EVM e Documentação" * Junho de 2025
• Condesk Op-ed: * "O Protocolo dos Agentes: Potencial do MCP da Web3", * Jul 2025
• Capital notável: * "Por que o MCP representa a oportunidade real da Web3", * julho de 2025
• TechCrunch: * "OpenAI adota o padrão de Anthropic ...", * 26 de março de 2025
• TechCrunch: * "Google para abraçar o padrão de Anthropic ...", * 9 de abril de 2025
• TechCrunch: * "Github, Microsoft abraça… (Comitê de Direção MCP)", * 19 de maio de 2025
• Microsoft Dev Blog: * "Official C# SDK for MCP", * abril de 2025
• Blog de rosto abraçando: * "#14: O que é MCP e por que todo mundo está falando sobre isso?" * Mar 2025
• Pesquisa Mescari: * "Fetch.ai Perfil", * 2023
• Média (Nu Fintimes): * "Unveing ​​SingularityNet", * março de 2024

O que é um DAG e como ele difere de uma blockchain?​

Um Grafo Acíclico Dirigido (Directed Acyclic Graph, DAG) é uma estrutura de dados na qual vértices (nodos) são conectados por arestas direcionadas que nunca formam um ciclo. No contexto de livros-razão distribuídos, um ledger baseado em DAG organiza transações ou eventos em um grafo semelhante a uma teia, em vez de uma única cadeia sequencial. Isso significa que, diferentemente de uma blockchain tradicional em que cada novo bloco referencia apenas um predecessor (formando uma cadeia linear), um nodo em um DAG pode referenciar múltiplas transações ou blocos anteriores. Como resultado, muitas transações podem ser confirmadas em paralelo, em vez de uma a uma em blocos cronológicos.

Se uma blockchain se parece com uma longa cadeia de blocos (cada bloco contendo diversas transações), um ledger baseado em DAG lembra mais uma árvore ou teia de transações individuais. Cada nova transação em um DAG pode se conectar (e, portanto, validar) uma ou mais transações anteriores, em vez de esperar para ser incluída no próximo bloco único. Essa diferença estrutural gera algumas distinções fundamentais:

• Validação paralela: Em blockchains, mineradores/validadores adicionam um bloco de cada vez, portanto as transações são confirmadas em lotes a cada novo bloco. Em DAGs, múltiplas transações (ou pequenos “blocos”) podem ser adicionados simultaneamente, pois cada uma pode se conectar a partes distintas do grafo. Essa paralelização evita que a rede dependa de um único encadeamento linear crescendo bloco a bloco.
• Ausência de ordem sequencial global: Uma blockchain cria uma ordem total de transações (cada bloco ocupa uma posição específica em uma única sequência). Um ledger baseado em DAG, por outro lado, produz uma ordem parcial. Não existe um “último bloco” único; diversos “tips” do grafo coexistem e podem ser estendidos simultaneamente. Protocolos de consenso são necessários para determinar posteriormente a ordem ou validade final das transações no DAG.
• Confirmação de transações: Em blockchains, as transações são confirmadas quando incluídas em um bloco minerado/validado que passa a integrar a cadeia aceita (geralmente após novos blocos serem adicionados). Em DAGs, uma nova transação pode ajudar a confirmar transações anteriores referenciando-as. Na Tangle da IOTA, por exemplo, cada transação deve aprovar duas transações anteriores, fazendo com que os usuários validem as transações uns dos outros. Isso reduz a divisão entre “criadores” e “validadores” vista em blockchains tradicionais – quem envia transações também executa parte da validação.

Importante: uma blockchain é um caso especial de DAG – um DAG restrito a uma única cadeia linear. Ambos são formas de tecnologia de registro distribuído (DLT) e compartilham metas como imutabilidade e descentralização. Entretanto, os ledgers baseados em DAG são estruturalmente “sem blocos” ou com múltiplos pais, conferindo-lhes propriedades distintas na prática. Blockchains como Bitcoin e Ethereum usam blocos sequenciais e frequentemente descartam blocos concorrentes (forks), enquanto os ledgers DAG buscam incorporar e organizar todas as transações não conflitantes. Essa diferença fundamental sustenta as variações de desempenho e design descritas a seguir.

Comparação técnica: arquitetura de DAG vs blockchain​

Para entender melhor as diferenças, comparemos suas arquiteturas e processos de validação:

• Estrutura de dados: Blockchains armazenam dados em blocos ligados em sequência linear (cada bloco contém muitas transações e aponta para um único bloco anterior). Ledgers baseados em DAG usam uma estrutura de grafo: cada nodo representa uma transação ou bloco de eventos e pode apontar para múltiplos nodos anteriores. O grafo é acíclico: ao seguir as arestas “para trás”, nunca retornamos ao ponto de partida. Isso permite definir uma ordenação topológica das transações (garantindo que cada referência apareça após a transação referenciada). Em suma: blockchains = cadeia unidimensional; DAGs = grafo multidimensional.
• Taxa de transferência e concorrência: Por causa da estrutura, blockchains e DAGs lidam com throughput de forma distinta. Em uma blockchain, mesmo em condições ideais, os blocos são adicionados um a um (frequentemente aguardando validação e propagação na rede antes do próximo bloco). Isso limita o throughput. Bitcoin, por exemplo, processa ~5–7 transações por segundo (TPS), e Ethereum ~15–30 TPS no modelo PoW clássico. DAGs permitem a entrada simultânea de múltiplas transações/blocos, com ramificações crescendo em paralelo e se juntando depois, o que pode elevar o throughput a milhares de TPS, comparáveis ou superiores a redes de pagamento tradicionais.
• Processo de validação de transações: Em blockchains, as transações aguardam no mempool e são validadas quando um minerador/validador as inclui em um novo bloco, que então é verificado pelos demais nodos. Em DAGs, a validação é mais contínua e distribuída: cada nova transação valida transações anteriores ao referenciá-las. Na Tangle da IOTA, cada transação executa uma pequena prova de trabalho e confirma duas anteriores, “votando” nelas. Na Nano, cada conta possui sua própria cadeia e as transações são validadas por votos de representantes. O efeito líquido é que os DAGs distribuem o trabalho de validação: em vez de um único produtor de bloco validar um lote, participantes ou validadores validam diferentes transações em paralelo.
• Mecanismo de consenso: Blockchains e DAGs precisam de um método para concordar sobre o estado do ledger (quais transações são confirmadas e em que ordem). Em blockchains, o consenso costuma resultar de PoW ou PoS produzindo o próximo bloco, seguindo a regra da “cadeia mais longa/pesada”. Em DAGs, o consenso pode ser mais complexo por não haver uma cadeia única. Algumas implementações usam gossip e votação virtual (Hedera Hashgraph), outras seleção de pontas via Monte Carlo (IOTA) ou esquemas de votação para definir quais ramos do grafo têm preferência. Abordaremos detalhes na seção de mecanismos de consenso. Geralmente, DAGs podem alcançar throughput elevado, mas precisam de um desenho cuidadoso para lidar com conflitos (p. ex., tentativas de gasto duplo) antes que a ordem final seja definida.
• Tratamento de forks: Em blockchains, quando dois blocos são minerados quase simultaneamente, ocorre um “fork”. Eventualmente, um ramo vence (cadeia mais longa) e o outro é órfão, desperdiçando trabalho. Em DAGs, a filosofia é aceitar forks como ramos adicionais do grafo. O DAG incorpora ambos; o algoritmo de consenso então decide quais transações são confirmadas (ou como resolver conflitos) sem descartar todo um ramo. Isso evita desperdício de recursos. O Tree-Graph do Conflux (DAG PoW), por exemplo, busca incluir todos os blocos no ledger e ordená-los, em vez de descartá-los.

Em resumo, blockchains oferecem uma estrutura sequencial simples com validação bloco a bloco, enquanto DAGs oferecem uma estrutura de grafo mais complexa que possibilita processamento assíncrono e paralelo de transações. Ledgers DAG requerem lógica adicional de consenso para gerir essa complexidade, mas prometem throughput superior e maior eficiência por aproveitar toda a capacidade da rede, sem restringi-la a uma fila única de blocos.

Benefícios dos sistemas blockchain baseados em DAG​

DAGs surgiram para superar limitações das blockchains em escalabilidade, velocidade e custo. Entre os principais benefícios:

• Alta escalabilidade e throughput: Redes DAG podem alcançar alto volume de transações porque as processam em paralelo. Não havendo gargalo de uma cadeia única, o TPS (transações por segundo) escala com a atividade da rede. Alguns protocolos DAG atingem milhares de TPS. O Hedera Hashgraph, por exemplo, suporta 10.000+ TPS na camada base e finaliza transações em 3–5 segundos (contra minutos ou mais nas blockchains PoW). Plataformas de contratos inteligentes baseadas em DAG, como Fantom, obtêm finalização quase instantânea (~1–2 s) sob cargas normais, tornando-as atraentes para casos que exigem alto volume (micropagamentos IoT, fluxos de dados em tempo real, etc.).
• Baixo custo (muitas vezes sem taxas): Muitos ledgers DAG apresentam taxas insignificantes ou transações sem custo. Eles não dependem de mineradores com recompensas ou taxas elevadas; em IOTA e Nano, por exemplo, não há taxas obrigatórias – o que é vital para micropagamentos. Onde há taxa (p. ex., Hedera, Fantom), ela costuma ser muito baixa e previsível, já que o sistema consegue lidar com a demanda sem guerra por espaço em bloco. Transações em Hedera custam cerca de US$0,0001. Ao incluir todas as transações válidas, sem desperdiçar trabalho com forks órfãos, o DAG também utiliza recursos de forma eficiente.
• Confirmação rápida e baixa latência: Em DAGs, as transações não precisam esperar para entrar em um bloco global, resultando em confirmação mais veloz. Muitos alcançam finalidade rápida – ponto em que a transação é definitiva. O consenso do Hedera Hashgraph finaliza transações em poucos segundos com certeza total (ABFT). Na Nano, as transações geralmente se confirmam em menos de 1 segundo, graças ao processo de votação leve. Isso proporciona experiências de usuário ágeis, ideal para pagamentos ou aplicativos interativos.
• Eficiência energética: DAGs não exigem mineração intensiva em PoW, tornando-os muito eficientes energeticamente. Alguns consomem menos energia por transação que blockchains PoS. Uma transação no Hedera consome cerca de 0,0001 kWh, muito abaixo de blockchains como Bitcoin (centenas de kWh) ou mesmo muitas redes PoS. A eliminação de cálculos desperdiçados (sem competição de mineração) e o aproveitamento de todas as transações contribuem para essa eficiência. Redes como Hedera têm pegada de carbono muito baixa, algumas inclusive compensam emissões e se tornam carbono-negativas.
• Sem mineração e validação democratizada: Em muitos modelos DAG, não há distinção clara entre mineradores e usuários. Na IOTA, cada transação aprova outras duas, descentralizando o trabalho de validação. Isso dispensa hardware potente ou grandes quantidades de tokens em staking para participar do consenso, tornando a rede mais acessível (embora alguns projetos DAG ainda usem validadores ou coordenadores).
• Melhor resposta a tráfego intenso: Blockchains sofrem com filas de mempool e aumento de taxas em momentos de grande uso. Como os DAGs permitem múltiplas ramificações paralelas, eles absorvem picos de tráfego com mais suavidade. À medida que o volume cresce, mais ramos são criados e processados simultaneamente, sem um limite rígido de throughput. Assim, a escalabilidade sob carga é mais “horizontal”: o sistema degrada menos em cenários de uso intenso (IoT massivo, eventos virais de DApps, etc.).

Em suma, ledgers DAG oferecem transações mais rápidas, baratas e escaláveis do que blockchains clássicas, mirando cenários de adoção em massa (micropagamentos, IoT, trading de alta frequência, etc.) que as blockchains convencionais lidam com dificuldade devido a limitações de throughput e custo. Entretanto, esses benefícios vêm acompanhados de trade-offs e desafios, discutidos adiante.

Mecanismos de consenso em plataformas DAG​

Como ledgers DAG não produzem naturalmente uma cadeia única, eles precisam de mecanismos de consenso inovadores para validar transações e garantir a concordância global do estado. Alguns exemplos:

• Tangle da IOTA – seleção de pontas e votação ponderada: A Tangle é um DAG de transações voltado ao IoT. Não há mineradores; cada transação executa uma pequena prova de trabalho e aprova duas transações anteriores (as “pontas” do grafo). A seleção de pontas usa um algoritmo Markov Chain Monte Carlo (MCMC) que escolhe probabilisticamente quais pontas aprovar, favorecendo o subtangle mais pesado. Inicialmente, a segurança dependia da quantidade de aprovações acumuladas – quanto mais aprovações indiretas, maior a confiança. Para proteger a rede nascente, havia um Coordenador central que emitia marcos finalizadores. Esse componente é eliminado na atualização “Coordicide” (IOTA 2.0), que implementa um consenso líderless ao estilo Nakamoto sobre um DAG. Nessa abordagem, os nodos votam na validade das transações referenciadas ao anexar novos blocos, e validadores (escolhidos via staking) emitem validation blocks. Uma transação é confirmada quando acumula peso de aprovação suficiente.
• Hedera Hashgraph – gossip e votação virtual (aBFT): O Hedera usa um DAG de eventos combinado a um algoritmo assíncrono tolerante a falhas bizantinas (aBFT). A ideia central é “gossip sobre gossip”: cada nodo transmite informações sobre transações e sobre sua história de gossip para outros. Isso forma um Hashgraph (DAG de eventos) no qual cada nodo sabe o que os demais ouviram e quando. A partir desse grafo, o Hedera executa votação virtual: em vez de enviar mensagens de voto, os nodos simulam localmente um algoritmo de votação analisando a estrutura do grafo. Isso produz uma ordem total e um timestamp de consenso justo (as transações são ordenadas pelo instante mediano em que a rede as recebeu). O consenso é sem líderes, tolerando até 1/3 de nodos maliciosos. Na prática, a rede é governada por um conselho de até 39 organizações (Hedera Council), então é permisionada, mas distribuída geograficamente. O resultado é um consenso extremamente rápido, com finalização em segundos.
• Lachesis da Fantom – PoS aBFT sem líderes: A Fantom é uma plataforma de smart contracts que usa um consenso DAG chamado Lachesis. Inspirado no Hashgraph, é um protocolo aBFT Proof-of-Stake. Cada validador cria um bloco de eventos e o adiciona ao seu DAG local, contendo transações e referências a eventos passados. Os validadores propagam esses blocos de forma assíncrona (sem uma sequência rígida). Quando uma supermaioria observou determinado evento, ele é marcado como “raiz”. Lachesis ordena os eventos finalizados e os registra na Opera Chain, um blockchain tradicional que mantém o histórico final. Assim, a DAG garante consenso rápido e assíncrono, e o resultado final é uma cadeia linear compatível com a EVM. A Fantom oferece finalidade de ~1–2 s e pode atingir milhares de TPS. Não há mineradores ou líderes fixos; todos os validadores participam na mesma medida, com peso baseado no stake de FTM.
• Open Representative Voting (ORV) da Nano: A Nano utiliza uma estrutura DAG específica chamada block-lattice. Cada conta possui sua própria blockchain, atualizada apenas pelo dono. Essas cadeias individuais formam um DAG, pois transações entre contas se conectam de forma assíncrona (um envio em uma cadeia faz referência ao recebimento em outra). O consenso é obtido pelo ORV: usuários escolhem um representante delegando peso (sem bloquear fundos). Representantes votam na validade das transações; quando uma supermaioria do peso (p. ex., >67%) concorda, a transação é cementada (irreversível). Não há recompensas de staking nem taxas; representantes atuam voluntariamente. A finalização típica é inferior a 1 s, e a rede é extremamente eficiente em energia (há apenas uma pequena PoW anti-spam realizada pelos emissores). O uso principal é como dinheiro digital instantâneo e sem tarifas.
• Outras abordagens:
  • Consenso Avalanche (X-Chain): O Avalanche usa um consenso DAG probabilístico em que validadores fazem amostragens aleatórias uns dos outros para determinar preferências. A X-Chain é um DAG de UTXOs que obtém consenso por esse método de amostragem repetida. As transações finalizam em ~1 s, e cada sub-rede pode alcançar cerca de 4.500 TPS. O protocolo é PoS e qualquer um com stake pode ser validador.
  • Conflux Tree-Graph: O Conflux expande o PoW de Bitcoin para um DAG de blocos, onde cada bloco referencia não apenas um pai, mas todos os blocos anteriores conhecidos. Isso evita o descarte de forks e eleva o throughput teórico para 3–6 mil TPS, utilizando PoW. O consenso ordena os blocos por uma regra de subárvore mais pesada.
  • Protocolos acadêmicos: Existem vários: SPECTRE e PHANTOM (blockDAGs da DAGlabs focados em alto throughput e confirmação rápida), Aleph Zero (consenso DAG aBFT na blockchain homônima), Parallel Chains/Prism, Narwhal & Bullshark da Sui (mempool DAG + consenso separado de finalização), entre outros.

Cada plataforma adapta o consenso às suas necessidades – sejam microtransações sem taxa, execução de smart contracts ou interoperabilidade. Em comum, visam evitar um gargalo sequencial. Os DAGs permitem muita atividade em paralelo e depois recorrem a algoritmos (gossip, votação, amostragem, etc.) para ordenar tudo, em vez de restringir a rede a um produtor de bloco por vez.

Estudos de caso: projetos blockchain baseados em DAG​

Alguns projetos notáveis:

• IOTA (The Tangle): A IOTA foi uma das primeiras criptomoedas DAG, voltada ao IoT. Sua Tangle é um DAG de transações em que cada nova transação confirma duas anteriores. A meta é viabilizar microtransações sem taxas entre dispositivos IoT. Lançada em 2016, utilizou inicialmente um Coordenador para proteger a rede nascente, mas está removendo-o com a atualização Coordicide, adotando um consenso totalmente descentralizado (votação em DAG). Em testes, alcançou centenas de TPS e espera-se que o IOTA 2.0 escale bem para demandas IoT. Casos de uso incluem streaming de dados com prova de integridade, pagamentos entre veículos, rastreamento de cadeia de suprimentos e identidade descentralizada (IOTA Identity). Não há smart contracts na camada base; há camadas adicionais para isso. A ausência de taxas é viabilizada por uma pequena PoW feita por quem envia a transação.
• Hedera Hashgraph (HBAR): O Hedera usa o consenso Hashgraph, desenvolvido por Leemon Baird, com governança de um conselho de até 39 organizações. É uma rede pública, porém permisionada quanto aos validadores. O DAG Hashgraph permite mais de 10 mil TPS com finalização em 3–5 segundos e baixíssimo consumo de energia (~0,0001 kWh por transação). Oferece serviços de tokenização (HTS), Consensus Service para registro imutável e smart contracts compatíveis com a EVM. Aplicações incluem rastreabilidade de cadeia de suprimentos, emissão em massa de NFTs, micropagamentos (publicidade, por exemplo) e soluções de identidade descentralizada. Seu diferencial é o desempenho e a estabilidade, com garantias matemáticas de ordem justa.
• Fantom (FTM): A Fantom é uma L1 de smart contracts que emprega o consenso DAG Lachesis. Lançada em 2019, se destacou no boom DeFi por ser rápida, barata e compatível com a EVM. Seu Opera Network usa Lachesis (aBFT PoS), onde validadores mantêm um DAG local de eventos e depois consolidam as transações em uma cadeia final. Oferece ~1 s para finalização e pode atingir milhares de TPS. DeFi, NFTs e jogos prosperaram na plataforma devido à velocidade e taxas baixas. A rede conta com dezenas de validadores independentes (qualquer um pode rodar um validador com o stake mínimo), demonstrando que DAGs podem atingir boa descentralização.
• Nano (XNO): A Nano (ex-RaiBlocks) é uma criptomoeda leve com estrutura de block-lattice. O foco é dinheiro digital P2P: transações instantâneas, sem taxas, com consumo mínimo de recursos. Cada conta tem sua própria cadeia, e transferências são feitas por blocos de envio e recebimento. O consenso via ORV (voto de representantes abertos) delega peso de voto a representantes, que validam conflitos. Não há recompensas ou taxas; os nós representantes operam voluntariamente. A confirmação é normalmente inferior a 1 s e o consumo de energia por transação é ínfimo. Adequado para micropagamentos, gorjetas, remessas e comércio.

(Tabela: comparação de projetos DAG selecionados. TPS = transações por segundo.)

Outros projetos incluem Obyte (Byteball) (pagamentos condicionais e armazenamento de dados), IoT Chain (ITC) (voltado ao IoT), Avalanche (usa DAG no consenso e tem adoção em DeFi/NFT), Conflux (DAG PoW de alto throughput na China) e protótipos acadêmicos como SPECTRE/PHANTOM. Os quatro exemplos destacados mostram a variedade de aplicações – de micropagamentos IoT a redes corporativas e smart contracts DeFi – todas tirando proveito da estrutura DAG.

Casos de uso da tecnologia DAG no ecossistema Web3​

DAGs se destacam em cenários que demandam alto desempenho e propriedades específicas:

• Internet das Coisas (IoT): Envolve milhões de dispositivos enviando dados e realizando pagamentos máquina a máquina. DAGs como IOTA foram criados para isso. Com micropagamentos sem taxas e suporte a altas frequências, dispositivos podem pagar por serviços e largura de banda em tempo real. Há pilotos de cidades inteligentes, rastreamento de cadeia de suprimentos (temperatura, localização), marketplaces de dados e aplicações de identidade descentralizada. A escalabilidade e o custo baixo dos DAGs se alinham à economia de micropagamentos no IoT.
• Finanças Descentralizadas (DeFi): Exchanges descentralizadas (DEXs), plataformas de empréstimo e pagamentos se beneficiam de alta vazão e baixa latência. DAGs (Fantom, Avalanche X-Chain, etc.) oferecem transações rápidas e taxas baixas mesmo em pico de demanda, reduzindo riscos de slippage e congestionamento. Em 2021, a Fantom viu grande atividade DeFi e manteve a rede operando suavemente. DAGs também podem servir como trilhas de pagamento (Nano) ou suportar trading de alta frequência e transações complexas de forma mais fluida.
• NFTs e jogos: O boom dos NFTs escancarou a necessidade de custos de minting reduzidos. Em blockchains saturadas, o gas tornou-se proibitivo. DAGs como Hedera e Fantom permitem mintar NFTs por frações de centavo, viabilizando ativos de jogos, colecionáveis e drops em larga escala. Em jogos, onde microtransações são comuns, a baixa latência e custo quase nulo melhoram a experiência (recompensas instantâneas, trocas rápidas sem “quebrar” o jogador em taxas). A alta capacidade também evita congestionamentos durante eventos populares.
• Identidade descentralizada (DID) e credenciais: Sistemas de identidade exigem registros imutáveis para IDs, credenciais e atestados. DAGs oferecem escala (potencialmente bilhões de transações de identidade) e baixo custo, essencial quando cada atualização precisa ser economicamente viável. O IOTA Identity fornece o método DID did:iota, permitindo identidade autossoberana, enquanto o Hedera possui iniciativas de registros de diplomas, certificados de vacinação e documentos de compliance. A rapidez e os custos baixos tornam viáveis as frequentes atualizações de identidade (rotação de chaves, novos atributos, etc.).
• Cadeia de suprimentos e integridade de dados: Qualquer caso que exija registrar grande volume de eventos se beneficia de DAGs. Rastreamento de produtos (fabricado, enviado, inspecionado) e logs de IoT (dados de energia, telecom) já usam redes como Hedera e IOTA. A capacidade elevada evita gargalos e o baixo custo viabiliza registrar até eventos de baixo valor. Projetos como Constellation Network focam em validar grandes volumes de dados, inclusive no setor governamental.
• Pagamentos e remessas: Transações rápidas e sem taxas tornam DAGs como Nano e IOTA adequados para pagamentos, gorjetas online e remessas internacionais (evitando taxas altas e longos tempos de espera). DAGs podem servir como rails de pagamento integrados a pontos de venda ou apps móveis, oferecendo experiência equivalente a cartões contactless. Hedera também participa de pilotos de pagamentos graças à finalização rápida e custos mínimos. Com alta capacidade, os DAGs mantêm desempenho mesmo em eventos de grande volume (Black Friday, por exemplo).
• Oráculos e feeds em tempo real: Oráculos precisam registrar dados externos (preços, clima, sensores) no ledger. DAGs podem atuar como redes de oráculos de alto throughput, garantindo ordenação e timestamp. O Hedera Consensus Service, por exemplo, é usado para registrar dados antes de enviá-los a outras blockchains. Em aplicações como publicidade descentralizada (registro de cliques/impressões), DAGs conseguem lidar com o volume elevado de eventos em tempo real.

O fio condutor é que DAGs oferecem escalabilidade, velocidade e baixo custo em cenários com transações de alta frequência ou em que a experiência de usuário precisa ser fluida (jogos, pagamentos). Embora nem todo caso migre para DAG (alguns preferem a maturidade, segurança ou efeitos de rede das blockchains tradicionais), eles preenchem nichos onde as blockchains convencionais esbarram em limitações.

Limitações e desafios dos DAGs​

Apesar das vantagens, os DAGs apresentam trade-offs:

• Maturidade e segurança: Muitos algoritmos de consenso DAG são relativamente novos e menos testados do que protocolos de blockchains estabelecidas. Isso pode significar vulnerabilidades desconhecidas. A complexidade adicional abre novas superfícies de ataque (spams de subtangles conflitantes, double spend antes da convergência, etc.). Alguns DAGs já tiveram incidentes (p. ex., a rede da IOTA precisou ser pausada após ataques/irregularidades). Em certos casos, a finalidade era apenas probabilística (sem uma garantia “final” determinística), o que é mais complexo para certas aplicações. Projetos recentes, como Hashgraph e Fantom, visam garantir finalidade instantânea via ABFT, mas o histórico ainda é curto se comparado a blockchains tradicionais.
• Complexidade do consenso: Algoritmos baseados em gossip, votação virtual, amostragem aleatória, etc., tornam as implementações maiores e mais complexas, aumentando a chance de bugs e dificultando o entendimento por parte dos desenvolvedores. A regra da cadeia mais longa é intuitiva, enquanto mecanismos como o Hashgraph ou o Avalanche exigem conhecimento mais profundo. Isso pode frear a adoção: empresas e desenvolvedores podem hesitar em confiar num sistema que parecem não dominar totalmente. Ferramentas e bibliotecas para DAGs ainda não alcançaram a maturidade do ecossistema Ethereum ou Bitcoin.
• Descentralização vs desempenho: Alguns DAGs sacrificam parte da descentralização para garantir desempenho. O Hedera, por exemplo, opera com um conjunto fixo de 39 nodos do conselho (embora planeje abrir gradualmente). A IOTA, por muito tempo, dependeu de um Coordenador central. A Nano confia nos representantes indicados pelos usuários, que podem concentrar grande parte do peso de voto. Em geral, blockchains costumam ser vistas como mais descentralizadas (milhares de nodos), enquanto alguns DAGs ainda não alcançaram números semelhantes. Isso não é inevitável, mas reflete estágios atuais de desenvolvimento.
• Dependência de volume: Certas redes DAG funcionam melhor com alto volume de transações. Na IOTA, a segurança melhora quando muitas transações honestas aprovam umas às outras. Se o tráfego é baixo, pontas podem demorar a ser aprovadas, e ataques podem ficar mais viáveis. Já blockchains mantêm segurança mesmo com poucas transações, desde que mineradores/validadores continuem produzindo blocos. Assim, alguns DAGs podem apresentar desempenho inconsistente: ótimos sob carga, mas lentos em períodos de baixo uso, a menos que haja mecanismos auxiliares.
• Ordenação e compatibilidade: Como os DAGs produzem apenas uma ordem parcial, protocolos complexos (smart contracts, por exemplo) demandam ordens determinísticas e resolução de conflitos. Plataformas como Fantom resolvem isso gerando uma cadeia final ordenada (Opera Chain), mas muitos DAGs puros preferem evitar estado global e contratos complexos inicialmente. Integrar DAGs com ecossistemas existentes (EVM, por exemplo) requer soluções específicas, elevando a complexidade.
• Armazenamento e sincronização: Alta capacidade de transações paralelas pode gerar crescimento rápido do ledger. São necessários algoritmos eficientes de pruning (para remover transações antigas que não impactam a segurança) e soluções para clientes leves (que não armazenam o DAG completo). Há também desafios de alcance (garantir que novas transações encontrem e referenciem as anteriores eficientemente) e de truncar o histórico com segurança. Embora blockchains também enfrentem crescimento de dados, a estrutura em DAG pode complicar cálculos de saldos ou provas parciais.
• Percepção e efeitos de rede: Além de aspectos técnicos, DAGs enfrentam o desafio de provar seu valor em um ecossistema dominado por blockchains. Muitos desenvolvedores e usuários estão mais confortáveis com blockchains, e os efeitos de rede (mais usuários, dApps, ferramentas) são fortes. DAGs às vezes são promovidos com promessas ousadas (“blockchain killer”), gerando ceticismo. Até que surjam “killer apps” ou uma base de usuários significativa, podem ser vistos como experimentais. Construir infraestrutura (listagens em exchanges, custódia, carteiras) também demanda tempo.

Resumindo, DAGs trocam simplicidade por desempenho, enfrentando desafios de complexidade do consenso, centralização parcial em certas implementações e necessidade de estabelecer confiança comparável às blockchains. A comunidade acadêmica e os desenvolvedores vêm estudando esses temas; uma publicação de 2024 (SoK) sobre protocolos DAG destaca o crescimento da diversidade de designs e a necessidade de compreender seus trade-offs. Conforme os projetos evoluem, muitos obstáculos (remoção de coordenadores, participação aberta, melhorias de ferramentas) devem ser superados, mas esses aspectos devem ser considerados ao avaliar DAG vs blockchain para um caso específico.

Tendências de adoção e perspectivas futuras​

Os DAGs ainda são minoritários em comparação com blockchains lineares, mas o interesse está aumentando:

• Mais projetos e pesquisas: Há crescimento no número de projetos explorando DAGs ou modelos híbridos. Plataformas como Aleph Zero (focada em privacidade) usam consenso DAG para ordenação rápida; Sui e Aptos integram mempools em DAG ou motores de execução paralela. Academicamente, há protocolos como SPECTRE, PHANTOM, GhostDAG e análises abrangentes (SoK) que classificam e avaliam abordagens. Pesquisas buscam resolver desafios como justiça, pruning, segurança em ambientes dinâmicos, etc.
• Modelos híbridos: Mesmo blockchains tradicionais incorporam conceitos DAG internamente para melhorar desempenho. Avalanche é um exemplo claro: apresenta-se como blockchain, mas o consenso é DAG. Ele ganhou adoção significativa em DeFi e NFTs, mostrando que usuários podem aderir a um sistema DAG sem sequer perceber, desde que suas necessidades sejam atendidas. Fantom expõe uma interface blockchain amigável enquanto usa DAG internamente, e outras redes podem seguir caminho semelhante.
• Adoção empresarial e de nicho: Empresas que exigem alto throughput, custos previsíveis e aceitam redes permisionadas têm explorado DAGs. O conselho do Hedera atraiu grandes corporações; isso impulsiona casos como tokenização de ativos, rastreamento de licenças de software, pagamentos corporativos etc. Consórcios também consideram DAGs para liquidações em telecom, registro de impressões publicitárias, transferências interbancárias e outros usos de alto volume. A IOTA participa de projetos financiados pela União Europeia (infraestrutura, identidade digital, IoT industrial). Se esses pilotos tiverem sucesso, poderemos ver adoção setorial.
• Avanços em descentralização comunitária: Críticas iniciais aos DAGs (coordenadores centrais, validadores restritos) estão sendo endereçadas. O Coordicide busca eliminar o coordenador da IOTA; o Hedera abriu seu código e discute planos para descentralizar ainda mais. Na Nano, a comunidade se mobiliza para distribuir o peso dos representantes. Esses passos são essenciais para ganhar credibilidade e aproximar os DAGs dos valores de descentralização do ecossistema Web3.
• Interoperabilidade e uso como layer 2: DAGs podem servir como camadas de escalabilidade ou redes interoperáveis, conectando-se a blockchains existentes via pontes. Um ledger DAG pode funcionar como layer 2 rápida para Ethereum, ancorando resultados em intervalos periódicos. Se a experiência for transparente, usuários podem desfrutar da velocidade do DAG mantendo a segurança ou liquidação na blockchain base.
• Perspectiva futura – complemento em vez de substituição (por enquanto): Muitos entusiastas reconhecem que DAGs complementam, não substituem totalmente as blockchains. No curto prazo, veremos uma paisagem heterogênea com blockchains e DAGs, cada qual otimizado para cenários específicos. DAGs podem ser a espinha dorsal de alta frequência do Web3, enquanto blockchains cuidam da liquidação de alto valor ou casos que exigem simplicidade e robustez. No longo prazo, se os DAGs provarem segurança e descentralização comparáveis, é possível que se tornem o paradigma dominante. A eficiência energética também se alinha a preocupações ambientais, favorecendo a adoção em um contexto de sustentabilidade.
• Sentimento comunitário: Há uma parte da comunidade cripto muito empolgada com DAGs, considerando-os o próximo passo evolutivo dos registros distribuídos. Ao mesmo tempo, existem céticos que destacam que segurança e descentralização não podem ser sacrificadas. Os projetos DAG precisam demonstrar que conseguem oferecer o melhor de ambos os mundos.

Em conclusão, o futuro dos DAGs é cautelosamente otimista. Blockchains ainda dominam, mas plataformas DAG estão ganhando espaço em domínios específicos e provando seu valor. À medida que as pesquisas solucionem desafios remanescentes, veremos mais convergência de ideias – blockchains incorporando melhorias inspiradas em DAG, e DAGs assimilando lições das blockchains em governança e segurança. Pesquisadores e desenvolvedores Web3 devem acompanhar os avanços dos DAGs, pois eles representam uma ramificação significativa na evolução das DLTs. É plausível que num futuro próximo tenhamos um ecossistema diversificado e interoperável, no qual os DAGs desempenhem papel vital em escalabilidade e aplicações especializadas, aproximando-nos de uma web verdadeiramente descentralizada e escalável.

Nas palavras de uma publicação do Hedera: ledgers baseados em DAG são “um passo promissor” na evolução das moedas digitais e da tecnologia descentralizada – não uma substituição total das blockchains, mas uma inovação importante que trabalhará lado a lado e inspirará melhorias em todo o panorama dos livros-razão distribuídos.

Fontes: As informações deste relatório foram extraídas de pesquisas acadêmicas sobre consenso DAG, documentação oficial e whitepapers de projetos como IOTA, Hedera Hashgraph, Fantom e Nano, além de blogs técnicos e artigos comparando DAGs e blockchains. Esses materiais respaldam as análises, benefícios e estudos de caso apresentados. O debate contínuo na comunidade de pesquisa Web3 indica que os DAGs continuarão em evidência na busca por soluções para o tripé escalabilidade–segurança–descentralização.

A Somnia é uma blockchain Layer-1 compatível com EVM construída para desempenho extremo, capaz de processar mais de 1.000.000 de transações por segundo (TPS) com finalidade em menos de um segundo. Para alcançar isso, a Somnia reimagina o design central da blockchain com quatro inovações técnicas principais:

• Consenso MultiStream: O consenso da Somnia é um novo protocolo BFT de prova de participação (proof-of-stake) onde cada validador mantém sua própria “cadeia de dados” de transações, produzindo blocos de forma independente. Uma cadeia de consenso separada periodicamente confirma o último bloco da cadeia de dados de cada validador e os ordena em uma única blockchain global. Isso permite a ingestão paralela de transações: múltiplos validadores podem propagar transações simultaneamente em seus fluxos de dados, que são posteriormente fundidos em um único registro ordenado. A cadeia de consenso (inspirada na pesquisa Autobahn BFT) garante a segurança, impedindo que qualquer validador faça um fork ou altere seu próprio fluxo uma vez que o bloco global seja finalizado. A Figura 1 ilustra essa arquitetura, onde cadeias específicas de validadores alimentam um bloco de consenso global.

• Execução Sequencial Acelerada: Em vez de depender da execução multi-threaded, a Somnia opta por tornar um único núcleo extremamente rápido. O cliente da Somnia compila contratos inteligentes EVM para código de máquina x86 nativo (just-in-time ou ahead-of-time). Contratos frequentemente usados são traduzidos em instruções de máquina otimizadas, eliminando a sobrecarga de interpretação típica e alcançando velocidade quase nativa de C++ para execução. Em benchmarks, isso resulta em centenas de nanossegundos por transferência ERC-20, suportando milhões de TX/seg em um único núcleo. Contratos menos chamados ainda podem ser executados no interpretador EVM padrão, equilibrando o custo de compilação. Além disso, a Somnia aproveita a execução fora de ordem e o pipelining de CPUs modernas (“paralelismo em nível de hardware”) para acelerar transações individuais. Ao compilar para código nativo, a CPU pode executar instruções em paralelo no nível do chip (por exemplo, sobrepondo buscas de memória e computações), acelerando ainda mais a lógica sequencial como transferências de tokens. Essa escolha de design reconhece que o paralelismo de software muitas vezes falha sob picos de carga de trabalho altamente correlacionados (por exemplo, uma mintagem de NFT popular onde todas as transações atingem o mesmo contrato). As otimizações de thread único da Somnia garantem que até mesmo cenários de contratos “quentes” alcancem alto rendimento, onde a execução paralela ingênua travaria.
• IceDB (Motor de Armazenamento Determinístico): A Somnia inclui um banco de dados de blockchain personalizado chamado IceDB para maximizar o desempenho e a previsibilidade do acesso ao estado. Diferente dos backends típicos de LevelDB/RocksDB, o IceDB fornece custos de leitura/escrita determinísticos: cada operação retorna um “relatório de desempenho” de exatamente quantas linhas de cache de RAM e páginas de disco foram acessadas. Isso permite que a Somnia cobre taxas de gas com base no uso real de recursos de uma maneira consistente e determinística em consenso. Por exemplo, leituras servidas da memória podem custar menos gas do que leituras frias que atingem o disco, sem não determinismo. O IceDB também usa uma camada de cache aprimorada otimizada tanto para leitura quanto para escrita, resultando em latência extremamente baixa (15–100 nanossegundos por operação em média). Além disso, o IceDB possui snapshotting de estado integrado: ele explora a estrutura interna do armazenamento estruturado em log para manter e atualizar hashes de estado global de forma eficiente, em vez de construir uma árvore de Merkle separada no nível da aplicação. Isso reduz a sobrecarga para calcular raízes de estado e provas. No geral, o design do IceDB garante acesso ao estado previsível e de alta velocidade e justiça na medição de gas, que são críticos na escala da Somnia.
• Compressão e Rede Avançadas: Processar milhões de TPS significa que os nós devem trocar enormes volumes de dados de transação (por exemplo, 1M de transferências ERC-20/seg ~ 1,5 Gbps de dados brutos). A Somnia aborda isso através de otimizações de compressão e rede:
  • Compressão de Streaming: Como cada validador publica um fluxo de dados contínuo, a Somnia pode usar compressão de fluxo com estado entre os blocos. Padrões comuns (como endereços repetitivos, chamadas de contrato, parâmetros) são comprimidos referenciando ocorrências anteriores no fluxo, alcançando taxas muito melhores do que a compressão de blocos independentes. Isso aproveita a distribuição de lei de potência da atividade da blockchain – um pequeno subconjunto de endereços ou chamadas responde por uma grande fração das transações, então codificá-los com símbolos curtos resulta em compressão massiva (por exemplo, um endereço usado em 10% das TX pode ser codificado em ~3 bits em vez de 20 bytes). As cadeias tradicionais não podem usar facilmente a compressão de fluxo porque os produtores de blocos rotacionam; os fluxos fixos por validador da Somnia desbloqueiam essa capacidade.
  • Agregação de Assinaturas BLS: Para eliminar as maiores partes incompressíveis das transações (assinaturas e hashes), a Somnia usa assinaturas BLS para transações e suporta a agregação de muitas assinaturas em uma só. Isso significa que um bloco de centenas de transações pode carregar uma única assinatura combinada, reduzindo drasticamente o tamanho dos dados (e o custo de verificação) em comparação com ter 64 bytes de assinatura ECDSA por transação. Os hashes de transação também não são transmitidos (os pares os recalculam conforme necessário). Juntos, a compressão e a agregação BLS reduzem os requisitos de largura de banda o suficiente para sustentar o alto rendimento da Somnia sem “sufocar” a rede.
  • Simetria de Largura de Banda: No design de múltiplos líderes da Somnia, cada validador compartilha continuamente sua fração de novos dados a cada bloco, em vez de um líder enviar o bloco inteiro para os outros. Consequentemente, a carga da rede é distribuída simetricamente – cada um dos N validadores faz upload de aproximadamente 1/N do total de dados para N-1 pares (e baixa as outras porções) a cada bloco, em vez de um único líder fazer upload de N-1 cópias. Nenhum nó precisa de largura de banda de saída maior que o rendimento geral da cadeia, evitando o gargalo onde um único líder deve ter uma enorme capacidade de upload. Essa utilização uniforme permite que a Somnia se aproxime dos limites físicos de largura de banda dos nós sem centralizar em alguns supernós. Em resumo, a pilha de rede da Somnia é projetada para que todos os validadores compartilhem o trabalho de propagar transações, permitindo um rendimento próximo ao nível de gigabit em toda a rede descentralizada.

Consenso e Segurança: A cadeia de consenso usa um protocolo de prova de participação PBFT modificado (Tolerância Prática a Falhas Bizantinas) com uma suposição parcialmente síncrona. A Somnia foi lançada com 60–100 validadores distribuídos globalmente (a mainnet começou com ~60 e visa 100). Os validadores são obrigados a executar hardware potente (especificações aproximadamente entre um nó Solana e Aptos em desempenho) para lidar com a carga. Esse número de validadores equilibra o desempenho com descentralização suficiente – a filosofia da equipe é “descentralização suficiente” (o suficiente para garantir segurança e resistência à censura, mas não tão extrema a ponto de prejudicar o desempenho). Notavelmente, o Google Cloud participou como validador no lançamento, ao lado de outros operadores de nós profissionais.

A Somnia implementa medidas de segurança PoS padrão, como depósitos de staking e slashing para comportamento malicioso. Para reforçar a segurança em seu novo motor de execução, a Somnia usa um sistema único chamado “Cuthbert” – uma implementação de referência alternativa (não otimizada) que roda em paralelo com o cliente principal em cada nó. Cada transação é executada em ambos os motores; se uma divergência ou bug for detectado nos resultados do cliente otimizado, o validador irá parar e se recusar a finalizar, prevenindo erros de consenso. Essa execução dupla atua como uma auditoria em tempo real, garantindo que as otimizações de desempenho agressivas nunca produzam transições de estado incorretas. Com o tempo, à medida que a confiança no cliente principal cresce, o Cuthbert pode ser descontinuado, mas durante os estágios iniciais ele adiciona uma camada extra de segurança.

Em resumo, a arquitetura da Somnia é adaptada para aplicações de massa e em tempo real. Ao desacoplar a propagação de transações da finalização (MultiStream), sobrecarregar a execução de núcleo único (compilação EVM e paralelismo em nível de CPU), otimizar a camada de dados (IceDB) e minimizar a largura de banda por transação (compressão + agregação), a Somnia alcança um desempenho ordens de magnitude além das L1s tradicionais. O CEO da Improbable, Herman Narula, afirma que é “a layer-one mais avançada… capaz de lidar com milhares de vezes o rendimento do Ethereum ou Solana” – construída especificamente para a velocidade, escala e responsividade necessárias para jogos de próxima geração, redes sociais e experiências imersivas de metaverso.

Tokenomics – Fornecimento, Utilidade e Design Econômico​

Fornecimento e Distribuição: O token nativo da Somnia, SOMI, tem um fornecimento máximo fixo de 1.000.000.000 de tokens (1 bilhão). Não há inflação contínua – o fornecimento é limitado e os tokens foram alocados antecipadamente para várias partes interessadas com cronogramas de vesting. A divisão da alocação é a seguinte:

No lançamento da mainnet (TGE no 3º trimestre de 2025), cerca de 16% do fornecimento entrou em circulação (principalmente dos desbloqueios iniciais das alocações da Comunidade e do Ecossistema). A maioria dos tokens (equipe, parceiros, investidores) fica bloqueada no primeiro ano e depois é liberada gradualmente, alinhando os incentivos para o desenvolvimento a longo prazo. Esse vesting estruturado ajuda a prevenir grandes vendas imediatas e garante que a fundação e os principais contribuidores tenham recursos ao longo do tempo para expandir a rede.

Utilidade do Token: O SOMI é central para o ecossistema da Somnia e segue um modelo de Prova de Participação Delegada (DPoS). Seus principais usos incluem:

• Staking e Segurança: Os validadores devem fazer stake de 5.000.000 de SOMI cada um para operar um nó e participar do consenso. Esse stake significativo (~0,5% do fornecimento total por validador) fornece segurança econômica; atores maliciosos arriscam perder seu depósito. A Somnia inicialmente visa 100 validadores, o que significa que até 500 milhões de SOMI poderiam ser colocados em stake para a operação dos nós (parte dos quais pode vir de delegação, veja abaixo). Além disso, delegadores (quaisquer detentores de tokens) podem fazer stake de SOMI delegando para validadores para ajudá-los a atingir o requisito de 5M. Os delegadores ganham uma parte das recompensas em troca. Isso abre os rendimentos de staking para não validadores e ajuda a descentralizar o stake entre muitos detentores de tokens. Apenas tokens em stake (seja por validadores ou via delegação) são elegíveis para recompensas da rede – simplesmente manter tokens sem fazer stake não gera recompensas.
• Taxas de Gas: Todas as transações on-chain e execuções de contratos inteligentes exigem SOMI para taxas de gas. Isso significa que cada interação (transferências, mintagens, uso de DApps) cria demanda pelo token. O modelo de gas da Somnia é baseado no do Ethereum (mesmas definições de unidade), mas com ajustes e custos base muito mais baixos. Como detalhado mais adiante, a Somnia tem taxas abaixo de um centavo e até descontos dinâmicos para DApps de alto volume, mas as taxas ainda são pagas em SOMI. Assim, se a rede tiver uso intenso (por exemplo, um jogo popular ou aplicativo social), usuários e desenvolvedores precisarão de SOMI para alimentar suas transações, impulsionando a utilidade.
• Recompensas para Validadores/Delegadores: As recompensas de bloco na Somnia vêm das taxas de transação e de um tesouro comunitário, não da inflação. Especificamente, 50% de todas as taxas de gas são distribuídas aos validadores (e seus delegadores) como recompensas. Os outros 50% das taxas são queimados (removidos de circulação) como um mecanismo deflacionário. Essa divisão de taxas (metade para os validadores, metade queimada) se assemelha ao modelo EIP-1559 do Ethereum, exceto que é uma divisão fixa de 50/50 no design atual da Somnia. Na prática, os ganhos dos validadores derivarão do volume de taxas da rede – à medida que o uso cresce, as recompensas de taxas crescem. Para impulsionar a segurança antes que as taxas sejam significativas, a Somnia também tem incentivos do tesouro para os validadores. A alocação da Comunidade inclui tokens destinados a recompensas de staking e liquidez; a fundação pode distribuí-los conforme necessário (provavelmente como suplementos de rendimento de staking nos primeiros anos). Importante, apenas tokens em stake ganham recompensas – isso incentiva a participação ativa e bloqueia o fornecimento. Os delegadores compartilham as recompensas de taxas de seu validador escolhido proporcionalmente ao seu stake, menos a comissão do validador (cada validador define uma “taxa de delegação”, por exemplo, se definida em 80%, então 80% das recompensas desse validador são compartilhadas com os delegados). A Somnia oferece duas opções de delegação: delegar para o pool de um validador específico (sujeito a um período de desvinculação de 28 dias, ou um unstake de emergência imediato com uma penalidade de 50%), ou delegar para um pool geral que distribui automaticamente entre todos os validadores com stake insuficiente (sem período de bloqueio, mas provavelmente um rendimento médio mais baixo). Este design flexível de DPoS incentiva os detentores de tokens a proteger a rede em troca de recompensas, ao mesmo tempo que oferece uma saída fácil (pool geral) para aqueles que desejam liquidez.
• Governança: À medida que a Somnia amadurece, o SOMI governará as decisões da rede. Os detentores de tokens eventualmente votarão em propostas que afetam atualizações de protocolo, uso de fundos do tesouro, parâmetros econômicos, etc. O projeto prevê uma governança multifacetada (veja “Governança de Tokens” abaixo) onde os detentores de SOMI (a “Token House”) controlam principalmente as alocações de fundos da fundação e da comunidade, enquanto validadores, desenvolvedores e usuários têm conselhos para decisões técnicas e de políticas. No início da mainnet, a governança é principalmente tratada pela Fundação Somnia (para agilidade e segurança), mas ao longo de 1 a 2 anos, ela será progressivamente descentralizada para a comunidade de tokens e os conselhos. Assim, deter SOMI conferirá influência sobre a direção do ecossistema, tornando-o um token de governança além de um token de utilidade.

Mecânicas Deflacionárias: Como o fornecimento é fixo, a Somnia depende da queima de taxas para introduzir pressão deflacionária. Como observado, 50% de cada taxa de gas é queimada permanentemente. Isso significa que, se o uso da rede for alto, o fornecimento circulante de SOMI diminuirá com o tempo, potencialmente aumentando a escassez do token. Por exemplo, se 1 milhão de SOMI em taxas forem gerados em um mês, 500 mil SOMI seriam destruídos. Esse mecanismo de queima pode compensar desbloqueios de tokens ou vendas, e alinha o valor do token a longo prazo com o uso da rede (mais atividade -> mais queima). Além disso, a Somnia atualmente não suporta gorjetas especificadas pelo usuário (taxas de prioridade) no lançamento – o modelo de taxa base é eficiente o suficiente dado o alto rendimento, embora possam introduzir gorjetas mais tarde se surgir congestionamento. Com taxas ultrabaixas, a queima por transação é minúscula, mas em escala (bilhões de transações), ela se acumula. O modelo econômico da Somnia, portanto, combina inflação zero, desbloqueios programados e queima de taxas, visando a sustentabilidade a longo prazo. Se a rede atingir um volume mainstream, o SOMI pode se tornar deflacionário, beneficiando stakers e detentores à medida que o fornecimento diminui.

Destaques do Modelo de Gas: O preço do gas da Somnia é geralmente muito mais barato que o do Ethereum, mas com algumas novidades para justiça e escalabilidade. A maioria dos custos de opcode são ajustados para baixo (já que o rendimento e a eficiência da Somnia são maiores), mas os custos de armazenamento foram recalibrados para cima por unidade (para evitar abuso dado o baixo custo por gas). Duas características especialmente notáveis planejadas para 2025 são:

• Descontos Dinâmicos por Volume: A Somnia introduz um desconto de preço de gas em níveis para contas ou aplicações que mantêm um alto uso de TPS. Na prática, quanto mais transações um aplicativo ou usuário executa por hora, menor o preço efetivo do gas que eles pagam (até 90% de desconto a ~400 TPS). Esse preço baseado em volume visa incentivar DApps de grande escala a rodar na Somnia, reduzindo drasticamente seus custos em escala. É implementado como um preço de gas que diminui gradualmente uma vez que certos limiares de TPS por conta são excedidos (0,1, 1, 10, 100, 400 TPS, etc.). Este modelo (esperado para ser lançado após o lançamento da mainnet) recompensa projetos que trazem carga pesada, garantindo que a Somnia permaneça acessível mesmo ao alimentar jogos em tempo real ou feeds sociais com centenas de transações por segundo. É um mecanismo incomum (a maioria das cadeias tem um mercado de taxas fixas), sinalizando a priorização da Somnia para casos de uso de rendimento massivo.
• Armazenamento Transiente: A Somnia planeja oferecer opções de armazenamento com prazo determinado, onde um desenvolvedor pode escolher armazenar dados on-chain apenas temporariamente (por horas ou dias) a um custo de gas muito menor do que o armazenamento permanente. Por exemplo, uma variável on-chain que só precisa persistir por uma hora (como o status de um lobby de jogo ou a posição efêmera de um jogador) pode ser armazenada com ~90% menos gas do que uma escrita permanente normal. A tabela de gas para um SSTORE de 32 bytes pode ser de 20k de gas para retenção de 1 hora contra 200k para retenção indefinida. Este conceito de “estado transiente” é explicitamente voltado para aplicações de jogos e entretenimento que geram muitos dados temporários (tabelas de classificação, estado do jogo) que não precisam viver para sempre on-chain. Ao fornecer um armazenamento baseado em expiração com descontos, a Somnia pode suportar tais aplicações em tempo real de forma mais eficiente. A implementação provavelmente envolve o descarte automático do estado após a duração escolhida (ou movê-lo para um armazenamento separado), embora os detalhes ainda devam ser divulgados. Esta característica, combinada com a compressão da Somnia, é voltada para jogos on-chain que gerenciam grandes volumes de atualizações de estado sem inchar a cadeia ou incorrer em custos enormes.

No geral, a tokenomics da Somnia se alinha com seu objetivo de impulsionar a Web3 na escala da Web2. Um grande pool inicial de tokens financiou o desenvolvimento e o crescimento do ecossistema (com apoiadores respeitáveis e longos períodos de bloqueio sinalizando compromisso), enquanto o design econômico contínuo usa recompensas impulsionadas pelo mercado (via taxas) e deflação para manter o valor. Os detentores de SOMI são incentivados a fazer stake e participar, pois todos os benefícios da rede (receita de taxas, poder de governança) são acumulados pelos stakers ativos. Com um fornecimento limitado e queima proporcional ao uso, o valor do SOMI está fortemente acoplado ao sucesso da rede: à medida que mais usuários e aplicativos se juntam, a demanda por tokens (para gas e staking) aumenta e o fornecimento diminui com as queimas, criando um ciclo de feedback que apoia a sustentabilidade do token a longo prazo.

Ecossistema e Parcerias​

Apesar de ter lançado sua mainnet apenas no final de 2025, a Somnia entrou em cena com um ecossistema robusto de projetos e parceiros estratégicos, graças a uma extensa fase de testnet e ao apoio de pesos pesados da indústria.

dApps e Protocolos do Ecossistema: No lançamento da mainnet, mais de 70 projetos e dApps já estavam construindo ou se integrando com a Somnia. O ecossistema inicial tende fortemente para aplicações de jogos e sociais, refletindo o mercado-alvo da Somnia de aplicativos imersivos e em tempo real. Projetos notáveis incluem:

• Sparkball: Um jogo Web3 de destaque na Somnia, Sparkball é um MOBA/brawler esportivo 4v4 de ritmo acelerado, desenvolvido pela Opti Games. Ele se juntou à Somnia como um título de lançamento, introduzindo jogabilidade on-chain e ativos de equipe baseados em NFT. Sparkball demonstra a capacidade da Somnia de lidar com matchmaking rápido e transações no jogo (por exemplo, mintar/trocar jogadores ou itens) com latência insignificante.
• Variance: Um RPG roguelite com tema de anime, história rica e sem mecânicas pay-to-win. Os desenvolvedores do Variance (veteranos de Pokémon GO e Axie Infinity) escolheram a Somnia por sua capacidade de lidar com economias de jogos em grande escala e transações baratas. Após discussões com o fundador da Somnia, a equipe se convenceu de que a Somnia entendia as necessidades dos desenvolvedores de jogos e a visão para os jogos Web3. Variance moveu seu token no jogo ($VOID) e a lógica de NFT para a Somnia, permitindo recursos como drops de loot on-chain e ativos de propriedade do jogador em escala. A comunidade do jogo cresceu significativamente após anunciar a mudança para a Somnia. Variance realizou playtests e missões comunitárias na testnet da Somnia, demonstrando combate multiplayer on-chain e recompensando jogadores com NFTs e tokens.
• Maelstrom Rise: Um jogo de batalha naval battle-royale (pense em Fortnite no mar) da Uprising Labs. Maelstrom apresenta combate de navios em tempo real e uma economia on-chain integrada para upgrades e colecionáveis. Já disponível off-chain (na Steam), Maelstrom está transicionando para a Somnia para dar aos jogadores a verdadeira propriedade de navios de guerra e itens. É um dos jogos Web3 mais acessíveis, visando integrar jogadores tradicionais ao misturar jogabilidade familiar com vantagens da blockchain.
• Dark Table CCG: Um jogo de cartas colecionáveis on-chain que suporta até 4 jogadores por partida. Oferece construção de baralhos free-to-play, com todas as cartas como NFTs que os jogadores possuem e trocam livremente. Dark Table aproveita a Somnia para executar uma economia de cartas multiplataforma sem servidores centrais, permitindo que os jogadores realmente possuam seus baralhos. Ele é projetado para ser de fácil entrada (não é necessário comprar cripto para começar) para atrair tanto jogadores casuais quanto competitivos de cartas para a Web3.
• Netherak Demons: Um RPG de ação de fantasia sombria apoiado pela aceleradora Dream Catalyst da Somnia. Os jogadores personalizam personagens demoníacos e participam de batalhas PvE e PvP em tempo real, com uma coleção de NFT que se conecta ao progresso do jogo. Netherak usa a tecnologia da Somnia para permitir a progressão persistente de personagens on-chain – as conquistas e o loot dos jogadores são registrados como ativos que eles controlam, adicionando um significado real à jogabilidade.
• Masks of the Void: Um jogo de ação e aventura roguelite com níveis gerados proceduralmente, também apoiado pela Uprising Labs. Ele planejou um playtest fechado onde a mintagem de um NFT gratuito concede acesso antecipado, mostrando como a Somnia pode integrar gating de NFT para conteúdo de jogos. Masks of the Void enfatiza a rejogabilidade e a progressão aprimorada pela blockchain (por exemplo, recompensas de metajogo que persistem entre as partidas como NFTs).

Estes são apenas alguns destaques. O ecossistema de jogos da Somnia abrange muitos gêneros – de shooters navais a jogos de cartas e RPGs – indicando o amplo apelo da plataforma para os desenvolvedores. Todos esses jogos aproveitam recursos on-chain (propriedade de itens, tokens para recompensas, personagens NFT, etc.) que exigem uma cadeia de alto desempenho para serem agradáveis para os jogadores. Os resultados iniciais são promissores: por exemplo, a testnet da Somnia rodou uma demonstração de MMO sandbox totalmente on-chain chamada “Chunked” (construída pela Improbable) onde milhares de jogadores interagiram em tempo real, gerando 250 milhões de transações em 5 dias – uma carga recorde que validou as capacidades da Somnia.

Além dos jogos, o ecossistema inicial da Somnia inclui outros domínios da Web3:

• Social e Metaverso: A Somnia foi projetada para alimentar redes sociais descentralizadas e mundos virtuais, embora aplicativos específicos ainda estejam em estágios iniciais. No entanto, indícios de plataformas sociais estão presentes. Por exemplo, a Somnia fez parceria com a Yuga Labs para integrar NFTs do Otherside (do metaverso do Bored Ape Yacht Club) no mundo da Somnia, permitindo que esses ativos sejam usados em experiências imersivas. Eventos impulsionados pela comunidade, como os “gamevents” Edison de BoredElon Musk, foram realizados com a tecnologia da Improbable em 2023, e a Somnia está pronta para trazer tais eventos metaversais totalmente on-chain no futuro. Há também um aplicativo Navegador do Metaverso Somnia – essencialmente um navegador/carteira Web3 personalizado voltado para a interação em mundos virtuais, facilitando o acesso dos usuários a DApps e experiências de metaverso em uma única interface. À medida que a rede amadurece, espere que dApps sociais (análogos descentralizados do Twitter/Reddit, hubs comunitários) e plataformas de metaverso sejam lançados na Somnia, aproveitando seus recursos de portabilidade de identidade (a Somnia suporta nativamente os padrões abertos da MSquared para interoperabilidade de avatares e ativos entre mundos).
• DeFi e Outros: No lançamento, a Somnia não estava primariamente focada em DeFi, mas alguma infraestrutura está em vigor. Existem integrações com oráculos de preços como o DIA (para feeds de preços on-chain) e o Chainlink VRF via adaptadores Protofire (para aleatoriedade em jogos). Alguns casos de uso no estilo DeFi foram discutidos, como corretoras de livro de ordens totalmente on-chain (a baixa latência da Somnia poderia permitir a correspondência de ordens on-chain de forma semelhante a uma corretora centralizada). Podemos esperar que um AMM ou DEX apareça (a documentação até inclui um guia para construir um DEX na Somnia), e talvez protocolos inovadores que misturam jogos e finanças (por exemplo, empréstimos de NFT ou mercados de ativos de jogos tokenizados). A presença de provedores de custódia como BitGo e Fireblocks como parceiros também indica um foco em apoiar casos de uso institucionais e financeiros (eles tornam a posse de tokens segura para corretoras e fundos). Além disso, a tecnologia da Somnia pode suportar aplicativos de IA e com uso intensivo de dados (o programa Dreamthon explicitamente convoca projetos de IA e InfoFi), então podemos ver inovações como agentes de IA descentralizados ou mercados de dados na cadeia.

Parcerias Estratégicas: A Somnia é apoiada por uma lista impressionante de parceiros e apoiadores:

• Improbable e MSquared: A Improbable – uma empresa líder em tecnologia de metaverso – é a principal parceira de desenvolvimento da Somnia. A Improbable, na verdade, construiu a blockchain Somnia sob contrato para a Fundação Somnia, contribuindo com sua década de experiência em sistemas distribuídos. A MSquared (M²), uma iniciativa de rede de metaverso apoiada pela Improbable, também está intimamente envolvida. Juntas, Improbable e MSquared comprometeram **até US$270 milhões** para apoiar o desenvolvimento e o ecossistema da Somnia. Este enorme pool de investimentos (anunciado no início de 2025) veio em parte da arrecadação de US$ 150 milhões da M² em 2022 (que incluiu Andreessen Horowitz, SoftBank Vision Fund 2, Mirana e outros como investidores) e US$ 120 milhões da alocação de risco da Improbable. O financiamento apoia subsídios, marketing e a integração de projetos. O envolvimento da Improbable também traz integrações técnicas: a Somnia é projetada para funcionar com a tecnologia Morpheus da Improbable para eventos virtuais massivos. Em 2023, a Improbable impulsionou experiências virtuais como o Virtual Ballpark da MLB e shows de K-pop com dezenas de milhares de usuários simultâneos – esses usuários poderiam em breve ser integrados à Somnia para que as interações do evento gerassem ativos ou tokens on-chain. Improbable e MSquared essencialmente garantem que a Somnia tenha tanto a pista financeira quanto casos de uso reais (eventos de metaverso, jogos) para impulsionar a adoção.
• Infraestrutura e Serviços Web3: A Somnia se integrou com muitos dos principais provedores de serviços de blockchain desde o primeiro dia:
  • OpenSea: O maior mercado de NFT do mundo está integrado com a Somnia, o que significa que NFTs baseados na Somnia podem ser negociados na OpenSea. Esta é uma grande vitória para os desenvolvedores de jogos na Somnia – seus NFTs no jogo (personagens, skins, etc.) têm liquidez e visibilidade imediatas em um mercado popular.
  • LayerZero: A Somnia está conectada a outras cadeias através do protocolo Stargate da LayerZero, permitindo transferências de ativos omnichain e pontes. Por exemplo, os usuários podem facilmente fazer a ponte de USDC ou outras stablecoins do Ethereum para a Somnia através do Stargate. Essa interoperabilidade é crucial para trazer liquidez para o ecossistema da Somnia.
  • Ankr: A Ankr fornece nós RPC e infraestrutura de nós global. Provavelmente é usada para oferecer endpoints RPC públicos, hospedagem de nós e serviços de API para a Somnia, facilitando o acesso dos desenvolvedores à rede sem executar seus próprios nós completos.
  • Sequence (Horizon): A Sequence é uma carteira de contrato inteligente e plataforma de desenvolvedor adaptada para jogos (pela Horizon). A integração com a Sequence sugere que a Somnia pode aproveitar recursos de carteira inteligente (por exemplo, abstrações de gas, login com e-mail/social) para integrar usuários mainstream. A carteira multi-chain da Sequence provavelmente adicionou suporte para a Somnia, para que os jogadores possam assinar transações com uma interface amigável.
  • Thirdweb: Os SDKs e ferramentas Web3 da Thirdweb são totalmente compatíveis com a Somnia. A Thirdweb fornece módulos plug-and-play para drops de NFT, mercados, tokens e, especialmente, Abstração de Conta. De fato, a documentação da Somnia tem guias sobre transações sem gas e abstração de conta via Thirdweb. Essa parceria significa que os desenvolvedores na Somnia podem construir DApps rapidamente usando as bibliotecas da Thirdweb e os usuários podem se beneficiar de recursos como integração com um clique sem carteira (taxas de gas patrocinadas pelo DApp, etc.).
  • DIA e Oráculos: A DIA é um provedor de oráculos descentralizado; a Somnia usa feeds de preços da DIA para DeFi ou dados de economia no jogo. Além disso, a Somnia trabalhou com a Protofire para adaptar o Chainlink VRF (função aleatória verificável) para geração de números aleatórios em contratos inteligentes da Somnia. Isso garante que os jogos possam obter aleatoriedade segura (para drops de loot, etc.). Podemos esperar mais integrações de oráculos (talvez feeds de preços completos da Chainlink no futuro) conforme necessário pelos projetos de DeFi.
• Parceiros de Nuvem e Empresariais: O Google Cloud não apenas investiu, mas também opera um validador, fornecendo credibilidade e expertise em infraestrutura de nuvem. Ter a divisão de nuvem de uma gigante da tecnologia validando ativamente a rede ajuda na confiabilidade e abre portas para colaborações empresariais (por exemplo, o Google Cloud pode oferecer serviços de nós de blockchain para a Somnia ou incluir a Somnia em seu mercado). Também houve parcerias com Fireblocks e BitGo – estes são os principais provedores de custódia e carteira de ativos digitais. O envolvimento deles significa que corretoras e instituições podem custodiar com segurança o SOMI e ativos baseados na Somnia desde o primeiro dia, facilitando o caminho para listagens do SOMI e adoção institucional. De fato, logo após a mainnet, a Binance listou o SOMI e o apresentou em uma campanha promocional de airdrop, provavelmente facilitada por essa prontidão de custódia.
• Programas de Crescimento do Ecossistema: A Fundação Somnia estabeleceu um **Programa de Subsídios de US$10 milhões** para financiar desenvolvedores que constroem na Somnia. Este programa de subsídios foi lançado junto com a mainnet para incentivar o desenvolvimento de ferramentas, DApps, pesquisa e iniciativas comunitárias. Complementando-o está o **Dream Catalyst**, a aceleradora da Somnia especificamente para startups de jogos Web3. O Dream Catalyst (gerenciado com a Uprising Labs) fornece financiamento, créditos de infraestrutura, mentoria e suporte de go-to-market para estúdios de jogos que constroem na Somnia. Pelo menos meia dúzia de jogos (como Netherak Demons e outros) fizeram parte da primeira coorte do Dream Catalyst, recebendo porções desse fundo de US$ 10 milhões. Há também o Dreamthon, um programa de aceleração futuro para outros verticais – focando em projetos de DeFi, IA, “InfoFi” (mercados de informação) e SocialFi no ecossistema da Somnia. Além disso, a Somnia organizou hackathons e missões online durante a testnet: por exemplo, um evento Somnia Odyssey de 60 dias recompensou usuários por completarem tarefas e provavelmente culminou em um airdrop. Os primeiros usuários podiam ganhar “pontos” e NFTs por testar dApps (um Programa de Pontos), e mini-hackathons estão planejados para engajar continuamente os desenvolvedores. Essa abordagem multifacetada – subsídios, aceleradoras, hackathons, missões comunitárias – mostra o forte compromisso da Somnia em construir um ecossistema vibrante rapidamente, diminuindo barreiras e financiando experimentadores.

Em resumo, a Somnia não foi lançada isoladamente, mas apoiada por uma poderosa aliança de empresas de tecnologia, investidores e provedores de serviços. O apoio da Improbable lhe dá tecnologia de ponta e um pipeline de eventos virtuais massivos. Parcerias com nomes como Google Cloud, Binance, LayerZero, OpenSea e outros garantem que a Somnia esteja conectada à infraestrutura cripto mais ampla desde o início, aumentando seu apelo para desenvolvedores (que querem ferramentas confiáveis e liquidez) e para usuários (que exigem pontes e negociação de ativos fáceis). Enquanto isso, uma variedade de jogos Web3 – Sparkball, Variance, Maelstrom e mais – estão construindo ativamente na Somnia, com o objetivo de serem a primeira onda de entretenimento totalmente on-chain que demonstra as capacidades da rede. Com dezenas de projetos ao vivo ou em desenvolvimento, o ecossistema da Somnia na mainnet já era mais rico do que algumas cadeias com anos de lançamento. Esse forte impulso provavelmente crescerá à medida que os subsídios e parcerias continuarem a dar frutos, potencialmente posicionando a Somnia como um hub central para jogos on-chain e aplicações de metaverso nos próximos anos.

Infraestrutura para Desenvolvedores e Usuários​

A Somnia foi construída para ser amigável ao desenvolvedor e para integrar potencialmente milhões de usuários que podem não ser experientes em cripto. Como uma cadeia compatível com EVM, ela suporta o familiar conjunto de ferramentas do Ethereum desde o início, ao mesmo tempo que oferece SDKs e serviços personalizados para aprimorar a experiência do desenvolvedor e a integração do usuário.

Ferramentas e Compatibilidade para Desenvolvedores: A Somnia mantém compatibilidade total com a Ethereum Virtual Machine, o que significa que os desenvolvedores podem escrever contratos inteligentes em Solidity ou Vyper e implantá-los com alterações mínimas. A rede suporta interfaces RPC padrão do Ethereum e ID de cadeia, então ferramentas como Hardhat, Truffle, Foundry e bibliotecas como Web3.js ou ethers.js funcionam perfeitamente (a documentação da Somnia até fornece guias específicos para implantação com Hardhat e Foundry). Isso reduz significativamente a curva de aprendizado – qualquer desenvolvedor Solidity pode se tornar um desenvolvedor Somnia sem aprender uma nova linguagem ou VM.

Para acelerar o desenvolvimento e os testes, a Somnia lançou um ambiente interativo de Playground. O Playground permite que as equipes (especialmente equipes de jogos/metaverso) prototipem a lógica on-chain de uma maneira de baixo atrito, usando modelos para NFTs, minijogos, tokens sociais, etc. Ele provavelmente fornece uma rede sandbox ou um portal de desenvolvedor para iterações rápidas. Além disso, a documentação GitBook da Somnia é abrangente, cobrindo tudo, desde a implantação de contratos até o uso de recursos avançados (como as APIs da Ormi, veja abaixo).

SDKs e APIs da Somnia: Reconhecendo que consultar dados on-chain de forma eficiente é tão importante quanto escrever contratos, a Somnia fez parceria com a Ormi Labs para fornecer serviços robustos de indexação de dados e API. A Ormi é essencialmente a resposta da Somnia ao The Graph: ela oferece subgraphs e APIs GraphQL para indexar eventos e estado de contratos. Os desenvolvedores podem criar subgraphs personalizados para seus DApps (por exemplo, para indexar todos os NFTs de itens de jogo ou postagens sociais) via Ormi, e então consultar esses dados facilmente. As APIs de Dados da Ormi entregam dados on-chain estruturados com alta disponibilidade, para que as aplicações de front-end não precisem executar seus próprios nós de indexação. Isso simplifica significativamente a construção de interfaces de usuário ricas na Somnia. A Somnia realizou Codelabs e tutoriais mostrando como construir UIs de dApps com os endpoints GraphQL da Ormi, indicando um forte suporte para essa ferramenta. Em resumo, a Somnia fornece suporte de primeira classe para indexação, o que é crucial para coisas como tabelas de classificação em jogos ou feeds em aplicativos sociais – dados que precisam ser filtrados e buscados rapidamente.

Além da Ormi, a página de infraestrutura da Somnia lista múltiplos endpoints RPC públicos e serviços de explorador:

• Endpoints RPC de provedores como Ankr (para acesso público à rede).
• Exploradores de Blocos: Parece que a Somnia tinha um explorador de testnet (“Shannon”) e presumivelmente um explorador de mainnet para rastrear transações e contas. Exploradores são vitais para desenvolvedores e usuários depurarem transações e verificarem a atividade on-chain.
• Safes (Multisig): A documentação menciona “Safes”, provavelmente uma integração com o Safe (anteriormente Gnosis Safe) para carteiras multi-assinatura. Isso significa que DAOs ou estúdios de jogos na Somnia podem usar carteiras multisig seguras para gerenciar seu tesouro ou ativos no jogo. A integração com o Safe é outra peça de infraestrutura que torna a Somnia pronta para empresas e DAOs.
• Adaptadores de Carteira: Muitas carteiras Web3 populares são suportadas. A MetaMask pode se conectar à Somnia configurando o RPC da rede (a documentação guia os usuários na adição da rede da Somnia à MetaMask). Para uma experiência de usuário mais fluida, a Somnia trabalhou com RainbowKit e ConnectKit (bibliotecas React para conexões de carteira), garantindo que os desenvolvedores de DApps possam facilmente permitir que os usuários se conectem com uma variedade de carteiras. Há também um guia para usar o Privy (uma solução de carteira focada em login amigável).
• Abstração de Conta: Através do SDK da Thirdweb, a Somnia suporta recursos de abstração de conta. Por exemplo, a Smart Wallet ou o SDK de Abstração de Conta da Thirdweb podem ser usados na Somnia, permitindo meta-transações (UX sem gas) ou carteiras com login social. A documentação descreve explicitamente transações sem gas com a Thirdweb, o que significa que os DApps podem pagar o gas em nome dos usuários – uma capacidade crítica para a adoção mainstream, já que os usuários finais podem nem precisar ter SOMI para jogar um jogo inicialmente.

Integração de Usuários e Engajamento da Comunidade: A equipe da Somnia tem sido proativa no crescimento de uma comunidade de desenvolvedores e usuários finais:

• O Discord da Somnia é o hub central para desenvolvedores (com um chat dedicado para desenvolvedores e suporte da equipe principal). Durante a testnet, os desenvolvedores podiam solicitar tokens de teste (STT) via Discord para implantar e testar seus contratos. Este canal de suporte direto ajudou a integrar muitos projetos.
• Para os usuários finais, a Somnia organizou eventos como a Somnia Quest e a Somnia Odyssey. A Quest foi uma campanha em junho de 2025 onde os usuários completavam tarefas sociais e na testnet (como seguir no X, entrar no Discord, experimentar DApps) para ganhar recompensas e subir em uma tabela de classificação. A Odyssey (mencionada em um blog em 9 de setembro de 2025) foi uma aventura de 60 dias que provavelmente levou à mainnet, onde usuários que interagiram consistentemente com aplicativos da testnet ou aprenderam sobre a Somnia poderiam desbloquear um airdrop. De fato, o HODLer Airdrop da Binance em 1º de setembro de 2025 distribuiu 30 milhões de SOMI (3% do fornecimento) para usuários da Binance que atendiam a certos critérios. Este foi um grande evento de aquisição de usuários, efetivamente dando a milhares de usuários de cripto uma participação na Somnia e um incentivo para experimentar a rede. O airdrop e várias missões ajudaram a Somnia a construir uma base de usuários inicial e presença nas redes sociais (o Twitter da Somnia – agora X – e outros canais cresceram rapidamente).
• Navegador do Metaverso: Como mencionado, a Somnia introduziu um aplicativo especializado de Navegador do Metaverso. Isso provavelmente serve como um portal amigável onde alguém pode criar uma carteira, navegar pelos DApps da Somnia e entrar em eventos virtuais sem problemas. Ele tem uma carteira Web3 integrada e uma interface simples para acessar DApps. Esse tipo de experiência curada poderia facilitar a entrada de usuários não-cripto na blockchain (por exemplo, um jogador poderia baixar o navegador Somnia e participar de um show virtual onde o navegador lida com a criação da carteira e as transações de tokens nos bastidores).
• Programas de Aceleração para Desenvolvedores: Cobrimos o Dream Catalyst e o Dreamthon na seção de ecossistema, mas do ponto de vista da infraestrutura para desenvolvedores, esses programas também garantem que novos desenvolvedores tenham orientação e recursos. O Dream Catalyst forneceu não apenas financiamento, mas também ferramentas de infraestrutura e suporte para construção de comunidade. Isso significa que as equipes participantes provavelmente receberam ajuda com a integração dos SDKs da Somnia, otimizando seus contratos para a arquitetura da Somnia, etc.

Em termos de documentação e recursos:

• A Somnia oferece um Lightpaper e um OnePager para visões gerais rápidas (linkados em seu site), e um Litepaper/whitepaper mais detalhado na documentação (a seção de Conceitos que referenciamos serve a esse propósito).
• Eles têm repositórios de exemplo e modelos de código (por exemplo, como construir um DEX, como usar Subgraphs, como integrar carteiras – tudo fornecido em seu GitBook oficial). Ao fornecer isso, a Somnia diminui a barreira de entrada para desenvolvedores de outras cadeias que desejam rapidamente colocar algo em funcionamento.
• Auditorias: A documentação menciona uma seção de Auditorias, implicando que o código da Somnia passou por auditorias de segurança de terceiros. Embora os detalhes não sejam fornecidos em nossas fontes, esta é uma infraestrutura importante – garantir que o software do nó e os contratos principais (como os contratos de staking ou de token) sejam auditados para proteger desenvolvedores e usuários.

No geral, a infraestrutura para desenvolvedores da Somnia parece bem pensada: compatibilidade com EVM para familiaridade, aprimorada com APIs de dados personalizadas, abstração de conta integrada e forte suporte ao desenvolvedor. Para os usuários, a combinação de taxas ultrabaixas, possíveis transações sem gas e aplicações especializadas (Navegador do Metaverso, missões, etc.) visa fornecer uma experiência de usuário de nível Web2 em uma plataforma Web3. O foco inicial da Somnia no engajamento da comunidade (airdrops, missões) mostra uma mentalidade de growth-hacking – semeando a rede com conteúdo e usuários para que os desenvolvedores tenham um motivo para construir, e vice-versa. À medida que a Somnia cresce, podemos esperar SDKs ainda mais refinados (talvez plugins para Unity/Unreal para desenvolvedores de jogos) e melhorias contínuas nas carteiras de usuário (talvez carteiras móveis nativas ou logins sociais). O financiamento substancial da fundação garante que tanto desenvolvedores quanto usuários serão apoiados com as ferramentas de que precisam para prosperar na Somnia.

Casos de Uso e Aplicações​

A Somnia foi construída especificamente para permitir uma nova classe de aplicações descentralizadas que antes eram inviáveis devido às limitações da blockchain. Seu alto rendimento e baixa latência abrem as portas para experiências totalmente on-chain e em tempo real em vários domínios:

• Jogos (GameFi): Este é o foco principal da Somnia. Com a Somnia, os desenvolvedores podem construir jogos onde cada ação do jogo (movimento, combate, drops de itens, trocas) pode ser registrada ou executada on-chain em tempo real. Isso significa propriedade verdadeira dos ativos do jogo – os jogadores mantêm seus personagens, skins, cartas ou loot como NFTs/tokens em suas próprias carteiras, não no banco de dados de uma empresa de jogos. Economias de jogos inteiras podem funcionar on-chain, permitindo recursos como recompensas play-to-earn, negociação entre jogadores sem intermediários e modificações de jogos impulsionadas pela comunidade. Crucialmente, a capacidade da Somnia (1M+ TPS) e a finalidade rápida tornam os jogos on-chain responsivos. Por exemplo, um RPG de ação na Somnia pode executar milhares de ações de jogadores por segundo sem lag, ou um jogo de cartas colecionáveis pode ter movimentos e embaralhamentos instantâneos on-chain. A abstração de conta e as taxas baixas da Somnia também permitem que os jogos potencialmente cubram o gas para os jogadores, tornando a experiência transparente (os jogadores podem nem perceber que a blockchain está por trás). A plataforma prevê especificamente “jogos totalmente on-chain em escala de internet” – mundos virtuais persistentes ou MMOs onde o estado do jogo vive na Somnia e continua enquanto a comunidade o mantiver vivo. Como os ativos estão on-chain, um jogo na Somnia poderia até continuar evoluindo sob o controle da comunidade se o desenvolvedor original sair – um conceito impossível na Web2. Exemplos atuais: Sparkball demonstra um brawler esportivo multiplayer on-chain; Chunked (a demonstração de tecnologia da Improbable) mostrou um sandbox semelhante ao Minecraft totalmente on-chain com interações reais de usuários; Variance e Maelstrom mostrarão como experiências mais ricas de RPG e battle royale se traduzem para a blockchain. A promessa final são jogos onde centenas de milhares de jogadores jogam simultaneamente em um mundo on-chain compartilhado – algo que a Somnia está posicionada de forma única para lidar.
• Redes Sociais e Mídia Social Web3: Com a Somnia, seria possível construir uma plataforma social descentralizada onde perfis de usuários, postagens, seguidores e curtidas são todos dados on-chain sob o controle do usuário. Por exemplo, um DApp semelhante ao Twitter na Somnia poderia armazenar cada tweet como um NFT de mensagem on-chain e cada seguidor como um relacionamento on-chain. Em tal rede, os usuários realmente possuem seu conteúdo e grafo social, que poderiam ser portados para outros aplicativos facilmente. A escala da Somnia significa que um feed social poderia lidar com a atividade viral (milhões de postagens e comentários) sem travar. E a finalidade em menos de um segundo significa que as interações (postar, comentar) aparecem quase instantaneamente, como os usuários esperam na Web2. Um benefício do social on-chain é a resistência à censura – nenhuma empresa pode deletar seu conteúdo ou banir sua conta – e a portabilidade de dados – você poderia se mudar para um frontend ou cliente diferente e manter seus seguidores/conteúdo porque está em um registro público. A equipe da Somnia menciona explicitamente redes sociais descentralizadas construídas sobre identidade auto-soberana e grafos sociais portáteis como um caso de uso principal. Eles também preveem governança de assembleia de usuários onde usuários-chave têm voz (isso poderia se relacionar com como as redes sociais moderam o conteúdo de forma descentralizada). Um exemplo inicial concreto são provavelmente fóruns comunitários dentro de jogos – por exemplo, um jogo na Somnia pode ter um chat de guilda on-chain ou um quadro de eventos que é descentralizado. Mas a longo prazo, a Somnia poderia hospedar alternativas completas ao Facebook ou Twitter, especialmente para comunidades que valorizam a liberdade e a propriedade. Outro ângulo interessante são as plataformas de propriedade de criadores: imagine um serviço semelhante ao YouTube na Somnia onde NFTs de vídeo representam o conteúdo e os criadores ganham diretamente via microtransações ou engajamento tokenizado. O rendimento da Somnia poderia lidar com os metadados e interações (embora o armazenamento de vídeo fosse off-chain), e suas transações baratas permitem micro-gorjetas e recompensas em tokens pela criação de conteúdo.
• Metaverso e Mundos Virtuais: A Somnia fornece a infraestrutura de identidade e econômica para metaversos. Na prática, isso significa que as plataformas de mundos virtuais podem usar a Somnia para identidades de avatares, ativos entre mundos e transações dentro de experiências virtuais. Os padrões abertos da MSquared para avatares/ativos são suportados na Somnia, então o avatar 3D de um usuário ou itens de moda digital podem ser representados como tokens na Somnia e portados entre diferentes mundos. Por exemplo, você pode ter um único NFT de avatar que usa em um show virtual, um encontro esportivo e um jogo – tudo em plataformas baseadas na Somnia. À medida que a Improbable orquestra eventos massivos (como festas virtuais para assistir a esportes, festivais de música, etc.), a Somnia pode lidar com a camada econômica: mintar POAPs (tokens de prova de participação), vender mercadorias virtuais como NFTs, recompensar participantes com tokens e permitir negociações peer-to-peer em tempo real durante os eventos. A capacidade da Somnia de suportar dezenas de milhares de usuários simultâneos em um estado compartilhado (através do consenso multi-stream) é crucial para cenários de metaverso onde uma grande multidão pode transacionar ou interagir simultaneamente. O MLB Virtual Ballpark e os eventos de K-pop em 2023 (pré-Somnia) alcançaram milhares de usuários; com a Somnia, esses usuários poderiam ter carteiras e ativos, permitindo coisas como um drop de NFT ao vivo para todos no “estádio” ou um placar de tokens em tempo real para participação no evento. Essencialmente, a Somnia pode sustentar uma economia de metaverso persistente e interoperável: pense nela como o livro-razão que registra quem possui o quê em muitos mundos virtuais interconectados. Isso suporta casos de uso como imóveis virtuais (NFTs de terrenos) que podem ser negociados ou usados como garantia, recompensas de missões entre mundos (complete um objetivo no jogo A, ganhe um item utilizável no mundo B), ou até mesmo reputação de identidade (registros on-chain das conquistas ou credenciais de um usuário em várias plataformas).
• Finanças Descentralizadas (DeFi): Embora a Somnia seja posicionada principalmente como uma cadeia de aplicativos para o consumidor, seu alto desempenho abre algumas possibilidades intrigantes de DeFi. Por um lado, a Somnia pode hospedar negociações de alta frequência e instrumentos financeiros complexos on-chain. A equipe menciona especificamente livros de ordens de limite totalmente on-chain. No Ethereum, as corretoras de livro de ordens são impraticáveis (muito lentas/caras), e é por isso que o DeFi usa AMMs. Mas na Somnia, um DEX poderia manter um contrato inteligente de livro de ordens e combinar ordens em tempo real, assim como uma corretora centralizada, porque a cadeia pode lidar com milhares de operações por segundo. Isso poderia trazer funcionalidade e liquidez semelhantes às de CEXs para a on-chain com transparência e auto-custódia. Outra área é a gestão de risco em tempo real: a velocidade da Somnia poderia permitir derivativos on-chain que atualizam os requisitos de margem a cada segundo, ou livros de ordens de opções ao vivo. Além disso, com seu recurso de armazenamento transiente, a Somnia poderia suportar coisas como contratos de seguro efêmeros ou pagamentos de streaming que existem apenas por um curto período. Protocolos DeFi na Somnia também podem aproveitar seu gas determinístico para custos mais previsíveis. Por exemplo, uma plataforma de micro-empréstimos na Somnia poderia processar transações minúsculas (como pagamentos de juros de US$ 0,01 a cada minuto) porque as taxas são frações de centavo. Assim, a Somnia poderia impulsionar microtransações e fluxos de pagamento Web3 em DeFi e além (algo que o Ethereum não pode fazer economicamente em escala). Adicionalmente, a capacidade da Somnia de comprimir dados e agregar assinaturas pode permitir o agrupamento de milhares de transferências ou negociações em um bloco, aumentando ainda mais o rendimento para casos de uso de DeFi como airdrops ou pagamentos em massa. Embora o DeFi não seja o foco de marketing, um ecossistema financeiro eficiente provavelmente surgirá na Somnia para apoiar os jogos e metaversos (por exemplo, DEXes para tokens de jogos, mercados de empréstimo para NFTs, etc.). Podemos ver protocolos especializados, por exemplo, uma corretora de fracionamento de NFT onde itens de jogos podem ser negociados fracionalmente – a Somnia pode lidar com a demanda explosiva se um item popular de repente disparar.
• Identidade e Credenciais: A combinação de identidade auto-soberana e alta capacidade da Somnia permite sistemas de identidade on-chain que poderiam ser usados para autenticação, reputação e credenciais na Web3. Por exemplo, um usuário poderia ter um NFT de identidade ou um token soulbound na Somnia que atesta suas conquistas (como “completou X missões de jogo” ou “participou de Y eventos” ou até mesmo credenciais off-chain como diplomas ou associações). Estes poderiam ser usados em múltiplas aplicações. O grafo social portável de um usuário – quem são seus amigos, a quais comunidades eles pertencem – pode ser armazenado na Somnia e levado de um jogo ou plataforma social para outro. Isso é poderoso para quebrar os silos da Web2: imagine trocar de aplicativo social, mas manter seus seguidores, ou um perfil de jogador que carrega seu histórico para novos jogos (talvez ganhando vantagens de veterano). Com o modelo de governança da Somnia incorporando uma Assembleia de Usuários (usuários-chave fornecendo supervisão), também poderíamos ver uma governança baseada em identidade onde usuários com participação comprovada têm mais voz em certas decisões (tudo aplicável on-chain através dessas credenciais). Outro caso de uso são as economias de criadores de conteúdo – um criador poderia emitir seu próprio token ou série de NFT na Somnia para sua base de fãs, e estes poderiam desbloquear acesso em várias plataformas (vídeos, chats, eventos virtuais). Como a Somnia pode lidar com grandes volumes, um criador popular com milhões de fãs poderia fazer um airdrop de emblemas para todos eles ou lidar com micro-gorjetas em tempo real durante uma transmissão ao vivo.
• Serviços Web em Tempo Real: De forma geral, a Somnia pode atuar como um backend descentralizado para serviços que exigem respostas instantâneas. Considere um aplicativo de mensagens descentralizado onde as mensagens são eventos on-chain – com finalidade em menos de um segundo, dois usuários poderiam conversar via Somnia e ver as mensagens aparecerem quase instantaneamente e de forma imutável (talvez com criptografia no conteúdo, mas com carimbos de data/hora e provas on-chain). Ou um mercado online onde pedidos e listagens são contratos inteligentes – a Somnia poderia atualizar o inventário e as vendas em tempo real, prevenindo o gasto duplo de itens e permitindo trocas atômicas de bens por pagamento. Até mesmo plataformas de streaming poderiam integrar a blockchain para gerenciamento de direitos: por exemplo, um serviço de streaming de música na Somnia poderia gerenciar contagens de reprodução de músicas e micropagamentos de licença para artistas a cada poucos segundos de reprodução (porque pode lidar com transações pequenas de alta frequência). Em essência, a Somnia permite interatividade de nível Web2 com a confiança e propriedade da Web3. Qualquer aplicação onde muitos usuários interagem simultaneamente (leilões, ferramentas de colaboração multiplayer, feeds de dados ao vivo) poderia ser descentralizada na Somnia sem sacrificar o desempenho.

Status Atual dos Casos de Uso: No final de 2025, os casos de uso mais tangíveis ao vivo na Somnia giram em torno de jogos e colecionáveis – vários jogos estão em fase de teste ou acesso antecipado na mainnet, e coleções de NFT (avatares, ativos de jogos) estão sendo mintadas na Somnia. A rede facilitou com sucesso grandes eventos de teste (bilhões de transações na testnet, demonstrações em larga escala), provando que esses casos de uso não são apenas teóricos. O próximo passo é converter esses testes em aplicações contínuas ao vivo com usuários reais. Adotantes iniciais como Sparkball e Variance serão testes de fogo importantes: se eles conseguirem atrair milhares de jogadores diários na Somnia, veremos a cadeia realmente mostrar sua força e talvez atrair ainda mais desenvolvedores de jogos.

Aplicações futuras potenciais são empolgantes de se considerar. Por exemplo, projetos de escala nacional ou empresarial: um governo poderia usar a Somnia para emitir uma identidade digital ou realizar uma eleição on-chain (milhões de votos em segundos, com transparência), ou uma bolsa de valores poderia usá-la para negociar títulos tokenizados em alta frequência. A parte de InfoFi mencionada para o Dreamthon sugere coisas como um Reddit descentralizado ou mercados de previsão (número massivo de pequenas apostas e votos) que a Somnia poderia impulsionar.

Em resumo, os casos de uso da Somnia abrangem jogos, social, metaverso, DeFi, identidade e além, todos ligados por um fio comum: transações em tempo real, em escala massiva, com total confiança on-chain. Ela visa trazer experiências geralmente reservadas para servidores centralizados para o reino descentralizado. Se o Ethereum foi pioneiro nas finanças descentralizadas, a ambição da Somnia é ser pioneira na vida descentralizada – do entretenimento às conexões sociais – finalmente entregando o desempenho necessário para aplicativos de estilo mainstream. À medida que a rede amadurece, provavelmente veremos novas inovações que aproveitam suas características únicas (por exemplo, jogos usando estado transiente para simulações de física, ou aplicativos sociais usando compressão de streaming para lidar com milhões de pequenas ações). O próximo ano ou dois revelará quais dessas aplicações potenciais ganham tração e provam a promessa da Somnia na prática.

Cenário Competitivo​

A Somnia entra em uma arena de Layer-1 lotada, mas se diferencia com seu rendimento extremo e foco em aplicações de consumo totalmente on-chain. Veja como a Somnia se compara a algumas outras blockchains L1 proeminentes:

Em essência, os análogos mais próximos da Somnia são Solana, Sui/Aptos e talvez app-chains especializadas como certas subnets da Avalanche ou as futuras cadeias de alto desempenho da Polygon. Como a Solana, a Somnia abre mão da descentralização extrema em favor do desempenho, mas a Somnia se diferencia por manter a EVM (ajudando-a a se apoiar na base de desenvolvedores do Ethereum) e por introduzir um consenso multi-chain único, em vez de um líder por vez. A abordagem de paralelismo da Solana (múltiplos threads de GPU processando diferentes transações) contrasta com a abordagem da Somnia (múltiplos validadores, cada um processando diferentes fluxos). Durante cargas correlacionadas (um contrato popular), a otimização de núcleo único da Somnia se destaca, enquanto o paralelismo da Solana seria limitado, já que todos os threads competem pelo mesmo estado.

Comparada à mainnet do Ethereum, a Somnia é ordens de magnitude mais rápida, mas sacrifica a descentralização (100 validadores contra centenas de milhares do Ethereum). O Ethereum também tem um ecossistema muito maior e testado em batalha. No entanto, o Ethereum não pode lidar diretamente com jogos ou aplicativos sociais em escala – eles acabam em L2s ou sidechains. A Somnia essencialmente se posiciona como uma alternativa a um rollup do Ethereum, uma que é sua própria L1 com desempenho superior a qualquer rollup atual e sem a necessidade de provas de fraude ou suposições de segurança separadas (além de seu conjunto menor de validadores). A longo prazo, o roteiro do Ethereum (sharding, danksharding, etc.) aumentará o rendimento, mas provavelmente não para milhões de TPS na L1. Em vez disso, o Ethereum aposta em rollups; a Somnia aposta em escalar a própria L1 com engenharia avançada. Eles podem não competir pelos mesmos casos de uso inicialmente (DeFi pode permanecer no Ethereum/L2, enquanto jogos vão para a Somnia ou cadeias semelhantes). A interoperabilidade (via LayerZero ou outros) pode permitir que eles se complementem, com ativos se movendo entre Ethereum e Somnia conforme necessário.

A Avalanche oferece subnets que, como a Somnia, podem ser dedicadas a jogos com alto rendimento. A diferença é que cada subnet da Avalanche é uma instância separada (você precisaria criar seus próprios validadores ou recrutar alguns validadores para se juntarem a ela). A Somnia, em vez disso, fornece uma cadeia de alta capacidade compartilhada, o que torna a interoperabilidade entre aplicativos mais fácil (todos os aplicativos da Somnia vivem em uma cadeia, componíveis, como no Ethereum ou Solana). A subnet principal da Avalanche (C-Chain) é EVM, mas muito mais lenta que a Somnia. Portanto, a Somnia supera a cadeia comum da Avalanche de longe, embora a Avalanche possa escalar se um projeto criar uma subnet personalizada (mas então essa subnet pode não ter a componibilidade geral completa ou a base de usuários). Para um desenvolvedor, implantar na Somnia pode ser mais simples do que gerenciar uma subnet da Avalanche, e você imediatamente aproveita o pool de usuários e a liquidez compartilhados da Somnia.

Sui (e Aptos) são frequentemente citados como cadeias de alto TPS de próxima geração, usando Move e consenso paralelo. A vantagem da Somnia sobre a Sui é o rendimento (a Sui não demonstrou milhões de TPS; seu design está talvez na casa das centenas de milhares, na melhor das hipóteses) e a compatibilidade com EVM. A vantagem da Sui pode ser a segurança do Move para lógica de ativos complexa e possivelmente um roteiro mais descentralizado (embora no lançamento a Sui também tivesse cerca de 100 validadores). Se a Somnia capturar os estúdios de jogos que preferem usar Solidity (talvez portando contratos Solidity de protótipos de jogos do Ethereum), ela poderia superar a Sui em ecossistema rapidamente, dada a dimensão da comunidade de desenvolvedores Solidity.

A Somnia também se compara à Solana ao visar a Web3 de consumo (ambas enfatizaram integrações sociais e de telefone – a Solana teve um telefone Saga, a Somnia um navegador, etc.). A ousada afirmação de Herman Narula de que a Somnia pode ter “milhares de vezes o rendimento da Solana” define o tom de que a Somnia se vê não apenas como outra cadeia rápida, mas como a cadeia EVM mais rápida, onde a Solana é a cadeia não-EVM mais rápida. Se a Somnia entregar na prática um TPS sustentado mesmo que uma ordem de magnitude melhor que a Solana (digamos que a Solana faça 5k TPS em média e a Somnia possa fazer 50k ou mais em média com picos na casa dos milhões), ela genuinamente criará um nicho para aplicações que nem mesmo a Solana pode lidar (por exemplo, um jogo blockchain na escala do Fortnite ou uma rede social de escala global).

Outro concorrente a ser notado é o Polygon 2.0 ou zkEVMs – embora não sejam L1s, eles oferecem escalonamento para EVM. A Polygon está trabalhando em uma série de ZK-rollups e cadeias de alto desempenho. Estes poderiam potencialmente igualar parte do desempenho da Somnia enquanto se beneficiam da segurança do Ethereum. No entanto, ZK-rollups com 1M de TPS ainda não existem e, mesmo assim, podem enfrentar limites de disponibilidade de dados. A abordagem da Somnia é uma solução tudo-em-um com sua própria segurança. Ela terá que provar que sua segurança (100 validadores PoS) é robusta o suficiente para aplicações de grande valor, algo que os rollups do Ethereum herdam inerentemente do ETH. Mas para jogos e social, onde os requisitos de segurança são ligeiramente diferentes (roubar um NFT de espada de jogo não é tão catastrófico quanto roubar bilhões em TVL de DeFi), o trade-off da Somnia pode ser perfeitamente aceitável e até preferível devido à experiência do usuário.

Em conclusão, a Somnia se destaca por levar o envelope de desempenho mais longe do que qualquer L1 de propósito geral atual, mantendo a familiaridade da EVM. Ela visa ocupar um espaço no mercado para a “Web3 na escala da Web2” que outros abordaram apenas parcialmente:

• O Ethereum dominará a confiança e o DeFi, mas delegará tarefas de alta frequência para L2 (que adicionam complexidade e fragmentação).
• A Solana mostrou alto TPS para DeFi e NFTs, mas não é EVM e teve problemas de estabilidade; a Somnia poderia atrair projetos que querem velocidade semelhante à da Solana com as ferramentas do Ethereum.
• A Avalanche oferece personalização e conforto EVM, mas não demonstrou um desempenho de cadeia única próximo ao da Somnia.
• Sui/Aptos estão na mesma geração da Somnia, competindo por desenvolvedores de jogos, mas as parcerias iniciais da Somnia (Improbable, grandes marcas) e a compatibilidade com EVM lhe dão uma forte vantagem se bem executada.

Como Narula disse, a Somnia é indiscutivelmente a primeira cadeia construída especificamente para experiências virtuais em tempo real em escala massiva. Se essas experiências (jogos, eventos, mundos sociais) se tornarem a próxima grande onda de adoção de blockchain, a concorrência da Somnia pode ser tanto a infraestrutura de nuvem tradicional (AWS, etc.) quanto outras blockchains – porque ela está tentando substituir servidores de jogos centralizados e bancos de dados sociais, não apenas competir por aplicativos de blockchain existentes. Nessa luz, o sucesso da Somnia será medido por sua capacidade de hospedar aplicações que atraem milhões de usuários que talvez nem saibam (ou se importem) que uma blockchain está rodando por baixo. Nenhuma L1 atual alcançou esse nível de aplicativo de usuário mainstream (mesmo os maiores aplicativos da Solana têm centenas de milhares, não milhões de usuários ativos). Essa é a meta que a Somnia estabeleceu para si mesma, e contra a qual sua arquitetura inovadora será testada nos próximos anos.

Roteiro e Status Atual​

A jornada da Somnia progrediu rapidamente do conceito à realidade em pouco tempo, e continua a evoluir pós-mainnet com metas claras:

Desenvolvimentos Recentes (2024–2025):

• Financiamento e Testnet (2024): O projeto surgiu do modo furtivo apoiado por um financiamento significativo. No início de 2024, a Improbable anunciou o compromisso de US$ 270 milhões para o ecossistema da Somnia e da MSquared. Isso proporcionou uma enorme pista de decolagem. A Somnia executou uma Devnet no final de 2024 (novembro), onde quebrou recordes: alcançando 1,05 milhão de TPS e outros benchmarks em uma configuração global de 100 nós. Esses resultados (incluindo 50k trocas Uniswap/seg, 300k mintagens de NFT/seg) foram divulgados para construir credibilidade. Após a Devnet, uma Testnet totalmente pública foi lançada em 20 de fevereiro de 2025. A testnet (codinome Shannon) funcionou por cerca de 6 meses. Durante esse tempo, a Somnia afirma ter processado mais de 10 bilhões de transações e integrado 118 milhões de endereços de carteira de teste – números impressionantes. Esses números provavelmente incluem testes de carga roteirizados e participação da comunidade. A testnet também viu um pico de rendimento diário de 1,9 bilhão de transações em um dia (um recorde para qualquer contexto EVM). A CoinDesk notou esses números, mas também que o explorador público estava offline no momento para verificação, implicando que algumas dessas eram métricas internas. No entanto, a testnet demonstrou estabilidade sob uma carga sem precedentes.

  Ao longo da testnet, a Somnia executou programas de engajamento: um programa de incentivo de Pontos onde os primeiros usuários que completavam tarefas podiam ganhar pontos (provavelmente conversíveis em futuros tokens ou recompensas), e colaborou com parceiros (desenvolvedores de jogos fizeram playtests, hackathons foram realizados). A fase de testnet também foi quando mais de 70 parceiros/projetos do ecossistema foram integrados. Isso indica que, na mainnet, muitas integrações e aplicativos estavam prontos ou quase prontos.

• Lançamento da Mainnet (3º trimestre de 2025): A Somnia lançou a mainnet em 2 de setembro de 2025. O lançamento incluiu a liberação do token SOMI e a habilitação do staking. Notavelmente, na mainnet:

  • 60 validadores entraram online (com grandes nomes como o Google Cloud entre eles).
  • A Fundação Somnia está operacional, supervisionando a cadeia como uma administradora neutra. A Improbable entregou a tecnologia e agora a Fundação (também referida como Fundação da Sociedade Virtual) está encarregada da governança e do desenvolvimento futuro.
  • Listagem e distribuição do SOMI: Um dia após o lançamento, a Binance revelou o SOMI como parte de suas listagens “Seed Tag” e realizou o airdrop HODLer. Isso foi um grande impulso – efetivamente um endosso de uma corretora de ponta. Muitas novas L1s lutam para conseguir tração em corretoras, mas a Somnia imediatamente colocou o SOMI nas mãos dos usuários via Binance.
  • Nas redes sociais, a equipe da Somnia e seus parceiros divulgaram as capacidades da mainnet. Um comunicado de imprensa da Improbable e a cobertura em veículos como CoinDesk, Yahoo Finance, etc., espalharam a notícia de que “a cadeia EVM mais rápida” está ao vivo.
  • dApps iniciais do ecossistema começaram a ser implantadas. Por exemplo, a ponte de NFT via LayerZero estava ativa (era possível fazer a ponte de stablecoins conforme a documentação), e alguns dos jogos da testnet começaram a migrar para a mainnet (lançamento do Sparkball, etc., por volta de setembro, conforme indicado por blogs e atualizações).
  • Eventos de airdrop da comunidade (a Somnia Odyssey) provavelmente culminaram por volta do lançamento, distribuindo parte da alocação de tokens da Comunidade para os primeiros apoiadores.

Em resumo, o lançamento da mainnet foi bem-sucedido e posicionou a Somnia com validadores ao vivo, um token ao vivo e mais de 70 projetos ao vivo ou com lançamento iminente. Importante, eles chegaram ao mercado exatamente quando o interesse em jogos Web3 e metaverso estava ressurgindo no final de 2025, aproveitando essa tendência.

Status Atual (Final de 2025): A mainnet da Somnia está operacional com blocos em menos de um segundo. A rede ainda está em uma fase de bootstrap, onde a Fundação Somnia e a equipe principal mantêm um controle significativo para garantir a estabilidade. Por exemplo, as propostas de governança provavelmente ainda não estão totalmente abertas; a fundação provavelmente está gerenciando atualizações e ajustes de parâmetros enquanto a comunidade está sendo educada sobre os processos de governança. A distribuição de tokens ainda está muito concentrada (já que apenas ~16% está em circulação e os tokens de investidores/equipe não começarão a ser desbloqueados até o final de 2026). Isso significa que a Fundação tem amplas reservas de tokens para apoiar o ecossistema (via subsídios, provisão de liquidez, etc.).

Na frente técnica, a Somnia provavelmente está monitorando e ajustando o desempenho em condições reais. Os dApps reais estão levando-a aos seus limites? Provavelmente ainda não – as contagens iniciais de usuários estão provavelmente na casa dos milhares, não milhões. Portanto, pode não haver 1M de TPS acontecendo na mainnet regularmente, mas a capacidade está lá. A equipe pode usar este período para otimizar o software do cliente, incorporar qualquer feedback do Cuthbert (se alguma divergência foi encontrada, seria corrigida prontamente) e reforçar a segurança. Os resultados das auditorias de segurança (se ainda não foram divulgados) podem ser publicados por volta desta época ou no início de 2026 para garantir a segurança dos desenvolvedores.

Roteiro de Curto Prazo (2026): A documentação e as comunicações da Somnia sugerem várias metas de curto prazo:

• Lançamento de Recursos: Alguns recursos foram planejados para serem ativados após o lançamento:
  • Os Preços Dinâmicos de Gas e Descontos por Volume estão programados para serem lançados até o final de 2025. Isso requer alguns testes e talvez aprovação da governança para ser ativado. Uma vez habilitado, dApps de alto rendimento começarão a desfrutar de gas mais barato, o que pode ser um ponto de venda para atrair parceiros empresariais ou grandes da Web2.
  • O recurso de Armazenamento Transiente também está agendado para o final de 2025. A implementação provavelmente precisa ser cuidadosamente testada (garantindo que a exclusão de dados funcione corretamente e não introduza problemas de consenso). Quando isso for ao ar, a Somnia será uma das primeiras cadeias a oferecer dados on-chain com prazo de validade, o que será enorme para os desenvolvedores de jogos (imagine sessões de jogo temporárias on-chain).
  • Gorjetas (taxas de prioridade): Eles notaram que as gorjetas podem ser introduzidas mais tarde, se necessário. Se o uso da rede aumentar a ponto de os blocos estarem consistentemente cheios, até 2026 eles podem habilitar gorjetas opcionais para priorizar transações (assim como o modelo de taxa base e gorjeta do Ethereum). Isso seria um sinal de congestionamento saudável se acontecer.
  • Expansão do Conjunto de Validadores: Inicialmente com ~60, o objetivo é aumentar o número de validadores ao longo do tempo para melhorar a descentralização sem prejudicar o desempenho. Eles mencionaram esperar um crescimento além de 100 à medida que a rede amadurece. O cronograma pode depender de quão bem o consenso escala com mais validadores (o PBFT tende a ficar mais lento à medida que os validadores aumentam, mas talvez sua variante inspirada no Autobahn possa lidar com algumas centenas). Em 2026, eles podem integrar validadores adicionais, possivelmente de sua comunidade ou novos parceiros. Isso poderia ser feito através de votos de governança (detentores de tokens aprovando novos validadores) ou automaticamente se houver stake suficiente apoiando novos entrantes.
  • Descentralização da Governança: A Somnia estabeleceu um roteiro de Descentralização Progressiva na governança. Nos primeiros 6 meses (fase de bootstrap), o conselho da Fundação está totalmente no controle. Portanto, aproximadamente até o 1º/2º trimestre de 2026, estaremos em bootstrap – durante o qual eles provavelmente refinarão processos e integrarão membros aos conselhos. Então, de 6 a 24 meses (meados de 2026 a final de 2027), eles entram na fase de Transição, onde a Token House (detentores de tokens) pode começar a votar em propostas, embora a Fundação possa vetar se necessário. Podemos ver os primeiros votos on-chain em 2026 para coisas como alocações de subsídios ou pequenas alterações de parâmetros. No segundo ano (2027), o objetivo é a fase Madura, onde as decisões dos detentores de tokens prevalecem e a Fundação só faz intervenções de emergência. Portanto, para 2026, uma meta chave é estabelecer esses órgãos de governança: possivelmente elegendo membros para o Conselho de Validadores, Conselho de Desenvolvedores, Assembleia de Usuários que foram descritos. Isso envolverá organização comunitária – provavelmente algo que a Fundação facilitará selecionando membros respeitáveis inicialmente (por exemplo, convidando os principais desenvolvedores de jogos para um conselho de desenvolvedores, ou grandes líderes de guildas da comunidade para uma assembleia de usuários).
• Crescimento do Ecossistema: Na frente de adoção, 2026 será sobre transformar projetos piloto em sucessos mainstream:
  • Esperamos lançamentos completos de jogos: Sparkball e Variance podem ir do beta para o lançamento oficial na mainnet da Somnia em 2026, com o objetivo de atrair dezenas de milhares de jogadores. Outros jogos da coorte Dream Catalyst (Maelstrom, Netherak, Dark Table, etc.) provavelmente serão lançados ao público. A equipe da Somnia apoiará esses lançamentos, possivelmente através de campanhas de marketing, torneios e programas de incentivo (como play-to-earn ou airdrops) para atrair jogadores.
  • Novas parcerias: A Improbable/MSquared planejava escalar de 30 eventos em 2023 para mais de 300 eventos de metaverso em 2024. Em 2024, eles fizeram muitos eventos off-chain; em 2025/2026, esperamos que esses eventos integrem a Somnia. Por exemplo, talvez um grande evento esportivo ou festival de música em 2026 use a Somnia para emissão de ingressos ou recompensas para fãs. O envolvimento do Google Cloud sugere possíveis eventos empresariais ou showcases através dos clientes de nuvem do Google. Além disso, dado que Mirana (associada à Bybit/BitDAO) e outros investiram, a Somnia pode ver colaborações com corretoras ou grandes marcas Web3 para utilizar a rede.
  • Integração com MSquared: O comunicado de imprensa da Chainwire observou que a M² planeja integrar a Somnia em sua rede de metaversos. Isso significa que qualquer mundo virtual usando a tecnologia da MSquared poderia adotar a Somnia como sua camada de transação. Até 2026, podemos ver a MSquared lançar formalmente sua rede de metaverso com a Somnia sustentando a identidade de avatares, negociação de itens, etc. Se o Otherside da Yuga Labs ainda estiver nos trilhos, talvez ocorra uma demonstração de interoperabilidade com a Somnia (por exemplo, usar seu NFT do Otherside em um mundo impulsionado pela Somnia).
  • Expansão da Comunidade de Desenvolvedores: Os US$ 10 milhões em subsídios serão distribuídos ao longo do tempo – até 2026, provavelmente dezenas de projetos terão recebido financiamento. O resultado disso pode ser mais ferramentas (digamos, um SDK Unity para a Somnia, ou mais melhorias na Ormi), mais aplicativos (talvez alguém construa um Twitter descentralizado baseado na Somnia ou uma nova plataforma DeFi). A Somnia provavelmente realizará mais hackathons (potencialmente alguns presenciais em conferências, etc.) e continuará com um devrel agressivo para atrair talentos. Eles podem mirar especialmente em desenvolvedores do Ethereum que estão atingindo limites de escalabilidade com seus dApps, oferecendo-lhes uma portabilidade fácil para a Somnia.
  • Interoperabilidade e Pontes: Já integrada com a LayerZero, a Somnia provavelmente expandirá as pontes para outros ecossistemas para um suporte mais amplo de ativos. Por exemplo, a integração com o Polygon ou o Cosmos IBC pode estar na mesa. Além disso, padrões cross-chain para NFTs (talvez permitindo que NFTs do Ethereum sejam espelhados na Somnia para uso em jogos) poderiam ser buscados. Como a Somnia é EVM, implantar contratos de ponte para tokens populares (USDC, USDT, WETH) é simples – 2026 pode ver uma liquidez mais profunda à medida que mais desses ativos cross-chain fluem.
  • Monitoramento de Desempenho: À medida que mais uso real chega, a equipe monitorará quaisquer problemas de estabilidade. Existem vetores de ataque (spam em muitas cadeias de dados, etc.)? Eles podem implementar refinamentos como limites de taxa por cadeia de dados ou otimizações adicionais, se necessário. A execução dupla do Cuthbert provavelmente continuará até pelo menos 2026 para capturar qualquer divergência; se o sistema se provar muito estável, eles podem considerar desligá-lo para reduzir a sobrecarga após um ou dois anos, mas isso depende da confiança total.
• Marketing e Divulgação: Com a mainnet e os aplicativos iniciais ao vivo, o desafio da Somnia para 2026 é construir uma base de usuários. Espere um marketing pesado voltado para jogadores e usuários de cripto:
  • Podemos ver parcerias com guildas de jogos ou equipes de esports, para levar jogadores aos jogos da Somnia.
  • Talvez colaborações com celebridades para eventos virtuais (dado que eles fizeram K-Pop e lendas do esporte em eventos de teste, eles poderiam escalar isso – imagine um músico famoso lançando um álbum através de um show no metaverso da Somnia com produtos NFT).
  • Além disso, participar e patrocinar grandes conferências (GDC para desenvolvedores de jogos, Consensus para cripto, etc.) para promover a plataforma.
  • No final de 2025, eles já tinham uma imprensa significativa (artigo da Binance Academy, cobertura da CoinDesk, etc.). Em 2026, mais análises independentes (perfis da Messari, etc.) surgirão, e a Somnia vai querer mostrar métricas de uso para provar a tração (como “X usuários ativos diários, Y transações processadas”).

Visão de Longo Prazo: Embora não tenha sido explicitamente perguntado, vale a pena notar a trajetória da Somnia:

• Em alguns anos, eles imaginam a Somnia como uma camada base amplamente utilizada para o entretenimento Web3, com bilhões de transações como rotina, e uma governança descentralizada administrada por sua comunidade e conselhos. Eles também provavelmente preveem melhoria técnica contínua – por exemplo, explorando sharding se necessário, ou adotando nova criptografia (talvez provas zk para comprimir dados ainda mais, ou criptografia pós-quântica eventualmente).
• Outro objetivo de longo prazo pode ser a neutralidade de carbono ou eficiência: cadeias de alto TPS muitas vezes se preocupam com o uso de energia. Se a Somnia atingir milhões de TPS, garantir que os nós possam lidar com isso de forma eficiente (talvez através de aceleração de hardware ou escalonamento na nuvem) será importante. Com o Google Cloud na mistura, talvez iniciativas de data centers verdes ou hardware especial (como GPUs ou FPGAs para compressão) possam ser considerados.
• Até lá, a concorrência também aumentará (Ethereum 2.0 com sharding, zkEVMs, melhorias na Solana, etc.). A Somnia terá que manter sua vantagem através da inovação e dos efeitos de rede (se capturar uma grande base de jogadores cedo, esse impulso pode levá-la adiante).

Em resumo, o roteiro para os próximos 1-2 anos foca em:

1. Ativar recursos chave do protocolo (descontos de gas, armazenamento transiente) para entregar totalmente a funcionalidade prometida.
2. Descentralizar a governança gradualmente – passando de uma liderança da fundação para uma liderança comunitária sem comprometer o progresso.
3. Impulsionar o crescimento do ecossistema – garantindo que os projetos financiados sejam lançados e atraiam usuários, forjando novas parcerias (com criadores de conteúdo, estúdios de jogos, talvez até empresas Web2 interessadas na Web3), e possivelmente expandindo para mais regiões e comunidades.
4. Manter o desempenho e a segurança à medida que o uso escala – observando quaisquer problemas quando, digamos, um jogo gera um pico de 10k TPS de tráfego real, e respondendo adequadamente (isso pode incluir a realização de mais eventos de teste públicos, talvez um evento de “teste de estresse da Mainnet” onde eles incentivam toneladas de transações para testar os limites).

A Somnia fez uma estreia chamativa, mas 2026 será o campo de provas: ela precisa converter sua tecnologia impressionante e seu ecossistema bem financiado em adoção real e uma rede sustentável e descentralizada. O grande tesouro de tokens da fundação (Ecossistema e Comunidade ~55% do fornecimento) lhe dá os meios para impulsionar a atividade por anos, então, no curto prazo, veremos esses tokens serem utilizados – via airdrops, recompensas (possivelmente mineração de liquidez se um DEX for lançado), recompensas para desenvolvedores e campanhas de aquisição de usuários. O slogan de lançamento da mainnet da Improbable foi que a Somnia “marca a fundação de uma economia de ativos digitais aberta, onde bilhões de pessoas podem interagir através de experiências imersivas”. Os próximos passos no roteiro são todos sobre assentar os tijolos dessa fundação: conseguir os primeiros milhões de pessoas e os primeiros aplicativos matadores para se engajarem com o “computador dos sonhos” da Somnia (como eles o apelidam), e assim validar que a Web3 pode de fato operar em escala de internet.

Se a Somnia continuar em sua trajetória atual, até o final de 2026 poderemos ver dezenas de jogos e plataformas sociais totalmente on-chain em funcionamento, uma rede florescente administrada pela comunidade com centenas de validadores, e o SOMI sendo usado diariamente por usuários mainstream (muitas vezes sem saber, por baixo dos panos dos jogos). Alcançar isso marcaria um marco significativo não apenas para a Somnia, mas para o avanço da indústria de blockchain em aplicações mainstream e em tempo real. As peças estão no lugar; agora é sobre execução e adoção nesta fase crítica de pesquisa profunda do roteiro do projeto.

Fontes:

• Documentação Oficial da Somnia (Litepaper e Conceitos Técnicos)
• Documentos de Tokenomics e Governança da Somnia
• Comunicado de Imprensa da Improbable (Lançamento da Mainnet)
• Cobertura da CoinDesk sobre o Lançamento da Somnia
• Binance Academy – O que é Somnia (SOMI)
• Gam3s.gg – Cobertura de Jogos da Somnia (Variance, Sparkball, etc.)
• Pesquisa da Stakin – Introdução à Somnia
• Comunicado de Imprensa da Chainwire – Investimento de US$ 270M e resultados da Devnet
• Blog da Somnia – Eventos da Improbable & MSquared, Notícias da Mainnet
• Documentação Oficial da Somnia – Guias para Desenvolvedores (pontes, carteiras, etc.)

A privacidade está se tornando infraestrutura pública. Em 2025, desenvolvedores precisam de ferramentas que tornem a criptografia tão fácil quanto armazenar dados. O Seal da Mysten Labs oferece exatamente isso—gerenciamento descentralizado de segredos com controle de acesso onchain. Este tutorial te ensinará como construir aplicações Web3 seguras usando criptografia baseada em identidade, segurança threshold e políticas de acesso programáveis.

Introdução: Por que o Seal Importa para Web3​

Aplicações cloud tradicionais dependem de sistemas centralizados de gerenciamento de chaves onde um único provedor controla o acesso aos dados criptografados. Embora conveniente, isso cria pontos únicos perigosos de falha. Se o provedor for comprometido, ficar offline ou decidir restringir o acesso, seus dados se tornam inacessíveis ou vulneráveis.

Seal muda completamente esse paradigma. Construído pela Mysten Labs para a blockchain Sui, Seal é um serviço de gerenciamento descentralizado de segredos (DSM) que possibilita:

• Criptografia baseada em identidade onde o conteúdo é protegido antes de deixar seu ambiente
• Criptografia threshold que distribui acesso às chaves entre múltiplos nós independentes
• Controle de acesso onchain com time locks, token-gating e lógica de autorização customizada
• Design agnóstico de armazenamento que funciona com Walrus, IPFS ou qualquer solução de armazenamento

Seja construindo aplicações de mensagens seguras, plataformas de conteúdo restrito por tokens ou transferências de ativos com time lock, Seal fornece as primitivas criptográficas e infraestrutura de controle de acesso que você precisa.

Primeiros Passos​

Pré-requisitos​

Antes de mergulhar, certifique-se de ter:

• Node.js 18+ instalado
• Familiaridade básica com TypeScript/JavaScript
• Uma carteira Sui para testes (como Sui Wallet)
• Entendimento de conceitos blockchain

Instalação​

Instale o SDK Seal via npm:

npm install @mysten/seal

Você também vai querer o SDK Sui para interações blockchain:

npm install @mysten/sui

Configuração do Projeto​

Crie um novo projeto e inicialize-o:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Crie uma configuração TypeScript simples:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Conceitos Fundamentais: Como o Seal Funciona​

Antes de escrever código, vamos entender a arquitetura do Seal:

1. Criptografia Baseada em Identidade (IBE)​

Diferente da criptografia tradicional onde você criptografa para uma chave pública, IBE permite criptografar para uma identidade (como um endereço de email ou endereço Sui). O destinatário só pode descriptografar se conseguir provar que controla essa identidade.

2. Criptografia Threshold​

Em vez de confiar em um único servidor de chaves, Seal usa esquemas t-of-n threshold. Você pode configurar 3-de-5 servidores de chaves, significando que qualquer 3 servidores podem cooperar para fornecer chaves de descriptografia, mas 2 ou menos não conseguem.

3. Controle de Acesso Onchain​

Políticas de acesso são aplicadas por smart contracts da Sui. Antes que um servidor de chaves forneça chaves de descriptografia, ele verifica se o solicitante atende aos requisitos da política onchain (propriedade de tokens, restrições de tempo, etc.).

4. Rede de Servidores de Chaves​

Servidores de chaves distribuídos validam políticas de acesso e geram chaves de descriptografia. Esses servidores são operados por diferentes partes para garantir que não haja um único ponto de controle.

Implementação Básica: Sua Primeira Aplicação Seal​

Vamos construir uma aplicação simples que criptografa dados sensíveis e controla o acesso através de políticas blockchain da Sui.

Passo 1: Inicializar o Cliente Seal​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // Inicializar cliente Sui para testnet
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // Configurar cliente Seal com servidores de chaves da testnet
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // threshold 2-de-3
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

Passo 2: Criptografia/Descriptografia Simples​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // Dados para criptografar
  const sensitiveData = "Esta é minha mensagem secreta!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Criptografar dados para um endereço Sui específico
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // Opcional: adicionar metadados
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('Dados criptografados:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // Depois, descriptografar os dados (requer autorização adequada)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('Dados descriptografados:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('Falha na criptografia/descriptografia:', error);
  }
}

basicExample();

Controle de Acesso com Smart Contracts da Sui​

O verdadeiro poder do Seal vem do controle de acesso programável. Vamos criar um exemplo de criptografia com time lock onde os dados só podem ser descriptografados após um tempo específico.

Passo 1: Implementar Contrato de Controle de Acesso​

Primeiro, precisamos de um smart contract Move que define nossa política de acesso:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

Passo 2: Integrar com Seal​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Criar política de acesso na Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Desbloquear em 1 minuto
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // Executar transação para criar política
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Seu keypair Sui
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // Agora criptografar com esta política
  const sensitiveData = "Isso será desbloqueado em 1 minuto!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('Dados com time lock criados. Tente descriptografar após 1 minuto.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

Exemplos Práticos​

Exemplo 1: Aplicação de Mensagens Seguras​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // Armazenar mensagem criptografada em armazenamento descentralizado (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Recuperar do armazenamento
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Descriptografar com Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Integração com armazenamento Walrus
    // Isso faria upload dos dados criptografados para Walrus
    // e retornaria o blob ID para recuperação
  }

  private async retrieveFromWalrus(blobId: string) {
    // Recuperar dados criptografados do Walrus usando blob ID
  }
}

Exemplo 2: Plataforma de Conteúdo com Token-Gating​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // Criar política de propriedade de NFT
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // Criptografar conteúdo com requisito de acesso por NFT
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // Destinatário especial para portadores de NFT
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // Verificar propriedade de NFT primeiro
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('Acesso negado: NFT necessário não encontrado');
    }

    // Descriptografar conteúdo
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // Criar contrato Move que verifica propriedade de NFT
    // Retorna ID do objeto de política
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Verificar se usuário possui NFT necessário
    // Consultar Sui para propriedade de NFT
  }
}

Exemplo 3: Transferência de Ativos com Time Lock​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Criar política de time lock na Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // Criptografar dados de transferência de ativo
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`Ativo bloqueado até ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // Processar a transferência de ativo
    console.log('Transferência de ativo desbloqueada:', transferData);

    return transferData;
  } catch (error) {
    console.error('Transferência ainda não desbloqueada ou acesso negado:', error);
    throw error;
  }
}

Integração com Armazenamento Descentralizado Walrus​

Seal funciona perfeitamente com Walrus, a solução de armazenamento descentralizado da Sui. Veja como integrar ambos:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Criptografar com Seal
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // Armazenar dados criptografados no Walrus
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Retornar referência que inclui informações tanto do Seal quanto do Walrus
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Recuperar do Walrus
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Descriptografar com Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// Exemplo de uso
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('Conteúdo de documento importante');
  const recipientAddress = '0x...';

  // Armazenar criptografado
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Armazenado com Blob ID:', result.blobId);

  // Depois, recuperar e descriptografar
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('Dados recuperados:', decrypted.toString());
}

Configuração Avançada de Criptografia Threshold​

Para aplicações de produção, você vai querer configurar criptografia threshold customizada com múltiplos servidores de chaves:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // Configurar com múltiplos servidores de chaves independentes
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // threshold 3-de-5
    network: 'mainnet',
    // Opções avançadas
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "Dados criptografados de missão crítica";

  // Criptografar com altas garantias de segurança
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // Exigir todos os 5 servidores para máxima segurança
    customThreshold: 5,
    // Adicionar redundância
    redundancy: 2,
    accessPolicy: {
      // Requisitos multifator
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

Melhores Práticas de Segurança​

1. Gerenciamento de Chaves​

// src/security-practices.ts

// BOM: Usar derivação segura de chaves
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// BOM: Armazenar chaves de forma segura (exemplo com variáveis de ambiente)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// RUIM: Nunca hardcodar chaves
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // Não faça isso!
);

2. Validação de Política de Acesso​

// Sempre validar políticas de acesso antes da criptografia
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validar endereço do destinatário
  if (!isValidSuiAddress(recipient)) {
    throw new Error('Endereço de destinatário inválido');
  }

  // Verificar se política existe e é válida
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('Política de acesso inválida');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. Tratamento de Erros e Fallbacks​

// Tratamento robusto de erros
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('Acesso negado: Verifique suas permissões');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // Tentar com configuração de backup
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('Servidores de chaves insuficientes disponíveis');
    } else {
      throw new Error(`Falha na descriptografia: ${error.message}`);
    }
  }
}

4. Validação de Dados​

// Validar dados antes da criptografia
function validateDataForEncryption(data: Buffer): boolean {
  // Verificar limites de tamanho
  if (data.length > 1024 * 1024) { // Limite de 1MB
    throw new Error('Dados muito grandes para criptografia');
  }

  // Verificar padrões sensíveis (opcional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('Aviso: Dados contêm padrões potencialmente sensíveis');
  }

  return true;
}

Otimização de Performance​

1. Operações em Lote​

// Agrupar múltiplas criptografias para eficiência
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. Cache de Respostas de Servidores de Chaves​

// Cache de sessões de servidores de chaves para reduzir latência
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Testando Sua Integração Seal​

Testes Unitários​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Integração Seal', () => {
  it('deve criptografar e descriptografar dados com sucesso', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('mensagem de teste');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('mensagem de teste');
  });

  it('deve aplicar políticas de controle de acesso', async () => {
    // Testar que usuários não autorizados não podem descriptografar
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('segredo'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('Acesso negado');
  });
});

Deploy para Produção​

Configuração de Ambiente​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // Configurações de segurança
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hora
  retryAttempts: 3
};

Monitoramento e Logging​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Dados criptografados ${encryptionId} para ${recipient}`);
    // Enviar para seu serviço de monitoramento
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] Descriptografia ${encryptionId}: ${success ? 'SUCESSO' : 'FALHA'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] Servidor de chaves ${serverUrl}: ${status}`);
  }
}

Recursos e Próximos Passos​

Documentação Oficial​

• Documentação Seal: https://seal-docs.wal.app/
• Repositório GitHub: https://github.com/MystenLabs/seal
• Documentação Sui: https://docs.sui.io/
• Documentação Walrus: https://docs.wal.app/

Comunidade e Suporte​

• Discord Sui: Junte-se ao canal #seal para suporte da comunidade
• GitHub Issues: Reporte bugs e solicite funcionalidades
• Fóruns de Desenvolvedores: Fóruns da comunidade Sui para discussões

Tópicos Avançados para Explorar​

1. Políticas de Acesso Customizadas: Construa lógica de autorização complexa com contratos Move
2. Integração Cross-Chain: Use Seal com outras redes blockchain
3. Gerenciamento de Chaves Empresarial: Configure sua própria infraestrutura de servidores de chaves
4. Auditoria e Compliance: Implemente logging e monitoramento para ambientes regulamentados

Aplicações de Exemplo​

• App de Chat Seguro: Mensagens criptografadas de ponta a ponta com Seal
• Gerenciamento de Documentos: Compartilhamento de documentos empresariais com controles de acesso
• Gerenciamento de Direitos Digitais: Distribuição de conteúdo com políticas de uso
• Analytics Preservando Privacidade: Workflows de processamento de dados criptografados

Conclusão​

Seal representa uma mudança fundamental em direção a tornar privacidade e criptografia preocupações de nível de infraestrutura em Web3. Ao combinar criptografia baseada em identidade, segurança threshold e controle de acesso programável, ele fornece aos desenvolvedores ferramentas poderosas para construir aplicações verdadeiramente seguras e descentralizadas.

As principais vantagens de construir com Seal incluem:

• Sem Ponto Único de Falha: Servidores de chaves distribuídos eliminam autoridades centrais
• Segurança Programável: Políticas de acesso baseadas em smart contracts fornecem autorização flexível
• Amigável ao Desenvolvedor: SDK TypeScript integra-se perfeitamente com ferramentas Web3 existentes
• Agnóstico de Armazenamento: Funciona com Walrus, IPFS ou qualquer solução de armazenamento
• Pronto para Produção: Construído pela Mysten Labs com padrões de segurança empresariais

Seja protegendo dados de usuários, implementando modelos de assinatura ou construindo aplicações complexas multipartidárias, Seal fornece as primitivas criptográficas e infraestrutura de controle de acesso que você precisa para construir com confiança.

Comece a construir hoje, e junte-se ao crescente ecossistema de desenvolvedores tornando a privacidade uma parte fundamental da infraestrutura pública.

Pronto para começar a construir? Instale @mysten/seal e comece a experimentar com os exemplos deste tutorial. A web descentralizada está esperando por aplicações que colocam privacidade e segurança em primeiro lugar.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Painel: Um Mergulho Profundo na Arquitetura de Blockchain​

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

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

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

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

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

Mais Destaques da Cúpula​

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

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

O ingresso de concerto na sua carteira digital está prestes a receber uma atualização massiva. Por décadas, um ingresso foi uma prova estática e descartável de compra — um código de barras para abrir a porta, e nada mais. Esse modelo está evoluindo. O ingresso está se tornando um objeto de associação programável e portátil, capaz de desbloquear experiências muito depois que o show termina.

Se feito corretamente, os ingressos NFT podem reduzir drasticamente fraudes e revenda abusiva, criar acesso mais justo para superfãs e dar aos organizadores maneiras poderosas de recompensar a lealdade — tudo sem forçar os fãs a entender criptomoedas. Isso não é um futuro teórico; implantações reais já estão ao vivo em grandes concertos, esportes profissionais, aviação e até Fórmula 1. A próxima onda de adoção depende de uma experiência de usuário fluida, design de políticas cuidadoso e escolhas tecnológicas pragmáticas.

O Antigo Stack de Ingressos Está Enferrujado​

O sistema tradicional de bilhetagem digital é frágil e está mostrando sua idade. Fãs e organizadores sentem as mesmas dores:

• Fraude & Bots: Bots predatórios agarram o estoque no instante em que ele entra à venda, apenas para listá‑lo em mercados secundários a preços inflacionados, excluindo fãs reais. Ingressos falsos ou duplicados assolam esses mercados, deixando compradores de mãos vazias e carteiras mais leves.
• Sistemas Fragmentados: O histórico de um fã está espalhado por dezenas de contas de fornecedores. Isso torna simples ações como transferir um ingresso para um amigo um processo doloroso e deixa os organizadores sem uma visão unificada de seus participantes mais leais.
• Artefatos Descartáveis: Uma vez escaneado, um QR code ou ingresso PDF torna‑se lixo digital inútil. Não tem valor contínuo, não conta história e não oferece utilidade futura.

Enquanto isso, o mercado continua dominado por um vendedor primário sob escrutínio antitruste. Esforços de reforma estado a estado ganham força, sinalizando que o status quo não é nem amado nem estável. O sistema está pronto para mudança.

Ingressos, Mas Programáveis​

Ingressos NFT não são sobre arte digital especulativa; são sobre acesso programável e propriedade. Ao representar um ingresso como um token único em uma blockchain, mudamos fundamentalmente o que ele pode fazer:

• Prova de Propriedade Verificável: Ingressos vivem na carteira digital do usuário, não apenas no banco de dados isolado do fornecedor. Essa prova criptográfica de propriedade reduz drasticamente o risco de ingressos falsificados e permite transferências seguras e verificáveis entre fãs.
• Regras de Transferência On‑Chain: Organizadores podem incorporar regras diretamente no contrato inteligente do ingresso. Isso pode significar janelas de transferência justas, limites de preço de revenda ao valor de face ou outra lógica que coiba a revenda predatória e alinhe incentivos para todos.
• Lealdade que se Compõe: Uma carteira contendo ingressos de eventos passados torna‑se um “grafo de fãs” portátil e verificável. Organizadores podem usar esse histórico para oferecer pré‑vendas token‑gated, upgrades de assentos e perks exclusivos que recompensam a presença real, não apenas nomes em uma lista de e‑mail.
• Interoperabilidade: “Entrar com a carteira” pode tornar‑se uma camada de identidade universal entre diferentes venues, artistas e parceiros. Fãs recebem uma experiência unificada sem espalhar suas informações pessoais por inúmeras plataformas.

Essa tecnologia já está deixando o laboratório e provando seu valor no mundo real.

Prova de Funcionamento: Implantações ao Vivo para Estudo​