Le mois de juin a été particulièrement dense en mises à jour de la technologie blockchain, les développeurs corrigeant des failles de confidentialité, reprogrammant des mises à niveau majeures, proposant des améliorations de résistance quantique et se dépêchant de renforcer la sécurité face à une vague croissante d’attaques sur la chaîne d’approvisionnement. De Bitcoin Core à Ethereum, de Zcash à Polygon, le rythme des changements au niveau des protocoles s’accélère — et certaines décisions prises aujourd’hui définiront la résilience de ces réseaux pour la prochaine décennie.
Summary
Points clés à retenir
- Bitcoin Core 31.1 corrige une vulnérabilité de confidentialité dans la fonctionnalité -privatebroadcast de la version 31.0 qui pouvait exposer l’adresse IP de l’initiateur d’une transaction.
- La mise à niveau Glamsterdam d’Ethereum a été reportée à la seconde moitié de l’année ; le hard fork Hegotá vise désormais la fin 2026 / début 2027.
- EIP-8182, une proposition de transfert privé natif, a été officiellement proposée pour inclusion dans le hard fork Hegotá.
- Le PDG de Consensys, Joseph Lubin, s’attend à ce qu’Ethereum devienne un protocole entièrement basé sur les preuves à divulgation nulle de connaissance (zero-knowledge proofs) d’ici 3 à 5 ans.
- Polygon zkEVM Mainnet Beta cessera ses opérations le 1er juillet 2026 — les utilisateurs doivent retirer leurs actifs avant la date limite.
- L’équipe de sécurité SlowMist a confirmé la présence de variantes de malwares actives dans 23 paquets npm, avec 408 dépôts GitHub contenant des identifiants volés.
- La puce quantique Majorana 2 de Microsoft serait 1 000 fois plus fiable que sa prédécesseure, avec une durée de vie moyenne des qubits de 20 secondes.
Bitcoin Core corrige une vulnérabilité de confidentialité dans la v31.1
Une faille cachée dans la nouvelle fonctionnalité -privatebroadcast de Bitcoin Core a été rendue publique ce mois-ci — et les implications pour les utilisateurs soucieux de leur confidentialité sont plus subtiles que la plupart des divulgations de bugs. La version 31.0 contenait une vulnérabilité qui, dans des conditions réseau spécifiques, pouvait exposer l’adresse IP de l’initiateur d’une transaction au nœud récepteur.
Comment la fuite d’IP se produit réellement
La vulnérabilité apparaît lorsque la diffusion privée sélectionne un nœud IPv4 ou IPv6 qui prend en charge le transport BIP324 v2. Si la poignée de main v2 échoue, Bitcoin Core revient à une tentative v1 — mais cette reconnexion contourne entièrement le proxy Tor, établissant une connexion IPv4 ou IPv6 directe avec le pair. Résultat : une fonctionnalité conçue pour renforcer la confidentialité finit par produire l’effet inverse dans certaines conditions de repli.
Le périmètre affecté est spécifique. Les nœuds exécutant Bitcoin Core 31.0 avec -privatebroadcast activé, diffusant des transactions via l’API RPC sendrawtransaction, et capables d’établir des connexions sortantes IPv4/IPv6 directes sont à risque. Les connexions Wallet RPC, onion et I2P ne sont pas affectées.
Avant de mettre à niveau vers la version 31.1, Bitcoin Core conseille aux utilisateurs concernés de désactiver -privatebroadcast, de désactiver le transport v2, ou de faire transiter le trafic sortant IPv4/IPv6 via Tor. La release candidate 31.1rc1 est déjà disponible pour test sur le site officiel de Bitcoin Core et inclut des correctifs au niveau de la validation, du réseau P2P, de la migration de portefeuille, de MuSig, du système de build, des tests et des modules d’intégration continue (CI).
Par ailleurs, le développeur rkrux a ouvert une discussion sur la suppression du signalement explicite Replace-by-Fee (RBF) dans le portefeuille Bitcoin Core, arguant que les signaux BIP 125 sont devenus redondants maintenant que le full-RBF est la politique standard et qu’ils peuvent laisser des empreintes inutiles sur la chaîne. Le membre de la communauté Murch a répliqué en soulignant que l’arrêt des signaux de remplaçabilité n’est pas une simple suppression d’empreintes — chaque expéditeur doit toujours choisir un numéro de séquence pour chaque entrée, avec environ 75 % des transactions utilisant déjà des numéros de séquence spécifiques, principalement MAX-2.
Ethereum reporte Glamsterdam et fait avancer les propositions de confidentialité
Le pipeline de développement d’Ethereum progresse sur plusieurs fronts, mais la nouvelle la plus immédiate concerne un changement de calendrier : la mise à niveau Glamsterdam — qui vise un scaling ultime de la couche 1 (L1) et une équité en matière de MEV — a été repoussée à la seconde moitié de l’année. Les itérations Devnet-5 et Devnet-6 sont toujours en cours, avec des contre-mesures contre les nouveaux EIP en développement actif. Le développeur principal Terence a confirmé que Glamsterdam devnet-6 a été publié, marquant une avancée significative vers un déploiement sur testnet.
Proposition de registre de clés publiques post-quantiques
Les chercheurs Ethereum Thomas Coratger et Tom Wambsgans ont publié un cadre pour établir un registre de clés publiques post-quantiques pour les validateurs — un chemin de migration progressif des signatures BLS vers des schémas de signature sécurisés post-quantiques. L’approche prévoit d’abord un fork de registre, permettant aux validateurs de pré-enregistrer des clés publiques post-quantiques, suivi de plusieurs forks supplémentaires avant le basculement officiel du mécanisme de signature.
Le candidat principal est le schéma de signature à base de hachage XMSS, qui offre une clé publique compacte de 52 octets — bien que chaque signature pèse environ 3 112 octets. Pour gérer cette surcharge, il faudra leanVM et une agrégation de SNARK post-quantiques. Il ne s’agit pas d’une mise à niveau à court terme, mais le fait que les chercheurs Ethereum définissent déjà l’architecture de migration montre à quel point le réseau prend au sérieux la menace quantique.
Proposition EIP-8182 de transfert privé natif pour Hegotá
EIP-8182, développé par Tom Lehman, a été officiellement proposé pour inclusion dans le hard fork Hegotá — la mise à niveau visant la résistance à la censure, l’amélioration de la confidentialité et l’allègement des nœuds, actuellement prévue pour la fenêtre fin 2026 / début 2027.
La proposition vise à apporter la confidentialité de manière native à la couche de base d’Ethereum sans frais supplémentaires, sans gouvernance par token ni coordination multi-signatures. Elle utilise des contrats système à adresse fixe et des précompilés de vérification ZK pour créer un pool d’anonymat partagé au niveau du protocole, accessible à tous les portefeuilles et applications. Ce pool partagé est crucial : les applications de confidentialité fragmentées divisent actuellement la liquidité et les ensembles d’anonymat entre différentes implémentations, affaiblissant les garanties de confidentialité pratiques pour tout le monde. En intégrant la confidentialité à la couche L1, EIP-8182 supprimerait cette fragmentation sans nécessiter de changements au niveau des applications.
La proposition est désormais en compétition pour une place dans le calendrier de hard fork des développeurs principaux — un processus qui implique un débat technique et communautaire important avant toute finalisation.
Le PDG de Consensys et l’avenir zero-knowledge d’Ethereum
Le PDG de Consensys, Joseph Lubin, a présenté une vision à plus long terme, déclarant qu’Ethereum pourrait devenir un protocole entièrement basé sur les preuves à divulgation nulle de connaissance d’ici 3 à 5 ans. Lubin a cité les réseaux de couche 2 qui génèrent déjà des preuves ZK en temps réel comme preuve que la technologie mûrit suffisamment vite pour atteindre la couche 1. Il imagine un futur où plusieurs prouveurs formellement vérifiés soutiennent Ethereum à la couche de base, permettant finalement un environnement d’exécution atomique unique, sans ponts, qui unifie la liquidité fragmentée.
Lubin a également abordé la future structure de la Fondation Ethereum, indiquant qu’il n’y aura pas de « seconde fondation » — à la place, au moins trois groupes se détacheront de la fondation existante, se concentrant respectivement sur le travail de protocole de base, l’ergonomie et la scalabilité, et la sensibilisation institutionnelle.
Avancées des couches 2 d’Ethereum et arrêt de Polygon zkEVM
L’écosystème de couche 2 d’Ethereum a connu ce mois-ci à la fois de nouveaux lancements et des échéances fermes. Le développement le plus urgent pour les utilisateurs existants est l’arrêt de Polygon zkEVM Mainnet Beta le 1er juillet 2026 — laissant environ deux semaines aux utilisateurs pour agir.
Cadre de confidentialité STRK20 de Starknet
Starknet a lancé STRK20, un cadre de confidentialité basé sur les preuves à divulgation nulle de connaissance qui permet à tout actif ERC20 au sein du réseau de prendre en charge des soldes privés et des transferts confidentiels. Contrairement aux mélangeurs de coins traditionnels, STRK20 intègre les fonctions de confidentialité directement dans le flux des actifs plutôt que de faire transiter les transactions par une couche de mixage séparée. Le cadre inclut un mécanisme de clés de visualisation (Viewing Keys), permettant aux utilisateurs de divulguer sélectivement des données de transaction à des fins de conformité. Le premier actif à l’adopter est strkBTC.
Le cadre peut être appliqué aux transferts, au trading, au lending, au staking et aux paiements — un périmètre large qui suggère que Starknet positionne STRK20 comme une infrastructure plutôt qu’une simple fonctionnalité.
Arrêt de Polygon zkEVM Mainnet Beta
Polygon zkEVM Mainnet Beta sera officiellement arrêté le 1er juillet 2026. Les actifs détenus dans des portefeuilles n’ayant pas finalisé leurs transferts inter-chaînes seront automatiquement migrés vers la couche principale d’Ethereum et pourront être réclamés via une interface dédiée. En revanche, les actifs verrouillés dans des protocoles DeFi ne peuvent pas être migrés automatiquement — ces utilisateurs doivent retirer manuellement leurs positions de LP et leurs actifs avant la date limite, sous peine de perdre définitivement l’accès.
Le réseau L2 Base a, de son côté, déployé sa mise à niveau Beryl sur le testnet Base Sepolia, avec une activation sur mainnet prévue pour le 25 juin. Beryl introduit le standard de token B20 pour émettre des stablecoins et d’autres actifs nativement au sein du logiciel de nœud de Base, réduit la fenêtre de retrait de Base vers Ethereum de 7 jours à 5 jours, et apporte Reth V2 afin de réduire l’empreinte disque des nœuds.
Mise à niveau Ironwood de Zcash et améliorations de la sécurité du réseau
Zcash prépare une importante mise à niveau du réseau visant à résoudre l’une des vulnérabilités les plus sérieuses apparues cette année sur une blockchain axée sur la confidentialité.
Ironwood cible le pool de confidentialité Orchard
La mise à niveau Ironwood de Zcash est prévue pour activation en juillet, afin de corriger des vulnérabilités dans le pool de confidentialité Orchard qui menaçaient auparavant les garanties d’offre fixe du réseau. La Fondation Zcash avait déjà publié Zebra 4.5.3 et 5.0.0 en tant que réponses d’urgence — Zebra 4.5.3 a temporairement désactivé les actions Orchard sur le mainnet via un soft fork d’urgence au bloc 3 363 426, tandis que Zebra 5.0.0 a activé le hard fork NU6.2 au bloc 3 364 600, réactivant Orchard avec un circuit corrigé. La fondation a confirmé que la vulnérabilité a été découverte avant toute exploitation connue et qu’aucune création de valeur non autorisée n’a eu lieu.
Ironwood va plus loin. Il introduira un nouveau pool de confidentialité corrigé et retirera progressivement l’ancien. Une fois l’opération terminée, les utilisateurs et les nœuds pourront agréger les soldes des deux pools pour vérifier de manière indépendante que le total de ZEC en circulation ne dépasse pas le plafond fixe de 21 millions de coins — restaurant ainsi la confiance décentralisée dans le mécanisme d’offre de Zcash.
Le développeur principal de Zcash, Sean Bowe, a confirmé qu’au moins trois grands cabinets d’audit examinent le circuit Orchard, que plusieurs outils d’audit basés sur l’IA analysent le code, et que les travaux de vérification formelle progressent. Le groupe Valar a lancé un testnet et commencé à implémenter des changements côté portefeuille. Selon Bowe, l’avancement est actuellement fluide.
Alertes de sécurité et avancées en informatique quantique
Deux développements ce mois-ci se situent aux extrémités opposées de la chronologie des menaces : l’un est une attaque active en cours dans l’écosystème npm, l’autre est une étape importante en matière de matériel quantique qui reste théorique pour la sécurité des blockchains — mais progresse plus vite que beaucoup ne l’avaient anticipé.
SlowMist alerte sur un malware npm exploitant des identifiants de développeurs volés
L’équipe de sécurité SlowMist a publié une alerte concernant de nouvelles variantes de malwares — identifiées sous les noms Shai-Hulud, Miasma et Hades — liées au compte de développeur volé « czirker » et actives dans l’écosystème npm. Le vecteur d’attaque est précis : le code malveillant se déclenche lors de l’exécution de npm install via un fichier binding.gyp préconfiguré, ce qui le rend facile à manquer dans les audits de dépendances standard.
Les chiffres confirmés sont notables. 23 paquets affectés ont été identifiés, dont un — leo-logger — atteignant 3 140 téléchargements hebdomadaires. De plus, 408 dépôts GitHub contenant des identifiants volés ont été découverts. L’activité malveillante couvre le vol de tokens GitHub et npm, d’identifiants cloud sur AWS, GCP et Azure, de données d’environnement local, ainsi que l’abus de pipelines GitHub Actions.
SlowMist recommande aux équipes de sécurité d’inspecter immédiatement les lockfiles et les enregistrements de paquets, de supprimer les paquets affectés, de faire tourner toutes les clés critiques et d’imposer l’authentification à deux facteurs. Le schéma d’attaque souligne un risque persistant dans les écosystèmes open source : le vol d’identifiants au niveau des comptes développeurs peut contaminer des centaines de dépôts en aval avant détection.
La puce quantique Majorana 2 de Microsoft dévoilée
Lors de sa conférence annuelle Build, Microsoft a dévoilé Majorana 2, sa puce quantique topologique de deuxième génération. L’entreprise affirme que la puce est 1 000 fois plus fiable que sa prédécesseure, avec une durée de vie moyenne des qubits de 20 secondes — et certains qubits atteignant jusqu’à 1 minute. Microsoft prévoit de se rapprocher de l’informatique quantique à grande échelle d’ici 2029, les outils d’agents IA contribuant apparemment à accélérer le filtrage des matériaux, l’automatisation des mesures et l’optimisation de la fabrication.
L’annonce a relancé les discussions externes sur les implications à long terme de l’informatique quantique pour la sécurité des signatures numériques de Bitcoin. Cette conversation mérite d’être menée sérieusement, mais le contexte est important : l’écart entre le matériel quantique actuel et le seuil de calcul nécessaire pour menacer la cryptographie à courbe elliptique de Bitcoin reste très important. Majorana 2 représente une avancée significative en matière de fiabilité des qubits, pas une menace imminente pour les réseaux blockchain en production.
Elle représente toutefois une raison crédible d’accélérer la recherche de migration post-quantique d’Ethereum — et pour des projets comme la Fondation Algorand, qui a publié une feuille de route de sécurité post-quantique visant une résistance quantique plus large d’ici fin 2027, de rester en avance sur la courbe. La question pratique pour chaque grand réseau blockchain n’est plus de savoir si une cryptographie résistante au quantique est nécessaire, mais quand la migration doit être achevée.
FAQ
Quel problème de confidentialité a été corrigé dans Bitcoin Core version 31.1 ?
Bitcoin Core 31.1 a corrigé une vulnérabilité de confidentialité dans la fonctionnalité -privatebroadcast de la version 31.0. Dans certaines conditions impliquant l’échec d’une poignée de main BIP324 v2, le logiciel revenait à une connexion v1 qui contournait le proxy Tor, exposant potentiellement l’adresse IP de l’initiateur de la transaction au nœud récepteur.
Quand la mise à niveau Glamsterdam d’Ethereum est-elle désormais attendue ?
La mise à niveau Glamsterdam d’Ethereum a été reportée à la seconde moitié de l’année. Le développement se poursuit via les itérations Devnet-5 et Devnet-6, tandis que le hard fork distinct Hegotá vise une fenêtre fin 2026 / début 2027.
Qu’est-ce qu’EIP-8182 et quelle est son importance ?
EIP-8182 est une proposition de transfert privé natif pour Ethereum, développée par Tom Lehman. Elle introduirait un mécanisme de transfert privé non obligatoire et sans frais de protocole directement à la couche L1 d’Ethereum, en utilisant des contrats système à adresse fixe et des précompilés de vérification ZK. Elle a été officiellement proposée pour inclusion dans le hard fork Hegotá et est importante car elle vise la confidentialité au niveau du protocole plutôt que de s’appuyer sur des outils de confidentialité fragmentés au niveau des applications.
Quelles menaces l’alerte de malware de SlowMist met-elle en évidence ?
SlowMist a identifié des variantes de malwares (Shai-Hulud, Miasma, Hades) exploitant le compte de développeur npm volé « czirker » pour infecter des paquets lors de l’installation. L’attaque vole des tokens GitHub et npm, des identifiants cloud sur AWS, GCP et Azure, ainsi que des données d’environnement local, tout en abusant de GitHub Actions. 23 paquets et 408 dépôts GitHub ont été confirmés comme affectés.
{« @context »: »https://schema.org », »@type »: »FAQPage », »mainEntity »:[{« @type »: »Question », »name »: »Quel problème de confidentialité a été corrigé dans Bitcoin Core version 31.1 ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Bitcoin Core 31.1 a corrigé une vulnérabilité de confidentialité dans la fonctionnalité -privatebroadcast de la version 31.0. Dans certaines conditions impliquant l’échec d’une poignée de main BIP324 v2, le logiciel revenait à une connexion v1 qui contournait le proxy Tor, exposant potentiellement l’adresse IP de l’initiateur de la transaction au nœud récepteur. »}},{« @type »: »Question », »name »: »Quand la mise à niveau Glamsterdam d’Ethereum est-elle désormais attendue ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »La mise à niveau Glamsterdam d’Ethereum a été reportée à la seconde moitié de l’année. Le développement se poursuit via les itérations Devnet-5 et Devnet-6, tandis que le hard fork distinct Hegotá vise une fenêtre fin 2026 / début 2027. »}},{« @type »: »Question », »name »: »Qu’est-ce qu’EIP-8182 et quelle est son importance ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »EIP-8182 est une proposition de transfert privé natif pour Ethereum, développée par Tom Lehman. Elle introduirait un mécanisme de transfert privé non obligatoire et sans frais de protocole directement à la couche L1 d’Ethereum, en utilisant des contrats système à adresse fixe et des précompilés de vérification ZK. Elle a été officiellement proposée pour inclusion dans le hard fork Hegotá et est importante car elle vise la confidentialité au niveau du protocole plutôt que de s’appuyer sur des outils de confidentialité fragmentés au niveau des applications. »}},{« @type »: »Question », »name »: »Quelles menaces l’alerte de malware de SlowMist met-elle en évidence ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »SlowMist a identifié des variantes de malwares (Shai-Hulud, Miasma, Hades) exploitant le compte de développeur npm volé « czirker » pour infecter des paquets lors de l’installation. L’attaque vole des tokens GitHub et npm, des identifiants cloud sur AWS, GCP et Azure, ainsi que des données d’environnement local, tout en abusant de GitHub Actions. 23 paquets et 408 dépôts GitHub ont été confirmés comme affectés. »}}]}
Article produit avec l’assistance de l’intelligence artificielle et relu par l’équipe éditoriale.
