Pool de backup e failover: para que servem o segundo e o terceiro slot no ASIC

Quase todo firmware de ASIC traz três campos para o endereço do pool. Normalmente só um é preenchido. O segundo e o terceiro ficam vazios ou duplicam o mesmo endereço, o que os torna inúteis. É o seguro mais barato da mineração: a configuração leva cinco minutos, não custa nada, e evita o tempo de inatividade quando o pool principal cai.

A seguir, explicamos o mecanismo de comutação, calculamos o custo do tempo de inatividade com nossa fórmula e tratamos à parte de um ponto que quase ninguém explica: o que acontece com sua contribuição no PPLNS quando o minerador passa para o backup.

O que são os três slots de pool no ASIC

Os três slots formam uma lista de prioridade. O minerador mantém a conexão stratum com o primeiro endereço. Se a conexão cair ou o pool parar de enviar tarefas, o firmware tenta o segundo endereço, depois o terceiro. Não há nada mais inteligente que isso: é uma varredura sequencial de cima para baixo, sem balanceamento e sem dividir o hashrate entre pools.

Ponto-chave sobre a comutação: ela não é instantânea. O minerador primeiro precisa determinar que realmente não há conexão. Ele espera o vencimento de um timeout, às vezes tenta reconectar várias vezes ao primeiro endereço, e só depois passa para o próximo. A duração dessa janela depende do firmware e da versão, não há um padrão único. Veja o valor exato na interface web do seu equipamento, na seção de configurações do pool, ou nos logs: lá dá para ver quantos segundos após a queda o minerador começou a bater no segundo endereço.

Daí uma conclusão prática. O failover não protege contra quedas curtas de poucos segundos. Ele protege contra situações que duram minutos e horas: o pool caiu, tem problemas de DNS, seu provedor perdeu a rota até um data center específico. Como distinguir um problema do lado do pool de um problema do seu próprio lado está detalhado no artigo o pool está fora do ar: diagnóstico passo a passo.

Segundo ponto: a maioria dos firmwares volta automaticamente ao primeiro pool quando ele é restabelecido. Ou seja, o backup funciona como uma plataforma temporária, não como uma mudança definitiva. Mas esse comportamento precisa ser verificado separadamente no seu próprio modelo, pois também depende do firmware.

Quanto custa uma hora de inatividade

Partimos da fórmula básica de produção esperada. Receita por período a um hashrate dado:

```

BTC = H * 86400 * R / (D * 2^32)

```

onde H é o hashrate em hashes por segundo, 86400 são os segundos do dia, R é a recompensa do bloco em BTC, D é a dificuldade da rede. A fórmula dá uma esperança matemática, não uma garantia: em volumes pequenos a produção real oscila em torno desse número.

Substituímos com a rede em 08.09.2026: dificuldade de 127,45 trilhões, recompensa de 3,125 BTC, hashrate da rede de 930,73 EH/s, participação das taxas no bloco de 0,66 por cento. Com esses parâmetros, 100 TH/s produzem 0,00004932 BTC por dia. À cotação de 78.349 dólares, isso dá 3,86 dólares por dia, ou seja, 16,1 centavos por hora.

Em seguida, aritmética simples por escala:

Em um S21 doméstico, a diferença entre 1 e 5 por cento de inatividade por mês se mede em alguns dólares, e nesse nível o failover é mais uma questão de higiene do que de dinheiro. Em dez petahashes, as mesmas porcentagens viram centenas de dólares por mês, e configurar o segundo slot se paga já na primeira falha. Você pode testar seus próprios números na calculadora de rentabilidade, colocando seu hashrate e o preço da eletricidade.

Vale lembrar também que a inatividade não é gratuita em termos de gastos: o equipamento fora do ar no pool continua consumindo energia se o minerador ficar girando em vazio tentando reconectar.

O que acontece com a contribuição no PPLNS ao passar para o backup

Resposta direta: no PPLNS, os shares que você já enviou não são zerados no momento da desconexão. Eles permanecem na janela e continuam participando da divisão dos blocos que o pool encontrar em breve, e depois vão sendo gradualmente deslocados pelos novos shares de outros mineradores. Uma passagem curta para o backup custa bem menos do que costuma-se pensar. Uma longa consome a contribuição por completo.

A mecânica é essa. O PPLNS não paga pelo share em si, mas pela proporção dos seus shares entre os últimos N shares do pool no momento em que um bloco é encontrado. Enquanto seus shares estiverem dentro dessa janela, cada bloco encontrado traz uma parte da recompensa. Assim que o fluxo de shares de outros empurra os seus para fora da janela, eles deixam de contar. Não é uma penalidade nem um cancelamento, é um deslocamento natural da janela.

O tamanho da janela varia entre pools, e a forma de descrevê-la também. Segundo nossa análise da documentação:

Daí uma regra prática: quanto mais ampla a janela do pool principal, mais tranquilo é suportar passagens curtas para o backup. Na Ocean, uma janela de oito dificuldades de rede significa que um share, em média, consegue participar da divisão várias vezes, e uma queda de conexão de dez minutos quase não tira nada. Com uma janela curta, a mesma queda custa mais.

E o contrário: uma passagem para o backup de várias horas significa que, no momento do retorno, quase não resta nada da sua contribuição na janela do pool principal, e o acúmulo recomeça do zero. É por isso que falhas longas doem mais no PPLNS do que no PPS e no FPPS, onde o pagamento não depende de o pool ter encontrado um bloco.

Uma ressalva importante: a maioria dos grandes pools de BTC não opera por padrão em PPLNS, mas em FPPS ou PPS+. Se você está no FPPS, toda essa aritmética de janela não se aplica a você, e passar para o backup custa exatamente o que você deixou de minerar durante a inatividade, nem mais nem menos.

Como escolher um pool de backup

Resposta direta: escolha um backup com o mesmo esquema de pagamento do pool principal, mas não tente procurar um pool do mesmo tamanho. A correspondência do esquema é importante porque dela depende como o rendimento é calculado durante o tempo de inatividade, e se você terá que lidar com dois modelos de pagamento diferentes em uma mesma semana. O tamanho do pool não influencia isso.

Por que o esquema importa mais que o tamanho. Se o pool principal é FPPS e o backup é PPLNS, cada comutação passa a acumular contribuição do zero em uma janela estranha, e ao voltar essa contribuição fica subaproveitada. Além disso, é mais difícil conciliar os relatórios: no FPPS o rendimento é regular, no PPLNS está ligado aos achados de blocos. Um esquema igual torna as duas plataformas comparáveis.

Por que o tamanho não é crítico. O hashrate do pool afeta a variância dos pagamentos: um pool pequeno encontra blocos com menos frequência, então o rendimento é mais irregular. Mas o backup, por definição, funciona em episódios curtos. Em duas horas de inatividade, a variância de um pool pequeno não vai estragar nada, porque no FPPS ela simplesmente não existe, e no PPLNS a contribuição de algumas horas é modesta de qualquer forma.

O que realmente observar ao escolher um backup:

1. O esquema de pagamento corresponde ao do pool principal.
2. O limite mínimo de saque é alcançável. Essa é a armadilha principal, detalhada abaixo.
3. A localização geográfica dos servidores difere do pool principal. Um backup no mesmo data center do principal não salva de uma falha do data center.
4. O cadastro não exige um processo de KYC de uma semana, senão o backup não conseguirá ser configurado rapidamente.
5. Taxa e limites são conhecidos com antecedência. É possível comparar por pool nas nossas análises de taxas e pagamentos mínimos.

Sobre se vale a pena trocar de pool e por que mudanças frequentes não são gratuitas, há uma análise separada: o custo de trocar de pool.

Vale a pena colocar solo ou outro pool no terceiro slot

Resposta direta: o terceiro slot faz sentido se não for uma cópia do segundo, mas um seguro contra outro tipo de falha. O segundo slot cobre a queda de um pool específico. O terceiro deve cobrir a situação em que ambos ficam indisponíveis, por exemplo por um problema de rota até uma região ou um bloqueio do lado do provedor.

Opções razoáveis para o terceiro slot:

1. Um pool de outra jurisdição e com outra infraestrutura de rede. A escolha mais prática para a maioria.
2. Um pool solo. Faz sentido se você estiver disposto, por princípio, a ter renda zero na maior parte do tempo em troca de uma chance de loteria de encontrar um bloco. Como regime permanente para hashrate pequeno, é uma aposta consciente, não um cálculo. Como terceiro slot que é ativado em horas raras de falha, o solo custa aproximadamente o preço dessas horas de inatividade da tabela acima.
3. O mesmo pool, mas outro endereço do seu endpoint stratum em outra região. Isso protege contra uma falha regional, mas não contra uma falha do pool inteiro.

Muitos usam a opção 3 como segundo slot, e isso não é ruim. Mas nesse caso o terceiro slot precisa obrigatoriamente ser um pool de terceiros, senão toda a lista fica atrelada a um único operador.

Erros típicos na configuração do failover

1. O mesmo endereço nos três slots. O caso mais frequente. A lista parece preenchida, mas não há proteção: o pool cai, as três entradas caem.
2. Backup com worker não verificado. O login foi digitado de memória, com erro de digitação ou apontando para uma subconta inexistente. Enquanto o pool principal está vivo, o erro não aparece. No momento da falha, o minerador troca e recebe uma recusa de autorização.
3. Um limite de saque que você nunca vai alcançar. Se o backup paga a partir de uma soma que seu hashrate vai acumular ao longo de anos de falhas raras, o dinheiro simplesmente se acumula no saldo. Em alguns pools o restante abaixo do limite não se perde e espera o próximo ciclo, mas em outros há regras sobre contas inativas e endereços de pagamento não definidos, podendo chegar à perda dos direitos sobre o acumulado conforme os termos de serviço. Leia os termos do pool específico antes de defini-lo como backup.
4. Failover configurado, mas nunca testado. A categoria mais lamentável, porque a pessoa está convencida de que está protegida.
5. Backup com o mesmo endereço de pagamento e o mesmo e-mail do principal, sem verificação de acesso separada. Se você perder o acesso à conta no momento da falha, o slot configurado serve de pouco.
6. Backup adicionado apenas em parte dos equipamentos. Em uma fazenda de trinta ASICs, a configuração por modelo de configuração garante uniformidade; percorrer manualmente um por um quase sempre deixa lacunas.

Como verificar se o failover funciona

Resposta direta: é preciso verificar cortando a conexão com o pool principal à força, não na teoria. A forma mais segura é trocar temporariamente a ordem dos slots ou bloquear o endereço do pool principal no roteador, observar que o minerador foi para o segundo endereço e começou a entregar shares aceitos, e depois devolver tudo como estava.

Ordem das ações:

1. Certifique-se de que o worker no pool de backup está criado e visível no painel dele. O mais simples é direcionar um minerador para o backup por dez minutos e ver que o hashrate do worker apareceu.
2. Anote o estado atual: endereços nos três slots, nomes dos workers, hashrate atual no pool principal.
3. Bloqueie o acesso ao pool principal. Opções: uma regra no roteador por domínio ou IP, desativar uma porta específica, ou substituir temporariamente o endereço do primeiro slot por um comprovadamente não funcional.
4. Cronometre. Anote em quantos segundos o minerador passou para o segundo endereço. Esse é o seu timeout real de failover, e é esse valor que deve ser levado em conta ao estimar as perdas.
5. Verifique no painel do pool de backup que os shares do worker estão chegando e sendo reconhecidos como válidos. A simples existência de conexão não basta.
6. Remova o bloqueio e veja se o minerador volta sozinho ao primeiro slot. Se não voltar, o retorno é manual, e isso precisa ser considerado no procedimento.
7. Repita o mesmo para o terceiro slot, bloqueando tanto o primeiro quanto o segundo pool.
8. Anote os resultados e a data da verificação. Repita após cada atualização de firmware: o comportamento do failover muda de versão para versão.

É conveniente combinar a verificação com trabalhos planejados, quando parte do hashrate já está inativa de qualquer forma. O custo da própria verificação se calcula pela mesma tabela: dez minutos a 10 PH/s são cerca de 2,7 dólares, um gasto único em troca da certeza de que a proteção funciona.

Em resumo

Três slots em vez de um não aumentam o rendimento. Eles eliminam do gráfico as quedas que, do contrário, se prolongariam até que você percebesse o problema manualmente. Com hashrate pequeno, o ganho se mede em poucos dólares por mês; com hashrate industrial, em centenas e milhares.

Vale a pena ter três coisas em mente. A comutação não é instantânea, segue o timeout do firmware, e seu valor precisa ser medido no seu próprio equipamento. No PPLNS, uma passagem curta para o backup custa menos do que parece, porque os shares envelhecem na janela gradualmente, não são zerados de repente. E um failover configurado, mas nunca testado, não é proteção, é apenas sua imitação.

Para estimar quanto a inatividade custa na sua configuração específica, use a calculadora, e para comparar as condições dos pools para backup, veja a seção de comparação de pools.