Futures
Accédez à des centaines de contrats perpétuels
TradFi
Or
Une plateforme pour les actifs mondiaux
Options
Hot
Tradez des options classiques de style européen
Compte unifié
Maximiser l'efficacité de votre capital
Trading démo
Introduction au trading futures
Préparez-vous à trader des contrats futurs
Événements futures
Participez aux événements et gagnez
Demo Trading
Utiliser des fonds virtuels pour faire l'expérience du trading sans risque
Lancer
CandyDrop
Collecte des candies pour obtenir des airdrops
Launchpool
Staking rapide, Gagnez de potentiels nouveaux jetons
HODLer Airdrop
Conservez des GT et recevez d'énormes airdrops gratuitement
Launchpad
Soyez les premiers à participer au prochain grand projet de jetons
Points Alpha
Tradez on-chain et gagnez des airdrops
Points Futures
Gagnez des points Futures et réclamez vos récompenses d’airdrop.
Investissement
Simple Earn
Gagner des intérêts avec des jetons inutilisés
Investissement automatique
Auto-invest régulier
Double investissement
Profitez de la volatilité du marché
Staking souple
Gagnez des récompenses grâce au staking flexible
Prêt Crypto
0 Fees
Mettre en gage un crypto pour en emprunter une autre
Centre de prêts
Centre de prêts intégré
PERSPECTIVE DÉVELOPPEUR | Comment devenir un validateur Ethereum en solo
Réfléchissez-y une seconde,
Une blockchain n’est qu’une grande base de données unique qui n’appartient à personne mais à laquelle tout le monde peut écrire, et tout ce qui y est écrit ne peut pas être supprimé. Vous devez avoir une copie de la base de données sur votre ordinateur si vous souhaitez y écrire.
Donc, vous avez enfin compris à quel point investir dans le fait de devenir validateur Ethereum est une bonne idée, et vous avez décidé d’essayer pour voir combien vous pouvez gagner.
Félicitations d’abord. C’est une tâche énorme et je, au nom de la communauté Ethereum, vous remercie (pour peu que vous ayez décidé de devenir validateur — pour gagner des récompenses de bloc, rendre Ethereum plus décentralisé, etc.) pour votre initiative audacieuse.
Dans le même esprit de décentralisation, nous allons voir comment devenir un validateur solo, ou comme on l’appelle aussi, faire du staking en solo sur Ethereum.
Nous n’aborderons pas d’autres méthodes de staking comme le staking liquide, le staking en tant que service ou autres. Sérieusement, vous avez décidé d’être validateur, alors pourquoi ne pas le faire à la manière cypherpunk, hein ?
Commençons par nous familiariser avec quelques mots :-
Ethereum est une blockchain Proof of Stake depuis “La Fusion” qui a eu lieu le 15 septembre 2022, transitionnant Ethereum du Proof-of-Work (PoW) au Proof-of-Stake (PoS).
Ce que cela signifie, c’est que la façon dont Ethereum atteint le consensus a complètement changé.
Souvenez-vous, comment nous disions qu’une blockchain n’est qu’une grande base de données unique sur plusieurs ordinateurs, eh bien, l’état de cette base doit être connu de tous les ordinateurs du réseau en permanence. Les ordinateurs (nœuds) participant au réseau doivent s’accorder sur l’état actuel de la base, c’est-à-dire atteindre un consensus !
Les nœuds Ethereum n’ont pas besoin de résoudre des problèmes mathématiques complexes pour atteindre le consensus comme c’était le cas en PoW, mais plutôt, ils verrouillent de l’éther à l’avance, en disant essentiellement :
“Hé, je suis prêt à être un validateur qui ajoutera des blocs et vérifiera des transactions, et si je me comporte mal d’une quelconque façon en accomplissant cette tâche, tu peux prendre l’éther que j’ai déposé à l’avance (mon stake) comme punition. Si je me comporte bien, tu me récompenses avec de l’éther nouvellement créé !”
Lorsque plus de deux tiers des validateurs sont d’accord sur l’état actuel de la base de données mentionnée ci-dessus, l’état de la blockchain est considéré comme finalisé !
Pourquoi deux tiers de tous les validateurs ?
Imaginez si nous devions attendre que tous les validateurs (au moment de l’écriture, Ethereum compte 1 031 682 validateurs actifs) dans le réseau soient d’accord sur l’état de la blockchain ? La vitesse de finalisation serait très lente, rendant Ethereum pratiquement inutilisable. La vitesse de finalisation d’une blockchain est aussi rapide que son nœud le plus lent, et comme Ethereum est maximally décentralisé (ce qui signifie qu’il peut fonctionner sur du matériel grand public, généralement plus lent que des ordinateurs ultra puissants), il faut prendre en compte le nœud le plus lent. Donc, deux tiers ne semblent pas être un mauvais chiffre pour attendre après cet argument peu convaincant, n’est-ce pas… 😂😂😂
Le modèle de sécurité d’Ethereum peut maintenant être résumé comme suit : “Les humains sont des créatures rationnelles qui veulent faire des profits et prendront des décisions rationnelles pour réaliser ces profits. Ils ne se comporteront donc pas mal, car s’ils le font, l’éther qu’ils ont verrouillé à l’avance (leur stake) sera réduit (slashed) !”
Vous voyez, la sécurité par le capitalisme, n’est-ce pas ?
Première chose d’abord,
Qu’est-ce qu’un nœud Ethereum ?
Un nœud Ethereum est un ordinateur exécutant un logiciel Ethereum appelé client Ethereum. C’est tout. Croyez-moi, c’est vraiment tout. C’est aussi simple que ça, pas de mots compliqués, rien d’autre. Voilà ! Nœuds Ethereum.
Ces nœuds constituent la blockchain Ethereum — un ensemble d’ordinateurs exécutant un logiciel similaire qui peuvent communiquer entre eux.
Tout le monde peut faire fonctionner un nœud Ethereum, mais il n’y a aucun avantage financier à en tirer. Ne vous méprenez pas, il y a certainement des bénéfices à faire tourner un nœud (différent d’être validateur) comme :-
En générant une clé de signature ‘magique’ spécialisée et en stakeant 32 ETH dans un contrat intelligent lié à cette clé, vous transformez votre nœud Ethereum en validateur.
Les validateurs sont des nœuds ‘activés’ qui traitent les transactions des utilisateurs et les finalisent (c’est-à-dire, la finalisation).
La validité de chaque transaction est votée par tous les validateurs (attestations signées) dans le réseau Ethereum, et certifiée par leur ETH mis en jeu.
Parce que les validateurs traitent et certifient les transactions des utilisateurs, ils sont récompensés pour leur bon travail et pénalisés en cas de mauvaise conduite. Si un validateur est trouvé malhonnête, malicieux ou gravement négligent, sa mise en jeu peut être réduite (slashed) jusqu’à la totalité de son stake, voire expulsé du réseau.
Cela incite les validateurs à rester honnêtes.
Alors, comment faire du staking solo sur Ethereum ?
Il faut déposer 32 ETH pour devenir validateur sur Ethereum. 32 ETH équivalent à environ Ksh. 13 998 370,65 au moment de l’écriture, où 1 ETH = Ksh. 437 449,08 — combien vaut 1 ETH quand vous lisez ceci ?
Comment ont-ils fixé la limite à 32 ETH ? C’est inscrit dans le code que les logiciels clients Ethereum doivent exécuter pour participer à la blockchain.
Vous devez ensuite faire fonctionner un logiciel client spécifique pour devenir validateur. Voici quelques exemples :-
Ce logiciel est collectivement appelé logiciel de la couche de consensus, car c’est lui qui atteint le consensus sur Ethereum — décide de l’état de la blockchain.
Maintenant que vous savez quel logiciel client faire fonctionner et que vous avez 32 ETH, vous êtes prêt à gagner ces récompenses de blocs, n’est-ce pas ? Eh bien, oui, mais comme d’habitude, le diable est dans les détails. Voyons comment cela peut rapidement devenir une tâche très complexe.
Staking en solo
Le staking en solo consiste à faire fonctionner entièrement votre propre nœud et à recevoir seul les récompenses de bloc.
Les exigences matérielles minimales pour faire du staking en solo sont :-
Les exigences matérielles peuvent sembler intimidantes au début, mais avez-vous vu les exigences matérielles de Solana ?
Souvenez-vous de notre mantra :
“Une blockchain n’est qu’une grande base de données unique qui n’appartient à personne mais à laquelle tout le monde peut écrire, et tout ce qui y est écrit ne peut pas être supprimé. Vous devez avoir une copie de la base sur votre ordinateur si vous souhaitez y écrire.”
Oui, restons là-dessus et voyons comment chaque composant matériel influence la performance.
Souvenez-vous quand nous disions qu’il faut faire tourner un client de la couche de consensus comme Lighthouse, eh bien, il faut aussi faire tourner un client de la couche d’exécution.
Qu’est-ce qu’un client de la couche d’exécution ? Je suis content que vous demandiez…
Un client de la couche d’exécution dans Ethereum est le logiciel qui exécute les contrats intelligents et transactions. C’est ici que vos dApps préférées comme Aave, Uniswap, et votre meme coin favori qui doit décoller sont exécutés. Cette couche d’exécution constitue la Machine Virtuelle d’Ethereum (EVM).
Exemples de clients de la couche d’exécution :-
NB : Améliorez la résilience d’Ethereum en utilisant un client d’exécution minoritaire. Que se passe-t-il si un événement Black Swan survient et que geth, qui détient environ 55% de part de marché au moment de l’écriture — c’est-à-dire que plus de la moitié des clients d’exécution Ethereum utilisent geth — a un bug critique ? Cela signifierait-il que Ethereum va s’effondrer ?
La validation de blocs se déroule ainsi :-
Prenons un exemple de configuration de reth (client de la couche d’exécution) avec Lighthouse (client de la couche de consensus).
Les étapes suivantes supposent que vous avez une bonne maîtrise de Linux, oui, y compris taper des commandes dans le terminal que vous avez copiées de StackOverflow sans vraiment comprendre ce qu’elles font, mais bon, elles fonctionnent.
ls -al | grep | xxd | echo -n
Vous ne comprenez rien à ce que je viens de taper ?
Si ls -al | grep | xxd | echo -n vous semble du mandarin, il est temps de dépoussiérer vos livres et de réviser vos commandes Linux. Pas besoin d’être un guru comme moi (oui, j’utilise Arch BTW), mais au moins, apprenez à différencier cd de rm -rf / !
Nous allons travailler sur une machine avec Ubuntu installé.
Nous devons d’abord créer un JSON Web Token (JWT) qui permettra au logiciel de la couche d’exécution (reth) et à celui de la couche de consensus (Lighthouse) de communiquer.
Exécutez les commandes suivantes une par une pour créer un répertoire nommé jwtsecret et générer le fichier JWT jwt.hex à l’intérieur.
Nous pointerons plus tard les fichiers de configuration des clients d’exécution et de consensus vers ce fichier JWT (jwt.hex).
Téléchargez reth et configurez le service
Téléchargez la dernière version de reth ici (https://github.com/paradigmxyz/reth/releases)) et son fichier de signature numérique (.asc) pour vérifier l’intégrité du fichier téléchargé.
Vérifiez le checksum comme suit :
Sortie attendue : Vérification du checksum
“
gpg: Signature made Mon 24 Jun 2024 01:33:15 PM EAT
gpg: using EDDSA key 50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E
gpg: Good signature from “Georgios Konstantopoulos (Reth signing key for 2024 and on) <[email protected]>” [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Clé principale (empreinte) : 50FB 7CC5 5B2E 8AFA 59FE 03B7 AA5E D56A 7FBF 253E
Vérifiez la clé de signature de la version ici (https://reth.rs/installation/binaries.html#signature-verification).
Si le checksum est correct, extrayez les fichiers et déplacez-les dans le répertoire (/usr/local/bin).
Puis nettoyez le répertoire de travail.
Créez un compte nommé reth sans accès serveur pour que reth (le logiciel de la couche d’exécution) puisse fonctionner en arrière-plan. Ce type de compte utilisateur n’aura pas de droits root, ce qui limite la surface d’attaque en cas d’infiltration via une mise à jour client compromise.
Créez un répertoire pour reth (le logiciel de la couche d’exécution) pour stocker les données de la blockchain de cette couche. Puis, donnez la propriété de ce répertoire à reth (le compte utilisateur) pour qu’il puisse lire et écrire dedans.
Créez un fichier de configuration systemd pour que le service reth tourne en arrière-plan.
Collez dans le fichier les paramètres suivants :
“
[Unit]
Description=Reth Execution Client (Holesky)
After=network.target
Wants=network.target
[Service]
User=reth
Group=reth
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/reth node \
–chain holesky \
–datadir=/var/lib/reth \
–log.file.directory=/var/lib/reth/logs \
–authrpc.jwtsecret=/var/lib/jwtsecret/jwt.hex \
–full \
–port 30304 \
–http \
–http.api eth,web3,net,txpool,debug,trace \
–http.addr <adresse_ip_interne> \
–http.port 8547 \
–ws \
–ws.addr <adresse_ip_interne> \
–ws.port 8548 \
–metrics 127.0.0.1:6060
[Install]
WantedBy=default.target
“
Une fois terminé, sauvegardez avec ESC → ENTER → :wq → ENTER
Revoyez votre résumé de configuration et modifiez si nécessaire.
Résumé de configuration reth :
Démarrez reth
Rechargez le démon systemd pour enregistrer les changements, démarrez reth et vérifiez son statut.
Sortie attendue : reth doit être “active (running)”. Appuyez sur CTRL+C pour quitter, reth continuera de tourner. La synchronisation sur le testnet Holesky prend environ 6 heures.
Utilisez la commande suivante pour voir les logs du processus de synchronisation de reth. Surveillez tout avertissement ou erreur.
Sortie attendue :
Appuyez sur CTRL+C pour arrêter.
Consultez ici (https://geth.ethereum.org/docs/fundamentals/logs)) pour plus de détails sur l’interprétation des logs de journalctl de reth.
Si le service reth fonctionne bien, vous pouvez l’activer pour qu’il démarre automatiquement au reboot.
Sortie attendue :
Documentation reth : https://reth.rs/
Configurer et lancer le client de la couche de consensus.
Les étapes seront similaires à celles pour le client de la couche d’exécution.
Téléchargez la dernière version de Lighthouse ici (https://github.com/sigp/lighthouse/releases)) et vérifiez le checksum.
Vérifiez le checksum :
Sortie attendue : Vérification du checksum
“
gpg: Signature made Mon 24 Jun 2024 01:40:15 PM EAT
gpg: using RSA key 15E66D941F697E28F49381F426416DC3F30674B0
gpg: Good signature from “Sigma Prime <[email protected]>” [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Clé principale (empreinte) : 15E6 6D94 1F69 7E28 F493 81F4 2641 6DC3 F306 74B0
Si le checksum est correct, extrayez les fichiers et déplacez-les dans (/usr/local/bin). Puis nettoyez le répertoire de travail.
NOTE : Nous exécuterons le client de consensus et le client validateur de Lighthouse en services séparés pour plus de flexibilité, notamment pour configurer un nœud de secours en cas de besoin.
Créez un compte (lighthouse) sans accès serveur pour que le client de consensus et le client validateur de Lighthouse tournent en arrière-plan. Ce type de compte n’aura pas de droits root, ce qui limite la surface d’attaque en cas d’infiltration via une mise à jour client compromise.
Créez un répertoire pour Lighthouse pour stocker la blockchain et les données du validateur de la couche de consensus.
Déplacez le répertoire validator_keys dans ce dossier. Puis, donnez la propriété à lighthouse pour qu’il puisse lire et écrire dedans.
Si pas d’erreur, créez un fichier de configuration systemd pour le client de consensus.
Collez la configuration suivante :
“
[Unit]
Description=Lighthouse Beacon Node (Holesky)
Wants=network-online.target
After=network-online.target
[Service]
User=lighthousebeacon
Group=lighthousebeacon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
–network holesky \
–datadir /var/lib/lighthouse_beacon \
–execution-endpoint http://127.0.0.1:8551 \
–execution-jwt /var/lib/jwtsecret/jwt.hex \
–checkpoint-sync-url=https://holesky.beaconstate.ethstaker.cc/ \
–metrics \
–metrics-port 8009 \
–validator-monitor-auto \
–port 9001 \
–http \
–http-port 5051 \
–http-address <adresse_ip_interne> \
–builder http://127.0.0.1:18550
[Install]
WantedBy=multi-user.target
“
Une fois terminé, sauvegardez avec ESC → ENTER → :wq → ENTER
Revoyez votre résumé de configuration et modifiez si nécessaire.
Résumé de la configuration du client de consensus Lighthouse :
–network : exécuter sur le testnet ETH Holesky
–datadir : répertoire pour stocker les données du client de consensus
–execution-endpoint : URL pour se connecter au client de la couche d’exécution
–execution-jwt : chemin vers le fichier JWT généré
–checkpoint-sync-url : pour une synchronisation quasi instantanée via une URL de checkpoint
–metrics : activer la surveillance des métriques
–metrics-port : port pour le monitoring (Prometheus, Grafana)
–validator-monitor-auto : pour plus de logs et métriques sur les validateurs locaux
–port : port pour la communication P2P (par défaut 9000)
–http : permettre au client validateur de se connecter au client de consensus et de fournir des métriques
–http-port : port pour la connexion au client de consensus
–http-address : IP du client de consensus (adresse interne)
–builder : URL pour se connecter à des constructeurs externes (ex. relais MEV)
Démarrez le client de consensus Lighthouse
Rechargez systemd, démarrez le service et vérifiez qu’il tourne.
Sortie attendue : Lighthouse est “active (running)”. Appuyez sur CTRL+C pour quitter, il continuera de fonctionner. La synchronisation sur Holesky prend quelques minutes.
Utilisez cette commande pour voir les logs de synchronisation de Lighthouse. Surveillez tout avertissement ou erreur.
Sortie attendue :
Appuyez sur CTRL+C pour arrêter la surveillance.
Si le service Lighthouse fonctionne bien, vous pouvez l’activer pour qu’il démarre automatiquement au reboot.
Vérifiez les racines d’état initial (synchronisation par checkpoint)
La documentation de Lighthouse est ici (https://lighthouse-book.sigmaprime.io/intro.html).
Génération de clés de validateur
Une clé de validateur est une clé cryptographique utilisée par les validateurs sur Ethereum. Ces clés sont essentielles pour proposer et attester (voter) sur des blocs. Il y a deux types principaux de clés :-
Comment générer ces deux clés ? Je suis content que vous demandiez… On va le faire à la manière cyperpunk.
Il est conseillé de générer ces clés sur une machine “air-gapped”, c’est-à-dire jamais connectée à Internet.
Prenez un Raspberry Pi bon marché — il coûte moins de 100 USD.
Si un Raspberry Pi ou une nouvelle machine n’est pas une option, téléchargez un OS récent, comme Tail OS. Démarrez Tail OS en live sur une clé USB, générez les clés de validateur, copiez-les sur la clé USB, et c’est tout.
Quelle que soit la méthode, assurez-vous d’être dans un environnement sécurisé (maison ou bureau) avec un réseau WiFi de confiance. Bloquez physiquement toutes les caméras — portables, webcams, caméras d’ordinateurs, personnes derrière vous — et éteignez toute connexion Internet (Ethernet, WiFi, Bluetooth) avant de générer les clés.
C’est une précaution sérieuse pour la vie privée, n’est-ce pas ? Vous ne protégez même pas votre phrase de récupération de portefeuille comme ça lol 😂😂😂. À vrai dire, il n’y a probablement rien dans votre vie que vous protégez autant lors de la génération de clés. Ce niveau de confidentialité indique que si vous perdez ou si vos clés sont compromises, c’est fini pour vous !
Pour plus de sécurité, nous allons montrer comment travailler avec un OS live (Tail OS) sur une clé USB.
Pourquoi Tail OS ?
Parce qu’Edward Snowden le recommande ! Vous ne savez pas qui c’est ?
Cherchez-le.
Téléchargez la dernière version du fichier binaire de génération de clé de dépôt de validateur Ethereum ici (https://github.com/ethereum/staking-deposit-cli/releases)) et vérifiez le checksum du fichier zip téléchargé.
Sortie attendue :
“
staking_deposit-cli-fdab65d-linux-amd64.tar.gz: OK
“
Après vérification du checksum, extrayez le contenu et changez de répertoire dans le dossier extrait.
Générez vos clés de signature de validateur
AVANT DE PASSER À L’ÉTAPE SUIVANTE
Je ne peux pas insister assez, protégez vos clés ! Gardez-les précieusement comme votre BTC !
Exécutez la commande suivante pour générer vos clés de validateur. Remplacez par le nombre de validateurs que vous souhaitez configurer et par votre adresse de retrait réelle.
Pour , utilisez une adresse de portefeuille Ethereum non-custodial et sécurisée que vous possédez, par exemple une adresse de portefeuille froid, une multi-sig SAFE. N’utilisez pas un portefeuille d’échange (CEX).
Vous serez invité à entrer les informations suivantes, choisissez selon votre convenance :
Sortie attendue :
Ensuite, votre liste de mots mnémotechniques sera générée. Écrivez-la sur un papier ou un carnet — Ne la stockez jamais en ligne ou sur un appareil connecté à Internet.
Sortie attendue :
Appuyez sur une touche une fois que vous avez écrit votre phrase mnémotechnique, et l’outil vous demandera de la retaper dans le même ordre pour vérifier que vous l’avez bien enregistrée.
Si vous avez bien tapé votre phrase mnémotechnique, vous verrez une œuvre ASCII représentant un rhinocéros !
Sortie attendue :
Deux fichiers seront générés :
Stockez ces deux fichiers sur une nouvelle clé USB en copiant tout le dossier staking-deposit-cli. Ensuite, supprimez l’original :
Redémarrez votre appareil (ordinateur ou autre) et retirez la clé USB. Il n’y aura pas de mémoire persistante dessus.
Ajouter la clé de validateur au nœud
Une fois que vous avez votre keystore de signature, il faut le placer dans votre nœud validateur pour qu’il puisse signer les attestations et proposer des blocs.
Insérez la clé USB contenant vos keystores dans votre nœud. Une fois insérée, identifiez-la avec :
Sortie attendue :
Cherchez votre clé USB dans la liste. Elle aura un nom comme sdx.
Une fois trouvée, montez-la dans le dossier /media :
Note : Remplacez sda1 par le nom réel de votre clé.
Vous pourrez accéder à votre clé USB via le terminal dans /media.
Copiez votre keystore de signature dans le répertoire HOME de votre nœud :
Démontez et éjectez la clé USB :
Vous devez maintenant créer un fichier de mot de passe en texte clair pour que votre nœud puisse déchiffrer le keystore.
Commencez par copier le nom du keystore :
Copiez le nom du fichier keystore.
Créez le fichier de mot de passe :
Entrez le mot de passe utilisé lors de la génération des clés, puis sauvegardez et quittez avec ESC → ENTER → :wq → ENTER.
Dépôt de 32 ETH pour devenir validateur
Écoutez bien, c’est ici que vous envoyez 32 ETH pour devenir validateur. Vous ne pouvez pas simplement envoyer 32 ETH à un portefeuille, vous devez utiliser le contrat officiel de dépôt de Beacon.
L’adresse du contrat est 0x00000000219ab540356cBB839Cbe05303d7705Fa sur le réseau principal.
Mais attention, vous ne pouvez pas envoyer directement comme à un portefeuille classique. Il faut passer par l’interface officielle Ethereum Launchpad (http://launchpad.ethereum.org/)).
Envoyer directement sans passer par le Launchpad entraînera un échec de transaction !
Vérifiez plusieurs fois l’adresse du contrat de dépôt de Beacon via Ethereum Foundation (https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/),), EthHub (https://ethhub.io/)), EtherScan (https://etherscan.io/)) pour confirmer qu’il s’agit bien de 0x00000000219ab540356cBB839Cbe05303d7705Fa.
Les scams sont nombreux dans la crypto, soyez très prudent.
Puisque nous travaillons sur un testnet (Holesky), nous continuerons à être validateur sur ce testnet.
Au lieu d’utiliser le Launchpad officiel (http://launchpad.ethereum.org/)),), nous utiliserons une plateforme de test (https://holesky.launchpad.ethstaker.cc/)).
Où obtenir 32 ETH testnet ?
Allez sur https://holesky-faucet.pk910.de/ et essayez de mint 32 ETH testnet.
Rejoignez le serveur Discord ici – https://discord.gg/ethstaker
Rejoignez le canal #cheap-holesky-validator
Tapez “/cheap-holeskysky-deposit ” dans la zone de texte et validez.
Cliquez sur le lien généré (ex. le texte Signer.is).
Connectez votre wallet Metamask et signez le message.
Copiez l’URL et collez-la dans la case “Enter Signature”.
Vérification des disclaimers obligatoires
Ensuite, allez sur https://holesky.launchpad.ethstaker.cc/ dans votre navigateur et cliquez sur “Devenir validateur”.
Lisez attentivement tous les disclaimers et assurez-vous de bien comprendre ce à quoi vous vous engagez. Ce n’est pas une simple acceptation de termes sans lecture, prenez le temps de tout lire et de tout comprendre.
Continuez à cliquer jusqu’à atteindre la section “Upload deposit data”. Ne vous inquiétez pas pour les sections “Choose client” et “Generate keys”, vous les avez déjà traitées si vous avez suivi ce guide dans l’ordre.
Faire le dépôt
Téléchargez le fichier deposit_data-.json que vous avez généré précédemment dans la section d’installation, puis uploadez-le dans la zone prévue. Continuez jusqu’à voir la page suivante.
Vous devrez cocher toutes les cases de disclaimer avant de pouvoir continuer. Mais avant, assurez-vous de ne pas être victime d’une tentative de phishing en cliquant sur “Learn here how to do it safely” comme indiqué.
Vous verrez une page où vous pourrez révéler l’adresse du contrat de dépôt de Beacon. Vérifiez que l’adresse affichée dans votre wallet correspond bien à celle indiquée avant d’approuver la transaction.
Les vérifications ci-dessus vous mèneront à l’adresse du contrat de dépôt pour le Mainnet. Sur Holesky, l’adresse du contrat de dépôt est :
0x4242424242424242424242424242424242424242
Une fois prêt, cliquez sur “Send Deposit” et suivez les instructions dans MetaMask ou votre portefeuille.
Après confirmation de la transaction, vous pourrez suivre la progression de l’activation et la performance de votre validateur en cliquant sur les liens externes en jaune. Mémorisez ces liens pour y revenir facilement.
N’ayez pas d’inquiétude si cela n’apparaît pas immédiatement, cela peut prendre un peu de temps pour que la mise en place soit effective.
Félicitations ! Vous êtes maintenant un fier contributeur à la décentralisation du réseau Ethereum. C’est plutôt cool, non ?
Sortie de votre validateur
À un moment donné, lors de la vie d’un validateur, vous voudrez peut-être sortir volontairement pour récupérer votre solde, votre stake (32 ETH) plus les récompenses accumulées, à condition d’avoir une adresse de retrait associée à votre validateur — ce que vous avez probablement si vous avez suivi ce guide, n’est-ce pas ? Vous ne vous en souvenez pas ?
Souvenez-vous des deux clés mentionnées lors de la “génération des clés de validateur” ? Ce sont celles-là.
Si vous souhaitez sortir volontairement du rôle de validateur, voici la procédure (en utilisant Lighthouse) :
Un validateur peut demander une sortie volontaire s’il est actif, non slashed, et actif depuis au moins 256 epochs (~27 heures).
NOTE : Après avoir lancé la demande de sortie volontaire, le validateur doit continuer à remplir ses devoirs jusqu’à ce que la sortie soit effective, pour éviter des pénalités.
Il faut compter au minimum 5 epochs (32 minutes) après la demande pour que la sortie soit effective, ce délai pouvant être plus long si d’autres validateurs attendent aussi de sortir.
Lancer une sortie volontaire
Pour initier la sortie, utilisez la commande suivante :
*L’option --keystore indique le chemin vers le keystore de vote (format EIP-2335).
*L’option --beacon-node indique l’endpoint HTTP du beacon node.
*L’option --network indique le réseau (par défaut mainnet).
*L’option --password-file indique le chemin vers le fichier contenant le mot de passe du keystore. Si non fourni, vous serez invité à le saisir.
Après avoir saisi le mot de passe, vous devrez confirmer avec une phrase d’exit spéciale. La phrase d’exit est :
Exit my validator
Voici un exemple pour une sortie volontaire sur le testnet Holesky :
Vous verrez un message confirmant la demande. La sortie sera en attente de finalisation, ce qui peut prendre plusieurs minutes.
Retrait complet des fonds stakés
Après la mise à jour Capella (12 avril 2023), si un validateur demande une sortie volontaire, il recevra ses fonds complets à l’adresse de retrait, à condition que ses credentials de retrait soient de type 0x01. Pour plus d’informations, consultez Ethereum.org.
Les procédures de sortie varient selon le client, mais restent similaires :-
Ce guide mélangeait des liens et contextes de testnet et de mainnet. Pourquoi ?
Parce que je n’ai pas 32 ETH sous la main, alors adaptez ce texte selon la chaîne (testnet ou mainnet) sur laquelle vous souhaitez devenir validateur !
C’était long, hein !
Vous avez lu exactement 6 309 mots, soit 40 289 caractères de mon discours pour vous expliquer comment faire du staking en solo.
J’espère que vos attentes initiales ont été satisfaites et que vous pouvez maintenant configurer avec succès votre propre validateur solo.
À la prochaine sur l’autre côté de la chaîne, où nous réfléchirons si EigenLayer est l’avenir des règlements Ethereum ou non, tout en se moquant de Solana toujours hors ligne et des boasts de Cardano sur ses papiers académiques… qui sont… enfin, c’est une autre histoire !