¿Acelerar sin sacrificar la descentralización? EIP-8198 de Ethereum: primero ajustar el tiempo, luego reducir el bloque

Por Ethlabs

Compilado por AididiaoJP, Foresight News

Este artículo se basa en entrevistas con unos 20 fundadores de DeFi, desarrolladores de aplicaciones e investigadores de infraestructura.

Ethereum tiene la oportunidad de ser más rápido y es hora de actuar.

Durante la última década, los «asesinos de Ethereum» han aparecido uno tras otro, con un eslogan casi idéntico: somos un Ethereum más rápido. Aun así, la red principal de Ethereum junto con las L2 sigue siendo el mayor ecosistema DeFi. Hasta el 17 de septiembre de 2026, el valor total bloqueado era de unos 58.000 millones de dólares; en lo que va de año, el volumen de operaciones al contado en los DEX de todas las capas ha superado los 750.000 millones de dólares.

La aceleración de la red principal ha sido contenida: se puede aumentar la velocidad, pero no a costa de la resistencia a la censura, la descentralización y la neutralidad creíble. Este equilibrio ha convertido a Ethereum en la opción preferida para el almacenamiento de valor en cadena. Ethlabs considera que ahora es posible aumentar la velocidad manteniendo estas propiedades.

El método es EIP-8198, también conocido como Quick Slots

Hoy Ethereum produce un bloque cada 12 segundos. Carl Beekhuizen redactó esta EIP en marzo de este año; Barnabé Monnot la presentó a All Core Devs el 6 de agosto para su inclusión en la actualización Hegotá, y Francesco D'Amato, junto con un número creciente de equipos de clientes y del ecosistema, la están impulsando.

La propuesta consta de dos pasos. Primero se realiza una refactorización importante para eliminar el código fijo que asume que «el tiempo de bloque siempre es de 12 segundos»; luego, con esta capacidad, se acelera gradualmente la producción de bloques según la preparación de la red. El plan inicial es reducir de 12 a 10 segundos, y cada reducción posterior requerirá pruebas y consenso por separado. El núcleo no es recortar al límite de una vez, sino hacer que el tiempo de bloque sea ajustable de forma segura.

La expansión de capacidad ya ha seguido esta lógica: el límite de gas se ajusta según el margen del cliente, y la capacidad de blobs puede renegociarse según la capacidad de datos. Ethlabs cree que la latencia debería recibir el mismo trato.

¿A quién le importa?

Nadie exige que la red principal de Ethereum sea el lugar de negociación más rápido del mundo. Pero como capa de liquidación segura y descentralizada para la economía mundial, puede ser más rápida.

Más rápido significa, ante todo, más fluido. Menos tiempo de espera, mejor experiencia. Al hablar con los constructores, se descubre que el impacto va más allá.

Bloques más rápidos hacen que los mercados en cadena sean más eficientes

La red principal ya es un mercado considerable. En los últimos 30 días, el volumen de operaciones en DEX fue de unos 41.250 millones de dólares. En comparación, el principal mercado de Singapur negoció unos 33.900 millones de dólares en valores en agosto de 2026. Un poco más de velocidad a nivel de protocolo ayuda a convertir la red principal en una capa de liquidación global más competitiva.

El mercado no espera a que Ethereum produzca bloques. Entre bloque y bloque, los precios siguen cambiando y la demanda sigue variando. Con ranuras más cortas, la liquidez en cadena se actualiza con más frecuencia, la ventana de cotizaciones obsoletas se reduce, los usuarios obtienen mejores ejecuciones y las condiciones para los creadores de mercado mejoran.

0xngmi, fundador de DefiLlama, afirma que ranuras más rápidas mejoran la experiencia de agregadores de comparación de precios en tiempo real como LlamaSwap: «Las cotizaciones varían menos entre bloques, por lo que el deslizamiento se puede ajustar de forma más ajustada».

Austin Adams, fundador de Doppler, que se dedica a la emisión de activos y liquidez de arranque en frío, ve lo mismo desde la perspectiva de los LP: «Ranuras más rápidas mejoran directamente los rendimientos de los LP y hacen que los mercados de capitales sean más eficientes. Implementar EIP-8198 cuanto antes ayuda a que la red siga dominando la formación de capital y el comercio».

Josh Kim, jefe de ingeniería de la plataforma de opciones Derive, señala que esperar a que una transacción de L1 se confirme obliga a los arbitrajistas a asumir riesgo de precio, lo que afecta su capacidad para reequilibrar el mercado y mantener diferenciales estrechos. Derive V3 se desplegará en la red principal de Ethereum: «Las órdenes grandes de opciones suelen arrastrar a los perpetuos y al contado en nuestro DEX. Cuando los arbitrajistas entran a reequilibrar, la velocidad de los bloques determina directamente las comisiones, el deslizamiento y el riesgo que asumen. Por ejemplo, al tener una posición larga en contado y corta en perpetuos, ahora hay que asumir 12 segundos de riesgo de liquidación en contado, y a menudo solo se atreven a entrar cuando el precio se mueve bruscamente».

Las acciones y ETF tokenizados también se benefician. Ondo utiliza solicitud de cotización (RFQ) para la emisión y el reembolso: el precio se firma fuera de la cadena, pero la transacción del usuario aún debe ejecutarse en Ethereum. Durante la espera, el subyacente sigue cotizando. Con ranuras más cortas, el riesgo que asumen los cotizantes es menor y hay margen para estrechar los diferenciales. Armand Khatri, responsable del ecosistema de Ondo, afirma: «Los mercados que fijan el precio de las acciones y ETF tokenizados nunca esperan a que Ethereum produzca bloques. Desde la firma de la cotización hasta la confirmación de la transacción, cada segundo alguien asume riesgo de precio, que al final se refleja en el diferencial. Ranuras más cortas reducen esa ventana y acercan el precio en cadena a la referencia fuera de cadena. Es una mejora real, y no sacrifica las propiedades que hacen que valga la pena liquidar en Ethereum».

Matthew, cofundador de Ethereum Institutional, cree que una mayor percepción del mercado dará más razones a las instituciones para trasladar su actividad a la cadena. Haikane, fundador de PropellerHeads, afirma que el negocio del trading tiene márgenes muy estrechos, y cualquier mejora en la latencia importa, lo que podría hacer que más negocios estén dispuestos a mover sus activos a la L1 para operar.

ZoomerAnon, colaborador de Aerodrome (protocolo que está abriendo una instancia en la red principal), apoya bloques más rápidos: las actualizaciones de precios son más oportunas, se pierde menos valor a manos de los arbitrajistas y más operaciones permanecen en los pools en cadena. «Que una gran parte del volumen se desvíe a creadores de mercado descentralizados no beneficia a Ethereum, y en parte se debe a la lentitud de los bloques. Podemos adaptarnos al nuevo tiempo de bloque cambiando parámetros y módulos, sin necesidad de redesplegar».

Varios actores con perspectivas distintas apuntan a lo mismo: bloques más cortos, actualizaciones de estado más frecuentes y un mercado de la red principal más eficiente. Si se puede ofrecer un estado más fresco sin sacrificar la descentralización, vale la pena hacerlo.

Para los usuarios, más rápido es más útil

Hay otro tipo de usuario que no quiere saber qué es una ranura. FWA.fun de TokenWorks se ha convertido recientemente en una de las aplicaciones que más gas consume en la red principal, atrayendo a nuevos usuarios y a otros que hacía tiempo no tocaban la red principal. Adam, su fundador, afirma que aunque el frontend oculte la espera, a los usuarios no les gusta esperar; el Chainlink VRF que utiliza FWA requiere 3 bloques adicionales de confirmación, y con bloques más cortos toda la espera se reduce. Muchos usuarios compran y envían transacciones de forma continua, y cada segundo ahorrado cuenta.

Ethlabs tiene otro flujo de trabajo para un Ethereum más rápido, FCR, que reduce el tiempo de confirmación unas 30 veces y también puede cubrir esta necesidad.

Dan Lipert, colaborador del protocolo de privacidad Railgun, cree que bloques más rápidos concentrarán más liquidez en la L1, con conjuntos de privacidad más grandes; las herramientas de cumplimiento también tendrán más oportunidades de reacción en ventanas críticas, y los usuarios podrán usar diversas aplicaciones de forma privada sin esperar pasivamente.

Las L2 ya se han optimizado para interacciones más rápidas. El trabajo de la L1 es distinto: ofrecer una capa de liquidación segura, neutral y resistente a la censura, para que esos sistemas puedan depender de ella en última instancia. Para quienes quieren acercar sus productos orientados al usuario a estas propiedades, una red principal más rápida ayuda directamente.

Más rápido también puede significar mayor resistencia a la censura

Una razón importante para poner transacciones en una cadena descentralizada es la resistencia a la censura. Si alguien se niega a incluir tu transacción, Ethereum debería darte otra vía lo antes posible.

George Davies, jefe de ingeniería de Gattaca, responsable de Titan Builder y que actualmente produce aproximadamente la mitad de los bloques de Ethereum, considera Quick Slots la primera prioridad de la próxima EIP de la capa de consenso: «Es la mayor mejora de experiencia para los usuarios de DeFi, y aporta beneficios de resistencia a la censura y finalidad».

Para quien sufre censura, el tiempo de bloque es tiempo de espera: determina cuánto tarda en tener otra oportunidad de entrar en la cadena.

Esto cobra más sentido combinado con la EIP estrella de Hegotá: FOCIL. FOCIL asigna a un grupo de validadores (includers) la responsabilidad adicional de incluir transacciones; Quick Slots aumenta la frecuencia con la que aparecen esas oportunidades de inclusión. Con bloques de 12 segundos, 5 veces por minuto; con bloques de 10 segundos, 6 veces por minuto. FOCIL da más puertas a las transacciones censuradas; Quick Slots hace que las puertas se abran con más frecuencia.

Michael Mosier, jefe de investigación de Blockspace, subraya la calidad de la inclusión: ranuras más cortas hacen que el espacio de bloques sea más predecible, estimulan la actividad de los usuarios y benefician a la infraestructura que sirve a la red. Patrick Apriori, de Frachtis, va más lejos: emparejado con FOCIL, la censura será más costosa, más breve y estructuralmente más difícil de llevar a cabo.

Aquí hay un concepto útil: la resistencia económica a la censura, es decir, cuánto le cuesta a un adversario mantener una transacción fuera de la cadena de forma continua. Con ranuras más cortas, el usuario espera menos por una oportunidad de inclusión; el adversario, para mantener la censura durante un tiempo fijo, se enfrenta a más oportunidades de proponentes. FOCIL añade includers a este proceso.

El rendimiento y la resiliencia suelen estar en conflicto. Quick Slots permite avanzar en ambos a la vez. Una capa que proporciona liquidación al mundo debería ser difícil de censurar y, cuando alguien lo intente, recuperarse rápidamente.

Más rápido no tiene por qué costar las propiedades fundamentales

Por supuesto, con la condición de que no se intercambie la descentralización.

Flashbots ha evaluado públicamente esta cuestión y su conclusión apoya esta dirección: ranuras más cortas reducen la latencia de confirmación y mejoran la experiencia; apoyan hacer configurable el tiempo de ranura y experimentar gradualmente con ranuras más cortas.

Les preocupa más la descentralización geográfica. Con ranuras más cortas, el tiempo disponible para la producción de bloques se reduce, y los participantes alejados de los centros de red e infraestructura podrían salir perjudicados. Pero según simulaciones calibradas por latencia, la magnitud de la reducción actualmente en discusión no supone una restricción sustancial. Incluso al pasar de 12 a 6 segundos, las diferencias de rendimiento entre regiones aumentarían, pero el resultado de concentración geográfica se mantendría prácticamente igual. El factor geográfico es más bien un límite de «hasta dónde se puede bajar», no un obstáculo para esta reducción.

Ethlabs también está siguiendo los tiempos de propagación de los nodos de toda la red, especialmente teniendo en cuenta la migración poscuántica y la relación entre futuros diseños de consenso, ranuras más cortas y firmas resistentes a cuántica más grandes.

Si la L1 es más rápida, las L2 también se coordinan mejor

Las L2 que dependen de Ethereum tienen parte de sus interacciones heredando el reloj de la L1. Lo más sencillo son los depósitos: para que activos o mensajes pasen de la L1 a la L2, primero debe incluirse una transacción de L1. Con bloques de L1 más cortos, este camino se completa antes, independientemente de si la L2 utiliza Ethereum para el secuenciado.

Para algunos diseños de interoperabilidad, el beneficio es mayor. Armagan, de Ethereum Economic Zone, pone un ejemplo: la solución en la que trabaja EEZ permite que un contrato en una rollup llame a un contrato en otra y use el valor de retorno en la misma transacción. Esta ventana síncrona se abre como máximo una vez por cada bloque de L1. Un reloj de L1 de 12 segundos se convierte en parte de la experiencia entre rollups. «El tiempo de ranura de la L1 determina el ritmo de la composición entre cadenas; con ranuras más cortas, la ventana síncrona aparece con más frecuencia y la peor espera hasta la siguiente también se reduce. Quick Slots es un doble beneficio para EEZ: la primera reducción ya densifica notablemente la ventana; una vez que el tiempo de ranura sea ajustable, cada reducción posterior respaldada por datos se traducirá directamente en una composición entre rollups más rápida para los usuarios».

Una L1 más rápida hace que la coordinación del ecosistema sea más frecuente. Ethlabs sigue posicionando la L1 como capa de liquidación global: suficientemente segura y descentralizada para que activos, aplicaciones y L2 puedan depender de ella. Quick Slots no pretende hacer la L1 tan rápida que las L2 dejen de ser necesarias, sino que la red principal se acelere gradualmente y que la L1 y las distintas L2 se fortalezcan juntas.

Más voces

Greg Casegamas, de Lido, subraya la competitividad. Las ranuras más rápidas no son críticas para su negocio principal de staking, pero como participante más amplio de Ethereum/DeFi, apoyan cualquier cosa que haga a Ethereum más fuerte y competitivo, y les gustaría que se marcara como de nivel S en Hegotá.

Guy Young, fundador de Ethena: DeFi funciona mejor con bloques más rápidos. Ethena ha construido sobre Ethereum desde el primer día y apoya explícitamente la propuesta.

Noveleader, investigador de Castle Labs, parte de la microestructura del mercado: comprimir el tiempo de bloque ayuda a reducir las pérdidas por reequilibrio (LVR) de los LP pasivos, acerca la fijación de precios en cadena a los mercados fuera de cadena, mejora la eficiencia del capital, reduce la fuga de arbitraje tóxico y hace más oportunas las ventanas de liquidación de los protocolos de préstamo. Al mismo tiempo, exigen pruebas de que ranuras más cortas no eleven las barreras para la dispersión geográfica y los validadores domésticos, para evitar que la ventana de propagación se estreche y el staking fluya silenciosamente hacia centros de datos con mejor red; también quieren ver cómo la compresión de ranuras afecta al juego de tiempos y a la competencia entre constructores: con ranuras más cortas, la latencia y las ventajas de coubicación valen más, y la producción de bloques podría concentrarse más. En el lado del ecosistema, los contratos y sistemas fuera de cadena que usan la altura de bloque como reloj (ciclos de gobernanza, bloqueos temporales, modelos de interés basados en bloques anualizados) deben tener una ruta de migración clara antes del lanzamiento.

Omid Malekan, profesor adjunto de Columbia Business School, pone una condición breve: preservando la descentralización, bloques más rápidos son mejores para todo.

Nicolas, del protocolo de capital riesgo en cadena Umia: ranuras más rápidas mejorarán la experiencia de la red principal, y como constructores lo valoran mucho; esperan que se priorice.

Por qué luchar por incluirlo en Hegotá

El ancho de banda de ingeniería de cada actualización es limitado. Los argumentos para incluir Quick Slots en Hegotá se resumen en tres frases: beneficia a la red; el trabajo de ingeniería es reutilizable; la ventana de oportunidad está abierta ahora.

Esperar tiene un coste. La actualización posterior a Hegotá se denomina actualmente I* y podría incluir el consenso desacoplado: separar la producción de bloques de la finalidad, que ya es la propuesta de mayor prioridad en la hoja de ruta del protocolo de la Ethereum Foundation. Barnabé señala que perderse Hegotá no significa que Quick Slots pase automáticamente a la siguiente bifurcación, sino que podría tener que competir por recursos de ingeniería con una reforma del consenso mucho mayor y esperar varios ciclos de actualización hasta tener una ventana limpia.

El tiempo de bloque es una restricción de toda la red. Las carteras pueden cambiar las animaciones de carga, los DEX pueden cambiar el enrutamiento, pero nadie puede hacer que el siguiente bloque de la red principal salga antes por su cuenta. Modificar esta restricción a nivel de protocolo beneficia a todas las aplicaciones y usuarios que dependen de la latencia de la L1, sin que cada uno tenga que hacer su propia adaptación. Cuando las exigencias de experiencia aumentan, poder mejorar la latencia a nivel de protocolo evita obligar cada vez más a las aplicaciones a asumirla por su cuenta.

El trabajo de ingeniería tiene un efecto compuesto. Gran parte del trabajo consiste en eliminar el supuesto de «siempre 12 segundos» de las especificaciones y los clientes. Si se hace ahora, cuando el rendimiento de los clientes y la red mejoren, las reducciones posteriores serán mucho más fáciles. Cada reducción seguirá requiriendo pruebas, coordinación y una actualización de red, pero Ethereum conservará una base reutilizable. La capacidad ya avanza según «mejorar, medir, volver a mejorar»; la latencia debería hacer lo mismo.

Lo que están preparando

Ethlabs sitúa Quick Slots dentro del flujo de trabajo más amplio de Fast Ethereum, pero como cualquier EIP, requiere coordinación de toda la red. El equipo de protocolo de la fundación enumera varias cosas de las que necesitan más certeza: una especificación consensuada, implementaciones conformes a la especificación, evaluación del impacto aguas abajo y compatibilidad con el consenso desacoplado.

El progreso actual incluye:

La especificación se está implementando en clientes ejecutables. Barnabé, con la participación de Francesco y de los colaboradores de la fundación Justin Traglia y Jihoon Song, ha propuesto una especificación de consenso que cubre los cambios de temporización y la transición de la actualización. El 12 de septiembre, Terence informó de que había implementado un prototipo de Prysm según la especificación de trabajo y lo había probado localmente con Kurtosis. El siguiente paso es alinear las implementaciones de múltiples clientes y probar la transición en condiciones de red más realistas.

Se está investigando qué está atado hoy a los 12 segundos. Ethlabs, junto con Sourcify, está revisando los supuestos de temporización de los contratos desplegados para identificar rutas que puedan requerir migración, incluidos los contratos que interactúan con raíces históricas de bloques beacon. La evaluación preliminar ya ha dado rutas de código concretas, no un vago «podría romperse».

También se está alineando la hoja de ruta posterior. Francesco, junto con el equipo de finalidad de la fundación, está examinando la relación entre Quick Slots y el consenso desacoplado. Ambas direcciones contemplan bloques más rápidos en el futuro.

Qué falta

Una actualización de Ethereum afecta a cientos de miles de millones de dólares en valor, debe garantizar que no haya tiempo de inactividad y coordina a tantas partes interesadas que no caben en una sala de reuniones. Para que una EIP llegue a la red principal, hay que proponerla, escribir la especificación, implementarla, probarla, encontrar lo que se rompe, arreglarlo y volver a probar, hasta que los responsables de la entrega tengan la confianza suficiente para incluirla en una actualización.

Quick Slots está en ese camino. Lo que queda por hacer está claro: integrar la especificación en el código principal, alinear las implementaciones, probar las condiciones de red, revisar las dependencias aguas abajo y planificar el siguiente paso del mecanismo en el contexto de la migración poscuántica. El trabajo de Ethlabs es convertir lo desconocido en implementaciones y planes de migración, para que pueda entrar realmente en el alcance de Hegotá.

Quienes mantienen clientes, ejecutan validadores, construyen infraestructura o tienen aplicaciones que se beneficiarían de una red principal más rápida quieren recibir comentarios; y si se les ha pasado por alto alguna restricción, aún más.

Descentralización y rendimiento no tienen por qué ser una elección; a veces se pueden tener ambos. Un Ethereum fuerte depende de la acción colectiva del ecosistema. Creen que es hora de que este ecosistema se mueva un poco más rápido.