Sigma Prime, l’équipe derrière Lighthouse, a publié Lighthouse v8.3.3, datée du 9 novembre sur sa page de versions GitHub, et demande à tous les opérateurs d’un nœud beacon Lighthouse de passer à cette version « dès que possible ». Les notes de version la présentent comme un correctif à haute priorité qui contient des correctifs de sécurité. Elles ne disent pas de quelles failles blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il s’agit : les détails seront « divulgués ultérieurement », une fois que les opérateurs auront eu le temps d’installer la nouvelle version.
L’affaire dépasse une seule équipe logicielle. Selon au moins un décompte, Lighthouse est le client de consensus le plus utilisé d’Ethereum : Miga Labs le crédite de 46,96 %, dans les données affichées sur clientdiversity.org lorsque Coindaro les a consultées le 11 novembre. Un autre suivi de la même page, Rated.Network, indique 20,6 %. Un bug sérieux dans un client de cette taille concerne tout le réseau.
Ni les notes de version ni le article de CryptoSlate du 11 novembre ne mentionnent d’exploitation ni de perte de fonds. CryptoSlate souligne aussi que le mécanisme des failles et leur impact potentiel n’ont pas été rendus publics.
Ce que dit la version Lighthouse v8.3.3, et ce qu’elle garde pour plus tard
La version, surnommée « Sleepy Gary » et signée avec la clé PGP de Sigma Prime, contient un tableau des priorités de mise à jour. Il sépare le logiciel en ses deux parties : le nœud beacon, qui suit la chaîne et dialogue avec les autres nœuds, et le client validateur, qui détient les clés de signature et émet les votes.
| Composant | Utilisateurs qui stakent | Utilisateurs qui ne stakent pas |
|---|---|---|
| Nœud beacon | Haute | Haute |
| Client validateur | Basse | Non évaluée |
L’urgence porte donc sur le nœud beacon, pour tous ceux qui en font tourner un, qu’ils stakent ou non. Le client validateur peut attendre un cycle de mise à jour normal. Dans l’échelle de priorité de Lighthouse, telle que la résume CryptoSlate, « haute » veut dire agir sous quelques heures ou quelques jours, tandis que « basse » relève de la prochaine mise à jour de routine, avec deux semaines données en exemple.
Les notes ne signalent aucun changement incompatible. Les opérateurs encore en v8.2.x ou plus ancienne sont invités à lire d’abord les notes de la version v8.3.0, car celle-ci apportait ses propres changements.
La liste publique des modifications est courte : une mise à jour de libp2p, une montée de version de crypto-bigint, des changements dans la façon dont les requêtes entrantes et les sous-flux expirés sont comptés puis libérés, la correction d’une méthode is_infinity et quelques correctifs de compilation. La version ne précise pas lesquelles de ces lignes, le cas échéant, sont les correctifs de sécurité. Y lire une carte des bugs relèverait de la conjecture.
Ce que l’on ignore au 11 novembre : quelles versions sont touchées, quelle est la gravité des failles et qui les a signalées. Lighthouse n’a pas non plus donné de date pour les avis de sécurité.
Pourquoi Sigma Prime garde les détails secrets pour l’instant
Retenir les détails est la politique affichée de Sigma Prime. Quatre jours avant la version, le 5 novembre, l’ingénieur de Sigma Prime Tan Chee Keong a décrit la procédure dans un billet de blog sur les rapports de bugs. Les chercheurs signalent les failles via le programme de bug bounty de l’Ethereum Foundation ou par e-mail ; un développeur répond généralement sous 24 heures avec un premier avis sur la validité et la gravité. Sigma Prime fait aussi tourner son propre outil d’analyse sur le code et reçoit les bugs trouvés par l’équipe de sécurité du protocole de l’Ethereum Foundation.
Selon cette politique, le correctif sort d’abord et les détails attendent. Ils sont publiés plus tard dans les notes de version et les avis de sécurité GitHub, une fois que les utilisateurs ont eu le temps de se mettre à jour.
Le même billet donne un aperçu rare des chiffres. Sur 81 rapports clos, 54 % se sont révélés valides. Parmi eux, 45 % ont été jugés de gravité faible, 41 % moyenne et 14 % haute, et Sigma Prime dit n’avoir pas encore reçu de rapport critique. Le délai médian entre le rapport et le correctif fusionné a été de 17 jours, la moyenne de 33.
L’historique va dans le même sens. La page des avis de sécurité de Lighthouse recense des correctifs antérieurs dont les détails ont été publiés après coup, dont quatre avis du 26 octobre 2026 (un de gravité haute, pour une saturation de la mémoire lors du service de requêtes de colonnes de données) et trois du 15 octobre. Les versions à haute priorité ne sont pas rares non plus. La page des versions classe les v8.2.0 (22 juin), v8.2.1 (21 juillet) et v8.2.2 (18 août) en haute priorité pour les nœuds beacon, chacune avec des correctifs de sécurité, et la v8.3.1 (22 octobre) en haute priorité pour les stakers après la compromission de l’autorité de certification eMudhra.
Ce que doivent faire les stakers solo et les opérateurs de nœuds
- Si vous faites tourner un nœud beacon Lighthouse, passez-le en v8.3.3 maintenant. Des binaires existent pour Linux x86_64 et aarch64 et pour les Mac Apple Silicon, et l’image Docker est sigp/lighthouse :v8.3.3.
- Vérifiez la signature PGP du téléchargement avec la clé de Sigma Prime, indiquée sur la page de la version, avant de l’installer.
- Mettez à jour le client validateur Lighthouse lors de votre prochaine maintenance courante. La version le classe en basse priorité.
- Vous venez de la v8.2.x ou d’une version plus ancienne ? Lisez les notes de la v8.3.0 avant de sauter le pas.
- Surveillez la page de la version : les liens vers les avis de sécurité y seront ajoutés une fois que les opérateurs auront eu le temps de se mettre à jour.
Ceux qui stakent via une plateforme d’échange, un protocole de staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">liquid staking ou un service de staking n’ont rien à installer : c’est leur opérateur de nœud qui fait tourner le logiciel. Dans un cluster de validateurs distribués construit avec Obol ou SSV Network, le conseil vaut pour chaque machine qui fait tourner un nœud beacon Lighthouse. La version ne concerne que Lighthouse. Pour les bases du rôle de chaque machine, voir notre guide des nœuds blockchain.
Pourquoi la part de marché d’un seul client compte
La preuve d’enjeu d’Ethereum exige que deux tiers des validateurs s’accordent avant qu’un bloc devienne final. La part d’un client devient ainsi un indicateur de sécurité. Si un client utilisé par plus d’un tiers des validateurs tombe en panne, la chaîne peut continuer à produire des blocs mais ne peut plus les finaliser. Si un client bogué dépassait les deux tiers, il pourrait finaliser une mauvaise chaîne. Clientdiversity.org fixe l’objectif à moins de 33 % pour chaque client et qualifie de zone de danger tout ce qui dépasse 66 %.
La place de Lighthouse dépend de celui qui compte, et les suivis divergent fortement.
| Suivi (clientdiversity.org, lu le 11 nov. 2026) | Lighthouse | Prysm | Teku | Nimbus |
|---|---|---|---|---|
| Miga Labs | 46,96 % | 17,73 % | 6,45 % | 18,86 % |
| Rated.Network | 20,6 % | 21,17 % | 53,86 % | 3,12 % |
La page indique que chaque source est mise à jour quotidiennement mais n’affiche aucune date pour ces relevés, et elle prévient que les données « peuvent ne pas être exactes à 100 % ». Un troisième suivi, Blockprint, donnait Teku à 99,83 % et Lighthouse à 0,16 % le 11 novembre, très loin des deux autres lectures. Selon Miga Labs, Lighthouse se situe au-dessus du seuil du tiers et sous celui des deux tiers. Selon Rated, il reste nettement sous le tiers.
Le sursaut de Prysm en décembre 2025
Ethereum a déjà vu ce qu’est un bug de client. La mise à niveau Fusaka a été activée sur le mainnet le 3 décembre 2025 à 21 h 49 UTC, selon l’Ethereum Foundation. Le lendemain, les nœuds Prysm ont manqué de ressources en traitant des attestations de nœuds désynchronisés et ont reconstruit d’anciens états de zéro, d’après le compte rendu de Cointelegraph sur le post-mortem de Prysm.
À l’époque 411 448, la participation aux votes est tombée à 74,7 %, soit environ huit points au-dessus de la barre des deux tiers, a rapporté Cointelegraph à partir de données de beaconcha.in. Elle est remontée à près de 99 % à l’époque 411 712. Les validateurs ont perdu environ 382 ETH de récompenses d’attestation sur plus de 42 époques, selon le même article de Cointelegraph, publié le 15 décembre 2025. Prysm détenait moins d’un tiers du réseau, la finalité a donc tenu.
Anthony Sassano, éducateur Ethereum, a écrit sur X à l’époque, comme le cite Cointelegraph, que le réseau aurait perdu la finalité si le bug avait touché Lighthouse. Dans son article du 5 décembre 2025, Cointelegraph, citant MigaLabs, plaçait Lighthouse à 52,55 % après l’incident, contre moins de 48,5 % avant. Le relevé de Miga Labs sur clientdiversity.org le 11 novembre 2026 est de 46,96 %.
Le 7 novembre, le client d’exécution Reth a connu sa propre faille, qui a poussé Base, BNB Chain et Tempo à se corriger. Pour comprendre comment fonctionnent les devoirs manqués et les pénalités, voir notre guide du slashing et des récompenses des validateurs Ethereum.
À surveiller ensuite
La prochaine étape est la divulgation elle-même. Lighthouse indique que les liens vers les avis de sécurité apparaîtront sur la page de la version v8.3.3 une fois que les opérateurs auront mis à jour. Quand les avis tomberont, ils devraient préciser quelles versions étaient exposées et quelle était la gravité des failles. Lighthouse n’a donné aucune date.