---
title: "Prova de histórico: pedidos registrados, ticks, slots e consenso Limites"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

> 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.

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Tópicos relacionados

- [Mecanismos de consenso](/pt-br/crypto/consensus-mechanism/)
- [Prova de aposta](/pt-br/crypto/proof-of-stake/)
- [Validadores](/pt-br/crypto/validator/)
- [Fork-choice regras](/pt-br/crypto/fork-choice-rule/)
- [Tempo de bloqueio](/pt-br/crypto/block-time/)

<a id="sources"></a>

## Fontes

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (acessado: 2026-08-19)
- [Solana: A New Architecture for a High Performance Blockchain](https://solana.com/solana-whitepaper.pdf) - Solana (acessado: 2026-08-19)
- [Tower BFT: Solana's High Performance Implementation of PBFT](https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft) - Solana (acessado: 2026-08-19)
- [Agave Entry Module](https://github.com/anza-xyz/agave/blob/master/entry/src/entry.rs) - Anza (acessado: 2026-08-19)
- [Agave Proof-of-History Recorder](https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs) - Anza (acessado: 2026-08-19)
- [Agave Bank Runtime](https://github.com/anza-xyz/agave/blob/master/runtime/src/bank.rs) - Anza (acessado: 2026-08-19)
- [Transaction Confirmation and Expiration](https://solana.com/developers/cookbook/transactions/confirmation) - Solana (acessado: 2026-08-19)
- [Verifiable Delay Functions](https://eprint.iacr.org/2018/601) - IACR Cryptology ePrint Archive (acessado: 2026-08-19)

Source: https://wiki.fcontext.com/pt-br/crypto/proof-of-history/index.mdx