La mise à jour de cette semaine du testnet MegaETH a corrigé un bug de performance insaisissable qui avait provoqué une augmentation continue du temps de miniblock entre les redémarrages du séquenceur. Voici l'histoire. C'est une histoire sur notre philosophie : mesurer, puis construire. Si l'on visitait récemment le tableau de bord de performance de MegaETH, on pourrait voir que le temps de miniblock avait augmenté pendant la semaine précédant le 3 juin. En réalité, une telle tendance commençait juste après chaque redémarrage du séquenceur depuis le lancement du testnet public. Auparavant, les mises à jour fréquentes du séquenceur signifiaient que le temps de miniblock n'augmentait pas d'une quantité perceptible avant que la tendance à la hausse ne soit réinitialisée. Cependant, les mises à jour récentes n'avaient pas nécessité de redémarrages du séquenceur, et la tendance s'est poursuivie pendant des semaines. Le 3 juin, le temps de miniblock a presque atteint 100 ms. Avec les redémarrages du séquenceur devenant encore moins probables à l'avenir grâce aux sauvegardes à chaud, il est temps d'éliminer le bug une bonne fois pour toutes. Comme nous collectons régulièrement beaucoup de données de télémétrie pour le testnet, l'équipe a rapidement commencé à creuser. La première découverte a été que l'augmentation du temps de miniblock s'accélérait avec le temps – non seulement le temps de miniblock augmentait, mais il augmentait de plus en plus vite. En général, un tel symptôme impliquerait que le travail impliqué dans la construction de chaque miniblock augmentait de manière superlinéaire à mesure que de plus en plus de miniblocks étaient construits. Cependant, nous avons rejeté l'hypothèse après quelques mesures et calculs. Nous avons construit le pipeline de miniblock pour qu'il soit presque entièrement asynchrone par rapport à l'EVM afin d'atteindre un temps de miniblock arbitrairement bas. Cela signifie que peu importe le temps qu'il faut pour construire un miniblock, l'EVM exécutera des transactions pendant tout ce temps. Ainsi, un temps de construction de miniblock plus long entraînerait un plus grand nombre de transactions par miniblock, mais nous n'avons pas observé cela. Donc, le problème ne peut pas venir de la construction des miniblocks. Un examen attentif du code confirme cette conclusion : aucune partie du processus de construction de miniblock n'a une complexité superlinéaire. L'équipe a élargi la recherche, et le véritable coupable est rapidement apparu. Le temps nécessaire pour valider les blocs EVM avait augmenté ; de plus, le temps de validation était parfaitement linéaire par rapport au nombre de blocs EVM produits depuis le dernier redémarrage. Lors de la validation des blocs EVM, l'environnement EVM, tel que la hauteur du bloc, est mis à jour, donc l'EVM doit faire une pause et ne peut pas exécuter de transactions, ce qui signifie pas de miniblocks non plus. Il y a un intervalle fixe d'une seconde entre les blocs EVM. Dans le budget d'une seconde, un temps de validation qui augmente linéairement entraîne une durée d'exécution des transactions qui diminue linéairement, ce qui à son tour entraîne un nombre de miniblocks produits qui diminue linéairement. Si nous prenons son réciproque, nous obtenons le temps moyen de miniblock, qui est inversement proportionnel dans le temps. C'est exactement la forme de fonction que nous avons vue sur le tableau de bord de performance. Les mathématiques étaient correctes. À ce stade, nous savions exactement ce qu'il fallait chercher : une procédure dont la charge de travail augmente linéairement dans le temps dans la partie particulière du code qui gère la validation des blocs EVM. Le reste du travail était simple. L'équipe a poussé la mise à jour cette semaine et le temps de miniblock n'a pas augmenté. Alors, quelle a été la leçon ? Je pense qu'elle a encore montré le pouvoir lorsque l'ingénierie est guidée par des mesures précises et des principes fondamentaux. L'équipe travaille sur d'autres mises à jour avec la même philosophie. Restez à l'écoute !