Un borrador de propuesta presentado por investigadores de Ethereum el 21 de octubre tiene como objetivo reducir el tiempo esperado de finalización de transacciones de la red de aproximadamente 16 minutos a unos cuatro, al convertir sus dos procesos de votación de consenso en flujos de mensajes separados. El borrador de Decoupled Consensus permanece abierto y sin fusionar.

Ben Edgington, quien describe su papel como coordinador del trabajo de finalización rápida de Ethereum, abrió el pull request y coescribió el borrador con Francesco D'Amato, Roberto Saltini, Yann Vonlanthen y Mikhail Kalinin. Su nota en el pull request dice que "muchos aspectos permanecen por definir (TBD)" y que el objetivo inmediato es obtener un número de EIP. Un revisor en el repositorio de EIPs propuso el 8453 el mismo día y pidió a los autores que abrieran un hilo de discusión en Ethereum Magicians, el foro donde se debaten las propuestas.

Por qué la finalización todavía toma unos 16 minutos

La finalización marca el punto antes del cual los validadores de Ethereum no revertirán los bloques. Alcanzarla requiere dos rondas de votación —una para justificar un checkpoint y otra para finalizarlo— y cada ronda dura una época de 32 slots de doce segundos. En una publicación del 11 de mayo en el blog de consenso de protocolo de la Ethereum Foundation, Edgington situó el mínimo en 768 segundos y el tiempo esperado para una transacción en unos 960, con 63 a 95 de los bloques más recientes sin finalizar en condiciones normales.

Esos bloques recientes aún pueden reorganizarse: los nodos pueden cambiar a una secuencia de bloques en competencia, enviando las transacciones de los bloques descartados de vuelta a la mempool para ser incluidas nuevamente. Los bloques finalizados son mucho más difíciles de modificar. Revertir uno requeriría que atacantes posean más de un tercio de todo el stake, y les costaría al menos un tercio de todo el ETH en stake mediante slashing.

La misma publicación describe una regla de confirmación rápida diseñada para dar una señal más temprana. Cuando la red funciona sin problemas y ningún atacante es demasiado poderoso, debería indicar en unos 13 segundos que un bloque no será reorganizado. No conlleva penalización económica para los atacantes y no tolera retrasos en la red, por lo que durante problemas de redcede a la finalización completa — justamente cuando los servicios más necesitan certeza.

Los servicios que actúan sobre transacciones de Ethereum eligen, por lo tanto, cuánto del tiempo de espera de finalización aceptan. La publicación enumera varios ejemplos, incluido el Cross-Chain Transfer Protocol (CCTP) de Circle para USDC. (Fuente: Ben Edgington, blog de consenso de protocolo de la Ethereum Foundation, mayo de 2026.)

Una finalización más rápida reduciría la brecha entre esas rutas, tanto para puentes de stablecoins como para productos tokenizados más nuevos, como los depósitos bancarios que JPMorgan lleva a Ethereum. Edgington espera que el bridging entre cadenas muestre las mejoras más visibles.

Una atestación se convierte en dos mensajes

El diseño de consenso actual de Ethereum, Gasper, empaqueta dos votos en cada atestación de validador. Uno alimenta a LMD GHOST, la regla de elección de bifuración que indica al próximo proponente sobre qué bloque construir. El otro alimenta a Casper FFG, el proceso más lento que finaliza los checkpoints. Como ambos viajan juntos, la elección de bifuración se basa en atestaciones de unos 30,000 validadores por slot, aunque los investigadores detrás del borrador dicen que muchos menos bastarían.

El borrador de EIP convierte esos votos en mensajes separados que viajan por la red y se procesan de forma independiente:

• Votos de head. Un comité de unos 512 validadores por slot, sorteado con probabilidades proporcionales al saldo efectivo de cada validador —el stake que el protocolo le acredita— decide qué bloque es la cabeza de la cadena y qué bloques recientes están confirmados.
• Atestaciones de finalización. El conjunto completo de validadores decide qué bloques están justificados y finalizados, en rondas con su propio calendario, y cada paso requiere al menos dos tercios del stake activo.

Con su propio calendario, la ronda de finalización puede usar el ancho de banda durante todo el período de votación y acortarse después sin rediseñar cómo funcionan los slots. El objetivo inicial de los autores es una reducción de al menos cuatro veces en el tiempo de finalización, sujeta a parámetros que aún deben especificar. Aplicado a la expectativa actual de 16 minutos, un recorte de cuatro veces significaría unos cuatro minutos, aunque el borrador mismo no da una cifra.

Dónde encaja el recorte de cuatro veces en un plan más amplio

En la misma publicación de mayo, Edgington planteó la ambición a más largo plazo: reducir el tiempo de finalización de unos 1,000 segundos a unos 10. Lo presentó como su opinión personal y no como una hoja de ruta oficial.

Escribió que diseños anteriores como la finalización de un solo slot y de tres slots fracasaron porque exigían resolver todos los problemas a la vez. El nuevo enfoque escalona el trabajo. "La finalización desacoplada es el gran desbloqueo", escribió, esperando que ese paso por sí solo aporte una aceleración de un solo dígito bajo, en línea con el de cuatro veces del borrador. Mejoras adicionales vendrían de actualizaciones separadas:

• Consolidación de validadores: desde la actualización Electra, los grandes operadores pueden fusionar hasta 64 validadores en uno, reduciendo el número de votos de finalización. Edgington calificó el progreso de lento.
• Agrupación de votos en el origen: los operadores que ejecutan muchos validadores detrás de un solo nodo combinarían sus votos antes de transmitirlos.
• Rotación del conjunto de validadores: solo un subconjunto de validadores participaría en la finalización en cada momento, sin excluir ni limitar a nadie.
• Redes y agregación más rápidas: mejoras peer-to-peer y la agregación basada en SNARKs moverían los votos de manera más eficiente.
• Finalización de una sola ronda: una ronda de votación en lugar de dos casi reduciría a la mitad la espera, a costa de bajar la tolerancia a fallos de un tercio del stake a quizás 20% o 17%.

El borrador mismo no incluye ninguno de estos pasos. Según los cálculos de Edgington, cuatro mejoras que aporten cada una una ganancia de tres veces se acercarían a la ambición de cien veces. También señaló que la hoja de ruta Strawmap listaba el consenso desacoplado como candidato principal para la actualización provisionalmente etiquetada I*, probablemente en 2027, como objetivo aspiracional.

Por qué Ethereum no se detendrá para ir más rápido

Los protocolos clásicos de tolerancia a fallos bizantinos como Tendermint finalizan los bloques rápidamente, pero dejan de producirlos cuando demasiados validadores se desconectan. El investigador Luca Zanolini argumentó en una publicación de marzo en el foro de Ethereum Research que detenerse es incompatible con el diseño de Ethereum. Señaló un límite demostrado conocido como el dilema disponibilidad-finalización: ningún protocolo único puede seguir creciendo mientras la participación sube y baja y al mismo tiempo mantenerse seguro ante una división de la red. La respuesta de Ethereum es una capa que sigue construyendo bloques con los validadores que estén en línea y otra que finaliza por detrás.

Zanolini citó el historial de la red. En mayo de 2023, errores en los clientes Prysm y Teku, que juntos ejecutaban más de la mitad de los validadores, perturbaron la finalización y desencadenaron la primera fuga de inactividad en la mainnet de Ethereum. Las propuestas de bloques nunca cayeron por debajo de aproximadamente 90% de los slots y las transacciones siguieron procesándose. En cambio, Solana no produjo bloques durante cinco horas en su caída de febrero de 2024, dejando los protocolos DeFi de la red sin poder operar.

Decoupled Consensus mantiene ese arreglo. La finalización sigue necesitando el quórum de dos tercios, por lo que una interrupción lo suficientemente grande puede detenerla mientras los validadores restantes siguen construyendo bloques. La mayoría de las aplicaciones pueden seguir funcionando, pero cualquier cosa que requiera liquidación final tiene que esperar. Si la participación no se recupera, la fuga de inactividad reduce gradualmente el stake de los validadores desconectados hasta que la finalización pueda reanudarse. Cómo funcionaría la fuga bajo el nuevo diseño aún está por escribirse.

La razón poscuántica va primero

La finalización más rápida atrae la atención, pero es la tercera en la lista de los autores. El pull request nombra primero una base para una futura transición poscuántica y segundo la seguridad de la elección de bifuración, y la motivación del borrador sigue el mismo orden.

La conexión es la agregación de firmas. Los validadores firman con BLS, un esquema que permite fusionar muchas firmas en una sola firma compacta. Zanolini escribió que ningún esquema poscuántico ofrece una agregación comparable en tamaños prácticos. Un comité de votos de head de unos pocos cientos de validadores evita el problema porque sus firmas pueden enviarse una junto a otra. Argumentó que esto podría permitir una versión poscuántica de la capa de producción de bloques antes de que alguien resuelva la agregación para los votos de finalización del conjunto completo de validadores. El borrador prepara ese camino pero no selecciona un esquema de firmas poscuántico.

Nuevas defensas con un objetivo más pequeño

La elección de bifuración actual conserva el último voto de cada validador sin límite de antigüedad. Según el borrador, eso permite a los atacantes retener votos y liberarlos en momentos estratégicos para inclinar a los nodos hacia una rama elegida. Bajo la propuesta, la elección de bifuración solo cuenta votos de un slot reciente, con plazos especificados para su llegada.

Los candados protegen los bloques que la cadena ha confirmado. Un bloque queda rápidamente fijado (fast-locked) cuando al menos la mitad del comité de ese slot envía votos de head oportunamente a su favor, sin que ningún validador vote en ambas direcciones. Los candados expiran, y votos recientes por un bloque en competencia pueden mover un candado a un bloque anterior, permitiendo que la cadena se recupere a medida que cambian las condiciones. Los proponentes también llevarían votos recientes en sus bloques para alinear las opiniones de los validadores. Esta técnica, llamada view-merge, reemplaza al proposer boost —el peso adicional en la elección de bifuración que actualmente se otorga a un bloque oportuno— y apunta a los ataques de balanceo y de reorganización.

El comité más pequeño es el contrapeso. Menos votantes significa menos trabajo de firmas en cada slot, pero aumenta la probabilidad de que un sorteo aleatorio entregue a un atacante una porción desproporcionada de un comité, y da a los atacantes un grupo más pequeño al que derribar con ataques de denegación de servicio. Elegir comités de forma privada mediante una función aleatoria verificable es una opción en estudio. El tamaño tampoco está decidido: publicaciones de investigación anteriores esbozaban unos 256 validadores, y el borrador deja abiertos tanto su cifra de 512 como el método de selección.

Qué debe suceder antes de cualquier actualización

Activar Decoupled Consensus requeriría un hard fork en la capa de consenso, con clientes de consenso y de validadores soportando nuevas obligaciones de votación, formatos de bloque y de estado y reglas de elección de bifuración. Las recompensas y penalizaciones, las condiciones de slashing, los parámetros de temporización y de candados, las reglas de transición del fork, los casos de prueba ejecutables y un análisis completo de seguridad y vivacidad aún están por escribirse. Una especificación en progreso se encuentra en una rama de características de las especificaciones de consenso de Ethereum. El borrador mantiene sin cambios el presupuesto total de recompensas de validadores, aunque los pagos podrían desplazarse entre los votos de head y las obligaciones de finalización.

El mayor contrapeso está más allá de este borrador. Edgington ha escrito que quiere una finalización lo suficientemente rápida sin excluir a los stakers caseros, a los stakers individuales ni a quienes están en ubicaciones remotas, y que la comunidad puede que en algún momento tenga que sopesar una finalización aún más rápida frente a la diversidad del staking.

Qué observar a continuación

• Estado del EIP: si el pull request se fusiona como Draft bajo el número 8453 y se abre un hilo de discusión en Ethereum Magicians.
• Trabajo de especificación: avance en las secciones de recompensas, slashing y fuga de inactividad que aún figuran como TBD.
• Alcance de la actualización: si los desarrolladores principales eligen el consenso desacoplado como tema principal para I*. Perderse esa lista retrasaría el objetivo aspiracional de 2027.