Le dernier cycle de développement du réseau de test Ethereum Shapella révèle quelques bogues

Les tests sur le réseau de test Zhejiang d'Ethereum avant la mise à jour de Shanghai-Capella ont révélé quelques bogues, mais rien qui n'affectera le calendrier d'introduction du jalonnement sur le réseau. 

Développeur Marius VanDerWijden documenté un bogue de synchronisation rencontré par d'autres clients dont les développeurs sont convaincus peut être corrigé, selon un fil de Tim Beiko de la Fondation Ethereum. Le bogue n'affectera aucun calendrier établi pour l'ensemble de mise à niveau proposé pour le testnet Sepolia prévu pour le 28 février, a-t-il noté.

La dernière mise à jour devnet de retrait a détaillé un test de résistance composé de 600,000 360,000 validateurs, dont XNUMX XNUMX ont effectué des mises à jour des identifiants de retrait au moment du fork. Des pics de RAM et de CPU chez les clients se sont produits et les développeurs évalueront le nombre de messages de mise à jour des informations d'identification perdus par rapport aux messages enregistrés au cours des prochains jours, a déclaré Beiko.

Le test de résistance a également révélé un bogue entre un client de preuve de participation, Prysm, et le client Besu, conçu pour les cas d'utilisation autorisés. Pour se synchroniser correctement, le client Prysm attend un certain nombre de réponses ; cependant, Besu impose des limitations de réponse qui le ramènent en dessous du seuil de synchronisation nécessaire, a déclaré Beiko. L'équipe de Besu se penche sur la question.

Interdiction sans blob

Après une discussion sur la meilleure façon d'optimiser l'orientation client initiale, les développeurs ont finalement décidé d'interdire complètement les transactions blobless 4844, ce qui modifierait les hypothèses des clients concernant les transactions et pourrait compliquer la configuration.

Les développeurs ont également discuté de la manière d'aller de l'avant avec la dépréciation du mot-clé SELFDESTRUCT, qui met fin à un contrat, supprime le bytecode du contrat de la blockchain et redirige les fonds sur le contact vers une adresse spécifiée.

Bien que la voie à suivre reste incertaine, il y a trois propositions actuelles sur le sujet en discussion alors que les développeurs cherchent à trouver "des options de désactivation qui ne cassent pas les choses", a déclaré Beiko.

"Le défi ici est qu'il ouvre un vecteur d'attaque malveillant : déployez un contrat, remplissez le stockage d'une certaine manière, et lorsque vous redéployez le contrat, l'ancien stockage est toujours là et peut être accessible de manière malveillante", a déclaré Beiko.