Ir para o conteúdo
Financial Context Wiki

Finalidade em blockchain: evidências, premissas e camadas de liquidação

Finalidade é a garantia específica de um protocolo de que uma decisão não será substituída sem violar as premissas de segurança ou acionar uma recuperação excepcional. Validade, escolha de fork, evidência de finalidade, limites de falha, dependências entre camadas e liquidação do aplicativo devem ser analisadas separadamente.

Atualizado

Análise educacional de protocolo. Rótulos como “confirmado”, “seguro”, “committed” ou “finalizado” só têm significado junto com a cadeia, as regras, as evidências, as premissas de falha, a camada e a política do aplicativo.

Resposta direta

Finalidade é a garantia específica de um protocolo de que uma decisão aceita, como um bloco, checkpoint ou compromisso de estado, não será substituída sem violar as premissas de segurança declaradas ou recorrer a uma recuperação excepcional. Não é uma propriedade física dos bytes da transação nem significa apenas que “a transação foi bem-sucedida”. Toda alegação deve identificar o objeto, a rede, a versão do protocolo, as evidências, o modelo de falhas e tempo, o ponto inicial confiável e o observador.

Validade, canonicidade e finalidade são conceitos diferentes. Um bloco válido satisfaz as regras de transição de estado e autorização. A escolha de fork seleciona o head canônico atual entre os candidatos válidos. A finalização aplica um predicado adicional, como um certificado de commit ou checkpoint finalizado, a um ancestral desse head. Uma transação pode ser executada com sucesso em um bloco válido que depois perca a escolha de fork; um head pode ser canônico sem estar finalizado; e um evento finalizado na cadeia de origem ainda pode falhar em uma ponte, corretora ou aplicação.

Sistemas de prova de trabalho costumam oferecer liquidação probabilística, não um bit explícito de finalidade: conforme o trabalho válido acumulado cresce acima de um bloco, substituí-lo tende a ficar menos provável e mais caro sob as premissas declaradas de poder de hash e rede. Um protocolo do tipo BFT pode oferecer finalidade determinística condicional: após um certificado de commit válido, duas decisões conflitantes não podem ser committed ao mesmo tempo se o peso defeituoso permanecer abaixo do limite demonstrado. Em PoS, a finalidade também pode ser responsabilizável ou econômica, pois votos conflitantes identificam peso passível de slashing. Esses rótulos descrevem evidências diferentes.

Nenhum protocolo torna o histórico absolutamente imutável. Comprometimento catastrófico de chaves, violação do limite de falha, bugs de cliente, transições inválidas aceitas por implementações, intervenção de governança ou recuperação social podem atravessar o limite do modelo. “Finalizado” deve significar que o caminho normal de reorganização do protocolo não pode substituir essa decisão sob essas premissas; a recuperação excepcional e sua autoridade devem ser documentadas separadamente.

Como analisar a finalidade

  1. Nomeie o objeto e o escopo. Identifique transação, bloco, checkpoint, raiz de estado, mensagem entre cadeias ou saque; registre cadeia, rede, camada, versão, altura ou slot, hash do bloco e checkpoint confiável.
  2. Verifique a validade antes do status. Reexecute ou valide de outra forma a transição de estado e a ancestralidade relevantes. Segundo as regras reais, quórum, pontuação de trabalho ou selo da interface não podem finalizar um objeto inválido.
  3. Separe seleção do head e finalização. Reconstrua a escolha de fork e o caminho canônico atual, depois localize o ancestral finalizado ou committed. Registre se o objeto foi apenas observado, confirmado, justificado, considerado seguro, committed ou finalizado.
  4. Reproduza as evidências. Em PoW, verifique cabeçalhos, alvo e chainwork acumulado acima do bloco. Em protocolos de voto, verifique elegibilidade, snapshot de pesos, domínio da mensagem, origem e destino, altura, rodada, desigualdade do quórum, assinaturas, locks e ancestralidade do certificado.
  5. Declare as premissas de safety e liveness. Especifique peso bizantino ou offline, sincronia, atraso, equivocação, comprometimento de chaves, correlação entre clientes, mudanças de membros, disponibilidade de slashing e resposta a uma paralisação. Uma parada pode preservar safety e perder liveness.
  6. Mapeie cada camada de liquidação. Acompanhe recebimento pelo sequenciador, execução L2, publicação de dados, inclusão L1, finalidade L1, conclusão de prova ou disputa, execução da ponte, crédito na corretora e ação do aplicativo. Rótulos parecidos em camadas distintas podem representar predicados diferentes.
  7. Defina e monitore uma política do aplicativo. Estabeleça evidências aceitáveis conforme valor e consequência, consulte nós independentes, trate reorganizações e alertas de finalidade conflitante, pause ações irreversíveis quando as premissas falharem e registre quem autoriza a recuperação.

O número de confirmações é uma observação, não uma regra universal de finalidade. No Bitcoin Core, confirmations depende da posição do bloco na cadeia ativa atual, enquanto chainwork registra o trabalho esperado acumulado. No Ethereum, a escolha do head por LMD-GHOST e a justificação e finalização de checkpoints por Casper FFG são transições distintas. No CometBFT, um commit exige mais de dois terços do poder em precommit para o mesmo bloco, na mesma altura e rodada. Cada status deve ser interpretado em seu próprio protocolo.

Exemplos calculados

1. Liquidação probabilística por prova de trabalho

O white paper do Bitcoin modela um atacante com participação de hash q=0.10 tentando alcançar a cadeia honesta depois de uma vantagem z=6. Sob as premissas de tentativas de hash independentes e distribuição de Poisson, a probabilidade calculada é:

P=0.0002428 = 0.02428%

O resultado é pequeno, não zero, e não constitui uma garantia universal de “seis confirmações”. A política real deve considerar valor, chainwork observado, concentração do poder de hash, risco de eclipse ou partição, incentivos de taxas e a credibilidade da premissa de participação constante.

2. Justificação e finalização no Ethereum

Considere um caminho simplificado de checkpoints consecutivos com saldo efetivo ativo total 100. Votos de 67/100 ligando o checkpoint justificado C_0 ao alvo C_1 atingem pelo menos dois terços e justificam C_1. Um link posterior elegível de 67/100 de C_1 para seu filho direto C_2 pode finalizar C_1 segundo a regra Casper FFG aplicável.

O head pode avançar além de C_2 enquanto a parte mais nova permanece não finalizada. Se o saldo 34 estiver offline, restam apenas 66 e a finalização imediata para, embora a escolha de fork e a produção de blocos possam continuar. Após mais de quatro epochs sem finalidade, o inactivity leak do Ethereum começa a penalizar a não participação para que uma supermaioria ativa possa enfim recuperar a finalidade.

3. Safety e liveness no CometBFT

Considere poder total 100 e a exigência de >2/3 precommits para o mesmo bloco, na mesma altura e rodada. Poder inteiro 67 realiza o commit. Dois conjuntos de commit com peso 67 se cruzam em pelo menos 67 + 67 - 100 = 34 de poder. Se o peso bizantino for inferior a um terço e os validadores honestos seguirem as regras de lock, dois commits conflitantes não podem se formar.

Se o peso 34 estiver indisponível, somente 66 poderá votar e nenhum commit será formado. O protocolo pode preservar safety enquanto a finalidade para. “Não existe bloco finalizado conflitante” e “novos blocos continuam sendo finalizados” são garantias diferentes.

4. Status do OP Stack e prazos de saque

Um sequenciador OP Stack pode expor inicialmente um bloco L2 como unsafe. Quando ele puder ser derivado integralmente dos dados da cadeia L1 canônica atual, o nó de rollup poderá marcá-lo como safe. Quando as entradas L1 correspondentes receberem um sinal de finalidade L1, o bloco L2 derivado poderá se tornar finalized.

Esse status se refere à derivação a partir de entradas finalizadas. Uma saída de optimistic rollup ou saque de L2 para L1 possui outro processo de prova e disputa e pode ser chamado de “finalizado” somente após sua condição de contestação ser satisfeita. Um aplicativo que reúna confirmação do sequenciador, inclusão de dados L1, finalidade do consenso L1 e execução do saque em um único instante pode liberar valor cedo demais.

Riscos e falhas de revisão

Definição e evidência

  • Chamar qualquer execução, recibo, confirmação, checkpoint ou selo bem-sucedido de “final”.
  • Omitir cadeia, rede, versão, hash do objeto, altura ou slot, camada e observador.
  • Tratar o head atual do fork choice como ancestral finalizado ou supor que a finalização selecione o head mais recente.
  • Contar blocos ou minutos sem validar ancestralidade, alvos, trabalho, votos ou certificados.
  • Comparar “duas confirmações” ou “dez minutos de finalidade” entre protocolos com evidências e modelos de falha diferentes.
  • Verificar assinaturas sem elegibilidade, peso, domínio, origem, destino, altura e rodada.
  • Igualar custo econômico, evidência passível de slashing e execução efetiva da penalidade.
  • Descrever risco probabilístico como zero ou safety determinística condicional como irreversibilidade absoluta.

Falhas de protocolo e operação

  • Exceder o limite bizantino, perder o peso online necessário para liveness ou ocultar uma partição de rede.
  • Permitir divergência entre implementações sobre validade, fork choice, transições, arredondamento do quórum ou ancestralidade do certificado.
  • Aceitar votos, commits, checkpoints ou dados de weak subjectivity obsoletos, repetidos ou de outra rede.
  • Concentrar chaves, stake, poder de hash, clientes, relays, nuvens ou visões RPC atrás de identidades nominalmente distintas.
  • Supor que inactivity leak, timeout ou mudança de view restaure o progresso imediatamente e sem consequências.
  • Não alertar sobre atraso de finalidade, certificados conflitantes, reorganização profunda, equivocação ou raízes finalizadas divergentes.
  • Usar governança emergencial ou recuperação social sem documentar autoridade, coordenação, versão do cliente e garantias afetadas.

Desalinhamento entre camadas e aplicação

  • Tratar inclusão pelo sequenciador como safety L2, publicação L1, finalidade L1, aceitação de prova e saque concluído ao mesmo tempo.
  • Liberar ativos em ponte antes que o evento de origem e a verificação própria da ponte satisfaçam a política.
  • Creditar depósitos ou executar operações irreversíveis a partir do status de um único RPC sem conciliação independente.
  • Supor que a finalidade garanta verdade do oráculo, correção do contrato, disponibilidade de dados, solvência da corretora ou liquidação jurídica.
  • Aplicar o mesmo limite fixo a qualquer valor, contraparte, incentivo de ataque e custo de recuperação.

Equívocos comuns

  • Uma transação bem-sucedida está finalizada. O sucesso descreve somente uma transição em um histórico candidato; canonicidade e finalidade exigem evidências adicionais.
  • Mais confirmações reduzem exatamente a zero o risco de PoW. A probabilidade do modelo pode cair muito, mas continua condicionada às premissas e não vira uma impossibilidade lógica.
  • Dois terços sempre significam finalidade. Desigualdade, tipo de mensagem, snapshot de pesos, altura, rodada, relação origem-destino e regra de lock são específicos do protocolo.
  • Finalidade garante que a rede continue avançando. Safety pode permanecer intacta enquanto participação ou conectividade insuficientes impedem novas finalizações.
  • Finalidade L1 conclui toda ação L2 ou de ponte. Derivação, prova de validade ou fraude, janela de contestação e execução no destino acrescentam prazos e caminhos de falha distintos.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...