La actualización de esta semana en la red de prueba MegaETH solucionó un elusivo error de rendimiento que había causado que el tiempo de minibloque aumentara continuamente entre reinicios del secuenciador. Aquí está la historia. Es una historia sobre nuestra filosofía: medir, luego construir. Si uno visitó recientemente el panel de rendimiento de MegaETH, podría ver que el tiempo de minibloque había estado aumentando durante la semana previa al 3 de junio. De hecho, tal tendencia comenzaría justo después de cada reinicio del secuenciador desde el lanzamiento de la red de prueba pública. Anteriormente, las frecuentes actualizaciones del secuenciador significaban que el tiempo de minibloque no aumentaría en ninguna cantidad perceptible antes de que la tendencia ascendente se reiniciara. Sin embargo, las actualizaciones recientes no habían requerido reinicios del secuenciador, y la tendencia continuó durante semanas. El 3 de junio, el tiempo de minibloque casi alcanzó los 100 ms. Con los reinicios del secuenciador volviéndose aún menos probables en el futuro gracias a las copias de seguridad en caliente, es hora de eliminar el error de una vez por todas. Dado que recopilamos rutinariamente muchos datos de telemetría para la red de prueba, el equipo rápidamente comenzó a investigar. El primer descubrimiento fue que el aumento en el tiempo de minibloque se aceleraba con el tiempo: no solo aumentaba el tiempo de minibloque, sino que aumentaba cada vez más rápido. Normalmente, tal síntoma implicaría que el trabajo involucrado en construir cada minibloque aumentaba de manera superlineal a medida que se construían más minibloques. Sin embargo, descartamos la hipótesis después de algunas mediciones y cálculos. Construimos la tubería de minibloques para que fuera casi completamente asíncrona con la EVM para lograr un tiempo de minibloque arbitrariamente bajo. Esto significa que, independientemente del tiempo que tome construir un minibloque, la EVM estará ejecutando transacciones durante todo ese tiempo. Por lo tanto, el mayor tiempo de construcción de minibloques llevaría a un mayor número de transacciones por minibloque, pero no observamos eso. Así que el problema no puede estar en la construcción de minibloques. Un examen cuidadoso del código confirma esta conclusión: ninguna parte del proceso de construcción de minibloques tiene complejidad superlineal. El equipo amplió la búsqueda, y el verdadero culpable surgió rápidamente. El tiempo que tardaba en comprometer bloques de EVM había estado aumentando; además, el tiempo de compromiso era perfectamente lineal al número de bloques de EVM producidos desde el último reinicio. Al comprometer bloques de EVM, el entorno de EVM, como la altura del bloque, se actualiza, por lo que la EVM debe pausar y no puede ejecutar transacciones, lo que significa que tampoco hay minibloques. Hay un intervalo fijo de 1 segundo entre los bloques de EVM. Dentro del presupuesto de 1 segundo, un tiempo de compromiso que aumenta linealmente lleva a una duración que disminuye linealmente para ejecutar transacciones, lo que a su vez lleva a un número de minibloques producidos que disminuye linealmente. Si tomamos su recíproco, obtenemos el tiempo promedio de minibloque, que es inversamente proporcional en el tiempo. Es exactamente la forma de función que vimos en el panel de rendimiento. Las matemáticas estaban correctas. En ese momento, sabíamos exactamente qué buscar: algún procedimiento cuyo carga de trabajo aumenta linealmente con el tiempo en la parte particular del código que maneja el compromiso de bloques de EVM. El resto del trabajo fue sencillo. El equipo lanzó la actualización esta semana y el tiempo de minibloque no ha aumentado. Entonces, ¿cuál fue la lección? Creo que mostró nuevamente el poder cuando la ingeniería está guiada por mediciones cuidadosas y principios fundamentales. El equipo está trabajando en otras actualizaciones con la misma filosofía. ¡Estén atentos!