Pour évaluer les chiffres de performance, il faut d’abord se demander : quelle partie du travail est-elle supprimée ? Dans la PR Geth #36078 , certains packages dont le coût de démarrage est élevé sont remplacés par des tags de compilation spécifiques dans l’environnement guest d’une zkVM. L’auteur indique le nombre de cycles d’exécution économisés pour différents packages. Il s’agit de travaux d’initialisation inutilisés par certains programmes guest ; la refonte des métriques est explicitement exclue du périmètre de cette modification. À mon avis, ce type d’optimisation mérite d’être examiné sous trois angles : l’environnement, les conditions de compilation et les fonctionnalités remplacées. Les cycles économisés à eux seuls ne peuvent pas être directement convertis en une hausse du débit du mainnet de $ETH . Il est plus utile de comprendre à quel chemin d’exécution correspondent ces chiffres que d’additionner tous les résultats de performance.
Le nœud $BTC démarré à partir d’un instantané assumeutxo vérifie également les blocs historiques en arrière-plan. La PR #36790 de Bitcoin Core explique un détail de comptage : les blocs en cours de téléchargement, utilisés uniquement pour l’état historique de la chaîne, étaient comptabilisés avec les demandes de blocs à la pointe de la nouvelle chaîne. Il pouvait alors arriver que les nouveaux blocs soient demandés sous forme de blocs complets. La solution exclut ces tâches historiques de ce calcul, afin que le relais de blocs compacts fonctionne également pendant la vérification en arrière-plan. Elle ne supprime pas la vérification historique ; sans chargement d’instantané, le comportement reste inchangé, selon le texte original. Pour comprendre les performances au démarrage d’un nœud, il faut examiner l’influence des tâches en arrière-plan sur les demandes au premier plan, et pas seulement vérifier si la page de démarrage affiche déjà la hauteur la plus récente.
La nouvelle proposition Agave #16840 vise à clarifier les erreurs de configuration réseau : lorsque le mode XDP zéro copie est requis, certains pilotes de cartes réseau ou interfaces bond ne sont pas compatibles, et l’ancien message d’erreur se limitait à « Operation not supported ». La proposition détecte les capacités à l’avance sur les noyaux Linux compatibles et lit le mode réellement utilisé par le noyau, afin que la supervision n’affiche pas seulement le « mode demandé ». Elle précise qu’aucun retour automatique au mode avec copie n’est effectué ; avec un ancien noyau ou en cas d’échec de la détection, le résultat dépend toujours du mode réellement utilisé. Pour l’exploitation des nœuds $SOL , les informations les plus utiles sont « ce qui a finalement été activé et la raison de l’échec ». La proposition est encore à l’état de brouillon (Draft) ; la validation sur des cartes réseau physiques reste à effectuer, et il ne faut pas la présenter comme déjà largement déployée.
L’appel de simulation ne renseigne pas le gas, mais signale qu’il est trop élevé ; le problème vient peut-être de la valeur par défaut. La PR #28315 de Reth concerne le cas d’Amsterdam : lorsque l’opérateur définit rpc.gascap sur max, la valeur de gas par défaut peut dépasser la limite de gas de la transaction. Le correctif choisit la plus petite des deux valeurs suivantes : la limite des appels RPC et la limite de transaction de l’environnement d’exécution actuel. Il ajoute également un test correspondant. Pour analyser l’échec de la simulation de l’application $ETH , conservez d’abord la version du nœud, la configuration du fork et les paramètres de la requête ; l’absence de valeur renseignée déclenche tout de même la règle par défaut. Cette discussion porte sur le traitement des paramètres de simulation RPC et ne permet pas d’en déduire que les frais du réseau principal ont augmenté.
La tentative de modification de lattice-hash dans Agave aujourd’hui vise à confier également les lots incomplets au SIMD : on les complète avec des messages vides, on les calcule en parallèle, puis on soustrait le hachage correspondant au remplissage. Cette voie n’est choisie que si le coût estimé est inférieur à celui du traitement en série. Voir $SOL optimisation du calcul côté client : le taux de remplissage des lots, la longueur des messages et le jeu d’instructions influent tous sur le résultat. L’auteur signale encore des régressions dans certains cas avec AVX2 ; il s’agit de tests ponctuels de rafraîchissement sur des cœurs spécifiques, et non d’une preuve que le débit de l’ensemble du réseau a augmenté dans les mêmes proportions.
Les vérifications mémoire réussissent dans les tests, mais le binaire de production intègre-t-il forcément les mêmes vérifications ? Le brouillon mono-move d’Aptos définit hardened et exhaustive comme des propriétés de compilation, et précise clairement que les compilations de production n’intègrent pas ces vérifications ; le niveau exhaustive est principalement destiné à la CI et au fuzzing. Pour comprendre la vérification à l’exécution $APT , il faut d’abord examiner le profil de compilation du binaire. La documentation répertorie également des vérifications nécessitant un contexte, qui seront reportées à une étape ultérieure. Des vérifications par étapes ne constituent ni une preuve complète ni la garantie que la production subira soudainement la même surcharge à l’exécution.
Les enregistrements de connexion d’un nœud concordent-ils toujours avec son état lorsqu’il est marqué comme inactif ? La demande concernant le suivi de disponibilité d’AvalancheGo indique que ces deux types de suivi étaient parfois mal associés. La solution consiste à réorganiser le stockage des états et à ajouter des tests de régression afin de réduire les risques d’erreur. Lorsqu’on consulte les informations de disponibilité du nœud $AVAX , il faut d’abord vérifier la définition des indicateurs et la source de l’état réel. Le texte d’origine ne fournit ni taux de déconnexion en production ni statistiques sur les pertes de récompenses ; il ne faut donc pas extrapoler une correction du suivi des états pour en tirer une conclusion sur la disponibilité de l’ensemble du réseau.