Cómo el próximo gran cambio de Ethereum podría transformar toda la industria de la cadena de bloques

Ethereum se encuentra en un punto de inflexión tecnológico crítico. Después de años confiando en la Máquina Virtual de Ethereum (EVM) como su columna vertebral computacional, la red enfrenta una presión creciente para transicionar hacia un modelo de ejecución fundamentalmente diferente, basado en la arquitectura RISC-V, específicamente optimizado para sistemas de pruebas de conocimiento cero.

Esto no es una actualización menor del protocolo. Es una reestructuración completa de cómo Ethereum procesa las transacciones y valida los cambios de estado. Y el momento importa: a medida que las soluciones de Capa 2 se multiplican y la tecnología de conocimiento cero madura, la arquitectura actual de la EVM comienza a mostrar sus limitaciones de maneras que no eran evidentes hace solo dos años.

Por qué la EVM se está convirtiendo en un cuello de botella

La EVM fue revolucionaria cuando se lanzó. Permitió todo el ecosistema de contratos inteligentes. Pero un diseño con una década de antigüedad acumula deuda técnica, y la aparición de sistemas de pruebas de conocimiento cero ha puesto al descubierto ineficiencias arquitectónicas que ahora son imposibles de ignorar.

El problema principal es sencillo: demostrar la ejecución de la EVM mediante circuitos ZK introduce una sobrecarga enorme. Las implementaciones actuales de zkEVM no prueban directamente la EVM en sí misma. En cambio, prueban un intérprete de la EVM, que en última instancia se compila en código RISC-V. Como ha señalado Vitalik Buterin, esto crea una capa de abstracción innecesaria que puede reducir el rendimiento en un 50 a 800 veces en comparación con pruebas nativas en RISC-V.

Incluso después de optimizar otros componentes—cambiando a funciones hash más rápidas como Poseidon—la ejecución de bloques aún representa entre el 80 y el 90 % del tiempo total de generación de pruebas. La sobrecarga del intérprete se ha convertido en el principal cuello de botella que impide que Ethereum escale mediante la verificación ZK en L1.

La trampa de la complejidad: acumulación de deuda técnica

Más allá del rendimiento, Ethereum ha acumulado otro problema: contratos precompilados. Son funciones codificadas de forma fija para compensar ineficiencias de la EVM en operaciones criptográficas específicas. Cada adición resolvió temporalmente una necesidad inmediata, pero gradualmente infló la base de código de confianza de Ethereum con soluciones especializadas y únicas.

El código envoltorio para un solo contrato precompilado como modexp es supuestamente más complejo que toda la implementación del intérprete RISC-V. Agregar nuevas funciones precompiladas requiere un proceso de bifurcación dura (hard fork) polémico, creando fricciones políticas y ralentizando la innovación en aplicaciones que necesitan nuevos primitivas criptográficas.

El diseño arquitectónico de la propia EVM también conlleva responsabilidades. Su diseño de pila de 256 bits tenía sentido para manejar valores criptográficos, pero es tremendamente ineficiente para enteros de 32 o 64 bits que se usan en la mayoría de los contratos inteligentes. En sistemas de conocimiento cero, estas ineficiencias son particularmente costosas: números más pequeños consumen los mismos recursos, pero aumentan la complejidad de dos a cuatro veces.

Por qué RISC-V surge como la solución

RISC-V no es una invención propietaria construida específicamente para Ethereum. Es un conjunto de instrucciones de código abierto que ya se ha convertido en la arquitectura de facto para máquinas virtuales de conocimiento cero. Entre las diez zkVMs capaces de probar bloques de Ethereum, nueve ya han estandarizado en RISC-V.

Este consenso de mercado señala algo importante: adoptar RISC-V no es una apuesta especulativa. Es alinearse con una infraestructura que todo el ecosistema de conocimiento cero ya ha validado mediante despliegues reales.

La atracción es multifacética:

Diseño minimalista: El conjunto de instrucciones básico de RISC-V contiene solo unas 47 instrucciones principales, en comparación con la complejidad implícita de la EVM. Un código de confianza más pequeño es mucho más fácil de auditar, probar y verificar formalmente—crucial para proteger miles de millones en valor en cadena.

Ecosistema maduro: Al adoptar RISC-V, Ethereum obtiene acceso inmediato a la infraestructura del compilador LLVM. Esto significa que millones de desarrolladores familiarizados con Rust, C++, Go y Python pueden escribir directamente para L1 sin aprender un nuevo lenguaje o entorno. La experiencia de desarrollo sería similar a la de desarrollo multiplataforma con NodeJS.

Ventajas de la verificación formal: A diferencia de la especificación del Yellow Paper de la EVM (escrita en lenguaje natural con ambigüedades inherentes), RISC-V cuenta con una especificación legible por máquina en SAIL. Este “estándar de oro” permite pruebas matemáticas estrictas de corrección—el santo grial de la seguridad en blockchain que traslada la confianza de la implementación humana a una prueba verificable.

Ruta de optimización de hardware: La arquitectura soporta aceleración mediante ASICs y FPGAs, permitiendo infraestructura especializada para generación de pruebas (similar al trabajo en curso en Succinct Labs, Nervos y Cartesi).

El plan de migración en tres fases

La transición de Ethereum no será revolucionaria, sino evolutiva. Vitalik Buterin ha delineado un enfoque cuidadoso y por fases:

Fase 1 - Despliegue limitado: RISC-V entra como una alternativa precompilada, reemplazando nuevas adiciones de contratos precompilados. Este entorno de prueba de bajo riesgo permite a la red ganar confianza en el nuevo sistema, manteniendo compatibilidad total con la EVM. Solo programas RISC-V específicos y preaprobados se ejecutan a través de rutas de ejecución en lista blanca.

Fase 2 - Coexistencia: Los contratos inteligentes pueden declarar su bytecode como EVM o RISC-V. Los dos sistemas coexisten e interoperan sin problemas mediante llamadas al sistema (ECALL), permitiendo que contratos en diferentes arquitecturas se llamen entre sí. Este entorno híbrido permite a los desarrolladores migrar gradualmente sin decisiones inmediatas.

Fase 3 - Capa nativa: La EVM se convierte en un contrato simulado que se ejecuta en RISC-V (la estrategia de “Rosetta”). Las aplicaciones legadas se ejecutan sin cambios, pero el motor de ejecución subyacente se simplifica a un solo núcleo RISC-V, reduciendo drásticamente la complejidad y la carga de mantenimiento para los desarrolladores de clientes.

Quién gana y quién enfrenta dificultades en la nueva era

Este cambio arquitectónico tendrá consecuencias muy diferentes para distintas soluciones de Capa 2.

Las Rollups de conocimiento cero ganan ventaja estructural. Proyectos como Polygon, zkSync y Scroll ya han estandarizado internamente en RISC-V. Una L1 que “habla el mismo idioma” permite una integración nativa con una complejidad de puente mínima. La reutilización de herramientas, la compatibilidad del compilador y la alineación de incentivos económicos trabajan a su favor. Uma Roy, cofundadora de Succinct Labs, ha demostrado esta ventaja con OP Succinct, que añade capacidades de prueba de conocimiento cero a Rollups optimistas—reduciendo los tiempos de retiro de siete días a aproximadamente una hora.

Las Rollups optimistas enfrentan decisiones más difíciles. Arbitrum y Optimism dependen de pruebas de fraude ejecutadas mediante la EVM de L1 para resolver disputas. Si la EVM desaparece, todo este modelo de seguridad requiere ser reconstruido. Estos equipos deben diseñar nuevos sistemas de prueba de fraude dirigidos a la nueva arquitectura L1 o desacoplarse fundamentalmente de las garantías de seguridad de Ethereum—ninguna opción es trivial.

Impacto económico: costos más bajos, mayor rendimiento

Para los usuarios finales, la transición se traduce en beneficios tangibles.

Se espera que los costos de generación de pruebas disminuyan aproximadamente 100 veces—de varios dólares por transacción a centavos o menos. Esto reduce directamente las tarifas de L1 y, más importante aún, los costos de liquidación en L2. Las ganancias de eficiencia permiten la visión de un “Gigagas L1”: aproximadamente 10,000 TPS a costos razonables, desbloqueando aplicaciones que actualmente son demasiado caras para ejecutarse en cadena.

Los desarrolladores obtienen acceso a una cadena de herramientas mucho más amplia. Construir código en cadena y fuera de cadena en el mismo lenguaje se vuelve una práctica estándar en lugar de una excepción. Este “modelo NodeJS” para desarrollo en blockchain atrae a nuevos creadores y acelera la innovación en aplicaciones.

Los riesgos críticos que nadie debe ignorar

Esta transformación presenta nuevos desafíos que requieren atención seria.

Medición de gas más difícil matemáticamente. Diseñar un modelo de gas justo y determinista para conjuntos de instrucciones de propósito general no está resuelto. Contar instrucciones simples invita a ataques de denegación de servicio—los atacantes pueden crear programas que disparen fallos repetidos de caché, consumiendo recursos masivos con un gas mínimo. Esto amenaza la estabilidad de la red y la integridad económica.

La seguridad de la cadena de herramientas ahora forma parte del modelo de amenazas. La responsabilidad de seguridad pasa de las máquinas virtuales en cadena a compiladores fuera de cadena como LLVM. Estos son sistemas de software extraordinariamente complejos con vulnerabilidades conocidas. Los atacantes podrían explotar errores del compilador para transformar código fuente benigno en bytecode malicioso indetectable mediante auditorías estándar.

Las compilaciones reproducibles siguen sin resolverse. Garantizar que los binarios compilados coincidan exactamente con el código fuente público es técnicamente desafiante. Variaciones ambientales menores producen salidas diferentes, socavando la transparencia y la confianza—justo lo que blockchain debería resolver.

Estos riesgos exigen una defensa en múltiples capas: despliegues por fases que minimicen daños irreversibles, pruebas continuas de fuzzing que descubran vulnerabilidades (la firma de seguridad Argus reportó la detección de 11 fallos críticos de solidez en zkVMs líderes), y la verificación formal que eventualmente refuerce las garantías teóricas.

El camino práctico a seguir: el plan de Succinct Labs

Esta transformación no es solo teórica. Los equipos ya están construyendo la infraestructura. SP1 de Succinct Labs es una zkVM de producción, de código abierto, que demuestra que la generación de pruebas basada en RISC-V funciona a escala. SP1 adopta una filosofía “centrada en precompilados”—descargando operaciones intensivas como el hash Keccak a circuitos ZK especializados y optimizados manualmente, que se pueden llamar mediante instrucciones estándar—combinando rendimiento de hardware personalizado con flexibilidad de software.

Su trabajo prueba el concepto y establece la viabilidad económica a través de la Red de Proveedores de Pruebas (Succinct Prover Network), un mercado descentralizado para generación de pruebas que muestra cómo será la capa de infraestructura futura.

La visión más amplia: Ethereum como capa de cómputo verificable

Esta transición replantea el papel fundamental de Ethereum. En lugar de seguir siendo principalmente una plataforma de ejecución de contratos inteligentes, Ethereum se convierte en la capa de confianza para cómputo verificable general—lo que Vitalik llama el fin del “Snarkify everything”.

Esto se alinea con la filosofía más amplia de “Ethereum Lean”: simplificar sistemáticamente el protocolo en tres módulos claros (Consenso Lean, Datos Lean, Ejecución Lean). Al eliminar la EVM y adoptar RISC-V, Ethereum afila su propósito central: liquidación eficiente y disponibilidad de datos para un universo de aplicaciones verificables.

El cambio reconoce una verdad fundamental: en un futuro dominado por pruebas de conocimiento cero, las primitivas computacionales importan. Ethereum puede resistir la evolución tecnológica inevitable o adoptarla estratégicamente. La hoja de ruta discutida en conferencias y foros de investigación de EthProofs sugiere que la Fundación Ethereum y el equipo central han optado por esta última vía.

No es un cambio de la noche a la mañana. Es una transformación de varios años que requiere coordinación, implementación por fases y una verdadera aceptación de la comunidad. Pero el caso técnico es cada vez más difícil de refutar, y los incentivos competitivos de soluciones de Capa 2 ya optimizadas para RISC-V generan una presión creciente para alinear la arquitectura de L1 con el futuro que ya está construyendo el ecosistema.

La pregunta ya no es si esto sucederá, sino qué tan cuidadosamente y deliberadamente Ethereum gestionará la transición—y si la comunidad podrá ejecutar esta ambiciosa reestructuración manteniendo la confianza y estabilidad en las que dependen miles de millones en valor.