El asunto de acelerar Ethereum siempre ha quedado atascado en un nudo difícil: si quieres que la cadena vaya más rápido, normalmente tienes que sacrificar la descentralización o la resistencia a la censura.
La propuesta EIP-8198 (Quick Slots) planteada por el autor #Ethlabs intenta sortear ese nudo, y la idea es bastante inteligente.
El enfoque es en dos pasos: primero ir reduciendo gradualmente el tiempo de producción de bloques de 12 a 10 segundos, pero sin cambiarlo de una sola vez; en su lugar, se convierte en una “actualización de cambio de velocidad controlable y que se puede probar de forma progresiva”. A la vez, se ajustan en paralelo los parámetros de capacidad, Gas y Blob.
Lo clave está en la palabra “progresiva”. En el pasado, lo que más temía el ecosistema de actualizaciones de Ethereum era el cambio “de golpe”: modificarlo todo, que luego surjan problemas, y que toda la red se vea afectada al mismo tiempo. Con un diseño de tasa de cambio variable, el riesgo se divide en porciones pequeñas: en cada ocasión se mueve solo un poco, se observa que no haya problemas y entonces se continúa.
Esto también explica por qué la evolución de Ethereum siempre parece tan lenta: no busca lo más rápido, sino “volverse más rápido sin perder el control”. La velocidad puede aumentarse poco a poco, pero si se abandona la descentralización, una vez que se pierde ya no se recupera.
La verdadera dificultad técnica nunca ha sido si se puede hacer más rápido, sino si, una vez acelerada, sigue siendo la misma cadena de antes.
La propuesta EIP-8198 (Quick Slots) planteada por el autor #Ethlabs intenta sortear ese nudo, y la idea es bastante inteligente.
El enfoque es en dos pasos: primero ir reduciendo gradualmente el tiempo de producción de bloques de 12 a 10 segundos, pero sin cambiarlo de una sola vez; en su lugar, se convierte en una “actualización de cambio de velocidad controlable y que se puede probar de forma progresiva”. A la vez, se ajustan en paralelo los parámetros de capacidad, Gas y Blob.
Lo clave está en la palabra “progresiva”. En el pasado, lo que más temía el ecosistema de actualizaciones de Ethereum era el cambio “de golpe”: modificarlo todo, que luego surjan problemas, y que toda la red se vea afectada al mismo tiempo. Con un diseño de tasa de cambio variable, el riesgo se divide en porciones pequeñas: en cada ocasión se mueve solo un poco, se observa que no haya problemas y entonces se continúa.
Esto también explica por qué la evolución de Ethereum siempre parece tan lenta: no busca lo más rápido, sino “volverse más rápido sin perder el control”. La velocidad puede aumentarse poco a poco, pero si se abandona la descentralización, una vez que se pierde ya no se recupera.
La verdadera dificultad técnica nunca ha sido si se puede hacer más rápido, sino si, una vez acelerada, sigue siendo la misma cadena de antes.