El Fork Hegotá de Ethereum: Cómo los Verkle Trees Podrían Reducir el Almacenamiento de Nodos en un 90% y Habilitar Clientes Sin Estado
Ejecutar un nodo completo de Ethereum en 2026 exige entre 4 y 8 TB de almacenamiento SSD NVMe, de 32 a 64 GB de RAM y una CPU moderna de ocho núcleos. Esa factura de hardware deja fuera a los aficionados, concentra el poder de validación entre operadores con amplios recursos y socava silenciosamente la promesa de descentralización que justifica toda la red. El hard fork Hegotá, programado para finales de 2026, tiene como objetivo cambiar esa ecuación con un único intercambio arquitectónico: reemplazar el Merkle Patricia Trie de 15 años de antigüedad por Árboles Verkle, una estructura de datos criptográfica que podría reducir los requisitos de almacenamiento de los nodos hasta en un 90 % y convertir los clientes de Ethereum "sin estado" en una realidad de producción por primera vez.
El problema del crecimiento del estado que Ethereum ya no puede ignorar
El estado de Ethereum — el registro completo de cada saldo de cuenta, espacio de almacenamiento de contrato y nonce — se ha inflado más allá de los 200 GB, y los datos completos de la cadena (incluyendo el historial) ahora superan los 3 TB en Geth. Los nodos de archivo requieren entre 18 y 20 TB. Cada transacción aumenta esta carga y nada en la arquitectura actual la reduce.
Las consecuencias son medibles. A principios de 2026, Etherscan detecta aproximadamente 14,339 nodos completos a nivel mundial. Estados Unidos alberga el 38.96 % de ellos, Alemania el 14.53 % y China el 14.01 %. Los nodos domésticos crecieron un 18 % interanual, pero la barrera de entrada sigue aumentando. Un validador individual que compró un SSD de 2 TB en 2022 ya se ha visto obligado a actualizarlo — o retirarse.
Este es el problema que la fase Verge de la hoja de ruta de Ethereum fue diseñada para resolver. Y los Árboles Verkle son la pieza técnica central.
Qué cambian realmente los Árboles Verkle
En su esencia, un árbol Verkle se parece al actual Merkle Patricia Trie de Ethereum. Ambas son estructuras de datos en forma de árbol donde cada nodo está vacío, es una hoja (que contiene un par clave-valor) o un nodo intermedio con hijos. La diferencia crítica radica en cómo demuestran que un dato existe en el árbol.
Los Merkle Patricia Trees utilizan pruebas basadas en hashes. Para probar un solo valor, es necesario proporcionar cada nodo hermano a lo largo del camino desde la hoja hasta la raíz — el conjunto completo de "nodos hermanos". Para el trie hexario (ancho 16) de Ethereum, esto significa tamaños de prueba de aproximadamente 150 KB por prueba. A medida que el estado crece, estas pruebas se vuelven más pesadas.
Los Árboles Verkle utilizan compromisos vectoriales basados en criptografía polinómica. En lugar de hashear cada hermano de forma independiente, el probador genera una única prueba compacta que cubre todas las relaciones padre-hijo a lo largo de todo el camino. La implementación propuesta para Ethereum utiliza un ancho de 256 (algunos investigadores abogan por 1,024), lo que hace que el árbol sea más superficial y las pruebas drásticamente más pequeñas.
Los números hablan por sí solos:
| Métrica | Merkle Patricia Trie | Árbol Verkle |
|---|---|---|
| Tamaño de la prueba por valor | ~150 KB | ~1-2 KB |
| Datos del testigo (witness) para un bloque | Megabytes | Kilobytes |
| Ancho del árbol | 16 (hexario) | 256 |
| Estructura de la prueba | Todos los hashes hermanos | Compromiso polinómico único |
Un árbol Verkle puede demostrar la pertenencia a un árbol con mil millones de puntos de datos utilizando menos de 150 bytes. El sistema actual necesita aproximadamente 1 KB en condiciones ideales — y el Patricia Trie de Ethereum está lejos de ser ideal.
Clientes sin estado: El objetivo final
El verdadero premio no son solo las pruebas más pequeñas — es la validación sin estado.
Hoy en día, cada nodo completo de Ethereum debe descargar, almacenar y mantener el trie de estado completo. Cuando llega un nuevo bloque, el nodo vuelve a ejecutar cada transacción contra su copia local del estado para verificar su corrección. Sin estado, no hay verificación.
Los Árboles Verkle cambian esta ecuación. Debido a que las pruebas son lo suficientemente compactas como para incluirse dentro de los propios bloques, un "cliente sin estado" puede verificar un bloque comprobando solo la prueba Verkle adjunta a él — sin almacenar ningún estado en absoluto. El validador recibe el bloque, verifica la prueba contra el compromiso de la raíz y confirma la corrección en milisegundos.
Lo que esto significa en la práctica:
- Almacenamiento casi nulo para validadores: Un nodo de staking podría operar con un espacio de disco mínimo, potencialmente inferior a 1 GB.
- Sincronización instantánea: Los nuevos nodos no necesitarían descargar más de 200 GB de estado. Verifican los bloques a medida que llegan.
- Participación más amplia: La barrera de hardware baja de un "servidor dedicado" a una "Raspberry Pi con buen ancho de banda".
- Mayor descentralización: Más nodos significan más distribución geográfica, más diversidad de clientes y más resiliencia contra la censura.
Vitalik Buterin ha descrito los Árboles Verkle como la clave para habilitar "clientes validadores sin estado" que logren una sincronización casi instantánea. Si la visión se mantiene, ejecutar un nodo validador de Ethereum podría volverse tan simple como verificar unos pocos kilobytes de datos por bloque.
El elefante cuántico en la habitación
No todo el mundo está convencido de que los Árboles Verkle deban implementarse. La objeción más seria proviene de la comunidad de computación cuántica.
Los Árboles Verkle se basan en compromisos polinómicos basados en curvas elípticas — la misma clase de criptografía que las computadoras cuánticas, al ejecutar el algoritmo de Shor, podrían romper teóricamente. Si llega una computadora cuántica suficientemente potente en la próxima década, cada prueba Verkle en Ethereum dejaría de ser confiable y la red necesitaría otra migración más.
Esto ha desencadenado un debate activo dentro de la comunidad de desarrolladores de Ethereum entre dos bandos:
Implementar los Árboles Verkle ahora. Los beneficios son inmediatos y bien comprendidos. Las computadoras cuánticas capaces de romper la criptografía de curva elíptica probablemente estén a 10-15 años de distancia. Ethereum puede adoptar los Árboles Verkle hoy y migrar a estructuras resistentes a la computación cuántica más tarde.
Saltar directamente a árboles de hash binarios con STARK. El EIP-7864 propone reemplazar el trie actual con un árbol binario utilizando una función de hash eficiente (Blake3 o Poseidon). Combinado con pruebas STARK, este enfoque sería resistente a la computación cuántica desde el primer día. Los árboles binarios producen ramas Merkle cuatro veces más cortas que la estructura actual, y un intercambio de funciones de hash podría añadir otra mejora de eficiencia de prueba de entre 3 y 100 veces.
El punto medio pragmático — y la trayectoria actual — parece ser implementar los Árboles Verkle en Hegotá mientras se monitorea el progreso de la computación cuántica y el rendimiento de las pruebas STARK. Si las alternativas basadas en STARK maduran lo suficientemente rápido, un futuro fork podría cambiar el esquema de compromiso sin repetir la migración de estado.
Hegotá en contexto: El ritmo de actualizaciones de Ethereum para 2026
Hegotá representa el segundo hard fork importante de 2026, tras Glamsterdam en la primera mitad del año. Este ritmo de dos forks refleja un cambio deliberado en la filosofía de desarrollo de Ethereum: actualizaciones más pequeñas y frecuentes en lugar de los lanzamientos masivos y retrasados que caracterizaron las eras anteriores.
Glamsterdam (H1 2026) se centra en mejoras de la capa de ejecución: optimizaciones de gas, Listas de Acceso a nivel de bloque (Block-level Access Lists) y la Separación Proponente-Constructor (ePBS) integrada. Se trata de cambios incrementales pero importantes que mejoran el rendimiento de la L1 y la gestión del MEV.
Hegotá (H2 2026) se dirige a la propia capa de estado. Los Verkle Trees (Árboles de Verkle) son el principal candidato para ser la función estrella, aunque también se están debatiendo mecanismos de expiración de estado e historial.
Ambas siguen a las actualizaciones de 2025 —Pectra y Fusaka— que introdujeron PeerDAS y ampliaron la capacidad de blobs para los rollups. Juntos, estos cuatro forks trazan un arco coherente: espacio de blobs para las L2, eficiencia de gas para la L1 y ahora compresión de estado para los operadores de nodos.
La convención de nomenclatura refleja esta continuidad. "Hegotá" combina "Bogotá" (el nombre en clave de la capa de ejecución, en referencia a la ciudad sede de la Devcon 2022) y "Heze" (el nombre en clave de la capa de consenso, en referencia a una estrella). Cada fork de Ethereum desde el Merge ha seguido este patrón de ciudad más estrella.
Qué cambia para los operadores de nodos, stakers y desarrolladores
Los stakers en solitario (solo stakers) son los que más se beneficiarán. Los requisitos actuales de hardware mínimo —32 GB de RAM, SSD de más de 2 TB, internet dedicado— crean una barrera financiera que empuja a muchos hacia protocolos de staking líquido (Lido, Rocket Pool) o exchanges centralizados. Si los Verkle Trees reducen las necesidades de almacenamiento a menos de 100 GB, la economía del staking en solitario cambia fundamentalmente.
Los proveedores de infraestructura de nodos se enfrentan a un cálculo diferente. Las empresas que operan cientos o miles de nodos verán disminuir los costes de hardware, pero deben invertir en actualizaciones de clientes y pruebas de migración. La transición de los Patricia Tries a los Verkle Trees requiere una conversión de estado única que no puede fallar: cualquier error en la migración podría corromper toda la base de datos de estado de Ethereum.
Los desarrolladores de DApps no deberían notar diferencias en el código de sus contratos inteligentes. El trie de estado es una preocupación de la capa de infraestructura, abstraída por las implementaciones de los clientes. Sin embargo, los desarrolladores que crean herramientas que consultan directamente el estado de Ethereum (exploradores de bloques, plataformas de análisis, buscadores de MEV) deberán actualizar su lógica de verificación de pruebas.
Los rollups de L2 se benefician indirectamente. Unas pruebas de estado más pequeñas en la L1 significan una verificación de estado más barata para los rollups que publican pruebas en Ethereum. Esto potencia las reducciones de costes ya logradas mediante los blobs de la EIP-4844, lo que podría situar los costes de las transacciones de L2 por debajo de los 0,0001 $.
El riesgo de la migración
La parte más difícil de los Verkle Trees no es la criptografía, sino la migración.
Ethereum no puede simplemente cambiar las estructuras de datos en un solo bloque. Todo el trie de estado —cada cuenta, cada contrato, cada ranura de almacenamiento— debe convertirse del formato Merkle Patricia al formato Verkle. Se trata de una transformación de varios gigabytes que debe producirse de forma atómica en todos los clientes, validadores y nodos simultáneamente durante el hard fork.
Las actualizaciones anteriores de Ethereum han modificado la forma en que se procesan los datos, pero ninguna ha reestructurado la forma en que se almacenan a este nivel fundamental. La analogía más cercana es el propio Merge, que cambió el mecanismo de consenso de proof-of-work a proof-of-stake, pero el Merge no tocó el trie de estado.
Los equipos de clientes (Geth, Nethermind, Besu, Erigon, Reth) ya están creando herramientas de migración y ejecutando conversiones en redes de prueba. El cronograma de Hegotá les otorga aproximadamente de seis a nueve meses de pruebas desde el momento en que se congelen las funciones. Dada la importancia, esta podría ser la actualización más auditada en la historia de Ethereum.
Mirando hacia el futuro: De Verge a Purge
Los Verkle Trees no son el destino final. Son la tecnología que permite la siguiente fase de la hoja de ruta de Ethereum: el Purge (la Purga).
Una vez que los clientes sin estado (stateless clients) estén activos, Ethereum podrá hacer expirar de forma segura los datos de estado antiguos sin comprometer la seguridad de la red. Los nodos ya no necesitarían almacenar años de estado histórico; podrían verificar nuevos bloques utilizando solo la raíz de estado actual y las pruebas de Verkle. Este mecanismo de "expiración de estado" limitaría permanentemente los requisitos de almacenamiento de Ethereum, independientemente de cuántas transacciones procese la red.
Combinado con la expiración del historial (EIP-4444), que permite a los nodos descartar cuerpos de bloques y recibos anteriores a un umbral configurable, el proceso completo de Verge a Purge podría reducir los requisitos de los nodos de Ethereum a algo que quepa en un smartphone.
Eso todavía está a años de distancia. Pero Hegotá, si se lanza según lo previsto, da el paso más importante: demostrar que Ethereum puede reestructurar fundamentalmente su capa de estado sin romper la red.
BlockEden.xyz opera nodos RPC de Ethereum de alto rendimiento e infraestructura de API, proporcionando a los desarrolladores un acceso fiable a la red a medida que evoluciona a través de actualizaciones como Hegotá. Explore nuestros servicios de API de Ethereum para construir sobre una infraestructura diseñada para lo que viene a continuación.