Ir para o conteúdo
Financial Context Wiki

Confirmações de bloco

Guia orientado por verificação sobre profundidade de confirmação PoW, estados safe e finalized de PoS, substituição no mempool, reorganizações e política de crédito de depósitos em plataformas.

Atualizado

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

Resposta direta

Uma confirmação de bloco é uma afirmação específica do observador e do protocolo: uma transação está incluída em um bloco da cadeia canônica vista por esse observador. A convenção inclusiva comum do Bitcoin Core conta o bloco que contém a transação como confirmação um. Para altura de inclusão h e altura da melhor cadeia H, a profundidade é H - h + 1. Alguns serviços exibem apenas os descendentes como H - h; portanto, a convenção deve ser declarada.

Em Proof of Work, a profundidade reduz o risco de reorganização sob premissas explícitas, mas não cria um ponto mágico de finalidade absoluta. Sistemas Proof of Stake podem expor estados nativos do protocolo. A Ethereum distingue latest, safe e finalized; uma quantidade fixa de blocos, slots ou minutos não substitui esses rótulos. Os estados detectado, creditado, negociável e sacável de uma plataforma são políticas internas distintas mesmo após o limiar da cadeia ser atingido.

Espera estimada
1.2 min
Intervalo ilustrativo
54s - 1.5 min

Os resultados são aproximações educacionais. Eles excluem regras de local, impostos, latência, comportamento do oráculo e outros parâmetros específicos do protocolo, a menos que sejam mostrados.

Como funciona

  1. Fixe cadeia e rede, ativo, identificador da transação, nó ou API, instante do observador, modelo de consenso e convenção de contagem. Verifique destinatário, valor e eventual memo ou tag antes de considerar que um hash correspondente é o pagamento pretendido.
  2. Separe assinada, transmitida, aceita pelo mempool local de um nó e propagada. Mempools são visões de política, não uma fila global de consenso. Verifique taxas, ancestrais não confirmados, Replace-by-Fee ou substituição pelo mesmo nonce e gastos conflitantes.
  3. Verifique inclusão pelo hash do bloco, altura, índice da transação e ancestralidade canônica, não só pela altura ou selo do explorador. Em cadeias de contas, inspecione também status do recibo, logs e mudança de estado efetiva; uma execução incluída ainda pode reverter.
  4. Aplique o modelo de consenso. Em PoW, declare a convenção, calcule a profundidade e compare visões independentes de melhor cadeia e trabalho acumulado. Em PoS, consulte estados nativos head, safe, justified ou finalized; não os deduza de distância fixa em blocos ou slots.
  5. Registre o ciclo de vida como estados explícitos: criada, transmitida, aceita no mempool local, incluída, profundidade canônica ou estado safe/finalized, reorganizada, reincluída, substituída ou conflitante. Uma reorganização não garante que a transação original retorne a todos os mempools.
  6. Mantenha separado o livro da plataforma: observada, limiar de rede atingido, creditada, negociável e sacável. Aplique a política vigente da plataforma por ativo, rede, valor e incidente; manutenção, conformidade e revisão manual podem acrescentar atrasos independentes.
  7. Cruze nós ou provedores independentes e continue monitorando até o estado exigido. Registre hashes, alturas, horários, rótulos RPC e versão da política, e ensaie substituição, reorganização, atraso de finalidade, nó desatualizado, relay da ponte e indisponibilidade da plataforma.

Exemplos resolvidos

  • Convenção de contagem. Uma transação Bitcoin está no bloco canônico h = 900,000 e a ponta da melhor cadeia é H = 900,005. A profundidade inclusiva é 900,005 - 900,000 + 1 = 6 confirmations; uma interface que conta só descendentes informa 900,005 - 900,000 = 5. A diferença é terminológica se ambas se referem ao mesmo hash e ancestralidade.
  • Reorganização e reinclusão. A transação primeiro tem 1 confirmation no bloco 900,000; depois o bloco sai da melhor cadeia e ela volta a 0 se continuar válida e sem conflito. Se for reincluída em 900,003 e a ponta alcançar 900,006, a profundidade inclusiva será 900,006 - 900,003 + 1 = 4 confirmations. Se um conflito confirmado a substituir, o Bitcoin Core pode informar confirmações negativas.
  • Rótulos PoS não são contagens de blocos. Suponha que uma transação Ethereum esteja no bloco de execução 20,000,000, enquanto um nó informa latest = 20,000,020, safe = 20,000,012 e finalized = 19,999,980, todos na mesma ancestralidade. A profundidade latest numérica é 20,000,020 - 20,000,000 + 1 = 21; a transação é safe, mas não finalized. São necessários ancestralidade dos hashes e rótulos de consenso; alturas não bastam.
  • Limiar da cadeia versus crédito da plataforma. A política exige 6 confirmations. Um depósito no bloco 900,000 está em 5/6 quando a ponta é 900,004 e chega a 6/6 em 900,005. Se a plataforma aplicar depois uma 15-minute compliance hold, elegibilidade on-chain e horários de crédito, negociação ou saque continuam sendo estados distintos; a retenção não é uma sétima confirmação.

Riscos

  • Consultar cadeia, rede ou ativo incorretos.
  • Usar hash, destinatário, memo ou tag errados.
  • Tratar uma transação assinada mas não transmitida como pendente.
  • Tratar o mempool de um nó como estado global da rede.
  • Não detectar rejeição por política, expulsão ou falta de propagação.
  • Ignorar substituição RBF, por mesmo nonce ou gasto conflitante.
  • Interpretar mal ancestrais, descendentes ou taxas de pacote não confirmados.
  • Misturar contagens inclusivas e somente de descendentes.
  • Confiar em nó desatualizado, sincronizando ou isolado.
  • Comparar alturas sem verificar hashes e ancestralidade.
  • Perder confirmações em reorganização PoW curta.
  • Tratar profundidade fixa como segurança absoluta para todo valor e adversário.
  • Confundir tempo decorrido, slots, epochs e blocos produzidos.
  • Tratar o head PoS como safe.
  • Tratar bloco safe como finalized.
  • Não detectar atraso de finalidade enquanto blocos continuam sendo produzidos.
  • Tratar execução incluída mas revertida como sucesso da aplicação.
  • Confundir logs de tokens ou interface do explorador com o estado resultante.
  • Equiparar detecção, crédito, negociação e permissão de saque da plataforma.
  • Tratar confirmação na origem como conclusão do fluxo de ponte, emissor ou destino.

Erros comuns

  • Um hash pesquisável ou entrada no mempool local já estão confirmados.
  • Uma convenção e o limiar de seis confirmações valem para toda cadeia, valor e serviço.
  • Uma taxa maior faz blocos posteriores ou finalidade PoS chegarem mais rápido.
  • Uma contagem fixa de blocos ou slots Ethereum equivale a safe ou finalized.
  • Inclusão ou finalidade garante execução correta, destinatário certo, crédito da plataforma ou conclusão da ponte.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...