Cofundador da Solana: Construindo uma máquina estatal global e analisando a arquitetura definitiva de Solana

**Palavras: Anatoly Yakovenko, CEO (Cofundador ou CEO), Solana

Compilador: 1912212.eth, Foresight News

O objetivo de Solana é sincronizar uma única máquina de estado global sem permissão o mais rápido possível, em conformidade com as leis da física. Acredito que a arquitetura que será capaz de alcançar isso será assim:

• Grande número de nós completos, mais de 10.000 (N > 10.000)

Para que a rede funcione como uma máquina de estado global, ela precisa suportar vários nós completos. A Turbine provou que a replicação rápida para redes muito grandes é escalável em hardware e redes modernas.

• Grande número de líderes de geração de blocos, mais de 10.000 (N > 10.000)
• Líderes concorrentes produzem blocos ao mesmo tempo, selecionados aleatoriamente na faixa de 4 a 16.

O Concurrency Leader permite que a rede tenha vários locais em todo o mundo para ordenar as transações dos usuários. Ele reduz a distância entre os usuários e a rede, eliminando a necessidade de verificação completa do nó antes que as transações sejam adicionadas à cadeia.

• O tempo de bloqueio é de 120 milissegundos

Tempos de bloqueio curtos criam pontos de finalização rápidos, aumentam a resistência à censura, melhoram a experiência do usuário, reduzem as janelas para reordenar transações e aceleram a rede em geral.

• Alguns dos nós de consenso de votação no subcomitê de aprovação, com um número entre 200 e 400, são selecionados aleatoriamente e rotativos a cada 4 a 8 horas por época.

O consenso é essencial para a escolha de uma bifurcação, o que ocorre devido ao particionamento da rede. Uma amostra de 200 ou mais nós será estatisticamente representativa de todas as principais partições na rede e corresponderá à sua distribuição real. Portanto, todos os votos completos do nó não são necessários, 200 é suficiente. Limite a aprovação a subcomitês para reduzir a memória e a largura de banda de rede necessárias para suportar blocos de 120 ms. A redução do tempo de bloqueio aumenta naturalmente o número de votos enviados por segundo, colocando alguma pressão sobre os recursos alocados para o consenso.

O verdadeiro desafio no bloco de 120ms é reproduzir todas as transações do usuário. Como a rede não tem permissão, é extremamente difícil garantir um ambiente de execução homogêneo com um tempo confiável para executar código de usuário arbitrário. Embora haja uma possibilidade, ela só pode ser alcançada limitando os recursos de computação disponíveis para transações do usuário e garantindo que cada nó seja superalocado para o pior cenário.

No entanto, não há razão para impor um estado completo para nós de consenso que votam em uma bifurcação ou um líder que constrói em uma bifurcação. Para manter as aprovações de nós de consenso e líderes em sincronia, o estado só precisa ser calculado uma vez por período.

Execução assíncrona

Motivação

A execução síncrona requer que todos os nós que votam e criam blocos sejam superconfigurados em qualquer bloco para determinar o pior tempo de execução possível. A execução assíncrona é um dos poucos casos em que há poucas compensações. Os nós de consenso podem realizar menos trabalho antes da votação. O trabalho pode ser agregado e agrupado, tornando-o eficiente na execução sem qualquer perda de cache. Ele pode até ser executado em uma máquina completamente diferente do nó de consenso ou líder. Os usuários que desejam a execução síncrona podem alocar recursos de hardware suficientes para executar cada transição de estado em tempo real sem ter que esperar por toda a rede.

Dada a diversidade de aplicativos e desenvolvedores principais, vale a pena planejar uma grande mudança de protocolo a cada ano. Se eu tivesse que escolher um, minha escolha seria executar de forma assíncrona.

VISÃO GERAL

Atualmente, os validadores repetem rapidamente todas as transações em cada bloco e votam somente após o estado completo ter sido calculado para o bloco. O objetivo desta proposta é separar as decisões de voto sobre bifurcações do cálculo das transições estaduais completas dos blocos.

Os validadores que votam na aprovação só precisam selecionar a bifurcação, não precisam executar nenhum estado. Apenas em cada época eles precisam do status para calcular a próxima aprovação.

O processo de votação foi ajustado de modo a poder ser realizado de forma independente. Os nós executam procedimentos de votação somente antes da votação. Como os validadores não ocupam muito espaço, os requisitos de memória devem ser relativamente pequenos. Uma vez que a votação tem um tempo de execução muito previsível, deve haver pouco ou nenhum desvio na execução do processo de votação.

Todas as transações sem direito a voto podem ser calculadas de forma assíncrona. Isso permite que o replay execute todas as transações sem direito a voto em lotes, pré-busca e JIT todos os programas com antecedência, praticamente eliminando todas as perdas de cache. O objetivo a longo prazo é que apenas máquinas que exijam cálculos em tempo real, de baixa latência e estado total sejam configuradas para essa tarefa. Presumivelmente, os usuários pagarão pelo hardware adicional.

Uma vez que a seleção da bifurcação e a execução do estado são separadas, torna-se mais fácil acelerar as coisas:

• Execução assíncrona
• Cada época rotativa um número fixo de comissões de votação
• Tempo de bloqueio de 200 ms

Como a repetição da transação do usuário não bloqueia a seleção da bifurcação, a volatilidade não é mais um problema ao subtrair o tempo de bloqueio. A única coisa a considerar é que, em 200 milissegundos, a taxa de votação do validador dobra. Fazer uma alteração bastante simples na forma como a quota é calculada para as aprovações permitir-nos-á fixar o tamanho da aprovação em 200 ou 400, ou qualquer número que pareça adequado.

É também natural separar completamente a implementação do consenso. Será mais rápido reiniciar o nó de consenso que só precisa verificar a conta do programa de votação na aprovação de tamanho fixo.

Na verdade, acredito que o tempo de confirmação aumentará porque a grande maioria das aprovações é votada o mais rápido possível e, enquanto esses votos são propagados, os nós que fornecem aos usuários resultados completos de execução de estado podem executar transações ao mesmo tempo. Portanto, qualquer desvio de repetição que vemos hoje deve ocorrer ao mesmo tempo que a propagação da rede de votação.

Votação

• As contas de voto devem ter um número suficiente de SOL para cobrir os votos de 2 épocas.
• As transações de votação devem ser simples. Uma votação não simples está fadada ao fracasso. Os geradores de blocos devem desistir de votações complexas.
• É permitido retirar o SOL das contas de voto, desde que o saldo não caia para menos de 1 época de votos.
• A fim de zerar todos os lamports, a diretiva Vote CLOSE deve exigir que toda a época decorra. As contas de votação são marcadas como FECHADAS na Era 1, mas só podem ser FECHADAS na Era 2. CLOSE permite-lhe levantar todo o SOL e eliminar contas de voto. Uma vez que uma conta é marcada como FECHAR, ela só pode ser completamente excluída e não pode ser reaberta.
• Os votos contêm um VoteBankHash em vez de um BankHash normal.

Regulamentação e aprovação do líder

Apenas os validadores cumprem os seguintes critérios:

• Valor da aposta > X
• Assim como o SOL > 2 épocas de votação
• e não está marcado como FECHAR

para entrar na agenda do líder e contar para a aprovação. Para a versão 2, podemos separar o LeaderSchedule do Quórum, e eles não precisam ter os mesmos requisitos cada.

Cálculo VoteBankHash

Ao contrário do Bankhash, que calcula todas as transações, os validadores só calculam o VoteBankHash para transações de votação simples relacionadas aos validadores no LeaderScheduler. Todas as outras transações são ignoradas. Depois de reproduzir todos os votos, o VoteBankHash é calculado no mesmo formato que o BankHash atual.

O VoteBankHash deve acumular o VoteBankHash anterior, não o BankHash completo.

Cálculos BankHash

Para todos os blocos confirmados otimistas (configuráveis para todos os blocos), o validador começa a calcular o UserBankHash, que inclui todas as transições de estado, mas exclui as transações que foram consideradas no cálculo VoteBankHash.

O BankHash é então derivado do acúmulo de (VoteBankHash, UserBankHash). Os principais 99,5% dos validadores enviam o BankHash como parte de sua votação a cada 100 intervalos de tempo. Embora seja cometido a cada 100 faixas horárias, é calculado em cada intervalo de tempo. Vale a pena notar que pode valer a pena para uma pequena porcentagem de nós enviar consistentemente BankHash em fofocas como um sinal suave sem nenhum não-determinístico observado.

Se menos de 67% dos validadores enviarem cálculos completos do BankHash, os líderes devem reduzir o espaço de bloco disponível para transações de usuários e contas graváveis em 50%. Esta medida destina-se a proteger a cadeia de abusos que possam aumentar excessivamente o tempo de repetição.

BankHash deve acumular BankHashes anteriores.

Ir para o líder do banco

Durante a criação do bloco, é provável que o líder não consiga obter o estado usado para criar o bloco, e não é ideal executar todas as transações durante o período de criação do bloco.

• Os líderes mantêm um cache de saldos de contas pagas.
• Se uma conta paga for usada como fonte para transferências do sistema, ou como uma conta gravável passada junto com um programa do sistema para outro programa, o saldo da conta paga será definido como 0.
• Os blocos são embalados de acordo com as unidades de computação (UCs) declaradas em ordem de prioridade de taxa local até que os blocos sejam preenchidos.
• As taxas são deduzidas do cache de saldo da conta paga.
• O cache de saldo da conta paga é complementado pelos cálculos do BankHash.

A rede incorre em relativamente pouco custo para falhas de spam de transação, consistindo apenas nos bytes armazenados no arquivo e na largura de banda necessária para propagar as transações no bloco.

Dado que os validadores já estão procurando maximizar seus ganhos, eles têm amplos incentivos para manter um cache preciso de contas pagas. Além disso, se não houver nenhuma penalidade em vigor, qualquer pessoa em qualquer rede pode facilmente servir o cache a longo prazo. Em caso de corrupção do servidor, um operador líder sem banco deve ser capaz de alternar facilmente ou fazer amostras de várias fontes.

Isso significa que, devido à motivação dos validadores para maximizar os ganhos, eles se esforçarão para manter um cache preciso de contas pagas. Na ausência de um mecanismo de penalização, esse cache pode ser servido por qualquer nó na rede por um longo tempo. Além disso, se um servidor falhar, um operador sem um líder bancário deve ser capaz de mudar facilmente ou obter amostras de várias fontes.

Compensações

A principal compensação é a falta de uma assinatura de confirmação no nó completo que atende o estado do usuário para confirmar que seu status de entrega é exatamente o mesmo que o restante aprovado. A única explicação autorizada do estado deve permanecer a mesma, mesmo que cada transação seja repetida sequencialmente no livro-razão. Quaisquer otimizações de desempenho não devem alterar os resultados. Assim, uma vez que a bifurcação é finalizada, apenas o estado correto é deixado para calcular, desde que a implementação do tempo de execução esteja livre de erros.

Os nós projetados para fornecer estado de forma confiável devem executar várias máquinas e clientes e, se houver uma discrepância na execução do estado, eles devem parar de operar. Isto é essencialmente o que os operadores devem fazer hoje, porque confiar apenas no resto da rede introduz a maioria dos pressupostos de integridade.

Os usuários também podem assinar transações que afirmam um BankHash ou acionam um abortamento. O resto da rede executará essas transações somente se o BankHash exato calculado for exatamente o mesmo que o BankHash fornecido ao usuário pelo provedor RPC.

Roteiro do nó de consenso apátrida de longo prazo

Redes com aprovações de tamanho fixo exigem apenas uma quantidade muito pequena de estado para iniciar. A aprovação em si e o seu peso de penhor, bem como todos os saldos das contas de voto. Esta é uma quantidade muito pequena de memória e um pequeno arquivo instantâneo que pode ser rapidamente distribuído e inicializado rapidamente em uma reinicialização.

Se a aprovação for inconsistente com o nó completo, o nó completo que está rastreando a aprovação e o status deixará de ser executado. Isso significa que, se houver um desacordo entre a aprovação e o status, a troca, canal fiduciário, RPC, bridge, etc., deixarão de funcionar. Isto requer apenas uma percentagem muito pequena de nós de consenso apátridas defeituosos.

Os líderes sem banco podem contar com uma amostra de vários nós completos para fornecer um cache do saldo inicial de uma conta paga. Mesmo que seja falho, o resultado será spam no bloco em vez de falha de consenso. Os operadores devem ser capazes de monitorizar a saúde dos seus líderes e a percentagem de spam que injetam nos seus blocos, e responder rapidamente a falhas.