Stale Rate é a proporção de resultados ou de trabalho ponderado classificados como desatualizados. Na mineração de Bitcoin através de um pool, refere-se normalmente a shares: provas parciais de cálculo que já não correspondem à tarefa atual. A definição exata e o efeito nas recompensas dependem do sistema observado.
Um pool é um serviço que distribui trabalho pelos mineiros. Quando a rede encontra um novo bloco, normalmente é preciso começar a construir sobre ele. Um resultado calculado com a tarefa anterior já não serve para o novo trabalho. Stratum V2, um protocolo de comunicação entre equipamentos de mineração, trata desta mudança através de SetNewPrevHash: a máquina começa a procurar um bloco que dê continuidade ao bloco agora indicado. Das tarefas previamente preparadas, só continua válida a assinalada pelo identificador de tarefa job_id. Por isso, Petra verifica a validade da tarefa, não apenas a hora de envio do resultado. [1]
Num exemplo simples, Petra submete 100 resultados com a mesma dificuldade. O pool aceita 98, rejeita 1 como stale e 1 por outro motivo. Os resultados stale rejeitados representam 1%; todas as rejeições juntas, 2%. F2Pool chama rejection rate à proporção de todas as submissões rejeitadas no total de submissões. No nosso exemplo, stale é apenas parte desse conjunto. Os números explicam o cálculo, não um limite operacional aceitável; uma classificação diferente pode dar outro significado ao painel. [2]
A dificuldade de uma share determina o grau de exigência do resultado a apresentar. Braiins contabiliza um resultado com dificuldade d como d unidades básicas de trabalho. Imagine uma stale share com dificuldade 1 e uma share aceite com dificuldade 9. Contando submissões, obtemos 50%; ponderando o trabalho, 10%. Nenhum cálculo é errado por si só, mas respondem a perguntas diferentes. Ao comparar, Petra usa a mesma unidade no numerador e no denominador e confirma que a convenção de dificuldade é a mesma. [3]
A documentação de F2Pool distingue a categoria Staled, que gera recompensas, das stale shares rejeitadas, que não as geram. A designação, por si só, não diz se Petra perdeu dinheiro. Esta política não pode ser generalizada a todos os pools: contam as regras do serviço concreto e o apuramento efetivo. Ao comparar fornecedores, Petra identifica primeiro a categoria dos resultados. Só depois pode estimar o efeito no rendimento. [2]
Ao ler um registo de funcionamento, é fácil esquecer que Stratum V2 pode confirmar várias submissões numa única mensagem SubmitShares.Success. O campo new_submits_accepted_count indica quantas foram agora confirmadas, enquanto new_shares_sum soma as respetivas dificuldades. Contar respostas do servidor não equivale, portanto, a contar shares aceites. Numa rejeição, SubmitShares.Error inclui sequence_number, o identificador da submissão, e error_code, o motivo do erro. Sem esta distinção, Petra poderia confundir qualquer erro com trabalho atrasado. [1]
A notícia de um novo bloco tem primeiro de circular pelos computadores que verificam Bitcoin. BIP152 descreve Compact Block Relay, uma transmissão de blocos que utiliza menos dados entre nós da rede P2P, ou seja, participantes diretamente ligados. Menos dados podem reduzir o atraso de transmissão. Trata-se, porém, de propagar blocos, não de contabilizar shares num pool. A proporção de blocos que ficaram fora da cadeia principal não mede, por isso, os resultados atrasados da máquina de Petra. [4]
Braiins disponibiliza estatísticas de trabalho para diferentes períodos: shares_5m (últimos 5 minutos), shares_60m (últimos 60 minutos) e shares_24h (últimas 24 horas). Petra não pode dividir resultados atrasados de um intervalo curto pelo trabalho de um dia inteiro e comparar esse valor com a estatística horária de outra máquina. As duas partes do cálculo devem abranger o mesmo período e os mesmos equipamentos. Se não houve submissões observadas, a proporção não está definida; não é uma perda medida de 0%. Uma falha na monitorização ou uma resposta em falta também não provam, por si só, que o resultado era stale. [5]
Petra começa pelas mudanças de tarefa, motivos de rejeição e condições da ligação durante o mesmo período. F2Pool associa os resultados stale às condições da rede. Outras rejeições podem decorrer de erros de firmware, o software que controla a máquina, ou de overclocking excessivo: aumentar a frequência de funcionamento dos chips para tentar realizar mais cálculos. Braiins recomenda ping, um teste simples para verificar se o servidor responde a pedidos de rede. Uma resposta positiva não confirma a correção da mineração nem o crédito das recompensas. Uma percentagem global menor não prova, por si só, que a causa foi resolvida. Importa perceber o que mudou e acompanhar o erro específico em condições comparáveis. [2] [6]
Para ter uma visão mais completa, leia este verbete junto com Mining Share, Share Difficulty, Mining Latency, Pool Fee, Bitcoin. Também há referências a este verbete em Stale Block, Mining Latency.