Crypto : Polygon révèle pourquoi les hard forks Austin et Kyoto étaient nécessaires

Polygon vient enfin d'expliquer ce que cachaient ses hard forks Austin et Kyoto. Les deux mises à jour avaient corrigé plusieurs failles de sécurité gardées privées pendant leur déploiement. Certaines pouvaient ralentir le réseau, faire planter des nœuds ou forcer les validateurs à effectuer un travail informatique très coûteux. Polygon affirme n'avoir observé aucune exploitation sur le mainnet.

En bref

• Austin a corrigé deux risques de déni de service dans Bor.
• Kyoto a renforcé Heimdall contre plusieurs attaques et erreurs de validation.
• Les correctifs avaient déjà été activés avant leur divulgation publique.

Crypto : Austin a fermé deux failles dans Bor

Polygon connaît déjà les hard forks de sécurité. En 2025, le réseau avait dû corriger un bug critique avec une mise à jour d'urgence. Austin s'est cette fois concentré sur Bor, le client chargé notamment de produire les blocs de Polygon PoS.

La première faille concernait les opérations de state sync venant d'Ethereum vers Polygon. Ces opérations peuvent exécuter du code et consommer du gas. Contrairement aux transactions crypto classiques, aucune limite stricte ne plafonnait cependant leur consommation totale dans un bloc.

Un bloc suffisamment chargé pouvait donc demander beaucoup trop de travail aux nœuds. Polygon a ajouté une limite. La seconde faiblesse venait d'un champ baptisé TxDependency. Il servait à aider l'exécution parallèle des transactions, mais sa taille n'était pas plafonnée.

Un producteur de bloc pouvait théoriquement créer un champ énorme. Un autre nœud recevait le bloc. Puis il pouvait planter en essayant de le traiter. Austin a simplement retiré ce champ du format transmis entre les nœuds.

Kyoto protégeait surtout Heimdall

Kyoto concernait Heimdall, l'autre grande brique du réseau Polygon PoS. Polygon avait déjà profondément modernisé ce composant avec Heimdall v2, présenté comme son hard fork le plus complexe depuis 2020.

La faille la plus importante venait de transactions crypto spécialement construites. Heimdall utilise des structures capables d'en contenir d'autres. Sans limite de profondeur, un attaquant pouvait empiler ces éléments et envoyer une transaction relativement simple à créer.

Les validateurs devaient ensuite effectuer beaucoup de calculs pour la décoder. Même travail. Sur presque tous les validateurs. Kyoto impose désormais une profondeur maximale et rejette les transactions qui dépassent ce seuil.

La mise à jour corrige également une liste de frais qui pouvait auparavant devenir extrêmement longue. Là encore, l'objectif consistait à empêcher un utilisateur de provoquer une consommation inutile de ressources.

D'autres correctifs touchent les checkpoints, les milestones et certains événements provenant d'Ethereum. Une signature de checkpoint valide pouvait notamment arriver sous une forme qui échouait ensuite lors de son traitement sur Ethereum. Pas besoin de voler des tokens pour gêner un réseau. Faire perdre du temps aux validateurs crypto peut déjà suffire.

Polygon avait corrigé avant de parler

Polygon n'a pas publié les détails immédiatement. Austin et Kyoto ont d'abord été déployés discrètement, testés sur Amoy puis activés sur le mainnet. Les explications sont venues après.

C'est volontaire. Publier une faille avant que les validateurs disposent du correctif aurait aussi donné le mode d'emploi aux attaquants. Austin nécessite désormais Bor v2.10.0. Kyoto demande Heimdall v0.11.0 pour les validateurs et les full nodes.

Polygon assure qu'aucune des vulnérabilités divulguées n'a provoqué d'incident connu sur le mainnet. Les corrections étaient donc préventives. Le réseau a beaucoup accéléré ses mises à jour depuis deux ans. Fin 2025, Polygon avait encore déployé Madhugiri pour réduire le temps de consensus et augmenter les performances. Austin et Kyoto racontent une autre partie du travail. Pas plus de vitesse cette fois. Simplement des portes qu'il valait mieux fermer avant que quelqu'un essaie de les ouvrir.

Les opérateurs restés sur une ancienne version après les hauteurs d'activation ne suivent déjà plus la chaîne canonique. Ils doivent mettre à jour leur logiciel puis se resynchroniser.