Comment configurer un validateur Solana

Terminologie : qu’est-ce qu’un validateur Solana ?

La suite d’outils Solana CLI contient le binaire solana-validator, qui peut :

• Se connecter à un cluster Solana et synchroniser son état actuel
• Produire, recevoir et partager des snapshots et d’autres données du cluster pour rester à jour
• Voter afin de vérifier les nouveaux blocs dans le cadre du consensus du cluster
• Traiter les transactions entrantes et produire de nouveaux blocs
• Exposer des API RPC et événementielles pour interroger les données du cluster et soumettre de nouvelles transactions

Un validateur Solana peut également être appelé client (car il se connecte au réseau de validateurs et demande des données), serveur (car il traite les requêtes d’autres validateurs et leur fournit des données) ou nœud.

Un nœud RPC est un validateur Solana sans stake et sans droit de vote qui conserve toutes les informations du réseau. Il répond uniquement aux demandes de données et ne participe pas au consensus.

Le terme « validateur Solana » peut également désigner une entité de l’écosystème Solana qui exploite un validateur Solana doté de stake et d’un droit de vote, et participe au consensus.

Vous trouverez ici plus d’informations sur les différences entre les RPC, les fournisseurs de RPC et les validateurs.

Pour commencer : obtenez le matériel serveur

Vous aurez besoin d’un ordinateur puissant exclusivement dédié au validateur, ainsi que d’un second si vous souhaitez exploiter des validateurs à la fois sur le testnet et le mainnet. À l’heure actuelle, la configuration minimale recommandée comprend 12 cœurs/24 threads, 256 Go de RAM, 2 SSD de 1 To (idéalement en RAID0) et une connexion Internet de 10 Gbit/s. Vous trouverez le détail des exigences matérielles ici.

Si vous êtes tenté de réduire les coûts en utilisant uniquement le mainnet, sachez que vous devez exploiter un validateur sur le testnet pour être admissible au Solana Foundation Delegation Program (SFDP).

Vous pouvez acheter et exploiter vous-même le matériel, ou le louer auprès d’un fournisseur de centre de données (nous recommandons TeraSwitch). Vous pouvez aussi le louer auprès d’un fournisseur de cloud computing, mais nous ne le recommandons pas, car cette option est souvent trop coûteuse et davantage sujette aux problèmes de performances. Solana Foundation Server Program vise à faciliter la location de matériel auprès d’opérateurs de centres de données pour les exploitants de validateurs. En savoir plus.

Pour contribuer à la décentralisation du réseau, envisagez des ASN et des villes qui ne concentrent pas déjà de nombreux nœuds Solana ou beaucoup de stake. Certains pools de staking et le SFDP vous récompenseront en fonction de la décentralisation par ASN et par ville.

Vous trouverez ici les principaux centres de données actuels.

Installez Solana CLI localement

Il est vivement recommandé d’installer les outils localement afin de pouvoir générer toutes les clés nécessaires sur votre machine et de conserver la clé de retrait à l’écart du serveur du validateur. Vous trouverez ici les instructions pour configurer Solana CLI localement.

Une fois les outils accessibles localement depuis votre ligne de commande, configurez-les pour qu’ils utilisent le testnet par défaut :

$ solana config set --url https://api.testnet.solana.com

Pour le mainnet, vous pouvez utiliser l’endpoint par défaut suivant :

$ solana config set --url https://api.mainnet-beta.solana.com

Les endpoints publics du mainnet sont souvent saturés de requêtes. Si leurs performances ne vous satisfont pas, vous pouvez vous inscrire à Helius et utiliser votre endpoint Helius comme suit :

$ solana config set --url https://mainnet.helius-rpc.com/?api-key=<YOUR-HELIUS-API-KEY>

La configuration et l’amorçage du validateur nécessiteront l’exécution de transactions. Vous devez donc disposer d’un wallet contenant quelques SOL. Si vous commencez tout juste à utiliser le testnet, vous pouvez créer un wallet par défaut et obtenir quelques SOL par airdrop avec les commandes suivantes :

$ mkdir -p ~/.config/solana
$ solana-keygen new --outfile ~/.config/solana/id.json
$ solana airdrop 1 ~/.config/solana/id.json

Il est vivement recommandé d’utiliser des wallets différents pour le testnet et le mainnet. Le format des clés étant identique, les mêmes clés peuvent être utilisées sur les deux réseaux, mais résistez à cette tentation. Si vous utilisez les mêmes clés pour des wallets approvisionnés sur le testnet et le mainnet, vous risquez facilement d’exécuter par erreur sur le mainnet des commandes destinées au testnet.

Découvrez-en plus sur la génération de clés et sur des méthodes de génération plus sécurisées.

Configurez le compte de vote

Le compte de vote de votre validateur est créé à l’aide de la commande solana create-vote-account et de trois paires de clés :

1. Paire de clés d’identité — Le validateur utilise cette paire de clés pour s’identifier auprès du réseau et soumettre des transactions, notamment des votes. La clé privée doit être stockée sur le serveur. Pour une sécurité optimale, n’y conservez donc pas plus de SOL que nécessaire pour les transactions de vote (environ 1 SOL/jour).
2. Paire de clés du compte de vote — Cette paire de clés désigne le compte de vote lui-même. Elle sert à rechercher ce compte et à lui déléguer du stake. La commande create-vote-account n’a besoin de la clé privée que pour prouver que vous possédez la clé requise. Une fois le compte de vote créé, seule la clé publique reste nécessaire. Elle ne peut pas être modifiée.
3. Paire de clés de retrait — Cette paire de clés sert de clé principale pour le compte de vote. Elle permet de retirer les récompenses, de modifier l’identité ou la clé de retrait, et d’effectuer d’autres opérations sur le compte. C’est de loin la plus sensible des trois. Elle ne doit pas être générée sur votre serveur ni y être copiée. Pour le mainnet, envisagez d’utiliser un wallet papier, un wallet matériel ou un wallet multi-signatures pour cette clé.

Créez les paires de clés

Créez les paires de clés pour le testnet comme suit :

$ solana-keygen new -o identity.json
$ solana-keygen new -o vote.json
$ solana-keygen new -o withdraw.json

Facultatif : utilisez un wallet papier pour la clé de retrait

Un wallet papier consiste en une phrase de 12 (ou 24) mots notée sur une feuille de papier, puis saisie au clavier chaque fois que la clé doit signer quelque chose. Si vous ne prévoyez pas de configurer un wallet multi-signatures, cette protection supplémentaire convient à la clé de retrait du mainnet, car celle-ci donne un accès racine à votre compte de vote. Exécutez cette commande :

$ solana-keygen new --no-outfile

Notez la phrase affichée sur une feuille de papier. Vous pouvez aussi noter la clé publique, la commande exacte utilisée pour créer la clé et le solana-keygen --version. Sachez qu’il existe plusieurs méthodes pour convertir la phrase secrète en clé privée. Avant de ranger la feuille, vérifiez que vous pouvez l’utiliser pour accéder à la clé :

$ solana-keygen verify <PUBKEY> ASK

Ne perdez surtout pas la feuille sur laquelle la clé est notée, car il n’existe aucun autre moyen de la récupérer. N’oubliez pas d’effacer la phrase clé de la mémoire tampon de votre terminal.

Facultatif : recherchez une clé personnalisée pour le compte de vote

Certains validateurs utilisent des clés publiques personnalisées pour leurs clés d’identité ou de compte de vote. Par exemple, le validateur Helius utilise HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU comme clé d’identité et he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk pour son compte de vote. Vous pouvez les créer avec la sous-commande grind comme suit :

$ solana-keygen grind --starts-with PREF1X:1

Cette sous-commande générera une clé dont la clé publique commence par PREF1X, qui peut correspondre à n’importe quelle chaîne base58 valide de votre choix. Elle génère des clés jusqu’à ce qu’elle en trouve une qui corresponde aux critères. Le temps nécessaire augmente donc de façon exponentielle avec la longueur du préfixe souhaité.

La clé du compte de vote ne peut pas être modifiée, en particulier après l’avoir publiée et une fois que des utilisateurs ont commencé à lui déléguer du stake. Si vous souhaitez une clé personnalisée, c’est le moment de la créer.

Créez le compte de vote à partir des paires de clés

Une fois les paires de clés prêtes, créez le compte de vote comme suit :

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json withdrawal.json

Ici, vote_account.json correspond à la paire de clés du compte de vote, identity.json à la paire de clés d’identité du validateur, withdrawal.json à la paire de clés de l’autorité de retrait et ~/.config/solana/id.json à un wallet contenant les SOL qui serviront à payer la création du compte de vote.

Si vous avez utilisé un wallet papier pour la paire de clés de retrait, votre commande peut ressembler à ceci :

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json ASK

Vous pouvez consulter le compte de vote (ou n’importe quel compte de vote) avec cette commande :

$ solana vote-account <PUBKEY>

À ce stade, la paire de clés d’identité sera nécessaire pour exécuter le serveur du validateur. La paire de clés de retrait devra rester secrète et être utilisée uniquement pour les retraits et les modifications du compte de vote. La paire de clés du compte de vote ne sera plus nécessaire (mais n’oubliez pas sa clé publique).

Vous trouverez ici plus d’informations sur les comptes de vote.

Facultatif : définissez la commission

create-vote-account accepte la commission comme paramètre facultatif. Par défaut, celle-ci est toutefois fixée à 100 %, ce qui signifie que votre validateur est privé. Si vous souhaitez attirer du stake externe vers votre validateur du mainnet, vous devrez probablement choisir une commission moins élevée.

Si la clé publique de notre compte de vote était <VOTE_ACCT_PUBKEY>, que nous souhaitions payer la modification depuis notre wallet approvisionné id.json, que nous disposions d’une clé de retrait sur wallet papier et que nous voulions fixer la commission à 8 %, nous pourrions procéder ainsi :

$ solana vote-update-commission --fee-payer ~/.config/solana/id.json <VOTE_ACCT_PUBKEY> 8 ASK

Facultatif : ajoutez un wallet multi-signatures

Un wallet multi-signatures est un type particulier de wallet qui exige la signature d’un ou plusieurs autres wallets pour exécuter des transactions. Il permet de partager la garde du compte de vote entre plusieurs personnes. Même si vous gérez vous-même le validateur, vous pouvez envisager un wallet multi-signatures pour ajouter facilement d’autres personnes au compte de vote par la suite.

Squads est un outil multi-signatures pour Solana qui propose des fonctionnalités spécialement conçues pour la gestion partagée des validateurs. Pour configurer le validateur dans Squads :

1. Configurez votre navigateur avec une extension de wallet Solana prise en charge, comme Backpack
2. Accédez à la dApp Squads
3. Configurez une squad avec les personnes et les paramètres souhaités pour votre validateur
4. Accédez à Developers > Validators, puis suivez le processus pour ajouter le validateur
5. Il vous sera demandé de coller la clé privée de retrait. Elle permettra de remplacer la clé de retrait existante par la clé de retrait partagée de la squad
6. Vérifiez la clé publique de retrait mise à jour avec solana vote-account

Vous trouverez ici plus d’informations sur l’utilisation de Squads pour la gestion partagée des validateurs.

Configurez votre machine comme serveur de validateur

Les étapes varieront selon la configuration initiale de votre machine, mais l’objectif est d’obtenir :

• La dernière version LTS d’Ubuntu, installée et à jour
  • D’autres distributions Linux (par exemple, basées sur Debian) peuvent également fonctionner, mais tous les exemples présentés ici supposent l’utilisation d’Ubuntu. Plus vous vous éloignez d’Ubuntu, plus vous devrez modifier les commandes
• Un accès SSH configuré au niveau utilisateur
• Un utilisateur de service sol configuré
• Un système optimisé et des disques durs configurés

Configurez le système et l’utilisateur

Assurez-vous que votre système est à jour et créez l’utilisateur de service sol :

$ sudo apt update
$ sudo apt upgrade
$ sudo adduser sol

Vous pouvez également accorder l’accès à sudo (vous sacrifiez alors un peu de sécurité au profit de la simplicité) :

$ sudo adduser sol sudo

Optimisez le système

Ajoutez les paramètres recommandés par Solana Labs à sysctl et systemd pour augmenter les limites relatives au nombre de descripteurs de fichiers, aux fichiers mappés en mémoire, etc. Lorsque votre validateur est le leader de bloc actuel ou à venir, l’ensemble du réseau tente d’ouvrir des connexions et de lui envoyer des transactions. La limite de descripteurs de fichiers est donc particulièrement importante.

Vous trouverez ici les derniers paramètres d’optimisation système recommandés par Solana Labs.

Configurez les disques durs

Solana Labs recommande actuellement d’utiliser deux SSD physiques d’au moins 1 To : l’un pour les données des comptes et l’autre pour celles des registres (le système d’exploitation peut également être installé sur ce disque). En raison du nombre élevé d’IOPS, Solana Labs déconseille de stocker les comptes et les registres sur le même disque.

Voici leur guide pour configurer les deux disques.

Une autre façon d’exploiter plusieurs disques pour augmenter les IOPS disponibles consiste à les regrouper dans un seul volume RAID0 et à laisser le contrôleur RAID optimiser la répartition des bandes entre les disques afin de maximiser leur capacité d’IOPS. Cette approche permet également d’ajouter d’autres disques au RAID afin d’augmenter davantage les IOPS si nécessaire. Nous n’avons encore rencontré aucun problème de performances lors de l’exécution d’un validateur avec cette configuration.

Si vous utilisez un seul volume RAID0, il vous suffit de configurer les répertoires de données du validateur sur votre volume. Vous pouvez le faire directement dans le répertoire personnel de l’utilisateur sol :

$ sudo su sol
$ mkdir -p /home/sol/accounts
$ mkdir -p /home/sol/ledger
$ mkdir -p /home/sol/snapshots
$ mkdir -p /home/sol/logs

Installez Solana CLI sur le serveur du validateur

Répétez les étapes ci-dessus pour installer Solana CLI, cette fois sur le serveur du validateur en tant qu’utilisateur sol. Pour l’installation sur le serveur du validateur, il est vivement recommandé de compiler le logiciel depuis le code source.

Si vous utilisez l’outil d’installation de Solana, vous pouvez exécuter la commande solana-install pour effectuer les futures mises à jour vers de nouvelles versions, ce qui est indispensable pour continuer à participer au cluster.

Facultatif : installez le client de validateur Jito

Jito Labs a créé un fork du validateur Solana et publié sa propre version, qui ajoute la prise en charge de la valeur maximale extractible (MEV). La MEV consiste à ajouter ou à réorganiser des transactions dans un bloc que vous créez afin de générer un bénéfice. Jito a créé un marché pour les personnes prêtes à payer un supplément pour le faire (les « searchers »). Si vous exploitez le validateur Jito, Jito vous enverra des lots de transactions MEV que votre validateur intégrera aux blocs qu’il crée en échange d’un pourboire supplémentaire.

Le validateur Jito ajoute de la complexité et de la latence à vos opérations, mais les pourboires MEV constituent une source de revenus supplémentaire. La configuration est globalement identique, mais vous devrez également étudier les points suivants :

• Collecte et gestion des pourboires MEV
• Latence du moteur de blocs Jito
• Éventuelle exécution d’un relais Jito

Vous trouverez ici les instructions d’installation du client de validateur Jito.

Créez les scripts d’exécution du validateur

Créez le script shell validator.sh

Commencez par copier la paire de clés d’identité de votre validateur sur le serveur distant :

$ scp identity.json remoteuser@your.validator.host:/home/sol

La méthode standard de gestion de la configuration de votre validateur consiste à l’encapsuler dans un script shell. Créez un script comme point de départ et rendez-le exécutable :

$ sudo su sol
$ cat >/home/sol/validator.sh <<EOF
#!/bin/bash
PATH=/home/sol/.local/share/solana/install/active_release/bin:$PATH
exec solana-validator \
    --identity /home/sol/identity.json \
    --vote-account <VOTE_ACCOUNT_PUBKEY> \
    --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
    --known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
    --known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
    --known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
    --only-known-rpc \
    --log /home/sol/logs/solana-validator.log \
    --accounts /home/sol/accounts \
    --snapshots /home/sol/snapshots \
    --ledger /home/sol/ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.testnet.solana.com:8001 \
    --entrypoint entrypoint2.testnet.solana.com:8001 \
    --entrypoint entrypoint3.testnet.solana.com:8001 \
    --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size
EOF
$ chmod +x /home/sol/validator.sh

Ces paramètres permettent de démarrer rapidement et en toute sécurité sur le testnet. Une fois l’ensemble configuré, vous devrez revenir à ce script et exécuter solana-validator --help pour afficher la liste complète des options de configuration et le personnaliser.

Essayez de lancer le validateur à l’aide du script :

$ ./validator.sh

Lors de son premier démarrage, il devra se synchroniser avec l’état actuel du cluster.

Vérifiez que le validateur fonctionne correctement

Vous pouvez suivre votre progression visible de l’extérieur, ou celle de n’importe qui, depuis n’importe quel emplacement du cluster avec :

$ solana catchup <IDENTITY_PUBKEY>

Depuis une session ouverte en tant qu’utilisateur sol, vous pouvez suivre sa progression en interne avec :

$ solana-validator --ledger /home/sol/ledger monitor

Vous trouverez ici plus d’informations pour vérifier que votre validateur se connecte correctement au cluster.

Configurez le validateur comme processus daemon

Créez un fichier systemd unit afin de le gérer comme un daemon :

$ sudo cat >/etc/systemd/system/sol.service <<EOF
[Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=sol
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
ExecStart=/home/sol/validator.sh

[Install]
WantedBy=multi-user.target
EOF

Assurez-vous que l’instance ./validator.sh lancée précédemment ne s’exécute plus, puis démarrez le validateur comme daemon :

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now sol

Configurez la surveillance et la sécurité

Désactivez l’authentification par mot de passe

Dans votre fichier /etc/ssh/sshd_config, vous pouvez configurer le daemon SSH pour qu’il refuse les connexions par mot de passe ou par question-réponse :

...
PasswordAuthentication no
ChallengeResponseAuthentication no
...

N’oubliez pas de recharger le daemon sshd avec la nouvelle configuration :

$ sudo systemctl reload sshd

Ajoutez fail2ban et ufw

fail2ban fonctionne immédiatement et bloque les connexions qui échouent plusieurs fois à s’authentifier :

$ sudo apt install fail2ban

ufw est un pare-feu fourni avec le système, que vous pouvez configurer avec quelques commandes, en supposant que la configuration finale de votre validateur utilise les ports et plages de ports par défaut et héberge SSH sur le port 22 :

$ sudo ufw allow 22/tcp
$ sudo ufw allow 8000:10000/tcp
$ sudo ufw allow 8000:10000/udp
$ sudo ufw enable

Paire de clés d’identité du validateur

Dans la pratique, la plupart des validateurs conservent leur clé d’identité sur leur serveur afin que le script du validateur puisse s’exécuter et redémarrer sans intervention humaine. Il est toutefois possible d’utiliser ASK ou prompt:// pour transmettre la clé d’identité au validateur, sans avoir à la stocker dans le système de fichiers du serveur. Cette méthode augmente votre charge opérationnelle et les risques, car une personne doit alors remplacer systemd et gérer manuellement le processus daemon, mais elle reste possible.

La meilleure stratégie pour sécuriser votre paire de clés d’identité consiste à ne l’approvisionner qu’avec le minimum de SOL nécessaire pour couvrir quelques jours de frais de vote.

Shinobi Systems a publié des outils pour faciliter la gestion des comptes de vote, notamment le transfert automatique des soldes hors du compte de vote sans utiliser systématiquement la clé de retrait.

Consultez la page de Solana Labs sur la sécurité des validateurs pour obtenir d’autres conseils.

Configurez la surveillance avec Watchtower

solana-watchtower est inclus dans la suite d’outils Solana CLI. Il permet de vous alerter en cas de problème avec votre validateur ou l’ensemble du cluster. Vous pouvez le configurer et l’exécuter de façon similaire au validateur lui-même en créant un script watchtower.sh.

Voici un exemple qui utilise PagerDuty pour les alertes et écrit les journaux dans watchtower.log :

$ cat >watchtower.sh <<EOF
#!/bin/bash
PATH=/home/solana/.local/share/solana/install/active_release/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

exec &gt;>watchtower.log \\
  env PAGERDUTY_INTEGRATION_KEY=<PAGERDUTY_KEY> \\
solana-watchtower \\
  --validator-identity <IDENTITY_PUBKEY> \\
  --monitor-active-stake \\
  --interval 20 \\
  --minimum-validator-identity-balance 3 \\
  --url https://api.testnet.solana.com
EOF

Solana Labs propose également un exemple de configuration utilisant Telegram pour les alertes.

Il est déconseillé de configurer watchtower sur la même machine que votre validateur, car vous ne recevrez aucune notification si toute la machine tombe en panne. Cette approche peut toutefois convenir si vous avez mis en place plusieurs formes de surveillance et pouvez contrôler ces situations séparément.

Contrairement au validateur, watchtower consomme peu de ressources et peut s’exécuter depuis un environnement de cloud computing ou serverless, comme ceux proposés par AWS ou GCP.

Facultatif : surveillance communautaire

De nombreux membres de la communauté Solana surveillent également le cluster et proposent des alertes reposant sur des conditions similaires à celles de watchtower.

Stakewiz propose une surveillance des validateurs Solana via Telegram. Par exemple, pour recevoir des alertes concernant le validateur Helius, vous pouvez accéder à sa page, puis cliquer sur « + Create Alert ».

Notez que la surveillance communautaire vise à informer les utilisateurs des problèmes touchant les validateurs auprès desquels ils placent leur stake. En tant qu’exploitant de validateur, vous ne devez pas compter uniquement sur des tiers pour surveiller vos services.

Facultatif : surveillance personnalisée via la méthode RPC getHealth

Pour vérifier directement l’état de santé de votre validateur, son interface JSON RPC propose une méthode appelée getHealth. Vous pouvez l’interroger régulièrement pour savoir si votre validateur fonctionne correctement et obtenir des informations sur les éventuels problèmes.

Facultatif : solutions de surveillance tierces

Une fois votre validateur déployé à grande échelle et vos revenus établis, vous pouvez envisager des solutions SaaS de surveillance professionnelles, comme Datadog ou Splunk. Ces solutions fonctionnent généralement de deux manières : soit elles exécutent sur votre serveur un processus daemon qui surveille localement les journaux et les métriques, puis les exporte vers le fournisseur, soit elles rendent getHealth ou un endpoint d’état similaire accessible afin que le fournisseur puisse interroger votre validateur à distance.

Ajoutez du stake au validateur

Le réseau Solana atteint le consensus grâce à un processus de vote par preuve d’enjeu (PoS), ce qui signifie que le poids de vote d’un validateur est proportionnel à la quantité de SOL qui lui est déléguée en stake. Le fonctionnement est comparable à celui d’une société par actions si vous considérez les SOL stakés comme des actions. Outre le vote, la fréquence à laquelle votre validateur devient leader de bloc est proportionnelle à la quantité de SOL qui lui est attribuée en stake.

De nombreux wallets, dApps et autres outils facilitent le staking de vos SOL auprès de validateurs existants. Voici toutefois comment procéder manuellement avec la CLI :

1. Créez 3 paires de clés avec solana-keygen new
2. Créez un compte de stake à partir des paires de clés avec solana create-stake-account
3. Transférez des SOL vers le compte de stake (vous pouvez utiliser solana aidrop pour le testnet)
4. Déléguez le stake déposé à un validateur avec solana delegate-stake
5. Attendez l’epoch suivant pour l’activation du stake, puis vérifiez son état avec solana stake-account

Créez les paires de clés et le compte de stake

Le processus de création des paires de clés et du compte de stake est similaire à celui du compte de vote. Les trois paires de clés sont les suivantes :

1. Paire de clés de l’autorité de stake - permet d’effectuer des opérations sur le compte de stake, comme la délégation, l’annulation de délégation, la division et la fusion
2. Paire de clés du compte de stake - clé publique qui identifie le compte de stake lui-même (la clé privée n’est plus nécessaire après la création du compte)
3. Paire de clés de retrait - paire de clés principale permettant de retirer le stake et de réinitialiser les paires de clés d’autorité du compte de stake. Manipulez-la avec précaution et envisagez un wallet matériel, un wallet papier ou un wallet multi-signatures

Il est vivement recommandé d’utiliser des clés distinctes pour le testnet et le mainnet, pour les mêmes raisons que pour le compte de vote. Vous pouvez toutefois réutiliser une même paire de clés d’autorité de stake et d’autorité de retrait pour plusieurs comptes de stake au sein d’un même cluster. L’utilisation des mêmes clés pour les comptes de stake est indispensable pour pouvoir les fusionner.

Voici un exemple de création d’un compte de stake contenant 1 SOL sur le testnet. Il utilise des wallets basés sur des fichiers pour les paires de clés, l’approvisionne depuis votre wallet id.json, puis délègue ce stake à votre nouveau validateur :

$ solana-keygen new -o stake_auth.json
$ solana-keygen new -o stake_acct_1.json
$ solana-keygen new -o stake_withdrawal_auth.json
$ solana airdrop 1 ~/.config/solana/id.json
$ solana create-stake-account --from ~/.config/solana/id.json stake_acct_1.json 1 --stake-authority stake_auth.json --withdraw-authority stake_withdraw_auth.json --fee-payer ~/.config/solana/id.json
$ solana delegate-stake --stake-authority stake_auth.json <STAKE_ACCT_1_PUBKEY> <VOTE_ACCT_PUBKEY> --fee-payer ~/.config/solana/id.json

Vous pouvez maintenant consulter son état pour vérifier si le stake est en cours d’activation et connaître l’epoch auquel il deviendra actif :

$ solana stake-account <STAKE_ACCT_1_PUBKEY>

Une fois l’epoch suivant commencé et le stake actif, les votes de votre validateur commenceront à compter. Vous pourrez consulter les votes récents dans la sortie de la commande solana vote-account. Si vous n’avez ajouté que quelques SOL, comme dans l’exemple, ne vous attendez pas à ce que votre validateur devienne leader de bloc.

Le vote coûte environ 1 à 2 SOL par jour. À l’heure où nous écrivons ces lignes, voter sur le mainnet coûterait donc à votre validateur environ 200 à 300 $ par jour.

(Plus d’informations sur la délégation de stake et la gestion des comptes de stake).

Publiez les informations du validateur

Si vous parcourez les annuaires courants de validateurs Solana, comme validators.app, vous remarquerez que tous les validateurs disposent d’un nom, d’une description, d’un logo et d’autres métadonnées. Ces données sont publiées on-chain pour tous les validateurs enregistrés dans chaque cluster. Vous pouvez les consulter en exécutant solana validator-info get.

Une fois votre validateur opérationnel, vous pouvez publier ses informations, en particulier lorsque vous l’exploitez sur le mainnet et cherchez à attirer du stake.

Voici un exemple simple de publication de vos métadonnées :

$ solana validator-info publish "My Awesome Validator" \
--website "https://awesome-validator.xyz/" \
--icon-url "https://awesome-validator.xyz/icon360x360.png" \
--keypair validator_identity.json \
--details "The best validator in the world!"

Une fois créé, l’enregistrement de métadonnées possède sa propre clé. Vous pouvez le mettre à jour ultérieurement avec l’argument --info-pubkey. Notez que l’URL de l’icône ne peut pas dépasser 80 caractères. Vous trouverez ici plus d’informations sur la publication des informations et métadonnées du validateur.

Conclusion

Félicitations ! Si vous avez suivi toutes les étapes jusqu’ici, votre propre validateur Solana devrait maintenant être opérationnel. Bienvenue dans la communauté des validateurs Solana !

Ressources supplémentaires

• Présentation des validateurs Solana
• Documentation des validateurs Solana
• Solana Foundation Delegation Program
• Solana Foundation - Pools de staking