Solana Proof of History: Como funciona o PoH

Nota de precisão: O desempenho da rede, a contagem de validadores, as taxas, as funcionalidades do protocolo, o suporte de carteiras e as integrações de terceiros mudam ao longo do tempo. Trate os valores datados como instantâneos históricos e verifique a documentação atual de fontes primárias.

O Solana Proof of History é um mecanismo de ordenação temporal criptográfica, não um protocolo de consenso autónomo. Funciona com o Tower BFT e o Proof of Stake para ajudar os validadores a ordenar eventos e a concordar com o ledger.

Aviso legal: Este artigo destina-se apenas a fins informativos e educativos. Não constitui aconselhamento financeiro ou de investimento. Os investimentos em criptomoedas acarretam riscos significativos, incluindo a perda potencial do capital. Consulte um consultor financeiro qualificado antes de tomar decisões de investimento.

Índice

1. O Que É o Proof of History? O Relógio Criptográfico da Solana Explicado
2. Como Funciona o Proof of History: A Cadeia de Hash SHA-256 Passo a Passo
3. Por Que o Proof of History Pode Reduzir a Sobrecarga de Ordenação
4. Proof of History vs. Proof of Work vs. Proof of Stake: Uma Comparação Direta
5. Como o Proof of History Interage com a Arquitetura Completa da Solana
6. Limitações e Críticas ao Proof of History: Uma Avaliação Honesta
7. Perguntas Frequentes Sobre o Proof of History e a Solana
8. Conclusão: O Proof of History é uma Inovação Genuína?

O que é o Solana Proof of History?

O Proof of History (PoH) é um mecanismo de marcação temporal criptográfica integrado na blockchain Solana que cria um registo verificável da ordem e do momento dos eventos, sem exigir que os validadores comuniquem constantemente entre si para estabelecer quando algo aconteceu.

Uma blockchain é um ledger distribuído onde os registos são ligados criptograficamente e mantidos através de uma rede de participantes sem uma autoridade central. Em qualquer blockchain distribuída, os nós devem concordar em duas coisas antes de confirmarem uma transação: o que aconteceu e quando aconteceu. A maioria das redes gasta um esforço computacional significativo na segunda questão. O Proof of History responde-lhe criptograficamente, para que a rede possa focar toda a sua largura de banda na primeira.

Uma distinção crítica a estabelecer imediatamente: o Proof of History não é um mecanismo de consenso. O verdadeiro mecanismo de consenso da Solana é o Tower BFT. O PoH é a camada de marcação temporal da qual o Tower BFT depende para operar eficientemente. Confundir os dois é o erro mais comum na cobertura da tecnologia da Solana, e este artigo corrige-o em todo o texto.

O Proof of History foi inventado por Anatoly Yakovenko, cofundador da Solana Labs e anteriormente engenheiro sénior na Qualcomm. Ele introduziu o conceito num whitepaper de 2017 intitulado Solana: A new architecture for a high performance blockchain. A beta da mainnet da Solana foi lançada em março de 2020, construída sobre a arquitetura que esse whitepaper descreveu.

A Solana é uma blockchain de Camada 1 de alto desempenho cujo token nativo é o SOL. O seu teto teórico de processamento, possibilitado pelo Proof of History a trabalhar em conjunto com várias outras inovações arquitetónicas, é um valor teórico histórico de aproximadamente 65.000 transações por segundo (TPS). O processamento real sustentado sob condições típicas de rede é substancialmente inferior, uma distinção que este artigo aborda em detalhe.

Se ouviu descrever o Proof of History como "o mesmo que Proof of Stake" ou assumiu que é o mecanismo de consenso da Solana, ambas as abordagens estão incorretas. A comparação completa e a relação exata entre estes mecanismos aparecem nas secções abaixo.

Como Funciona o Proof of History: A Cadeia de Hash SHA-256 Passo a Passo

A analogia do relógio criptográfico capta o que o PoH faz, mas para compreender por que razão investidores e programadores o tratam como uma verdadeira inovação arquitetónica, é necessário ver como o relógio realmente funciona.

O Que É uma Função de Hash Criptográfica? (O Bloco de Construção)

Uma função de hash criptográfica recebe qualquer entrada (uma palavra, um documento, um registo de transação) e produz uma saída de comprimento fixo que é única para essa entrada e determinística. É também praticamente impossível de inverter: conhecer a saída não diz nada de útil sobre o que entrou. A saída é chamada de hash e funciona como uma impressão digital única para quaisquer dados que a produziram.

Mude um caractere da entrada e a saída mudará completa e imprevisivelmente. Essa sensibilidade à entrada é precisamente o que torna o hashing sequencial uma base fiável para a marcação temporal.

A função de hash específica que o Proof of History utiliza é o SHA-256 (Secure Hash Algorithm, 256-bit), o mesmo algoritmo que protege as transações de Bitcoin. O SHA-256 é computacionalmente intensivo para executar, mas trivialmente rápido de verificar. Essa assimetria é central: produzir um hash é lento, mas verificar um é instantâneo. Essa propriedade é exatamente o que torna o SHA-256 adequado para a função de marcação temporal do PoH.

A Cadeia de Hash: Como o PoH Codifica o Tempo Criptograficamente

O PoH funciona executando o SHA-256 numa sequência ininterrupta, onde cada saída se torna a entrada para a computação seguinte. Como cada passo requer tempo de computação real e irredutível, a cadeia de saídas constitui um registo verificável do tempo decorrido. Ninguém pode fingir ter chegado ao passo 500.000 sem ter efetivamente computado os passos 1 a 499.999.

Pense nisto como um cronómetro criptográfico. Cada tique do relógio é uma saída SHA-256 registada, e a cadeia de tiques prova que uma quantidade específica de computação e, portanto, uma quantidade mensurável de tempo, decorreu entre os eventos.

Eis como a sequência funciona:

1. O validador líder inicia a cadeia. Um validador designado (o "líder" para aquele slot) executa o SHA-256 numa entrada inicial, que pode ser qualquer valor arbitrário ou o hash de um bloco anterior.
2. Cada saída torna-se a próxima entrada. O hash resultante é reintroduzido no SHA-256 como a nova entrada. Esta é a cadeia. Cada elo depende inteiramente do anterior.
3. Um contador de sequência rastreia a posição. Cada iteração carrega um número de contagem: hash #1, hash #2, hash #347.891. Este contador é a contagem de tiques do relógio.
4. As transações são incorporadas na cadeia à medida que chegam. Quando uma transação entra na rede, o líder faz o hash da mesma na sequência nesse preciso momento. Os dados da transação são incorporados na saída do hash naquela posição de contagem específica.
5. A posição incorporada prova o momento da transação. Uma transação com hash na posição 347.891 ocorreu comprovadamente após a posição 347.890 e antes da posição 347.892. Não é necessário um carimbo de data/hora externo. A própria cadeia é a prova.
6. Outros validadores verificam a sequência. A verificação é rápida porque verificar um hash demora uma fração do tempo que demora a produzi-lo. Um validador pode confirmar que toda a sequência é válida sem reexecutar todas as computações.
7. A cadeia resultante é uma linha do tempo à prova de adulteração. Alterar qualquer hash em qualquer posição invalida todos os hashes que o seguem, tornando o registo impossível de falsificar sem refazer todo o trabalho subsequente.

A analogia da fotografia capta bem a propriedade de prova de adulteração. Imagine tirar uma fotografia a cada segundo, onde cada fotografia inclui a fotografia anterior dentro do enquadramento. Qualquer pessoa que olhe para a fotografia #1.000 pode verificar a sequência sem ter estado presente em cada disparo, porque cada imagem está criptograficamente aninhada na seguinte. Alterar a fotografia #400 corromperia visivelmente todas as imagens subsequentes.

Esta cadeia de hash sequencial é o que os criptógrafos chamam de funcionalmente semelhante a uma Verifiable Delay Function (VDF). Uma VDF formalmente definida, tal como descrita por Boneh, Bonneau, Bünz e Fisch no seu artigo de 2018 publicado na CRYPTO (IACR ePrint 2018/601), é uma função que requer um tempo prescrito para ser computada, não pode ser paralelizada para acelerar essa computação e produz uma prova que permite uma verificação rápida. O PoH alcança o mesmo efeito prático através de hashing SHA-256 sequencial. Não é formalmente uma VDF no sentido estrito da teoria da complexidade, mas a semelhança funcional é precisa. Investigadores académicos que descrevem o PoH como "semelhante a uma VDF" ou "uma VDF informal" estão a usar um enquadramento preciso.

Fonte: Anatoly Yakovenko, "Solana: A new architecture for a high performance blockchain," 2017. Disponível em solana.com/solana-whitepaper.pdf

Esta cadeia de carimbos temporais criptográficos é o que permite à camada de consenso da Solana, o Tower BFT, saltar as rondas de comunicação que atrasam outras blockchains, porque o tempo já está provado.

Porque é que o Proof of History da Solana Pode Reduzir a Sobrecarga de Ordenação

A fonte cita intervalos de rendimento (throughput) teóricos e observados historicamente, mas o Proof of History por si só não produz um valor de TPS. O mix de transações, o tráfego de votos, o agendamento de runtime, o hardware do validador, a rede, o congestionamento e a metodologia de medição afetam o rendimento reportado. Utilize medições em direto datadas para decisões operacionais.

As comparações com a Visa, Ethereum ou Bitcoin não são equivalentes: contam eventos diferentes e utilizam modelos de confiança, quitação e finalidade diferentes. O PoH é uma parte do design da Solana, a par do Sealevel, Turbine, Gulf Stream, mercados de taxas e infraestrutura de validador.

Como o Tower BFT Utiliza o PoH para Saltar Rondas de Comunicação

O ganho de velocidade do PoH não tem a ver com fazer hashing mais rápido. Tem a ver com a eliminação de toda uma categoria de comunicação que os mecanismos de consenso tradicionais exigem.

Sistemas distribuídos que devem tolerar falhas bizantinas (participantes defeituosos ou maliciosos) precisam de Tolerância a Falhas Bizantinas (BFT): a capacidade de chegar a consenso mesmo quando alguns validadores estão offline, a enviar informações falsas ou a comportar-se de forma adversária, desde que menos de um terço dos validadores esteja comprometido.

Definição chave: A Tolerância a Falhas Bizantinas (BFT) refere-se à capacidade de um sistema distribuído continuar a operar corretamente mesmo quando alguns participantes falham ou agem de forma maliciosa. O conceito tem origem no Problema dos Generais Bizantinos, uma experiência mental clássica da ciência da computação de Lamport, Shostak e Pease (1982).

Nos sistemas de consenso BFT tradicionais, os validadores têm de trocar mensagens para concordar em duas coisas antes de confirmar uma transação: o que aconteceu e a que horas aconteceu. Concordar com o tempo exige normalmente várias rondas de passagem de mensagens através da rede. À medida que o número de validadores aumenta, esta sobrecarga de comunicação cresce quadraticamente, tornando cada vez mais caro chegar a um consenso rapidamente.

O PoH fornece uma referência de ordenação verificável que pode reduzir alguma coordenação temporal. Não elimina a comunicação de consenso nem torna um slot equivalente à finalidade económica. A confirmação otimista, a confirmação enraizada e a quitação ao nível da aplicação utilizam limiares e tempos diferentes.

Sealevel e Gulf Stream: Velocidade Além do Relógio

O PoH por si só não produz 65.000 TPS. É a camada fundamental que torna possíveis as outras inovações de desempenho da Solana.

O Sealevel é o runtime de execução paralela de Smart Contracts da Solana. Smart Contracts são programas armazenados numa blockchain e invocados através de transações. Onde a EVM da Ethereum processa transações sequencialmente, o Sealevel pode executar transações não conflituosas através de múltiplos núcleos de processador. Este paralelismo provém das contas que cada transação declara que irá ler ou escrever; o PoH fornece uma referência de ordenação, mas não determina quais as contas que são independentes.

O Gulf Stream é o protocolo de encaminhamento de transações sem mempool da Solana. Em vez de manter transações não confirmadas num grupo de espera, o Gulf Stream empurra as transações para o próximo líder validador esperado antes de o bloco atual ser finalizado, utilizando o agendamento de líderes do PoH para saber quem é o próximo. O Turbine, o protocolo de propagação de blocos da Solana inspirado pelo BitTorrent, divide então os blocos confirmados em pacotes mais pequenos e distribui-os pela rede de validadores de forma eficiente.

O PoH é a base. O Sealevel e o Gulf Stream constroem-se diretamente sobre ele, e o mesmo acontece com o Turbine. O valor de 65.000 TPS reflete todas estas inovações a operar em conjunto, com o PoH como a camada de ordenação da qual cada uma depende.

As aplicações DeFi, incluindo corretoras descentralizadas e protocolos de empréstimo, exigem um elevado rendimento de transações para funcionarem à escala. A arquitetura da Solana baseada em PoH torna viável para estas aplicações processarem milhares de operações por segundo na camada base, uma capacidade que a maioria das atuais blockchains de Camada 1 não iguala, embora as soluções de Camada 2 noutras cadeias estejam a reduzir esta lacuna para casos de uso específicos.

Para compreender porque é que esta arquitetura é importante, ajuda comparar o PoH diretamente com os mecanismos de consenso para os quais foi concebido para trabalhar em conjunto.

Proof of History vs. Proof of Work vs. Proof of Stake: Uma Comparação Direta

O ponto estrutural mais importante antes desta comparação: o Proof of History não é um mecanismo de consenso. O Proof of Work e o Proof of Stake são mecanismos de consenso. Comparar o PoH diretamente ao PoW ou PoS é como comparar um relógio a um sistema de votação. Eles resolvem problemas diferentes, e essa distinção molda tudo o resto nesta tabela.

Nota: O TPS teórico da Solana representa o rendimento combinado de PoH, Sealevel, Turbine e Gulf Stream sob condições ideais. Este valor não é alcançado rotineiramente em produção.

PoH vs. Proof of Work: Velocidade e Energia

O Proof of Work da Bitcoin e o Proof of History da Solana abordam problemas diferentes, mas o contraste entre eles no rendimento e na energia é nítido. No PoW, os mineiros competem para resolver um puzzle computacionalmente intensivo. O vencedor adiciona o bloco seguinte e recebe uma recompensa. Esta competição é intencionalmente dispendiosa, uma vez que o gasto de energia é o que torna proibitivamente caro reverter a cadeia. A Bitcoin processa aproximadamente 7 TPS como resultado direto deste design.

O PoH não substitui o modelo de segurança do PoW. Resolve um problema diferente, o problema da ordenação temporal, com muito menos desperdício computacional. Apenas um validador (o líder atual) produz a sequência PoH, em vez de cada mineiro competir simultaneamente.

O SHA-256 também é utilizado no processo de mineração da Bitcoin, mas a aplicação difere fundamentalmente. Os mineradores de Bitcoin procuram uma hash com propriedades específicas numa corrida competitiva. O PoH da Solana executa o SHA-256 sequencialmente para produzir um registo temporal, não para competir por nada.

PoH vs. Proof of Stake: Não são a mesma coisa

Não, o Proof of History não é o mesmo que Proof of Stake. A Solana não utiliza o PoH em vez do PoS. Utiliza ambos simultaneamente, para fins diferentes.

O Proof of Stake é um mecanismo de consenso no qual os validadores são escolhidos para produzir blocos com base na quantidade de criptomoeda que decidiram investir em staking como garantia. A Ethereum mudou para Proof of Stake em setembro de 2022 com a sua atualização Merge. O PoS da Ethereum processa aproximadamente 15 a 30 TPS na sua camada base, com soluções de Camada 2 como a Arbitrum e a Optimism a estender a capacidade efetiva consideravelmente além desse valor.

A Solana utiliza um sistema baseado em PoS para a seleção de validadores, o que determina quem se torna o líder responsável por produzir a sequência PoH para um determinado slot. O PoH fornece então a ordenação temporal que o Tower BFT utiliza para alcançar o consenso. Os dois mecanismos são complementares, não concorrentes. O PoH é o relógio; o PoS determina quem lhe dá corda.

Como o Proof of History Interage com a Arquitetura Completa da Solana

Para os programadores que avaliam a Solana como uma plataforma, a questão não é apenas o que o PoH faz isoladamente. É como o PoH se encaixa na arquitetura completa de oito inovações que Anatoly Yakovenko descreveu no seu Whitepaper de 2017, e o que essa arquitetura exige do hardware que a executa.

Tower BFT: Utilizar o Registo PoH como um Relógio de Votação

O Tower BFT utiliza o registo temporal verificável do PoH para implementar um mecanismo de bloqueio de votos que seria impossível sem uma sequência de slots partilhada e fiável.

Eis como funciona na prática. Os validadores na Solana votam em blocos que acreditam ser válidos. Cada voto está associado a um número de slot PoH específico. O Tower BFT impõe uma regra de bloqueio: uma vez que um validador vota num slot, não pode votar num Fork conflituante por um número exponencialmente crescente de slots subsequentes. Quanto mais longo for o bloqueio, mais SOL em staking o validador corre o risco de perder por slashing se tentar votar em ambos os lados de um Fork.

O Tower BFT pode impor estes bloqueios baseados em tempo especificamente porque o PoH fornece uma sequência de slots verificável e partilhada. Sem o PoH, não haveria uma referência comum fiável para "o slot 347.891 ocorreu antes do slot 347.892". O bloqueio de votos baseado no tempo requer um relógio fiável. O PoH é esse relógio.

O calendário de líderes é determinado antecipadamente utilizando ponderações de SOL em staking. Os validadores sabem qual o nó que deverá produzir o fluxo PoH e propor um bloco para cada slot futuro. Esta previsibilidade permite o reencaminhamento consciente do líder antes de o bloco atual ser finalizado, reduzindo a dependência de uma Mempool global convencional sem eliminar o congestionamento, a perda de transações, as taxas de prioridade ou o risco de MEV.

BFT no contexto do Tower BFT significa que a rede tolera até um terço de validadores a agir de forma maliciosa ou a falhar, enquanto continua a alcançar o consenso. A estrutura de bloqueio exponencial garante que atacar a rede através da manipulação de votos se torne geometricamente mais caro à medida que o período de bloqueio aumenta.

Sealevel: Como a Ordenação de Transações PoH Permite o Paralelismo

A maioria das blockchains processa transações em série, uma de cada vez, porque sem uma ordenação verificada não conseguem determinar com segurança quais as transações que podem ser executadas simultaneamente sem conflitos. Se duas transações tentarem ambas modificar o mesmo saldo de conta, processá-las em paralelo sem conhecer a sua ordem corre o risco de resultados de gasto duplo.

O Sealevel resolve isto lendo a fila de transações verificada do PoH e analisando os conjuntos de contas de leitura e escrita declarados de cada transação. Como cada transação na Solana deve especificar quais as contas de onde lê e para onde escreve, o Sealevel pode identificar no momento da submissão quais as transações que são independentes. As transações independentes (aquelas que tocam em contas inteiramente diferentes) podem ser executadas simultaneamente em vários núcleos de processador ou threads de GPU. As transações interdependentes são executadas sequencialmente na sua ordem PoH verificada.

O papel do PoH é fornecer a fila de transações ordenada e com carimbo temporal que o Sealevel consome. Sem a ordenação verificada que o PoH produz, a execução paralela exigiria um custo fixo de coordenação elevado para evitar conflitos. A Solana refere-se aos seus programas na blockchain como "programas" em vez de contratos inteligentes na sua documentação nativa, refletindo uma distinção arquitetónica do modelo de execução da Ethereum, embora o termo "contratos inteligentes" seja amplamente compreendido e utilizado em toda a indústria.

O Gulf Stream utiliza o calendário de líderes do PoH para enviar transações não confirmadas diretamente para os próximos líderes validadores, e o Turbine utiliza blocos ordenados por PoH como base para a sua árvore de propagação de blocos ao estilo BitTorrent. Todos os principais componentes de desempenho na arquitetura da Solana dependem do PoH como a sua base de ordenação.

Esta coesão arquitetónica é também a origem de algumas das críticas mais significativas ao PoH, especificamente as exigências de hardware que impõe aos validadores.

Limitações e Críticas ao Proof of History: Uma Avaliação Honesta

O Proof of History traz compensações arquitetónicas reais, e a mais consequente delas é a exigência de hardware que impõe aos validadores que o executam.

Executar um validador da Solana requer hardware de servidor topo de gama: um CPU com elevado número de núcleos, um mínimo de 128 GB de RAM, SSDs NVMe e conectividade de rede multi-gigabit. A documentação da Solana recomenda especificações de hardware cujo custo de montagem e operação varia entre 5.000 $ e 20.000 $ ou mais.

Esta barreira de custo limita a participação no conjunto de validadores a operadores com bons recursos. Um nó completo de Bitcoin pode ser executado num Raspberry Pi que custa menos de 100 $. Um validador da Solana não pode. O resultado é a pressão de centralização: quanto mais elevado for o custo de participação, menor será o grupo de potenciais validadores e mais concentrado se torna o poder de consenso da rede entre operadores institucionais bem financiados.

A pressão de centralização é o enquadramento correto aqui, e não uma centralização consumada. A Solana tem mantido aproximadamente 1.500 a 2.000 validadores ativos, menos do que o conjunto de validadores da Ethereum de várias centenas de milhares, embora o limiar de hardware mais baixo da Ethereum envolva requisitos económicos diferentes (32 ETH necessários para staking). A Solana Foundation implementou programas de delegação de staking para apoiar validadores mais pequenos, mas o requisito de hardware subjacente impulsionado pelas exigências de processamento do PoH permanece estrutural, não incidental.

A compensação é deliberada: a arquitetura de Yakovenko prioriza a capacidade de processamento sobre a acessibilidade, aceitando a pressão de centralização como o custo do desempenho. Se essa compensação é aceitável depende do que o avaliador mais valoriza.

Interrupções da Rede: O Proof of History foi o Culpado?

O Proof of History em si não foi a causa das principais interrupções da rede Solana. As interrupções resultaram de inundações de transações de spam que sobrecarregaram a capacidade de computação da rede e de erros no software cliente dos validadores.

Os incidentes documentados são específicos. Em setembro de 2021, a rede Solana sofreu uma interrupção de 17 horas causada por um surto de transações geradas por Bot durante a oferta inicial DEX da Raydium. O volume de transações de spam sobrecarregou a memória dos validadores, fazendo com que estes falhassem e a rede parasse até que um reinício coordenado pudesse ser organizado. Ocorreram interrupções de rede adicionais em janeiro de 2022 e maio de 2022, cada uma atribuível a combinações de ataques de spam e erros de software dos validadores, e não a falhas no próprio mecanismo PoH.

A ligação arquitetural honesta é esta: o design da PoH prioriza o rendimento (throughput) em detrimento de uma gestão de recursos conservadora, o que significava que a rede não tinha limitação de taxa integrada ou prevenção de spam baseada em taxas na altura dessas interrupções. Uma rede concebida para 65.000 TPS deve processar 65.000 TPS de tráfego de entrada, incluindo tráfego malicioso. Arquiteturas mais conservadoras, ao estrangularem o rendimento, também estrangulam a superfície de ataque.

Após 2022, a Solana implementou várias respostas de engenharia: o protocolo de rede QUIC para uma ingestão de transações mais resiliente, mercados de taxas de transação para tornar o spam economicamente dispendioso e qualidade de serviço ponderada pelo stake para priorizar transações de validadores com stake significativo. Estas medidas melhoraram consideravelmente a estabilidade da rede.

O histórico de interrupções reflete a imaturidade da engenharia num sistema de alto desempenho, e não uma falha no próprio conceito de Proof of History, embora os dois estejam ligados arquiteturalmente. Os investidores e programadores que avaliam a Solana devem compreender esta distinção com precisão.

Dependências de Sincronização de Relógio

A cadeia de hash sequencial da PoH depende de os validadores manterem relógios locais suficientemente precisos. Um desvio significativo do relógio (clock drift) entre validadores pode criar inconsistências no tempo das slots, onde os validadores discordam sobre a que slot pertence uma determinada saída de hash.

Na prática, isto é gerido através da sincronização padrão NTP (Network Time Protocol), e o desvio do relógio não tem sido uma fonte significativa de falhas no mundo real. Representa, no entanto, uma superfície de ataque teórica: um atacante sofisticado que pudesse manipular os sinais de tempo que chegam a um número significativo de validadores poderia potencialmente perturbar a atribuição de slots. Isto é reconhecido como uma consideração de design, em vez de uma vulnerabilidade crítica no modelo de ameaça atual.

Perguntas Frequentes Sobre a Solana Proof of History

As respostas seguintes abordam as perguntas mais comuns sobre a Proof of History, extraídas de padrões de pesquisa que refletem o que investidores, programadores, investigadores e céticos perguntam com mais frequência.

Qual é o objetivo da Proof of History na Solana?

A Proof of History cria um registo de tempo criptográfico que permite aos validadores da Solana concordar com a ordem e o tempo das transações sem trocarem mensagens de marcação temporal entre si. Ao resolver a questão de "quando é que isto aconteceu" criptograficamente, a PoH liberta o Tower BFT para se concentrar exclusivamente na questão de "isto é válido", reduzindo a sobrecarga do consenso e permitindo o elevado rendimento de transações da Solana.

A Proof of History é o mesmo que Proof of Stake?

Não. A Proof of History é um mecanismo de marcação de tempo; a Proof of Stake é um mecanismo de consenso para selecionar quais os validadores que propõem blocos. Resolvem problemas diferentes. A Solana utiliza ambos simultaneamente: a PoH fornece a sequência de tempo verificável que ordena as transações, enquanto um sistema baseado em PoS determina qual o validador que produz o fluxo de PoH para cada slot. Confundir os dois é comum em coberturas de menor qualidade sobre a Solana, mas são componentes arquiteturalmente distintos.

Anatoly Yakovenko, cofundador e CEO da Solana Labs, introduziu a Proof of History num Whitepaper de 2017 intitulado Solana: A new architecture for a high performance blockchain. Antes de fundar a Solana Labs, Yakovenko foi engenheiro de equipa sénior na Qualcomm, onde trabalhou em sistemas operativos distribuídos e algoritmos de compressão. A Mainnet beta da Solana foi lançada em março de 2020.

O rendimento teórico da Solana é um valor teórico histórico de aproximadamente 65.000 transações por segundo em condições ideais; o rendimento observado no mundo real varia tipicamente entre 2.000 e 4.000 TPS. A camada base da Ethereum processa aproximadamente 15 a 30 TPS, com soluções de Camada 2 a prolongarem significativamente o rendimento efetivo. A vantagem de velocidade da camada base da Solana é estrutural, impulsionada pela ordenação temporal da PoH que permite a execução paralela e a redução da sobrecarga de consenso.

As três limitações primárias documentadas são: requisitos elevados de hardware para validadores (128GB+ RAM, SSDs NVMe, rede multi-gigabit, custo de hardware de 5.000 a mais de 20.000 dólares) que criam pressão de centralização ao excluir participantes com menos recursos; problemas históricos de fiabilidade da rede, incluindo a interrupção de 17 horas em setembro de 2021 e múltiplas paragens da rede em 2022 causadas por ataques de spam e erros no cliente do validador; e a dependência da sincronização do relógio, onde um desvio significativo do relógio do validador representa uma superfície de ataque teórica gerida na prática através da sincronização NTP.

O máximo teórico da Solana é um valor teórico histórico de aproximadamente 65.000 transações por segundo, conforme descrito no Whitepaper de 2017 de Yakovenko. Este valor representa todas as inovações arquiteturais da Solana a operar na sua capacidade máxima sob condições de rede ideais. O rendimento observado no mundo real sob condições típicas de rede ativa varia entre aproximadamente 2.000 e 4.000 TPS. O teto teórico reflete o design arquitetural; o valor do mundo real reflete o desempenho em produção.

O Tower BFT é o mecanismo de votação ponderada por stake e de escolha de Fork da Solana, construído em torno de slots de PoH. Os validadores votam com bloqueios (lockouts) crescentes, tornando as votações conflituantes dispendiosas. Não equipare uma slot de destino com a finalidade total; verifique os níveis de compromisso atuais e os requisitos da aplicação.

O mecanismo criptográfico em si, a cadeia de hash sequencial SHA-256, é seguro. O SHA-256 nunca foi quebrado com sucesso em ambientes de produção e é considerado criptograficamente robusto pela comunidade de segurança. A fiabilidade ao nível da rede, incluindo as interrupções de 2021 e 2022, é uma preocupação distinta da segurança criptográfica. A cadeia de hash da PoH não foi comprometida durante nenhuma das interrupções de rede da Solana; esses eventos foram causados por exaustão de recursos e erros de software, e não por qualquer falha do protocolo criptográfico.

Sem a PoH, os validadores da Solana precisariam de trocar mensagens de marcação temporal antes de cada ronda de consenso para estabelecer a ordem das transações, conforme exigido pelos sistemas de consenso BFT tradicionais. Esta sobrecarga de passagem de mensagens cresce com o número de validadores e limita o rendimento. A PoH substitui essa comunicação por uma prova criptográfica: a própria cadeia de hash demonstra a ordem e o tempo dos eventos, para que os validadores possam avançar diretamente para a votação da validade da transação, em vez de negociarem primeiro o tempo.

Não. O hashing SHA-256 sequencial da PoH é executado num único validador líder designado para cada slot, e não num campo de mineiros concorrentes. Não é intensivo em energia da mesma forma que a mineração Proof of Work da Bitcoin, onde cada mineiro gasta simultaneamente poder de computação a competir para encontrar um hash válido. O consumo total de energia da Solana é uma fração do da Bitcoin. O custo de hardware associado aos validadores da Solana é uma preocupação financeira e de descentralização, mas é distinto da questão do consumo de energia.

A Solana é, por si só, uma blockchain de Camada 1. Não corre em cima de outra rede da mesma forma que as soluções de Camada 2 da Ethereum. A Solana opera a sua própria blockchain independente utilizando Proof of History para a ordenação temporal das transações e Tower BFT para o consenso, com o SOL como o seu token nativo.

O código da Solana é de código aberto (open source), tornando o mecanismo PoH disponível para outros projetos estudarem e adaptarem. Na prática, a PoH está profundamente integrada na arquitetura completa da Solana. O Tower BFT, o Sealevel e o Gulf Stream dependem todos da sequência PoH. Extrair e aplicar a PoH a uma blockchain diferente exigiria a reprodução de grande parte da estrutura circundante da Solana para alcançar os mesmos benefícios de desempenho.

Explore SOL em Bybit

Os leitores podem rever informações atuais do mercado SOL) ou o mercado spot SOL/USDT.). Estes links fornecem acesso ao mercado e não provam que a Solana, uma carteira, ou um protocolo de terceiros seja adequado para todos os leitores.

Conclusão: É a Prova de História uma Inovação Genuína?

A Prova de História é uma inovação criptográfica genuína. O mecanismo de cadeia de hashes SHA-256 resolve um problema real em sistemas distribuídos: provar a passagem do tempo sem confiar num único relógio, de uma forma que é verificável por qualquer observador sem exigir a reexecução de todo o cálculo.

As implicações de desempenho são reais. A vantagem de throughput da camada base da Solana sobre outras blockchains de Camada 1 importantes é estrutural, não incidental, e a PoH é o mecanismo fundamental que a torna possível. Os investidores que avaliam se essa vantagem é durável devem ponderá-la contra as contrapartidas documentadas: requisitos de hardware de validador que criam pressão de centralização, um histórico de fiabilidade da rede que inclui falhas sérias, e um design otimizado para desempenho que prioriza o throughput sobre a resiliência conservadora.

Essas contrapartidas são desafios de engenharia, não falhas fundamentais no design criptográfico. A implementação pós-2022 do QUIC, mercados de taxas e qualidade de serviço ponderada por stake demonstra que a equipa de engenharia da Solana abordou as falhas de fiabilidade mais agudas. Se a maturação adicional trará o perfil de fiabilidade de acordo com a promessa de throughput é uma questão que o histórico operacional contínuo da rede responderá.

Um leitor que tenha trabalhado através deste artigo pode agora definir Prova de História com precisão e explicar como a cadeia de hashes SHA-256 produz um registo de tempo verificável. Eles podem distinguir PoH de mecanismos de consenso como Prova de Participação, articular porque PoH permite a vantagem de throughput da Solana, e avaliar as limitações documentadas com o contexto apropriado. Essa é a imagem técnica necessária para avaliar a arquitetura da Solana pelos seus méritos.

As informações neste artigo refletem documentação técnica publicamente disponível e estão atualizadas à data de publicação. Os protocolos Blockchain e as métricas de desempenho da rede mudam com o tempo. Este conteúdo não é afiliado nem patrocinado pela Solana Labs ou pela Solana Foundation.

Leitura Relacionada

• Mecanismo de consenso Solana
• Arquitetura Solana
• Velocidade Solana: TPS Real vs. Teoria