TL;DR
- Les développeurs d'ethereum ont fusionné une correction Glamsterdam après avoir identifié une logique de transition de fork pouvant acheminer les dépôts de validateurs vers des constructeurs partageant la même clé publique.
- Le bogue a affecté l'intégration de Gloas, où les dépôts en attente pouvaient être mal classifiés lors de la création des registres de constructeurs et de validateurs, mais il ne s'agissait pas d'une exploitation sur le mainnet.
- La pull request #5736 sépare désormais le routage des dépôts selon les informations d'authentification de retrait, conserve les dépôts de validateur dans leur file d'attente et ajoute des tests de régression avant le déploiement.
Les développeurs d'Ethereum ont fusionné une correction de la spécification de consensus pour Glamsterdam après avoir identifié un bogue d'intégration de fork Gloas qui pouvait rediriger les dépôts de validateurs vers des constructeurs de blocs partageant la même clé publique. Pull request #5736 a été fusionnée dans master le 26 octobre et modifie la manière dont les dépôts en attente sont classifiés pendant le fork. Ce défaut affectait la logique de transition pour la future mise à jour d'Ethereum, et non le protocole mainnet actuel, limitant ainsi le problème au chemin de développement et de test pour Ethereum.
Gloas Fix sépare les chemins de dépôt du validateur et du constructeur
Le problème sous-jacent concernait le moment où Gloas initialise son registre de constructeurs. Selon la règle de routage précédente, une fois qu’un dépôt en attente enregistrait un constructeur, les dépôts ultérieurs utilisant la même clé publique pouvaient augmenter le solde de ce constructeur, indépendamment de leurs crédits de retrait. Un dépôt de validateur pouvait donc quitter la file d’attente des validateurs et être crédité à un constructeur à la place. Ce bogue a créé un chemin conditionnel permettant aux fonds fournis pour le staking d’atteindre un compte contrôlé par une autre partie.

La description du problème illustre le risque avec un protocole de staking finançant un validateur exploité par une autre partie. Si l'opérateur a d'abord mis en file d'attente un dépôt de constructeur valide en utilisant la même clé et que les deux dépôts sont restés en attente au moment du fork, le dépôt de validateur financé par le protocole pourrait également être transféré au constructeur. Aucun validateur ne serait créé à partir de ce dépôt, ce qui pourrait perturber la comptabilité basée sur la preuve ou les procédures de récupération. Le scénario documenté était un cas limite au niveau du protocole, et non une preuve que les dépôts sur le mainnet Ethereum avaient été déviés.
La correction fusionnée sépare les dépôts selon les identifiants de retrait lors de l'intégration de Gloas. Les dépôts de validateur restent désormais dans la file d'attente des validateurs même lorsqu'un constructeur utilise la même clé, tandis que les dépôts valides de constructeur peuvent s'inscrire ou recharger indépendamment les constructeurs. Les dépôts de constructeur existants peuvent également recevoir des recharges selon les nouvelles règles. Cette modification aligne l'intégration sur les registres indépendants de validateurs et de constructeurs décrits par l'EIP-8282 et ajoute des tests de régression couvrant l'ordre et le routage des dépôts.
Le moment est important car Glamsterdam combine les modifications de la couche d'exécution d'Amsterdam avec les modifications de la couche de consensus de Gloas, y compris la séparation proposer-builder inscrite. La mise à jour plus large a déjà traversé les tests publics, tandis que son déploiement Hoodi a été reporté pour un examen supplémentaire et son activation sur mainnet reste non confirmée. La correction du routage des dépôts renforce donc les spécifications pour un futur fork plutôt que de réparer une exploitation en cours sur Ethereum. Elle renforce également la raison pour laquelle la logique de transition autour de l'encouragement et de l'infrastructure de construction de blocs nécessite des tests avant que les changements de protocole proposés n'atteignent la production en toute sécurité.

