Origens: comprovação da história

Curiosidade

1. Como os nós distribuídos podem concordar sobre a ordem dos eventos sem sincronização constante?
2. Por que um agendador de líder determinístico permite a execução paralela de transações?
3. Qual é a relação entre os tempos de bloco de subsegundos e os requisitos de hardware do validador?

Explorar

1. Anatoly Yakovenko publicou o white paper do Solana em novembro de 2017, introduzindo o Proof of History (PoH). O PoH gera uma sequência de hashes SHA-256, cada um derivado do anterior. Esse processo criptográfico funciona como um relógio verificável. Os validadores o utilizam para estabelecer a ordem temporal sem precisar se comunicar entre si para cada transação. Esse mecanismo reduz a carga de comunicação em comparação com protocolos de consenso que dependem da latência de ida e volta para sincronização global.
2. A Solana combina PoH com votação por prova de stake por meio do Tower BFT. O beta da mainnet foi lançado em 16 de março de 2020. Os blocos são gerados em intervalos de aproximadamente 400 milissegundos por um líder agendado. O cronograma determinístico permite que os validadores saibam exatamente quando eles gerarão um bloco. As transações podem ser encaminhadas com antecedência aos próximos líderes, contornando assim o mempool global. A finalidade total é alcançada em aproximadamente 32 intervalos, ou cerca de 13 segundos.
3. O Turbine lida com a propagação de blocos fragmentando-os em pequenos pedaços distribuídos na rede de forma paralela, utilizando uma estrutura em árvore. Se a propagação atrasar, a taxa de transferência cai significativamente. O Gulf Stream resolve o congestionamento do mempool encaminhando transações diretamente para os próximos líderes antes que elas sejam incluídas em um bloco. Isso garante que os validadores recebam os dados das transações o mais rápido possível, reduzindo a latência e evitando gargalos durante períodos de alto volume.
4. O Sealevel permite a execução paralela de contratos inteligentes, pois as transações declaram suas dependências de conta com antecedência. Se duas transações não compartilharem dependências de conta, o Sealevel as executa simultaneamente em vários núcleos de CPU. Isso contrasta com os modelos de execução sequencial, nos quais cada transação espera que a anterior seja concluída, independentemente da independência lógica. A arquitetura visa milhares de transações por segundo, maximizando a utilização do hardware.
5. O trade-off é a necessidade de hardware de validação robusto. Um alto volume de transações requer poder de processamento significativo e largura de banda de rede para manter os horários dos slots. Um segundo cliente independente, o Firedancer da Jump Crypto, foi lançado na mainnet primeiro em uma forma híbrida (“Frankendancer”) a partir de setembro de 2024, e como um cliente totalmente independente a partir de dezembro de 2025. Isso aumenta a diversidade de clientes na rede, reduzindo a dependência de um único código-fonte para a lógica de consenso e execução.
6. Para verificar essa arquitetura, abra um explorador de blocos da Solana. Selecione qualquer slot recente. Observe a lista de transações incluídas. Note que o bloco foi produzido por um validador específico identificado nos metadados do slot. Verifique quantas transações ele contém e o tempo entre slots consecutivos, que geralmente é de cerca de 400 milissegundos, embora alguns slots sejam pulados quando um líder não consegue produzir um bloco.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• A. Yakovenko, 'Solana: A new architecture for a high performance blockchain' (2017)
• Solana Foundation, Solana Documentation: Proof of History
• Solana Foundation, Solana Documentation: Turbine and Gulf Stream
• Jump Crypto, Firedancer Technical Overview