Como configurar um validador da Solana

Terminologia: o que é um validador da Solana?

O conjunto de ferramentas da Solana CLI contém o binário solana-validator, que pode:

• Conectar-se a um cluster da Solana e sincronizar o estado atual do cluster
• Produzir, receber e compartilhar snapshots e outros dados do cluster para se manter atualizado
• Votar para verificar novos blocos como parte do consenso do cluster
• Processar transações recebidas e produzir novos blocos
• Disponibilizar APIs RPC e orientadas a eventos para permitir consultas aos dados do cluster e o envio de novas transações

Um validador da Solana também pode ser chamado de cliente (pois se conecta à rede de validadores e solicita dados), servidor (pois processa solicitações de outros validadores e fornece dados a eles) ou nó.

Um nó RPC é um validador da Solana sem stake e sem direito a voto que acompanha todas as informações da rede. Isso significa que ele apenas responde a solicitações de dados e não participa do consenso.

O termo “validador da Solana” também pode se referir a uma entidade do ecossistema Solana que opera um validador da Solana com stake e direito a voto, participando do consenso.

Mais informações sobre a diferença entre RPCs, provedores de RPC e validadores estão disponíveis aqui.

Primeiros passos: obtenha o hardware do servidor

Você precisará de um computador potente dedicado exclusivamente à operação do validador e de um segundo se quiser operar validadores tanto na testnet quanto na mainnet. Atualmente, a recomendação mínima é de 12 núcleos/24 threads, 256 GB de RAM, 2 discos SSD de 1 TB (idealmente com RAID0) e uma conexão de internet de 10 GB. Os requisitos de hardware estão disponíveis em mais detalhes aqui.

Se você estiver pensando em economizar operando apenas na mainnet, saiba que é necessário operar um validador na testnet para se qualificar para o Programa de Delegação da Solana Foundation (SFDP).

Você pode comprar e operar o hardware por conta própria ou alugá-lo de um provedor de data center (recomendamos a TeraSwitch). Também pode alugá-lo de um provedor de computação em nuvem, mas não recomendamos essa opção, pois costuma ter um custo proibitivo e estar mais sujeita a problemas de desempenho. O Solana Foundation Server Program busca facilitar o aluguel de hardware de operadores de data center por operadores de validadores. Saiba mais aqui.

Para ajudar a descentralizar a rede, considere ASNs e cidades que ainda não tenham muitos nós ou stake da Solana. Alguns pools de staking e o SFDP oferecerão recompensas com base na descentralização por ASN e cidade.

Os principais data centers atuais estão disponíveis aqui.

Instale a Solana CLI localmente

É altamente recomendável instalar as ferramentas localmente para gerar todas as chaves necessárias no seu ambiente e manter a chave de saque fora do servidor do validador. As instruções para configurar a Solana CLI localmente estão disponíveis aqui.

Quando as ferramentas estiverem disponíveis localmente na sua linha de comando, configure-as para apontar para a testnet por padrão:

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

Para a mainnet, você pode apontar para o endpoint padrão aqui:

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

Os endpoints públicos da mainnet costumam ficar sobrecarregados com solicitações. Se você não estiver satisfeito com o desempenho, pode criar uma conta na Helius e usar seu endpoint da Helius assim:

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

A configuração e a inicialização do validador exigirão a execução de transações. Portanto, você precisa ter uma carteira configurada com algum SOL. Se estiver começando com a testnet, poderá criar uma carteira padrão e fazer um airdrop de SOL para si mesmo com os seguintes comandos:

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

É altamente recomendável usar carteiras diferentes para a testnet e a mainnet. Como o formato das chaves é o mesmo, é possível usar as mesmas chaves em ambas, mas resista a essa tentação. Se você usar as mesmas chaves para carteiras com fundos na testnet e na mainnet, poderá executar acidentalmente na mainnet comandos destinados à testnet.

Leia mais sobre como gerar chaves aqui, além de conhecer métodos mais seguros de geração de chaves.

Configure a conta de voto

A conta de voto do seu validador é criada com o comando solana create-vote-account e três pares de chaves:

1. Par de chaves de identidade — O validador usa esse par de chaves para se identificar na rede e enviar transações, como votos. A chave privada precisará ficar no servidor. Portanto, a prática mais segura é não manter nela mais SOL do que o necessário para as transações de voto (cerca de 1 SOL/dia).
2. Par de chaves da conta de voto — Esse par de chaves se refere à própria conta de voto e é usado para consultar a conta de voto e delegar stake a ela. O comando create-vote-account só precisa da chave privada para comprovar que você possui a chave necessária. Após a criação da conta de voto, apenas a chave pública será necessária. Isso não pode ser alterado.
3. Par de chaves de saque — Esse par de chaves funciona como uma chave mestra da conta de voto e é usado para sacar recompensas, alterar a identidade ou a chave de saque e realizar outras operações na conta. Essa chave é, de longe, a mais sensível das três e não deve ser gerada nem copiada para o servidor. Na mainnet, considere usar uma carteira de papel, uma carteira de hardware ou uma multi-sig para essa chave.

Crie os pares de chaves

Crie os pares de chaves para a testnet da seguinte forma:

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

Opcional: use uma carteira de papel para a chave de saque

Uma carteira de papel é uma frase de 12 (ou 24) palavras anotada em uma folha de papel e digitada pelo teclado sempre que a chave precisa assinar algo. Se você não pretende configurar uma multi-sig, a segurança adicional oferecida por ela é adequada para a chave de saque da mainnet, pois essa chave concede acesso root à sua conta de voto. Execute este comando:

$ solana-keygen new --no-outfile

Anote em uma folha de papel a frase exibida. Você também pode anotar a chave pública, o comando exato usado para criar a chave e o solana-keygen --version. Saiba que existem diferentes métodos para converter a frase secreta em uma chave privada. Antes de guardar a folha, confirme que você consegue usá-la para acessar a chave:

$ solana-keygen verify <PUBKEY> ASK

Em hipótese alguma perca a folha de papel com a chave anotada, pois não há outra forma de recuperá-la. Não se esqueça de apagar a frase da chave do buffer do terminal.

Opcional: encontre uma chave personalizada para a conta de voto

Alguns validadores têm chaves públicas personalizadas para as chaves de identidade ou da conta de voto. Por exemplo, o validador da Helius usa HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU como chave de identidade e he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk como conta de voto. Você pode criá-las com o subcomando grind da seguinte forma:

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

Esse subcomando gerará uma chave cuja chave pública começa com PREF1X, que pode ser qualquer string base58 válida especificada por você. Para isso, ele gera chaves até encontrar uma que corresponda aos critérios. Portanto, o tempo necessário cresce exponencialmente conforme o tamanho do prefixo desejado.

A chave da conta de voto não pode ser alterada, especialmente depois que você a divulgar e as pessoas começarem a delegar stake a ela. Portanto, se quiser uma chave personalizada, este é o momento de criá-la.

Crie a conta de voto usando os pares de chaves

Quando os pares de chaves estiverem prontos, crie a conta de voto da seguinte forma:

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

Aqui, vote_account.json é o par de chaves da conta de voto, identity.json é o par de chaves de identidade do validador, withdrawal.json é o par de chaves da autoridade de saque e ~/.config/solana/id.json é uma carteira com SOL que será usado para pagar pela criação da conta de voto.

Se você usou uma carteira de papel para o par de chaves de saque, seu comando poderá ter esta aparência:

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

Você pode consultar a conta de voto (ou qualquer conta de voto) com este comando:

$ solana vote-account <PUBKEY>

Neste ponto, o par de chaves de identidade será necessário para executar o servidor do validador, o par de chaves de saque deverá ser mantido em sigilo e usado somente para saques e alterações na conta de voto, e o par de chaves da conta de voto não será mais necessário (apenas não se esqueça da chave pública).

Mais informações sobre contas de voto estão disponíveis aqui.

Opcional: defina a comissão

O create-vote-account aceita a comissão como parâmetro opcional, mas o padrão é 100%, indicando que seu validador é privado. Se quiser atrair stake externo para seu validador da mainnet, você provavelmente precisará escolher uma comissão menor.

Se a chave pública da nossa conta de voto fosse <VOTE_ACCT_PUBKEY>, quiséssemos pagar pela alteração com nossa carteira com fundos id.json, tivéssemos uma chave de saque em uma carteira de papel e quiséssemos definir a comissão como 8%, poderíamos fazer assim:

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

Opcional: adicione uma multi-sig

Uma multi-sig é um tipo especial de carteira que exige as assinaturas de uma ou mais carteiras adicionais para executar transações. Ela pode ser usada para compartilhar a custódia da conta de voto entre várias pessoas. Mesmo que você gerencie o validador sozinho, pode ser útil considerar uma multi-sig para adicionar outras pessoas à conta de voto com facilidade no futuro.

O Squads é uma ferramenta multi-sig para Solana que inclui funcionalidades específicas para gerenciar validadores compartilhados. Para configurar o validador no Squads:

1. Configure seu navegador com um plugin de carteira da Solana compatível, como o Backpack
2. Acesse o dApp do Squads
3. Configure um squad com as pessoas e os parâmetros desejados para seu validador
4. Acesse Developers > Validators e siga o fluxo para adicionar o validador
5. Você deverá colar a chave privada de saque, que será usada para substituir a chave de saque existente pela chave de saque compartilhada do squad
6. Verifique a chave pública de saque atualizada usando solana vote-account

Mais informações sobre o uso do Squads para o gerenciamento compartilhado de validadores estão disponíveis aqui.

Configure sua máquina como servidor de validador

As etapas variam de acordo com o estado inicial da sua máquina, mas o objetivo é chegar ao seguinte resultado:

• Versão LTS mais recente do Ubuntu instalada e atualizada
  • Outras distribuições Linux (por exemplo, baseadas em Debian) também podem funcionar, mas todos os exemplos aqui pressupõem o Ubuntu; quanto mais você se afastar do Ubuntu, mais precisará modificar os comandos
• Acesso SSH no nível do usuário configurado
• Usuário de serviço sol configurado
• Ajustes do sistema e discos rígidos configurados

Configuração do sistema e do usuário

Verifique se o sistema está atualizado e crie o usuário de serviço sol:

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

Você também pode conceder acesso a sudo (isso troca um pouco de segurança por conveniência):

$ sudo adduser sol sudo

Ajustes do sistema

Adicione as configurações recomendadas pela Solana Labs a sysctl e systemd para aumentar os limites permitidos de descritores de arquivos, arquivos mapeados em memória e outros recursos. Quando seu validador for o líder de bloco atual ou seguinte, toda a rede tentará abrir conexões e enviar transações a ele. Por isso, o limite de descritores de arquivos é particularmente importante.

As configurações mais recentes de ajuste do sistema recomendadas pela Solana Labs estão disponíveis aqui.

Configuração dos discos rígidos

A recomendação atual da Solana Labs é ter 2 SSDs físicos de 1 TB ou mais: um para os dados das contas e outro para os dados dos ledgers (o sistema operacional também pode ficar nesse disco). Não é recomendável manter as contas e os ledgers no mesmo disco devido ao alto volume de IOPS.

Confira o guia da Solana Labs para configurar os 2 discos.

Uma forma alternativa de aproveitar vários discos para aumentar as IOPS disponíveis é configurá-los juntos em um único volume RAID0 e deixar o controlador RAID otimizar quais stripes são armazenados em cada disco, maximizando a capacidade de IOPS de ambos. Isso também permite adicionar outros discos ao RAID para aumentar ainda mais as IOPS, se necessário. Até o momento, não tivemos problemas de desempenho ao operar um validador com essa configuração.

Se você estiver usando um único volume RAID0, basta configurar nele os diretórios de dados do validador, o que pode ser feito diretamente no diretório inicial do usuário sol:

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

Instale a Solana CLI no servidor do validador

Repita as etapas acima para instalar a Solana CLI, mas desta vez no servidor do validador como o usuário sol. Ao instalar no servidor do validador, é altamente recomendável compilar a partir do código-fonte.

Se você usar a ferramenta de instalação da Solana, poderá usar o comando solana-install para fazer atualizações futuras para novas versões, o que é obrigatório para continuar participando do cluster.

Opcional: instale o cliente validador da Jito

A Jito Labs criou um fork do validador da Solana e lançou sua própria versão, adicionando recursos de Valor Máximo Extraível (MEV). MEV é o conceito de adicionar ou reordenar transações dentro de um bloco que você está criando para obter lucro. A Jito criou um mercado para pessoas que querem pagar um valor adicional para fazer isso (os “searchers”). Se você operar o validador da Jito, ela enviará pacotes de transações MEV para seu validador incluir nos blocos criados em troca de uma gorjeta adicional.

O validador da Jito adiciona alguma complexidade e latência às operações do seu validador, mas também oferece gorjetas de MEV como fonte adicional de receita. A configuração é praticamente a mesma, mas você também precisará analisar:

• Coleta e gerenciamento de gorjetas de MEV
• Latência do mecanismo de blocos da Jito
• Possível operação de um relayer da Jito

As instruções para instalar o cliente validador da Jito estão disponíveis aqui.

Crie scripts para executar o validador

Crie o script de shell validator.sh

Primeiro, copie o par de chaves de identidade do validador para o servidor remoto:

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

A forma padrão de gerenciar a configuração do seu validador é envolvê-la em um script de shell. Crie um script como ponto de partida e torne-o executável:

$ 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

Essas configurações são adequadas para começar a operar com rapidez e segurança na testnet. Depois que tudo estiver configurado, você precisará voltar a esse script e executar solana-validator --help para ver a lista completa de opções de configuração e personalizá-lo.

Tente iniciar o validador usando o script:

$ ./validator.sh

Na primeira inicialização, ele precisará alcançar o estado atual do cluster.

Verifique se o validador está funcionando corretamente

Você pode acompanhar de qualquer ponto do cluster o progresso visível externamente do seu validador ou de qualquer outro usando:

$ solana catchup <IDENTITY_PUBKEY>

Você pode ver o progresso internamente, em uma sessão como o usuário sol, com:

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

Mais informações sobre como verificar se o validador está se conectando corretamente ao cluster estão disponíveis aqui.

Configure o validador como um processo daemon

Crie um arquivo systemd unit para que ele seja gerenciado como um 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

Verifique se a execução anterior de ./validator.sh não está mais ativa e inicie o validador como um daemon:

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

Configure o monitoramento e a segurança

Desative a autenticação por senha

No arquivo /etc/ssh/sshd_config, o daemon SSH pode ser configurado para não aceitar métodos de login por senha nem por desafio-resposta:

...
PasswordAuthentication no
ChallengeResponseAuthentication no
...

Não se esqueça de recarregar o daemon sshd com a nova configuração:

$ sudo systemctl reload sshd

Adicione fail2ban e ufw

O fail2ban funciona imediatamente para bloquear conexões que falharem na autenticação várias vezes:

$ sudo apt install fail2ban

ufw é um firewall fornecido com o sistema e pode ser configurado com alguns comandos, supondo que a configuração final do validador use as portas e os intervalos de portas padrão e hospede o SSH na porta 22:

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

Par de chaves de identidade do validador

Na prática, a maioria dos validadores mantém a chave de identidade no servidor do validador para que o script possa ser executado e reiniciado sem intervenção humana. No entanto, é possível usar ASK ou prompt:// para fornecer a chave de identidade ao validador sem precisar mantê-la no sistema de arquivos do servidor. Isso aumenta a sobrecarga e o risco operacional, pois uma pessoa precisa assumir o papel de systemd e gerenciar manualmente o processo daemon, mas é possível.

A melhor estratégia para proteger seu par de chaves de identidade é manter nele apenas a quantidade mínima de SOL necessária para cobrir alguns dias de custos de votação.

A Shinobi Systems disponibilizou algumas ferramentas para ajudar a gerenciar contas de voto, incluindo transferências automáticas de saldo para fora da conta de voto sem precisar usar a chave de saque todas as vezes.

Consulte a página da Solana Labs sobre segurança de validadores para ver mais dicas.

Configure o monitoramento com o Watchtower

solana-watchtower está incluído no conjunto de ferramentas da Solana CLI e pode ser usado para alertar sobre problemas com seu validador e com o cluster em geral. Você pode configurá-lo e executá-lo de forma semelhante ao próprio validador, criando um script watchtower.sh.

Veja um exemplo que usa o PagerDuty para alertas e grava os logs em 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

A Solana Labs também tem um exemplo de como configurá-lo usando o Telegram para alertas.

Não é recomendável configurar o watchtower na mesma máquina do validador, pois você não receberá notificações se toda a máquina ficar indisponível. No entanto, isso pode ser aceitável se você tiver várias formas de monitoramento e puder acompanhar esses casos separadamente.

Ao contrário do validador, o watchtower não consome muitos recursos e pode ser executado em um ambiente de computação em nuvem ou serverless, como os oferecidos pela AWS ou pelo GCP.

Opcional: monitoramento feito pela comunidade

Muitas pessoas da comunidade Solana também monitoram o cluster e estão dispostas a oferecer alertas com base em condições semelhantes às oferecidas pelo watchtower.

O Stakewiz oferece monitoramento de validadores da Solana pelo Telegram. Por exemplo, se você quisesse receber alertas sobre o validador da Helius, poderia acessar a página dele e clicar em “+ Criar alerta”.

Observe que o monitoramento feito pela comunidade foi projetado para informar as pessoas sobre problemas nos validadores aos quais delegaram stake. Como operador de um validador, você não deve depender exclusivamente de terceiros para monitorar seus serviços.

Opcional: monitoramento personalizado pelo método RPC getHealth

Se você quiser consultar diretamente a integridade do seu validador, a interface JSON RPC dele tem um método chamado getHealth, que pode ser consultado periodicamente para saber se o validador está íntegro e obter informações sobre eventuais problemas.

Opcional: soluções de monitoramento de terceiros

Quando seu validador estiver operando em escala e você tiver uma fonte de receita para proteger, considere soluções SaaS de monitoramento de nível comercial, como Datadog ou Splunk. Esses tipos de solução geralmente funcionam executando um processo daemon no servidor, que monitora logs e métricas localmente e os exporta para o provedor, ou disponibilizando o getHealth ou um endpoint de status semelhante para que o provedor consulte seu validador remotamente.

Adicione stake ao validador

A rede Solana chega a um consenso por meio de um processo de votação de proof-of-stake (PoS). Isso significa que o peso de voto de um validador é proporcional à quantidade de stake em SOL delegada a ele, de forma semelhante ao funcionamento de uma sociedade por ações se você considerar o SOL em staking como ações. Além da votação, a frequência com que seu validador se torna líder de bloco é proporcional à quantidade de SOL em stake nele.

Há muitas carteiras, dApps e outras ferramentas que facilitam o staking do seu SOL em validadores existentes, mas estas são as etapas para fazer isso manualmente com a CLI:

1. Crie 3 pares de chaves usando solana-keygen new
2. Crie uma conta de stake a partir dos pares de chaves usando solana create-stake-account
3. Transfira algum SOL para a conta de stake (isso pode ser feito com solana aidrop na testnet)
4. Delegue o stake depositado a um validador usando solana delegate-stake
5. Aguarde a próxima época para que o stake seja ativado e verifique com solana stake-account

Crie os pares de chaves e a conta de stake

O processo de criação dos pares de chaves e da conta de stake é semelhante ao da criação da conta de voto, com os 3 pares de chaves a seguir:

1. Par de chaves da autoridade de stake - permite tarefas operacionais na conta de stake, como delegar, remover delegação, dividir e mesclar
2. Par de chaves da conta de stake - a chave pública que identifica a própria conta de stake (a chave privada não é necessária após a criação da conta de stake)
3. Par de chaves de saque - o par de chaves mestre para sacar stake e redefinir pares de chaves de autoridade na conta de stake. Trate-o com cuidado e considere usar uma carteira de hardware, uma carteira de papel ou uma multi-sig

É altamente recomendável usar chaves separadas para a testnet e a mainnet pelos mesmos motivos aplicáveis à conta de voto. No entanto, você pode reutilizar um único par de chaves de autoridade de stake e de autoridade de saque em várias contas de stake dentro do mesmo cluster. Usar as mesmas chaves nas contas de stake é um pré-requisito para mesclá-las.

Veja um exemplo de criação de uma conta de stake com 1 SOL na testnet usando carteiras baseadas em arquivos para os pares de chaves, financiando-a com sua carteira id.json e delegando esse stake ao seu novo validador:

$ 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

Agora você pode consultá-la para verificar se o stake está sendo ativado e em qual época ficará ativo:

$ solana stake-account <STAKE_ACCT_1_PUBKEY>

Quando a próxima época começar e o stake estiver ativo, os votos do seu validador começarão a contar, e você poderá ver os votos recentes como parte do comando solana vote-account. Se você adicionou apenas alguns SOL, como no exemplo, não espere que seu validador se torne líder de bloco.

A votação custa cerca de 1 a 2 SOL por dia. Portanto, no momento da publicação, seu validador gastaria aproximadamente US$ 200 a US$ 300 por dia apenas para votar na mainnet.

(Mais informações sobre delegação de stake e gerenciamento de contas de stake).

Publique as informações do validador

Se você consultar diretórios comuns de validadores da Solana, como o validators.app, perceberá que todos os validadores têm nome, descrição, logotipo e outros metadados. Esses dados são publicados on-chain para todos os validadores registrados em cada cluster e podem ser visualizados executando solana validator-info get.

Quando seu validador estiver em funcionamento, talvez você queira publicar suas informações, especialmente ao operar na mainnet e tentar atrair stake.

Veja um exemplo básico de como publicar seus metadados:

$ 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!"

Quando o registro de metadados for criado, ele terá sua própria chave, que poderá ser atualizada posteriormente com o argumento --info-pubkey. Observe que a URL do ícone pode ter no máximo 80 caracteres. Mais informações sobre a publicação de informações e metadados do validador estão disponíveis aqui.

Conclusão

Parabéns! Se você acompanhou todas as etapas e chegou até aqui, seu próprio validador da Solana já deve estar em funcionamento. Boas-vindas à comunidade de validadores da Solana!

Recursos adicionais

• Visão geral dos validadores da Solana
• Documentação de validadores da Solana
• Programa de Delegação da Solana Foundation
• Solana Foundation — pools de stake