Como funciona o protocolo Proof of History da Solana

Um dos problemas mais difíceis em sistemas distribuídos é a concordância no prazo. O Spanner do Google usa relógios atômicos sincronizados entre seus datacenters. Os engenheiros do Google sincronizam esses relógios com uma precisão muito alta e os mantêm constantemente.

Esse problema é ainda mais difícil em sistemas contraditórios como o blockchain. Os nós na rede não podem confiar em uma fonte externa de tempo ou qualquer momento que apareça em uma mensagem. O Hashgraph, por exemplo, resolve esse problema , ou seja, cada mensagem que é vista pela rede é assinada e cronometrada pela rede. Cada mensagem deve viajar para a supermaioria dos nós do sistema, então, depois que a mensagem coleta assinaturas suficientes, todo o conjunto precisa ser propagado para toda a rede. Como você pode imaginar, isso é muito lento.

E se você pudesse simplesmente confiar no código codificado na mensagem? Uma enorme riqueza de otimizações de sistemas distribuídos de repente estaria à sua disposição:

Proof of History

E se ao invés de confiar no horário, por exemplo, você pudesse provar que a mensagem ocorreu algum tempo antes e depois de um evento? Quando você tira uma foto com a capa do New York Times, você está criando uma prova de que sua foto foi tirada depois que o jornal foi publicado, ou você tem alguma maneira de influenciar o que o New York Times publica. Com o proof of history, você pode criar um registro histórico que provas que um evento ocorreu em um momento específico no tempo.

A prova da história é uma função de atraso verificável. Nossa implementação específica usa um hash resistente à pré-imagem sequencial que é executado continuamente com a saída anterior usada como a próxima entrada. Periodicamente, a contagem e a saída atual são registradas.

Para uma função de hash SHA256, esse processo é impossível de ser paralelo sem um ataque de força bruta usando núcleos ⁸ 2¹².

Podemos então ter certeza de que o tempo real passou entre cada contador como foi gerado, e que a ordem gravada de cada contador é a mesma que era em tempo real.

Limite superior no tempo

Os dados podem ser inseridos na sequência, anexando os dados ao estado gerado anteriormente. Os estados, os dados de entrada e a contagem são todos publicados. Anexar a entrada faz com que todas as saídas futuras sejam alteradas de maneira imprevisível. Ainda é impossível fazer a paralelo, e enquanto a função hash for resistente à pré-imagem e à colisão, é impossível criar uma entrada que geraria um hash desejado no futuro, ou criar uma história alternativa com os mesmos hashes. Podemos provar que o tempo passou entre as duas operações de acréscimo. Podemos provar que os dados foram criados algum tempo antes de ser anexado. Assim como sabemos que os eventos publicados no New York Times ocorreram antes do jornal ser escrito.

Limite inferior no tempo

As entradas no Proof of History podem ter referências à própria Prova de História. A referência anterior pode ser inserida como parte de uma mensagem assinada com a assinatura do usuário, de modo que não pode ser modificada sem a chave privada dos usuários. É como tirar uma foto com o jornal New York Times ao fundo. Como esta mensagem contém o hash 0xdeadc0de, sabemos que ela foi gerada depois que a contagem 510144806912 foi criada.

Mas, como a mensagem também é inserida de volta no fluxo do Proof of History é como se você tirasse uma foto com o New York Times ao fundo e, no dia seguinte, o New York Times publicasse essa foto. Sabemos que o conteúdo dessa foto existia antes e depois de um dia específico.

Verificação

Embora a sequência gravada só possa ser gerada em um único núcleo de CPU, a saída pode ser verificada em paralelo.

Cada parte gravada pode ser verificada do início ao fim em núcleos separados em 1/(número de núcleos) de tempo que levou para gerar. Portanto, uma GPU moderna com 4000 núcleos pode verificar um segundo em 0,25 milissegundos.

ASICS

Este tópico merece seu próprio artigo, mas resumindo a história é que não nos importamos muito se algumas CPUs são mais rápidas do que outras e se um ASIC pode ser mais rápido do que as CPUs disponíveis para a rede. O mais importante é que há um limite finito de quão mais rápido um ASIC pode se tornar.

Estamos usando SHA256 e, graças ao Bitcoin, houve uma pesquisa significativa para tornar esse hash criptográfico rápido. É impossível acelerar esta função usando uma área de dado maior, como uma Tabela de pesquisa, ou desenrolando-a sem impacto na velocidade do clock. Tanto a Intel quanto a AMD estão lançando chips para consumidores que podem fazer uma rodada completa de SHA256 em 1,75 ciclos.

Por causa disso, temos muita certeza de que um ASIC personalizado não será 100x mais rápido, muito menos 1000x, e a maioria das semelhanças estará dentro de 30% do que está disponível para a rede. Podemos construir protocolos que explorem esse limite e só permitem a um invasor uma oportunidade muito limitada, facilmente detectável e de curta duração para um ataque de negação de serviço.

Fonte: solana.com

Isenção de responsabilidade. A Universidade do Bitcoin não endossa nenhum conteúdo nesta página. Embora tenhamos como objetivo fornecer a você informações importantes do mundo das criptomoedas, os leitores devem fazer sua própria pesquisa e análise antes de tomarem quaisquer decisões e assumir total responsabilidade por elas, nem este artigo pode ser considerado como um conselho de investimento.