Miser individuellement votre ETH à domicile

Oui, les comptes de validateurs modernes sont capables de contenir jusqu’à 2048 ETH. Les ETH supplémentaires au-delà de 32 s'accumuleront de manière progressive, augmentant par paliers de nombres entiers à mesure que votre solde réel augmente. Ceci est connu sous le nom de solde effectif.

Pour augmenter le solde effectif d’un compte, et donc accroître les récompenses, il faut dépasser une marge de 0,25 ETH au-delà de chaque palier entier en ETH. Par exemple, un compte avec un solde réel de 32,9 ETH et un solde effectif de 32 ETH devrait gagner encore 0,35 ETH pour porter son solde réel au-delà de 33,25 ETH avant de déclencher une augmentation du solde effectif.

Cette marge empêche également le solde effectif de baisser tant qu’il n’est pas descendu de 0,25 ETH en dessous de son solde effectif actuel.

Chaque paire de clés associée à un validateur nécessite au minimum 32  ETH pour être activée. Tout solde au-delà de ce montant peut être retiré à l’adresse de retrait associée à tout moment, via une transaction signée par cette adresse. Tout fonds dépassant le solde effectif maximal sera automatiquement retiré de façon périodique.

Si la mise en jeu à domicile vous semble trop exigeante, envisagez d'utiliser un fournisseur de mise en jeu en tant que service, ou si vous disposez de moins de 32 ETH, consultez les pools de mise en jeu.

Se déconnecter pendant que le réseau se finalise correctement n'entraînera PAS de délestage. 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 reste très différent du délestage. Ces pénalités sont légèrement inférieures à la récompense que vous auriez obtenue si le validateur avait été disponible pour attester, et les pertes peuvent être récupérées avec un temps de remise en ligne à peu près équivalent.

Notez que les pénalités d'inactivité sont proportionnelles au nombre de validateurs se trouvant 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 valideurs sont hors ligne, ces utilisateurs subiront ce que l'on appelle une fuite d'inactivité quadratique, qui consiste en une fuite exponentielle d'ETH à partir de comptes de valideurs hors ligne. Cela permet au réseau de s'auto-régénérer en brûlant les ETH des validateurs inactifs jusqu'à ce que leur solde atteigne 16 ETH, après quoi ils seront automatiquement éjectés du pool de validateurs. Les validateurs en ligne restants comprendront finalement, à nouveau, 2/3 du réseau, satisfaisant ainsi la supermajorité nécessaire pour finaliser à nouveau la chaîne.

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

Seuls quelques moyens spécifiques peuvent aboutir à ce qu'un validateur soit délesté et éjecté du réseau. À l'heure où nous écrivons ces lignes, les délestages qui se sont produits sont exclusivement le produit de configurations matérielles redondantes où les clés de signature sont stockées sur deux machines distinctes à la fois. Cela peut entraîner par inadvertance un double vote de vos clés, ce qui constitue une faute passible de délestage.

L'exécution d'un client supermajoritaire (tout client utilisé par plus de 2/3 du réseau) comporte également le risque d'un délestage potentiel dans le cas où ce client présente un bogue qui entraîne une fourche de la chaîne. Cela peut aboutir à une fourche défectueuse qui sera finalisée. Pour revenir à la chaîne voulue, il faudrait soumettre un vote circulaire en essayant d'annuler un bloc finalisé. Il s'agit également d'une infraction passible de délestage et qui peut être évitée simplement en utilisant un client minoritaire à la place.

Des bogues équivalents dans un client minoritaire ne seraient jamais finalisés et ne donneraient donc jamais lieu à un vote circulaire, et entraîneraient simplement des pénalités d'inactivité, et non un délestage.

• En savoir plus sur l'importance d'exécuter un client minoritaire.
• En savoir plus sur la prévention du délestage

Les clients individuels peuvent varier légèrement en termes de performances et d'interface utilisateur, car ils sont tous développés par des équipes différentes utilisant des langages de programmation variés. Ceci étant dit, aucun d'entre eux n'est « le meilleur ». Tous les clients de production sont d'excellents logiciels, qui exécutent tous les mêmes fonctions de base pour se synchroniser et interagir avec la blockchain.

Puisque tous les clients de production fournissent 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 actuellement PAS utilisé par une majorité de validateurs sur le réseau. Cela peut sembler paradoxal, mais le fait d'utiliser un client majoritaire ou supermajoritaire vous expose à un risque accru de délestage en cas de bogue dans ce client. Utiliser 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 ont leur importance. Les solutions cloud centralisées, telles qu'Amazon Web Services ou Digital Ocean, offrent la commodité de ne pas avoir à obtenir et à faire fonctionner du matériel, au détriment de la centralisation du réseau.

Plus il y a de clients validateurs fonctionnant sur une seule solution de stockage en cloud centralisée, plus cela devient dangereux pour ces utilisateurs. Tout événement qui mettrait ces fournisseurs hors ligne, qu'il s'agisse d'une attaque, d'une demande réglementaire ou d'une simple panne de courant ou d'Internet, entraînera la mise hors ligne simultanée de tous les clients de validation qui dépendent de ce serveur.

Les pénalités hors ligne sont proportionnelles au nombre de personnes se trouvant hors ligne au même moment. L'utilisation d'un VPS augmente considérablement le risque que les pénalités pour indisponibilité soient plus sévères, et accroît votre risque de fuite quadratique ou de délestage dans le cas où la panne serait suffisamment importante. Pour minimiser vos propres risques et ceux encourus par le réseau, les utilisateurs sont fortement encouragés à se procurer et à exploiter leur propre matériel.

Les retraits de quelque nature que ce soit de la Chaîne Phare (Beacon Chain) exigent que les identifiants de retrait soient définis.

Les nouveaux validateurs définissent cela au moment de la génération et du dépôt des clés. Les validateurs existants qui n'ont pas encore défini cela peuvent mettre à niveau leurs clés pour prendre en charge cette fonctionnalité.

Une fois que les identifiants de retrait sont définis, les paiements de récompense (ETH cumulés par rapport aux 32 initiaux) seront distribués périodiquement à l'adresse de retrait automatiquement.

Pour déverrouiller et recevoir la totalité de votre solde, vous devez également terminer le processus de sortie de votre validateur.