Durante casi una década, la Ethereum Virtual Machine —la famosa EVM— ha sido el motor de todo lo que conocemos como Ethereum. Contratos inteligentes, finanzas descentralizadas, identidades en blockchain, DAOs y NFTs: todo se construyó sobre ella. Sin embargo, este entorno de ejecución, que alguna vez fue sinónimo de innovación, ahora se ha convertido en una reliquia técnica con limitaciones profundas que afectan tanto al rendimiento como a la seguridad y escalabilidad de la red.
Lo que comenzó como una máquina virtual ligera y funcional se ha transformado en un entorno frágil, difícil de auditar y casi imposible de optimizar. Algunas de sus instrucciones, como SELFDESTRUCT, siguen presentes a pesar de haber sido ampliamente criticadas por introducir riesgos graves de seguridad. Otras, como los opcodes arbitrarios y la estructura profunda de stacks, han hecho que auditar contratos inteligentes complejos sea una tarea de élite.
Y lo más importante: la EVM no fue pensada para lo que viene. Las tecnologías de pruebas de conocimiento cero —las famosas ZK proofs—, clave para la escalabilidad y la privacidad en la nueva era de las blockchains, simplemente no encajan bien con la arquitectura actual de la EVM. Es como tratar de enseñar física cuántica con una calculadora Casio de los 80.
Vitalik Buterin no ha sido tímido al respecto. En una propuesta reciente publicada en Ethereum Magicians, planteó abiertamente la necesidad de reemplazar la EVM por completo. No refactorizarla. No “mejorarla”. Reemplazarla.
Y lo hizo con la frialdad quirúrgica de alguien que sabe que ya no hay vuelta atrás. El sistema está roto, afirma. Y no se puede arreglar.
En su lugar, aparecen dos nombres: RISC-V y Cairo.
RISC-V, una arquitectura abierta, simple y modular, ha sido adoptada por la comunidad hardware por su eficiencia y flexibilidad. Vitalik propone algo radical: usar RISC-V como nueva base para ejecutar contratos inteligentes, beneficiándose de su compatibilidad con herramientas modernas como LLVM y Rust, su simplicidad extrema y —sobre todo— su adaptabilidad a las pruebas ZK.
La propuesta no busca solo mejorar el rendimiento: busca rediseñar Ethereum desde las tripas, dotarlo de un entorno que no solo soporte el futuro, sino que lo anticipe.
Junto a RISC-V, aparece Cairo, el lenguaje desarrollado por StarkWare, núcleo de StarkNet. Aunque más especializado, Cairo tiene una ventaja única: fue creado desde cero para ser ZK-native. Su diseño está pensado para que toda ejecución sea demostrable criptográficamente, sin confianza entre partes. Un cambio no solo técnico, sino filosófico.
Pero esta visión no está construida en el vacío. El diagnóstico de Vitalik se apoya en un análisis técnico sólido de las limitaciones actuales:
1. Problemas estructurales de la EVM
Diseñada en 2015, la EVM enfrenta limitaciones técnicas graves:
- Complejidad heredada: Opcodes obsoletos como SELFDESTRUCT y estructuras de stack profundas que dificultan las auditorías y optimizaciones.
- Ineficiencia con ZK-proofs: Hasta el 50 % de los ciclos computacionales en sistemas zkEVM se malgastan traduciendo bytecode EVM a RISC-V.
- Rigidez arquitectónica: El diseño de 256 bits, originalmente pensado para operaciones criptográficas, hoy es una carga estructural que añade sobrecarga innecesaria.
Estos factores no solo complican el mantenimiento: generan cuellos de botella que encarecen el gas en hasta 100 veces respecto a arquitecturas modernas.
2. RISC-V: La alternativa modular
RISC-V no es solo una arquitectura elegante; es una plataforma versátil que permite una ejecución mucho más eficiente y flexible. Su integración en Ethereum supondría:
- Ejecución nativa de contratos compilados desde Solidity o Vyper, sin necesidad de traducciones intermedias.
- Syscalls especializados diseñados específicamente para blockchain (acceso a storage, balances, eventos, etc.).
- Compatibilidad con LLVM, lo cual permite aprovechar toda la infraestructura de compilación y depuración moderna.
Ventajas concretas:
- Eliminación de la traducción EVM → RISC-V en pruebas ZK, reduciendo los ciclos en un ~90 %.
- Aumento del rendimiento: operaciones como calldatacopy se ejecutan entre 10x y 100x más rápido.
- Acceso a tooling de bajo nivel: integración con GDB, Rust, Clang, y análisis estático profesional.
3. Cairo: El enfoque ZK-nativo
Cairo, por su parte, apuesta por una lógica completamente distinta: reemplazar no solo la VM, sino también el lenguaje, por uno diseñado exclusivamente para computación verificable:
- Lenguaje fuertemente tipado inspirado en Rust, con ownership model.
- Pruebas STARK generadas de forma nativa, sin capas adicionales.
- Sierra, una capa intermedia que garantiza verificabilidad paso a paso.
Su rendimiento en pruebas ZK supera ampliamente al de la EVM, mostrando eficiencias de 30 a 50 veces mejores en entornos de alto volumen criptográfico.
4. Comparativo técnico: RISC-V vs Cairo
| Parámetro | RISC-V | Cairo |
|---|---|---|
ZK-efficiency | ~10-100x vs EVM | ~30-50x vs EVM |
Interoperabilidad | Compatible con EVM vía wrappers | Requiere reescritura completa |
Lenguajes soportados | Solidity, Vyper, Rust | Cairo (nuevo DSL) |
Costo de transición | Gradual (coexistencia con EVM) | Disruptivo |
5. Plan de transición propuesto por Vitalik
La propuesta contempla una evolución no disruptiva en cuatro fases:
- Coexistencia dual: Permitir que contratos EVM y RISC-V convivan con interoperabilidad.
- Intérpretes EVM-on-RISC-V: Ejecutar contratos existentes sin modificar nada, encapsulándolos dentro de la nueva VM.
- Precompilados optimizados: Añadir funciones específicas para mejorar el rendimiento de pruebas ZK y operaciones criptográficas.
- Desactivación progresiva de la EVM: Incentivar el uso de RISC-V para nuevas DApps, manteniendo soporte para lo legacy.
6. Desafíos técnicos por resolver
A pesar del potencial, el cambio presenta retos importantes:
- Falta de syscalls especializados: RISC-V aún no tiene instrucciones nativas para lógica blockchain.
- Nuevo modelo de gas: Es necesario rediseñar la economía de ejecución con base en los ciclos reales de RISC-V.
- Portabilidad de funciones precompiladas: Migrar funciones como firmas con curvas elípticas será clave.
- Optimización para pruebas ZK: Aun siendo mejor que la EVM, RISC-V necesita ajustes para maximizar eficiencia en circuitos como Halo2 o Nova.
7. Impacto en el ecosistema Ethereum
- Desarrolladores: Mantendrán Solidity y Vyper, pero ganarán acceso a herramientas como Rust y LLVM.
- Rollups ZK: Costes operativos se reducirán hasta en un 80 % eliminando capas de traducción.
- Infraestructura: Se abrirá la puerta a nodos con aceleradores ASIC/FPGA optimizados para RISC-V.
- Competencia: Ethereum podrá igualar (e incluso superar) el rendimiento de blockchains como Solana, con decenas de miles de TPS teóricos.
En síntesis: lo que propone Vitalik no es una simple refactorización del código. Es una cirugía a corazón abierto. Una oportunidad para rediseñar Ethereum desde su capa más profunda y dotarlo de una arquitectura que le permita sobrevivir, escalar y liderar en la próxima década. El reemplazo de la EVM por RISC-V (y posiblemente Cairo en ciertos contextos) no solo resolvería problemas de eficiencia y auditabilidad: permitiría que Ethereum adopte un nuevo paradigma basado en pruebas criptográficas nativas, modularidad extrema y rendimiento real.
Ethereum nació como una promesa. Pero para cumplirla, tal vez tenga que morir una parte de sí mismo. Y renacer como algo mucho más potente.