Polygon Labs a corrigé plusieurs failles de sécurité sur son réseau de preuve d'enjeu par le biais de deux hard forks coordonnés, y compris une vulnérabilité qui aurait pu forcer l'ensemble des validateurs à effectuer un traitement coûteux à partir d'une seule transaction spécialement conçue.
L'équipe de support des validateurs de Polygon a divulgué les correctifs dans un message sur le forum le 27 août, après que les hard forks Austin et Kyoto aient déjà été testés et activés. L'équipe a déclaré que les correctifs de sécurité affectant le consensus ont été déployés en privé, validés sur le testnet Amoy et divulgués seulement après que le parc de nœuds du réseau principal ait été protégé.
Les vulnérabilités ont affecté Bor, le client d'exécution de Polygon PoS, et Heimdall, qui gère la coordination des validateurs et d'autres fonctions de consensus. Polygon a déclaré n'avoir trouvé aucune preuve que l'un de ces problèmes ait été exploité ou ait causé des perturbations sur le réseau principal.
Le hard fork Austin a mis à niveau Bor vers la version 2.10.0 et a corrigé deux chemins de déni de service liés au traitement des blocs.
L'un d'eux concernait les événements de synchronisation d'état (state-sync) utilisés pour les dépôts du pont L1-vers-L2. De tels événements peuvent exécuter du code de contrat et des précompilations, mais leur exécution n'était pas soumise à une limite de gaz par bloc efficace. Austin a introduit une limite sur la quantité de gaz que les événements de synchronisation d'état peuvent consommer au sein d'un bloc, les empêchant d'épuiser les ressources de traitement.
Une faiblesse distincte concernait les données TxDependency utilisées lors du traitement des blocs. Un producteur de blocs malveillant aurait pu fournir un champ de données surdimensionné, provoquant potentiellement une allocation de mémoire excessive et le plantage des nœuds pairs traitant le bloc.
Polygon a décrit les deux problèmes comme des vecteurs de déni de service liés au traitement des blocs plutôt que des failles de correction du consensus et a déclaré qu'aucun n'avait causé de perturbation connue avant le déploiement des correctifs.
Le hard fork Kyoto, qui a fait passer Heimdall à la version 0.11.0, a couvert un groupe plus large de correctifs de validation des entrées et de renforcement du consensus.
Parmi eux, Polygon a identifié les champs google.protobuf.Any profondément imbriqués comme la vulnérabilité la plus grave du lot. Les transactions Heimdall peuvent encapsuler des messages à l'intérieur de champs Any, qui à leur tour peuvent être imbriqués les uns dans les autres.
Sans limite de profondeur, un attaquant aurait pu construire une transaction contenant des champs profondément imbriqués à un coût relativement faible tout en forçant chaque validateur la traitant à effectuer un travail de décodage substantiel. Polygon a déclaré que la faille offrait une voie sans permission pour imposer un traitement coûteux et coordonné à l'ensemble des validateurs.
Kyoto a ajouté une analyse au niveau des octets qui rejette les transactions une fois que l'imbrication dépasse un seuil défini. La vérification s'applique à la fois à l'admission dans le mempool et à l'étape de traitement du consensus afin que la même transaction ne puisse pas être acceptée par une voie et rejetée par une autre.
D'autres correctifs de Heimdall concernaient la comptabilité des jalons (milestones), le traitement des points de contrôle (checkpoints) et la relecture d'événements L1. La création échouée de « future-span » peut désormais se dégrader et réessayer à la prochaine limite au lieu de bloquer un « commit de jalon », tandis que de nouvelles clés de relecture traitent un cas limite où des événements L1 distincts pourraient autrement entrer en collision.
Les deux hard forks sont obligatoires pour les opérateurs qui souhaitent rester sur le réseau PoS canonique de Polygon.
Bor v2.10.0 est requis pour tous les nœuds, tandis que Heimdall v0.11.0 s'applique aux validateurs et aux nœuds complets. Polygon a déclaré que les opérateurs exécutant des versions antérieures aux hauteurs d'activation se sont déjà éloignés du consensus canonique et doivent mettre à jour leur logiciel pour rejoindre le réseau.
Les changements ont été livrés sous forme de mises à niveau binaires, ce qui signifie que les opérateurs n'ont pas besoin de migrer l'état, de modifier la configuration de la genèse ou d'effectuer une resynchronisation complète. Les nœuds qui sont sortis du consensus peuvent être mis à niveau et revenir à la hauteur appropriée d'avant le hard fork avant de rattraper la chaîne canonique.
Polygon a déjà utilisé des hard forks pour résoudre des problèmes affectant son infrastructure PoS. En septembre 2025, les développeurs ont exécuté un hard fork après qu'un bogue logiciel ait causé des retards de finalité de transaction allant jusqu'à 15 minutes.
L'incident précédent a affecté la synchronisation des validateurs et la finalité rapide locale, tandis que la production de blocs et le jalonnement Ethereum (Ethereum checkpointing) se sont poursuivis. Des mises à jour de Bor et Heimdall ont été déployées pour restaurer le traitement des jalons, la synchronisation d'état et la finalisation du consensus.
Un mois plus tard, la mise à niveau Rio du réseau principal a introduit la validation sans état basée sur les témoins et un modèle de producteur de blocs élu par les validateurs, alors que Polygon continuait de modifier la façon dont son réseau PoS traite et vérifie les transactions.
La performance du réseau est restée un autre axe d'attention en 2026. En mai, crypto.news avait déjà rapporté que Polygon avait réduit le temps de bloc à une moyenne de 1,75 seconde, sa première réduction du temps de bloc depuis son lancement.
L'ingénieur logiciel de Polygon, Lucca Martins, a déclaré à l'époque que le changement avait augmenté le débit théorique à environ 3 260 transactions par seconde et avait permis au réseau de traiter environ 14 % de paiements supplémentaires par seconde. Ce travail faisait partie de l'effort de Polygon pour prendre en charge des volumes de transactions plus élevés provenant des paiements en stablecoins et de l'activité de finance décentralisée.
Les derniers correctifs de sécurité sont arrivés après que Polygon ait achevé le remplacement de MATIC par POL en tant que jeton natif de gaz et de staking sur son réseau PoS. La migration a commencé en septembre 2024 dans le cadre de la feuille de route Polygon 2.0, avec le MATIC détenu directement sur Polygon PoS converti en POL à un ratio de un pour un.
Le plan original MATIC-vers-POL désignait POL comme le jeton utilisé pour les paiements de gaz et le staking, tandis que ses fonctions proposées devaient s'étendre à mesure que Polygon développait son architecture de staking et de chaînes agrégées.
Les changements se sont étendus à Polygon Labs elle-même. En juillet, l'entreprise a supprimé une autre série d'emplois tout en achevant l'intégration de l'échange de cryptomonnaies Coinme. Le PDG Marc Boiron a déclaré que la restructuration était conçue pour soutenir la rentabilité d'ici 2027, alors que Polygon Labs s'orientait vers un modèle commercial axé sur les paiements.
Le POL n'a montré que peu de réaction positive à la divulgation de sécurité. Le jeton se négociait près de 0,09983 $ le 30 août, en baisse d'environ 2,3 % sur les 24 heures précédentes et de 6,8 % sur sept jours, selon les données de CoinGecko fournies avec le rapport. Son prix est resté environ 60,8 % inférieur à celui d'un an plus tôt, conférant au jeton une capitalisation boursière d'environ 1,07 milliard de dollars.
POL
MATIC