Ce mois-ci a rendu cela indéniable : gérer de gros montants d’ethereum : staking natif sur des points uniques de défaillance n’est pas une stratégie sûre à long terme pour vos fonds. Nous introduisons Validator Beat, un cadre simple pour garantir que votre staking est exploité en toute sécurité. La phase 1 signifie qu’aucun point unique de défaillance ne vous fera slashing. La phase 2 signifie qu’aucun point unique de défaillance ne vous mettra hors ligne. Les défaillances des validateurs de la phase 0 pourraient vous coûter des semaines de récompenses au mieux, ou des décennies de récompenses, voire tout votre capital au pire. Ne prenez pas de raccourcis dans un espace à risque asymétrique comme celui-ci ; c’est comme ramasser des pièces de un cent devant un rouleau compresseur.

Pourquoi vous ne devriez pas mettre en staking votre ETH sur une configuration à point unique de défaillance en une seule image

Le fait que la majeure partie d’Internet public soit chiffrée par ces 6 « clés privées » révèle beaucoup sur les systèmes à point unique de défaillance. Votre portefeuille de staking ETH mérite mieux. Mettez uniquement en staking sur des configurations de validateur distribué de première étape, où aucun opérateur ne peut choisir une clé privée comme celle-ci à votre place 🫠

Ethereum envisage des pénalités de temps d'arrêt corrélées pour les stakers, une idée de @VitalikButerin. L'objectif est de décourager les points centraux de défaillance avant qu'ils ne provoquent un événement massif de slashing. J'ai créé un site web pour comprendre le EIP et pourquoi nous devrions l'adopter. 🔗 ci-dessous, tl;dr👇

Quels sont certains des plus grands wallets à clé privée unique qui signent de manière programmatique ? Des bots MEV, des wallets chauds d'échange, peut-être, mais pas des oracles (multisig), pas des ponts (multisig), pas de DeFi… Tout ce qui possède une valeur significative à protéger évolue vers l'utilisation de plusieurs configurations avec tolérance aux pannes et diversité pour la sécurité. Au niveau de la couche de consensus, je pense que nous sommes en retard par complaisance. Je dirais que moins de 1 % du stake, voire 0 %, sont exécutés sur des configurations appropriées sans point unique de défaillance, selon à quel point vous voulez être rigoureux dans votre définition. Nous passons sous silence le fait qu'un pirate peut simplement détruire votre argent au lieu de le voler, ce qui le rend moins attrayant pour eux — ce qui peut être vrai — mais je ne suis pas sûr que ce soit suffisant ; lorsque les coûts des campagnes de spear phishing pilotées par l'IA diminuent et que leur qualité augmente. La défense doit réussir à chaque fois, l'attaque n'a besoin de réussir qu'une seule fois. Ce n'est pas symétrique. Nous avons eu un échappatoire de justesse l'année dernière avec 10 % du jeu de validateurs, et nous l'avons presque oublié. Il est également rationnel pour un pirate d'accumuler des clés volées plutôt que de se manifester après avoir volé certaines clés. L'avantage d'un pirate augmente de manière non linéaire avec la quantité d'ETH qu'il peut slasher. Nous ne savons pas combien de clés ont déjà été volées en silence, mais je ne pense pas que ce soit 0. Essayons de régler cela avant, et non après, une catastrophe. Exécutons davantage de validateurs distribués, réduisons le nombre de points uniques de défaillance dans nos configurations de staking, et rendons Ethereum plus anti-fragile.

@dsrvlabs déploient des validateurs distribués depuis notre tout premier réseau de test public il y a quatre ans. C’est un grand plaisir de les voir désormais adopter des validateurs distribués pour une part significative de leur staking dans l’ensemble curaté par Lido. Ce déploiement leur permettra d’exécuter jusqu’à 40 validateurs distribués 0x02 dans le cadre de la transition de consolidation en cours de Lido.

En principe, pénaliser les pannes corrélées pousse le réseau vers la diversité que nous souhaitons tous, et si les calculs sont vérifiés, la charge côté client est faible. Nous avions initialement des hésitations, mais la méthodologie a été récemment corrigée par Oisin chez Obol. Un bogue client qui met hors ligne un grand groupe est pénalisé plus sévèrement, tandis que les clients minoritaires et les opérateurs bien conçus avec une infrastructure diversifiée à peine le remarquent. Avec l'énoncé mis à jour, clair et étayé par des données, précisant exactement quel comportement il s'agit de décourager, nous sommes intéressés à voir cela être mis en œuvre s'il y a du temps. Heureux de voir le vote de confiance et l'approbation de l'équipe Lodestar en faveur de l'EIP 7716, dans la limite de la capacité d'Hegota 🎉

Je dirais que je suis surpris, mais en réalité je suis simplement déçu par la présomption continue de l’EF Protocol quant à la décentralisation comme donnée acquise. Permettez-moi d’être clair : FOCIL ne fonctionne pas si l’ensemble des attestateurs ne le veut pas. Le focus des priorités du protocole met en avant la préparation post-quantique comme objectif, d’accord, et rend hommage à CROPS : « FOCIL est le pilier de la couche de consensus de Hegotá. Notre appétit au-delà de celui-ci est presque nul, sauf si une addition soutient directement la préparation post-quantique. » L’éléphant dans la pièce que l’EF continue d’ignorer est que la chaîne se centralise à un rythme rapide, et qu’il n’y a aucun intérêt à reconnaître ces problèmes ou à les prioriser pour les résoudre. Par exemple, les pénalités de corrélation (7716) qu’ils décrivent comme : « Ajoute une surface de slashing pour la corrélation des validateurs sans contribution CROPS ou PQ. Pas une priorité dans un fork, nous cherchons à garder le champ d’application de la CL léger. » C’est déjà inexact : 7716 n’a aucun mécanisme de slashing, et il est au mieux malavisé d’affirmer qu’il ne contribue pas à CROPS. 7716 est le meilleur EIP sur la table pour améliorer la diversité des clients et pénaliser la centralisation. Ce n’est pas une solution miracle, mais c’est ce que nous avons, et il ne doit pas être DFI’d. Passer un an sur H-star pour déployer FOCIL sans traiter les problèmes sous-jacents de l’ensemble des validateurs risque de faire dire aux quelques entités de staking centralisées : « En fait, non » et de refuser d’attester les créneaux avec des IL qu’elles n’apprécient pas. Cela ne leur coûte aucune récompense ; penser que nous les socialiserons en slashing pour cela relève du vœu pieux, et maintenant Ethereum est compromis et vous avez besoin d’une autorisation pour utiliser la chaîne. Prévenir ce résultat ne dépend pas d’un seul EIP sur la marge ; il faut un changement culturel au sein de l’EF pour qu’ils comprennent qu’ils n’ont pas un droit divin de Dieu à une chaîne décentralisée, et qu’ils ne peuvent pas se concentrer uniquement sur des défis académiques comme la PQ tout en ignorant les défis réels comme l’accélération continue de la centralisation de la chaîne. Nous avons besoin d’un rapport trimestriel sur l’état de la chaîne, pour rendre plus difficile le fait de garder la tête dans le sable face à la gravité de la situation. Nous avons besoin d’au moins un EIP par fork axé sur l’amélioration du Nakamoto, du Gini de staking ou d’un autre aspect de l’ensemble des validateurs, et nous avons besoin d’un leadership pragmatique, orienté action, qui se soucie véritablement que Ethereum soit CROPS au-delà d’un simple test de pureté. (J’espère que c’est @pcaversaccio.) Il existe certaines personnes au sein de l’EF qui se soucient réellement que la chaîne soit CROPS, mais à moins que nous, la communauté, ne soyons clairs et fermes dans nos exigences, ils ne seront pas écoutés. Montrez-leur pourquoi nous sommes des partisans d’Ethereum et non d’une autre chaîne centralisée ; défendez la décentralisation et CROPS dans H-star et au-delà. Merci.

Le nombre de rapports de vulnérabilités que nous recevons a également suivi une courbe similaire sur la même période ; il a été difficile d’y faire face. De nombreux problèmes de type « duplicata, pas de correction » (oui, vous pouvez consulter nos API publiques, c’est exactement leur but), mais aussi de nombreux problèmes valides et modérés que nous avons corrigés et rémunérés. Presque tout le capital actif d’ethereum, soit 100 milliards de dollars, présente au moins un point unique de défaillance susceptible de provoquer une fuite de ses clés et une pénalisation. Une mauvaise opsec, des chaînes d’approvisionnement défaillantes, une exposition élevée à des logiciels, systèmes d’exploitation, processeurs spécifiques, etc., pourraient entraîner, pour les déléguateurs qui font confiance à des configurations individuelles, une perte allant jusqu’à 100 % de leur capital. Nous allons aider à simplifier et mettre en évidence ces points uniques de défaillance dans une nouvelle initiative visant à améliorer la sécurité d’ethereum et la sécurité des ETH de ses stakers. En cas de succès, la plupart des organisations passeront des configurations à point unique de défaillance à des systèmes de staking sans point unique de défaillance, tels que les configurations distribuées de validateurs multi-opérateurs. Cela permettra de mieux sécuriser les fonds de leurs stakers et d’assurer qu’ethereum ne tombe jamais en panne.

Ceci représente une avancée majeure pour les blockchains post-quantiques. Les signatures seuil constituent un élément fondamental pour l'utilisation sécurisée d'une blockchain, et jusqu'à présent, aucune solution n'existait pour les implémenter avec un schéma post-quantique. Ethereum sera sécurisé face aux menaces post-quantiques sans avoir à sacrifier la sécurité au niveau des applications et de la consensus. Des validateurs distribués post-quantiques, quand ?