Ir para o conteúdo
Financial Context Wiki

Subjetividade fraca: checkpoints confiáveis e sincronização PoS segura

A subjetividade fraca permite que um nó de prova de participação verifique para frente de forma objetiva após obter um ponto de verificação confiável suficientemente recente. Saiba por que assinaturas antigas podem apoiar históricos de longo alcance, como a atualidade do ponto de verificação e a independência da fonte são verificadas, e o que a sincronização do ponto de verificação não prova.

Atualizado

Para fins educacionais apenas; não é um conselho de investimento. Investir pode resultar em perda.

Resposta direta

Subjetividade fraca é um modelo de segurança proof-of-stake no qual um nó pode verificar blocos, transições de estado, votos e escolha de forks de acordo com as regras do protocolo após iniciar a partir de um ponto de verificação suficientemente recente obtido por meio de um canal confiável ou socialmente corroborado. A entrada subjetiva “fraca” é o ponto de partida. Não é permissão para escolher blocos posteriores arbitrários: uma vez ancorado, o nó deve rejeitar históricos que não contenham o ponto de verificação e verificar normalmente para frente.

O problema é a ambiguidade histórica. Um adversário que obtém chaves de validadores que saíram e que não podem mais ser punidos economicamente pode construir uma longa história alternativa com assinaturas que parecem válidas. Um nó que observou a cadeia canônica enquanto esses validadores ainda eram passíveis de penalização mantém memória útil. Um nó completamente novo, um nó cuja base de dados foi deletada ou um nó offline além da janela de recência segura do protocolo pode não ser capaz de identificar a história socialmente canônica apenas a partir dos dados de gênese e das mensagens de pares.

No Ethereum, um ponto de verificação de fraca subjetividade é um epoch e block_root que o cliente trata como um ponto de referência absoluto. Uma sincronização bem-sucedida deve provar que o caminho canônico contém essa raiz naquela época; uma incompatibilidade é uma falha crítica, não um voto de escolha de fork. Um ponto de verificação de fraca subjetividade também difere de um ponto de verificação finalizado comum: se um nó encontra pela primeira vez duas histórias finalizadas conflitantes sem memória prévia, apenas as regras de finalização não identificam qual história social é canônica.

Não universalize o mecanismo do Ethereum. Clientes leves CometBFT começam a partir de um cabeçalho confiável dentro de um trusting_period configurado e transferem confiança usando sobreposição de conjuntos de validadores, assinaturas, limites de tempo e testemunhas. A pesquisa Ouroboros Genesis, em vez disso, define uma regra de seleção de cadeia destinada a inicializar a partir de um bloco gênesis confiável sob seu modelo de segurança declarado. Portanto, “prova de participação” não implica em um único formato de checkpoint, uma única fórmula de período ou um único procedimento de inicialização.

Além disso, separe a subjetividade fraca de um atalho de sincronização. A sincronização por checkpoint pode reduzir o tempo de inicialização e o processamento do estado histórico, mas velocidade não é a definição de segurança. Uma raiz confiável não autentica o site que a forneceu, não valida uma carga útil de execução fora das suposições declaradas pelo cliente, não restaura histórico podado, não prova a disponibilidade dos dados nem torna honesto um conjunto de pares eclipsados.

Como verificar um bootstrap de subjetividade fraca

1. Identifique o protocolo exato e o modelo de segurança

Registre o network, chain ID, raiz ou hash do gênesis, fork ativo ou runtime, versão do cliente, tipo de checkpoint e especificação de consenso. Determine se o protocolo exige um checkpoint social recente, um cabeçalho confiável mais conjunto de validadores, uma cadeia de prova de finalização ou apenas o gênesis sob um modelo diferente. Nunca transplante o compute_weak_subjectivity_period do Ethereum ou o trusting_period do CometBFT para outra cadeia sem suas regras.

2. Decida se a confiança existente ainda é atual

Inventarie o último ponto de verificação finalizado localmente e verificado do nó, sua época ou altura e horário, a fonte de tempo atual e qualquer restauração de banco de dados. Calcule a idade usando as regras e o estado vivos do protocolo, não uma estimativa de calendário lembrada. Para Ethereum, o guia da Fase 0 testa current_epoch <= ws_state_epoch + ws_period; o Electra altera o cálculo do período para depender do saldo ativo total e da rotatividade do saldo. Se a confiança expirou, obtenha uma nova âncora de forma externa, em vez de tentar mais contra pares não confiáveis.

3. Adquirir e corroborar o ponto de verificação

Obtenha o mesmo checkpoint de canais administrados de forma independente e provenientes de fontes independentes: por exemplo, um nó que você opera, outro operador, várias equipes de clientes e exploradores com infraestrutura distinta. Registre cada fonte, horário de recuperação, rede, epoch e raiz completa. Cinco URLs que copiam de um upstream são um único domínio de falha. Uma simples maioria de respostas não substitui a independência da fonte, transporte autenticado ou revisão social de incidentes.

4. Vincule cada campo de ponto de verificação

Verifique a rede e a identidade gênese antes do valor do ponto de verificação. Preserve a raiz completa sem truncamento e emparelhe-a com a época ou altura exata, estado se necessário, versão do fork e tempo de aquisição. O guia do Ethereum usa o block_root:epoch_number; a inicialização do CometBFT também vincula um cabeçalho confiável e conjunto de validadores, além de parâmetros de confiança. Uma raiz correta anexada à cadeia ou altura errada não é um ancoradouro válido.

5. Implemente um caminho de sincronização com falha fechada

Configure o checkpoint através da interface documentada do cliente e mantenha os logs de inicialização. Durante a sincronização, exija que o caminho canônico no período do checkpoint seja igual ao block_root fornecido. O guia Ethereum exige um erro crítico descritivo e a saída do processo quando a asserção falha. Não descarte silenciosamente o checkpoint, não recorra à maioria dos peers, não o sobrescreva com uma resposta mais recente de um peer, nem mantenha um validador assinando enquanto sua visão de consenso for incerta.

6. Separe as camadas que foram e que não foram verificadas

Acompanhe separadamente a confiança no ponto de verificação do consenso, a verificação de farol ou bloco de consenso, o status da carga de execução, a sincronização do estado de execução, o preenchimento histórico e as provas de aplicação. A sincronização otimista Ethereum permite que o ExecutionPayload de uma âncora de ponto de verificação seja assumido como VALID sem primeiro fornecê-lo ao mecanismo de execução, enquanto um nó otimista não deve realizar funções de validador. O preenchimento do ponto de verificação Lighthouse verifica a integridade da cadeia de hash histórica e as assinaturas do proponente, mas não reconstrói cada estado histórico por padrão.

7. Atualize, monitore e ensaie a recuperação

Defina um alerta e atualize a margem confortavelmente dentro do período aplicável. Monitore a finalização, a saúde do relógio, a discordância do cliente, o status execution_optimistic, a diversidade de pares, a idade do checkpoint e lacunas de backfill. Pratique a recuperação de um banco de dados excluído, checkpoint expirado, fontes contraditórias e um provedor indisponível. Mantenha registros assinados de âncoras e decisões, mas não permita que um checkpoint arquivado se torne um checkpoint obsoleto permanentemente confiável.

Exemplos resolvidos

Ponto de verificação Ethereum com folga restante

Use um estado ilustrativo cujo cálculo de referência Electra aplicável forneça ws_period = 3,532 epochs. Suponha current_epoch = 420,000 e que o ponto de verificação corroborado independentemente seja checkpoint_epoch = 418,200:

checkpoint_age = 420,000 - 418,200 = 1,800 epochs.

O teste de atualidade do guia é 420,000 <= 418,200 + 3,532, então o ponto de verificação está dentro do período. Em 32 slots * 12 seconds = 6.4 minutes per epoch, sua idade é 1,800 * 6.4 / 1,440 = 8 days. O espaço restante é 3,532 - 1,800 = 1,732 epochs, ou 1,732 * 6.4 / 1,440 = 7.6978 days. Isso usa um período da tabela de referência, não uma promessa da rede ao vivo; o cliente deve calcular a partir do fork real e do estado.

O ponto de verificação expirado não é reparado por mais pares

Suponha current_epoch = 500,000, checkpoint_epoch = 496,000 e o aplicável ws_period = 3,532 epochs:

checkpoint_age = 500,000 - 496,000 = 4,000 epochs.

Porque 500,000 > 496,000 + 3,532, o ponto de verificação está desatualizado por 4,000 - 3,532 = 468 epochs. A 6.4 minutos por época, isso está 468 * 6.4 / 60 = 49.92 hours além do limite. Baixar a mesma raiz expirada de 100 pares não restaura a suposição; o operador precisa de um ponto de verificação suficientemente recente de canais confiáveis e corroborados.

Contagem de fontes versus independência das fontes

Um operador recebe cinco respostas. Quatro relatam epoch = 600,000 e uma raiz completa idêntica rotulada root_A, enquanto uma relata uma raiz completa diferente rotulada root_B. A investigação mostra que três sites concordantes todos fazem proxy do mesmo nó hospedado; o quarto é o próprio nó do operador. A aparente concordância é 4 / 5 = 80%, mas representa apenas duas linhagens independentes. Sob uma política que exige três caminhos administrativos e de dados independentes, o ponto de verificação ainda não é aprovado. Um terceiro operador independente confirma root_A, o serviço dissidente é isolado, e o registro de proveniência explica a decisão.

Orçamento do período de confiança estilo CometBFT

Considere uma cadeia configurada com unbonding_period = 21 days e um trusting_period = 14 days selecionado pelo operador, consistente com a exigência de que o período de confiança seja mais curto que o de desbloqueio. Um cabeçalho confiável com idade 11 days tem 14 - 11 = 3 days de margem. Uma meta de atualização diária deixa margem operacional. Se o cliente retornar após 16 days, o cabeçalho está dois dias além do seu período de confiança e deve ser substituído por uma nova inicialização confiável; as fórmulas de época Ethereum não decidem este caso CometBFT.

Riscos e falhas de revisão

  • Rede incorreta: Uma raiz válida de testnet, fork, clone ou gênese diferente pode ancorar o histórico errado.
  • Checkpoint obsoleto: Uma raiz fora do período aplicável não satisfaz mais a premissa sobre validadores recentes.
  • Fórmula de período errada: Atualizações do fork, saldos, churn, unbonding e parâmetros de segurança podem alterar o limite.
  • Fonte única: Vários endpoints podem compartilhar nó, conta de nuvem, banco de dados, provedor de DNS ou operador.
  • Distribuição comprometida: Uma versão, site, pacote, resposta DNS ou mensagem de suporte maliciosa pode trocar o checkpoint.
  • Comparação truncada: Comparar só prefixo, captura ou identificador formatado pode ocultar uma raiz completa diferente.
  • Campos incompatíveis: A raiz correta com época, altura, estado, fork ou chain errados não é o mesmo checkpoint.
  • Fallback para maioria dos peers: Um nó sob eclipse pode ver muitos peers adversários; a quantidade não substitui a âncora confiável.
  • Fallback silencioso: Um cliente ou wrapper que ignora um checkpoint rejeitado anula o controle fail-closed.
  • Históricos finalizados conflitantes: Um nó novo não resolve falha de consenso apenas porque ambos os ramos estão marcados como finalizados.
  • Erro de relógio: Horário local incorreto compromete verificações de slot, época, idade, período de confiança e headers futuros.
  • Confusão de estado optimistic: Um bloco de consenso importado ainda pode conter execution payload não validado por completo.
  • Funções prematuras do validador: Assinar em estado optimistic, sem sincronização ou com âncora incerta pode causar votos errados ou slashing.
  • Confusão sobre integridade histórica: Sincronização por checkpoint e backfill podem omitir estados históricos mesmo com o head atual válido.
  • Assinaturas de backfill inválidas: Um bloco histórico ligado por hash ainda requer as verificações da assinatura do proponente.
  • Prova insuficiente de execução ou aplicação: A âncora de consenso não prova valores RPC arbitrários, alegações de contrato ou índices off-chain.
  • Lacuna de disponibilidade de dados: Conhecer a raiz de estado não garante acesso a cada body, blob, witness ou registro histórico.
  • Plano de recuperação expirado: Se a expiração for descoberta durante uma interrupção, talvez não exista fonte independente disponível.
  • Captura da coordenação social: Governança, equipes de clientes, exploradores, exchanges e operadores podem compartilhar incentivos ou dependências.
  • Falsa universalidade: Outro design PoS pode usar premissas, cadeias de prova, períodos de confiança ou garantias de bootstrap desde a gênese diferentes.

Equívocos comuns

Subjetividade fraca significa que as regras do protocolo são subjetivas após a inicialização?

Não. O nó aceita uma âncora recente específica através de um canal social ou confiável, e então aplica validação determinística e regras de escolha de fork à frente. Blocos que entram em conflito com a âncora são rejeitados.

Algum ponto de verificação finalizado é automaticamente um ponto de verificação de inicialização seguro?

Não. Deve pertencer à rede e à história social canônica pretendidas, ser suficientemente recente de acordo com as regras aplicáveis, incluir os campos requeridos e vir por um caminho confiável e corroborado. A finalização observada pela primeira vez em uma história fornecida por um invasor não estabelece a proveniência.

Sincronizar desde o gênesis resolve o problema do ataque de longo alcance?

Não para um protocolo cujo modelo de segurança requer um checkpoint de fraca subjetividade recente. Reproduzir internamente assinaturas válidas desde o gênese não informa a um nó novo qual das duas histórias finalizadas antigas a comunidade realmente seguiu. Outros protocolos podem fornecer garantias de inicialização do gênese diferentes sob diferentes suposições.

A sincronização de checkpoint valida toda a execução histórica e o estado?

Não. O comportamento do cliente é estratificado e específico da implementação. O nó pode confiar ou importar otimistamente a âncora, sincronizar o estado atual da execução separadamente e preencher apenas os links de bloco e as assinaturas do proponente sem reconstruir todos os estados históricos.

Um checkpoint codificado pode ser confiável para sempre?

Não. Um checkpoint está vinculado a uma rede e ponto final. Ele pode continuar útil como um registro de auditoria ou restrição histórica, mas um nó cuja suposição de confiança recente tenha expirado precisa de uma âncora adequadamente recente ou do processo de recuperação especificado por esse protocolo.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...