Staker vos ETH à domicile

Lorsque vous exploitez votre propre nœud, vous devriez passer du temps à apprendre à utiliser le logiciel que vous avez choisi. Cela implique de lire la documentation pertinente et d'être attentif aux canaux de communication de ces équipes de développement.

Mieux vous comprendrez le logiciel que vous exécutez et le fonctionnement de la preuve d'enjeu (PoS), moins ce sera risqué en tant que staker, et plus il sera facile de résoudre les problèmes qui pourraient survenir en cours de route en tant qu'opérateur de nœud.

La configuration d'un nœud nécessite un niveau de confort raisonnable avec l'informatique, bien que de nouveaux outils rendent cela plus facile au fil du temps. La compréhension de l'interface en ligne de commande est utile, mais n'est plus strictement requise.

Cela nécessite également une configuration matérielle très basique et une certaine compréhension des spécifications minimales recommandées.

Les directives actuelles de la communauté concernant le matériel et la bande passante du validateur sont maintenues dans les recommandations sur le matériel et la bande passante (EIP-7870) (s'ouvre dans un nouvel onglet). À titre indicatif, prévoyez un SSD NVMe de 4 To, 64 Go de RAM (moins peut fonctionner, mais c'est la marge recommandée), un processeur multicœur moderne et solide, et une connexion Internet d'environ 50 Mbps en téléchargement / 25 Mbps en envoi.

Depuis que la mise à jour Fusaka a introduit PeerDAS, un nœud de staking n'a besoin de stocker et de télécharger qu'une fraction des données de blob du réseau, réduisant considérablement les exigences en matière de disque et de bande passante pour les stakers à domicile.

Tout comme les clés privées sécurisent votre adresse Ethereum, vous devrez générer des clés spécifiquement pour votre validateur. Vous devez comprendre comment conserver en toute sécurité toute phrase secrète ou clé privée.

Sécurité d'Ethereum et prévention des arnaques

À la différence des pénalités d'inactivité pour être hors ligne, la réduction est une pénalité beaucoup plus grave réservée aux infractions malveillantes. En exécutant un client minoritaire avec vos clés chargées sur une seule machine à la fois, votre risque de subir une réduction est minimisé. Cela dit, tous les stakers doivent être conscients des risques de réduction.

Oui. Un validateur avec des identifiants de retrait composés (0x02) peut détenir un solde effectif allant jusqu'à 2048 ETH, tandis que le minimum pour s'activer reste de 32 ETH. Les récompenses sur un validateur composé sont ajoutées automatiquement à sa mise, et il gagne des récompenses sur chaque ETH entier au-dessus du minimum de 32 ETH, vous pouvez donc staker des montants qui ne sont pas des multiples de 32. Voir Composition et le maximum de 2048 ETH.

Les validateurs avec des identifiants de retraits réguliers (0x01) restent plafonnés à un solde effectif de 32 ETH, tout solde supérieur à cela étant automatiquement transféré vers l'adresse de retrait tous les quelques jours.

Pour un validateur composé, seul le solde supérieur au maximum de 2048 ETH est transféré automatiquement. Pour retirer quoi que ce soit en dessous de cela, vous déclenchez un retrait partiel depuis votre adresse de retrait (une transaction qui coûte du gaz), ce qui peut réduire tout solde au-dessus du minimum de 32 ETH. Si vous exécutez plusieurs validateurs, vous pouvez également les consolider en un seul validateur composé sans sortir du réseau.

En savoir plus sur les retraits de staking

Se déconnecter lorsque le réseau se finalise correctement n'entraînera PAS de réduction. De petites pénalités d'inactivité sont encourues si votre validateur n'est pas disponible pour attester pendant une époque donnée (d'une durée de 6,4 minutes chacune), mais cela est très différent de la réduction. Ces pénalités sont légèrement inférieures à la récompense que vous auriez gagnée si le validateur avait été disponible pour attester, et les pertes peuvent être récupérées avec approximativement un temps égal de retour en ligne.

Notez que les pénalités pour inactivité sont proportionnelles au nombre de validateurs hors ligne en même temps. Dans les cas où une grande partie du réseau est hors ligne en même temps, les pénalités pour chacun de ces validateurs seront plus importantes que lorsqu'un seul validateur est indisponible.

Dans des cas extrêmes, si le réseau cesse de se finaliser parce que plus d'un tiers des validateurs sont hors ligne, ces utilisateurs subiront ce que l'on appelle une fuite d'inactivité quadratique, qui est un drainage exponentiel des ETH des comptes de validateurs hors ligne. Cela permet au réseau de s'auto-guérir à terme en brûlant les ETH des validateurs inactifs jusqu'à ce que leur solde atteigne 16 ETH, moment auquel ils seront automatiquement éjectés du pool de validateurs. Les validateurs en ligne restants finiront par représenter à nouveau plus des 2/3 du réseau, satisfaisant la supermajorité nécessaire pour finaliser à nouveau la chaîne.

En bref, cela ne peut jamais être totalement garanti, mais si vous agissez de bonne foi, exécutez un client minoritaire et ne conservez vos clés de signature que sur une seule machine à la fois, le risque de subir une réduction est presque nul.

Il n'y a que quelques moyens spécifiques pouvant entraîner la réduction et l'éjection d'un validateur du réseau. Au moment de la rédaction, les réductions qui se sont produites ont été exclusivement le produit de configurations matérielles redondantes où les clés de signature sont stockées sur deux machines distinctes en même temps. Cela peut entraîner par inadvertance un double vote de vos clés, ce qui est une infraction passible de réduction.

L'exécution d'un client supermajoritaire (tout client utilisé par plus des 2/3 du réseau) comporte également le risque d'une réduction potentielle dans le cas où ce client aurait un bug qui entraînerait un fork de la chaîne. Cela peut aboutir à un fork défectueux qui est finalisé. Pour revenir à la chaîne prévue, il faudrait soumettre un vote d'encerclement (surround vote) en essayant d'annuler un bloc finalisé. C'est également une infraction passible de réduction et peut être évitée simplement en exécutant un client minoritaire à la place.

Des bugs équivalents dans un client minoritaire ne se finaliseraient jamais et n'entraîneraient donc jamais de vote d'encerclement, et se traduiraient simplement par des pénalités d'inactivité, et non par une réduction.

• En savoir plus sur l'importance d'exécuter un client minoritaire.
• En savoir plus sur les récompenses, les pénalités et la réduction

Les clients individuels peuvent varier légèrement en termes de performances et d'interface utilisateur, car chacun est développé par des équipes différentes utilisant une variété de langages de programmation. Cela dit, aucun d'entre eux n'est le « meilleur ». Tous les clients en production sont d'excellents logiciels, qui remplissent tous les mêmes fonctions de base pour se synchroniser et interagir avec la chaîne de blocs.

Puisque tous les clients en production offrent les mêmes fonctionnalités de base, il est en fait très important que vous choisissiez un client minoritaire, c'est-à-dire tout client qui n'est PAS actuellement utilisé par une majorité de validateurs sur le réseau. Cela peut sembler contre-intuitif, mais l'exécution d'un client majoritaire ou supermajoritaire vous expose à un risque accru de réduction en cas de bug dans ce client. L'exécution d'un client minoritaire limite considérablement ces risques.

Bien qu'un serveur privé virtuel (VPS) puisse être utilisé en remplacement du matériel domestique, l'accès physique et l'emplacement de votre client validateur sont importants. Les solutions cloud centralisées telles qu'Amazon Web Services ou Digital Ocean offrent la commodité de ne pas avoir à acquérir et à exploiter de matériel, au détriment de la centralisation du réseau.

Plus il y a de clients validateurs exécutés sur une seule solution de stockage cloud centralisée, plus cela devient dangereux pour ces utilisateurs. Tout événement qui met ces fournisseurs hors ligne, que ce soit par une attaque, des exigences réglementaires, ou simplement des pannes de courant/d'Internet, entraînera la mise hors ligne simultanée de chaque client validateur qui dépend de ce serveur.

Les pénalités hors ligne sont proportionnelles au nombre d'autres personnes hors ligne en même temps. L'utilisation d'un VPS augmente considérablement le risque que les pénalités hors ligne soient plus sévères, et augmente votre risque de fuite quadratique ou de réduction dans le cas où la panne est suffisamment importante. Pour minimiser vos propres risques, et les risques pour le réseau, les utilisateurs sont fortement encouragés à acquérir et à exploiter leur propre matériel.

Chaque retrait nécessite que votre validateur ait une adresse de retrait définie. Les nouveaux stakers la définissent au moment de la génération de la clé et du dépôt. Les stakers des premiers jours du réseau qui n'ont pas encore défini d'adresse de retrait devront mettre à jour leurs identifiants de retrait avant de pouvoir retirer.

Pour les validateurs avec des identifiants de retraits réguliers (0x01), les paiements de récompenses (les ETH accumulés au-delà des 32 initiaux) sont périodiquement distribués automatiquement à l'adresse de retrait. Pour les validateurs composés (0x02), les récompenses restent stakées et se composent automatiquement. Vous pouvez retirer tout solde supérieur à 32 ETH en déclenchant un retrait partiel depuis votre adresse de retrait.

Pour débloquer et récupérer l'intégralité de votre solde, vous devez sortir votre validateur. Vous pouvez le faire en utilisant vos clés de signature de validateur, ou le déclencher directement depuis votre adresse de retrait avec une transaction de la couche d'exécution, ce qui signifie que vos fonds restent récupérables même si vos clés de signature sont perdues.