Guide détaillé de A à Z de mise en place d’un validateur sur Ethereum 2.

Prérequis et implications

Devenir un validateur sur Ethereum 2 n’est pas quelque chose à prendre à la légère. Vous allez devoir bloquer 32 ETH (ou plus), sans pouvoir les retirer pendant un certain moment, et devoir vous assurer que votre validateur continue à être actif sur toute cette période, sans quoi vous perdrez une partie de vos ETH placés.

De grands pouvoirs impliquent de grandes responsabilités

Avant de vous jeter à l’eau, assurez-vous de pouvoir répondre à l’affirmatif à ces questions:

  • Avez-vous 32 ETH ou plus à séquestrer pendant 3 ans ?
  • Pourrez-vous accorder du temps à vos validateurs pendant 3 ans (mettre à jour les logiciels, s’assurer que le validateur fonctionne etc…)
  • Avez-vous un minimum de connaissances en anglais (pour les mises à jour, les débats etc…)
  • Avez-vous accès à un interpreteur de commande (parfois appelé Terminal, ou Console de commande)
  • Avez-vous lu notre poste d’introduction à la preuve d’enjeu ?

Moins de 32 ETH ? Pas de panique !

Si vous n’avez pas 32 ETH, ou que vous ne vous sentez pas de devenir validateurs, vous pourrez toujours rejoindre des « staking pool« .

Prenez cependant le soin de vous renseigner sur les staking pool avant d’y séquestrer vos ETH ! Il y a beaucoup d’arnaques

Mise en place de la machine

Première étape : mettre en place une machine qui servira de validateur.

Deux options s’offrent à vous: vous pouvez utiliser une machine chez vous, ou bien un serveur hébergé ailleurs. Les deux ont leurs avantages et inconvénients : facilité d’accès, stabilité de la connexion à internet, taille du disque dur, confiance en l’hébergeur… je vous laisse faire votre choix. Dans ce guide, je vais utiliser un hébergeur (aucun lien d’affiliation, c’est juste celui que j’utilise personellement), afin de montrer cette étape aussi. Si vous avez déjà un ordinateur chez vous (ou votre serveur est déjà mis en place), vous pouvez procéder à l’étape « Mise en place des logiciels » directement !

Je peux perdre mes ETH ?!

Vous vous apprêtez à séquestrer au moins 32 ETH. Mais êtes-vous sûr de connaître les risques et les pénalités ? Plus de détail dans l’appendice en bas de la page.

Cette partie va vous montrer comment:

  • Louer un serveur chez un hébergeur (ici netcup.eu)
  • Configurer le pare-feu
  • Configurer les clés d’accès (ssh) et s’y connecter

Louer un serveur

Allez c’est parti ! Rendons-nous chez netcup.eu (ce guide n’est en aucun cas affilié ! C’est simplement l’option que j’utilise personellement).

Sélectionnez « Server », et cherchez l’option VPS 6000 G9.

Quelle offre choisir ?

Ce qui importe, c’est d’être sûr que le serveur tiendra la route en cas de perturbation sur le réseau. Aujourd’hui, il est recommandé d’avoir au moins 4 Cœurs, 16 GB de RAM, 256Gb de SSD, juste pour faire tourner le Beacon Node (plus d’info sur ce terme plus tard dans le tutoriel) et les validateurs.

Cependant, à ça il faut ajouter l’instance d’ETH1, qui nécessite elle-même 16Gb de RAM et 500 GB de SSD. Et si vous voulez, vous pouvez aussi lancer un slasher, ce qui prend des ressources supplémentaires.

L’option VPS 6000 est une option avec laquelle vous n’aurez pas de problèmes dans les années à venir. Elle a largement de quoi faire, et tiendra la route même en cas de conditions etrêmes sur le réseau. L’option VPS 4000 est correcte et devrait être suffisante. L’option VPS 3000 fera pile l’affaire pour le moment, mais il faudra s’attendre à devoir changer de plan d’ici 1 an ou deux. Enfin, si vous ne comptez pas lancer d’instance eth1 (si vous utilisez Infura par exemple), l’option VPS 2000 sera suffisante.

Si pour vous les termes eth1, Infura, beacon node et validateurs sont du charabia, vous pouvez allez lire le « Petit récapitulatif » dan « Mise en place des logiciels ».

Une fois votre offre sélectionnée, vous devrez procéder à la création de compte. Retenez bien les informations que vous entrez : une fois la demande effectuée, vous recevrez un appel de netcup.eu en anglais (ils sont allemands) et ils vous demanderont de bien confirmer : votre nom / prénom, votre adresse, votre code postale. C’est tout à fait normal (bien que déroutant je vous le concède !).

Une fois ces informations confirmées par téléphone, ils vous enverront vos identifiants de connexion par e-mail : les e-mails sont en allemand et en anglais, donc il faudra scroller jusqu’en bas pour trouver la version anglaise !

Connectons-nous d’abord à notre espace client. Comme écrit dans le mail, le lien est celui-là : https://www.customercontrolpanel.de . Vos identifiants figurent aussi dans le mail (en orange sur la photo).

La première étape à suivre est de sécuriser notre compte client mettant en place le 2FA : un méchanisme de sécurité qui vous demandera d’entrer un code fournit par votre téléphone lors de vos prochaines connexions. Pour ce faire, cliquez sur Master Data en bas à gauche.

Là vous pouvez cliquer sur le bouton « Enable two factor authentication ».

N’oubliez pas de sauvegarder votre clé au cas où vous seriez amené à perder votre téléphone

Bien maintenant que votre compte est sécurisé, vous pouvez procéder au règlement. La facture devrait être à peu près égale à trois fois le montant mensuel : pas de panique, cela suit une période de facturation trimestrielle.

Une fois le règlement effectué, vous devriez recevoir de nouvelles informations par e-mail : un e-mail intitulé « Access data for SCP » et un autre intitulé « Ihr vServer bei netcup ist bereit gestellt.

Access data for SCP

D’abord par mesure de sécurité, rendez-vous sur le servercontrolpanel (https://www.servercontrolpanel.de/SCP), connectez-vous avec les identifiants contenus dans le mail, et changez votre mot de passe (menu déroulant en haut à droite, puis Option).

Sur ce paneau de contrôle, vous avez accès à vos machines, et si vous cliquez sur l’une de vos machines, vous aurez un détail de l’utilisation de celle-ci.

Les curieux remarqueront que j’ai pris l’option VPS 4000… c’est pour le testnet !

Vous pouvez maintenant vous connecter à la machine !

Connexion à la machine

Fini la rigolade ! On passe aux choses sérieuses ! Pour ce faire, nous allons utiliser ssh ! ssh est un programme qui permet de se connecter de façon sécurisée à un serveur.

Pour l’utiliser, rien de plus simple : depuis le terminal de votre machine, tapez ceci (en remplaçant « adresseip » par l’adresse IP de votre propre machine, qui vous a été communiquée dans le deuxième e-mail)

ssh root@adresseip

Le mot de passe demandé est celui qui apparaît dans l’email que netcup vous a envoyé. Ensuite, vous devriez avoir un message vous signalant que l’authenticité de la machine ne peut pas être prouvée… c’est normal, tapez « yes » !

Si vous avez une erreur ici, c’est probablement que vous n’avez pas bien copié la clé grâce à ssh-copy-id. J’ai utilisé une clé ECDSA et non ed25519, c’est pourquoi votre message d’erreur ne sera pas exactement le même…

Première étape…. changer de mot de passe ! Et oui, sécurité, sécurité, sécurité !

Entrez simplement :

passwd

Et choisissez un mot de passe solide (différent des autres mot de passe que vous utilisez habituellement !)

Création d’un utilisateur

Nous sommes actuellement connecté en tant que l’utilisateur « root« . C’est en quelque sorte le superman de votre ordinateur : il a tous les droits. C’est une très mauvaise habitude, et un grand risque de sécurité d’être connecté en tant que root, c’est pourquoi nous allons créer un utilisateur !

La commande a entrer est celle-ci (en changeant utilisateur pour le nom d’utilisateur que vous désirez créer).

adduser utilisateur

Suivez les instructions du terminal (soyez sûrs de choisir un mot de passe solide !). Puis, ajoutez cet utilisateur à la liste des « sudoers » : c’est la liste des utilisateurs qui sont autorisés à effectuer des actions en tant qu’administrateur (parfois). Tapez la commande ci-dessous (en remplaçant utilisateur par votre nom d’utilisateur choisi, évidemment).

usermod -aG sudo utilisateur

Pour être sûr que cela fonctionne correctement, déconnectez-vous de la machine en tappant :

exit

Puis connectez-vous cette fois-ci en utilisant votre nom d’utilisateur :

ssh utilisateur@adresseip

Sécurisation de la machine

La sécurité, c’est important ! C’est pourquoi nous allons procéder à la mise en place de trois mesures de sécurité : l’authentification par clé, le changement de port SSH, et l’installation d’un pare-feu.

Je vais tenter d’expliquer simplement à quoi servent ces deux mesures.

  1. L’authentification par clé : pour vous connecter à votre machine vous avez utilisé un mot de passe. Mais si votre mot de passe se fait hack, ou bien si vous avez choisi un mot de passe trop fragile, un hacker pourra facilement se connecter à votre machine. C’est pourquoi nous allons utiliser l’authentification par clé : vous allez créer une clé SSH sur votre ordinateur, et c’est grâce à la présence de cette clé (et non le mot de passe) que vous serez autorisé à vous connecter.
  2. Changer le port SSH : Le port par défaut pour se connecter en SSH sur n’importe quelle machine est le 22. Cela veut dire qu’un hacker essaiera par défaut de vous attaquer par le port 22. En le changeant à un autre port, il sera obligé de deviner quel port vous avez choisi pour essayer de s’y connecter. Cela complique nettement la tâche !
  3. Installer un pare-feu : Par défaut, tous vos ports sont ouverts. Un attaquant peut donc essayer de vous attaquer sur beaucoup de ports différents. Un pare-feu résoud ce problème : il réduits les ports ouverts, et donc rend la surface d’attaque beaucoup plus petite.

Authentification par clé

Nous allons créer votre clé SSH qui vous servira à vous connecter au serveur. Commencez par vous déconnecter de votre serveur (exit). Ensuite, tappez cette commande :

ssh-keygen -t ed25519

Ensuite suivez les instructions sur votre console. Une fois terminé, il vous faudra ajouter cette clé à la liste des clés autorisées par votre serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisatur@adresseip

Et voilà le travail ! Votre clé apparaît désormais parmi les clés autorisées sur votre serveur. Cependant, le serveur autorise toujours à se connecter en fournissant le mot de passe de l’utilisateur : nous allons modifierons cela quand nous effectuerons le changement de port SSH.

Changer de port SSH

Commençons par mettre à jour notre système.. Je ne vais pas détailler ces commandes mais en gros, elles mettent à jour le système, retirent les logiciels dont on ne se sert pas et installent UFW 🙂

Sudo et privilèges d’administrateur

Nous avons créé un utilisateur qui n’est pas root car c’est risqué de lancer toutes les commandes en tant qu’administrateur. Cependant, de temps en temps nous avons besoin de lancer des commandes en tant qu’administrateur. La solution : ajouter « sudo » au début de la commande que nous lançons. Il se peut que lancer sudo vous demande votre mot de passe : c’est tout à fait normal !

sudo apt update && sudo apt upgrade
 sudo apt dist-upgrade && sudo apt autoremove
 sudo apt install -y ufw

Maintenant nous pouvons changer le port SSH. Vous n’avez qu’à choisir un numéro de port entre 1024 et 49151, et vous assurez qu’il ne sort pas en rouge lorsque vous tapez cette commande (en remplaçant numerodeport par le numéro de port que vous avez choisi) :

sudo ss -tulpn | grep numerodeport

S’il sort en rouge, c’est qu’il est déjà utilisé par votre ordinateur. Choisissez en un nouveau et recommencez !

Ensuite, mettez à jour votre fichier de configuration SSH. Lancez l’editeur de nexte nano:

sudo nano /etc/ssh/sshd_config

Ici vous aurez 4 lignes à modifier :

  • Remplacer la ligne « Port 22 » par « Port NUMERODEPORT » en remplaçant NUMERODEPORT par le numéro que vous avez choisi (spécifie le port utilisé pour SSH).
  • Enlever le « # » devant la ligne « #PubkeyAuthentication yes » (spécifie que nous acceptons la conneixon par clé).
  • Remplacer la ligne « PasswordAuthentication yes » par « Password authentication no » (spécifie que nous voulons désactiver la connexion par mot de passe).
  • Remplacer la ligne « PermitRootLogin yes » par « PermitRootLogin no » (spécifie que nous voulons interdire de se connecter en tant que root).

Appuyez ensuite sur CTRL+o (la touche contrôle et la touche o en même temps), puis Entrer, puis CTRL+x (la touche contrôle et la touche x en même temps). C’est la suite à tapper si l’on veut enregistrer un fichier et le fermer avec Nano.

Voici un GIF du déroulé de l’opération (avec comme exemple de port 39889).

Maintenant, nous pouvons redémarrer le service SSH. Il suffit d’entrer cette commande :

sudo systemctl restart ssh

Attention, à compter de maintenant, pour vous connecter au serveur, la commande ne sera plus « ssh utilisateur@ip » mais « ssh -p NUMERODEPORT utilisateur @ip ».

Se connecter via l’interface Netcup.eu

Si vous vous retrouvez dans un cas ou vous ne parvenez plus à vous connecter à la machine en SSH, sachez que vous pouvez toujours vous reconnecter en passant par l’interface de de netcup.eu .

Plus d’information en bas de la page dans l’appendice.

Pour vous déconnecter, tapez:

exit

Puis reconnectez-vous :

ssh -p numerodeport utilisateur@adresseip

Installation du pare-feu

Maintenant faisons en sorte de rejeter les connexions par défaut :

sudo ufw default deny incoming

Acceptons les connections sur notre port SSH choisi :

sudo ufw allow numerodeportssh/tcp

Puisque nous allons utiliser Geth et Lighthouse, nous allons ouvrir les ports 30303 et 9000 (respectivement)

sudo ufw allow 30303
 sudo ufw allow 9000

Mettons maintenant en marche ces pare-feu :

sudo ufw enable

Maintenant, en tapant « sudo ufw status verbose« , vous devriez avoir un rendu similaire (mon port choisi pour SSH est le 38998) :

Et voilà ! Votre machine est désormais installée et sécurisée. Nous pouvons passer à la prochaine étape : créer les clés des validateurs.

Créer les clés de validateurs

Mainnet vs Testnet

Ce guide détail les étapes nécessaires pour la mise en place d’un validateur sur le « mainnet », c’est-à-dire le résau officiel Ethereum 2. Il existe cependant des « testnet », c’est-à-dire des réseaux qui permettent de tester, sans mettre en jeu des « vrais » ETH. Je vous recommande d’abord d’essayer d’installer et de lancer correctement un validateur sur un testnet. Pour ce faire, il suffit de remplacer « mainnet » par le nom du testnet (au moment de l’écriture, « pyrmont »).

Une fois le validateur ayant été correctement lancé sur le testnet, vous pourrez passer au mainnet !

Rendez-visite à ce site : https://github.com/ethereum/eth2.0-deposit-cli/releases/ et trouvez la version du logiciel pour linux : elle devrait se terminer par « linux-amd64.tar.gz« .

Voici à quoi elle ressemble au jour de création de ce guide :

Ensuite copiez-en le lien :

Maintenant, reprenez le terminal et tapez ces commandes (en remplaçant le lien « https:// » par le contenu de votre presse-papier (le lien que vous avez copié lors de l’étape précédente)).

cd ~
 sudo apt install -y curl
 curl -LO https://github.com/ethereum/eth2.0-deposit-cli/releases/download/v1.1.0/eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz

Vous venez de télécharger la version compressée du logiciel qui va vous servir à créer les clés de vos validateurs. Pour le décompresser, il vous suffit de taper :

tar xvf eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz
 rm -rf eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz
 cd eth2deposit-cli-ed5a6d3-linux-amd64

Les noms des fichiers pourraient différer sur votre machine : ici c’est eth2deposit-cli-ed5q6d3 car c’est la version actuelle, mais elle pourrait changer dans le futur. Pour l’afficher, lancez simplement la commande ls.

Vous pouvez maintenant créer vos clés ! Entrez cette commande (en changeant nombredevalidateurs par le nombre de validateurs que vous comptez lancer) :

./deposit new-mnemonic --num_validators nombredevalidateurs --mnemonic_language=english --chain mainnet

Prenez votre temps ! Gardez vos secrets au chaud…

Prenez le temps de bien vérifier la commande que vous venez de taper. Avez-vous bien remplacé le NOMBREDEVALIDATEURS par le nombre de validateurs que vous comptez lancer ? Avez vous bien bien écrit « mainnet » ?

Dans cette commande, vous allez devoir noter vos mots de passe. Je vous recommande de les écrire sur un bout de papier, d’en faire une deuxième copie et garder les deux copies dans deux endroits différents.

Personne ne pourra vous sauver si vous oubliez vos mot de passe ou vos mnemonics : c’est donc d’une importance capitale pour vous de vous appliquer pendant cette opération.

Première étape : créer un mot de passe. Choisissez-en un (de préférence au hasard), de bonne qualité, et notez le sur le bout de papier. Ensuite lisez le bout de papier, et tapez-le ici. Soyez sûrs que ça correspond à ce que vous avez noté sur le bout de papier !

Ensuite vous verrez apparaître une liste de mots : c’est ce que l’on appelle votre mnemonic. Notez-le précieusement, en faisant bien attention à l’orthographe des mots (ils sont en anglais, attention aux faux amis!).

J’ai bien évidemment pris le soin d’utiliser un autre mnnemonic que celui-ci…

Vous devrez ensuite entrer, dans l’ordre, le mnemonic (suite de mots) que vous venez de noter. Soyez sûrs de taper ce que vous avez écrit sur votre papier !

Si vous tapez la commande ls, vous devriez avoir le même rendu :

Dans le dossier validator_keys se trouvent plusieurs fichier : un fichier deposit_data…json, et autant de keystore-m…json que vous avez entré de numéro de validateurs. Le fichier deposit_data est un fichier unique qui contient des informations nécessaires pour pouvoir déposer des ETH pour staker : les fichier keystore-m sont des fichiers représentants vos clés de validateur. Ils seront utilisés par la suite !

Vous avez créé vos clé de validateur (ainsi que le fichier de deposit associé, nous y reviendrons plus tard). Maintenant il est temps d’installer les logiciels !

Mise en place des logiciels

Troisième étape: mettre en place les logiciels nécessaires au staking.
Ces instructions sont écrites pour Ubuntu (Linux). Si vous utilisez une autre machine, il faudra probablement adapter quelques commandes !

Petit récapitulatif

Il y a trois logiciels principaux qui vont être exécutés par votre machine:

  • Le client Ethereum 1 : Oui, cela peut paraître étonnant mais la chaîne Ethereum 2 a besoin de connaître l’état de la chaîne Ethereum 1 afin de fonctionner correctement.
  • Le Beacon Node (BN) : C’est le logiciel qui s’occupe de communiquer avec les autres nœuds du réseau, de la gestion de la base de donnée de la chaîne: bref c’est lui qui fait le gros du travail.
  • Le Validator Client (VC) : C’est le fameux « validateur » qui revient à toutes les sauces. C’est un logiciel relativement simple, qui ne s’occupe de faire qu’une seule chose: signer des transactions. Périodiquement, il doit signer des transactions, grâce à sa clé privée (clé qui doit rester secrète, bien cachée sur l’ordinateur). Il demande au BN quels messages il doit signer, s’assure que les informations renvoyées par le BN sont correctes, puis signe le message et le transmet au BN, qui lui le transmettra aux autres nœuds du réseau.

Ce qui est intéressant, c’est que plusieurs VC peuvent se connecter au même BN: en effet, on peut faire tourner des centaines de validateurs, qui se connectent tous au même BN. Un VC ne consomme pas beaucoup (rappelez-vous, c’est le BN qui fait la majorité du travail), en lancer plusieurs sur la même machine permet donc d’augmenter un peu la rentabilité.

Une question devrait vous traverser l’esprit : est-il possible de connecter son VC a un BN sur une autre machine ? La réponse est oui ! Vous pourriez très bien connecter vos VCs au BN d’un ami, ou d’une entreprise, si vous leur faites confiance. Vous n’êtes donc pas OBLIGE de faire tourner un BN, si vous faites confiance à un autre BN. Attention cependant : si le BN dans lequel vous avez confiance se met à mal agir (se déconnecter, être piraté…), vous pourriez en faire les frais ! C’est pourquoi il est recommandé de faire tourner son propre BN.

Le paragraphe précédent s’applique tout aussi bien au nœud Ethereum 1 que vous devez lancer: vous pouvez décider de ne pas en lancer, et de vous remettre à un ami / une entreprise (par exemple Infura). Cependant, comme pour le BN, c’est déconseillé, car on n’est jamais mieux servi que par soi-même !

Machine peu performante

Si votre machine est peu performante, une solution pourrait être de ne pas lancer geth et d’utiliser un autre accès à la chaîne Eth 1.

Un des services les plus connus est Infura. Un tutoriel est disponible dans l’appendix afin d’en savoir plus. Cependant, comme écrit just au-dessus, il est FORTEMENT recommandé de lancer son propre client Ethereum 1 🙂

Les clients

Il y a plusieurs implémentations de clients pour Ethereum 2 : les plus connus sont Lighthouse, Prysm, Teku, et Nimbus. Chaque client a ses spécificités (que ce soit l’équipe derrière, l’histoire, les buts recherchés, le langage utilisé, les caractéristiques techniques, la communauté etc…). Dans cet article, nous allons utiliser l’implémentation Lighthouse, de l’équipe Sigma Prime.

Client Ethereum 1

De la même manière que différent clients Ethereum 2 existent, il existe aussi plusieurs implémentations de client Ethereum 1. Les plus connus sont geth et openethereum (anciennement parity-ethereum). Dans ce tutoriel, j’utiliserai geth et parlerai de geth mais ce qu’il faut comprendre c’est « client Ethereum 1 ».

Nous avons deux possibilités pour lancer notre client :

  1. Classique : Nous téléchargeons les code source des clients, nous les compilons (ou téléchargeons directement le binaire), puis nous lançons les logiciels un par un (geth, BN et VC). Cette technique est standarde, fonctionne correctement et permet de personnaliser des paramètres.
  2. Docker-compose : C’est une technique qui repose sur l’utilisation d’un logiciel (docker-compose) qui fera tout ça à notre place. Voyez-ça comme un logiciel qui gère les autres logiciels : nous lui disons simplement « lance-moi une instance de geth, un BN, un VC, et connecte-les ensemble), et tada, le tour est joué !

J’ai personellement opté pour l’utilisation de docker-compose : ça rend la tâche très simple à utiliser, installer, et mettre à jour.

Docker et Docker-Compose

Afin de nous faciliter la tâche, nous allons utiliser un logiciel qui s’occupera de lancer les autres logiciels à notre place. Je vous présente : Docker !

Pour installer Docker sur Ubuntu, c’est tout simple :

sudo apt install -y docker.io

Assurons-nous que Docker a bien été installé en lançant cette commande en la comparant au screenshot en-dessous.

sudo docker run hello-world

Si cette commande ne fonctionne pas, c’est probablement que docker n’a pas été correctement installé. Dans ce cas, veuillez suivre les instructions d’installations officielles.

Profitons-en pour aussi installer Docker-Compose

sudo apt install -y docker-compose

Maintenant que nous avons installé le logiciel docker-compose, il ne nous reste plus qu’à lui dire ce que nous voulons lui faire faire (lancer geth, un BN et un VC). Ca tombe bien : l’équipe de lighthouse a un dossier avec tout de déjà préparé !

Assurons-nous d’abord d’être dans le bon répertoire :

cd ~

Puis téléchargeons le dossier de configuration

git clone https://github.com/sigp/lighthouse-docker/

La commande ls (qui liste les fichier du répertoire) devrait ressembler à cela maintenant :

Allez maintenant éditer le fichier de configuration. Déplacez-vous dans le bon répertoire :

cd lighthouse-docker

Faites une copie du fichier de configuration :

cp default.env .env

Et allez éditer le fichier de configuration : (n’oubliez pas, pour quitter c’est CTRL+O, Enter, CTRL+X)

nano .env

Voici la liste des paramètres à éditer. Si le paramètre n’apparaît pas dans cette liste, c’est qu’il doit être laissé à sa valeur par défaut. Attention, si vous voulez vous mettre sur le réseau de test, alors le paramètre NETWORK ne sera pas mainnet mais le nom du testnet (par exemple pyrmont).

NETWORK=mainnet
 START_VALIDATOR=YES
 VALIDATOR_COUNT=2
 START_GETH=YES
 ENABLE_METRICS=YES

Bien entendu je vous laisse éditer VALIDATOR_COUNT pour être égal au nombre de validateurs que vous avez choisi de créer.

Si vous avez une machine puissante, vous pouvez aussi mettre SLASHER=YES afin de mettre en route un slasher.

Maintenant notre fichier de configuraiton prêt, nous devons importer les validateurs. Pour ce faire, copiez d’abord les clés de validateurs dans le fichier courant.

cp -r ../eth2deposit-cli-ed5a6d3-linux-amd64/validator_keys/ .

Bien entendu il se peut que le nom de votre dossier varie : comme précisé au-dessus le mien est eth2deposit-cli-ed5a6d3-linux-amd64 mais je vous laisse adapter la commande à votre machine.

Puis initialisez les clés grâce à cette commande :

sudo docker run -it -v $(pwd)/lighthouse-data:/root/.lighthouse -v $(pwd)/validator_keys:/root/validator_keys sigp/lighthouse lighthouse --network mainnet account validator import --directory /root/validator_keys

Nous sommes fin prêts ! Nous allons ouvrir un gestionnaire de fenêtre, afin de conserver notre fenêtre ouverte (plus d’info dans l’encart juste en-dessous).
D’abord installons tmux :

sudo apt install -y tmux

Puis lançons-le !

tmux

Et maintenant, la commande finale :

sudo docker-compose up

Et voilà ! Vous devriez voir plein de messages fuser dans tous les sens. Ces messages sont des « logs », c’est-à-dire des messages qui décrivent le statut des différents logiciels (rappelez-vous, geth, BN et VC) qui tournent.

En bleu les messages émis par le BN, en jaune les messages de geth, et ne vert les messages des VC.

Si ces logs ne vous conviennent pas et vous voulez isoler seulement les logs du BN ou du VC, tappez :

sudo docker container ls --format '{{.Names}}'

Vous devriez avoir cela en sorite (peut-être deux lignes en plus si vous avez déjà lancé grafana / prometheus).

Pour suivre seulement les logs du validateurs par exemple :

sudo docker logs lighthouse-docker_validator_client_1 --follow

Et pour suivre le BN :

sudo docker logs lighthouse-docker_beacon_node_1

Ces commandes est lançable même si vous n’êtes pas dans tmux, et vous pouvez les quitter à tout moment en appuyant sur CTRL+c .

tmux

Nous avons lancé les logiciels à l’aide d’un gestionnaire de fenêtre (appelé tmux). Il permet aux logiciels de continuer à tourner en tâche de fond. Pour vous détacher de cette fenêtre et la laisser tourner en tâche de fond, il vous suffit d’appuyer sur CTRL+b puis la lettre d.

A chaque fois que vous voudrez retrouver vos logiciels (pour les arrêter, ou les mettre à jour etc), il suffira de tapper tmux a. Vous pourrez donc faire des aller-retours jusqu’à vos logiciels grâce à ce gestionnaire de fenêtre.

Vous pouvez quitter cet écran en appuyant sur CTRL+b puis d. Cela « détache » l’écran tmux et vous renvoie vers l’écran de départ. Les logiciels continuer donc de tourner en tâche de fond. Pour retourner sur l’écran de tmux, tappez :

tmux a

Si vous voulez arrêter complètement les logiciels : appuyez sur CTRL+c, puis entrez :

sudo docker-compose down

Mettre à jour

En tant que validateur sur le réseau, vous avez comme devoir de tenir vos logiciels à jour. Un tutoriel sur comment le faire est disponible dans l’appendix, en bas de la page 🙂

Maintenant que nous avons nos logiciels qui tournent, il ne nous reste plus qu’une étape : effectuer le(s) dépôt(s) d’ETH sur le réseau ! Rendez-vous sur le site officiel : https://launchpad.ethereum.org/overview (vous pouvez préfixer le nom du testnet désiré, par exemple : https://pyrmont.launchpad.ethereum.org/overview pour le testnet de pyrmont).

Lisez attentivement les 10 étapes (un récapitulatif ne fais jamais de mal), et vous devriez arriver sur cette page:

Vous pouvez choisir les logiciels que l’on utilise : geth, puis Lighthouse

Maintenant indiquez le nombre de validateurs que vous voulez lancer (dans mon cas, 2)

Puis cochez la case qui certifie que vous avez copié vos mnemoniques et votre mot de passe, et cliquez sur Continue.

Sur la page suivante, vous allez uploader votre fichier deposit_data dont on a parlé à tout à l’heure. Mais comment faire ? Le fichier se trouve sur mon serveur, pas du mon ordinateur ! Pas de panique ! J’ai la solution : scp !

scp est un programme qui permet de copier des fichiers depuis un serveur vers votre ordinateur (ou dans l’autre sens) de façon sécurisé.

D’abord créons un dossier pour stocker nos fichiers :

cd ~
 mkdir validateurs
 cd validateurs

Sur votre terminal, déconnectez-vous de votre machine (tapez exit), puis entrez simplement (en remplacant, comme d’habitude…) :

scp -r -P numerodeport utilisateur@adresseip:lighthouse-docker/validator_keys .

Et voilà le travail ! Vous devriez maintenant pouvoir cliquer sur le gros bouton + présent sur la page, et aller chercher le fichier deposit_data qui se trouve dans le dossier validateurs, dans votre répertoire d’utilisateur (home directory).

Maintenant vous devriez pouvoir uploader le fichier deposit_data :

Et vous devriez voir cet écran ! (si vous ne vous êtes pas trompés de réseau !)

Maintenant il faut faire le dépôt. Je vous laisse suivre le tutoriel d’installation de Metamask (vous pouvez y connecter votre Ledger si jamais c’est cela que vous utilisez)

Obtenir du gETH

Si vous vous apprêtez à faire un dépôt sur un testnet, la monnaie utilisée n’est pas l’ETH mais le gETH (görli-ETH). Il peut s’obtenir via des faucets, ou en rejoignant le Discord d’EthStaker.

Attention : je suis ici sur pyrmont.launchpad.ethereum.org car j’ai fait ce tutoriel sur le testnet de pyrmont. Si vous voulez déposer sur le mainnet, il faut être sûr dêtre sur launchpad.ethereum.org !

Une fois Metamask installé, soyez sûrs d’être sur la bonne chaîne : Ethereum Mainnet pour un dépôt sur le mainnet, et Goerli pour un dépôt sur un testnet.

Vous n’avez plus qu’à lancer la transaction… et tada ! Votre dépôt aura été effectué ! Vous pouvez désormais suivre l’état de vos validateurs : dans metamask, cliquez sur la transaction que vous venez d’effectuer.

Dépôt sur le testnet Pyrmont

Puis cliquez sur la flèche qui vous mènera à l’explorateur de block :

Et ici vous pouvez voir les clés publique associées ! Vous pouvez consulter l’état de votre validateur en cliquant dessus.

Ici nous utilisons le site beaconscan. Un autre explorateur connu est beaconcha.in. Dans cette photo, mon dépôt n’a pas encore été inclus : en effet, une votre dépôt effectué, il faut du temps afin qu’il soit « inclus » et que votre validateur apparaisse dans la liste « officielle » des validateurs. Plus d’info sur ce procédé.

Monitoring

Cette partie est optionelle : il s’agit de mettre en place un système de monitoring (afin de garder un oeil sur sa machine !). Nous allons utiliser Grafana et Prometheus : Prometheus va se charger de récupérer des données de nos logiciels (mémoire utilisée etc), et Grafana se chargera de les afficher.

Encore une fois, docker va nous sauver ! Nous allons cloner le repo lighthouse-metrics qui a déjà tout de préparé pour nous :

cd ~
 git clone https://github.com/sigp/lighthouse-metrics
 cd lighthouse-metrics

Ensuite, nous allons lancer grafana et prometheus grâce à la commande… docker-compose ! Notez l’utilisation de -d, qui permet de le lancer en tâche de fond.

sudo docker-compose up -d

Maintenant nous pouvons passer à la dernière étape : visualiser les données ! Déconnectez-vous du serveur (tappez exit), et tappez la commande suivante (en remplacant, comme d’habitude):

ssh -p numerodeport -L 127.0.0.1:3000:127.0.0.1:3000 utillisateur@adresseip

Et maintenant, sur votre navigateur, tapez cette URL : localhost:3000 ! Vous devriez arriver sur un panneau de configuration ! Le nom d’utilisateur est admin et le mot de passe changeme. Ensuite, vous devrez cliquer sur le bouton Manage

Puis cliquez sur le bouton Import

Maintenant vous devez visiter cette page et en copier le contenu, et le coller le contenu dans la box « Import panel via JSON »

Puis cliquez sur Load et Import et… tada !!

C’est un panneau de monitoring global, il vous est bien sûr possible de modifier et l’adapter à vore convenance !

Aller plus loin

Des améliorations sont toujours possibles ! Vous pourriez créer des services qui se relancent automatiquement, avoir un système de sauvegarde, avoir un meilleur système de logging… cependant ce guide n’est là que pour couvrir les bases. Il ne faut vraiment pas hésiter à aller chercher de l’aide et poser des questions, voici donc quelques recommandations de site / communautés qui pourraient vous intéresser :

https://reddit.com/r/ethstaker/ : Le subreddit d’une communauté de staker (je vous recommande de rejoindre le Discord, c’est un des meilleurs endroits pour poser des questions)
https://reddit.com/r/ethereum : Le subreddit officiel d’Ethereum
https://lighthouse-book.sigmaprime.io/ : La documentation officielle de Lighthouse
https://docs.prylabs.network/docs/getting-started/ : La documentation officielle de Prysm
https://docs.teku.consensys.net/en/latest/ : La documentation officielle de Teku
https://status-im.github.io/nimbus-eth2/ : La documentation officielle de Nimbus

Pour se renseigner sur le protocole en général il y a bien entendu :
– La spécification officielle : https://github.com/ethereum/eth2.0-specs
– Cet article que j’ai particulièrement apprécié : https://ethos.dev/beacon-chain/
– Les spécifications commentées de Vitalik et de Ben Edgington

Appendice

Détails sur les pénalités

Base de données des Slashings

Une des règles du réseau est qu’un validateur ne doit jamais publier deux messages conflictuels pour un même block. Pour être sûr qu’il ne publie jamais de messages conflictuels, un validateur tient à jour une base de donnée de tous les messages qu’il a envoyé. Cette base de donnée (souvent appellée slashing protection database, et située dans ~/lighthouse-docker/lighthouse-data) est TRES importante, car si vous la perdez, votre validateur pourrait bien publier deux messages conflictuels et se faire pénaliser !

Il est donc recommandé d’en faire une sauvegarde régulièrement ! Et si vous la perdez, il est recommandé d’attendre plusieurs heures avant de relancer votre validateur, afin de réduire les chances qu’il produise des messages conflictuels.

Il y a deux grosses catégories de pénalités que vous pourriez encourir :

  1. Slashing : une grosse partie de vos ETH sont retirés instantanément, et votre validateur se fait exclure (il ne peut plus staker). Cela pourrait se produire si vous lancez deux fois le même validateur, ou si vous utillisez une version malicieuse d’un client. Cela pourrait aussi se produire dans le cas ou vous perdez votre base de donnée de protection (voir l’encart juste au-desus).
  2. Leaking : C’est le fait d’avoir une « fuite » d’ETH dû à une absence. Si votre validateur n’est pas en ligne, il subit des pertes. Ces pertes sont proportionelles au nombre de validateurs qui sont hors-ligne en même temps que vous. Si vous êtes tout seul, les pénalités sont minimes (de l’ordre de 0.3% par semaine, ce qui vous laisse LARGEMENT le temps de revenir en ligne), mais si la moitié du réseau en hors-ligne en même temps, alors les pénalités augmentent très rapidement. Il y a donc un risque à avoir votre machine chez un hébergeur type AWS ou netcup.eu : s’ils tombent en panne, vous ne serez pas le seul à être hors-ligne et encourerez donc des peines plus élevées…

Se connecter via l’interface de Netcup.eu

Rendez-vous sur le servercontrolpanel et cliquez sur votre machine. Ensuite cliquez sur la « Console » en haut à droite de l’écran (entouré en rouge sur la photo).

Une fenêtre pop-up devrait s’ouvrir (si elle ne s’ouvre pas vérifiez les paramètres de votre navigateur). Ici, il vous suffit de vous connecter en entrant d’abord le nom d’utilisateur, puis le mot de passe de votre utilisateur. Si vous n’avez pas encore d’utilisateur, utilisez les identifiants de root.

Cela vous donne accès à un shell classique : à vous de résoudre les problèmes afin de pouvoir vous reconnecter depuis votre interprêteur ! (Probablement un problème de port SSH / pare-feu…)

Infura et autres ETH1 endpoints

Si votre machine est peu performante, une solution possible est d’utiliser un « fournisseur » d’accès à ETH1 plutôt que de faire tourner votre propre instance de geth. C’est plus risqué (car vous devez faire confiance à votre fournisseur plutôt que de lancer un client par vous-même), mais cela devrait réduire les ressouces utilisées par votre machine.

Infura

Je vais ici donner un exemple de mise en place avec Infura. Si vous avez déjà votre fournisseur d’accès à Ethereum 1, vous pouvez passer cette étape.

Rendez-vous sur le site infura.io et créez un nouveau compte.

Une fois votre compte créé, cliquer sur l’onglet Ethereum dans la barre de gauche.

Créez ensuite un nouveau projet en cliquant sur « Create New Project » (il se peut que l’interface soit différente si c’est votre premier projet)

Ensuite cliquez sur votre projet et allez dans l’onglet Settings.

En bas de la page vous trouverez les informations qui nous intéressent : le menu déroulant vous permet de choisir le réseau (mainnet pour le réseau officiel, Görli pour les testnets). Puis vous pouvez copier l’URL (entouré en rouge) qui vous servira dans l’étape suivante.

Modifications à apporter

Grâce à docker-compose, cette modification est un réel jeu d’enfant : il n’y a que deux lignes à modifier !

nano .env

Ensuite les deux lignes à modifier sont : START_GETH qui doit être vide, et VOTING_ETH1_NODES qui doit être mis à l’URL du fournisseur d’accès à ETH1 (celui que vous avez copié si vous avez suivi le tutoriel Infura).

START_GETH=
 VOTING_ETH1_NODES=urldufournisseur

Les autres paramètres sont à laisser comme dans décrit plus haut dans le guide.

Et voilà le travail ! Maintenant lorsque vous lancerez vos logiciels (sudo docker-compose up), vous passerez par votre fournisseur plutôt que par geth ! Vous pouvez donc supprimer le dossier geth maintenant pour libérer de la place sur votre machine :

sudo rm -rf ~/lighthouse-docker/geth-data

Migrer vos validateurs

La migration de validateurs d’un serveur à un autre est une opération facile mais qui nécessite une attention particulière. Le dossier important à copier se trouve dans lighthouse-data/mainnet/validators (ou /testnet/ si sur testnet).

Attention, cette migration ne sert que si vous changez de machine mais comptez utiliser le meme client (Lighthouse). En attendant l’EIP-3076, changer de client n’est PAS recommandé.

De plus nous copierons aussi le dossier secret afin d’éviter de devoir importer les validateurs de nouveau.

Ok première étape : s’assurer que nos validateurs sont éteints. Pour ça :

tmux a

Puis CTRL+c et ensuite

sudo docker-compose down

Sont-ils vraiment éteints ?

Pour vous assurer que vos validateurs sont éteints, vous pouvez entrer la commande sudo docker container ls --format {{.Names}} et vérifier que rien la sortie de cette commande est vide (ou au moins qu’elle ne contient pas « validator_client ».

Nous allons devoir autoriser la connexion en tant que root. Oui c’est une mauvaise pratique, et nous ne le ferons que temporairement, car les fichiers qui se trouvent dans validators appartiennent à root.

Pour ce faire, il faut aller éditer le fichier /etc/ssh/sshd_config et changer la ligne « PermitRootLogin no » en « PermitRootLogin yes« . Pour que cette modification ait lieu, il faut ensuite redémarrer le service ssh : sudo systemctl restart ssh.

Maintenant vous pouvez vous déconnecter de la machine (exit), et vous déplacer dans le dossier Validateurs que nous avions créé précédemment.

cd ~/validateurs

De là il ne nous reste plus qu’à copier le dossiers validators ainsi que les dossiers secrets et wallets (les derniers ne sont pas nécessaires mais ils son pratiques). Bien sûr il vous faut remplacer numerodeportssh, utilisateur, et adresseip (et mainnet si vous utilisez un testnet).

scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/validators .
scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/secrets .
scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/wallets .

Une fois cette opération effectuée, vous pouvez retourner sur le serveur et retirer le login en tant que root (PermitRootLogin).

Maintenant il faut faire le chemin inverse : c’est à dire envoyer vos dossiers validators et secrets sur votre nouvelle machine, dans le bon répertoire. Je pars du principe ici que la nouvelle machine est déjà crée, et que vous avez déjà cloné les repo lighthouse-docker (que vous avez suivi ce tuto quoi !). Assurez-vous aussi que PermitRootLogin est mis sur yes. La manipulation est simple :

scp -r -P numerodeportssh validators root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/validators
scp -r -P numerodeportssh wallets utilisateur@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/wallets
scp -r -P numerodeportssh secrets utilisateur@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/secrets

Enfin nous allons copier le dossier validator_keys afin qu’il soit sur notre serveur aussi :

scp -r -P numerodeport ~/validateurs/validator_keys utilisateur@adresseip:lighthouse-docker/validator_keys

Et voilà ! Le tour est joué ! Vous pouvez commencer à valider sur cette nouvelle machine ! Assurez-vous de bien avoir remis PermitRootLogin no, et assurez-vous de bien avoir éteint votre ancienne machine !

Mettre à jour les logiciels

Eh oui, en tant que validateur sur le réseau, il vous faudra vous assurer d’être à jour !

D’abord éteindre grafana et prometheus :

cd ~/lighthouse-metrics
 sudo docker-compose down

Puis éteindre le BN, geth et les VC en attachant tmux

tmux a

Puis en l’interrompant (CTRL+c), puis en le stoppant :

sudo docker-compose down

Quittez votre session tmux en appuyant sur CTRL+d.

Maintenant vous pouvez mettre à jour les paquets :

sudo apt update && sudo apt upgrade

Puis mettre à jour les logiciels :

cd ~/lighthouse-metrics && git checkout . && git pull origin stable && sudo docker-compose pull
 cd ~/lighthouse-docker && git checkout . && git pull && sudo docker-compose pull

Maintenant il faut retourner à l’étape de création du fichier .env (en haut de cette page !), puis vous pourrez relancer les logiciels : d’abord tmux, puis sudo docker-compose up, puis CTRL+b, puis d, ensuite cd ~/lighthouse-metrics, puis sudo docker-compose up -d !

Commentaires

Commentaires

  1. Mage
    24 novembre 2020 - 19h46

    Le screenshot metamask est branché sur pyrmont, gaf a envoyer les eth de test et pas les vrai eth si c est sur pyrmont nan?

    Répondre
      Scott Piriou
      25 novembre 2020 - 09h58

      Modification faite ! Merci 🙂

      Répondre
  2. Sin
    25 novembre 2020 - 09h29

    Merci beaucoup pour ce super Guide !
    Est-ce possible d’ajouter des explications sur la config d’ Infura pour le client eth1 dans le cas ou la machine ne pourrait pas supporter le client eth1 LightHouse?

    Répondre
      Scott Piriou
      25 novembre 2020 - 11h50

      C’est fait ! 🙂

      Répondre
        Sin
        25 novembre 2020 - 11h52

        Waouw!
        Merci!!!

        Répondre
    larco
    26 novembre 2020 - 16h38

    Bonjour,
    Au moment d’exécuter « sudo docker-compose up » j’ai ceci
    Attaching to lighthouse-docker_geth_1, lighthouse-docker_beacon_node_1, lighthouse-docker_validator_client_1
    beacon_node_1 | error: Found argument ‘–testnet’ which wasn’t expected, or isn’t valid in this context
    beacon_node_1 | Did you mean –testnet-dir?
    Le fichier defaut contient bien ceci: TESTNET=mainnet
    Aurais-je oublié qqchose?
    Merci

    Répondre
      Scott Piriou
      26 novembre 2020 - 18h32

      Non tu as bien suivi le guide… le problème vient du fait qu’une mise à jour a eu lieu cette nuit sur lighthouse et le repo n’a pas eu le temps de s’updater encore.
      La PR associée est celle-ci : https://github.com/sigp/lighthouse-docker/pull/42/files .
      Lorsqu’elle sera merged (c’est-à-dire ajoutée au code) alors il faudra changer le flag TESTNET=mainnet en NETWORK=mainnet .
      Je pense que la situation devrait être réglée demain (27 Nov.). 🙂

      Répondre
        larco
        26 novembre 2020 - 18h58

        Merci pour la réponse! Concrètement je dois faire les modif à la main, retélécharger les fichier ou bien cela se mettra à jour automatiquement?
        Merci et bonne soirée

        Répondre
          Scott Piriou
          26 novembre 2020 - 19h02

          Concrètement il suffira de lancer se rendre dans le dossier lighthouse-docker (cd ~/lighthouse-docker), nettoyer en tapant git checkout ., puis mettre a jour en tapant git pull, puis il faudra refaire les etapes de creation du fichier .env 😀

          Répondre
            Tacis
            27 novembre 2020 - 10h39

            On attend avec impatience la modification 🙂

            Répondre
            Scott Piriou
            28 novembre 2020 - 15h14

            C’est bon 🙂 Le guide a aussi été mis à jour, tout devrait fonctionner 🙂

            Répondre
    larco
    28 novembre 2020 - 16h09

    Bonjour,
    Merci!!! Cela à l’air ok, enfin je suppose si j’ai ces messages et que je suis en v1.0.1 🙂
    beacon_node_1 | Nov 28 13:59:06.061 INFO Waiting for genesis wait_time: 2 days 22 hrs, peers: 24, service: slot_notifier
    validator_client_1 | Nov 28 13:59:07.516 INFO Waiting for genesis seconds_to_wait: 252075, bn_staking_enabled: true

    Répondre
      Scott Piriou
      28 novembre 2020 - 17h11

      il semblerait que tu sois en place 🙂 encore une fois je conseille vivement d’abord de s’habituer au testnet ! 🙂

      Répondre
    Francky
    30 novembre 2020 - 17h45

    Hello Scott,
    Merci beaucoup pour ce guide très clair et très intéressant !
    J’ai 2 questions :
    – Sur beaconcha.in, j’ai mon deposit qui est toujours « pending » alors qu’il a été fait il y a bientôt 24h, normal ?
    – Par ailleurs, je fais tourner geth & LightHouse sur mon VPS mais je l’ai pris avec un SSD de 320 GO mais je suis déjà ce soir à 96,5% d’espace disque occupé… Doubler la capacité va commencer à coûter cher… 🙁 Une solution ? Puis-je basculer sur Infura & couper Geth ? Si OUI, comment faire ?
    Autre alternative : comment déménager mon validateur chez un autre provider car je n’aurais pas à recréer les clés, etc.
    Merci de votre aide ! 🙂
    F.

    Répondre
      Scott Piriou
      3 décembre 2020 - 14h01

      Bonjour,
      Pour ce qui est du deposit, je vous invite à consulter ce lien : https://kb.beaconcha.in/ethereum-2.0-depositing
      Pour ce qui est de geth, en effet ça prend de la place… Plus que ce que je pensais moi aussi…
      Sur DigitalOcean, vous pouvez ajouter un « block storage » c’est-à-dire de la place sur votre machine, mais il faudra probablement un peu modifier quelques configurations… pour ce qui est de « déplacer » vos validateurs, il vous suffit d’embarquer avec vous votre fichier « validator_keys » ainsi que votre fichier « lightouse-data » qui se trouve dans le fichier « lighthouse-docker » (ce fichier contient votre slashing-db !).
      Dans un premier temps, je vous recommande de basculer votre Eth1 vers Infura, puis de chercher quelles solutions s’offrent à vous. Vous pourriez par exemple décider de staker chez vous, ou bien staker chez un autre provider, ou bien réduire votre droplet et opter pour ajouter des block storage… Malheureusement cela ferait trop de tutoriel pour moi, donc je vous laisse chercher sur internet ! N’hésitez pas à rejoindre le Discord d’ethstaker, il y aura des gens pour vous aider 🙂

      Répondre
    larco
    1 décembre 2020 - 10h15

    Bonjour,
    Depuis la version 1.0.3 j’ai ceci comme message:
    beacon_node_1 | Dec 01 08:14:00.177 WARN Error connecting to eth1 node. Trying fallback …, endpoint: http://geth:8545, service: eth1_rpc
    beacon_node_1 | Dec 01 08:14:00.177 CRIT Couldn’t connect to any eth1 node. Please ensure that you have an eth1 http server running locally on http://localhost:8545 or specify one or more (remote) endpoints using --eth1-endpoints <COMMA-SEPARATED-SERVER-ADDRESSES>. Also ensure that eth and net apis are enabled on the eth1 http server, warning: BLOCK PROPOSALS WILL FAIL WITHOUT VALID, SYNCED ETH1 CONNECTION, service: eth1_rpc
    beacon_node_1 | Dec 01 08:14:00.177 ERRO Failed to update eth1 cache error: Failed to update Eth1 service: « All fallback errored: http://geth:8545 => EndpointError(NotReachable) », retry_millis: 7000, service: eth1_rpc
    Alors que le fichier .env contient bien ceci:
    START_GETH=
    VOTING_ETH1_NODES=https://mainnet.infura.io/v3/df3d56xxxxxxxxxxxxxxx
    Quelqu’un aurait une idée? merci

    Répondre
      Scott Piriou
      3 décembre 2020 - 16h14

      Je viens de relire le message: il semblerait que tu n’aies pas correctement sauvegarde ton fichier .env … en tout cas il n’essaie pas se connecter a Infura, mais bin a geth:8545

      Répondre
        larco
        3 décembre 2020 - 16h21

        C’était effectivemment bien cela, je modifiais le default.env et non le .env!
        Cela ne m’arrivera plus 🙂
        Merci en tout cas, ça tourne maintenant!

        Répondre
    john
    3 décembre 2020 - 09h41

    Bonjour,
    Jai suivi le tuto mais jai visiblement un probleme, je ne sais pas ou je me suis planté.
    Quelqu un pour m’aider ?
    Dec 03 07:38:55.675 CRIT Couldn’t connect to any eth1 node. Please ensure that you have an eth1 http server running locally on http://localhost:8545 or specify one or more (remote) endpoints using --eth1-endpoints <COMMA-SEPARATED-SERVER-ADDRESSES>. Also ensure that eth and net apis are enabled on the eth1 http server, warning: BLOCK PROPOSALS WILL FAIL WITHOUT VALID, SYNCED ETH1 CONNECTION, service: eth1_rpc
    beacon_node_1 | Dec 03 07:38:55.676 ERRO Failed to update eth1 cache error: Failed to update Eth1 service: « All fallback errored: http://geth:8545 => EndpointError(NotReachable) », retry_millis: 7000, service: eth1_rpc
    beacon_node_1 | Dec 03 07:39:00.656 WARN BlockProcessingFailure outcome: MissingBeaconBlock(0x2ff95525bf95d6315d92e42bdf0ff171b44749b65185b64ee08fd47b831e9cf1), msg: unexpected condition in processing block.
    beacon_node_1 | Dec 03 07:39:02.679 WARN Error connecting to eth1 node. Trying fallback …, endpoint: http://geth:8545, service: eth1_rpc
    beacon_node_1 | Dec 03 07:39:02.681 CRIT Couldn’t connect to any eth1 node. Please ensure that you have an eth1 http server running locally on http://localhost:8545 or specify one or more (remote) endpoints using --eth1-endpoints <COMMA-SEPARATED-SERVER-ADDRESSES>. Also ensure that eth and net apis are enabled on the eth1 http server, warning: BLOCK PROPOSALS WILL FAIL WITHOUT VALID, SYNCED ETH1 CONNECTION, service: eth1_rpc
    beacon_node_1 | Dec 03 07:39:02.681 ERRO Failed to update eth1 cache error: Failed to update Eth1 service: « All fallback errored: http://geth:8545 => EndpointError(NotReachable) », retry_millis: 7000, service: eth1_rpc
    beacon_node_1 | Dec 03 07:39:05.000 INFO Syncing est_time: –, distance: 778 slots (2 hrs 35 mins), peers: 55, servic
    MErci

    Répondre
      Scott Piriou
      3 décembre 2020 - 13h49

      Bonjour, désolé du retard. Tu as dû oublier de mettre « START_GETH=true » 😉 En tout cas le BN n’arrive pas a se connecter a la chaine eth1 🙂

      Répondre
    DarkCenobyte
    5 décembre 2020 - 23h21

    Bonsoir,
    J’ai une petite question par rapport au choix de Netcup, je sais qu’ils ont le meilleur prix pour le cas d’un node ETH2.0, cependant, je me demande est-ce qu’ils autorisent cet usage et est-ce que quelqu’un a explicitement poser la question à leur support ?
    Si on regarde leurs conditions d’utilisations, ils interdisent le mining (sur leurs VPS ET sur leurs « root-servers » (des VPS à coeur dédiés), alors certe ce n’est pas du mining dans notre cas mais du staking, cependant si on s’inquiète un peu plus et que l’on va voir leur forum (en allemand), avec un peu de google traduction sur un long thread dédié, on découvre que si ils autorisaient le mining au début, ils ont évoluer vers une position relativement anti-cryptomonnaie (sous prétexte d’usage électrique), et qu’ils n’ont pas répondu favorablement ou défavorablement publiquement au cas des coins stakés, mais qu’il y a une relative opposition à cela. Ils ont néanmoins publiquement reconnus qu’ils ne blacklisterait pas les machines à l’usage du fait de ne pas pouvoir différencier mining et « autre usage lourd » (encodage vidéo?/IA?), et de ce fait effectue une blacklist sur des usages réseaux lié aux cryptomonnaies…
    Personnellement, en l’absence d’une approbation de la part de Netcup, je pense basculer chez Hetzner du coup qui n’as jamais montré de signe d’opposition aux crypto, même si cela induit payer plus chère pour avoir du RAID1 sur le hardware du fait d’avoir un vrai serveur dédié… (en vue du gain, je pense que 40~55€ / mois est acceptable aussi vue les sommes engagés)

    Répondre
      Scott Piriou
      6 décembre 2020 - 11h55

      Bonjour et merci pour votre recherche. Il y a en effet d’autres providers et comme mentionné dans le guide, cet article n’est en aucun lien affilié à Netcup. Hetzner est en effet une alternative, et il y en a d’autres. Ce guide avait été rédigé en utilisant DigitalOcean au début, mais les tarifs étaient trop élevés.
      Je ne sais pas si Netcup a explicitement autorisé le staking sur leur VPS. C’est donc à vos risques et périls ! 🙂
      Une autre option est bien sûr d’avoir la machine chez soi ! 🙂

      Répondre
        DarkCenobyte
        6 décembre 2020 - 12h25

        Merci pour la réponse 🙂
        DigitalOcean en effet devient trop chère quand il s’agit de scaler sur le stockage.
        Personnellement j’utilise Prysm au lieu de Lighthouse, mais je suis tombé sur l’article en recherchant des avis autour de Netcup.
        J’ai finalement pris le risque de demander à Netcup plutôt que d’être discret (au pire si mon noeud est désactivé, j’ai mis en place un système qui fait qu’il ne peut être réactivé tout seul avec une clé de chiffrement placé sur un service AWS et ne la délivrant qu’à une IP où je pourrais suspendre mon ancienne IP par sécurité, et temporairement placer le node ailleurs).
        Si la réponse est négative, je basculerais vers un dédié Hetzner.
        Le hosting à domicile n’est pas trop une option pour moi (j’ai eu 4 mois de panne de fibre cette année si je cumule… Et je ne me vois pas brancher un noeud à un relai 4G x) , finalement les dédiés/vps sont probablement le plus viable pour moi)

        Répondre
        DarkCenobyte
        9 décembre 2020 - 00h21

        Alors, j’ai bien fais de basculer mon node vers Hetzner je pense ce week-end, j’ai reçu cet email aujourd’hui de la part de Netcup :
        https://imgur.com/a/ENeWm3m

        Répondre
    LH
    14 décembre 2020 - 22h42

    Bonjour,
    La V1.0.4 est dispo mais pas encore via Docker. Comment savoir que la mise a jour est dispo via Docker sans devoir arrêter LightHouse et lancer les commandes etc ?
    Merci

    Répondre
    Andy
    16 décembre 2020 - 00h47

    Bonjour,
    J’ai besoin de quelques éclaircissement,
    Voyant sur le discord une mise à jour de Lighthouse, j’ai suivi ce que vous indiquez jusqu’à l’étape où l’on doit recrée le fichier .env.
    En effet, le miens est resté identique (remplis comme il le faut), j’ai donc relancer le docker sans y toucher.
    Sauf que je me retrouve avec la beacon node qui n’arrive plus à se connecter à geth (Il tourne sur ma machine).
    Elle m’affiche la même erreur que larco avait au 1 décembre (j’ai bien modifié le .env)
    Geth a bien l’air de fonctionner, mais j’ai tout de même un warning (je ne sais pas si il faut en tenir compte):
    WARN [12-15|22:31:09.767] Served net_version conn=172.21.0.2:41268 reqid=1 t= »26.641µs » err= »the method net_version does not exist/is not available »
    Où peut être mon erreur ?

    Répondre
      Scott Piriou
      18 décembre 2020 - 12h57

      Je vous recommande de faire une sauvegarde de votre .env (cp .env .env.bak) puis de le re-creer (cp default.env .env, puis editer le fichier .env).
      Il se peut que le fichier de configuration default.env ait subit des changements, et que votre .env soit outdated.
      Sinon je vous recommande les Discord en bas de page (debugger par commentaire c’est difficile haha :))

      Répondre
    Francky
    19 décembre 2020 - 15h19

    Hello à tous,
    Tout fonctionnait parfaitement depuis 12 jours avant la MAJ Lighthouse que je viens de faire ce matin. Je continue de faire tourner mon propre GETH pour info.
    J’ai désormais le même message qu’Andy le 16/12 ou larco le 01/12 :
    CRIT Couldn’t connect to any eth1 node. Please ensure that you have an eth1 http server running locally on http://localhost:8545 or specify one or more (remote) endpoints using –eth1-endpoints . Also ensure that eth and net apis are enabled on the eth1 http server etc….
    J’ai pourtant suivi la recommandation de backuper mon .env puis repartir du fichier default.env en le dupliquant pour faire un nouveau .env avec les paramètres suivants :
    NETWORK=mainnet
    START_VALIDATOR=YES
    VALIDATOR_COUNT=1
    START_GETH=YES
    ENABLE_METRICS=YES
    Par contre, vous ne parlez plus des 2 lignes :
    IMPORT_LAUNCHPAD_KEYSTORE=YES
    LAUNCHPAD_KEYSTORE_PASSWD=XXX
    Devons-nous les reparamétrer comme dans la 1ère version de votre tutoriel avec YES et le password saisi au départ ? En tout cas, pour l’instant, j’ai ce que j’ai fais.
    En parallèle, au passage, j’ai juste mis YES à START_SLASHER et j’ai saisi un GRAFFITI pour le fun avec quelques lettres en majuscules…
    Avez-vous une idée SVP ?
    P.S. : En parallèle, j’en profite pour savoir si vous savez à quoi sert le nouveau paramètre du .env => SEARCH_BLOCKS ?
    Merci beaucoup de votre aide !

    F.

    Répondre
      Scott Piriou
      19 décembre 2020 - 15h53

      Bonjour,

      Ce probleme vient du fait que la version de geth utilisee dans le docker-compose n’est pas la version « stable ». (https://github.com/sigp/lighthouse-docker/pull/52).

      Je vous invite donc a modifier le fichier docker-compose.yml afin de changer la ligne « image: ethereum/client-go » en « image: ethereum/client-go:stable » comme cela: https://github.com/sigp/lighthouse-docker/pull/52/files

      Sinon, vous pouvez aussi utiliser Infura (ce guide detail comment).

      Je precise que les variables IMPORT_LAUNCHPAD_KEYSTORE et LAUNCHPAD_KEYSTORE_PASSWD ne sont plus mises dans le .env (ce guide a ete mis a jour et utilise une commande pour initialiser les cles plutot que de conserver ces variables).

      Enfin, SEARCH_BLOCKS est une variable qui permet d’eviter des erreurs dans le cas ou la liste de blocks demandee a geth serait trop grande. Si vous n’avez pas de problemes, vous n’avez pas besoin de toucher a cette variable 🙂

      Répondre
    Francky
    19 décembre 2020 - 21h25

    Merci beaucoup Scott !

    J’utilise désormais la version « stable » de GETH et cela semble mieux fonctionner car je n’ai plus ce message une fois l’ensemble synchronisé à nouveau 🙂

    Je rebondis par contre sur votre autre information concernant les variables IMPORT_LAUNCHPAD_KEYSTORE et LAUNCHPAD_KEYSTORE_PASSWD.
    3 questions rapides à ce sujet :

    Il est donc préférable de laisser ces 2 champs vierges dans le .env et de lancer la nouvelle commande de votre tutoriel ?
    Faut-il saisir le mot de passe quelque part du coup dans cette commande ou ailleurs ?
    Par ailleurs, s’agira-il d’une étape qu’il faut faire à chaque mise à jour des validateurs (notamment la 2ème commande) ?

    Merci d’avance !

    F.

    Répondre
      Scott Piriou
      19 décembre 2020 - 22h12

      Super 🙂
      Oui en règle générale il vaut mieux éviter de garder des mot de passe en clair. La saisie du mot de passe se fera lorsque vous lancerez la commande : il vous faudra entrer une fois votre mdp pour chaque validateur…
      Bien sûr, libre à vous de garder ces variables là et de ne pas lancer la longue commande. Cette commande ne sert qu’à initialiser vos clés.
      Comme elle ne sert qu’à initialiser vos clés, ce n’est pas une étape à répéter à chaque mise à jour. Pas de soucis si vous le faites pas mégarde : elle ne supprimera rien et n’est donc pas dangereuse.
      Elle est à lancer dans le dossier lighthouse-docker 🙂

      Répondre
    Narw
    24 décembre 2020 - 13h27

    Bonjour,
    Depuis la v1.0.5 ce message apparait:
    validator_client_1 | Dec 24 11:25:49.299 WARN Offline beacon node endpoint: http://localhost:5052/, error: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: « http », host: Some(Domain(« localhost »)), port: Some(5052), path: « /eth/v1/node/version », query: None, fragment: None }, source: hyper::Error(Connect, ConnectError(« tcp connect error », Os { code: 99, kind: AddrNotAvailable, message: « Cannot assign requested address » })) })
    J’ai déjà essayé de refaire une installation toute fraiche cela ne change rien…
    Quelqu’un a une idée?
    Merci

    Répondre
      Narw
      24 décembre 2020 - 14h27

      Solution du Discord Lighthouse (et ca fonctionne)
      can you edit the scripts/start-validator-client.sh to –beacon-nodes instead of –beacon-node in the second last line and restart?

      Répondre
    Stake topluluk bağış alan duyurusu | Ethereum Vakfı Blogu – atmhaber.com
    28 mars 2021 - 10h22

    […] Fransızca yeni başlayanlar için stake etme kılavuzu […]

    Répondre
    Dude
    17 juin 2021 - 11h38

    Bonjour,
    y a t’il un tuto pour pouvoir utiliser l’application mobile beaconchain afin de monitorer son noeud lorsque l’on utilise le cocker?
    (https://kb.beaconcha.in/beaconcha.in-explorer/mobile-app-less-than-greater-than-beacon-node)
    Merci

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *