Hace poco, me di cuenta de que Vitalik lanzó una serie de propuestas bastante audaces sobre la estructura fundamental de Ethereum. Lo interesante aquí es que no son solo mejoras menores, sino que es como "desmontar el motor" mientras el avión vuela a 10.000 metros de altura.

El problema que Vitalik señala es bastante interesante: los desarrolladores de Ethereum llevan mucho tiempo evitando usar EVM si pueden. Cada vez que necesitan agregar una nueva operación criptográfica, en lugar de implementarla en la EVM, solicitan agregar un "contrato precompilado" para evitar completamente la máquina virtual. Esto muestra que la EVM se está convirtiendo en un verdadero cuello de botella.

Vitalik propone dos cambios importantes. Primero, reformar el árbol de estado de Ethereum, ese "sistema de índices" que se revisa cada vez que se verifica un saldo o se valida una transacción. Actualmente usa una estructura bastante compleja llamada Árbol de Patricia Merkle Keccak. Vitalik quiere reemplazarlo por un árbol binario más simple, reduciendo la longitud de las ramas Merkle a aproximadamente una cuarta parte. Al mismo tiempo, cambiar la función hash, pudiendo usar Blake3 o Poseidon. Este cambio reducirá significativamente el ancho de banda necesario para los clientes ligeros.

Pero el segundo cambio es el "gran bombazo": reemplazar la EVM con una arquitectura RISC-V a largo plazo. La lógica es muy simple: si los sistemas de prueba ZK ya usan RISC-V, ¿por qué la máquina virtual debe usar un lenguaje diferente y agregar una capa de traducción entre ellas? Eliminar esta capa de traducción aumentará automáticamente el rendimiento. Vitalik planea tres pasos: primero, ejecutar contratos precompilados en la nueva máquina virtual, luego permitir su implementación directa, y finalmente "jubilar" la EVM, reescribiéndola como un contrato inteligente que funcione en la nueva máquina virtual para garantizar compatibilidad total.

Lo interesante es que Vitalik proporciona una cifra: el árbol de estado y la máquina virtual representan más del 80% del cuello de botella en la prueba de Ethereum. En otras palabras, si no se toca esas dos partes, la escalabilidad de Ethereum en la era ZK se limitará a eso.

Pero no todos están de acuerdo. Offchain Labs, el equipo de desarrollo de Arbitrum, respondió con bastante detalle. Dicen que RISC-V realmente es adecuado para crear pruebas ZK, pero no para servir como "formato de entrega" para contratos. Distinguen entre "conjunto de instrucciones de entrega" y "conjunto de instrucciones de prueba" — dos cosas que no necesitan ser iguales. Offchain Labs propone usar WebAssembly (WASM) para la capa de contratos, ya que WASM funciona eficientemente en hardware estándar, tiene mecanismos de verificación de tipo seguros, y su ecosistema de herramientas ha sido probado en miles de millones de casos. Incluso han implementado un prototipo en Arbitrum: usar WASM como formato de transacción, luego compilarlo a RISC-V para crear pruebas ZK. Ambas capas funcionan de manera independiente.

Offchain Labs también señala un riesgo importante: la tecnología de pruebas ZK cambia muy rápido, y recientemente RISC-V pasó de 32 bits a 64 bits. ¿Qué pasa si en dos años aparece una arquitectura mejor y se ha integrado RISC-V en Ethereum L1 ahora?

El contexto más amplio es que las soluciones de capa 2 están empezando a "reformarse" fuera de Ethereum. Hace un mes, Vitalik preguntó si Ethereum todavía necesita una "ruta L2 especializada". En lugar de entrar en pánico, las L2 están activamente "liberándose de Ethereum", buscando su propia razón de existencia independiente.

Vitalik también admite que reemplazar la EVM aún no cuenta con un amplio consenso entre la comunidad de desarrolladores. La reforma del árbol de estado está más madura, con un borrador concreto, pero reemplazar la EVM con RISC-V todavía está en la etapa de "hoja de ruta". Sin embargo, Vitalik acaba de declarar que Ethereum ya cambió su motor de reacción una vez (The Merge), y que puede hacer aproximadamente cuatro cambios más: el árbol de estado, la optimización del consenso, la verificación ZK-EVM, y la sustitución de la máquina virtual.

Se espera que la actualización Glamsterdam se implemente en la primera mitad de 2026, seguida por Hegota. La reforma del árbol de estado y la optimización de la capa de ejecución son las principales direcciones ya definidas. La verdadera cuestión no es "si es posible", sino cómo quitar las piezas de parche. Ethereum ha demostrado esta capacidad al pasar de PoW a PoS, de L1 todo a centrarse en Rollups. Esta vez, está excavando los cimientos antiguos para reconstruirlos, no solo añadiendo nuevas funciones. Es una reforma con visión a largo plazo, y la respuesta probablemente será clara en 2027. Pero al menos una cosa está clara: Ethereum no pretende convertirse en un "sistema antiguo que necesita parches" en la era ZK.