Ir para o conteúdo

Ajuste de dificuldade do Bitcoin: alvos, reajustes e limites

O Bitcoin reajusta o limiar da prova de trabalho a cada 2.016 blocos para conduzir o intervalo médio de longo prazo a dez minutos. Alvo, codificação compacta, janela de timestamps, limites, regras de rede e resultados probabilísticos devem ser analisados separadamente.

Atualizado

Apenas análise educacional do protocolo. Uma dificuldade exibida, estimativa da taxa de hash ou previsão de reajuste não comprova, por si só, rentabilidade, segurança de confirmação, descentralização ou condições futuras da rede.

Resposta direta

O ajuste de dificuldade do Bitcoin é uma regra determinística de consenso que altera periodicamente o maior hash de prova de trabalho aceitável, chamado target ou alvo, para conduzir o intervalo médio de bloco de longo prazo a dez minutos quando a taxa de hash ativa muda. Na mainnet, o alvo normalmente permanece fixo por 2.016 blocos e é recalculado para o período seguinte. Cada nó validador deriva o mesmo alvo obrigatório dos cabeçalhos anteriores; mineradores não votam nele e um explorador não o define.

A prova de trabalho de um cabeçalho só é válida se seu hash, interpretado como inteiro, for menor ou igual ao alvo codificado no campo nBits de 32 bits. Um alvo menor admite menos hashes e exige mais tentativas esperadas. Por convenção, dificuldade é um número relativo inversamente proporcional ao alvo:

D = T₁ / T

Aqui, T é o alvo atual e T₁ o alvo de referência para dificuldade 1. Alvo e dificuldade, portanto, movem-se em sentidos opostos. Nenhum mede diretamente máquinas, energia, identidade dos mineradores ou taxa de hash observada.

Dez minutos é uma expectativa, não uma agenda. Tentativas de hash e chegadas de blocos são aleatórias: dois blocos podem surgir com segundos de diferença ou nenhum aparecer por uma hora mesmo com alvo e taxa estáveis. O reajuste é uma realimentação atrasada durante um período; reduz desvios persistentes na frequência, mas não elimina a variância de curto prazo nem responde imediatamente a um choque de taxa de hash.

O ajuste influencia o ritmo temporal de eventos baseados em altura, incluindo reduções do subsídio, mas não define os valores, o intervalo de 210.000 blocos ou a regra de oferta final. Tampouco seleciona sozinho a cadeia canônica. A escolha de bifurcação do Bitcoin compara o chainwork acumulado após validar cabeçalhos e blocos; a dificuldade de um bloco não é trabalho acumulado.

Como analisar o reajuste

  1. Fixe a rede e as regras. Mainnet, testnet legada, Testnet4, signet e regtest não compartilham todas as exceções. Registre cadeia, regras do software, altura candidata e ativação do reajuste ou de blocos especiais de dificuldade mínima.
  2. Decodifique o alvo declarado. Expanda o nBits compacto do cabeçalho candidato no alvo T. Rejeite alvos negativos, nulos, com overflow ou acima de powLimit, e exija que o hash do cabeçalho satisfaça ≤ T.
  3. Localize a fronteira. Na mainnet, um novo alvo é exigido quando a altura candidata é divisível por 2.016. Nas demais alturas, o nBits do bloco anterior deve continuar inalterado.
  4. Selecione a janela temporal. Na fronteira da mainnet, o Bitcoin Core subtrai o timestamp do primeiro bloco do período anterior de 2.016 blocos daquele do último. Os extremos contêm 2.016 blocos, mas apenas 2.015 intervalos. A duração nominal ainda é 2,016 × 600 = 1,209,600 segundos.
  5. Limite o tempo decorrido. Defina t = clamp(t_actual, 302,400, 4,838,400) segundos, de um quarto a quatro vezes os 14 dias nominais. Timestamps de cabeçalho são campos de consenso fornecidos por mineradores e sujeitos a outras restrições, não horários exatos de recebimento do nó.
  6. Calcule e codifique o novo alvo. Pelas regras atuais da mainnet, calcule com inteiros T_new = min(powLimit, T_old × t / 1,209,600) e codifique o resultado de forma compacta em nBits. Divisão inteira e arredondamento compacto podem produzir pequenas diferenças em relação ao quociente decimal ideal.
  7. Interprete probabilisticamente. Aproximadamente, D_new / D_old = T_old / T_new. Compare o reajuste com a distribuição dos tempos de bloco e uma taxa de hash claramente marcada como estimativa; separe-o de conclusões sobre receita, chainwork, concentração e risco de confirmação.

A fórmula da mainnet usa como T_old o alvo do último bloco. A Testnet4 é deliberadamente diferente: a BIP 94 permite um bloco especial de dificuldade mínima após um timestamp suficientemente atrasado, proíbe a exceção no primeiro bloco de um período e baseia o reajuste na dificuldade real desse primeiro bloco para não contaminar o período seguinte. A regtest normalmente desativa reajustes. Uma regra sem a rede indicada é incompleta.

Exemplos resolvidos

1. Período nominal sem alteração

Suponha T_old = 10 em unidades arbitrárias de alvo e uma duração medida de exatamente 1,209,600 segundos. O limite não muda nada:

T_new = 10 × 1,209,600 / 1,209,600 = 10

A razão de dificuldade é 10 / 10 = 1, então a dificuldade idealizada não muda. Isso não quer dizer que cada bloco levou dez minutos; intervalos aleatórios rápidos e lentos podem se compensar.

2. Período rápido de 12 dias

Suponha que os timestamps extremos estejam separados por 12 dias. Como está dentro dos limites, a razão do alvo é 12 / 14 = 6/7. O novo alvo fica em cerca de 85,7143% do anterior, enquanto:

D_new / D_old ≈ 14 / 12 = 1.166667

A dificuldade idealizada sobe cerca de 16,67%, não 14,29%. A queda percentual do alvo e a alta da dificuldade diferem porque são grandezas recíprocas.

3. Limite de quatro vezes

Se os extremos estiverem separados por apenas 1,75 dia, o cálculo usa o mínimo de 3,5 dias. O alvo pode cair para aproximadamente um quarto e a dificuldade pode subir para cerca de quatro vezes em um reajuste da mainnet.

Se os timestamps cobrirem 70 dias, usa-se o máximo de 56. O alvo pode aumentar aproximadamente quatro vezes e a dificuldade cair para um quarto, salvo se powLimit limitar o alvo antes. “Limite de quatro vezes” deve indicar se trata de alvo ou dificuldade e em qual sentido.

4. Choque de taxa de hash no meio do período

Use uma expectativa simplificada: os primeiros 1.008 blocos são minerados a um ritmo coerente com dez minutos e levam cerca de sete dias. Em seguida desaparece 30% da taxa de hash enquanto o alvo fica fixo. Os 70% restantes teriam intervalo esperado de 10 / 0.70 ≈ 14.286 minutos; os últimos 1.008 blocos levam cerca de dez dias e o período inteiro cerca de 17.

Ignorando extremos, aleatoriedade e arredondamento compacto, o multiplicador do alvo é 17/14 ≈ 1.214286; o da dificuldade é 14/17 ≈ 0.823529, queda de aproximadamente 17,65%. Não cai 30% por completo porque o choque afetou apenas metade do período. Se a taxa continuar em 70%, os blocos ainda serão esperados mais lentos que dez minutos depois desse ajuste parcial e o período seguinte fornecerá mais realimentação.

Riscos e falhas de revisão

Erros de regras e aritmética

  • Chamar a própria barreira de dificuldade, em vez de distinguir o alvo de sua medida relativa inversa.
  • Inverter a fórmula, fazendo um período rápido elevar o alvo ou um período lento elevar a dificuldade.
  • Tratar 2.016 blocos como 2.016 intervalos medidos; o cálculo atual da mainnet abrange 2.015 intervalos.
  • Esquecer os limites de 3,5 e 56 dias, powLimit, divisão inteira ou arredondamento do nBits compacto.
  • Aplicar uma afirmação da mainnet à Testnet4, testnet legada, signet, regtest ou outra cadeia de prova de trabalho.
  • Supor que a previsão de um explorador seja entrada de consenso, não estimativa antes do bloco de fronteira.
  • Usar horários locais de recebimento em vez dos timestamps de cabeçalho usados pelo cálculo.
  • Confundir dificuldade atual, trabalho por bloco, chainwork acumulado ou resultado da escolha de bifurcação.

Medição e inferência

  • Tratar taxa de hash estimada como inventário direto das máquinas ativas, em vez de inferência do trabalho e chegadas aleatórias.
  • Extrapolar um reajuste de uma pequena parte do período, onde a variância comum pode dominar.
  • Ler alta da dificuldade como prova de alta do preço, receita dos mineradores, energia ou descentralização.
  • Ler queda como prova de falha da rede sem examinar trabalho absoluto, concentração e duração.
  • Comparar dificuldades entre cadeias sem normalizar função hash, alvo de referência e regras de ajuste.
  • Descrever dez minutos como prazo, garantia de serviço ou tempo fixo de confirmação.
  • Inferir rentabilidade sem recompensa, taxas, disponibilidade, termos do pool, hedge, eletricidade, financiamento e eficiência.

Segurança e operações

  • Tratar o reajuste como proteção imediata contra entrada ou saída abrupta de taxa de hash no período atual.
  • Supor que dificuldade menor aumenta a capacidade do bloco ou elimina imediatamente uma fila de transações.
  • Escolher política de confirmação só pela dificuldade, ignorando trabalho acumulado, capacidade de reorganização e valor.
  • Ignorar incentivos à manipulação de timestamps e mitigações específicas ao avaliar mecanismos de ajuste.
  • Mudar aritmética de consenso, indexação de fronteiras ou codificação compacta sem vetores entre implementações e plano de ativação.

Equívocos comuns

  • Cada bloco do Bitcoin leva dez minutos. Dez minutos é a média-alvo com taxa de hash compatível; cada chegada continua aleatória.
  • Mineradores votam na próxima dificuldade. Nós validadores calculam independentemente o nBits permitido; um bloco que declare outro valor é inválido.
  • Um alvo 20% menor significa dificuldade 20% maior. A relação é inversa: multiplicador do alvo 0,8 implica dificuldade 1/0.8 = 1.25, ou 25% maior.
  • O reajuste mede diretamente a taxa de hash. Ele reage à produção de blocos com timestamps; toda taxa é estimativa com hipóteses de amostragem e tempo.
  • Dificuldade é a política monetária do Bitcoin. O reajuste estabiliza o ritmo temporal da emissão baseada em altura; regras separadas definem subsídios e reduções.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...