Ir para o conteúdo
Financial Context Wiki

Prova de histórico: pedidos registrados, ticks, slots e consenso Limites

Proof of History é o relógio sequencial de cadeia de hash da Solana: torna verificáveis a ordem registrada e as contagens de cálculo, mas não prova por si só o tempo real, a justiça da ordem de chegada, a escolha de fork ou a finalidade.

Atualizado

Análise de protocolo apenas para fins educacionais; não constitui aconselhamento de investimento, operação de validadores, desempenho ou segurança. Os parâmetros de Proof of History, o comportamento do cliente, a programação de líderes, a votação, a escolha de fork e as regras de confirmação podem mudar conforme a rede e a versão do software.

Resposta direta

Prova de histórico, ou PoH, é o relógio criptográfico e a estrutura de dados de ordenação de razão do Solana. Um produtor aplica repetidamente uma função hash para que cada saída dependa da saída anterior, registre periodicamente contagens e estados e misture dados derivados de transações na cadeia. Um verificador pode recalcular essas transições e confirmar a ordem registrada por aquela cadeia específica.

PoH não é um algoritmo de consenso independente. Ele não escolhe o fork canônico, fornece acordo ponderado por participação, finaliza blocos nem prova que uma transação chegou à rede em determinado momento real. A Solana combina o relógio com líderes programados, execução de transações, votos de validadores, escolha de fork e bloqueios no estilo Tower BFT. Dois forks podem conter sequências PoH internamente válidas; as regras de consenso determinam qual histórico a rede segue.

O alcance dessa garantia é limitado. Se uma entrada compromete os dados d após o estado h2, o estado posterior h3 = H(h2 || d) não pode ser calculado sem esse compromisso. Isso demonstra que o produtor conhecia d antes de h3 e fixa sua posição registrada em relação às saídas posteriores. Não demonstra quando cada validador recebeu d, se a ordem foi justa, se d descreve um fato externo verdadeiro nem se a entrada se tornou canônica.

A geração é sequencial porque a próxima entrada não é conhecida até que o hash anterior exista. Os estados limites publicados permitem que os verificadores reproduzam segmentos delimitados separados em paralelo, mas o trabalho de hash agregado permanece. Por esse motivo, PoH é frequentemente comparado com uma função de atraso verificável, enquanto a explicação Tower BFT do próprio Solana o chama de um uso vago desse termo; um VDF formal normalmente possui uma interface de avaliação e verificação cuja verificação é eficiente em relação à avaliação sequencial.

Como analisar a Prova de História

  1. Fixar o contexto de rede e software. Rede de registro, hash de gênese, slot, época, Agave ou outra versão do cliente e tempo de observação. Leia valores ativos como hashes_per_tick, ticks_per_slot e ns_per_slot; não importe constantes de um artigo antigo ou de outro cluster.
  2. Reconstrua a cadeia de hash. Comece a partir de um estado predecessor confiável e verifique o num_hashes de cada entrada, o hash resultante e a lista de transações. Na implementação de entrada do Agave, um identificador de entrada depende da entrada anterior e, quando as transações estão presentes, um hash derivado de suas assinaturas.
  3. Validar ticks e posicionamento de slot. Verifique entradas de tick, contagens de hash esperadas, altura de tick e altura máxima de tick em relação às regras do banco e do registrador. O gravador mapeia a altura do tick em um slot usando ticks_per_slot configurado; slots são intervalos de protocolo, não evidências independentes de um relógio externo.
  4. Distinguir inclusão de chegada. Um compromisso prova que a entrada foi conhecida o mais tardar em sua inserção nessa sequência. Para reivindicar um limite inferior, identifique uma referência anterior assinada para um estado PoH anterior. Nenhum dos limites prova a ordem global vista pela primeira vez, a justiça do mempool ou um carimbo de data / hora UTC confiável.
  5. Geração separada da verificação. Meça a produção sequencial em uma cadeia de dependência e, em seguida, meça a reprodução usando limites de segmento autenticados e núcleos disponíveis. Relate hashes totais, latência do caminho crítico, trabalho agregado do verificador e suposições de dados de limite, em vez de dizer apenas que a verificação é “rápida”.
  6. Trace o caminho de consenso. Identifique o líder programado, estado do banco, votos, bloqueios, regra de escolha de fork, estado enraizado ou finalizado e nível de compromisso. Uma cadeia PoH válida ainda pode pertencer a um fork perdedor, e um contador de aparência mais longa por si só não é um certificado de consenso.
  7. Stress casos adversários e operacionais. Equivocação do líder de teste, omissão e reordenação de transação, slots ignorados, partições, hardware mais rápido ou mal calibrado, contagens de ticks inválidas, atraso repetição, indisponibilidade do razão, divergência de cliente e operador correlacionado ou controle de infraestrutura.

A saída da revisão deve distinguir quatro declarações: validade de sequência, tempo de protocolo configurado, status de consenso e tempo externo. Indique quais dados de hash e razão iniciais eram confiáveis, quais hashes foram recalculados, quais evidências de votação ou compromisso foram verificadas e quais observações vieram de relógios locais ou serviços de terceiros.

Exemplos trabalhados

1. A inserção de dados corrige uma posição registrada

Considere h1 = H(h0) e depois h2 = H(h1). Um produtor insere um compromisso derivado de transação d e calcula h3 = H(h2 || d), seguido por h4 = H(h3). Qualquer pessoa que reproduza as mesmas operações pode verificar se a cadeia registrada confirma d entre h2 e h3, e que h4 depende do resultado.

A instrução do limite superior é restrita: o produtor conhecia d antes de calcular h3. Se a própria transação assinada fizer referência a h1, um verificador também poderá mostrar que ela foi formada após o conhecimento desse estado anterior, sujeito a verificações de assinatura e procedência. Sem essa referência anterior, PoH sozinho não fornece limite inferior. Nenhum dos casos prova quando outro nó recebeu a transação pela primeira vez.

2. A repetição do segmento reduz a latência, não o trabalho agregado

Suponha que um intervalo registrado contenha 1.000.000 hashes e pontos de verificação autenticados o dividam em 10 segmentos de 100.000 hashes. Com núcleos suficientes, dez segmentos podem ser reproduzidos simultaneamente, de modo que a latência de verificação do relógio de parede pode se aproximar da duração de um segmento mais a sobrecarga.

Os verificadores coletivamente ainda executam 1.000.000 de hashes; os pontos de verificação expõem estados iniciais independentes, mas não transformam a cadeia em uma prova sucinta. O desempenho depende do hardware, do agendamento, da movimentação da memória e da confiança nos limites. É por isso que uma repetição PoH paralela não deve ser automaticamente descrita como o algoritmo de verificação eficiente de cada construção formal de VDF.

3. A aritmética de tick e slot depende da configuração

Assuma uma configuração ilustrativa com hashes_per_tick = 100,000 e ticks_per_slot = 8. Um slot totalmente com hash contém hashes 100,000 * 8 = 800,000, com limites de tick após cada intervalo configurado. Alterar qualquer um dos parâmetros altera o mapeamento; este exemplo não é uma constante de mainnet atual.

Agave também suporta casos de protocolo em que o comportamento de contagem de hash é representado pela configuração em vez desta multiplicação simplificada. Um revisor deve obter os campos reais do banco e validar as entradas de acordo com as regras do cliente. A conversão de um slot ou contagem em segundos depende adicionalmente da calibração da duração alvo e da execução observada, não apenas da verificação criptográfica.

4. A ordem registrada não é uma ordem de chegada ou finalidade

Suponha que a transação A atinja um líder antes da transação B, mas o líder registra B perto da contagem 300.000 e A perto da contagem 450.000. PoH válido prova que B precede A naquela sequência produzida. Não prova que B chegou primeiro, que a ordem foi justa ou que outro líder observou a mesma ordem.

Agora suponha que uma partição produza bifurcação X e bifurcação Y, cada uma com uma sequência válida. A validação PoH pode rejeitar entradas malformadas em qualquer bifurcação, mas não seleciona X ou Y. A programação do líder, os votos ponderados pela participação, os bloqueios, a escolha da bifurcação e o nível de compromisso solicitado determinam o resultado do consenso; os aplicativos não devem substituir uma contagem PoH por confirmação ou evidência de finalidade.

Riscos e falhas de revisão

Erros criptográficos e de tempo

  • Chamar PoH de um relógio de parede confiável ou reivindicar uma contagem de hash prova independentemente um UTC timestamp.
  • Dizer que a inclusão da transação prova o tempo de recebimento em toda a rede, a ordem vista pela primeira vez ou a veracidade dos dados externos.
  • Assumir que a geração sequencial evita que um produtor retenha, omita ou escolha quando inserir dados conhecidos.
  • Tratar a resistência à colisão apenas como um limite completo na velocidade do hardware, desvio de calibração ou implementação variação.
  • Descrevendo a repetição de segmento paralelo como trabalho zero ou como uma prova sucinta sem contar hashes agregados.
  • Chamar PoH de VDF formal sem declarar a construção, a interface de prova e as suposições de verificação que estão sendo comparadas.
  • Confiar limites de pontos de verificação, hashes predecessores ou baixados segmentos do razão sem autenticar sua proveniência.

Consenso e erros de protocolo

  • Tratar PoH, prova de participação, Tower BFT, eleição de líder, escolha de fork e finalidade como o mesmo mecanismo.
  • Assumindo que a sequência válida com a contagem mais alta deve ser canônica sem examinar votos e estado de escolha de fork.
  • Tratar uma entrada reproduzida localmente como confirmada, enraizada ou finalizada sem verificar a semântica de compromisso solicitada.
  • Usar valores históricos de hashes_per_tick, ticks_per_slot ou duração de slot como constantes atuais universalmente válidas.
  • Ignorando slots ignorados, rotação de líder, partições, equívocos e diferenças de versão do cliente ao reconstruir a ordem.
  • Comparar contagens de bifurcações não relacionadas ou estados iniciais como se pertencessem a uma sequência autenticada.
  • Assumir que o blockhash recente de uma transação é apenas um carimbo de data / hora do relógio de parede em vez do contexto de validade do protocolo.

Operações, desempenho e controle erros

  • Benchmarking de geração de hash sozinho, ignorando execução, verificação de assinatura, reprodução, largura de banda e armazenamento.
  • Equacionando o paralelismo de segmento teórico com a recuperação observada do validador em CPU, I/O e contenção de memória.
  • Ignorando falhas de validação de tick, travamentos de gravador, atrasos bancários, lacunas de razão, confiança de instantâneo e estado corrompido.
  • Contando identidades de validador como independentes quando cliente, hospedagem, rede, infraestrutura ou controle líder é compartilhado.
  • Presumir que hardware mais rápido remove latência de rede, perda de pacotes, censura, negação de serviço ou risco de concentração de participação.
  • Apresentar uma duração de slot alvo, estimativa de rendimento ou benchmark antigo como uma garantia de nível de serviço.

Equívocos comuns

  • PoH é o algoritmo de consenso completo de Solana. PoH fornece uma sequência gravada verificável; votação do validador, bloqueios, escolha de fork e outras regras de consenso decidem o histórico seguido pela rede.
  • PoH prova o tempo exato do mundo real de cada transação. Prova dependência e contagem dentro de uma sequência autenticada; mapear essa sequência para o tempo civil requer configuração e observações externas.
  • PoH garante uma ordem de transação justa. Um líder pode selecionar, atrasar, reordenar ou omitir entradas dentro das restrições de protocolo e recursos; PoH torna auditável apenas a ordem resultante registrada.
  • PoH é mineração de prova de trabalho com outro nome. Ambos usam hashing, mas a função principal de PoH é um relógio sequencial, não uma corrida paralela aberta cujo trabalho vencedor escolhe a cadeia.
  • Qualquer sequência PoH válida é final. Forks concorrentes podem ser válidos internamente; confirmação e finalidade exigem evidência de consenso da rede.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...