Polygon a publié le 27 août 2026 sur son forum communautaire le détail de deux hardforks déjà actifs sur son réseau PoS, Austin pour le client Bor v2.10.0 et Kyoto pour le client Heimdall v0.11.0. Les deux corrigent des problèmes de sécurité et de disponibilité de la chaîne. Polygon PoS fonctionne avec deux logiciels distincts. Bor produit et exécute les blocs, Heimdall porte la couche validateurs et l'ancrage périodique des checkpoints sur Ethereum. Un correctif de consensus touche donc l'un ou l'autre, parfois les deux.
Que corrige le hardfork Austin sur Bor ?
Deux changements, présentés comme fermant chacun une voie de déni de service pendant le traitement des blocs. Le premier plafonne le gaz consommé par bloc par les événements de state sync. Ces événements correspondent aux dépôts qui transitent du pont entre Ethereum et Polygon vers la chaîne PoS. Ils exécutent du code de contrat comme des transactions ordinaires, mais leur consommation n'était mesurée contre aucune limite stricte. 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 bloquer 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 les transactions d'un bloc qui n'entrent pas en conflit. Ce champ n'avait pas de limite de taille, si bien qu'un producteur de blocs pouvait y insérer un contenu arbitrairement volumineux dans un bloc frère par ailleurs valide, et faire planter tout pair qui tentait de le traiter. Polygon indique que l'exécution parallèle continue de fonctionner sans cet indice.
Que change Kyoto côté Heimdall ?
Kyoto regroupe une série de durcissements du consensus et de validations d'entrées. Les principaux points listés par Polygon :
- une limite sur l'imbrication des types `google.protobuf.Any` dans les transactions, une transaction spécialement construite pouvant auparavant imposer un décodage coûteux à l'ensemble des validateurs pour un coût faible côté émetteur
- un plafond sur le nombre de jetons déclarés pour payer les frais, dont la vérification était proportionnelle à la longueur de la liste
- la normalisation de l'octet de récupération des signatures de checkpoint, une signature valide pouvant sinon être soumise sous une forme qui échoue à la vérification sur Ethereum et bloque l'ancrage
- le traitement idempotent des messages de downtime d'un producteur, qui ne crée plus un span supplémentaire à chaque répétition
- des clés de rejeu distinctes pour les événements Ethereum liés aux modules topup, clerk et stake, deux événements distincts pouvant auparavant produire la même clé et l'un masquer l'autre
Polygon décrit la limite d'imbrication comme le point le plus sérieux du lot, parce qu'elle fermait une manière ouverte à tous d'imposer un travail coûteux et simultané à l'ensemble du jeu de validateurs. La règle s'applique de la même façon à l'entrée dans le mempool et sur le chemin du consensus, pour qu'une transaction ne puisse pas être acceptée par une voie et rejetée par l'autre.
À quelles hauteurs les forks se sont-ils activés ?
Les deux versions ont d'abord été déployées en privé puis validées sur Amoy, le réseau de test de Polygon, avant l'activation sur le réseau principal.
| Version | 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 |
Les deux mises à jour sont obligatoires pour tous les validateurs et les nœuds complets. Polygon précise qu'il s'agit de simples remplacements de binaires, sans migration d'état ni resynchronisation complète. Un nœud resté sur une version antérieure au delà de ces hauteurs a déjà quitté la chaîne canonique, et doit revenir à une hauteur antérieure aux forks pour se resynchroniser. Polygon affirme qu'aucun des deux problèmes de Bor n'a été observé en train de perturber le réseau principal.
Qu'ont voté les validateurs de Solana au même moment ?
Selon Cointelegraph, les validateurs de Solana ont approuvé la proposition SGP-0002, dite Double Disinflation, qui fait passer le rythme annuel de désinflation de 15 % à 30 %. Le média chiffre à 18,9 millions de SOL l'émission évitée sur six ans et rapporte 67 % de votes favorables, 25,16 % contre et 7,84 % d'abstentions, pour une participation de 60,7 % du stake éligible. La cible d'inflation de long terme reste à 1,5 %, atteinte en environ 2,8 ans contre 5,7 ans avec l'ancien calendrier. Ce calendrier fixe l'émission du réseau, pas ce que touche un délégateur. Le rendement réel d'une délégation dépend du validateur choisi et des commissions prélevées, comme sur toute chaîne en preuve d'enjeu.
