Polygon Labs a ordonné aux opérateurs de nœuds exécutant des binaires pré-hardfork de procéder immédiatement à la mise à niveau, après que son audit de sécurité du 27 août a confirmé que les nœuds Bor en dessous de v2.10.0 et les nœuds Heimdall en dessous de v0.11.0 ne suivent plus le consensus canonique. Austin a été activé au bloc 91 949 700 du mainnet côté client d'exécution, tandis que Kyoto a été activé à la hauteur 51 533 000 le 18 août à 10:10:31 UTC pour la couche de consensus.
Pourquoi c'est important
Austin a clos deux vecteurs d'épuisement des ressources dans Bor. Le premier a plafonné le gaz consommé par Bor lors du traitement des événements state-sync issus des dépôts du pont L1 vers L2, puisque ces appels s'exécutaient auparavant hors du plafond de gaz du bloc et pouvaient bloquer le traitement si suffisamment d'événements arrivaient. Le second a supprimé le champ extra-data TxDependency de Bor après que des chercheurs ont montré qu'un producteur pouvait injecter un blob surdimensionné dans ce champ et faire crasher les nœuds pairs traitant un bloc frère. Polygon a déclaré ne pas avoir observé de perturbation du mainnet liée à Austin et a présenté ces changements comme des correctifs proactifs.
Le correctif le plus sévère de Kyoto a ajouté une vérification d'imbrication au niveau de l'octet sur les messages google.protobuf.Any dans Heimdall, fermant un vecteur où une seule transaction peu coûteuse pouvait forcer chaque validateur à dépenser beaucoup de ressources pour le décodage. Kyoto a également plafonné les listes de fee-coins avant une analyse de validation O(n) (Heimdall autorise un seul fee coin), normalisé les octets de récupération de signature des checkpoints afin qu'une signature valide ne puisse pas échouer à la récupération sur Ethereum, rendu idempotents les messages répétés d'indisponibilité des producteurs, lié les votes de plage de milestone au hash parent signé, empêché les créations de future-span échouées de bloquer l'engagement de milestone, et rendu injectives les clés de rejeu pour les événements topup, clerk et stake sur les index de log hors plage. Une perturbation RPC d'une heure signalée précédemment a été liée à un correctif à chaud de Heimdall dans ce même chemin de code.
Impact sur le marché
Les deux hardforks sont de simples mises à niveau binaires sans migration d'état ni changement de genesis, donc les nœuds qui se sont mis à niveau dans les délais n'ont rien à faire. Les opérateurs déjà au-delà de la hauteur concernée sur un client plus ancien doivent installer la version applicable, revenir à un bloc pré-hardfork si nécessaire, et resynchroniser selon les indications de Polygon.
Questions fréquemment posées
-
Que doivent faire les opérateurs de nœuds après les hardforks Austin et Kyoto ?
Les opérateurs exécutant Bor en dessous de v2.10.0 ou Heimdall en dessous de v0.11.0 doivent installer la dernière version, revenir à un bloc pré-hardfork si nécessaire, et resynchroniser selon les indications de Polygon. Les nœuds déjà mis à niveau dans les délais n'ont aucune action à effectuer.
-
Quand Austin et Kyoto ont-ils été activés sur le mainnet Polygon PoS ?
Austin a été activé au bloc 91 949 700 côté client d'exécution. Kyoto a été activé à la hauteur 51 533 000 le 18 août à 10:10:31 UTC pour la couche de consensus. Les deux hauteurs d'activation sont désormais dépassées.
-
Qu'a corrigé le hardfork Austin dans Polygon PoS ?
Austin a plafonné le gaz consommé par Bor lors du traitement des événements state-sync issus des dépôts du pont L1 vers L2 et a supprimé le champ extra-data TxDependency, qui n'avait aucune limite de taille et pouvait permettre à un producteur de faire crasher des nœuds pairs avec un blob surdimensionné. Polygon a…
-
Quel était le correctif le plus sévère de Kyoto ?
Kyoto a ajouté une vérification d'imbrication au niveau de l'octet sur les messages google.protobuf.Any dans Heimdall, fermant un vecteur où une seule transaction peu coûteuse pouvait forcer chaque validateur à dépenser beaucoup de ressources pour le décodage. Une perturbation RPC d'une heure signalée précédemment a…
-
Ces hardforks nécessitent-ils une migration d'état ou une resynchronisation à partir de zéro ?
Non. Les deux sont de simples mises à niveau binaires sans migration d'état ni changement de genesis. Les nœuds qui n'ont pas divergé ne nécessitent aucune resynchronisation, bien que les opérateurs déjà au-delà de la hauteur concernée sur un client plus ancien doivent revenir en arrière et resynchroniser selon les…
CoinTelegraph
Crypto News
CoinDesk
TheBlock