Vitalik Buterin propone migración de Árbol de Estado Binario y transición a VM RISC-V para la eficiencia del protocolo

El cofundador de Ethereum, Vitalik Buterin, publicó una propuesta técnica detallada abogando por dos importantes actualizaciones del protocolo: la transición del actual Árbol de Merkle Patricia hexario a una estructura de árbol de estado binario, y eventualmente reemplazar la Máquina Virtual de Ethereum por una arquitectura basada en RISC-V.

Las propuestas, descritas en un post de marzo de 2026, buscan abordar los cuellos de botella en la eficiencia de las pruebas, reducir los requisitos de ancho de banda de datos y mejorar las capacidades de verificación en el lado del cliente. Buterin caracterizó la migración al árbol binario como una actualización “omnibus” que incorpora diez años de aprendizaje sobre el diseño del árbol de estado, mientras que posiciona los cambios en la VM como un elemento de hoja de ruta a largo plazo que podría hacer en gran medida innecesarios los precompilados y simplificar la arquitectura del protocolo.

Migración al Árbol de Estado Binario Propuesta para Mejorar la Eficiencia en las Pruebas

Buterin describió la EIP-7864, actualmente en desarrollo, que reemplazaría el Árbol de Merkle Patricia keccak hexario de Ethereum con una estructura de árbol binario que utiliza funciones hash más eficientes. El cambio propuesto reduciría la longitud de las ramas de Merkle en un factor de cuatro, de 512*log(n)/4 a 32*log(n) bytes.

Esta reducción disminuiría los requisitos de ancho de banda de datos para herramientas de verificación en el lado del cliente, incluyendo Helios y sistemas de recuperación de información privada. La eficiencia en las pruebas mejoraría de tres a cuatro veces solo por las ramas más cortas, con ganancias adicionales por la selección de funciones hash. Los candidatos potenciales para funciones hash incluyen blake3, que ofrece aproximadamente tres veces más eficiencia que keccak, o variantes de Poseidon, que podrían proporcionar mejoras de 100 veces en eficiencia, sujeto a análisis de seguridad adicional.

El diseño del árbol binario incorpora agrupamiento en “páginas” que combina ranuras de almacenamiento adyacentes en páginas de 64 a 256 ranuras, representando de 2 a 8 kilobytes de datos. Esta estructura permite que el acceso al almacenamiento logre beneficios de eficiencia similares a la carga y edición de código. Los encabezados de bloques y los primeros aproximadamente 1 a 4 kilobytes de código y almacenamiento residirían en la misma página, potencialmente ahorrando más de 10,000 gas por transacción para aplicaciones descentralizadas que acceden frecuentemente a las ranuras de almacenamiento iniciales.

Otros beneficios citados incluyen la reducción de la varianza en la profundidad de acceso entre contratos grandes y pequeños, una implementación más sencilla en comparación con las estructuras hexarias, y la capacidad de incorporar bits de metadatos necesarios para futuras implementaciones de expiración de estado.

Consideraciones sobre la Transición de la Máquina Virtual a Arquitectura RISC-V

Buterin presentó un argumento para reemplazar la Máquina Virtual de Ethereum con una arquitectura basada en RISC-V, describiendo al EVM como enfrentando limitaciones para satisfacer las necesidades del diseño de propósito general de Ethereum. La propuesta identifica múltiples objetivos de eficiencia para una nueva VM.

Las mejoras en la eficiencia de ejecución en bruto podrían eliminar la mayoría de los requisitos de precompilados. La eficiencia del probador aumentaría, abordando las limitaciones actuales donde los probadores están escritos para RISC-V en lugar de EVM. Las capacidades de prueba en el lado del cliente permitirían a los usuarios generar ZK-proofs sobre el comportamiento de la cuenta bajo condiciones de datos específicas. La simplicidad de implementación se lograría mediante un intérprete RISC-V que requeriría solo unas pocas centenas de líneas de código.

Se delineó una hoja de ruta de despliegue en tres fases. La primera fase limitaría la nueva VM a funciones de precompilado, con aproximadamente el 80 por ciento de los precompilados existentes y nuevos implementados como código NewVM. La segunda fase permitiría a los usuarios desplegar contratos con NewVM. La tercera fase retiraría completamente el EVM, reimplementándolo como un contrato inteligente escrito en la nueva VM.

Los usuarios del EVM mantendrían compatibilidad total hacia atrás durante esta transición, siendo el cambio en el costo de gas la diferencia principal, aunque Buterin señaló que estos serían eclipsados por los trabajos continuos de escalado en los años siguientes.

Contexto de la Evolución del Protocolo y Consideraciones para Desarrolladores

Buterin caracterizó ambas propuestas como soluciones a los mayores cuellos de botella en la eficiencia de las pruebas, que en conjunto representan más del 80 por ciento del overhead en las pruebas. Los cambios se describen como obligatorios para varios casos de uso de pruebas en el lado del cliente.

La migración al árbol binario se enmarcó como una incorporación de aprendizajes de diez años de experiencia en el diseño del árbol de estado. La transición de la VM se posicionó como más especulativa y no consensuada en el presente, con Buterin afirmando que Ethereum seguiría siendo funcional solo con EVM y mejoras en GPU, pero que una VM mejor podría hacer que el protocolo sea “hermoso y grandioso”.

Ambas propuestas enfrentan cronogramas de implementación alineados con la hoja de ruta a largo plazo del estado de Ethereum, con la migración al árbol binario avanzando a través del proceso EIP y la transición de la VM considerada una iniciativa a más largo plazo, pendiente de la finalización de los cambios en el árbol de estado.

Preguntas Frecuentes: Propuestas de Actualización del Protocolo Ethereum

¿Cuál es la diferencia entre el árbol de estado actual de Ethereum y el árbol binario propuesto?

Ethereum actualmente usa un Árbol de Merkle Patricia hexario con hashing keccak. El árbol binario propuesto usaría una estructura binaria con funciones hash más eficientes, reduciendo la longitud de las ramas de Merkle en aproximadamente cuatro veces. Esto disminuye el ancho de banda de datos para la verificación en el lado del cliente y mejora la eficiencia en las pruebas. El diseño binario también agrupa las ranuras de almacenamiento en páginas para un acceso más eficiente.

¿Cómo afectaría una transición de EVM a RISC-V a las aplicaciones existentes de Ethereum?

Bajo la hoja de ruta en tres fases propuesta, las aplicaciones EVM existentes mantendrían compatibilidad total hacia atrás durante toda la transición. La EVM sería reimplementada eventualmente como un contrato inteligente escrito en la nueva VM, permitiendo que los contratos existentes sigan funcionando. El costo de gas cambiaría, pero estos cambios se implementarían junto con otras mejoras de escalado.

¿Qué mejoras de eficiencia podría ofrecer la nueva VM?

Una VM basada en RISC-V podría ofrecer una eficiencia de ejecución en bruto suficiente para eliminar la mayoría de los requisitos de precompilados, mejorar la eficiencia del probador en comparación con las implementaciones actuales de EVM, y capacidades de prueba en el lado del cliente que permitan la generación de ZK-proofs sobre el comportamiento de la cuenta. La implementación sería significativamente más sencilla, con un intérprete que requeriría solo cientos de líneas de código en comparación con la complejidad actual de la EVM.