Ir para o conteúdo
Financial Context Wiki

Regras de escolha de fork: ramos válidos, peso e heads canônicos

Uma regra de escolha de fork transforma a visão local validada de um nó em um head canônico atual. Validade, ancestralidade, trabalho acumulado ou peso de voto, checkpoints, tempo, desempates, reorganização e finalidade devem ser analisados separadamente.

Atualizado

Análise educacional de protocolo. O head atual de um nó depende da rede, versão das regras, visão local validada, evidência de peso, checkpoint e tempo; ele não fica automaticamente finalizado nem seguro para liquidação irreversível.

Resposta direta

Uma regra de escolha de fork é o procedimento do protocolo que transforma a visão local validada de blocos e mensagens de consenso concorrentes em um head canônico atual. A saída é provisória e relativa ao observador: dois nós honestos podem escolher brevemente heads diferentes porque receberam outros blocos válidos, votos ou eventos temporais. Quando suas visões admissíveis convergem sob as premissas de rede do protocolo, a regra também deve convergir.

A escolha de fork não torna válido um bloco inválido. Verificações de transição de estado, autorização, prova, ancestralidade e disponibilidade de dados determinam primeiro quais candidatos são admissíveis; só então seus pesos são comparados. O head escolhido também não está necessariamente finalizado. A escolha identifica o ramo a estender agora; uma regra de finalidade pode proteger um ancestral mais antigo com evidência de segurança mais forte. Substituir o head atual pode ser operação normal, enquanto substituir um checkpoint finalizado cruza outro limite do protocolo.

“Cadeia mais longa” não é fórmula universal. Bitcoin seleciona a cadeia válida de maior trabalho: o trabalho de prova esperado acumulado, não a altura bruta, decide. O LMD-GHOST do Ethereum parte de um checkpoint justificado, filtra ramos viáveis e segue de modo guloso o filho com maior saldo atestador de últimas mensagens, mais o boost do proponente aplicável; somente a mensagem elegível mais recente de cada validador contribui. Outros protocolos podem usar certificados de disponibilidade, locks do líder, rounds ou certificados explícitos de commit, em vez de competição persistente pelo ramo mais pesado.

O resultado depende de entradas exatas: cadeia e rede, versão do fork, âncora confiável, hora ou slot atual, blocos válidos conhecidos, links de pais, snapshot de trabalho ou peso de voto, últimas mensagens, evidência de equivocação, checkpoints justificado e finalizado, disponibilidade, tempo do proponente e desempates determinísticos. Um selo do explorador ou um RPC é observação da saída de um nó, não a regra nem prova independente das entradas.

Como analisar uma regra de escolha

  1. Fixe identidade e versão. Registre cadeia, rede, fork de consenso, versão do cliente, gênese ou âncora confiável, altura ou slot atual e regra exata ativa. Não importe lógica de mainnet para testnet, sidechain, rollup ou proposta futura.
  2. Construa o grafo admissível. Verifique hashes, pais, provas de consenso, transições, estado do payload e disponibilidade necessária. Marque nós desconhecidos, otimistas, inválidos e podados; peso não recupera ramo inválido.
  3. Reconstrua ancestralidade e restrições. Encontre o ancestral comum e confirme quais candidatos descendem de checkpoints, locks ou certificados exigidos. Separe a árvore bruta observada da árvore filtrada que a regra considera.
  4. Reproduza cada entrada de peso. Em PoW, decodifique alvos e some a prova de cada bloco ao chainwork acumulado. Em votação, verifique identidade, saldo efetivo ativo ou outro peso, domínio, raiz alvo, slot ou epoch, substituição da última mensagem, tratamento da equivocação e boost temporário.
  5. Execute seleção e desempate exatamente. Aplique a recursão ou comparador especificado em cada bifurcação, com arredondamento e ordem determinística do protocolo. Registre se peso igual permite preferência local temporária, sem fingir que o empate é acordo final.
  6. Concilie mudanças de head. Quando muda o vencedor, identifique blocos removidos e anexados, reverta e reproduza estado, concilie recibos, logs e mempool e calcule profundidade desde o ancestral comum. Distinga head, safe, justified, committed e finalized.
  7. Teste sob estresse e monitore. Teste blocos atrasados ou ocultos, partições, votos obsoletos, equivocação, balanceamento, tempo do proponente, divergência de clientes, checkpoints fracos e dados indisponíveis. Compare nós independentes e alerte sobre divergência, reorganização profunda ou conflito com estado finalizado antes de ações irreversíveis.

No Bitcoin Core atual, os candidatos são primeiro comparados por nChainWork; com trabalho igual, são ordenados pela sequência ativável mais antiga e por um desempate interno final. O campo RPC blocks é a altura da cadeia de maior trabalho totalmente validada, e bestblockhash identifica sua ponta. Na especificação atual do Ethereum, get_head(store) parte de justified_checkpoint, percorre uma árvore filtrada e escolhe em cada etapa o filho que maximiza (get_weight(store, child), child.root). São detalhes específicos de protocolo e versão, não definições genéricas de consenso.

Exemplos calculados

1. Troca por trabalho acumulado no Bitcoin

Dois ramos válidos compartilham o ancestral C. As pontas têm chainwork(A)=240 e chainwork(B)=235, então o nó escolhe A mesmo que uma visão superficial das alturas pareça similar. Um novo bloco válido acrescenta trabalho 10 ao ramo B:

chainwork(B') = 235 + 10 = 245

Como 245 > 240, B vira o candidato de maior trabalho. O nó desconecta os blocos de A posteriores a C, conecta B até B' e concilia as transações. A contagem bruta não basta quando alvos por bloco diferem; trabalho igual é empate temporário, não evidência de finalidade.

2. Subárvore observada mais pesada e gulosa

Use uma árvore LMD-GHOST simplificada enraizada no checkpoint justificado J. Seus filhos são A e B. As últimas mensagens elegíveis dão peso 61 à subárvore inteira de A e 39 à de B, então o primeiro passo escolhe A. Os filhos de A, A_1 e A_2, têm pesos de subárvore 34 e 27; o passo seguinte escolhe A_1.

O head é encontrado escolhendo repetidamente o filho mais pesado, não contando comprimento nem selecionando a folha com maior voto direto isolado. A regra de produção também inclui filtro de viabilidade, snapshots de saldo, tratamento de equivocação, tempo do proponente e desempates omitidos nesta árvore didática.

3. Substituição da última mensagem

Suponha que as últimas mensagens elegíveis deem inicialmente peso 55 a A e 45 a B. Um validador de peso 20 envia depois uma mensagem elegível mais nova apoiando um descendente de B. A contabilidade de última mensagem remove o apoio antigo de A e o adiciona a B:

A: 55 - 20 = 35; B: 45 + 20 = 65

O peso é contado uma vez, não nos dois ramos, por isso o caminho escolhido pode mudar. Isso não autoriza voto inconsistente: se evidência válida de attester slashing identificar equivocação, o store atual do Ethereum rastreia o validador e exclui seu peso da pontuação ordinária.

4. Filtro de checkpoint e boost do proponente

Suponha que um nó observe peso bruto de últimas mensagens 70 em um ramo conflitante com seu checkpoint finalizado e 30 em um descendente viável. O ramo conflitante é excluído antes da escolha do head; maioria bruta não supera a restrição de checkpoint pelo fork choice ordinário.

Agora dois filhos viáveis no slot atual têm pesos de atestação 35 e 50. Na configuração citada do Ethereum, um boost oportuno equivale a 40% do peso de um comitê, não 40% do stake total. Se o comitê pesa 100 e o boost se aplica ao filho de 35, sua pontuação vira 35 + 40 = 75, superando 50 nessa etapa. O boost é temporário e específico do fork; não é voto adicional nem finalidade.

Riscos e falhas de revisão

Conjunto candidato e evidência

  • Comparar pesos antes de validar pais, transições, provas, estado do payload ou dados exigidos.
  • Tratar execução desconhecida ou otimista, dados indisponíveis ou visão só de headers como estado totalmente validado.
  • Usar altura, timestamp, quantidade de transações, fees ou popularidade do explorador no lugar do peso especificado.
  • Somar dificuldade exibida sem reproduzir prova por bloco e chainwork sob os alvos corretos.
  • Contar todo voto histórico em vez da última mensagem elegível de cada validador com o snapshot correto.
  • Ignorar domínio, raiz, slot, epoch, pontualidade, assinatura, equivocação e evidência de slashing.
  • Comparar ramos brutos que filtros de checkpoint, lock, certificado ou disponibilidade tornam inelegíveis.
  • Aplicar especificação futura, parâmetro de outra rede ou otimização como lei de consenso atual.

Falhas de seleção e operação

  • Descrever Bitcoin como “maior altura” bruta ou Ethereum como voto simples de dois terços no head.
  • Trocar a recursão gulosa da subárvore por pontuação global de folhas ou omitir boost, arredondamento e desempate da raiz.
  • Supor que nós com ordem de chegada, relógio ou mensagens diferentes reportem o mesmo head imediatamente.
  • Não desconectar e repetir corretamente estado, recibos, logs, índices e mempool durante uma reorganização.
  • Permitir divergência de clientes em validade, viabilidade de checkpoints, últimas mensagens, tempo ou desempates.
  • Perder condições de balanceamento, ocultação, equivocação, partição, eclipse, votos atrasados e reorganização do proponente.
  • Confiar em um RPC, explorador, relay, família de clientes, nuvem ou operador como visão independente do consenso.

Desalinhamento de finalidade e aplicação

  • Chamar o head escolhido de finalizado, irreversível ou seguro sem a evidência separada de finalidade.
  • Liberar depósitos, mensagens de ponte ou operações irreversíveis sobre head transitório sem política por valor.
  • Supor que ancestral finalizado garanta correção ou disponibilidade de todo head, payload, oráculo ou resultado novo.
  • Usar contagem fixa em cadeias com modelos distintos de trabalho, voto, checkpoint e recuperação.
  • Tratar checkpoints emergenciais, âncoras de subjetividade fraca ou recuperação social como entradas ordinárias sem confiança.

Equívocos comuns

  • O ramo mais longo sempre vence. O protocolo pode comparar trabalho acumulado, últimas mensagens ponderadas, certificados ou outra pontuação; altura bruta não é universal.
  • O ramo observado mais pesado é automaticamente válido. Validade e disponibilidade filtram candidatos antes da seleção por peso.
  • Fork choice e finalidade são a mesma regra. O primeiro escolhe o head atual a estender; a segunda protege um ancestral sob condições adicionais.
  • Todo voto permanece para sempre no total. Em regras de última mensagem, uma nova mensagem elegível substitui o apoio anterior do validador.
  • Um explorador prova a cadeia canônica. Ele só informa a visão de uma infraestrutura; validação e conciliação independentes continuam necessárias.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...