Polygon a corrigé deux vulnérabilités dans BlockSTM V2, le système d'exécution parallèle du client Bor qui alimente la blockchain Polygon PoS, qui pouvaient permettre à des transactions valides de ralentir les nœuds du réseau. Selon l'analyse technique publiée par Polygon, les bugs n'ont pas modifié les résultats des transactions et ne menaçaient pas le consensus. Le risque concernait la disponibilité : un nœud pouvait calculer le résultat correct d'un bloc, mais passer tellement de temps à le traiter qu'il prenait du retard sur le reste du réseau. La société a divulgué ses conclusions en même temps que la version publique de Bor v2.10.3, la version du client contenant les correctifs.

Polygon déclare n'avoir aucune connaissance d'une exploitation sur le mainnet ou le testnet Amoy.

Pourquoi la fin anticipée de l'exécution série ne mettait pas fin au retard

Bor traite les blocs entrants à la fois par exécution série et parallèle, en retenant la voie qui se termine en premier. L'exécution série suit l'ordre des transactions, tandis que l'exécution parallèle tente de traiter les transactions simultanément, puis vérifie si ses hypothèses de dépendances étaient correctes. Cette approche peut accélérer les charges de travail ordinaires lorsque les transactions ne dépendent pas les unes des autres, mais elle crée également un travail spéculatif qui doit s'arrêter rapidement dès qu'il n'est plus utile.

Cette conception place Bor dans la famille des systèmes d'exécution parallèle optimiste : le client suppose que la plupart des transactions sont indépendantes, les exécute côte à côte et paie un coût de vérification lorsqu'une hypothèse s'avère erronée. Les bugs de performance dans de tels systèmes se manifestent généralement par du travail gaspillé plutôt que par de mauvais résultats, ce qui correspond au profil décrit par Polygon.

Le test de hachage de code répété de Polygon a révélé la faille. L'exécution série a terminé la transaction en quelques dizaines de millisecondes, mais la voie parallèle a continué de travailler pendant environ 11 secondes. À l'époque, l'annulation n'était vérifiée qu'entre les transactions, ce qui signifie qu'une transaction coûteuse déjà en cours d'exécution en parallèle devait se terminer même après que l'exécution série avait produit le résultat.

C'est pourquoi ce test était important : la transaction était valide et Bor pouvait déterminer rapidement son état final, mais le nœud devait quand même attendre la fin d'un traitement inutile.

Deux failles créaient un travail que le gas ne valorisait pas entièrement

Les deux vulnérabilités provenaient de sources différentes de travail excédentaire. L'une permettait à l'exécution spéculative de conserver trop de données calculées. L'autre recalculait à plusieurs reprises le hash du code d'un contrat alors qu'elle aurait pu réutiliser un résultat antérieur.

Les limites de gaz facturent aux utilisateurs les opérations de transaction spécifiées, mais elles ne captent pas toujours tous les coûts introduits par l'implémentation d'un client. Dans ces cas, la croissance du cache et le hachage redond pouvaient générer un travail côté nœud disproportionné par rapport au coût apparent de la transaction.

Polygon a classé les deux bugs en gravité moyenne et a déclaré qu'aucun n'affectait le consensus. Cette classification correspond au profil des conclusions : l'exposition concernait des nœuds plus lents et des ressources gaspillées, et non des résultats de transaction modifiés ou un consensus endommagé.

Ce que le correctif Bor v2.10.3 change

Les correctifs de la v2.10.3 limitent cette surcharge sans modifier les résultats d'exécution. La mise à jour restreint le cache partagé utilisé pendant l'exécution spéculative et permet à Bor de réutiliser un résultat de hash de code au lieu de le recalculer lors de lectures répétées. L'objectif est d'empêcher qu'une charge de travail valide mais maladroite ne consomme des ressources excessives ou ne prolonge inutilement le temps de traitement des blocs.

Selon les notes de version de Bor v2.10.3, la version publique ne nécessite pas de hard fork, de migration de base de données ni de resynchronisation des nœuds. Les opérateurs peuvent mettre à niveau leurs nœuds individuellement.

Le correctif privé a précédé la divulgation publique

Polygon a déclaré avoir distribué un build privé pour le testnet Amoy le 5 octobre, suivi d'un build privé pour le mainnet le 8 octobre. La société a publié la divulgation technique sur le forum de gouvernance de Polygon le 15 octobre, après que les mises à niveau ont atteint la majeure partie du réseau. Une annonce de version distincte couvre le déploiement sur le mainnet et le testnet.

Les notes de version indiquent que la plupart des validateurs et des principaux fournisseurs RPC exécutaient déjà la version privée. Cela ne signifie pas que tous les nœuds connectés avaient été mis à niveau, c'est pourquoi l'annonce de Polygon aux opérateurs invite les utilisateurs de Bor v2.10.2 ou antérieur à effectuer la mise à jour rapidement. Les opérateurs déjà sur les builds privés peuvent passer à la version publique lors de leur prochaine fenêtre de maintenance.

Le problème restant est la couverture du correctif

Pour les portefeuilles, les applications et autres services, les nœuds en retard peuvent renvoyer des informations de chaîne obsolètes ou mettre plus de temps à soumettre des transactions. La divulgation de Polygon n'établit pas que les utilisateurs ont subi de telles perturbations, et la société déclare ne connaître aucune exploitation sur le mainnet ou Amoy.

Comme la v2.10.3 est livrée sans hard fork, il n'existe aucune échéance au niveau du protocole obligeant les retardataires à effectuer la mise à niveau ; l'adoption se fait selon le calendrier de chaque opérateur. La couverture du correctif constitue donc le signal observable à suivre : la rapidité avec laquelle les opérateurs Bor en v2.10.2 ou antérieur passent à la version corrigée.

Le travail plus large de Polygon sur le traitement accéléré et l'infrastructure de paiement rend cette fiabilité opérationnelle pertinente. Le correctif supprime les deux sources identifiées de travail excédentaire ; la prochaine étape pratique est l'application de celui-ci par les opérateurs Bor restants.

Cet article est fourni à titre informatif uniquement. Les descriptions des vulnérabilités et les évaluations d'exploitation reflètent la divulgation publiée par Polygon.

Source : Coindoo