Pourquoi avoir un nœud complet (ou full node) sur Ethereum ?

🍎 Participer au bon fonctionnement du réseau Ethereum.

• Vérifiez par vous-même que toutes les transactions sur le réseau sont valides.

• Ne faites pas confiance, vérifiez.

📡 Diffusez vos transactions via votre propre nœud.

• Supprimez la dépendance envers les tiers et les intermédiaires tels qu'Infura ou Alchemy.

• Augmentez la résistance à la censure grâce à la décentralisation.

Faire tourner un nœud complet a des exigences matérielles très similaires à celles d'un nœud de validation. La seule différence est que les nœuds de validation proposent des blocs.

Si vous suivez l'un des guides de staking en solo et terminez toutes les étapes à l'exception du processus de dépôt (qui nécessite 32 ETH), alors vous avez un nœud complet !

Le staking (ou mise en jeu) nécessite de bloquer 32 ETH pour activer un validateur. Vous serez responsable de stocker des données, de traiter des transactions et d'ajouter de nouveaux blocs à la blockchain. Cela permet de sécuriser Ethereum pour l'ensemble des utilisateurs, tout en vous permettant de gagner des ETH supplémentaires.

💰Collecter des récompenses

Les gains sont attribués en contrepartie d’actions qui aident le réseau à parvenir à un consensus. Vous obtiendrez des récompenses pour l'exécution d'un logiciel qui regroupe correctement les transactions dans de nouveaux blocs et vérifie le travail des autres validateurs, cela permet de faire fonctionner la chaîne de manière sécurisée.

🔒Meilleure sécurité

Le réseau devient plus résistant aux attaques à mesure que davantage d'ETH sont mis en jeu, car il faut alors plus d'ETH pour contrôler la majorité du réseau. Pour devenir une menace, vous devriez détenir la majorité des validateurs, ce qui signifie que vous devriez contrôler la majorité de tous les ETH mis en jeu - c'est beaucoup !

🌿 Développement durable

Les stakers n'ont pas besoin d'ordinateurs gourmands en énergie pour participer à un système de preuve d'enjeu (PoS) - un simple ordinateur personnel ou (à l'avenir) un smartphone suffit. Cela rend progressivement Ethereum plus respectueux de l'environnement.

Comment staker vos ETH

🏡 Staking à domicile

• Impact positif

• Contrôle total

• Récompenses intégrales

• Aucun tiers de confiance

Le staking individuel sur Ethereum représente le summum en matière de staking. Il permet d’obtenir la totalité des récompenses de participation, améliore la décentralisation du réseau et ne nécessite jamais de faire confiance à quelqu'un d'autre avec vos fonds.

Ceux qui envisagent de staker à domicile devraient disposer d'au moins 32 ETH et d'un ordinateur dédié connecté à Internet 24h/24 et 7j/7. Des connaissances techniques peuvent être utiles, mais des outils faciles à utiliser existent désormais pour simplifier ce processus.

☁️ Service de Staking

• Vos 32 ETH

• Votre clé de validation

• Confiance à un opérateur externe

Si vous ne voulez pas ou ne vous sentez pas à l'aise pour gérer la configuration et la maintenance d’un validateur, mais que vous souhaitez tout de même staker vos 32 ETH, les options de service de staking vous permettent de déléguer la partie difficile tout en percevant une partie des récompenses.

Ces options vous guident généralement dans l’activation d'un validateur, le téléchargement de vos clés de validation et le dépôt de vos 32 ETH. Cela permet au service de valider en votre nom.

Cette méthode de staking nécessite un certain niveau de confiance envers le fournisseur. Pour limiter les risques, vous seul conservez les clés pour retirer vos ETH.

🪺 Pool de Staking

• Pas de montant minimum

• Gagner des récompenses

• Simple

• Populaire

Plusieurs solutions de staking mutualisé (ou pool) existent désormais pour aider les utilisateurs qui ne possèdent pas ou ne se sentent pas à l'aise avec le staking de 32 ETH.

Beaucoup de ces options incluent ce qu'on appelle le « staking liquide » qui implique un jeton de liquidité ERC-20 représentant vos ETH misés.

Le staking liquide permet une sortie facile et à tout moment et rend le staking aussi simple qu'un échange de jetons. Cette option permet également aux utilisateurs de conserver la garde de leurs actifs dans leur propre portefeuille Ethereum.

Le staking mutualisé n'est pas natif au réseau Ethereum. Des tiers développent ces solutions, et elles comportent leurs propres risques.

🏢 Plateformes d'échange centralisées

• Impact négatif

• Tiers de confiance

De nombreuses plateformes d'échange centralisées proposent des services de staking si vous n'êtes pas encore à l'aise avec la détention d'ETH dans votre propre portefeuille. Elles peuvent être une solution de secours pour vous permettre de gagner un rendement sur vos ETH avec un minimum de supervision ou d'effort.

Le compromis ici est que les fournisseurs centralisés regroupent de grandes quantités d'ETH pour gérer un grand nombre de validateurs. Cela peut être dangereux pour le réseau et ses utilisateurs, car cela crée une cible centralisée importante et un point de défaillance, rendant le réseau plus vulnérable aux attaques ou aux bugs.

Si vous ne vous sentez pas à l'aise pour gérer vos propres clés, ce n'est pas grave. Ces options sont là pour vous. En attendant, pensez à consulter la page à propos des portefeuilles sur ethereum.org , où vous pourrez commencer à apprendre comment prendre véritablement en main vos fonds. Lorsque vous serez prêt, revenez et améliorez votre méthode de staking en essayant par exemple l'un des services proposés de staking mutualisé avec un jeton.

Comme vous avez pu le remarquer, il existe de nombreuses façons de participer au staking sur Ethereum. Ces solutions visent à une grande diversité d'utilisateurs et sont en fin de compte chacune singulières et différentes en ce qui concerne les risques, les récompenses et la confiance. Certaines sont plus décentralisées, éprouvées et/ou risquées que d'autres. Nous fournissons des informations sur des projets populaires dans ce domaine, mais faites toujours vos propres recherches avant d'envoyer des ETH n'importe où.

Sources ↗

Ne paniquez pas!

Manquer quelques attestations est tout à fait normal et a un coût extrêmement faible. La pénalité pour avoir manqué une attestation est exactement la même que la récompense pour une attestation réussie. Ainsi, avec environ 240 attestations par jour par validateur, en manquer une ou deux représente toujours un taux d'attestation réussi de plus de 99% !

Comprendre les attestations manquées, la faible efficacité et comment améliorer votre configuration

Il y a deux causes possibles pour manquer une attestation ou avoir une faible efficacité avec votre validateur. Certaines causes sont sous votre contrôle en tant qu'opérateur et d'autres causes sont indépendantes de votre volonté.

Même avec une configuration parfaite, vous pourriez manquer certaines attestations ou voter incorrectement lors d'une attestation, réduisant ainsi votre efficacité de temps en temps. Les causes qui échappent à votre contrôle sont souvent liées à la propagation du réseau ou au fait que certains de vos pairs soient en retard dans l'exécution de leurs propres devoirs.

Pour approfondir et tout savoir sur le devoir d'attestation, la synchronicité, l'efficacité et la propagation sur le réseau, consultez ces excellents articles.

• Comprendre les ratés ↗ par Adrian Sutton

• Explorer ETH2: Inclusion d'Attestation ↗ par Adrian Sutton

• Définir l'Efficacité de l'Attestation ↗ par Jim McDonald

En tant que validateur, vous ne pouvez pas faire grand-chose concernant les éléments qui sont hors de votre contrôle. Ce que vous pouvez faire en revanche, c'est travailler sur les éléments de votre configuration que vous contrôlez afin de maximiser vos récompenses. Même si vous aviez une configuration qui fonctionnait bien avant la fusion, il est possible qu'avec le travail supplémentaire introduit, une partie négligée de votre configuration soit la cause de manques supplémentaires ou d'une efficacité moindre depuis que la fusion a eu lieu. C'est pourquoi vous devriez vérifier à nouveau tous ces éléments.

1. Assurez-vous que vos clients sont à jour. Les mises à jour des clients incluent souvent des optimisations et des améliorations qui vous aideront à accomplir vos tâches à temps.

2. Assurez-vous que votre machine dispose constamment de ressources suffisantes (CPU, RAM, disque, etc.). L'utilisation d'une machine dédiée peut aider. Si vos clients manquent de l'une de ces ressources, cela sera probablement une cause de manques supplémentaires et d'une moindre efficacité.

3. Assurez-vous que votre horloge est correctement synchronisée. Le protocole de la chaîne de balises est très sensible au temps. "chrony" est un bon outil pour améliorer la synchronisation de votre horloge. Sur Ubuntu ou les dérivés de Debian, installer "chrony" est souvent aussi simple que sudo apt install chrony. Sur Windows, vous pouvez suivre ces instructions ↗ pour améliorer la synchronisation de votre horloge.

4. Assurez-vous d'avoir une bonne latence internet, bande passante et qualité. Pour les validateurs au domicile, il n'est pas réaliste de demander une ISP dédiée ou une connexion internet pour votre validateur, mais assurez-vous que vos autres utilisations du réseau n'interfèrent pas trop avec votre validateur. En cas de doute, voyez si vous pouvez obtenir un meilleur forfait dela part votre fournisseur ou vérifiez s'il y a un fournisseur alternatif dans votre région qui pourrait améliorer votre connexion internet.

5. Assurez-vous d'avoir constamment suffisamment de pairs. Surveiller le nombre de pairs de vos clients n'est pas une mauvaise idée si vous avez la capacité technique.

6. Assurez-vous d'avoir correctement configuré des ports ouverts permettant les connexions entrantes. Cela peut non seulement améliorer la santé du réseau de votre configuration et le nombre de vos pairs, mais cela améliorera également la santé globale du réseau Ethereum. Pour tester si vos ports sont ouverts, vous pouvez utiliser le vérificateur de ports ouverts de StakeHouse. L'appel à curl https://eth2-client-port-checker.vercel.app/api/checker?ports=30303,9000 devrait renvoyer un résultat qui inclut 30303 et 9000 dans le champ open_ports si ces ports sont ouverts depuis Internet. 30303 est le port P2P par défaut pour Geth et 9000 est le port P2P par défaut pour de nombreux clients de consensus. Ajustez ces valeurs si vous utilisez des ports personnalisés ou si vous utilisez des clients ayant des ports par défaut différents. Consultez la documentation de votre client pour en savoir plus à ce sujet.

Une fois que vous avez mis en place tous ces éléments, il y a pas grand chose que vous puissiez faire de plus pour aider. Il pourrait y avoir quelques avantages marginaux à se connecter avec plus de pairs au coût d'une utilisation accrue des ressources, en particulier la bande passante. Dans des circonstances normales, le nombre de pairs par défaut de vos clients devrait être suffisant. La surveillance de la qualité d'internet avec des outils comme ceux de pingman ↗ peut aider à identifier la cause de certaines de ces attestations manquées si elles sont liées au réseau, mais cela restera probablement hors de votre contrôle.

Source ↗

TODO

Welcome to the EthStaker Knowledge base!

An unbiased, open-source collection of useful information and concepts about Ethereum staking. If you're looking to get started staking on Ethereum or simply to learn more about how the network is secured through Proof of Stake (PoS) validators, you've come to the right place!

🔗 Useful Links

• Staking glossary

• Staking FAQ

🚀 Getting started

• What is Ethereum staking?

• Running a node without any ETH

• Deposit process explained

🚨 AIDE !

• My validator is offline! What do I do?

• Missed attestations! What can I do?

• I'm worried about downtime 😔

• I'm worried about slashing 🔪

💰 Rewards

• How does my validator earn ETH?

• Block proposal frequency

💻 Hardware

• Hardware requirements

• Hardware examples

⛓️ Validator Clients

• Validator clients explained

• Execution clients

• Consensus clients

• Checkpoint sync

• Validator effectiveness

• MEV boost

Can I contribute to the EthStaker knowledge base?

Yes! This is a living documentation site, meaning we need the community's help to maintain and update the content. Any contribution, from writing whole sections and translations to correcting spelling and grammar mistakes will be greatly appreciated.

You can earn GitPOAPs by contributing directly to the EthStaker Knowledge Base (a contributor↗) and by asking a question that leads to content being created (a supporter↗).

To suggest changes or add new content please visit our EthStaker Github↗ or if you have any questions please join our Discord↗.

✏️ Get Involved

• How to contribute

Supported by a GitBook Community License ♥️

Récompenses de staking

Les paiements des récompenses sont automatiquement traités pour les comptes de validateurs actifs qui ont un solde effectif supérieur à 32 ETH.

Tout solde au-delà de 32 ETH gagné grâce aux récompenses ne contribue pas réellement au processus de validation, ni n'augmente le poids de ce validateur sur le réseau. Ce surplus est donc automatiquement retiré en tant que paiement de récompense tous les deux ou trois jours. Hormis fournir une adresse de retrait, ces récompenses ne nécessitent aucune action de la part de l'opérateur du validateur. Tout cela est initié sur la couche de consensus, aucun frais de transaction (gas) n'est donc requis à aucune étape.

Retrait complet du staking

Fournir une adresse de retrait est nécessaire avant que des fonds puissent être transférés hors du validateur.

Les utilisateurs souhaitant arrêter complètement le staking et retirer la totalité de leur solde doivent également signer et diffuser un message de "sortie volontaire" avec les clés du validateur. Cela déclenchera le processus de sortie du staking. Ceci est effectué avec votre client de validation puis est soumis à votre nœud sur la Beaconchain, et ne nécessite pas de gas.

Le processus de sortie d'un validateur prend un temps variable, en fonction du nombre de validateurs quittant en même temps. Une fois terminé, ce validateur ne sera plus responsable de l'exécution des tâches du réseau, ne sera plus éligible aux récompenses et n'aura plus d'ETH "en jeu". À ce moment-là, le compte sera marqué comme étant entièrement "sortie".

Une fois qu'un compte est signalé comme "sortie" et que les informations d'identification de retrait ont été fournies, il n'y a plus rien à faire pour l'utilisateur, si ce n'est attendre. Les comptes sont automatiquement et continuellement balayés par les proposeurs de sortis éligibles, et le solde de votre compte sera transféré en totalité (également appelé "retrait complet") lors du prochain balayage.

Comment fonctionnent les paiements de retrait et des récompenses ?

Qu'un validateur donné soit éligible à un retrait ou non est déterminé par l'état de son compte. Aucune intervention de l'utilisateur n'est nécessaire à aucun moment pour déterminer si un compte doit ou non initier un retrait - l'ensemble du processus est effectué en boucle automatiquement par la couche de consensus.

Balayage des validateurs

Lorsqu'un validateur est programmé pour proposer le prochain bloc, il doit constituer une file d'attente de retrait, comprenant jusqu'à 16 retraits éligibles. Cela commence à partir de l'indice de validateur 0, en déterminant s'il y a un retrait éligible pour ce compte selon les règles du protocole, et en l'ajoutant à la file d'attente s'il y en a un. Le validateur qui doit proposer le bloc suivant reprendra là où le dernier s'est arrêté, progressant dans l'ordre indéfiniment.

Eligibilité d'un compte pour les retraits

Lorsqu'un proposeur de bloc balaie les validateurs pour d'éventuels retraits, chaque validateur vérifié est évalué en fonction d'une courte série de questions pour déterminer si un retrait doit être déclenché et, le cas échéant, combien d'ETH doivent être retirés.

1. Une adresse de retrait a-t-elle été fournie ? Si aucune adresse de retrait n'a été fournie, le compte est ignoré et aucun retrait n'est initié.

2. Le validateur est-il sorti et peut-il être retiré ? Si le validateur est complètement sorti et que nous avons atteint l'époch où son compte est considéré comme " pouvant être retiré ", alors un retrait complet sera effectué. Cela transférera le solde total à l'adresse de retrait.

3. Le solde effectif est-il supérieur à 32 ? Si le compte dispose d'identifiants de retrait, n'est pas déjà sorti et a un solde supérieur à 32 en attente, un retrait partiel sera effectué, transférant uniquement les récompenses supérieures à 32 à l'adresse de retrait de l'utilisateur.

Seules deux actions sont à entreprendre par les opérateurs de validateurs au cours du cycle de vie d'un validateur :

• Fournir un justificatif de retrait pour permettre toute forme de retrait

• Sortir du réseau, ce qui déclenchera un retrait complet

Sans aucun frais

Cette approche des retraits de staking évite d'exiger que les stakers soumettent manuellement une transaction demandant un montant particulier d'ETH à retirer. Cela signifie également qu'aucun frais de transaction (gas) n'est requis, et que les retraits ne sont donc pas en concurrence pour l'espace de bloc disponible sur la couche d'exécution.

À quelle fréquence recevrai-je mes récompenses de staking ?

Un maximum de 16 retraits peut être traité dans un seul bloc. À ce rythme, 115 200 retraits de validateurs peuvent être traités par jour (en supposant qu'il n'y ait pas de créneaux manqués). Comme indiqué ci-dessus, les validateurs sans retraits éligibles seront ignorés, ce qui réduit le temps nécessaire pour terminer le balayage.

En développant ce calcul, nous pouvons estimer le temps qu'il faudra pour traiter un certain nombre de retraits :

Comme vous pouvez le voir, le délai s’allonge à mesure que davantage de validateurs sont présents sur le réseau. Une augmentation des blocs manqués pourrait aussi ralentir cela proportionnellement, mais cette estimation représentera généralement l'estimation la plus lente possible.

• Archival node

• Attestation

• Attestation aggregator

• Beacon chain

• Block

• Block proposer

• Block status

  • Proposed

  • Scheduled

  • Missed/skipped

  • Orphaned

• Canonical chain

• Chain head

• Checkpoints

• Client

• Committees

• Consensus layer

• Deposit contract

• Effectiveness

• Epoch

• Execution layer

• Finalization

  • Finality issues

• Fork

• Full node

• Genesis block

• Hard fork

• Head vote

• Inactivity leak

• Inclusion distance

• Input data

• Justification

• Light clients

• MEV

• Mempool

• Node

• Operator

• Participation rate

• Peers

• Priority fees

• Private key

• Proof of stake (PoS)

• Public key

• Signing

• Slashable offenses

  • Attestation violation

  • Proposer violation

• Slasher node

• Slot

• Solo staker

• Source vote

• Staker

• Staking deposit CLI

• Suggested fee recipient

• Sync committee

• Target vote

• Validator

  • Eligible for activation & Estimated activation

  • Unique index

  • Current balance & Effective balance

• Validator lifecycle

  • 1. Deposited

  • 2. Pending

  • 3. Active validator

  • 4. Slashing validator

  • 5. Exiting validator

• Validator pool

• Validator queue

• Validator seed phrase / mnemonic

• Withdrawal address

Archival node

• Stores everything kept in a full node and builds an archive of historical states.

• Archive nodes are required if you want to query something like an account balance at a particular block.

• This data represents units of terabytes (more than 20TB for Geth), which makes archive nodes less attractive for most users but can be handy for services like block explorers, wallet vendors, and chain analytics.

Syncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical states but the full node is able to build them on demand.

Archive nodes aren't required to participate in block validation and can theoretically be built from scratch by simply replaying the blocks from genesis.

Source ↗

Attestation

Votes by validators which confirm the validity of a block. At designated times, each validator is responsible for publishing different attestations that formally declare a validator's current view of the chain, including the last finalized checkpoint and the current head of the chain.

Every active validator creates one attestation per epoch (~6.5 minutes), consisting of the following components:

An important component related to effectiveness is the chain head vote. This is a vote the validator makes about what it believes is the latest valid block in the chain at the time of attesting. The structure of a chain head vote consists of the following components:

• Slot - Defines where the validator believes the current chain head to be.

• Hash - Defines what the validator believes the current chain head to be to be.

The combination uniquely defines a point on the blockchain. By combining enough of these chain head votes the Ethereum network reaches consensus about the state of the chain.

Source (ethereum.org) ↗ Source (Attestant) ↗

Attestation aggregator

Although the data in each attestation is relatively small, it mounts up quickly with tens of thousands of validators. As this data will be stored forever on the blockchain, minimizing it is important, and this is done through a process known as attestation aggregation.

Aggregation takes multiple attestations that have all chosen to vote with the same committee, chain head vote, and finality vote, and merges them together into a single aggregate attestation.

An aggregate attestation differs in two ways from a simple attestation. First, there are multiple validators listed. Second, the signature is an aggregate signature made from the signatures of the matching simple attestations. Aggregate attestations are very efficient to store, but introduce additional communications and computational burdens.

If every validator was required to aggregate all attestations it would quickly overload the network with the number of communications required to pass every attestation to every validator. Equally, if aggregating were purely optional then validators will not bother to waste their own resources doing so. Instead, a subset of validators is chosen by the network to carry out aggregation duties1. It is in their interest to do a good job, as aggregate attestations with higher numbers of validators are more likely to be included in the blockchain so the validator is more likely to be rewarded.

Validators that carry out this aggregation process are known as aggregators.

Source ↗

Beacon chain

A major part of the work of the beacon chain is storing and managing the registry of validators – the set of participants are responsible for running the Ethereum Proof of Stake (PoS) system.

This registry is used to:

• Assigns validators their duties.

• Finalizes checkpoints.

• Perform a protocol level random number generation (RNG).

• Progress the beacon chain.

• Vote on the head of the chain for the fork choice.

Source ↗

Block

A block is a bundled unit of information that include an ordered list of transactions and consensus-related information. Blocks are proposed by Proof of Stake (PoS) validators, at which point they are shared across the entire peer-to-peer network, where they can easily be independently verified by all other nodes. Consensus rules govern what contents of a block are considered valid, and any invalid blocks are disregarded by the network. The ordering of these blocks and the transactions therein create a deterministic chain of events with the end representing the current state of the network.

Block proposer

A chosen validator by the Beacon Chain to propose the next block. There can only be one valid block per slot.

Block status

Proposed

The block was proposed by a validator.

Scheduled

Validators are currently submitting data.

Missed/skipped

The proposer didn’t propose the block within the given time frame, so the block was missed/skipped.

Orphaned

In order to understand this, let us look at the diagram below "1, 2, 3, ... ,9" represent the slots.

1. Validator at slot 1 proposes the block “a”.

2. Validator at slot 2 proposes “b”.

3. Slot 4 is being skipped because the validator didn’t propose a block (e.g.: offline).

4. At slot 5/6 a fork occurs: Validator(5) proposes a block, but validator(6) doesn’t receive this data (e.g.: the block didn’t reach them fast enough). Therefore Validator(6) proposes its block with the most recent information it sees from validator(3).

5. The fork choice rule ↗ is the key here - It decides which of the available chains is the canonical one.

Canonical chain

The canonical chain is the chain which is agreed to be the 'main' chain and not a fork.

Chain head

The latest block received by a validator. This does not necessarily mean it is the head of the canonical chain.

Checkpoints

The Beacon Chain has a tempo divided into slots (12 seconds) and epochs (32 slots). The first slot in each epoch is a checkpoint. When a supermajority of validators attests to the link between two checkpoints, they can be justified and then when another checkpoint is justified on top, they can be finalized.

Client

An implementation of Ethereum software that verifies transactions in a block. These can be consensus layer clients or execution layer clients. Each validator needs both an execution layer client and a consensus layer client.

Committees

A group of at least 128 validators is assigned to validate blocks in each slot. One of the validators in the committee is the aggregator, responsible for aggregating the signatures of all other validators in the committee that agree on an attestation. Not to be confused with sync committees.

Consensus layer

Ethereum's consensus layer is the network of consensus clients.

Deposit contract

The Deposit contract is the gateway to Ethereum Proof of Stake (PoS) and is managed through a smart contract on Ethereum. The smart contract accepts any transaction with a minimum amount of 1 ETH and valid input data. Ethereum beacon nodes listen to the deposit contract and use the input data to credit each validator.

More info on the deposit contract

Effectiveness

The average time it takes for a validator's attestations to be included in the chain.

Check out our page explaining validator effectiveness in more detail

Epoch

1 Epoch = 32 Slots Represents the number of 32 slots (12 seconds) and takes approximately 6.4 minutes. Epochs play an important role when it comes to the validator queue and finality.

Execution layer

Ethereum's execution layer is the network of execution clients.

Finalization

one-thirdIn Ethereum Proof of Stake (PoS) at least two third of the validators have to be honest, therefore if there are two competing epochs and one third of the validators decide to be malicious, they will receive a penalty. Honest validators will be rewarded.

In order to determine if an epoch has been finalized, validators have to agree on the latest two epochs in a row, then all previous Epochs can be considered as finalized.

Finality issues

If there are less than 66.6% of the total possible votes (the participation rate) in a specific epoch, the epoch cannot be justified. As mentioned in "Finalization", three justified epochs in a row are required to reach finality. As long as the chain cannot reach this state it has finality issues.

During finality issues, the validator entry queue will be halted and new validators will not be able to join the network, however, inactive validators with less than 16 ETH balance will be exited from the network. This leads to more stability in the network and a higher participation rate, allowing the chain to eventually finalize.

Fork

A change in protocol causing the creation of an alternative chain or a temporal divergence into two potential block paths. Also see hard fork

Full node

Stores and maintains the full blockchain data on disk. It serves blockchain data upon request and helps support the network by participating in block validation and by verifying all blocks and states. All states can be derived from a Full node.

Source ↗

Genesis block

The first block in a blockchain, used to initialize a particular network and its cryptocurrency.

Hard fork

A hard fork occurs when an update is being pushed to the Ethereum network and the new version of the software forks from the old version. Usually requires operators to update their validator software to stay on the correct side of the fork. Also see fork

Head vote

The validator has made a timely vote for the correct head block.

Inactivity leak

If the Beacon Chain has gone more than four epochs without finalizing, an emergency protocol called the "inactivity leak" is activated. The ultimate aim of the inactivity leak is to create the conditions required for the chain to recover finality. Finality requires a 2/3 majority of the total staked ether to agree on source and target checkpoints. If validators representing more than 1/3 of the total validators go offline or fail to submit correct attestations then it is not possible for a 2/3 supermajority to finalize checkpoints. The inactivity leak lets the stake belonging to the inactive validators gradually bleed away until they control less than 1/3 of the total stake, allowing the remaining active validators finalize the chain. However large the pool of inactive validators, the remaining active validators will eventually control >2/3 of the stake. The loss of stake is a strong incentive for inactive validators to reactivate as soon as possible!

Inclusion distance

The inclusion distance of a slot is the difference between the slot in which an attestation is made and the lowest slot number of the block in which the attestation is included. For example, an attestation made in slot s and included in the block at slot s + 1 has an inclusion distance of 1. If instead the attestation was included in the block at slot s + 5 the inclusion distance would be 5.

The value of an attestation to the Ethereum network is dependent on its inclusion distance, with a low inclusion distance being preferable. This is because the sooner the information is presented to the network, the more useful it is.

To reflect the relative value of an attestation, the reward given to a validator for attesting is scaled according to the inclusion distance. Specifically, the reward is multiplied by 1/d, where d is the inclusion distance.

Input data

The Input data, also called the deposit data, is a user generated, 842 long sequence of characters. It represents the validator public key and the withdrawal public key, which were signed with by the validator private key. The input data needs to be added to the transaction to the deposit contract in order to get identified by the beacon-chain.

More info about the deposit process

Justification

66.6% of the total validators need to attest in favour of a block's inclusion in the canonical chain. This condition upgrades the block to "justified". Justified blocks are unlikely to be reverted, but they can be under certain conditions.

When another block is justified on top of a justified block, it is upgraded to "finalized". Finalizing a block is a commitment to include the block in the canonical chain.

More info on justification ↗

Light clients

An Ethereum client that does not store a local copy of the blockchain, or validate blocks and transactions. It offers the functions of a wallet and can create and broadcast transactions.

MEV

MEV or "maximal extractable value", is a controversial topic. Node operators can extract MEV by accepting blocks built by "searchers", via a small side program called "mev-boost ↗" by Flashbots. In this case, the Consensus Layer client such as Nimbus, Teku, etc. will, when asked to procure a block to propose, get blocks from MEV relays via mev-boost and from the Execution Layer client such as Besu, Geth, etc. and then choose whichever block from the relay pays best. The Execution Layer does not currently communicate its expected payout and would only be chosen when the relay offers no block. For this, the relay has to be trusted to deliver valid blocks.

Rewards from MEV are paid to the same suggested fee recipient address as priority fees.

Source ↗

Mempool

When an Ethereum node receives a transaction, it is not instantly added to a block. The transaction is held in a waiting area or a buffer zone.

The transaction goes from a number of levels of verification such as it checks whether the output is greater than the input, whether the signature is valid or not, etc., and then only it is added to a block. The transaction is not added to a block if it fails any of these validations. The role of a mempool comes while a transaction is going through these checks. It is simply kept in this waiting area or a mempool. As soon as the transaction confirms, it is removed from the mempool and added to a block. Mempool is not a master reference shared universally by all nodes. There’s no “one” mempool. This means each node configures its own rules for the node’s mempool. In fact, a node can be the first to receive a transaction but it is possible that it might not have propagated the transaction to the rest of the network.

Source ↗

Node

Any instance of Ethereum client software that is connected to other computers also running Ethereum software, forming a network. A node doesn’t necessarily need a validator but a validator requires a node. Running a node by itself does not generate any revenue but does contribute to the robustness of the network.

Operator

A person who maintains a validator

Participation rate

The participation rate is the percentage of validators that are online and performing their duties.

If the validator set is 1,000 validators, and 250 validators are offline or rarely making proposals or attestations, then it could be estimated that the participation rate is 75%.

Source ↗

Peers

Other nodes running Ethereum clients that connect to each other over a peer-to-peer network. Communication between peers is how the Ethereum network remains decentralized as there is no single point of failure.

Priority fees

Almost all transaction on Ethereum set a priority fee ↗ to incentivize block proposers to include the transaction as a higher priority than others. The higher the fee relative to other transactions currently waiting in the mempool This fee is paid to the block proposer. All of the priority fees in a block are aggregated and paid in a single state change directly to the suggested fee recipient set by the block proposer. This address could be a hardware wallet, a software wallet, or even a multi-sig contract.

Private key

A secret number that allows Ethereum users to prove ownership of an account or contracts, by producing a digital signature.

Proof of stake (PoS)

A method by which a cryptocurrency blockchain protocol aims to achieve distributed consensus. PoS asks users to prove ownership of a certain amount of cryptocurrency (their "stake" in the network) in order to be able to participate in the validation of transactions.

Public key

A number, derived via a one-way function from a private key, which can be shared publicly and used by anyone to verify a digital signature made with the corresponding private key.

Signing

Demonstrating cryptographically that a message or transaction was approved by the holder of a specific private key).

Slashable offenses

If your validator commits a slashable offense it will be force exited from the validator pool and will have ETH deducted depending on the circumstances of the event. Typically, this will be 1-2 ETH but could be significantly more ↗.

This is not something to be overly worried about, there are simple steps you can take to make sure that you don't invoke a slashing event.

There are three ways a validator can be slashed, all of which amount to the dishonest proposal or attestation of blocks.

Attestation violation

• Double voting: Signing two different attestations in one epoch.

• Surround votes: Attesting to a block that "surrounds" another one (effectively changing history).

Proposer violation

• Double block proposal: Proposing and signing two different blocks for the same slot.

Slasher node

The slasher is its own entity but requires a beacon-node to receive attestations. To find malicious activity by validators, the slashers iterate through all received attestations until a slashable offense has been found. Found slashings are broadcasted to the network and the next block proposer adds the proof to the block. The block proposer receives a reward for slashing the malicious validator. However, the whistleblower (Slasher) does not receive a reward.

Slot

32 Slots = 1 Epoch A time period of 12 seconds in which a randomly chosen validator has time to propose a block. The total number of validators is split up in committees and one or more individual committees are responsible to attest to each slot. One validator from the committee will be chosen to be the aggregator, while the other 127 validators are attesting. After each Epoch, the validators are mixed and merged to new committees. Each slot may or may not have a block in it as a validatory could miss their proposal (e.g. they may be offline or submit their block too late). There is a minimum of 128 validators per committee.

Solo staker

An operator who runs a validator on the Ethereum network without a protocol between their validator and the Beaconchain

Source vote

The validator has made a timely vote for the correct source checkpoint.

Staker

Someone who has deposited ETH into a validator to secure the network. This can be someone who runs a validator (an operator) or someone who deposited their ETH into a pool, where someone else is the operator of the validator.

Staking deposit CLI

A command-line tool used to generate validator keys and deposit data files.

• https://github.com/ethereum/staking-deposit-cli

Suggested fee recipient

The fee recipient is an Ethereum address nominated by a Beacon Chain validator to receive tips from user transactions and MEV.

Sync committee

A sync committee is a randomly selected group of validators that refresh every ~27 hours. Their purpose is to add their signatures to valid block headers. Sync committees allow light clients to keep track of the head of the blockchain without needing to access the entire validator set. Occurs every 2 years on average, however, there can be "dry spells" multiple times longer than the average without being given one. So if your validator is selected... congratulations! 🥳

Target vote

The validator has made a timely vote for the correct target checkpoint.

Validator

A node in a Proof of Stake (Pos) system responsible for storing data, processing transactions, and adding new blocks to the blockchain. To activate validator software, you need to be able to stake 32 ETH. A validator's job is to propose blocks and sign attestations. It has to be online for at least 50% of the time in order to have positive returns. A validator is run by an operator (a human), on hardware (a computer) and is paired with a node (many thousand validators can run on one node).

Eligible for activation & Estimated activation

Refers to pending validators. The deposit has been recognized by the Beacon Chain at the timestamp of “Eligible for activation”. If there is a queue of pending validators ↗, an estimated timestamp for activation is calculated.

Unique index

Every validator receives a unique index based on when they are added from the validator queue.

Current balance & Effective balance

The current balance is the amount of ETH held by the validator as of now. The effective Balance represents a value calculated by the current balance. It is used to determine the size of a reward or penalty a validator receives. The effective balance can never be higher than 32 ETH.

In order to increase the effective balance, the validator requires “effective balance + 1.25 ETH”. In other words, if the effective balance is 20 ETH, a current balance of 21.25 ETH is required in order to have an effective balance of 21 ETH. The effective balance will adjust once it drops by 0.25 below the threshold as seen in the examples above.

Here are examples of how the effective balance changes:

• If the Current balance is 32.00 ETH – the Effective balance is 32.00 ETH.

• If the Current balance dropped from 22 ETH to 21.76 ETH – Effective balance will be 22.00 ETH.

• If the Current balance increases to 22.25 and the effective balance is 21 ETH, the effective balance will increase to 22 ETH.

Validator lifecycle

1. Deposited

32 ETH has been deposited to the ETH1 deposit-contract and this state will be kept for around 7 hours. This offers security in case the Ethereum chain gets attacked.

2. Pending

Waiting for activation on the Beacon Chain.

Before validators enter the validator queue, they need to be voted in by other active validators. This occurs every 4 hours.

3. Active validator

Currently attesting and proposing blocks.

The validator will stay active until:

• Its balance drops below 16 ETH (ejected).

• Voluntary exit.

• It gets slashed.

4. Slashing validator

The Validator has been malicious and will be slashed and kicked out of the system.

A Penalty is a negative reward (e.g. for going offline). A Slashing is a large penalty (≥ 1/32 of balance at stake) and a forceful exit ... . - Justin Drake

5. Exiting validator

• Ejected: The validator balance fell below a threshold and was kicked out by the network.

• Exited: Voluntary exit, the withdrawal key holder has the ability to withdraw the current balance of the corresponding validator balance.

Validator pool

The number of currently active validators securing the Ethereum network. The current validator pool can be seen here ↗.

Validator queue

The validator queue is a first-in-first-out queue for activating and exiting validators on the Beacon Chain.

• Until 327680 active validators in the network, 4 validators can be activated per epoch. For every (4 * 16384) = 65536 active validators, the validator activation rate goes up by one.

• 5 validators per epoch requires 327680 active validators, allowing 1125 validators per day.

• 6 validators per epoch requires 393216 active validators, allowing 1350 validators per day.

• 7 validators per epoch requires 458752 active validators, allowing 1575 validators per day.

• 8 validators per epoch requires 524288 active validators, allowing 1800 validators per day.

• 9 validators per epoch requires 589824 active validators, allowing 2025 validators per day.

• 10 validators per epoch requires 655360 active validators, allowing 2200 validators per day.

• Amount of activations scales with the amount of active validators and the limit is the active validator set divided by 64.

Exiting validators works in the same way, with the amount of validators that can exit the Beacon Chain per day rate limited to preserve the stability of the network.

Validator seed phrase / mnemonic

The Seed Phrase or Mnemonic is a set of words (usually 12, 18 or 24 words long) used to generate your validator keys. Your mnemonic is the backup for your validator keys and will be the ONLY way to withdraw your ETH when the time comes and no one can help you recover your mnemonic if you lose it.

Withdrawal address

An address that can be optionally set when creating a validator key that will be used to withdraw staked ETH. If this address is not set at the time of key creation it can be set at the time of withdrawal instead. For more information about setting the withdrawal address on key creation, see our FAQ answer.

The importance of using a UPS

It is strongly recommended that you connect your node/validator to a UPS. Doing so will ensure that it does not abruptly switch off should there be a sudden loss of power.

There are many potential issues that an abrupt shutdown can cause, such as:

• Database corruption

  • This will require you to (depending on the severity of the corruption) delete the stored DB and resync it from scratch. Depending on the speed of your SSD, this could put you offline for a while.

• OS corruption

  • This will require an OS reinstallation. You will then need to reconfigure the machine, install an execution and consensus client, set up your validators, then get both clients in sync.

• Hardware failure

  • If your hard drive fails, you will need to source and install a new one, then complete the above steps (Install an OS and sync the clients).

If a power outage doesn't damage any physical components, you might still be unsafe. When power is restored you could experience a power surge that could overload and fry components, meaning more downtime while you investigate which components are damaged and then have them replaced.

Depending on the UPS model and the OS you are using, you can configure your UPS to gracefully shutdown the connected computer(s) once the battery level falls below a certain point. Incredibly powerful in protecting your data and computer.

My UPS (1600VA/960W) cost me roughly $200 USD and provides around an hour of power to all the connected devices. I have both my node and router connected, so in the event that there is a power outage, the node will still be online working away. I've had a few short power outages since becoming a validator so it has definitely come in handy!

Configuring auto start

If things switch off while you are sleeping or not at home, the below steps are very useful in having things start back up automatically.

Computer set to switch on automatically after loss of power

In your BIOS there will most likely be a power setting, in there you should be able to find an option to have your computer switch back on once power is restored.

If you cannot find the setting, you may need to check your motherboards user guide.

NOTE - To enter your BIOS, you will need to press a specific button after switching on the machine (and before the OS loads). The most common keys are "DEL", "F1", "F2", "F10".

This does vary between motherboards, and if you are unsure what yours is, check your POST information once the PC starts as it may show it on the screen. Or you can check your motherboards user guide. Or you can do what I do, which is to spread your hands out on the keyboard and press the before mentioned keys all at once and hope one of them works.

If running a VM, setting servers to start

If you are using a hypervisor to host your nodes/validators, then you should set the VM's to automatically switch on once the computer has booted. It also saves you from manually starting them up should you manually restart the host computer.

Using services and configuring auto start

It is common practice to configure your execution node, consensus node and consensus validators as services and set them to automatically start once the OS has booted. This can be done with systemd.

Doing the above three steps will help to minimise downtime.

Very loud fan on a NUC

If you are using a NUC, you may notice that the fan is quite loud and can be uncomfortable on the ears. This is due to a setting called turbo boost which is enabled by default.

Now, this isn't a best practice, so please don't take it as such. Instead, this should be viewed as a quality-of-life option if your NUC fan is very loud and is disturbing the peace.

Une fois que vous avez configuré votre machine avec un client d'exécution et un client de consensus, vous êtes prêt à commencer le processus de dépôt.

Les dépôts de staking sont traités via la plateforme de lancement ethereum.org :

https://launchpad.ethereum.org/fr/overview

Les captures d'écran suivantes montrent le processus de dépôt.

Choisir un client d'exécution

Choisir un client de consensus

Générer votre paire de clés

Définir une adresse de retrait pour vos récompenses ou en cas de sortie du validateur

Quel est votre système d'exploitation actuel ?

Comment voulez-vous générer vos clés ?

Enregistrer le fichier pour le validateur

Enregistrer le fichier pour le dépôt des 32 ETH

Déposer le fichier json

Connecter votre portefeuille puis faite le dépôt

Félicitations ! Vous avez enclenché le processus pour activer votre validateur.

Ne paniquez pas !

La pénalité pour avoir manqué des attestations est exactement la même que la récompense pour une attestation réussie. Toute pénalité due à une indisponibilité sera récupérée en autant de temps.

. Selon le nombre total de , un validateur proposera en moyenne un bloc seulement tous les quelques mois. Si vous avez la malchance d'être hors ligne au moment où votre validateur est sollicité pour proposer un bloc, ce n'est pas grave non plus.

Le réseau Ethereum est robuste et conçu pour gérer ces situations. Si vous manquez votre proposition de bloc, qui aurait dû contenir votre bloc sera vide. Outre les perdues pour avoir manqué la proposition de bloc, il n'y a pas de pénalités ou de sanctions résultant d'une proposition de bloc manquée.

Les systèmes de basculement et de sauvegarde automatisés peuvent sembler être une bonne idée, mais ils sont beaucoup plus susceptibles de provoquer une sanction (par exemple, une double proposition) qu'un processus de récupération manuel. Manquer quelques jours de récompenses peut sembler mauvais sur le moment, mais être pénalisé et potentiellement manquer des MOIS de récompenses est bien pire !

Geth renvoie des erreurs et ne se synchronise pas.

C'est aléatoire

La fréquence à laquelle un validateur reçoit des propositions de blocs et est sélectionné pour faire partie d'un , est entièrement aléatoire. Tant que vous ne constatez pas de propositions manquées, il n'y a absolument rien que vous puissiez faire pour augmenter la fréquence.

La vraie aléatoire peut sembler assez étrange. Un validateur qui ne reçoit pas de proposition pendant 9 mois est parfaitement normal. Un validateur qui obtient deux propositions en une semaine est également tout à fait normal. Sur un ensemble assez grand, cela s'équilibre, mais pour un petit nombre de validateurs, l'aléatoire peut effectivement sembler déstabilisant.

Pour voir les dernières statistiques sur la fréquence des propositions de blocs, jetez un œil à .

L'outil par peut être utilisé pour connaître la fréquence moyenne actuelle des propositions et des comités de synchronisation. Fin 2022, c'est à peu près une proposition tous les 2 mois et une participation au comité de synchronisation tous les 2,5 ans.

N'y a-t-il vraiment rien que je puisse faire ?!?

Nous aimons plaisanter en disant que brûler quelques peut augmenter vos chances. Mais non, sérieusement, c'est aléatoire. Il n'y a rien que vous puissiez faire pour augmenter vos chances de propositions, à part faire fonctionner plus de validateurs.

Les validateurs, qui participent à la sécurisation de la et exécutent des "tâches", sont récompensés par la nouvelle émission d'ETH. De plus, les validateurs reçoivent des frais de priorité payés par les utilisateurs, et éventuellement de la . Les validateurs sont récompensés pour l'exécution de ces tâches par une nouvelle émission d'ETH sur le "solde du validateur". Le rendement annuel actuel peut être consulté sur la plateforme de .

*Varie en fonction du nombre total de validateurs dans le réseau. Estimation approximative pour 435 000 validateurs actifs.

**Cela est soumis à l'aléatoire ; il peut y avoir des "périodes creuses" sans en recevoir une beaucoup plus longues que la moyenne.

Les récompenses reçues sur la couche de ne sont actuellement pas liquides. Elles sont bloquées sur la chaîne jusqu'à ce que les soient implémentés. Les récompenses fournies sur la couche d', cependant, sont liquides et peuvent être accédées instantanément.

Pénalités pour les validateurs

Si le validateur est hors ligne et n'exécute pas ses devoirs, il sera pénalisé à un taux légèrement inférieur aux récompenses pour la même période de temps.

Les validateurs sont pénalisés pour de petites quantités d'ETH s'ils sont hors ligne et ne parviennent pas à exécuter leurs devoirs assignés. Cela est appelé la . Si un validateur viole l'une des règles fondamentales de la chaîne Balise et semble attaquer le réseau, il peut être . L'exclusion est une sortie forcée de votre validateur sans votre permission, accompagnée d'une amende relativement importante qui retire une partie du solde en ETH de votre validateur.

En réalité, la seule condition qui peut entraîner une exclusion est si vous faites fonctionner les clés de votre validateur sur deux nœuds en même temps (comme dans une configuration de secours / redondance, où votre nœud de sauvegarde se met en marche accidentellement alors que votre nœud principal est encore en fonctionnement). Ne laissez pas cela arriver, et vous ne serez pas exclu. L'exclusion ne peut pas se produire en étant hors ligne pour maintenance.

Ci-dessous se trouve un tableau qui montre les pénalités qui peuvent arriver à un validateur :

*Varie en fonction du nombre total de validateurs dans le réseau. Estimation approximative pour 435 000 validateurs actifs.

Can I be slashed for being offline?

Can I stop running my validator for a few days and then start it back up again?

Can I withdraw my ETH at any time?

Does my validator need to be online to withdraw my ETH?

How are validators incentivized to stay active and honest?

The key concept is the following:

• Rewards are given for actions that help the network reach consensus.

• Minor penalties are given for inadvertent actions (or inactions) that hinder consensus.

In other words, you maximize your rewards by providing the greatest benefit to the network as a whole.

How important are disk IOPS?

Disk IOPS are very important if you want your node to operate to its true potential.

Low disk IOPS can cause many different issues such as missed attestations, missed block proposals, failure to get in sync with the network as well as failure to keep up with the network if already in sync.

How does MEV Boost min-bid work?

Beacon Nodes pick the highest reward (local or remote) if it is above the min-bid value.

If the highest reward (local or remote) is below the min-bid value then the local block will be selected.

There are circuit breakers in beacon nodes that select a local payload when certain network conditions are met such as there being many missed slots recently.

How long do pre-signed exit messages remain valid?

Pre-signed exit messages only remain valid for two hard forks. After that, you will need to generate new ones.

An exit message signed at any epoch less than the last hard fork is lumped into a "previous version" bucket and given its fork version. That means that if your operation was signed two fork versions ago the verification function has the wrong fork version, hence the wrong domain, hence the wrong signing root, hence the wrong signature, hence it fails to verify.

How much ETH do I need to stake to become a validator?

Each key-pair associated with a validator requires locking 32 ETH to be activated, which represents your initial balance as well as your initial and maximum voting power for any validator.

How should I deal with a compromised or stolen machine?

The best thing to do is to exit your validator as soon as it is practical to do so. Even in the case of an encrypted machine that is physically stolen where you can safely assume the thief won't ever be able to gain access, it is simply not worth the thought or the risk of being slashed at some point in the future.

If your validator keys are ever compromised or you even suspect them of being compromised, exiting the validator and spinning up new ones are the best course of action you can take to protect yourself.

Once your ETH is secured, further investigations and actions can be taken to prevent or mitigate this from occurring again.

I am overwhelmed and don't know where to start - what can I do?

Staking on Ethereum gives you many options to participate. This can be overwhelming - no doubt. We all have been there!

And - You don't have to face problems on your own.

I proposed a block! What did I earn?

Is the deposit/source address shown anywhere?

Is there a penalty for missing a block proposal?

Is there a penalty for missing an attestation?

Is there any advantage to having more than 32 ETH at stake?

No. There is no advantage to having more than 32 ETH staked.

Should I set a withdrawal address when setting up my solo staking validator?

And that’s it. Once your validator uses v1 credentials the withdrawal address is fixed and can’t be changed. In the current design, skimming is automatic, and so are full withdrawals: Full withdrawal just happens after exit is completed.

A tool to export the withdrawal key will likely not be created, and it’d also not be very useful. You need the withdrawal key at most twice:

• Once to generate the signing key (only if no withdrawal address was set at that time).

• Once more to sign a message to set one.

In both cases the key can be generated inside the CLI tool, be used for its purpose, and then be discarded again without ever being written to disk.

Taxes!! How can I stay on top of them?

Calculating staking taxes can be both difficult and tiresome but it is an important thing to do. Luckily an amazing tool exists to simplify this process.

This will give you a rundown of the rewards your validators have accrued. Always double check with a local tax agent before filing to ensure they have been calculated in an appropriate manner for the jurisdiction that you are a tax resident of.

What exactly is a validator?

What happens if I lose my validator keys?

What happens if I lose my validator seed phrase / mnemonic?

If you lose your seed phrase, the one used to generate the validator keys, then unfortunately your staked ETH is most likely unrecoverable.

However, if you had set a withdrawal address, then the validator keys are enough to sign a voluntary-exit, which causes a withdrawal to that address. There is also a special case if you have a pre-signed voluntary-exit message, but that's likely only used by staking services and only noted here for completeness.

What if I want to stop staking?

What is a node operator?

A node operator is the human being who makes sure the client software is running appropriately, maintaining hardware as needed.

What is a validator client?

What is the deposit contract?

You can think of the deposit contract as a transfer of funds from an Ethereum account to a proof-of-stake validator account. It specifies who is staking, who is validating, how much is being staked, and who can withdraw the funds.

What is the easiest way to Solo Home Staking?

Setting up your own validator for "Solo Home Staking" is not difficult.

What is the time commitment for running a validator?

The majority of the time commitment for staking is the initial learning and setup. It will probably take a day or two of tinkering to get it all figured out (maybe more, and that's okay!). Once you get going you're looking at updating once a month or so (ten minutes) and responding to outages, which are rare.

What should I do if I am getting lots of client errors post Shanghai?

The most common cause of this issue is when node operators have failed to upgrade their node software prior to the network upgrade taking place. This can cause database corruption where a resync is required to get the node operating again.

Ensure that you are running a client version that is supported post network upgrade. The below versions should be the versions you are running at a minimum.

If you were running an older version post network upgrade, most likely your local database will need to be deleted and resynced as it has most likely corrupted. This is more commonly true for execution clients than it is for consensus clients.

If you download the beaconchai.in app or sign up to an account you can configure email alerts when new client releases are published so you won't run into this issue.

Two other methods are to follow the projects on Github so you can be emailed when a new release is published, or to join the client team Discord servers where new software releases are announced.

When should I top up my validator’s balance?

The answer to this question very much depends on how much ETH you have at your disposal. You should certainly top up if your balance is close to 16 ETH. This is to ensure you don’t get exited out of the validator set (which automatically happens if your balance falls below 16 ETH). At the other end of the spectrum, if your balance is closer to 31 ETH, it’s probably not worth adding the extra ETH required to get back to 32.

Where are some good places to view various staking metrics?

There are many great resources out there to help you monitor your setup, a few are linked below.

All of these services will help you see things such as attestation performance, block proposals and total ETH accrued from staking.

Where should I set my withdraw address to?

It is critical that you set your validator withdraw address to an address that you have created yourself and have full control over.

This is typically defined as: A wallet address where you have the private keys and the ability to both send and receive transactions.

If you do not have the private key for the wallet (For example, an address on an exchange) then do not set that as your validator withdraw address as there is no guarantee that the 3rd party will give you your rewards or even exist in the near future to continue giving you your rewards.

Always remember: Not your keys, not your coins.

Advanced setups such as setting the withdraw address to a multisig is also supported but it is only recommended for advanced users.

Why can't I see my withdrawn ETH?

You may notice that your block proposals and ETH withdrawals are not appearing in your wallet transactions. Do not panic, this is both expected and normal. They will not appear there as both of these are not transactions.

Whichever wallet you use will show your up to date ETH balance even if the transaction list is empty.

Why did my smart plug turn off my machine?

A not so frequently asked question but it has come up a few times! Some smart plugs only switch themselves back on after power failure when internet access has been restored.

However, in the case where your router or other critical network equipment are plugged into a smart plug with this "feature", they will not power back on unless the internet connection is restored, but the internet won't restore unless it has turned back on.

If you use a smart plug, it may be worthwhile to run a few tests to see if yours does this, otherwise you may find this out the hard way while attending Devcon on the other side of the world where it can only be fixed with manual action on-site...

Why do I need to have funds at stake?

As a validator, you'll need to have funds at stake so you can be penalized for behaving dishonestly. In other words, to keep you honest, your actions need to have financial consequences.

Why is all my RAM being used?

Why the 32 ETH maximum?

Each 32 ETH deposit activates one set of validator keys. These keys are used to sign off on the state of the network. The lower the ETH requirement, the more resulting signatures must be saved by the network. 32 ETH was chosen as a balance between enabling as many people as possible to stake without inhibiting decentralization by bloating the size of each block with signatures.

Limiting the maximum stake to 32 ETH per validator encourages decentralization of power as it prevents any single validator from having an excessively large vote on the state of the chain. It also limits the amount of ETH that can be exited from staking at any given time, as the number of validator that can exit in a given time period is limited. This helps protect the network against certain attacks.

A full node is one that runs both an and a .

Here is a simple breakdown of what is required to run a full Ethereum node:

• A stable Internet connection. The longer you stay online, the better your rewards. A spotty Internet connection will hurt your returns.

• At least 10Mbps of bandwidth both up and down. A full node usually takes around 8Mbps to 10Mbps up & down of network traffic, depending on your configuration.

• No data cap is imposed by your ISP. Running a full node will take a lot of data - as much as over 2 TB per month of on-chain data alone. This can be mitigated somewhat with a few settings tweaks to the ETH clients, but as a rule of thumb, don't run a full node if your Internet plan comes with a monthly data cap.

• Stable electricity. For the same reason as needing a stable Internet connection, you also want to have reliable power. This can be mitigated with a large UPS (backup battery) to deal with short blackouts.

• A computer with sufficient specs. This is pretty flexible because it really depends on what Execution and Consensus client you use, and what settings you configure them with. The computer can be a local machine, or it can be a Virtual Private Server (VPS) hosted in the cloud. Read below for some more information on those two options, and how to decide which is best for you.

The following are considered minimum requirements to run a full node:

• Linux or macOS Operating System

• Quad-core CPU (or dual-core hyperthreaded); both x64 and arm64 are supported

• 16 GB of RAM (preferably DDR4)

• 2 TB of free SSD Disk Space

  • A spinning platter hard drive is not fast enough to handle the constant random reads and writes that blockchain activity requires. You MUST use a solid-state drive.

• The ideal setup, and best practice is to have a dedicated computer for staking. Try to limit additional processes running on your staking box. Especially if it is something that is connecting to the outside world. Every extra process and every file being downloaded is another opportunity for an exploit.

• Your ETH will be locked into the until at the earliest mid-2023, . It makes sense to buy some good hardware. This isn’t like mining with razor-thin margins, it will pay for itself quickly.

• Use Linux, it's easy! For the foreseeable future, Linux will receive better support from both the client teams and the community at large. If you choose Linux you will have access to more guides and more technical support from the community at large. Linux is lightweight, stable, secure, and it doesn't force you to restart for updates every other day.

• Use a ! It is both good for the health of Ethereum and good for the health of your money.

• A battery backup (UPS) is strongly recommended! Plug your modem and router into it also. Many ISPs have generators to support emergency services communications, meaning the internet continues to work during a power outage as long as your equipment is powered. Your ISP may be the same. Aside from blackouts, not having your computer shut down on every momentary power flicker is a nice quality-of-life improvement when staking from home.

• Everything here applies to both solo staking and being a 16 ETH minipool node operator with .

Hardware examples

Hardware options

Raspberry Pi

Price: Lower cost.

Performance: Running an execution and consensus node on a Raspberry Pi is possible. Specifically, Nimbus which was designed to run on devices like a Raspberry Pi. Being able to run Ethereum nodes on low-powered hardware is great for decentralization and an honorable goal. However, running a validator is different. I maintain that the Pi’s lack of processing power and memory is a risk in some situations such as a period with no finalization. The reward of saving a few hundred dollars vs more powerful hardware does not even come close to outweighing the risk of extended downtime due to a lack of processing power or memory.

Power Usage: Approximately 8 watts.

Old laptop/desktop

Price: Lower cost.

CPU: For staking on Mainnet, a CPU that scores at least 6000 or better on Passmark is strongly recommended. For initial sync times, single-thread performance is better than having many cores.

Memory: Unless you go with an extremely bare-bones OS, 16GB is the minimum amount of RAM recommended for Mainnet.

Storage: An SSD is required. You do not need to worry about SATA vs NVMe, either will be fast enough. Buying one with a high terabytes written spec will help with longevity. The Ethereum execution and consensus layer are approaching 1TB in size so a 2TB or bigger drive is recommended.

Caveats: Stability and uptime are essential to maximize your profits. If you are using an older desktop consider replacing the PSU and the fans. Buying a titanium or platinum-rated PSU will help save on the monthly power bill as well.

If you are planning on staking with an older laptop, consider that they have reduced capacity to deal with heat due to their form factor, and in rare cases, running while plugged in 24/7 can cause issues with the battery. If you do choose to stake with a laptop, try using one that far exceeds the CPU requirements as running a laptop at nearly full load 24/7 is not advisable. You will probably be fine, but generally speaking, laptops are not designed with that in mind.

New laptop

If you are buying brand new, there is not much value in paying the price premium for a portable form factor, screen, keyboard, and trackpad. Once you get your staking machine set up, you do not need any of these features. You can just remote into the staking machine from your normal computer. The low profile form factor will actually be a downside when taking thermal performance into account. Laptops typically do not include an ethernet port now, which means you will be relying on WiFi. WiFi is very reliable now, but you can't beat the simplicity and reliability of a cable.

New pre-built desktop

This is likely the simplest option and it will be easy to upgrade and service in the future**.**

Price: Medium price.

Power Usage: Probably around 30 watts.

Custom built desktop

This is essentially the same as using a prebuilt desktop. However, building your own gives you the option of choosing a case you like the look of, and buying higher-quality parts. For those of you who have never built a computer, it is easier than Lego because they only go together one way. Also, you won’t get any weird proprietary parts that will be difficult to replace should they ever fail. Unfortunately with prebuilt computers, concessions are sometimes made with components like the PSU to assuage the accountants and boost margins. Style points for adding a RAID card!

Intel NUC

Price: Medium price.

Power usage: 20-25ish watts.

NUCs are super cute, and their small form factor gives them a very high significant-other approval factor. Unfortunately that does come with a bit of a price premium and slightly less performance than the larger desktop option. However, these are minor drawbacks. This is probably the best option for most people.

Server

Price: Higher price.

Power Usage: It's bad. A modern server runs around 100 watts. If you get an older one, expect to be up around 150 watts.

Enterprise servers are jam packed with features, and are specifically designed to do exactly what a validator is trying to do. Run 24/7/365. They have redundant power supplies in case one breaks, they mostly have 2 CPUs, so in the unlikely event of one going bad, you can pop it out and restart with just one. They have built in RAID cards so you can have redundant storage. They have hot swappable drive trays, so if one of your drives goes bad, you don't even need to shut down. All of the components are high quality and built to last. You also get monitoring and maintenance tools that are not included in consumer gear like iDRAC and iLo. I would definitely caution that while servers are great for staking, you probably want to be the type of person who is willing to go into the weeds a bit and geek out. There is some research required to know what you are looking for before you go out and buy a server and there is a possibility you run into a weird technical issue that you will have to troubleshoot.

Price: Medium price

Performance: The DAppNodeXtreme is a good option if you are looking for a custom built OS with an easy UX. A DAppNode box is just a NUC pre-configured with their software. If you are confident enough to install an OS by yourself, you can save a bit of money by purchasing a normal NUC and installing DAppNode yourself. You can also install the DAppNode OS on any computer. If you don’t want to mess around with installing operating systems and want an easy UX, buying a DAppNode box is a convenient and simple way to get started.

Power Usage: 20-25ish watts.

Avado is an easy home-staking solution for people with limited technical knowledge or limited time. The Avado boxes are pre-configured computers with a user-friendly UI that allows you to use and manage the device from anywhere in the world.

Using an AVADO is convenient, secure and true to the spirit of decentralization.

Price: Medium price.

Performance: Definitely upgrade to 16GB of memory. The CPU will be more than fast enough with a 15,108 passmark score. Make sure you have a plan to get up to 2TB or more of storage, the internal memory and storage is integrated into the motherboard and requires soldering and advanced technical knowledge to upgrade.

Power Usage: Slightly less than the NUC, but not enough to make any real difference.

It's not possible to run Linux on the new ARM architecture this uses. It is more expensive that the NUC and also falls short on upgradeability, and ease of service, but for the Mac OS fans out there this is a great option that will work very well.

Virtual Private Server

Price: Anywhere from $20 - $50 per month.

Performance: You can buy as much as you can afford.

If you live somewhere that is prone to natural disaster or has an unstable power grid or internet connection but still want to solo stake, this is a good option. If you do have stable power and internet, running your own hardware will be a cheaper/more profitable solution long term. You need to evaluate the pros/cons of this for your own situation. Remember that if one of the VPS providers goes down, it will mean all of the people using that VPS service to host will also go down, and the inactivity penalties will be much larger than if you have uncorrelated downtime yourself.

Vous ne devriez pas trop vous inquiéter des interruptions, mais comprendre ce qui se passe lorsque votre validateur est hors ligne peut vous aider à gagner en confiance en tant qu'opérateur solo à domicile.

Par exemple

• Vous lancez votre validateur solo à domicile avec 32 ETH.

• Tout se passe bien et après quelques mois, le solde de votre validateur est de 32,5 ETH.

• Puis... votre validateur est hors ligne ! 🚨

  • Si cela se produit réellement, consultez le guide "" .

Pénalité d'Inactivité

• Dès que votre validateur ne participe plus au réseau, il commencera à des ETH.

  • Lorsque vous êtes hors ligne, pour chaque attestation manquée, la fuite d'inactivité serait d'environ -0,000011 ETH (la fuite d'inactivité est légèrement inférieure à une attestation réussie).

  • Pour une attestation réussie normale, vous pourriez être récompensé de 0,000014 ETH.

• Si vous avez une défaillance catastrophique et que vous ne parvenez pas à remettre votre validateur en ligne pendant 5 jours, il vous faudra environ 5 jours de connexion pour revenir au même solde qu'au moment de la défaillance.

Propositions de Blocs Manquées

Si vous êtes hors ligne, vous ne pourrez pas produire de bloc. Mais à quelle fréquence les propositions de blocs se produisent-elles pour un seul validateur ? Actuellement, en moyenne, un validateur proposera un bloc tous les 2-3 mois.

Donc, dans cet exemple, même si vous êtes hors ligne pendant 5 jours, il y a seulement une petite chance que vous manquiez une proposition de bloc. Mais que se passe-t-il si vous manquez une proposition de bloc ?

Puis-je être exclu pour avoir été hors ligne ?

Que faire si je ne peux pas récupérer mon validateur et/ou que je souhaite arrêter la mise en jeu?

Conclusion

L'exclusion est un terme effrayant. Mais qu'est-ce que c'est exactement, comment cela peut-il se produire et à quel point devriez-vous vous inquiéter ?

Qu'est ce que cette exclusion ?

L'exclusion ("slashing" en anglais) est un terme utilisé pour décrire la réaction du réseau Ethereum face à un validateur agissant contre les règles du réseau. Les validateurs exécutent un certain nombre de devoirs (par exemple, et ).

Si quelqu'un voulait attaquer le réseau Ethereum, il pourrait proposer plusieurs blocs ou attester de plusieurs blocs conflictuels. Pour décourager les attaques sur le réseau, dans un système de , les validateurs ont quelque chose en jeu, qui est actuellement de 32 ETH par validateur. Lorsqu'un validateur enfreint les règles du réseau, deux choses se produiront :

1. Le validateur se voit retirer une certaine quantité d'ETH de ce solde initial de 32 ETH mis en jeu.

2. Le validateur est forcé de sortir et est retiré du .

La quantité d'ETH prise en tant que pénalité varie en fonction de l'état du réseau. Si un petit nombre de validateurs sont sanctionnés simultanément, alors une estimation approximative de la pénalité est de 1 ou 2 ETH. Dans un événement extrêmement rare de type "Cygne Noir", lorsque une grande partie du réseau est simultanément hors ligne ou enfreint les règles (par exemple, lors d'une attaque coordonnée), la pénalité peut aller jusqu'à 100% de la mise, voire la totalité.

Lorsque votre validateur est forcé de sortir et que la mise est retirée, vous pouvez remettre en jeu votre ETH restant (si vous avez toujours les 32 requis), après avoir à nouveau passé la et .

This is a simple NUC that I set up for my home staking validator. It was very easy to build - around 10 minutes to unpack everything, slot in the RAM and SSD, and turn it on.

I decided on the larger form factor for the NUC (there's a normal and a slim version) to avoid any problems with restricted airflow and overheating. I'm also not constrained on space so I didn't mind having a slightly larger form factor on my shelf.

2TB SSD is the right amount for me as I won't need to upgrade it within the next 1-2 years and possibly by that time there may be improvements made in the protocol and/or clients that allow for smaller states, needing less storage.

You don't need 64GB of RAM but I wanted to have extra in case I needed it in the future, but 16GB would have been fine.

Total cost: £1165 (October 2022)

The machine only needed three parts:

To open the NUC, simply unscrew the four retaining screws, and detach the ribbon cable.

The ribbon cable has a small plastic retainer that can be unclipped by hand.

With the ribbon cable removed, the NUC will look like this:

The first component to insert is the SSD. There is a retaining screw that needs to be removed before the SSD is inserted (1).

The SSD is placed in the slot that says "NVMe ONLY" (2). It can only fit one way because of the little notch, so there's nothing to worry about.

Replace the SSD retaining screw (1).

The SSD in place should look like this:

Insert the RAM into the slots. Again, they can only fit one way because of the little notch.

The finished setup should look like this:

Replace the NUC base plate and secure the four retaining screws... and that's it!

All you need to do now is plug in the power cable and press the power button to turn it on 🥳

If you're ever out and about and away from home for long periods of time, then this tutorial is for you!

Question - Why should I set up a VPN server? It is easier to simply forward ports and connect in.

Answer - A VPN server introduces another layer of security. To connect to your node via SSH, you first have to connect to your VPN and then SSH into your node. This introduces another barrier and makes intrusions much more difficult.

Requirements

• You will need a public static IP address or a DNS for your home network.

• This tutorial assumes you have Ubuntu Server 22.04 LTS installed and running. If not, no stress! You can follow the below link for a tutorial on how to do that.

Recommendations

• For security purposes, I recommend you set up the VPN server on a separate machine that is not your staking machine. This can even be a VM.

With all of that out of the way - Let's dive right into it!

Step 1 ) Run commands to ensure your machine is up to date.

Please login to the machine and authenticate as superuser using the below command

sudo -i

Now execute the below command to ensure the OS and packages are up to date. Please upgrade any that aren't.

apt-get update && apt-get upgrade

Step 2 ) Install OpenVPN dependencies.

Please execute the below command.

apt-get install ca-certificates wget net-tools gnupg

Step 3) Import OpenVPN GPG key and add the official repository.

Execute the below three commands

• This command will load the OpenVPN public GPG key.

• This command will add the OpenVPN access server repository to your machine.

• This command will check all configured repositories for updates.

Step 4) Install OpenVPN access server.

Now the fun begins! To install, execute the below command

Hooray, you've just installed OpenVPN access server! Pay attention to this part of the debug, it contains valuable information.

The Admin UI is for making changes to the server config and adding users.

Step 5) Configuring the server for remote access.

Browse to your Admin UI URL. You'll receive a certificate warning, you can safely ignore this and continue. Once completed, you'll see the below UI.

Please login, read and accept the EULA and we are ready to go!

We need to make a few network changes, for this please navigate to Configuration > Network Settings

Step 5.1) - Changing the VPN traffic port

Please find the "Multi-Daemon Mode" section, and edit both ports away from the default ports. This is for security purposes. These ports can be the same number. I picked 9514, but this is an example only, I recommend choosing your own ports.

Step 5.2) - Adding in your public IP

Please don't navigate away from the "Network Settings" page for now. But you will need to open the below URL in a new tab.

Copy your IP address from this website and paste it in the "Hostname or IP Address" field located at the top of the "Network Settings" page. This will already be populated with your private IP address, you must overwrite it with your public one.

Step 5.3) Configure the admin UI and client UI to run on different ports.

This step is optional but for security purposes I heavily recommend it.

We are going to configure the admin UI and the client UI to run on different ports because we only need to publicly access the client UI.

On the same page "Network Settings", please scroll down to the bottom and find "Client Web Server" and toggle the "Use a different IP address or port" setting.

Now we can change which port we want the client web server to run on, you can make this any port of your choosing. I chose 9515.

From here, please click "Save Settings" and then "Update Running Server"

Once the running server has been updated, you may need to refresh your browser and log back into the admin UI.

Step 5.4) Enforce MFA on all user accounts

This step is also optional, but for security purposes I also heavily recommend it.

We are going to require that all user accounts setup and use 2FA so in the worst case scenario where someone did get your otherwise guess your user credentials, they won't be able to gain access.

Please navigate to Authentication > Settings

Please find the "TOTP Multi-Factor Authentication" setting and toggle it

Once the setting has been changed, you must again click "Save Settings" down the bottom and then "Update running server" as shown in the bottom of the last example (Step 5.3).

Step 5.5) Advanced users only - Adding a static route

If you are an advanced user - You may have setup your OpenVPN server on a different subnet than your Ethereum nodes/validators.

If that is the case, you will need to browse to "Configuration > VPN Settings" and add in a static route for your validator network.

If they are not on separate subnets, please continue onto step 6.

Step 6) Adding user accounts.

Step 6.1) - Create a new user and set a password

Please navigate to "User management" > "User Permissions".

From here, you can add a new user. Please type out a username and tick the "Allow Auto-login" box, then select the "More Settings" box.

You can now set a password for the account in the new options that appear when you click "More Settings".

Once done, please "Save Settings" and "Update Running Server" again.

Step 6.2) Advanced users only - Allow access to another network

Step 7) Unblock local ports.

If you are using a local firewall (which you should be), you may need to unblock the local ports depending on how you have it configured.

Almost there!

Step 8) Port forwarding.

For this step you will need to login to your router and forward ports to the machine running OpenVPN access server. The exact workflow is router dependent, so please search online for instructions and include your router make and model in the search.

You will need to forward two ports, both TCP/UDP.

• The port(s) you entered for "Multi-Daemon Mode" (I used 9514)

• The port you entered for "Client Web Server" (I used 9515)

Once completed, please browse to the below website and enter in your ports to check if they are forwarded correctly.

Step 9) - Configure a device for VPN access.

If you've made it this far, then congrats! You will be pleased to know that all the hard stuff is out of the way.

Please complete this step on the device you want to set up remote access.

NOTE: If you enabled MFA as per step 5.4, then after logging in you will be prompted to setup a 2FA credential. You can use something like Google Authenticator or Authy. I heavily recommend enabling this as the extra security is definitely worth it.

Step 9.1 ) - Install OpenVPN client

Please select the OS you are using.

From here you can select a client for your device.

• If on Windows or Mac, it will automatically download the OpenVPN client software and guide you through the rest of the process.

• If on Linux, Android or iOS, it will take you to an external page with further instructions.

Step 9.2) Download the client user profile

Please download the "autologin profile".

Once done, you will have to import the profile into the OpenVPN software. The software itself (Windows or Mac) or external pages (Linux, Android or iOS) will show you how to do this.

Step 10) - Connect to the VPN

Lucky you, I saved the easiest step for last.

• If using a laptop or desktop, please connect to another network such as a mobile hotspot.

• If using a phone, please disconnect from your WiFi and ensure you are connected to your telco's internet.

Go back to the OpenVPN software and hit connect and you'll be connected in just a matter of seconds.

If the connection was successful, you will see it now matches your home IP as you are now connected to your home internet connection. From here you can securely SSH into your Ethereum nodes/validators.

If you can connect to your home network but are unable to SSH into your servers, you may need to tweak the firewall on your Ethereum node to accept incoming SSH connections from the IP address of your OpenVPN server.

FAQ

Can I connect to this VPN while also using a different VPN provider?

No. At least not easily. To get this to work you will need to write your own IP tables.

Does the client UI need to be exposed to the internet?

No. If you can access the server within your local network and download and setup your user profile, then you won't need to access the client UI externally.

However if you aren't within your local network and you need to redownload a user profile (For example if you are travelling and your phone/laptop dies and you get a new one) then you won't be able to login to the portal and download a new user profile.

A firewall is a security mechanism that monitors both incoming and outgoing network connections and can either accept or reject traffic based on a set of configurable rules. It is heavily recommended to have one configured to improve the security of your node/validator setup.

There are two kinds of firewalls:

Software firewalls

Software firewalls are run on the individual machine and protect it from other devices within the local network that it sits on.

It is recommended to have all traffic dropped by default and to set up individual rules allowing it where required, that way traffic can only enter the machine where it is explicitly allowed.

For example, if you run your execution node and consensus node on different machines, you can set up a firewall rule on your execution node to only allow traffic on port 8551 from the IP address of your consensus node.

If you are running Ubuntu Server, a firewall will already be installed by default under , you will just have to configure it and enable it.

If you are running Geth and Prysm and have the software running on different machines, you could set the below config.

Execution (Assuming Geth with IP 192.168.1.50)

Consensus (Assuming Prysm with IP 192.168.1.51)

From here additional ports can be unblocked such as SSH, the consensus HTTP API (If you are also running your validator on another machine) or the execution RPC API (If you wish to interact with the Ethereum network using your own node).

Hardware firewalls

Hardware firewalls are run on dedicated devices (Usually your router) and can manage traffic both within networks and between networks.

One way to really fortify your setup is to configure a dedicated subnet on your router solely for your nodes/validators and have the firewall drop traffic from any other subnet from reaching this subnet (Also known as blocking all RFC 1918 traffic)

Should your regular everyday computer (Or any other device on your network) become compromised, the infiltrator won't even know about your nodes as they are sitting on another subnet that is completely blocked off.

Here is a list of example home-staking setups created by the EthStaker community:

• NUC - Eridian

To protect your server from brute-force SSH connection attempts, you can install fail2ban.

This program will monitor incoming connections and block IP addresses that try to log in with faulty credentials repeatedly.

sudo apt-get install -y fail2ban

sudo vim /etc/fail2ban/jail.d/ssh.local

[sshd]
enabled = true
banaction = ufw
port = 22
filter = sshd
logpath = %(sshd_log)s
maxretry = 5

You can change the maxretry setting, which is the number of attempts it will allow before locking the offending address out.

Save the file and restart the service.

sudo systemctl restart fail2ban

Congratulations! You've successfully improved the security of your node 🥳

Checkpoint sync, also known as weak subjectivity sync, creates a superior user experience for syncing Beacon Node. It's based on assumptions of weak subjectivity↗ which enables syncing Beacon Chain from a recent weak subjectivity checkpoint instead of genesis. Checkpoint sync makes the initial sync time significantly faster with similar trust assumptions as syncing from genesis.

In practice, this means your node connects to a remote service to download recent finalized states and continues verifying data from that point. The third-party providing the data needs to be trusted to provide the correct information about the finalized state and should be picked carefully.

Validate against a known trusted source

You must verify the slot and state_root against a known trusted source. This can be a friend, someone from the community that you know or any other source that you trust. There is a maintained list of publicly hosted checkpoint sync endpoints here↗, but it is recommended to use your own trusted source first if possible.

You will need to know the IP & Port of your beacon node.

Obtaining slot and state root

Option A:

1. Check your consensus client logs

2. Find the slot number.

3. Find the state_root value.

Option B:

1. Open http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized in your browser.

2. Find the slot number.

3. Find the state_root value.

Option C:

1. Install curl and jq.

2. In a new terminal window run:

   Copy

   curl -s http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized | jq .'data.header.message'

If the slot and state_root from your validator matches the slot and state_root from (multiple) other sources, then it's a match, congratulations 🎉. If it's not a match you should start from scratch by wiping your beacon node and starting from the top.

Technical notes on checkpoint sync ↗

Weak Subjectivity ↗

MEV Boost Information and Guides

• Beaconcha.in Relays ↗

• CoinCashew MEV-boost guide ↗

• Flashbots docs ↗

• Flashbots GitHub ↗

• Inclusion Watch ↗

• mevboost.org ↗ - Tracker with real-time stats for MEV-Boost relays and block builders.

• mevboost.pics ↗

• MEV-Explore ↗ - Dashboard and live transaction explorer for MEV transactions.

• MEV Panda ↗

• MEV relay list ↗

• MEV Watch ↗

• Rated Network ↗

• Relay Monitor ↗

• Relay Scan ↗

• Tornado Warnings ↗

• Transparency dashboard ↗

• Uptime Monitor ↗

The EthStaker Knowledge Base aims to be an unbiased, open-source collection of useful information and concepts related to Ethereum staking. To ensure a positive and productive environment for all contributors and users, we have established a code of conduct. By participating in the EthStaker Knowledge Base, you agree to abide by these guidelines.

1. Be Respectful and Inclusive:

Treat all participants with kindness, respect, and empathy, regardless of their background, experience, or perspectives. The EthStaker Knowledge Base welcomes individuals from all walks of life and seeks to foster an inclusive community that values diverse ideas and perspectives.

1. Maintain a Professional Tone:

Ensure that your contributions to the Knowledge Base are clear, concise, and professional. Avoid using offensive language, personal attacks, or engaging in any form of harassment. Constructive criticism is encouraged, but always provide it in a respectful and helpful manner.

1. Contribute Accurate and Unbiased Information:

Ensure that the information you contribute is accurate, up-to-date, and unbiased. Refrain from promoting specific projects, products, or services that could lead to conflicts of interest. Instead, provide objective comparisons and analyses that empower users to make informed decisions.

1. Acknowledge and Attribute Sources:

When using information, ideas, or concepts from other sources, provide proper attribution and credit. This not only maintains the integrity of the Knowledge Base but also recognizes and respects the work of others in the community.

1. Prioritize Collaboration and Open Communication:

The EthStaker Knowledge Base thrives on collaboration and open communication. Share your ideas, ask questions, and engage with other contributors in a constructive and transparent manner. By working together, we can create a comprehensive and valuable resource for the Ethereum staking community.

1. Protect User Privacy:

Respect the privacy of all users and contributors. Do not share personal information or contact details without explicit permission. Any communication related to the EthStaker Knowledge Base should occur through public channels, unless otherwise agreed upon by all parties involved.

1. Report and Address Issues:

If you encounter any issues or violations of this code of conduct, please report them to the EthStaker Knowledge Base moderators. We are committed to maintaining a safe and welcoming environment for all participants, and will take appropriate action to address any concerns or misconduct.

By adhering to this code of conduct, we can create a positive and productive environment that fosters collaboration, innovation, and the advancement of knowledge within the Ethereum staking community. Thank you for your commitment to maintaining the integrity and values of the EthStaker Knowledge Base.

Validator effectiveness can be thought of as how useful an attestation is to the network, considering both block production and inclusion distance.

Attestation Inclusion Process

How are attestations included on the Ethereum network? The process is roughly as follows:

This is a simplified view of attesting, but can be a useful starting point.

1. Every attesting validator generates an attestation with the data it has available about the state of the chain.

2. The attestation is propagated around the Ethereum network to relevant aggregators.

3. Every relevant aggregator that receives the attestation aggregates it with other attestations that have the same claims.

4. The aggregated attestation is propagated around the Ethereum network to all nodes.

5. Any validator that is proposing a block and has yet to see the aggregated attestation on the chain adds the aggregated attestation to the block.

Whenever an attestation has an inclusion distance greater than 1 it is important to understand why. There are a number of possible reasons:

Attestation Generation Delay

A validator may have problems that result in delayed attestation generation. For example, it may have out-of-date information regarding the state of the chain, or the validator may be underpowered and take a significant amount of time to generate and sign the attestation. Regardless of the reason, a delayed attestation has a potential knock-on effect for the rest of the steps in the process.

Attestation Propagation Delay

Once an attestation has been generated by a validator it needs to propagate across the network to the aggregators. The nature of this process means that early propagation is critical to ensure that it is received by an aggregator in time for integration into the aggregated attestation before broadcasting. Validators should attempt to ensure they are connected to enough varied peers to ensure fast propagation to aggregators.

Aggregate Generation Delay

An aggregator can delay the attestation aggregation process. Most commonly this is because the node is already overloaded by generating attestations, but the speed of the aggregation algorithm can also cause significant delays when there is a large number of validators that need to be aggregated.

Aggregate Propagation Delay

Similar to attestation propagation delay, the aggregation attestation needs to make its way around the network and can suffer the same delays.

Block Production Failure

For an attestation to become part of the chain it needs to be included in a block. However, block production is not guaranteed. A block may not be produced because a validator is offline, or is out of sync with the rest of the network and so produces a block with invalid data that is rejected by the chain. Without a block there is no way to include the attestation in the chain at that slot, resulting in a higher than optimal inclusion distance.

Block production failure has a second impact, which is that it increases the total number of attestations that are eligible for inclusion in the next block that is produced. If there are more attestations available than can fit in a block the producer is likely to include the attestations that return the highest reward, which will be those with the lowest inclusion distance. This can result in attestations that miss their optimal block also missing subsequent blocks due to being less and less attractive to include.

The fact that block production is out of the validator’s control (except for those the validator itself produces) requires the definition of the term earliest inclusion slot, where the earliest inclusion slot is the first slot greater than the attestation slot in which a valid block is produced. This takes in to account the fact that attestations cannot be included in blocks that do not exist, and is no reflection on the effectiveness of the validator.

Malicious Activity

It is possible for a malicious actor to refuse to include any given attestations in their aggregates, or to refuse to include attestations in their blocks. The former is mitigated by having multiple aggregators for each attestation group, and the latter by the cost of excluding an aggregated attestation. Ultimately, however, if the cost of excluding an attestation from a block is compensated for monetarily, or is considered to have a higher value politically, there is nothing an attesting validator can do to force inclusion by a block-producing validator.

Calculating Attestation Effectiveness

Attestation effectiveness can be thought of as how useful an attestation is to the network, considering both block production and inclusion distance. It is formally defined as:

(earliest inclusion slot - attestation slot) / (actual inclusion slot - attestation slot)

Effectiveness is represented as a percentage value. An attestation that fails to be included with the maximum inclusion distance of 32 is considered to have an effectiveness of 0. Here are some example effectiveness calculations:

Aggregate Attestation Effectiveness

Attestation effectiveness for a single attestation is interesting but not very useful by itself. Aggregating effectiveness over multiple attestations, both over time and multiple validators, gives a better view of the overall effectiveness of a group of validators. Aggregate effectiveness can be calculated as a simple average of individual attestation effectiveness, for example a 7-day trailing average across all validators in a given group.

Source ↗

This is a Custom-built-desktop that I put together for stake solo validator. I decided on high-quality components at a good price so that they will not be obsolete quickly.

There are 6 main things to keep in mind:

1. Motherboard External site link ↗

2. Microprocessor External site link ↗

3. RAM memory External site link ↗

4. Hard Drive External site link ↗

5. Power supply External site link ↗

6. Cabinet External site link ↗

I decided on a mini ITX motherboard Z690l which is a small form factor, the card is modern to house Intel 12th generation microprocessors that will last me for many years of hard work.

An Intel Corei5-12400 microprocessor with integrated graphics, the ratio with or without integrated graphics is very little difference in cost, plus you save on buying a graphics card.

A 16GB DDR5 RAM with RGB looks great for your build, in addition to the 6000 MHz it reaches.

A hard drive SSD 2TB PCI Express 3.0 NV1 M.2 NVMe.

The power supply EVGA Supernova 750 GM is very important for the assembly, I decided on an EVGA for the mini ITX that does not make noise, that is modular, you save on cables that you do not need and the fan is only activated when it is needed. With the SFX shape that is smaller.

Finally, Cabinet Cooler Master NR200P SFF - Mini-ITX, removable and with great access to modify the hardware components, including fans.

It is certainly a wise decision to build your own node. They are quality components without a doubt, you can save more by buying other motherboards or another type of RAM.

1. $280 USD - Motherboard Z690I AORUS ULTRA LITE LGA 1700/ Intel Z690/ Mini-ITX/ DDR5/ Dual M.2/ PCIe 3.0/ USB 3.2 Gen2X2 Type-C/2.5 GbE LAN

2. $225 USD - Microprocessor Intel Procesador Core i5-12400 - S-1700-2.50GHz - 6-Core - 18MB Smart Cache (12va. Generación - Alder Lake)

3. $125 USD - RAM memory 16GB DDR5 XPG ECC CL40 XMP 6000 MHz RGB

4. $145 USD - Hard Drive SSD 2TB PCI Express 3.0 NV1 M.2 NVMe

5. $115 USD - Power supply EVGA Supernova 750 GM, 80 Plus Gold 750W, Fully Modular, Eco Mode with FDB Fan, SFX Form Factor

6. $125 USD - Cabinet Cooler Master NR200P SFF - Mini-ITX

TOTAL: $1015 USD (September 2022)

Greetings #StakeFromHome #Mexico

There are multiple consensus clients (previously known as 'Eth2' clients) to support the consensus upgrades. They are running the Beacon Chain and provide a proof-of-stake (PoS) consensus mechanism to execution clients.

Consensus clients all follow the same specification ↗. If a client doesn't follow this spec it won't be able to come to consensus with the rest of the network.

Lighthouse

Lighthouse is a consensus client implementation written in Rust under the Apache-2.0 license. It is maintained by Sigma Prime and has been stable and production-ready since Beacon Chain genesis. It is relied upon by various enterprises, staking pools and individuals. It aims to be secure, performant and interoperable in a wide range of environments, from desktop PCs to sophisticated automated deployments.

Loadstar

Lodestar is a production-ready consensus client implementation written in Typescript under the LGPL-3.0 license. It is maintained by ChainSafe Systems and is the newest of the consensus clients for solo-stakers, developers and researchers. Lodestar consists of a beacon node and validator client powered by JavaScript implementations of Ethereum protocols. Lodestar aims to improve Ethereum usability with light clients, expand accessibility to a larger group of developers and further contribute to ecosystem diversity.

Nimbus

Nimbus is a consensus client implementation written in Nim under the Apache-2.0 license. It is a production-ready client in use by solo-stakers and staking pools. Nimbus is designed for resource efficiency, making it easy to run on resource-restricted devices and enterprise infrastructure with equal ease, without compromising stability or reward performance. A lighter resource footprint means the client has a greater margin of safety when the network is under stress.

Implemented by Trinity. Works like fast sync but also downloads the data needed to execute latest blocks, which allows you to query the chain within the first few minutes from starting.

• Syncs state first and enables you to query RPC in a few minutes.

• Still in development and not fully reliable, background sync is slowed down and RPC responses might fail.

Prysm

Prysm is a full-featured, open source consensus client written in Go under the GPL-3.0 license. It features an optional webapp UI and prioritizes user experience, documentation, and configurability for both stake-at-home and institutional users.

Teku

Teku is one of the original Beacon Chain genesis clients. Alongside the usual goals (security, robustness, stability, usability, performance), Teku specifically aims to comply fully with all the various consensus client standards.

Teku offers very flexible deployment options. The beacon node and validator client can be run together as a single process, which is extremely convenient for solo stakers, or nodes can be run separately for sophisticated staking operations. In addition, Teku is fully interoperable with Web3Signer↗ for signing key security and slashing protection.

Teku is written in Java and is Apache 2.0 licensed. It is developed by the Protocols team at ConsenSys that is also responsible for Besu and Web3Signer.

The Ethereum community maintains multiple open-source execution clients (previously known as 'Eth1 clients', or just 'Ethereum clients'), developed by different teams using different programming languages. This makes the network stronger and more diverse. The ideal goal is to achieve diversity without any client dominating to reduce any single points of failure.

Geth

Go Ethereum (Geth for short) is one of the original implementations of the Ethereum protocol. Currently, it is the most widespread client with the biggest user base and variety of tooling for users and developers. It is written in Go, fully open source and licensed under the GNU LGPL v3.

Besu

Hyperledger Besu is an enterprise-grade Ethereum client for public and permissioned networks. It runs all of the Ethereum Mainnet features, from tracing to GraphQL, has extensive monitoring and is supported by ConsenSys, both in open community channels and through commercial SLAs for enterprises. It is written in Java and is Apache 2.0 licensed.

Besu's extensive documentation will guide you through all details on its features and setups.

Nethermind

Nethermind is an Ethereum implementation created with the C# .NET tech stack, licensed with LGPL-3.0, running on all major platforms including ARM. It offers great performance with:

• An optimized virtual machine.

• State access.

• Networking and rich features like Prometheus/Grafana dashboards, seq enterprise logging support, JSON RPC tracing, and analytics plugins.

Erigon

Erigon, formerly known as Turbo‐Geth, started as a fork of Go Ethereum oriented toward speed and disk‐space efficiency. Erigon is a completely re-architected implementation of Ethereum, currently written in Go but with implementations in other languages under development. Erigon's goal is to provide a faster, more modular, and more optimized implementation of Ethereum. It can perform a full archive node sync using around 2TB of disk space, in under 3 days.

Ethereum is a peer-to-peer network with thousands of nodes that must be able to communicate with one another using standardized protocols. The "networking layer" is the stack of protocols that allow those nodes to find each other and exchange information. This includes "gossiping" information (one-to-many communication) over the network as well as swapping requests and responses between specific nodes (one-to-one communication). Each node must adhere to specific networking rules to ensure they are sending and receiving the correct information.

There are two parts to the client software (execution clients and consensus clients), each with its own distinct networking stack. As well as communicating with other Ethereum nodes, the execution and consensus clients have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication.

Execution clients gossip transactions over the execution-layer peer-to-peer network. This requires encrypted communication between authenticated peers. When a validator is selected to propose a block, transactions from the node's local transaction pool will be passed to consensus clients via a local RPC connection, which will be packaged into Beacon blocks.

Consensus clients will then gossip Beacon blocks across their p2p network. This requires two separate p2p networks: one connecting execution clients for transaction gossip and one connecting consensus clients for block gossip.

Source ↗

It is very important that you forward ports to both your Ethereum execution and consensus clients, this ensures you are able to peer with other nodes efficiently.

Your execution and consensus client will still run without port forwarding, but you may notice it will take a very long time to find peers, and you may struggle to connect with a meaningful number of them too. So it is in your best interest (and heavily recommended) to have them forwarded.

Below are a list of the default ports that the software(s) are set to listen on.

If your node is running and the port(s) have been forwarded, you can use an online tool such as this one to check whether the ports are forwarded correctly.

For more information on how to actually forward the ports, it is best to search for instructions via google, make sure to include your router make and model as the specific steps taken to forward ports will vary depending on your router.

Static IP's

It is also recommended to configure your node with a static IP. This can be hardcoded on the machine itself or set as a reservation on your DHCP server (which is usually your router).

If your node gets a dynamic IP address assigned to it, there is always the chance that your machine may get assigned a different IP address and your port forwarding will no longer work as they will be pointing to the old IP.

Extra reading: Exploring Eth2 – Why Open Ports Matter

Automatic security updates are helpful when you are not able to access your machine but want critical security updates to be applied automatically.

Update system packages again.

Restart the machine.

Congratulations! You've successfully enabled unattended-upgrades on your staking machine 🥳

To install Linux on a physical machine here are the steps to follow:

1. Download a Linux distribution image onto your everyday computer.

2. Flash a USB with the distribution image.

3. Boot your staking machine from the USB.

4. Select the right options for your installation.

Download a Linux distribution image

There are lots of Linux distributions available. If you are an experienced Linux user then you will already know which distribution you want to use based on your skills and ability. However, if you are a new Linux user or just want to keep things simple, then the recommended Linux distribution is Ubuntu Linux.

There are two types of distribution that you can choose:

• Desktop:

• Server:

Desktop comes with a graphical interface that is similar to Windows or macOS desktops. For staking machines, the desktop version isn't ideal as it comes with additional overhead that isn't required, but it can be easier for new users who feel more comfortable with a graphical interface.

Server is a command line only interface. This can feel intimidating at first, but when following you will simply be copying and pasting commands, so it's not too difficult. You can remotely connect to your staking machine securely using protocols like SSH, but the easiest way to get started is to directly connect a keyboard and monitor. .

Flash a USB with the distribution image

There are lots of tools available to flash USB drives with disk images. One that is open source and works across multiple platforms is . Simply select the Linux distribution image you downloaded previously, select the USB, then Flash!

Boot your staking machine from the USB

This step should be as easy as inserting the USB that you flashed with the disk image in the previous step and then turning on your staking machine. In some cases, you may need to force the machine to boot from the USB rather than any currently installed OS. This can be done by editing the BIOS boot order and allowing booting from USB. Google is the best place to find information about booting from a USB if you do encounter any problems at this stage.

Select the right options for your installation

Once you have booted from a USB you will be presented with an installation menu. Use the arrow keys (up and down) to move the selection and use the return key (enter) to select the option.

After selecting Try or Install Ubuntu Server you will see a screen like this. You don't need to do anything at this point, the system is just starting up.

Once the system has started you will be presented with the installation wizard. The first step is to select the language.

Select the keyboard layout.

Select the installation type you want to use. For this, select Ubuntu Server.

Select a network. If your staking machine uses an ethernet cable for a direct network connection (recommended) then this option should already be populated. If using WiFi, select those details.

Select a proxy if required. If you are using a standard home network and don't know what this option means, don't worry, just leave it blank.

Select where you want to download the updates for the operating system from. This location can be selected based on your geographic location so that the downloads are faster. But it's easier to just select the default option that's pre-populated.

Select the storage configuration. As your staking machine is most likely a dedicated machine selecting Use an entire disk is the best option. Don't worry about encryption as you want your machine to be able to automatically restart, and encrypted disks make that process much more complex.

You'll be shown a summary screen of the storage configuration. Linux by default may not use the entire available disk space. In the screenshot above the local storage size is shown as 1.171 Terabytes, but the confirmation screen below only shows 100GB being used.

To use all the available disk space, use the arrow keys to highlight the ubuntu-lv row and hit the return/enter key to select Edit. Enter the Max value shown next to Size in the input field, then save the update.

After confirming the storage settings you will be presented with an additional confirmation screen to make sure that you're ready to completely format and wipe any existing data on the storage disk. That's what we want, so select Continue.

Setting up the user profile is important as it's how you will access the machine, both directly and remotely. Select a name for your user and the name for your server that will appear on your local network. Your username is used to login to the machine and the password protects your user account.

This screen might be displayed asking you to select or deselect popular snaps. Don't worry about this page, it might even be empty for you. Simply move on to the next screen.

At this point, the installation will begin using all the configuration settings you've provided. This can take a few minutes (10 or more) depending on your hardware and configuration. You don't need to do anything, just wait until it completes. At the end of the installation process, you will need to reboot your machine. Select Reboot Now and it will ask you to remove the installation device (the USB you used during the installation).

Once the system reboots you'll see startup information similar to the output below. Wait until that completes and you'll be shown a login screen.

This is the login screen for your validator machine. The name of this machine is eridian-validator.

Enter the username you created during the installation. You will then be prompted for your password. As you type your password nothing will be shown on the command line (so it will look like it's not working!) but don't worry, this is for security and the typing is working.

And... you're in!

Congratulations! You've successfully installed Ubuntu Linux server on your staking machine 🥳

Lighthouse Slashing Protection

The Lighthouse validator client includes a mechanism to protect its validators against accidental slashing, known as the slashing protection database. This database records every block and attestation signed by validators, and the validator client uses this information to avoid signing any slashable messages.

Connecting remotely to a staking machine, whether it's hosted by a cloud provider (AWS, etc.) or running in your home is most often achieved using SSH (Secure Shell).

SSH is a command line tool that allows direct access to a remote machine. This tutorial will cover:

This tutorial won't cover the networking setup required to get a static IP, hostname and/or as those are covered in other tutorials.

While SSH on its own is a great tool, there are some limitations that can be frustrating when connecting over a poor internet connection. For example, if the internet drops even for a second (if you're in a moving car or train) or you change WiFi networks, the SSH connection will be closed.

Installing SSH on your staking machine

When you installed Linux on your staking machine the installation options should have asked if you would like to install SSH during the setup process.

To check if SSH is installed on your staking machine run the command:

If SSH is installed you should see a response showing the installed version:

If you get an error or don't see the version output then it's likely that the SSH server is not installed. When you want to install any new packages to your Linux system it's best practice to make sure that your current packages are up to date for security purposes:

Then install openssh-server:

If you are using UFW as your firewall and have restricted incoming and outgoing connections then you will need to add the SSH port to allow remote connections (replacing <SSH_PORT> with the configured SSH port - the default port is 22):

Connecting to your staking machine using SSH

Once you have confirmed SSH is installed on your staking machine, you can connect from a different machine using the command:

For example: ssh eridian@186:204:70:208

This command attempts to connect with your user's username at the specific IP address (or Host Name) of your staking machine.

You may get a prompt saying something like "You haven't connected to this machine before, do you want to trust it?" to which you should submit Yes as the response.

At this point, if everything is configured correctly, you should be prompted to input your password. This is the password you use to log in with your staking machine user.

Using Mosh to improve your remote connection experience

Benefits of using Mosh:

• Mosh uses a predictive interface for typing commands into the console. Standard SSH only shows the typed command once it has returned from the remote server. If you have a slow connection, this can be perceived as a laggy/slow interface. Mosh displays the text as you type commands, giving a much nicer user experience.

Limitations of using Mosh:

• A limitation you will notice when using Mosh is that you can't scroll back up the terminal history. This is due to the way Mosh only renders the current screen, which has some performance advantages but can be frustrating if you miss something and can't scroll back to see it.

Install Mosh on your staking machine:

If you are using UFW, allowing Mosh ports through the firewall:

Mosh uses the same connection method as SSH, so once it is installed and the ports have been allowed it should be as simple as connecting with the command:

If you have changed the default SSH port you can specific the port used by Mosh using the command:

Using Blink Shell for iOS for mobile connections

On your device (iPhone or iPad) open the Blink Shell app and type:

Keys & Certificates can be added if you are using an SSH key for your connections:

Hosts can be configured so you have an alias command e.g. ssh validator that you can use with preconfigured settings

iCloud sync can be turned off if you don't want your SSH keys and passwords to be stored in iCLoud.

Auto Lock is a useful feature to add additional security to your portable device.

And that's it! You can now connect to your home staking validator remotely from your iOS device 🗺️

Generating SSH keys

For additional security, SSH keys can be used alongside or instead of your username/password authentication when connecting to your staking machine.

Changing the default SSH Port

The default port configured is 22 for SSH connections. If you want to change the default port for any reason (e.g. due to port forwarding on your router or the port being used by another service) follow these steps:

1. Open the /etc/ssh/sshd_config file and locate the line:
2. Uncomment that line (by removing the leading # character) and change the value with an appropriate port number (for example, 22000):
3. Save the change.

4. Restart the SSH server:
5. To confirm the port has been updated correctly run:
6. The result should show the new port number:

This is a list of high quality staking guides that are recommended on :

It's critically important for the health and long term sustainability of Ethereum that there is a diverse and balanced client ecosystem. Multiple, independently developed and maintained clients exist because client diversity makes the network more resilient to attacks and bugs. Multiple clients is a strength unique to Ethereum - other blockchains rely on the infallibility of a single client. However, it is not enough simply to have multiple, clients available, they have to be adopted by the community and the total active nodes distributed relatively evenly across them.

Please consider running a minority client to support Ethereum.

Even if you have a large SSD installed, there are cases where Ubuntu only reports 200GB of total available space, causing the system to run out of disk space when syncing.

The error message is similar to:

Fatal: Failed to register the Ethereum service: write /var/lib/goethereum/geth/chaindata/383234.ldb: no space left on device

To address this issue, assuming you have an SSD that is larger than 200GB, expand the space allocation for the LVM by following these steps:

Congratulations! You're now using all available disk space on your staking machine 🥳

Exiting a validator requires a signed message to be sent from your validator client. The exit process details are different for each client. These links are for each specific client:

Two-factor authentication involves requiring a second security measure in addition to your password or SSH key, usually on a separate device from your primary one.

For example, you may be familiar with logging into a website such as a crypto exchange using both a password and a Google Authenticator code (or an SMS code). This two-step process is an example of two-factor authentication.

SSH can also be configured to require a Google Authenticator code, which means that an attacker that somehow compromised your SSH key and its passphrase would still need the device with the authenticator app on it (presumably your phone). This adds an extra layer of security to your system.

Start by installing (or a compatible equivalent) on your phone if you don't already have it. For Android users, consider which is an open-source alternative that supports password locking and convenient backups.

Next, install the Google Authenticator module on your node with this command:

Now tell the PAM (pluggable authentication modules) to use this module. First, open the config file:

Find @include common-auth (it should be at the top) and comment it out by adding a # in front of it, so it looks like this:

Next, add these lines to the top of the file:

Then save and exit the file with Ctrl+O, Enter, and Ctrl+X.

Now that PAM knows to use Google Authenticator, the next step is to tell sshd to use PAM. Open the sshd config file:

Now change the line KbdInteractiveAuthentication no to KbdInteractiveAuthentication yes so it looks like this:

(Older versions of SSH call this option ChallengeResponseAuthentication instead of KbdInteractiveAuthentication.)

Add the following line to the bottom of the file, which indicates to sshd that it needs both an SSH key and the Google Authenticator code:

Every option added to AuthenticationMethods will be required when you log in. So you can choose e.g. 2FA and password, or a combination of all three methods.

• publickey (SSH key)

• password publickey (password)

• keyboard-interactive (2FA verification code)

Then save and exit the file with Ctrl+O, Enter, and Ctrl+X.

Now that sshd is set up, we need to create our 2FA codes. In your terminal, run:

First, it will ask you about time-based tokens. Say y to this question:

You will now see a big QR code on your screen; scan it with your Google Authenticator app to add it. You will also see your secret and a few backup codes looking like this:

Finally, it will ask you for some more parameters; the recommended defaults are as follows:

Once you're done, restart sshd so it grabs the new settings:

When you try to SSH into your server with your SSH keys, you should now also be asked for a 2FA verification code, but not for a password.

A common reason for Geth to fail can be an unexpected shutdown of a validator machine. Geth uses RAM for temporary memory and during a graceful shutdown some important information will be written to disk. However, during an unexpected shutdown, there isn't time to write to disk (e.g. due to a sudden loss of power) so important data is lost. This loss of data leads to a corruption of the chaindata folder, requiring a resync.

File Locations

• Standard location of the chaindata folder.

• Standard location of the ancient folder.

Steps (If the ancient folder exists)

Good news! The required resync can be made much faster than a full resync simply by keeping the ancient folder. The ancient folder contains files that are not corrupted during an unexpected shutdown.

1. Stop Geth.

2. Move the ancient folder.

3. Delete the chaindata directory and recreate it.

4. Move the ancient folder back to the now empty chaindata directory.

5. Change the ownership of the chaindata directory to the Geth user.

6. Start Geth.

Congratulations! You've successfully started a Geth resync 🥳

Steps (If the ancient folder does not exist)

If the ancient folder does not exist, that's not a problem. It just means you will need to resync Geth from scratch, which will take a bit longer.

1. Stop Geth.

2. Delete the chaindata directory and recreate it.
3. Confirm the ownership and permissions for the chaindata directory are set to the Geth user.
4. Start Geth.

Congratulations! You've successfully started a Geth resync 🥳

When migrating validator keys, take your time, do not rush!

There are many scenarios where you need to move the validator keys from one machine to another, here are some examples:

• ⬆️ Upgrading hardware.

• 🔧 Recovering from a hardware failure.

• ☁️ Migrating from a cloud hosting service to a home staking machine.

In any of these cases, the procedure should be the same. The most important thing to remember is that the penalty for being offline is very low, so do not optimize for minimum downtime. A slashing event caused by incorrect key migration will incur a penalty equivalent to MONTHS of simply being offline.

🚨 Do not rush 🚨

Definitions

Source: Where the keys are coming from. Target: Where the keys are being migrated to.

Steps

1. Stop the validator client on the source machine.

2. Stop the validator client on the target machine.

3. Wait a MINIMUM of 2 finalized before continuing.

4. Copy the validator keys to the target machine either through intermediate storage (e.g. a USB) or directly from source to target machine (e.g. scp, rsync, etc.). If the validator keys have been lost due to a hardware failure, .

5. Delete the keys from the source machine. This ensures that even if the source machine restarts unexpectedly, the validator signing keys won't exist so cannot be used by the validator client.

6. If available, export any from the source machine and import on the target machine.

7. Turn off the source machine and be 100% sure it cannot be restarted.

8. Start the validator client on the target machine.

9. Import the validator keys.

10. Check the validator client logs to confirm everything is working correctly.

Congratulations! You've successfully migrated your validator keys between two machines 🥳

This page will show you how to configure your execution client to serve HTTP RPC requests.

This will allow you to interact directly with the Ethereum network using your own node. No need to use a 3rd party service like Infura anymore!

1) Configure your execution client

You will need to add the following flags to your execution client.

2) Configure your wallet

The below example will show you how to use your RPC endpoint with Metamask as it is one of the most commonly used wallets.

2.1) Open Metamask, click the menu icon at the top right, and select "Add Network"

2.2) Scroll down the bottom and select "Add a network manually"

2.3) Fill in your node details

The specific details will vary depending on your local setup. As I am running Geth on the same machine as my Metamask installation, so I am using 127.0.0.1 as the IP address.

If your RPC is unavailable or otherwise inaccessible, it may show an error when you enter the Chain ID and won't allow you to save the network.

2.4) Look out for the confirmation message

2.5) Swap to your new network if Metamask hasn't done so already

Success! Now you can use Metamask as you normally would with the added benefit of accessing the Ethereum network through your own node 🥳

As described in , the only way to receive rewards from the or the initial 32 ETH deposit upon a is for a validator to have set a changing their Withdrawal Credentials from 0x00 to 0x01.

It is possible upon validator creation to specify a withdrawal address and, if you have done so, there is no need to update your credentials. In fact, once your credentials have been set to 0x01 it will not be possible to change them in the future. This is why it is imperative that when you choose a withdrawal address, you choose one that you have full control over such as a hardware wallet. It is heavily recommended to NOT choose a wallet on an exchange or third party where you do not control the private keys.

Please note: If at any point you are confused as to what to do, please ask the EthStaker community for guidance. There are no stupid questions and we always strive to be welcoming first and knowledgeable second.

eth-docker users: There is a standalone guide if you use eth-docker . The following guide can be considered a companion as the steps are very similar.

Warnings

• Choose an address you have full control over: Hardware wallets are preferred and exchange wallets MUST NOT BE USED. You may think it is clever to send to a hot wallet or an exchange to avoid extra transaction fees, but you are risking not only your rewards but the initial 32 ETH deposit.

• Once your withdrawal credentials have changed from 0x00 to 0x01 they can not be changed in the future.

• Your mnemonic is required to change your credentials: Your funds will be locked indefinitely as long as your withdrawal credentials are 0x00. Without your mnemonic, it will not be possible to update your credentials. Except for extremely rare cases of controlling the withdrawal private key and keystores, we recommend searching thoroughly and retracing your steps if you are having trouble locating your mnemonic.

• Go offline! Security is important: When making this change, you will be exposing your mnemonic so it is heavily encouraged to perform this action offline. Failing to do so could result in the theft of the mnemonic and your validators.

• All Beacon chain rewards and the initial deposit will go to the specified address automatically without user interaction: The address specified will be the only location rewards and the initial deposit can go once set. If the specified address becomes compromised, it is advised to work with a White Hat group to recover your funds.

• Do not throw away your mnemonic after updating your credentials: Even after the credentials are changed, you are still advised to hold on to your mnemonic as it can be used to regenerate your keystore files if those files become lost. Your mnemonic can be passed on to your heirs.

Choose your tool

There are two primary tools that are used to make the credential change and both have different requirements. Look at both options and choose based on your situation. Normally if you have multiple validators associated with a single mnemonic, ethdo is the preferred approach.

Waygu KeyGen

A GUI application that provides the functionality available with the Ethereum Staking CLI tool. If you are a non-technical user, this is a perfect choice. It is easy to use and less error-prone than attempting the Staking CLI directly. There is a for this tool.

ethdo

An extremely powerful CLI tool that is ideal for technical users or those who have multiple validators associated with the same mnemonic. This tool has also proved to be very effective with users who have run into issues with Waygu KeyGen, normally due to misunderstandings. Due to the technical barrier of this tool, the rest of the guide will be centered around how to use it.

Preparation

In order for ethdo to make the necessary changes, there are a number of things you will need:

• Offline Preparation File: This is a file that contains information on all validators in the Beacon chain such as the public key, validator index, and current credentials (called the Beacon chain state). This data is required for the tool to make the necessary signature. To generate this file, you can run the following command on your Beacon chain client: ./ethdo validator credentials set --prepare-offline

• An execution layer address: In order to receive funds, you need to specify an execution layer address that you fully control. This would preferably be a hardware wallet such as a ledger but you certainly want to choose an address that has the highest security. After an address is set, if the corresponding wallet were to be compromised, you would have a high likelihood of losing your rewards and initial deposit.

• A USB flash drive: The machine you are going to perform this change on will not have access to the internet and thus you will not be able to download or upload anything directly. In order to get the necessary information to the machine and the results from the machine, you will need a flash drive to store said information and results. On this flash drive you should put the ethdo cli tool, the offline-preparation.json file, and the address you wish to set.

Change your credentials

Before you start this process, understand that until you move your results to an online computer and submit them, you can not mess up this step. Take a breath and relax, we'll get through it together.

Warning: It's worth repeating - Please go through the effort of performing this operation on a fully offline computer. A user reported that they made the change online on their work computer and they received a message from their IT staff with their mnemonic included. Luckily for that individual, whoever discovered the mnemonic was a good person and warned them. Please take security seriously.

Start the offline computer

Get the tools on the computer

In the terminal, we are going to copy the contents of the flash drive to your local device to avoid any permission issues. To do so, you first need to locate your drive contents. Usually running these commands will find it:

Once found, you can run :

and copy the resulting location along with the usd drive name.

Now to copy the contents, we can navigate back to our home and run a command to copy the contents and fix the permissions:

Where <PWD_RESULT> is the result of your command above. Something similar to:

At this point, running:

should result in the CLI executing and providing a list of all the commands it has to offer.

Create the operation

Now with your address and mnemonic on hand, you can run the following command and fill in the necessary information:

Where the withdrawal-address is the execution address you FULLY CONTROL and the mnemonic is the 24 word phrase that was used or created when you made your validators.

Submit the operation

In order to submit the operation, we need to transfer the change-operations.json file to a computer with a connection to the internet. Copy the change-operations.json file to your USB through the file explorer or the following command:

again, should be similar to:

You can now safely shut off the air-gapped computer.

Plug in the USB to a computer you are comfortable with that has an internet connection.

Open the change-operations.json file and look for an attribute called to_execution_address. That is the address your Beacon chain rewards will go to. Be absolutely sure this is the address you specified and have full control over. Sending a test transaction to and from the address is advised.

Where <IP> is the address of your node, most likely localhost

Verifying changes

FAQ

My credentials are 0x01. Do I have to do anything?

How can I change my withdrawal address again?

After you have set a withdrawal address, changing your credentials from 0x00 to 0x01, it is NOT possible to change them again. If you would like to have your rewards and deposit go to a different address, you will need to exit the validator and reenter with the desired address specified.

I have my deposit mnemonic. Can I change my credentials?

The only way to submit a valid credential change is if the operation is signed by the Mnemonic you created the validators with. This is normally a 24-word phrase. Your deposit account is irrelevant unless you specified your deposit mnemonic when creating your validators.

I lost my mnemonic. Won't the funds go back to the deposit address?

We are sorry to say no. Beacon chain rewards and the initial deposit can only go to the set address or will remain locked indefinitely if the credentials are 0x00. During the development of the Beacon chain and at the time of its launch, it was expected that 0x00 credentials could be used to handle withdrawals directly. But due to changes in future development plans, it was decided that an execution layer address would need to be specified forced the 0x00 to 0x01 change.

I'm 100% certain I have the correct mnemonic. Why is the credentials set command failing?

ethdo works by searching the Beacon chain state for the public keys corresponding to the mnemonic provided. It attempts 1024 different indices (also known as paths or positions) before failing. If you use a third party such as StakeFish or Staked.Us, it is possible the public key will not match. You can get around this by using your private key instead. Please follow these instructions and get in contact with the EthStaker community if you have issues:

This will output the private key of the 0th path. Copy that value and try this command:

The change-operations.json is showing a weird 0x010000000 value! What is that?

When you have set a withdrawal address, the credentials have a pattern of 0x01 followed by 22 0 and then your address without the 0x prefix. So if your address was 0x123456789abcdeedcba987654321012345789abc your credentials would be 0x010000000000000000000000123456789abcdeedcba987654321012345789abc after it was successfully changed.

With that out of the way, let's get into it. There are a few things that you can do to minimize your potential downtime.

There will always be situations where you will have downtime, it is inevitable when running a validator so please don't chase a perfect attestation record. There are however some things you can do to minimize downtime.

The below ideas may or may not be feasible depending on how many validators you are running. Please weigh up the pros and cons yourself and decide if it is appropriate for you to do in your circumstances.

Connecting your node and router to a UPS

This will ensure abrupt shutdowns don't occur potentially saving your hardware from breaking, or your DB/OS from corrupting saving you a resync/reinstall. More information can be found about this on the

Running multiple Consensus-Execution client pairs.

Either on the same machine but on a different SSD or an entirely separate machine and running different consensus/execution client software. A separate machine is more important if you are running a sizeable number of validators, otherwise, it may be overkill.

It is perfectly safe to run multiple nodes for redundancy, just not multiple validators.

The benefit of doing this is you won't have any downtime should one of the client pairs go offline, or corrupt, or if the SSD where it is sitting breaks and it requires manual maintenance to bring back online. You'll be able to fix the broken node in your own time while the validator will happily use the other configured beacon node and continue performing its duties.

You can even take it a step further and have your validator client on a separate SSD (For example, with your OS) and have it point to your beacon nodes, both of which would also be on separate SSDs, with less points of failure all around.

Having spare hardware ready to go.

It can be useful to have a spare SSD ready to be swapped out in case of hardware failure. You will be able to immediately start the process to recover your nodes/validators and when that is done you can then buy a replacement drive at your own leisure.

If you travel around a lot, you could even have it plugged into your machine on standby ready to go meaning your node could be recovered remotely, unless of course, the drive that fails is your OS drive.

There will be times when you are offline and are missing attestations, do not stress or panic when this happens and focus on getting yourself back online. If for example, you are offline for 4 hours, it will take 4 hours of being online to be back where you started in terms of validator balance.

For more information about downtime see our helper posts: