Propuesta de Ethereum busca reducir la ventana de retención de bloques a 36 días para aliviar la carga de los nodos
Puntos clave
- •El borrador de la propuesta reduciría el período obligatorio de retención de bloques de la capa de consenso de 33.024 épocas, unos 147 días, a 8.192 épocas, aproximadamente 36,4 días.
- •La EIP es no bifurcante e informativa: actualiza las expectativas de los operadores de nodos en lugar de las reglas del protocolo, y busca facilitar el relleno posterior a la sincronización desde puntos de control mientras reduce las exigencias de ancho de banda, espacio en disco y sincronización.
- •La propuesta ha entrado en revisión pública con el respaldo inicial del contribuidor Dapplion y del desarrollador de Lighthouse Michael Sproul, pero no se ha fusionado y aún requiere un número oficial de EIP.
- •Los desarrolladores evalúan 66 propuestas de mejora para la actualización Hegotá de 2027, incluidas medidas de privacidad como las Frame Transactions de la EIP-8141, el pool protegido compartido de la EIP-8182 y los nonces con clave de la EIP-8250.
- •Hasta mediados de agosto de 2026, solo la EIP-7805 (FOCIL), un mecanismo de resistencia a la censura que impone listas de inclusión de transacciones, había sido confirmada para Hegotá, antes de la actualización Glamsterdam prevista para el cuarto trimestre de 2026.

El desarrollador de Ethereum Kevaundray Wedderburn presentó el 17 de agosto una nueva propuesta de mejora de Ethereum a través del pull request #12188 de GitHub, en la que pide reducir la ventana de retención de bloques de la capa de consenso (CL).
La propuesta, que por ahora es un borrador a la espera de un número oficial de EIP, reduciría el período de retención obligatorio de 33.024 épocas a 8.192 épocas, aproximadamente 36,4 días. Dado que cada época de la capa de consenso abarca 32 slots de unos 6,4 minutos, el requisito actual equivale a unos 147 días —casi cinco meses— de historial almacenado. La EIP está clasificada como no bifurcante e informativa: en lugar de modificar las reglas del protocolo de Ethereum, actualizaría las expectativas de los operadores de nodos.
El objetivo principal del cambio es reducir la carga de relleno (backfill) que sigue a la sincronización desde puntos de control, la práctica habitual de iniciar un nuevo nodo beacon a partir de un punto de control reciente y confiable en lugar de reproducir la cadena desde el génesis, para luego recuperar los bloques más antiguos. Al acortar el tiempo que los nodos deben conservar los bloques beacon históricos, la propuesta disminuiría las exigencias de ancho de banda, espacio en disco y tiempo de sincronización, en línea con el objetivo declarado de Ethereum de mantener los requisitos de los nodos lo suficientemente ligeros como para fomentar una amplia participación. El borrador también resuena con discusiones anteriores de la capa de ejecución, como la EIP-4444, que propuso que los clientes dejaran de servir datos de bloques históricos con más de un año de antigüedad.
El borrador ha entrado en revisión pública y ha recibido apoyo inicial dentro de la comunidad de desarrolladores. El contribuidor de Ethereum Dapplion respaldó la dirección de la propuesta, mientras que Michael Sproul, desarrollador del cliente Lighthouse, señaló que no prevé problemas operativos para Lighthouse. Sproul añadió que, en una red mixta, los clientes más antiguos seguirían pudiendo sincronizarse con pares que aún conserven la ventana de retención más larga. El pull request no se ha fusionado; los próximos pasos incluirían la asignación de un número oficial de EIP y, en caso de adoptarse, la alineación de los ajustes predeterminados de retención entre las implementaciones de los clientes.
Los desarrolladores evalúan 66 propuestas para la actualización Hegotá de 2027
El borrador sobre la ventana de retención es una de varias propuestas que circulan esta semana en la comunidad de desarrolladores de Ethereum, mientras la atención también se dirige hacia un impulso más amplio para expandir las capacidades a nivel de protocolo de Ethereum de cara a la actualización de red Hegotá prevista para 2027. Las actualizaciones de Ethereum tradicionalmente se lanzan en paquetes, y las listas de candidatas de este tamaño suelen reducirse a medida que avanzan la revisión técnica y las auditorías.
Los desarrolladores evalúan actualmente un paquete de 66 propuestas de mejora de Ethereum para Hegotá, varias de las cuales apuntan a la privacidad on-chain, un área que la red históricamente ha dejado en manos de soluciones de terceros porque su libro mayor público hace que los datos de las transacciones sean visibles para cualquiera por defecto.
La propuesta de privacidad central es la EIP-8141, o "Frame Transactions", que permitiría a los pools de privacidad pagar sus propias tarifas de gas sin depender de relayers externos. Dado que cada interacción con intermediarios crea un rastro de metadatos que puede exponer la información del remitente, eliminar esa dependencia se considera un paso significativo hacia una privacidad de transacciones nativa.
Como complemento, la EIP-8182 introduciría un pool protegido compartido para transferencias anónimas de ETH y tokens ERC-20, mientras que la EIP-8250 propone nonces con clave para impedir que observadores vinculen transacciones privadas separadas mediante el análisis de patrones de nonce.
De las propuestas en revisión, solo la EIP-7805 (FOCIL), un mecanismo de resistencia a la censura que impone listas de inclusión de transacciones, había sido confirmada para Hegotá hasta mediados de agosto de 2026. Las demás propuestas siguen sujetas a revisión técnica y auditorías de seguridad.
Se espera que Hegotá siga a la actualización Glamsterdam, prevista actualmente para el cuarto trimestre de 2026, lo que da a los desarrolladores aproximadamente un año para definir el alcance final del paquete, incluidas las propuestas de privacidad que avanzarán.
Fuente: Metaverse Post