PERSPECTIVA DO DESENVOLVEDOR | Como se Tornar um Validador Ethereum Solo

Pense nisso por um segundo,

Uma blockchain é apenas uma grande base de dados única que não pertence a ninguém, mas pode ser escrita por qualquer um, e tudo que nela for escrito não pode ser apagado. Para escrever nela, é preciso ter uma cópia da base de dados no seu computador.

Então, finalmente percebeu o quão bom investimento é tornar-se um validador do Ethereum e decidiu tentar ver quanto consegue ganhar?

Primeiro, parabéns. Isso é uma grande responsabilidade e, em nome da comunidade Ethereum, agradeço (por qualquer motivo que tenha para se tornar um validador — ganhar recompensas de bloco, tornar o Ethereum mais descentralizado etc) pela sua iniciativa audaciosa.

Na mesma linha de descentralização, vamos ver como ser um validador solo, ou como é conhecido de forma mais elegante, fazer staking solo no Ethereum.

Não vamos abordar outras formas de staking, como staking líquido, staking como serviço ou similares. Quero dizer, você decidiu ser um validador, por que não fazer do jeito cypherpunk, hein?

Vamos nos familiarizar com alguns termos primeiro:

O Ethereum é uma blockchain de Prova de Participação (Proof of Stake) desde que aconteceu o “The Merge” em 15 de setembro de 2022, que mudou o Ethereum de Prova de Trabalho (PoW) para Prova de Participação (PoS).

Isso significa que a forma como o Ethereum alcança consenso mudou completamente.

Lembra como dissemos que uma blockchain é apenas uma grande única base de dados em vários computadores? Bem, o estado dessa base de dados precisa ser conhecido por todos os computadores na rede o tempo todo. Os computadores (nós, os nós) participantes na rede precisam concordar sobre qual é o estado atual da base de dados, ou seja, alcançar consenso!

Os nós do Ethereum não precisam resolver problemas matemáticos complexos para alcançar consenso, como era no PoW, mas sim, eles bloqueiam uma quantidade de éter (ETH) de antemão, basicamente dizendo:

“Ei, estou disposto a ser um validador que irá adicionar blocos e verificar transações, e se eu me comportar mal de alguma forma enquanto faço isso, você pode tirar o éter que eu depoistei de antemão (meu stake) como punição. Se eu me comportar corretamente, você me recompensa com éter recém-criado!”

Quando mais de dois terços dos validadores concordam com o estado atual da base de dados, o estado da blockchain é considerado finalizado!

Por que dois terços de todos os validadores?

Imagine se tivéssemos que esperar que todos os validadores (no momento da escrita, Ethereum tem 1.031.682 validadores ativos) na rede concordassem com o estado da blockchain? A velocidade de finalização da blockchain seria muito lenta, tornando o Ethereum praticamente inutilizável. A velocidade de finalização de uma blockchain é tão rápida quanto o seu nó mais lento, e considerando que o Ethereum é altamente descentralizado (ou seja, pode ser executado em hardware comum de consumo, que geralmente é mais lento do que computadores institucionais de alta performance), temos que levar em conta o nó mais lento. Então, dois terços não parecem um número ruim para esperar, após esse argumento não tão convincente, estou certo… 😂😂😂

O modelo de segurança do Ethereum agora pode ser resumido como “Seres humanos são criaturas racionais que querem lucrar e tomarão decisões racionais para alcançar esses lucros. Portanto, eles não se comportarão mal, pois, se se comportarem, o éter que bloquearam de antemão (seu stake) será cortado!”

Conseguir segurança através do capitalismo, não é?

Primeiro de tudo,

O que diabos é um nó do Ethereum?

Um nó do Ethereum é um computador rodando o software do Ethereum, chamado cliente Ethereum. É só isso. Acredite, é exatamente isso. É o mais simples possível, sem palavras complicadas, sem enrolação. É isso! Nós do Ethereum.

Esses nós compõem a blockchain do Ethereum — um conjunto de computadores rodando software semelhante que podem se comunicar entre si.

Qualquer um pode rodar um nó do Ethereum, mas não há benefício financeiro em fazer isso. Não me leve a mal, há benefícios em rodar um nó (não confundir com ser um validador), como:

1. Não precisar confiar em outros nós na rede, pois você pode verificar todos os dados das transações por conta própria — o verdadeiro espírito cypherpunk de “Não confie, verifique!”
2. Você pode usar dApps de forma mais segura e privada, pois não precisa vazar seus endereços de carteira e saldos para nós intermediários suspeitos.
3. Você pode conectar sua carteira Ethereum diretamente ao endpoint RPC do seu próprio nó Ethereum. Assim, você tem acesso exclusivo e prioridade para incluir suas transações, ao invés de competir com todos pelo endpoint RPC público.
4. Você garante que as regras de consenso sejam seguidas, assim, não pode ser enganado a aceitar blocos que não seguem as regras, mesmo em um evento de cisne negro onde todos os nós decidem se coludir. Em tal evento improvável, uma recuperação social pode ser feita pelos nós, escolhendo seguir a cadeia honesta.
5. Quanto mais nós na rede, mais diversificada e robusta ela fica, dificultando que toda a rede falhe ou que transações sejam censuradas.
6. Nós completos fornecem acesso aos dados da blockchain para clientes leves que dependem deles (ou seja, Light Clients). Isso ajuda os usuários a acessarem e interagirem com o Ethereum de forma segura e descentralizada, sem precisar sincronizar toda a blockchain, ampliando as possibilidades de uso.

Ao gerar uma chave de assinatura ‘mágica’ especializada e fazer stake de 32 ETH em um contrato inteligente vinculado a essa chave, você transforma seu nó Ethereum em um validador.

Validadores são nós ‘ativados’ que processam as transações dos usuários e as consolidam (ou seja, finalizam).

A validade de cada transação é votada por todos os validadores (sign attestations) na rede Ethereum e atestada pelo ETH que eles fizeram stake.

Como validadores processam e atestam as transações dos usuários, eles são recompensados por fazerem bem seu trabalho e penalizados quando se comportam mal. Se forem considerados desonestos, maliciosos ou gravemente negligentes, terão seu stake cortado até o valor total e expulsos da rede.

Isso incentiva os validadores a serem e permanecerem honestos.

Então, como fazer staking solo no Ethereum?

Você precisa fazer stake de 32 ETH para se tornar um validador no Ethereum. 32 ETH equivalem a Ksh. 13.998.370,65 na data de escrita, onde 1 ETH = Ksh. 437.449,08 — quanto vale 1 ETH agora que você está lendo?

Como eles chegaram ao requisito de 32 ETH? Está embutido no código que os computadores (software cliente) executam para participar na blockchain do Ethereum.

Depois, você precisa rodar um software cliente específico para se tornar um validador. Aqui estão exemplos de softwares para rodar:

1. Prysm (https://prysmaticlabs.com/))
2. Lighthouse (https://lighthouse-book.sigmaprime.io/))
3. Teku (https://consensys.io/teku))
4. Nimbus (https://nimbus.team/))
5. Lodestar (https://lodestar.chainsafe.io/))

Esses softwares são chamados coletivamente de Software de Camada de Consenso porque são eles que alcançam o consenso na Ethereum — decidem o estado da blockchain.

Agora que você sabe qual software rodar e tem 32 ETH, está pronto para ganhar aquelas recompensas de bloco, certo? Bem, sim, mas, como sempre, o diabo está nos detalhes. Vamos ver como isso pode facilmente se tornar uma tarefa bem complexa.

Staking solo

Staking solo envolve rodar seu próprio nó completamente e receber as recompensas de bloco sem compartilhá-las com ninguém.

Requisitos mínimos de hardware para fazer staking solo:

1. CPU: Quad-core
2. RAM: 32GB
3. Armazenamento: SSD NVMe de 2TB, >500 IOPS de leitura, >1700 IOPS de escrita, não-QLC (considerar SSD NVMe de 4TB, >5000 IOPS de leitura, >1700 IOPS de escrita, não-QLC, se quiser uma configuração sem estresse)
4. Requisitos de rede (verifique com seu ISP):
   1. Volume: Sem limite ou pelo menos 2TB por mês
   2. Velocidade: Pelo menos 500mb/s compartilhado — seu nó validador precisa de pelo menos 10mb/s de internet dedicada
   3. Endereço IP: Estático, se possível
5. Energia: Fonte de alimentação ininterrupta (UPS)

Os requisitos de hardware podem parecer assustadores à primeira vista, mas já viu os requisitos de hardware do Solana?

Lembre-se do nosso mantra:

“Uma blockchain é apenas uma grande base de dados única que não pertence a ninguém, mas pode ser escrita por qualquer um, e tudo que nela for escrito não pode ser apagado. Você precisa ter uma cópia da base de dados no seu computador se quiser escrever nela.”

Vamos então analisar como cada componente de hardware afeta o desempenho:

Lembrando que você precisa rodar um cliente de camada de consenso como Lighthouse, certo? Além disso, também precisa rodar um cliente de camada de execução.

O que é um cliente de camada de execução? Fico feliz que tenha perguntado…

Um cliente de camada de execução no Ethereum é o software que executa contratos inteligentes e transações. É onde suas dApps favoritas, como Aave, Uniswap e aquela sua meme coin que você espera que decole, são executadas. Essa camada de execução compõe a Ethereum Virtual Machine (EVM).

Exemplos de clientes de camada de execução incluem:

• geth
• reth
• nethermind
• besu
• erigon

NB: Melhore a resiliência do Ethereum usando um cliente de execução minoritário. E se acontecer um evento de cisne negro e o geth — que tem cerca de 55% de participação de mercado na hora da escrita, ou seja, mais da metade dos clientes de execução do Ethereum usam geth — tiver um bug crítico? Isso significa que o Ethereum vai travar?

A validação de blocos funciona assim:

1. Executa contratos inteligentes na EVM. Isso é possível porque o validador está rodando um cliente de camada de execução como o reth.
2. Essa execução altera o estado da blockchain.
3. Essas mudanças precisam ser comunicadas por toda a cadeia — lembre-se da nossa única grande base de dados — para que seja alcançado consenso e todos os nós concordem com o estado da cadeia naquele momento. Isso significa que a camada de execução precisa se comunicar de alguma forma com a camada de consenso.

Vamos fazer um exemplo de configuração do reth (cliente de camada de execução) com o Lighthouse (cliente de camada de consenso).

Os passos abaixo assumem que você já tem uma noção básica de trabalhar com o ambiente Linux, incluindo digitar comandos no terminal, mesmo que sem entender exatamente o que fazem, mas que funcionam.

ls -al | grep | xxd | echo -n

Ah, você não entendeu nada do que acabei de digitar?

Se ls -al | grep | xxd | echo -n parece mandarim para você, é hora de revisar seus livros e aprender seus comandos Linux. Não precisa ser um guru como eu (sim, uso Arch), mas pelo menos aprenda a diferenciar seu cd de seu rm -rf /!

Vamos trabalhar em uma máquina com Ubuntu instalada.

Primeiro, precisamos criar um JSON Web Token (JWT) que permitirá que o software de camada de execução (reth) e o de camada de consenso (Lighthouse) se comuniquem.

Execute os comandos abaixo, um de cada vez, para criar uma pasta chamada jwtsecret e gerar o arquivo JWT jwt.hex dentro dela:

sudo mkdir -p /var/lib/jwtsecret

openssl rand -hex 32 | sudo tee /var/lib/jwtsecret/jwt.hex > /dev/null

Depois, configuraremos os arquivos de configuração dos clientes de execução e consenso para apontar para esse arquivo JWT (jwt.hex).

Baixe o reth e configure o serviço:

Baixe a versão mais recente do reth aqui (https://github.com/paradigmxyz/reth/releases)) e seu arquivo de assinatura digital (.asc) para verificar o checksum, garantindo que o arquivo não foi alterado.

curl -LO https://github.com/paradigmxyz/reth/releases/download/v1.0.0/reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz

curl -LO https://github.com/paradigmxyz/reth/releases/download/v1.0.0/reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz.asc

Verifique o checksum com:

gpg --keyserver keyserver.ubuntu.com --recv-keys 50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E

gpg --verify reth-v0.1.0-alpha.23-x86_64-unknown-linux-gnu.tar.gz.asc reth-v0.1.0-alpha.23-x86_64-unknown-linux-gnu.tar.gz

Saída esperada: Verificação do checksum bem-sucedida, como:

“

gpg: assinatura feita em Seg 24 Jun 2024 13:33:15 EAT

gpg: usando chave EDDSA 50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E

gpg: assinatura boa de “Georgios Konstantopoulos (Chave de assinatura Reth para 2024 e seguintes) <[email protected]>” [desconhecido]

gpg: AVISO: Esta chave não é certificada com uma assinatura confiável!

gpg: Não há indicação de que a assinatura pertença ao proprietário.

“

Verifique a chave de assinatura da versão aqui (https://reth.rs/installation/binaries.html#signature-verification)).

Se o checksum for válido, extraia os arquivos e mova-os para /usr/local/bin:

tar xvf reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz

sudo cp reth /usr/local/bin

rm -r reth reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz.asc reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz

Crie uma conta chamada reth sem acesso ao servidor, para rodar como serviço em background:

sudo useradd --no-create-home --shell /bin/false reth

Crie uma pasta para o reth armazenar os dados da blockchain:

sudo mkdir -p /var/lib/reth

sudo chown -R reth:reth /var/lib/reth

Crie o arquivo de configuração systemd para o reth:

sudo vi /etc/systemd/system/reth.service

Cole as configurações abaixo:

“

[Unit]

Description=Cliente de Execução Reth (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 <endereço_ip_interno> \

–http.port 8547 \

–ws \

–ws.addr <endereço_ip_interno> \

–ws.port 8548 \

–metrics 127.0.0.1:6060

“

Após salvar, revise sua configuração e ajuste se necessário.

Resumo da configuração do reth:

1. –chain: rodar na testnet Holesky
2. –datadir: pasta para armazenar os dados do nó
3. –log.file.directory: caminho para logs
4. –authrpc.jwtsecret: caminho para jwt.hex
5. –full: rodar nó completo
6. –port: porta P2P (padrão 30303)
7. –http: habilitar RPC HTTP
8. –http.api: módulos RPC
9. –http.addr: IP interno (exemplo 192.168.x.x)
10. –http.port: porta RPC (padrão 8545)
11. –ws: ativar websocket
12. –ws.addr: IP websocket
13. –ws.port: porta websocket
14. –metrics: ativar métricas

Inicie o reth:

sudo systemctl daemon-reload

sudo systemctl start reth.service

sudo systemctl status reth.service

Saída esperada: “active (running)”. Use CTRL+C para parar, ele continuará rodando. Pode levar cerca de 6 horas para sincronizar na testnet Holesky.

Verifique os logs de sincronização:

sudo apt install ccze -y

sudo journalctl -fu reth -o cat | ccze -A

Saída esperada: monitoramento em tempo real, com atenção a avisos ou erros.

Para ativar o reth ao reiniciar:

sudo systemctl enable reth.service

Configuração do cliente de consenso (Lighthouse):

Baixe a versão mais recente (https://github.com/sigp/lighthouse/releases)) e verifique o checksum:

curl -LO https://github.com/sigp/lighthouse/releases/download/v5.2.1/lighthouse-v5.2.1-x86

curl -LO https://github.com/sigp/lighthouse/releases/download/v5.2.1/lighthouse-v5.2.1-x86

Verifique com:

gpg --keyserver keyserver.ubuntu.com --recv-keys 15E66D941F697E28F49381F426416DC3F30674B0

gpg --verify lighthouse-v5.1.3-x86_64-unknown-linux-gnu.tar.gz.asc lighthouse-v5.1.3-x86_64-unknown-linux-gnu.tar.gz

Saída esperada: assinatura válida.

Extraia e mova para /usr/local/bin:

tar xvf lighthouse-v5.1.3-x86_64-unknown-linux-gnu.tar.gz

sudo cp lighthouse /usr/local/bin

rm -r lighthouse*

Crie usuário separado para o cliente de consenso:

sudo useradd --no-create-home --shell /bin/false lighthousebeacon

Crie pasta para dados:

sudo mkdir -p /var/lib/lighthouse_beacon

sudo chown -R lighthousebeacon:lighthousebeacon /var/lib/lighthouse_beacon

sudo chmod 700 /var/lib/lighthouse_beacon

Configure o serviço:

sudo vi /etc/systemd/system/lighthousebeacon.service

Cole:

“

[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 <endereço_ip_interno> \

–builder http://127.0.0.1

“

Após salvar, revise sua configuração.

Inicie o Lighthouse:

sudo systemctl daemon-reload

sudo systemctl start lighthousebeacon.service

sudo systemctl status lighthousebeacon.service

Saída: “active (running)”. Pode levar alguns minutos para sincronizar na Holesky.

Verifique os logs:

sudo journalctl -fu lighthousebeacon -o cat | ccze -A

Para ativar ao reiniciar:

sudo systemctl enable lighthousebeacon.service

Verificação de raízes iniciais (checkpoint):

1. Acesse https://holesky.beaconcha.in/ no navegador e procure pelo número do slot.
2. Confirme Block Root e State Root com a saída do journalctl.
3. Verifique os logs.

Documentação do Lighthouse em (https://lighthouse-book.sigmaprime.io/intro.html)).

Geração de Chaves do Validador

Chave do validador é a chave criptográfica usada pelos validadores do Ethereum. Existem dois tipos principais:

1. Chave de Validador (ou Chave de Assinatura):
   • Usada para assinar atestações e propor blocos.
   • Garante que o validador possa provar suas ações e manter a integridade.
   • É uma chave quente, precisa estar online para participar.
2. Chave de Retirada:
   • Usada para gerenciar e retirar fundos do stake.
   • Quando desejar retirar ETH e recompensas, usa essa chave.
   • É uma chave fria, mantida offline por segurança, usada só na retirada.

Como gerar essas duas chaves? Recomendo fazer de forma cyperpunk, usando uma máquina isolada (air-gapped), que nunca tocou na internet.

Se possível, use um Raspberry Pi (custa menos de 100 USD). Se não, baixe um sistema operacional seguro, como Tail OS, rode de um USB, gere as chaves, copie para o USB e pronto.

Faça a geração em ambiente seguro, com WiFi confiável, e bloqueie câmeras físicas (laptop, webcam, etc). Desligue internet e conexões wireless antes de gerar as chaves.

Para segurança, não armazene a seed phrase online ou em dispositivos conectados à internet. Proteja suas chaves como se fosse seu BTC!

Vamos usar Tail OS para maior segurança.

Baixe o arquivo binário de geração de chaves de depósito do validador aqui (https://github.com/ethereum/staking-deposit-cli/releases)), verifique o checksum:

curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/v2.7.0/staking_deposit-cli-fdab65d-linux-amd64.tar.gz

echo “ac3151843d681c92ae75567a88fbe0e040d53c21368cc1ed1a8c3d9fb29f2a3a deposit-cli-fdab65d-linux-amd64.tar.gz” | sha256sum --check

Saída esperada: OK

Extraia:

tar xvf deposit-cli-fdab65d-linux-amd64.tar.gz

cd staking_deposit-cli-fdab65d-linux-amd64

Gere as chaves de assinatura do validador:

Antes de continuar, desligue internet, WiFi, Bluetooth, cubra câmeras, e esteja em ambiente seguro.

Execute:

./deposit new-mnemonic --num_validators <número> --chain holesky --eth1_withdrawal_address <seu_endereço_de_retirada>

Use um endereço de carteira não custodial, como uma cold wallet ou multi-sig seguro.

Responda às perguntas:

1. Selecione idioma
2. Confirme seu endereço de retirada
3. Selecione idioma da seed phrase
4. Crie uma senha para proteger os keystores
5. Confirme a senha

Ao terminar, anote a seed phrase em papel — nunca online ou em dispositivos conectados à internet.

Depois, o programa gera dois arquivos:

1. keystore-m_.json — sua chave de assinatura, guarde com muito cuidado.
2. deposit_data-.json — link entre ETH deposit e seu validador, use uma única vez.

Copie esses arquivos para um USB, remova o original:

sudo rm -r $HOME/staking-deposit-cli/validator_keys

Reinicie seu dispositivo e remova o USB, que não terá memória persistente.

Para usar a chave no seu nó, conecte o USB, identifique-o:

lsblk

Procure pelo seu USB, por exemplo sdx.

Monte o USB:

sudo mount /dev/sda1 /media

Copie a chave para o diretório do seu nó:

sudo cp -r /media/staking-deposit-cli/validator_keys ~/

Desmonte o USB:

sudo umount /media

Crie um arquivo de senha para seu nó usar ao acessar a chave:

ls ~/validator_keys

Copie o nome do arquivo keystore, crie o arquivo de senha:

sudo vi <nome_do_keystore>.txt

Digite a senha que criou antes, salve.

Agora, para fazer o depósito de 32 ETH, envie para o contrato de depósito do Beacon na mainnet (endereço 0x0000…5Fa). Mas NÃO envie direto, use o Launchpad oficial (http://launchpad.ethereum.org/)).

Se estiver na testnet Holesky, use o launchpad de teste (https://holesky.launchpad.ethstaker.cc/)).

Como obter 32 ETH de teste? Vá ao site https://holesky-faucet.pk910.de/, mint 32 test ETH, ou a quantidade que puder, e siga os passos no Discord (https://discord.gg/ethstaker).

Depois, acesse o link gerado, conecte sua carteira Metamask, assine a mensagem, copie o link, cole na caixa de assinatura.

Acesse https://holesky.launchpad.ethstaker.cc/, clique em “Tornar-se um validador”, leia os avisos, e na seção “Upload de dados de depósito”, envie o arquivo deposit_data-.json gerado anteriormente.

Antes de confirmar, verifique o endereço do contrato de depósito na sua carteira, para garantir que é o endereço correto (para Holesky, é 0x4242…42).

Clique em “Enviar Depósito” e siga as instruções do seu wallet.

Depois, você pode acompanhar a ativação do seu validador pelos links fornecidos. Pode demorar alguns minutos para aparecer.

Parabéns! Agora você é um contribuinte para a descentralização do Ethereum.

Saindo do seu validador

Se desejar sair, pode fazer uma saída voluntária, enviando uma mensagem ao beacon chain. Você precisa estar ativo, não ter sido penalizado (slashed), e ter pelo menos 256 epochs (~27h) desde a ativação.

Após iniciar a saída, o processo leva pelo menos 5 epochs (~32 minutos). Você pode usar o comando:

lighthouse account validator exit --keystore <caminho_do_keystore> --beacon-node http://localhost:5052

Confirme a saída com a frase de confirmação, e ela será processada na cadeia.

Se desejar retirar seus ETH e recompensas, após a atualização Capella (12/04/2023), você pode fazer a retirada completa, se tiver as credenciais corretas (tipo 0x01).

Cada cliente de consenso tem seu procedimento de saída, como Prsym (https://docs.prylabs.network/docs/wallet/exiting-a-validator)), Nimbus (https://nimbus.guide/voluntary-exit.html)), Lodestar (https://chainsafe.github.io/lodestar/run/validator-management/validator-cli#validator-voluntary-exit)), Teku (https://docs.teku.consensys.net/HowTo/Voluntary-Exit)).

Este post mistura links de testnet e mainnet. Adapte para a rede que deseja validar!

Ufa, foi longo!

Você leu exatamente 6.309 palavras, ou 40.289 caracteres, explicando como fazer staking solo.

Espero que suas expectativas tenham sido atendidas e que agora consiga montar seu próprio validador solo.

Até a próxima, na outra ponta da cadeia, onde discutiremos se o EigenLayer é o futuro das liquidações do Ethereum ou não, enquanto zoamos a Solana por estar sempre offline e a Cardano com seus papers acadêmicos que… bem, essa é história para outro dia!