Rubriques tendance
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
MegaETH
MegaETH est la première blockchain en temps réel, exploitant une spécialisation extrême des nœuds pour éliminer les limites de gaz de bloc et débloquer le calcul continu pour les développeurs.
Le chef technique lapin déchiffre tranquillement des modèles mathématiques sur les raisons pour lesquelles tu ne vas pas y arriver (ngmi)
À dimanche !
31 juil. 2025
J'ai eu un vol de retour très productif depuis Copenhague (grâce au fait que le siège à côté de moi était vide) !
J'ai réussi à élaborer un modèle mathématique qui explique pourquoi la nouvelle structure de données trie d'état de MegaETH est évolutive alors que le MPT et ses variantes ne le sont pas, peu importe l'optimisation de leurs implémentations. Cela inclut les Verkle tries qui avaient suscité beaucoup d'espoir pour accélérer la mise à jour de la racine d'état, ainsi que les différentes bases de données optimisées pour le MPT.
J'ai adopté la technique utilisée dans l'analyse – approcher un processus aléatoire avec un espace d'état explosif en utilisant un processus sans mémoire – en travaillant sur le papier IBLT sans ratelimit. C'est une technique élémentaire, mais c'est très gratifiant de l'utiliser avec succès ailleurs !
Je vais introduire la nouvelle structure de données lors de l'atelier Science et Ingénierie du Consensus (pendant le SBC). Ce sera la première fois que nous en parlerons en détail même si elle est en production sur le testnet depuis le premier jour : ) À bientôt là-bas !
16,37K
MegaETH a reposté
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 !
14,58K
Meilleurs
Classement
Favoris