Ir para o conteúdo
Financial Context Wiki

Consenso de Nakamoto: validade, trabalho da cadeia, confirmações e reorganizações

O consenso de Nakamoto combina regras de validade aplicadas independentemente, produção de blocos por prova de trabalho sem permissão, propagação e seleção da cadeia válida com mais trabalho acumulado. Analise separadamente visões locais, chainwork, confirmações, reorganizações, prefixo comum, incentivos e ataques de rede.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

O consenso de Nakamoto é o processo do tipo Bitcoin em que nós aplicam independentemente as regras de validade, produtores de prova de trabalho estendem blocos sem lista permissionada de membros, blocos se propagam pela rede ponto a ponto e cada nó escolhe o ramo válido com mais prova de trabalho acumulada. Ele ordena transações válidas segundo a visão observada pelo nó; não torna válida uma transação inválida, não estabelece fatos externos ao livro-razão nem cria finalidade determinística imediata.

A validade vem antes da seleção da cadeia. Um ramo com cabeçalho, prova de trabalho, transação, script, saída já gasta, valor de coinbase ou limite de bloco inválido é rejeitado, independentemente da altura ou trabalho alegado. Entre ramos que passam pelas regras do nó e têm dados disponíveis, o trabalho acumulado, não apenas o número de blocos, determina a cadeia ativa. “Cadeia mais longa” é uma abreviação informal para a cadeia válida que representa o maior esforço de prova de trabalho.

A ponta ativa é provisória. Blocos válidos concorrentes podem dar temporariamente visões locais diferentes a nós honestos bem conectados; trabalho adicional costuma resolver o fork, e um nó pode desconectar um ramo e conectar outro numa reorganização. A contagem de confirmações mede a profundidade da transação na cadeia ativa atual do observador. Maior profundidade pode reduzir a probabilidade de alcance sob um modelo específico de hashrate e rede, mas nenhuma contagem é universalmente final.

O termo abrange mais que hashing. Seu argumento de segurança também depende de validade de blocos e transações, propagação ponto a ponto, adoção honesta da cadeia válida de maior trabalho, potência efetiva de mineração honesta suficiente, comportamento econômico e usuários observando independentemente a rede e o software pretendidos. Prefixo comum, crescimento e qualidade da cadeia são propriedades formais provadas apenas em modelos declarados, não fatos incondicionais de toda cadeia de prova de trabalho implantada.

Como analisar o consenso de Nakamoto

  1. Fixe identidade e escopo de observação. Registre chain, network, genesis hash, client version, conjunto de regras, checkpoints ou configuração assume-valid, observador, pares e horário. Capture bestblockhash, height e chainwork; dois nós podem relatar honestamente pontas diferentes enquanto mensagens se propagam.
  2. Valide antes de comparar trabalho. Verifique ligação dos cabeçalhos, restrições de timestamp, alvo decodificado, prova de trabalho, compromissos Merkle e witness, transações, scripts, gastos UTXO, coinbase e limites de recursos. Um ramo invalid não se torna elegível alegando mais altura ou trabalho.
  3. Reconstrua a árvore observada. Ligue cada candidato por hash do bloco anterior a um ancestral conhecido e diferencie blocos completos de cabeçalhos. Reconcilie os estados active, valid-fork, valid-headers, headers-only e invalid em interfaces como getchaintips; não chame toda ponta visível de cadeia concorrente válida.
  4. Recalcule o trabalho acumulado. Decodifique o alvo nBits de cada cabeçalho e calcule o trabalho representado pelas regras inteiras da implementação, conceitualmente work = floor(2^256 / (target + 1)). Some pela ancestralidade e compare ramos válidos desde o ancestral comum; altura, hashrate estimado e rótulos de pools não substituem chainwork.
  5. Rastreie seleção e reorganização. Reproduza a escolha do candidato de maior trabalho, a ordem local no empate e o estado de chegada. Se surgir um ramo válido melhor, identifique o fork, desconecte o sufixo antigo, conecte o novo, atualize o UTXO set e reconcilie transações com o mempool e registros da aplicação.
  6. Defina uma política de confirmação baseada em risco. Calcule confirmations = tip_height - block_height + 1 apenas para bloco na cadeia ativa atual. Declare valor em risco, reversibilidade, parcela atacante, propagação, exposição eclipse, taxa stale observada, profundidade e resposta; seis é convenção, não limiar de finalidade do protocolo.
  7. Teste todo o argumento sob estresse. Teste partições, latência, retenção de blocos, mineração egoísta, ataques eclipse, concentração de pool e hardware, variações súbitas de hashrate, incentivos de taxas e subsídio, divergência de clientes, reorganizações profundas e recuperação. Relacione conclusões a prefixo comum, crescimento, qualidade, persistência e vivacidade apenas sob as premissas citadas.

O resultado é uma explicação reproduzível e específica do observador sobre qual história válida um nó seleciona agora e por quê. Regras definem admissibilidade; prova de trabalho encarece histórias alternativas; propagação expõe o trabalho; escolha de fork seleciona a história atual; e política de confirmações decide quando a aplicação age. Reduzir essas camadas a “aprovação da rede” oculta as condições que podem falhar.

Exemplos resolvidos

1. Trabalho inválido não vence

Suponha que o ramo A informe valid_A = false e chainwork_A = 1,200 units, enquanto B tem valid_B = true e chainwork_B = 1,000 units. O nó rejeita A e escolhe B. Trabalho só é comparado entre candidatos admissíveis; prova de trabalho não autoriza coinbase excessiva, assinatura inválida ou gasto duplo.

Se um observador tiver apenas os cabeçalhos de A e outro seus blocos completos, os estados podem diferir até terminar download e validação. Cabeçalhos válidos não provam que todas as transações e transições passaram pela validação completa.

2. Altura não é trabalho acumulado

Num exemplo simplificado com alvo variável, C adiciona seis blocos de 100 unidades cada, ou 6 * 100 = 600 units. D adiciona cinco de 130, ou 5 * 130 = 650 units. Se ambos forem válidos e partirem do mesmo trabalho, D é o ramo de maior trabalho apesar de ter um bloco a menos.

Se duas pontas válidas tiverem exatamente 650 units, o empate não força todos os nós a ver de imediato a mesma ponta. Ordem de chegada e estado local podem divergir até outro bloco válido tornar um ramo mais pesado. Uma visão transitória empatada não é finalidade global determinística.

3. Confirmações podem ser removidas

Uma transação incluída na altura 100 quando a ponta ativa é 105 tem tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations. Suponha que outro ramo válido bifurque após 99 e se torne o de maior trabalho na altura 106 sem a transação. A reorganização desconecta os blocos antigos 100 through 105; a transação perde seis confirmações ativas e pode voltar ao mempool, conflitar com outro gasto ou continuar ausente.

Aplicações devem reconciliar hash e ancestralidade, não guardar apenas o número seis. Crédito em exchange, bens entregues, mensagens de ponte e liquidação de derivativos podem ser economicamente irreversíveis mesmo quando a história de origem não é.

4. A probabilidade de alcance depende do modelo

No modelo ilustrativo do whitepaper do Bitcoin, seja a parcela atacante q = 0.10, a honesta p = 0.90 e a vantagem honesta z = 6. A aproximação de Poisson dá lambda = z * (q / p) = 0.6666667 e P(catch up) = 0.0002428027 = 0.02428027%. Com q = 0.30 na mesma profundidade, sobe para P(catch up) = 0.1321111687 = 13.21111687%.

Esses números não são garantias atuais do Bitcoin. O cálculo supõe tentativas hash independentes e estáveis e as condições de corrida do modelo; omite isolamento eclipse, vantagem de propagação, estratégias egoístas, respostas de preço e aluguel, bugs e reação da aplicação. A política deve declarar o modelo e testar condições piores, não citar apenas seis confirmações.

Riscos e falhas de revisão

Erros de protocolo e medição

  • Comparar trabalho antes de validar independentemente cabeçalho, corpo e ancestralidade.
  • Chamar o ramo mais alto ou visto primeiro de vencedor sem calcular chainwork acumulado.
  • Usar contagem de blocos, hashrate nominal, parcela de pool ou explorador como proxy de chainwork.
  • Misturar mainnet, testnet, signet, forks, versões, checkpoints ou identidades genesis.
  • Tratar dados só de cabeçalho, indisponíveis ou otimistas como história totalmente validada.
  • Ignorar decodificação do alvo, aritmética inteira, ligação de hash anterior ou ancestral comum.
  • Tratar um RPC ou explorador como visão global sem hash, altura, hora e contexto de pares.

Erros de rede, incentivos e controle

  • Supor propagação instantânea ou a mesma ordem de chegada em todos os nós.
  • Tratar empate de trabalho como estado global único, não como visões locais temporárias.
  • Ignorar blocos stale, latência, retenção, mineração egoísta e vantagem de propagação.
  • Inferir mineradores independentes de nomes de pools ou propriedade física de suas parcelas.
  • Ignorar concentração de pool, firmware, fabricante, hosting, energia, geografia e rede.
  • Tratar recompensas como prova de que extensão honesta é sempre ótima para todos.
  • Omitir exposição a eclipse, partição, Sybil, envenenamento de pares, DoS e manipulação temporal.

Erros de liquidação e segurança

  • Chamar confirmação de finalidade do protocolo ou prometer que seis não podem ser removidas.
  • Aplicar uma contagem a todo valor, contraparte, reversibilidade e ameaça.
  • Converter o exemplo probabilístico do whitepaper em probabilidade de ataque medida hoje.
  • Dizer que maioria hash falsifica assinaturas, toma moedas arbitrárias ou valida inflação.
  • Dizer que minoria hash não pode desviar com lucro nem causar reorganização ou censura.
  • Igualar a ponta de maior trabalho a fatos externos, propriedade jurídica ou liquidação da aplicação.

Erros comuns

  • A cadeia mais longa sempre tem mais blocos. Nós Bitcoin escolhem a cadeia válida de maior trabalho acumulado; altura pode ser proxy inadequado se os alvos mudarem.
  • Mineradores decidem quais regras são válidas. Eles propõem blocos; cada nó completo aplica independentemente suas regras configuradas.
  • Seis confirmações criam finalidade absoluta. Seis é convenção; o risco depende de modelo, profundidade, adversário, propagação e integridade da observação.
  • Um atacante de 51% pode gastar moedas alheias. Hash pode apoiar reorganização, gasto duplo e censura, mas não fornece assinatura privada alheia nem faz nós inalterados aceitarem inflação inválida.
  • Hashrate total alto prova descentralização e segurança. Controle efetivo, visibilidade, hardware, coordenação de pools, diversidade de clientes, incentivos e duração também importam.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...