Polygon a publié le 27 août 2026 sur son forum communautaire le détail de deux hardforks déjà activés sur son réseau proof-of-stake. Austin porte sur Bor, le client qui produit les blocs. Kyoto porte sur Heimdall, le client qui gère le consensus des validateurs et l'ancrage des checkpoints sur Ethereum. Les correctifs ont d'abord été déployés en privé, puis validés sur Amoy, le réseau de test de Polygon, avant activation sur le mainnet. La publication n'est intervenue qu'une fois le parc de machines jugé sûr. Cointelegraph a relayé cette divulgation dans sa revue quotidienne du 30 août, en rappelant qu'aucune de ces failles n'a été vue exploitée sur le réseau principal.
Que corrige le hardfork Austin sur Bor ?
Deux changements, tous deux liés au traitement des blocs. Le premier plafonne le gas consommé par les state-sync events à l'intérieur d'un bloc. Ces événements transportent les dépôts qui passent d'Ethereum vers Polygon par le pont entre les deux chaînes et exécutent du code de contrat comme une transaction ordinaire. Leur consommation n'était pourtant mesurée contre aucune limite dure, contrairement au gas des transactions classiques. Un bloc chargé d'assez d'événements, ou d'un seul événement très coûteux, pouvait allonger le traitement au point de figer temporairement la chaîne. Le second retire du format réseau le champ TxDependency. Bor s'en servait comme indice pour l'exécution parallèle, en signalant quelles transactions d'un bloc n'entrent pas en conflit. Ce champ n'avait pas de limite de taille. Un producteur de blocs pouvait donc glisser un contenu arbitrairement volumineux dans un bloc frère par ailleurs valide, et tout pair qui le recevait plantait en tentant de le traiter. Polygon précise que l'exécution parallèle fonctionne sans avoir à faire confiance à cet indice.
Quelles failles Kyoto ferme-t-il côté Heimdall ?
La plus sévère du lot concerne l'imbrication des types `google.protobuf.Any`. Les transactions Heimdall enveloppent leurs messages internes dans ces types, qui peuvent s'imbriquer les uns dans les autres. Sans plafond, une transaction fabriquée avec de nombreux niveaux d'imbrication forçait l'ensemble des validateurs à un travail de décodage massif, pour un coût dérisoire côté émetteur. Kyoto ajoute un pré-scan qui rejette la transaction au-delà d'un seuil, appliqué à l'identique à l'entrée du mempool et sur le chemin du consensus, pour qu'une même transaction ne puisse pas être admise d'un côté et refusée de l'autre. Le reste du lot durcit la finalité et la comptabilité interne :
- plafonnement du nombre de coins de frais déclarés dans une transaction, dont la validation s'effectuait en temps linéaire
- normalisation de l'octet de récupération des signatures de checkpoint, un défaut qui pouvait faire échouer la vérification côté Ethereum et bloquer l'ancrage sans rien falsifier
- traitement idempotent des messages d'indisponibilité d'un producteur, qui créaient auparavant un span supplémentaire à chaque répétition
- rattachement du vote d'extension de milestone au hash parent effectivement signé par le validateur
- clés de rejeu injectives pour les événements venus d'Ethereum, deux événements distincts pouvant jusque-là produire la même clé et s'occulter mutuellement
Polygon indique que ces gardes restent inertes sous la hauteur de fork et ne se déclenchent que sur les entrées fabriquées qu'elles visent.
À quelles hauteurs les forks se sont-ils activés ?
| Client | Réseau | Hauteur d'activation |
|---|---|---|
| Bor v2.10.0 (Austin) | Amoy | 44 120 000 |
| Bor v2.10.0 (Austin) | Mainnet | 91 949 700 |
| Heimdall v0.11.0 (Kyoto) | Amoy | 42 252 000 |
| Heimdall v0.11.0 (Kyoto) | Mainnet | 51 533 000 |
Que doivent faire les opérateurs ?
Les deux mises à jour sont obligatoires. Bor v2.10.0 concerne toutes les machines, Heimdall v0.11.0 tous les validateurs et les nodes complets. Il s'agit de simples remplacements de binaire, sans migration d'état, sans changement de genesis et sans resynchronisation complète. Un node resté sur une version antérieure au-delà des hauteurs indiquées a déjà quitté la chaîne canonique. Concrètement, il traite une histoire divergente de celle du réseau et les données qu'il sert sont fausses. Polygon indique qu'il faut mettre à jour le binaire puis revenir à une hauteur antérieure aux forks pour resynchroniser et rejoindre le réseau. Polygon qualifie les deux problèmes visés par Austin de vecteurs d'épuisement de ressources, et non d'erreurs de correction du consensus.
