Skip to main content

Qué es una blockchain non-EVM

Nota: Este documento es una traducción automática del original en inglés.

Qué es una blockchain non-EVM

Una blockchain non-EVM es cualquier blockchain que no usa la Ethereum Virtual Machine como su motor de ejecución. En lugar de ejecutar bytecode de Solidity, las cadenas non-EVM usan máquinas virtuales diferentes, lenguajes de programación diferentes y modelos de ejecución diferentes. Los ejemplos incluyen Solana (SVM/Sealevel), las cadenas basadas en Cosmos (CosmWasm, módulos específicos de aplicación), NEAR (runtime basado en WebAssembly), Sui y Aptos (MoveVM) y Bittensor (runtime personalizado basado en Substrate).

La distinción importa porque la elección de la máquina virtual determina qué lenguajes de programación usan los desarrolladores, cómo se comportan los contratos inteligentes, qué herramientas están disponibles y con qué facilidad un proyecto puede interactuar con otras cadenas. Un proyecto construido sobre una cadena non-EVM no puede simplemente copiar y pegar contratos de Solidity de Ethereum —necesita una base de código diferente, habilidades de desarrollador diferentes y un conjunto diferente de herramientas de infraestructura—.

En resumen: las blockchains non-EVM usan entornos de ejecución distintos de la Ethereum Virtual Machine. Esto significa lenguajes de programación diferentes, herramientas diferentes y compensaciones arquitectónicas diferentes —pero también el potencial de características de rendimiento que la EVM no puede lograr—.

En qué se diferencia la ejecución non-EVM de la EVM

La EVM es una máquina virtual basada en pila que ejecuta bytecode de Solidity secuencialmente, usa enteros de 256 bits y mide el cómputo mediante gas. Las cadenas non-EVM se apartan de este modelo de varias maneras:

Máquinas virtuales diferentes

Cadena / ecosistema Máquina virtual Lenguaje principal Diferencia arquitectónica clave
Solana SVM (Sealevel) Rust Ejecución paralela de transacciones mediante acceso a estado declarado
Cadenas Cosmos CosmWasm / módulos nativos Rust (CosmWasm), Go (módulos) Blockchain específica de aplicación con comunicación entre cadenas integrada (IBC)
NEAR WebAssembly (Wasm) Rust, AssemblyScript Ejecución fragmentada (sharded) con llamadas asíncronas entre fragmentos
Sui MoveVM Move Modelo de estado centrado en objetos que permite la ejecución paralela
Aptos MoveVM Move Motor de ejecución paralela Block-STM
Bittensor Substrate runtime Rust Coordinación específica de IA; subnets como unidades de ejecución

Cada máquina virtual toma compensaciones diferentes. La SVM de Solana requiere que las transacciones declaren a qué estado accederán por adelantado, permitiendo al runtime ejecutar en paralelo las transacciones que no entran en conflicto —algo que la EVM no puede hacer de forma nativa—. Las cadenas Cosmos abandonan por completo el modelo de ejecución compartida: cada aplicación obtiene su propia cadena con lógica personalizada, conectada a otras cadenas mediante el protocolo IBC. Las cadenas basadas en Move (Sui, Aptos) usan un modelo de programación orientado a recursos que previene ciertas clases de bugs (como la reentrada) a nivel de lenguaje.

Lenguajes de programación diferentes

El ecosistema de la EVM está dominado por Solidity —un lenguaje diseñado específicamente para los contratos inteligentes de Ethereum—. Las cadenas non-EVM usan lenguajes de propósito general o alternativas creadas a propósito:

  • Rust — usado por Solana (vía el framework Anchor), Cosmos (vía CosmWasm), NEAR y las cadenas basadas en Substrate, incluida Bittensor. Las garantías de seguridad de memoria y el rendimiento de Rust lo hacen adecuado para programas on-chain.
  • Move — desarrollado originalmente en Facebook/Diem, ahora usado por Sui y Aptos. Move trata los activos on-chain como recursos de primera clase que no pueden duplicarse ni destruirse accidentalmente, reduciendo una categoría de vulnerabilidades comunes de contratos inteligentes.
  • Go — usado para el desarrollo de módulos nativos en las cadenas Cosmos SDK. Los validadores ejecutan binarios compilados en Go directamente.
  • AssemblyScript — un lenguaje similar a TypeScript que compila a WebAssembly, usado como lenguaje alternativo para el desarrollo en NEAR.

Esta diversidad de lenguajes significa que los desarrolladores no pueden transferir directamente las habilidades de Solidity a las cadenas non-EVM. Un proyecto que construye sobre Solana necesita ingenieros de Rust; un proyecto que construye sobre Sui necesita ingenieros de Move. El conjunto de talento de desarrolladores para cada lenguaje afecta a la rapidez con la que un proyecto puede construir e iterar.

Características de rendimiento diferentes

Las cadenas non-EVM a menudo logran perfiles de rendimiento diferentes:

  • Ejecución paralela — Solana, Sui y Aptos ejecutan en paralelo las transacciones que no entran en conflicto, lo que puede ofrecer mayor rendimiento que el modelo de ejecución secuencial de la EVM.
  • Comisiones más bajas y predecibles — algunas cadenas non-EVM tienen estructuras de comisiones diseñadas desde el principio para un alto rendimiento, evitando los volátiles mercados de comisiones que las cadenas EVM pueden experimentar durante la congestión.
  • Modelos de estado personalizados — las cadenas non-EVM pueden usar modelos de estado optimizados para patrones de acceso específicos. El modelo centrado en objetos de Sui, por ejemplo, permite la propiedad por objeto y el procesamiento paralelo que serían complejos de implementar en la EVM.

Estas ventajas de rendimiento vienen con compensaciones: ecosistemas de desarrolladores más pequeños, herramientas menos maduras, menos firmas de auditoría con experiencia relevante y menos composabilidad con el gran ecosistema de DeFi y tokens basado en EVM.

Por qué importa para los proyectos de IA cripto

La elección de la máquina virtual tiene implicaciones prácticas para los proyectos de blockchain relacionados con la IA:

  • Flexibilidad de ejecución — las cadenas non-EVM pueden admitir modelos de ejecución mejor adaptados a las cargas de trabajo de coordinación de IA. La ejecución paralela, las máquinas de estado personalizadas y los conjuntos de instrucciones de menor sobrecarga pueden servir mejor a las transacciones de alta frecuencia relacionadas con la IA (asignaciones de tareas de cómputo, envíos de resultados, actualizaciones de registros de modelos).
  • Adecuación del lenguaje — las cadenas basadas en Rust se alinean bien con la infraestructura de IA/ML, ya que gran parte de las herramientas de IA (componentes críticos para el rendimiento, coordinación de GPU, programación de sistemas) están escritas en Rust o se interconectan bien con código Rust.
  • Diseño específico de aplicación — las appchains de Cosmos y las subnets de Bittensor permiten a los proyectos de IA construir lógica de ejecución personalizada a nivel de cadena, sin las restricciones del conjunto de opcodes y el modelo de gas de la EVM.
  • Compensaciones de ecosistema — los proyectos non-EVM no pueden aprovechar fácilmente el gran ecosistema de la EVM de protocolos DeFi, bridges de tokens e infraestructura de wallets. Los proyectos de IA en cadenas non-EVM deben construir esta infraestructura ellos mismos, apoyarse en bridges entre cadenas o aceptar un ecosistema inicial más pequeño.

En las fichas de proyecto de DecAIHub, Type: non-EVM le dice al lector que el proyecto no usa Solidity, no puede desplegar en cadenas compatibles con EVM sin reescribir y opera en un ecosistema técnico diferente.

Dónde aparece en las fichas de proyecto de DecAIHub

En las fichas de proyecto de DecAIHub, la designación non-EVM aparece en:

  • Type — non-EVM indica que los contratos inteligentes o la lógica on-chain del proyecto usan una máquina virtual distinta de la EVM. Esto afecta a qué herramientas, lenguajes y estándares se aplican.
  • Main chain — se lista la cadena non-EVM específica (Solana, Bittensor, una cadena Cosmos, Sui, etc.). Cada cadena tiene su propia VM, lenguaje y ecosistema.
  • Token standard — las cadenas non-EVM tienen sus propios estándares de token. Solana usa tokens SPL; las cadenas Cosmos usan denominaciones nativas o CW-20 (CosmWasm); las cadenas basadas en Move usan recursos coin/fungible-asset. Estos no son intercambiables con ERC-20.
  • Smart contracts / lógica on-chain — el lenguaje de programación y el framework difieren de los proyectos EVM. Los programas de Solana se escriben en Rust (Anchor), los contratos de Cosmos en Rust (CosmWasm) o Go, y así sucesivamente.

Lo que una clasificación non-EVM por sí sola no prueba

  • Non-EVM no significa mejor rendimiento. Aunque algunas cadenas non-EVM ofrecen ejecución paralela o comisiones más bajas, el rendimiento depende de la cadena específica, su infraestructura de validadores y la carga actual —no solo de la elección de la VM—.
  • Non-EVM no prueba sofisticación técnica. Elegir una cadena non-EVM es una decisión de infraestructura. No indica la calidad del AI component del proyecto, su código o su producto.
  • Non-EVM no significa que el proyecto no pueda interactuar con cadenas EVM. Muchos proyectos non-EVM usan bridges, oráculos o tokens envueltos (wrapped) para conectarse con Ethereum y otros ecosistemas EVM. La interacción entre cadenas es posible; solo requiere infraestructura adicional.
  • Una VM diferente no significa garantías de seguridad diferentes. Los bugs de contratos inteligentes, los errores de lógica y los riesgos de centralización existen en todas las cadenas independientemente de la máquina virtual. Los lenguajes non-EVM como Rust y Move eliminan algunas clases de bugs pero introducen otras.
  • Una etiqueta non-EVM no explica por qué el proyecto eligió esa cadena. La elección podría estar motivada por necesidades de rendimiento, experiencia del equipo de desarrollo, incentivos del ecosistema o simplemente por dónde empezó el equipo fundador. Sin contexto adicional, la etiqueta por sí sola es informativa, no evaluativa.

No confundir con

  • EVM — la EVM es la Ethereum Virtual Machine. Non-EVM se define en contraste con ella: cualquier cadena que no use la EVM cae en la categoría non-EVM.
  • Ethereum — Ethereum es la cadena EVM original. Ser non-EVM significa que la cadena no es Ethereum y no usa el motor de ejecución de Ethereum —pero aún puede interactuar con Ethereum mediante bridges o protocolos entre cadenas—.
  • Solana — Solana es una blockchain non-EVM específica con su propia máquina virtual (SVM). "Non-EVM" es una categoría amplia que incluye Solana, Cosmos, Sui, Aptos, NEAR, Bittensor y muchas otras.
  • "Anti-Ethereum" — ser non-EVM no es una declaración contra Ethereum. Muchas cadenas non-EVM coexisten con Ethereum y se benefician de la liquidez puenteada (bridged). La elección de la VM refleja prioridades de diseño diferentes, no una oposición ideológica.
  • Incompatible — las cadenas non-EVM no pueden ejecutar bytecode de la EVM de forma nativa, pero esto no significa que estén aisladas. Los bridges entre cadenas, los protocolos de mensajería (como IBC, LayerZero, Wormhole) y los tokens envueltos permiten la interoperabilidad entre los ecosistemas EVM y non-EVM.

Preguntas frecuentes

¿Cuáles son las cadenas non-EVM más comunes usadas por los proyectos de IA cripto?

Solana y Bittensor están entre las cadenas non-EVM que se encuentran con más frecuencia en el espacio de la IA cripto rastreado por DecAIHub. El alto rendimiento de Solana y su ecosistema basado en Rust atraen a proyectos de IA que necesitan coordinación on-chain rápida y de bajo costo. Bittensor está diseñada específicamente para la IA descentralizada, con subnets dedicadas a tareas de IA específicas. Las appchains basadas en Cosmos son otro patrón, particularmente para proyectos que quieren un entorno de ejecución totalmente personalizado con comunicación entre cadenas integrada vía IBC.

¿Puede un proyecto non-EVM también desplegar en cadenas EVM?

Sí, pero requiere una base de código separada. Un proyecto escrito en Rust para Solana no puede desplegarse en Ethereum tal cual —tendría que reescribirse en Solidity (o tener una implementación de Solidity separada)—. Algunos proyectos mantienen contratos tanto en cadenas EVM como non-EVM, pero cada despliegue requiere desarrollo, auditoría y mantenimiento independientes. Los bridges entre cadenas también pueden permitir que los proyectos non-EVM tengan representación de token en cadenas EVM (p. ej., tokens SPL envueltos como ERC-20 en Ethereum).

¿Es non-EVM mejor para las aplicaciones de IA?

No hay una respuesta universal. Las cadenas non-EVM pueden ofrecer ventajas para casos de uso de IA específicos —la ejecución paralela de Solana se adapta a la coordinación de alto rendimiento, la arquitectura de subnets de Bittensor está diseñada específicamente para incentivos de IA, y las appchains de Cosmos permiten lógica de ejecución totalmente personalizada—. Sin embargo, las cadenas EVM ofrecen un ecosistema de desarrolladores más grande, herramientas más maduras, mayor liquidez DeFi y un soporte de wallets más amplio. La mejor elección depende de los requisitos específicos del proyecto: qué cargas de trabajo corren on-chain, qué rendimiento se necesita, qué ecosistema prefiere el equipo y dónde están los usuarios objetivo.

¿Tienen las cadenas non-EVM estándares de token como ERC-20?

Sí, pero diferentes. Solana usa tokens SPL. Las cadenas Cosmos usan denominaciones nativas o tokens CW-20 (vía CosmWasm). Sui y Aptos usan los recursos coin y fungible asset de Move. NEAR usa NEP-141. Cada estándar define cómo se crean, transfieren y gestionan los tokens en esa cadena. Estos estándares no son intercambiables con ERC-20 —un token construido como SPL en Solana no puede usarse directamente en una cadena EVM sin envolverlo (wrapping) o puentearlo (bridging)—.

Referencias externas

Véase también

No comments to display

Back to top