Melhor Share Solo, Sem Bloco: eCash RTT

O Real-Time Targeting do eCash, conhecido como Heartbeat, é uma regra de consenso que eleva o alvo de mineração exigido por cerca de dois minutos após cada bloco e depois o deixa decair até a dificuldade publicada. Um share que supera a dificuldade mostrada em um explorador só é um bloco válido se chegar depois desse decaimento. Esse é, de longe, o motivo mais comum pelo qual um minerador solo no XEC vê um share recorde e não ganha nada.

Principais conclusões

• O eCash exige uma dificuldade maior que a publicada por cerca de 115 segundos após cada bloco, em cadência estável.
• A exigência começa astronomicamente alta e cai como a quinta potência do tempo decorrido. Ela nunca pode ser mais fácil que a dificuldade padrão.
• Exploradores mostram a dificuldade de cada bloco como ele foi minerado — o valor mínimo. Não existe nenhum feed público da exigência em tempo real.
• Reproduzimos a fórmula oficial contra os logs de um nó em produção ao longo de 15 medições: desvio máximo de 0,002%.
• A rampa inicial íngreme com que os mineradores solo se deparam hoje existe inteiramente por causa da atualização de 15 de novembro de 2025, que adicionou uma janela de filtro de um bloco.

Por que meu share superou a dificuldade da rede e não encontrou um bloco?

Um minerador nos escreveu com uma reclamação precisa e totalmente razoável. Ele havia resolvido um bloco eCash com um share de cerca de 8,0 bilhões de dificuldade contra uma dificuldade de rede publicada de cerca de 7,36 bilhões. Horas depois, seu minerador registrou um share bem melhor — cerca de 11,87 bilhões — e nada aconteceu. Ele conferiu cada bloco da cadeia desde então. A dificuldade publicada tinha ficado entre 7,1 e 7,4 bilhões a noite toda. Sob as regras do Bitcoin, aquele share era um bloco.

Ele estava certo sobre os números e errado sobre a regra. No eCash, a dificuldade que um explorador publica não é a dificuldade que você precisa superar no momento em que envia. É o piso.

Seu share de 11,87 bilhões chegou cerca de 100 segundos após o bloco anterior — ainda dentro da rampa. Naquele instante a rede exigia 14,85 bilhões, então o share valia cerca de 80% do necessário. Quinze segundos depois a rampa se esgotou, a exigência caiu para 7,33 bilhões, e exatamente o mesmo share teria vencido. Não faltou hashrate a ele. Faltou um quarto de minuto.

O que é o Real-Time Targeting do eCash?

O Real-Time Targeting foi ativado com a atualização Heartbeat em 15 de novembro de 2024. O problema que ele resolve é específico das cadeias SHA-256 minoritárias.

O eCash compartilha o algoritmo com Bitcoin e Bitcoin Cash, então o hashrate migra entre elas atrás de rentabilidade. Quando a dificuldade do eCash cai, hashrate externo entra em massa e minera vários blocos em rápida sucessão — os blocos turbo. O algoritmo de dificuldade padrão reage elevando a dificuldade; o hashrate visitante vai embora; a cadeia fica encalhada com dificuldade alta e uma fração do hashrate, produzindo lacunas entre blocos que podem durar horas. Depósitos travam. Confirmações ficam imprevisíveis.

O Heartbeat ataca a primeira metade desse ciclo. Ao invalidar blocos minerados cedo demais após o antecessor, ele remove a recompensa da mineração em rajada, de modo que o algoritmo base nunca chega a supercorrigir. O design é inspirado na pesquisa de Tom Harding sobre Real-Time Block Rate Targeting.

O mecanismo só funciona por causa do Avalanche. O alvo em tempo real depende da medição de cada nó sobre quando um bloco chegou, algo inerentemente subjetivo. O pós-consenso do Avalanche reconcilia essas visões subjetivas em uma única decisão de rede, sem tocar no cabeçalho do bloco nem no consenso Nakamoto.

Como o alvo em tempo real do eCash é calculado?

A regra é implementada no Bitcoin ABC como uma política de estacionamento em vez de uma regra de validade. O código relevante fica em src/policy/block/rtt.cpp, e a fórmula central está declarada no próprio comentário do arquivo:

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K vale 6, então o alvo escala com a quinta potência do tempo decorrido. T é o espaçamento-alvo daquela janela de filtro. O tempo decorrido é medido a partir de quando o nó recebeu cada cabeçalho de bloco anterior, não a partir do carimbo de tempo escrito no cabeçalho.

A fórmula é avaliada sobre cinco janelas simultaneamente, e vence o resultado mais estrito:

Os comprimentos de janela são números primos, pulando um entre entradas sucessivas. O código-fonte explica por quê: é uma tentativa cuidadosa de evitar frequências de ressonância ao encadear uma série de filtros. A série para em 17 blocos porque janelas adicionais já não alteram a seletividade do filtro de forma significativa.

Duas propriedades importam para mineradores. Aplica-se o alvo mais baixo entre todas as janelas, então governa a restrição mais dura. E o resultado é limitado: o alvo em tempo real nunca é mais alto — nunca mais fácil — que o alvo padrão. A dificuldade só pode ser empurrada para cima, nunca para baixo.

Reconstruir as constantes a partir de gamma(1 + 1/6) = 0.9277193336 reproduz os cinco coeficientes publicados com dez algarismos significativos.

Quanto mais difícil é um bloco eCash logo após o anterior?

Esta é a tabela que não existe em nenhum outro lugar, calculada a partir da fórmula oficial em cadência estável de dez minutos. O multiplicador se aplica à dificuldade que um explorador publicaria.

Um bloco encontrado um segundo depois do antecessor precisaria de cerca de vinte bilhões de vezes a dificuldade publicada. Aos dez segundos, duzentas mil vezes. A curva é brutalmente íngreme e então simplesmente para: depois de cerca de 115 segundos a exigência iguala exatamente a dificuldade publicada, e ali permanece.

Quando os blocos recentes chegaram mais rápido que dez minutos, cada janela parte de um tempo decorrido mais curto e a rampa começa mais alta e dura mais. Isso não é efeito colateral. É o mecanismo anti-blocos-turbo fazendo seu trabalho.

A fórmula corresponde ao que um nó realmente faz?

Nós testamos. Abaixo estão os valores registrados por um dos nossos nós eCash nos dois minutos e meio após um bloco, ao lado dos valores que a fórmula publicada prevê usando apenas os tempos de chegada dos blocos visíveis no mesmo log.

Em todas as quinze medições registradas, o desvio máximo foi de 0,002%. A fórmula publicada não é uma aproximação do que os nós fazem — é exatamente o que eles fazem.

Vale destacar um detalhe. Nos primeiros 99 segundos, a restrição determinante foi a janela de um bloco. Só aos 109 segundos a janela de dois blocos assumiu, e 40 segundos depois a dificuldade padrão fixou o piso.

O que mudou em 15 de novembro de 2025?

Antes daquela atualização havia quatro janelas, começando em dois blocos. A atualização de 15 de novembro de 2025 adicionou a janela de um bloco com seu espaçamento de 150 segundos.

Passar as duas configurações pela fórmula em cadência estável de dez minutos produz um resultado marcante:

Em cadência normal, a configuração de quatro janelas não produzia nenhuma rampa. Ela só entrava em ação quando os blocos já estavam chegando rápido demais — que era seu propósito restrito. A rampa inicial íngreme com que um minerador solo se depara hoje, em uma cadeia por outro lado saudável, existe inteiramente por causa da janela de um bloco adicionada em novembro de 2025.

Se você minerou eCash solo antes dessa data e nunca viu isso acontecer, é por isso.

Por que a dificuldade que meu pool mostra não bate com a do explorador?

Porque no eCash são números diferentes, e o software de mineração diz isso.

O software de mineração solo para eCash do Bitcoin ABC lê rtt.nexttarget a cada chamada getblocktemplate, converte para dificuldade e — só para o eCash — usa esse valor como a dificuldade de rede que reporta e registra. Qualquer outra cadeia SHA-256 usa em vez disso os bits de dificuldade do cabeçalho do bloco.

Essa única ramificação explica o comportamento que todo operador de pool eCash vê: depois que um bloco chega, a dificuldade de rede reportada fica astronomicamente alta, cai uma ordem de magnitude a cada dez segundos por cerca de dois minutos, e então se aplaina no valor que um explorador acabará publicando.

Operadores de nó têm uma segunda opção: calcular o alvo localmente a partir de rtt.prevheadertime, rtt.prevbits e rtt.nodetime, todos presentes no modelo de bloco. Ambos os caminhos estão documentados na página de mineração do eCash.

O que acontece com um bloco que viola o alvo em tempo real?

Ele é estacionado, não rejeitado. O nó o marca com uma violação de política rotulada policy-bad-rtt e o põe de lado, então a sondagem do Avalanche decide se o resto da rede concorda. Se o nó estiver em minoria, ele inverte sua posição. O cabeçalho do bloco permanece intacto o tempo todo, e o consenso Nakamoto não é modificado.

Executar getchaintips em um nó eCash mostra esses ao lado da cadeia ativa, marcados como status: parked. Em um dos nossos nós a chamada retornou 262 pontas de ramo estacionadas abrangendo as alturas de bloco 940.265 a 960.666 — cerca de 20.400 blocos, então aproximadamente 1,3% dos blocos nesse intervalo foram estacionados ao menos uma vez.

Esse número é um limite superior das violações do alvo em tempo real, não uma contagem delas. O eCash estaciona blocos por vários motivos, e o Avalanche também estaciona o lado perdedor de uma disputa comum de fork. Mas em uma cadeia onde dois blocos concorrentes na mesma altura são raros, uma taxa de pontas estacionadas acima de um por cento indica que o mecanismo está ativo e trabalhando, não parado.

Isso se aplica ao Bitcoin, ao Bitcoin Cash ou às outras cadeias SHA-256?

Não. Entre as cadeias SHA-256, esse comportamento é exclusivo do eCash, porque depende da camada Avalanche para reconciliar temporização subjetiva.

No Bitcoin e no Bitcoin Cash, um share acima da dificuldade da rede é um bloco, ponto final. Se você minera várias cadeias e está comparando seus números de melhor share entre elas, a coluna do eCash é a única onde a temporização entra na conta. Nossa análise das probabilidades da mineração solo e o Radar de Rede usam ambos a dificuldade publicada, que é a base correta para a probabilidade de longo prazo — a rampa se dilui na média ao longo do tempo.

Qual o tamanho da zona morta para um minerador solo?

Todo share que cai antes de a rampa se esgotar é desperdiçado, por melhor que seja. Em cadência estável:

Cerca de um quinto de cada intervalo de bloco é inutilizável para um share que mal supera a dificuldade. Shares mais fortes vencem a rampa mais cedo, que é a razão pela qual um share verdadeiramente enorme quase nunca é desperdiçado.

Isso não altera seu retorno esperado de nenhuma forma sobre a qual você possa agir. Já está refletido na produção real de blocos da cadeia e, portanto, na própria dificuldade. Nada na configuração do seu minerador influencia isso.

O que um minerador solo deve realmente fazer a respeito?

Para a maioria das pessoas, a resposta honesta é nada — mas leia seus números corretamente.

• O visor de melhor dificuldade do seu minerador é calculado localmente, no instante em que o hash é encontrado, antes de o pool ter respondido. Ele registra o valor independentemente de o share vir a ser válido ou não. É também um número histórico que não zera quando você encontra um bloco.
• Um melhor share histórico acima da dificuldade publicada no eCash não é prova de bloco perdido ou roubado. Se quiser confirmar que um bloco existe, olhe a transação coinbase on-chain. Em um pool não custodial seu endereço é escrito no coinbase antes de o hashing começar, então um bloco real fica visível em seu próprio nome e ninguém pode movê-lo.
• Se estiver curioso sobre quão perto chegou, nosso artigo melhor share explicado cobre como ler esses números, e a calculadora de probabilidades converte hashrate em expectativas realistas. A página do pool eCash lista a dificuldade atual e todos os endpoints regionais, o gerador de configuração monta os ajustes stratum, e dados ao vivo de blocos e workers ficam no painel do pool.

Se você roda seu próprio nó eCash para minerar solo, há um item de configuração que importa. Um nó precisa de 17 blocos de tempos de chegada de cabeçalho registrados antes de conseguir calcular o alvo em tempo real. Até tê-los, pode construir modelos com dificuldade baixa demais e ver seus blocos estacionados. Definir persistrecentheaderstime=1 salva esses tempos de referência em disco e os recarrega ao reiniciar, o que fecha a lacuna.

Fontes

• Documentação de mineração do eCash — os campos RTT do modelo de bloco, a implementação de referência do cálculo do alvo e os coeficientes de filtro publicados
• Heartbeat Upgrade: A Steady Pulse for eCash — a justificativa, o problema da mineração oportunista e o papel do pós-consenso do Avalanche
• Código-fonte do Bitcoin ABC — src/policy/block/rtt.cpp, contendo a fórmula, as constantes de janela e a política de estacionamento
• Software de mineração solo para eCash — como o alvo em tempo real vira a dificuldade de rede reportada no eCash

Os números de verificação deste artigo foram produzidos avaliando a fórmula publicada contra os logs de um nó eCash em funcionamento em 2 de agosto de 2026 e comparando os resultados valor a valor.