Attention aux risques de mise en gage : si vous utilisez Geth pour le staking, vous pourriez réellement perdre tous vos actifs
TechFlow SélectionTechFlow Sélection
Attention aux risques de mise en gage : si vous utilisez Geth pour le staking, vous pourriez réellement perdre tous vos actifs
L'article souligne la position de supermajorité du client Geth dans le réseau Ethereum et les risques potentiels qui en découlent.
Dédié à des analyses Web3 approfondiesRédaction : Labrys
Traduction : TechFlow
Cet article examine une panne survenue sur le client d'exécution Nethermind du réseau Ethereum, ayant entraîné la déconnexion de tous les validateurs utilisant Nethermind (environ 10 % du réseau). L'article souligne la position dominante du client Geth dans le réseau Ethereum et les risques potentiels qu'elle engendre. Bien que Geth soit un client stable et fiable, sa prévalence sur le réseau signifie qu'une panne majeure pourrait avoir un impact significatif sur l'ensemble du réseau. L'article appelle la communauté à accorder plus d'attention à la diversité des clients d'exécution afin de réduire les risques liés à la centralisation.
Introduction
Cette semaine, un client d'exécution du réseau Ethereum, Nethermind, a connu une panne qui a provoqué la déconnexion de tous les validateurs exécutant Nethermind (soit environ 10 % du réseau).
Il s'agit d'un incident mineur, car Nethermind est utilisé par une minorité d'acteurs. Voici ci-dessous un graphique montrant le solde total de mes propres validateurs fonctionnant avec Nethermind. On peut observer qu'autour de 4 heures locale, au moment où la panne est intervenue, les validateurs se sont déconnectés. L'équipe a publié un correctif environ quatre heures plus tard ; une fois installé, mes validateurs ont repris leur activité vers 9 heures locale. Pendant cette période, la pénalité subie par mes validateurs équivalait aux récompenses qu'ils auraient perçues. Dans l'après-midi, vers 13 heures, leur solde était supérieur à ce qu'il était avant l'incident. Globalement, il s'agissait donc d'une panne mineure.
Beaucoup supposent à tort que si une panne similaire affectait Geth, les pénalités seraient comparables. Ce n'est pas vrai. Cela n'a rien à voir avec Geth lui-même ou la manière dont il est conçu, mais avec le nombre massif d'utilisateurs de Geth.
Selon les données de ClientDiversity.org, environ 84 % des validateurs d'Ethereum exécutent Geth. La justification avancée par ces acteurs est que Geth est incontestablement le meilleur et le plus stable des clients. Alors que des clients minoritaires comme Nethermind ont été touchés cette semaine par des pannes et interruptions, Geth fonctionne bien depuis la fusion (et même auparavant). D'après mon expérience personnelle, lorsqu'on passe de Geth à un client minoritaire, on constate que les validateurs nécessitent davantage de ressources et ratent plus souvent leurs validations.
Cet article ne constitue pas une attaque contre Geth. J'ai beaucoup de respect pour leur équipe. Malheureusement, en raison de l'utilisation massive de Geth, nous devons discuter honnêtement des risques encourus lorsque Geth détient la grande majorité des stakings.
Personne ne souhaite quitter Geth, surtout ceux qui dépendent du temps de fonctionnement pour promouvoir des rendements maximaux, comme les opérateurs professionnels de staking, sachant pertinemment qu'ils risquent davantage de rater des attestations et connaître plus d'arrêts.
À partir de septembre dernier, on estimait que le plus grand opérateur, Lido, faisait fonctionner environ 76 % de ses validateurs sous Geth.
Mais je suis content d'exécuter un client minoritaire, même si cela me fait perdre quelques récompenses supplémentaires, non pas parce que je suis altruiste au point de sacrifier mes intérêts pour la décentralisation du réseau, mais parce que je sais que mon ETH sera ainsi protégé de la majorité des bogues.
Que se passerait-il si Geth avait un bogue ?
Cela dépend du bogue lui-même.
Comme plus des deux tiers des validateurs Ethereum exécutent Geth, tout bogue grave dans Geth empêcherait immédiatement la finalisation de la chaîne. Cela ne signifie pas que la chaîne s'arrête ou est interrompue. Tant que les autres clients continuent de fonctionner, la chaîne poursuit son activité. Environ 84 % des blocs seront manqués, ce qui signifie qu'un nouveau bloc serait produit toutes les 75 secondes environ, au lieu des 12 secondes habituelles. Ces blocs seraient sujets à des réorganisations, et donc, une fois la chaîne relancée, les transactions qu’ils contiennent ne seraient pas garanties. Cela semble grave, mais rappelons-nous qu’avant la fusion, Ethereum n’a jamais eu de notion de confirmation finale pendant des années, et il en va de même aujourd’hui pour Bitcoin — c’est pourquoi les bourses exigent généralement 6 confirmations ou plus avant d’accepter un dépôt, afin de réduire le risque de perte lié à une réorganisation.
Certains peuvent se souvenir qu’en mai 2023, Ethereum a déjà vécu une telle situation, quand un bogue est apparu dans certains clients de consensus. Pendant deux jours, la chaîne a cessé deux fois d’être finalisée, entraînant la perte de nombreux blocs, et à un moment donné, seulement 40 % du réseau fonctionnait encore. Après la récupération du réseau, la plupart des utilisateurs de DApp n’ont remarqué aucun problème, excepté un ralentissement des confirmations de transactions.
Mais qu’en est-il des validateurs ?
Fuite d’inactivité
Lorsqu’un client minoritaire tombe en panne, la pénalité consiste à perdre des ETH au même rythme que celui auquel ils sont gagnés (comme visible sur le graphique de mon validateur ci-dessus). Mais si Geth tombe en panne, comme cela bloque immédiatement la finalisation de la chaîne, la pénalité est bien plus sévère. Cette pénalité accrue s’appelle la « fuite d’inactivité » (inactivity leak), appliquée aux validateurs déconnectés lorsque la chaîne cesse d’être finalisée pendant 4 périodes (environ 25 minutes) ou plus. Cette sanction plus stricte vise à encourager les validateurs déconnectés à revenir en ligne rapidement, ou, dans le pire des cas, à détruire progressivement leurs mises jusqu’à ce que leur part totale descende sous 1/3, permettant ainsi aux validateurs en ligne de finaliser la chaîne.
Pendant la fuite d'inactivité, un validateur déconnecté pendant seulement 2 jours perd 0,6 % de sa mise, soit l’équivalent de 2 mois de récompenses !
Après 5 jours de déconnexion, toute une année de récompense de staking (3,5 %) est perdue ! Cela signifie qu’il faudrait plus de 2 ans de staking pour retrouver le solde précédent l’incident.
En une semaine, 10 % de la mise, soit 3 années de récompenses, seront perdus. En environ 20 jours, 50 % de la mise seront perdus, et en environ 40 jours, 90 % de la mise seront perdus.
En comparaison, un validateur déconnecté en raison d’un bogue dans un client minoritaire ne perd que 0,4 % de sa mise après 40 jours.
Combien de temps durera la punition d'inactivité ?
Cela dépend du bogue.
Si le bogue peut être corrigé, la punition durera le temps nécessaire à l’équipe Geth pour publier le correctif et que vous l’appliquiez à votre validateur (ou que vous passiez à un autre client d’exécution).
En pratique, on s’attend à ce que le problème soit résolu en quelques heures ou au maximum quelques jours. Si le correctif prend autant de temps que l’incident récent de Nethermind, un validateur perdra 0,004 % de sa mise, ce qui n’est pas un problème majeur.
Le scénario devient grave si le bogue conduit les validateurs à produire des blocs invalides, que Geth considère comme valides et sur lesquels il atteste. Cela provoquerait un fork de la chaîne. La chaîne se diviserait en deux branches : une contenant des blocs invalides (chaîne Geth), et l’autre ignorant ces blocs (chaîne non-Geth). Les validateurs exécutant Geth considéreraient les deux branches comme valides, et choisiraient donc de construire sur celle ayant le poids le plus élevé. 84 % des validateurs mettent en jeu leur mise sur la chaîne Geth, contre seulement 16 % sur la chaîne non-Geth. Ainsi, les validateurs Geth choisiront la chaîne Geth comme étant la plus lourde et continueront à y construire.
Bien sûr, une fois que tous ces problèmes seront résolus, les blocs de la chaîne Geth seront abandonnés (ce qui posera ses propres problèmes), mais le plus grave est que la chaîne Geth disposera d’assez de mise (plus de 2/3) pour finaliser la chaîne invalide.
Une fois la chaîne Geth finalisée, un validateur qui a attesté sur cette chaîne ne peut plus participer à la construction de la chaîne non-Geth (jusqu’à ce que celle-ci soit aussi finalisée), sans risquer d’être puni. En réalité, les validateurs Geth sont désormais engagés sur la chaîne invalide et bloqués dessus jusqu’à ce que la chaîne non-Geth soit finalisée. C’est précisément là que réside le risque clé mal compris par beaucoup.
Étant donné que les validateurs Geth sont piégés sur la chaîne invalide, ils sont considérés comme inactifs sur la chaîne non-Geth et subissent donc la fuite d’inactivité. Aucune mise à jour logicielle ni correctif ne peut sauver ces validateurs. Ils seront progressivement vidés jusqu’à ce que leur mise représente moins d’un tiers du total, permettant alors à la chaîne non-Geth d’être finalisée.
Actuellement, 28 976 695 ETH sont misés sur le réseau. Parmi eux, 84 % (environ 24 millions d’ETH) sont attribuables aux validateurs exécutant Geth, et 16 % (environ 5 millions d’ETH) aux validateurs ne l’exécutant pas. Pour que la chaîne non-Geth puisse être finalisée, les validateurs Geth doivent voir leur mise détruite jusqu’à ce qu’elle représente moins d’un tiers du total. Cela implique de détruire environ 21,5 millions d’ETH (près de 90 % de leur mise), ramenant leur mise restante à environ 250 000 ETH, inférieure au tiers du total (2,5 millions + 5 millions d’ETH). Les 5 millions d’ETH contrôlés par les validateurs non-Geth représenteraient alors plus des deux tiers, leur permettant de finaliser la chaîne.
Ce processus serait extrêmement douloureux, prenant environ 40 jours. Il entraînerait une réduction d’environ 18 % de l’offre totale d’ETH, abaissant le total à moins de 100 millions d’ETH.
Course vers la sortie
Un point important ici est que les validateurs sur la chaîne invalide ne resteront probablement pas passifs. Ils ont toujours la possibilité de retirer leur mise, et même s’ils ne le font pas, le réseau les expulsera automatiquement lorsque leur solde effectif atteint 16 ETH. Mais cela ne signifie pas que leur perte se limite à 16 ETH.
Lorsqu’un validateur quitte (même s’il est forcé), il entre dans une file d’attente de sortie, et tant qu’il est dans cette file, il continue de perdre des ETH !
Nous savons que, dans le pire des cas, environ 40 jours sont nécessaires pour que la fuite d’inactivité permette à la chaîne valide de reprendre la finalisation. Combien de temps dure la file d’attente de sortie ?
La file d’attente de sortie comporte une limite de sortie, qui restreint le nombre de validateurs pouvant quitter le réseau chaque période (environ 6,4 minutes). Cette limite est définie comme suit :
Actuellement, 13 validateurs sortent toutes les 6,4 minutes. Si tous les validateurs Geth souhaitent sortir, il faudrait au moins environ 260 jours pour que tous soient sortis. Étant donné que 90 % de la mise sera détruite en environ 40 jours, la majorité des validateurs auront vu leur solde vidé avant même de pouvoir sortir.
Les 2 % premiers validateurs Geth à initier une sortie pourront sortir dans les 5 premiers jours, avec une perte maximale équivalant à une année de récompense de staking.
Vous devez faire partie des 3 % premiers à sortir pour limiter vos pertes à moins de 10 % de votre mise.
Seuls les 8 % premiers à sortir pourront limiter leurs pertes à moins de 50 % de leur mise. À ce stade, toute personne n’ayant pas initié manuellement sa sortie sera expulsée de force et placée dans la file d’attente avec un solde effectif de 16 ETH.
Quarante jours plus tard, lorsque 90 % de leur mise aura été détruite, plus de 85 % des validateurs seront encore dans la file d’attente.
La possibilité de sortir ne vous sauvera pas. Votre risque à la baisse ne se limite pas à la perte imposée par l’expulsion forcée (16 ETH).
Et la punition par slashing ?
Certaines personnes pensent à tort que les stakers Geth subiraient non seulement la fuite d’inactivité, mais aussi une punition par slashing en cas de bogue. C’est faux.
La punition par slashing ne s’applique qu’aux doubles signatures, entièrement contrôlées par le client de consensus. Un bogue dans Geth ne devrait pas amener le client de consensus à commettre une erreur passible de slashing. Le fait que Geth produise des blocs invalides n’est pas une erreur passible de slashing.
Seule la punition par fuite d’inactivité s’applique en cas de bogue dans Geth.
Que devriez-vous faire ?
Les stakers actuels utilisant Geth ne comprennent peut-être pas pleinement les risques liés à l’utilisation d’un client d’exécution en quasi-monopole. Beaucoup supposent à tort qu’en cas de bogue, un correctif sera publié en quelques heures, avec peu de pertes d’Ether.
Beaucoup ignorent que le risque d’attester un bloc invalide pourrait les enfermer sur une chaîne invalide finalisée, entraînant presque certainement la destruction de la majeure partie de leur ETH. C’est un risque réel qui pourrait devenir concret.
Staker de l’Ethereum n’est pas un placement sans risque. Investiriez-vous au moins 75 000 dollars dans un outil dont le gain potentiel maximal annuel est de 3,5 %, mais qui pourrait entraîner une perte de 100 % ? Probablement pas. Pourtant, c’est exactement ce que font aujourd’hui 84 % des stakers Ethereum.
En passant à un client minoritaire (en supposant qu’un même bogue n’apparaît pas dans plusieurs clients), vous pouvez limiter vos pertes maximales à 3,5 % par an.
Avec ces connaissances, continuer à exécuter Geth semble insensé. Je ne peux supposer que ceux qui utilisent Geth ne comprennent pas pleinement ce risque.
Si vous détenez un LST (par exemple stETH, cbETH, etc.) et que ce LST utilise Geth pour ses validateurs, comprenez que votre Ether est exposé, et envisagez de désengager ou de basculer vers un autre LST, jusqu’à ce que Geth ne domine plus aussi largement.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@Labrys_io
