Skip to main content

O que é uma blockchain non-EVM

Nota: Este documento é uma tradução automática da versão original em inglês.

O que é uma blockchain non-EVM

Uma blockchain non-EVM é qualquer blockchain que não usa a Ethereum Virtual Machine como seu motor de execução. Em vez de rodar bytecode Solidity, as chains non-EVM usam máquinas virtuais diferentes, linguagens de programação diferentes e modelos de execução diferentes. Os exemplos incluem Solana (SVM/Sealevel), chains baseadas em Cosmos (CosmWasm, módulos específicos de aplicação), NEAR (runtime baseado em WebAssembly), Sui e Aptos (MoveVM) e Bittensor (runtime customizado baseado em Substrate).

A distinção importa porque a escolha da máquina virtual determina quais linguagens de programação os desenvolvedores usam, como os smart contracts se comportam, qual ferramental está disponível e com que facilidade um projeto pode interagir com outras chains. Um projeto construído em uma chain non-EVM não pode simplesmente copiar e colar contratos Solidity do Ethereum — ele precisa de uma base de código diferente, habilidades de desenvolvedor diferentes e um conjunto diferente de ferramentas de infraestrutura.

Em resumo: as blockchains non-EVM usam ambientes de execução diferentes da Ethereum Virtual Machine. Isso significa linguagens de programação diferentes, ferramental diferente e trade-offs arquiteturais diferentes — mas também o potencial para características de desempenho que a EVM não consegue alcançar.

Como a execução non-EVM difere da EVM

A EVM é uma máquina virtual baseada em pilha que executa bytecode Solidity sequencialmente, usa inteiros de 256 bits e mede a computação por meio de gas. As chains non-EVM se afastam desse modelo de várias maneiras:

Máquinas virtuais diferentes

Chain / ecossistema Máquina virtual Linguagem primária Diferença arquitetural-chave
Solana SVM (Sealevel) Rust Execução paralela de transações via acesso declarado ao estado
Cosmos chains CosmWasm / módulos nativos Rust (CosmWasm), Go (módulos) Blockchain específica de aplicação com comunicação cross-chain integrada (IBC)
NEAR WebAssembly (Wasm) Rust, AssemblyScript Execução fragmentada (sharded) com chamadas cross-shard assíncronas
Sui MoveVM Move Modelo de estado centrado em objetos, permitindo execução paralela
Aptos MoveVM Move Motor de execução paralela Block-STM
Bittensor Substrate runtime Rust Coordenação específica de IA; subnets como unidades de execução

Cada máquina virtual faz trade-offs diferentes. A SVM da Solana exige que as transações declarem qual estado vão acessar com antecedência, permitindo que o runtime execute transações não conflitantes em paralelo — algo que a EVM não consegue fazer nativamente. As chains Cosmos trocam o modelo de execução compartilhada por completo: cada aplicação ganha sua própria chain com lógica customizada, conectada a outras chains via o protocolo IBC. As chains baseadas em Move (Sui, Aptos) usam um modelo de programação orientado a recursos que previne certas classes de bugs (como reentrância) no nível da linguagem.

Linguagens de programação diferentes

O ecossistema EVM é dominado pelo Solidity — uma linguagem projetada especificamente para smart contracts do Ethereum. As chains non-EVM usam linguagens de propósito geral ou alternativas criadas para fins específicos:

  • Rust — usado pela Solana (via framework Anchor), Cosmos (via CosmWasm), NEAR e chains baseadas em Substrate, incluindo a Bittensor. As garantias de segurança de memória e o desempenho do Rust o tornam adequado para programas on-chain.
  • Move — desenvolvido originalmente no Facebook/Diem, agora usado pela Sui e Aptos. O Move trata os ativos on-chain como recursos de primeira classe que não podem ser duplicados ou destruídos acidentalmente, reduzindo uma categoria de vulnerabilidades comuns de smart contracts.
  • Go — usado para desenvolvimento de módulos nativos em chains baseadas no Cosmos SDK. Os validadores rodam binários compilados em Go diretamente.
  • AssemblyScript — uma linguagem semelhante a TypeScript que compila para WebAssembly, usada como linguagem alternativa para o desenvolvimento na NEAR.

Essa diversidade de linguagens significa que os desenvolvedores não podem transferir habilidades de Solidity diretamente para chains non-EVM. Um projeto construindo na Solana precisa de engenheiros de Rust; um projeto construindo na Sui precisa de engenheiros de Move. O pool de talentos de desenvolvedores para cada linguagem afeta a rapidez com que um projeto pode construir e iterar.

Características de desempenho diferentes

As chains non-EVM frequentemente alcançam perfis de desempenho diferentes:

  • Execução paralela — Solana, Sui e Aptos executam transações não conflitantes em paralelo, o que pode oferecer maior throughput do que o modelo de execução sequencial da EVM.
  • Taxas mais baixas e mais previsíveis — algumas chains non-EVM têm estruturas de taxa projetadas para alto throughput desde o início, evitando os mercados de taxa voláteis que as chains EVM podem experimentar durante o congestionamento.
  • Modelos de estado customizados — as chains non-EVM podem usar modelos de estado otimizados para padrões de acesso específicos. O modelo centrado em objetos da Sui, por exemplo, permite propriedade por objeto e processamento paralelo que seria complexo de implementar na EVM.

Essas vantagens de desempenho vêm com trade-offs: ecossistemas de desenvolvedores menores, ferramental menos maduro, menos firmas de auditoria com expertise relevante e menos componibilidade com o grande ecossistema de DeFi e tokens baseado em EVM.

Por que isso importa para projetos de cripto IA

A escolha da máquina virtual tem implicações práticas para projetos de blockchain relacionados a IA:

  • Flexibilidade de execução — as chains non-EVM podem suportar modelos de execução mais adequados a cargas de trabalho de coordenação de IA. A execução paralela, máquinas de estado customizadas e conjuntos de instruções de menor sobrecarga podem servir melhor às transações de alta frequência relacionadas a IA (atribuições de tarefas de computação, submissões de resultados, atualizações de registro de modelos).
  • Adequação de linguagem — as chains baseadas em Rust se alinham bem com a infraestrutura de IA/ML, já que grande parte do ferramental de IA (componentes críticos de desempenho, coordenação de GPU, programação de sistemas) é escrita em Rust ou interage bem com código Rust.
  • Design específico de aplicação — as appchains Cosmos e as subnets Bittensor permitem que os projetos de IA construam lógica de execução customizada no nível da chain, sem as restrições do conjunto de opcodes e do modelo de gas da EVM.
  • Trade-offs de ecossistema — os projetos non-EVM não conseguem se conectar facilmente ao grande ecossistema da EVM de protocolos DeFi, bridges de tokens e infraestrutura de carteiras. Os projetos de IA em chains non-EVM precisam construir essa infraestrutura eles mesmos, depender de bridges cross-chain ou aceitar um ecossistema inicial menor.

Nos cartões de projeto do DecAIHub, Type: non-EVM informa ao leitor que o projeto não usa Solidity, não pode fazer deploy em chains compatíveis com EVM sem reescrever e opera em um ecossistema técnico diferente.

Onde isso aparece nos cartões de projeto do DecAIHub

Nos cartões de projeto do DecAIHub, a designação non-EVM aparece em:

  • Type — non-EVM indica que os smart contracts ou a lógica on-chain do projeto usam uma máquina virtual diferente da EVM. Isso afeta qual ferramental, linguagens e padrões se aplicam.
  • Main chain — a chain non-EVM específica é listada (Solana, Bittensor, uma chain Cosmos, Sui, etc.). Cada chain tem sua própria VM, linguagem e ecossistema.
  • Token standard — as chains non-EVM têm seus próprios token standards. A Solana usa tokens SPL; as chains Cosmos usam denominações nativas ou CW-20 (CosmWasm); as chains baseadas em Move usam recursos de coin/fungible-asset. Esses não são intercambiáveis com o ERC-20.
  • Smart contracts / lógica on-chain — a linguagem de programação e o framework diferem dos projetos EVM. Os programas Solana são escritos em Rust (Anchor), os contratos Cosmos em Rust (CosmWasm) ou Go, e assim por diante.

O que uma classificação non-EVM por si só não prova

  • Non-EVM não significa melhor desempenho. Embora algumas chains non-EVM ofereçam execução paralela ou taxas mais baixas, o desempenho depende da chain específica, de sua infraestrutura de validadores e da carga atual — não apenas da escolha da VM.
  • Non-EVM não prova sofisticação técnica. Escolher uma chain non-EVM é uma decisão de infraestrutura. Isso não indica a qualidade do AI component do projeto, de seu código ou de seu produto.
  • Non-EVM não significa que o projeto não pode interagir com chains EVM. Muitos projetos non-EVM usam bridges, oráculos ou tokens encapsulados (wrapped) para se conectar com o Ethereum e outros ecossistemas EVM. A interação cross-chain é possível; ela apenas requer infraestrutura adicional.
  • Uma VM diferente não significa garantias de segurança diferentes. Bugs de smart contract, erros de lógica e riscos de centralização existem em todas as chains, independentemente da máquina virtual. Linguagens non-EVM como Rust e Move eliminam algumas classes de bugs, mas introduzem outras.
  • Um rótulo non-EVM não explica por que o projeto escolheu aquela chain. A escolha pode ser impulsionada por necessidades de desempenho, expertise da equipe de desenvolvimento, incentivos de ecossistema ou simplesmente por onde a equipe fundadora começou. Sem contexto adicional, o rótulo por si só é informativo, não avaliativo.

Não confundir com

  • EVM — a EVM é a Ethereum Virtual Machine. Non-EVM é definido em contraste a ela: qualquer chain que não usa a EVM se enquadra na categoria non-EVM.
  • Ethereum — o Ethereum é a chain EVM original. Ser non-EVM significa que a chain não é o Ethereum e não usa o motor de execução do Ethereum — mas ela ainda pode interagir com o Ethereum via bridges ou protocolos cross-chain.
  • Solana — a Solana é uma blockchain non-EVM específica com sua própria máquina virtual (SVM). "Non-EVM" é uma categoria ampla que inclui Solana, Cosmos, Sui, Aptos, NEAR, Bittensor e muitas outras.
  • "Anti-Ethereum" — ser non-EVM não é uma declaração contra o Ethereum. Muitas chains non-EVM coexistem com o Ethereum e se beneficiam de liquidez via bridge. A escolha da VM reflete prioridades de design diferentes, não oposição ideológica.
  • Incompatível — as chains non-EVM não conseguem rodar bytecode EVM nativamente, mas isso não significa que estejam isoladas. Bridges cross-chain, protocolos de mensagens (como IBC, LayerZero, Wormhole) e tokens encapsulados (wrapped) permitem a interoperabilidade entre os ecossistemas EVM e non-EVM.

Perguntas frequentes

Quais são as chains non-EVM mais comuns usadas por projetos de cripto IA?

Solana e Bittensor estão entre as chains non-EVM mais frequentemente encontradas no espaço de cripto IA acompanhado pelo DecAIHub. O alto throughput e o ecossistema baseado em Rust da Solana atraem projetos de IA que precisam de coordenação on-chain rápida e de baixo custo. A Bittensor é criada especificamente para IA descentralizada, com subnets dedicadas a tarefas específicas de IA. As appchains baseadas em Cosmos são outro padrão, particularmente para projetos que querem um ambiente de execução totalmente customizado com comunicação cross-chain integrada via IBC.

Um projeto non-EVM também pode fazer deploy em chains EVM?

Sim, mas isso requer uma base de código separada. Um projeto escrito em Rust para a Solana não pode ser implantado no Ethereum como está — ele precisaria ser reescrito em Solidity (ou ter uma implementação Solidity separada). Alguns projetos mantêm contratos em chains EVM e non-EVM, mas cada deploy requer desenvolvimento, auditoria e manutenção independentes. As bridges cross-chain também podem permitir que projetos non-EVM tenham representação de token em chains EVM (por exemplo, tokens SPL encapsulados como ERC-20 no Ethereum).

Non-EVM é melhor para aplicações de IA?

Não há resposta universal. As chains non-EVM podem oferecer vantagens para casos de uso específicos de IA — a execução paralela da Solana é adequada à coordenação de alto throughput, a arquitetura de subnets da Bittensor é criada especificamente para incentivos de IA, e as appchains Cosmos permitem lógica de execução totalmente customizada. No entanto, as chains EVM oferecem um ecossistema de desenvolvedores maior, ferramental mais maduro, liquidez DeFi mais profunda e suporte de carteiras mais amplo. A melhor escolha depende dos requisitos específicos do projeto: quais cargas de trabalho rodam on-chain, qual desempenho é necessário, qual ecossistema a equipe prefere e onde estão os usuários-alvo.

As chains non-EVM têm token standards como o ERC-20?

Sim, mas diferentes. A Solana usa tokens SPL. As chains Cosmos usam denominações nativas ou tokens CW-20 (via CosmWasm). Sui e Aptos usam os recursos de coin e fungible asset do Move. A NEAR usa NEP-141. Cada padrão define como os tokens são criados, transferidos e gerenciados naquela chain. Esses padrões não são intercambiáveis com o ERC-20 — um token construído como SPL na Solana não pode ser usado diretamente em uma chain EVM sem encapsulamento (wrapping) ou bridge.

Referências externas

Ver também

No comments to display

Back to top