Execução assíncrona de programas: o alvorecer de uma nova APE-oca da Solana

Introdução

Em meio aos debates acalorados e às palestras repletas de anúncios da movimentada conferência Breakpoint deste ano, o cofundador da Solana, Anatoly Yakovenko, reservou um tempo para um único workshop técnico, improvisado e não gravado. Munido de um flip chart e marcadores, ele explorou os detalhes de um tema que defende com entusiasmo como a próxima evolução da Solana e que é o foco deste artigo: a execução assíncrona.

Como ponto de partida para abordar a visão ambiciosa da execução assíncrona (abreviada como AE daqui em diante), iniciaremos nosso percurso com uma explicação geral dos principais conceitos e objetivos da AE. Em seguida, examinaremos os mecanismos atuais de execução e consenso da Solana para estabelecer uma base para a análise comparativa das futuras arquiteturas propostas. Depois, exploraremos as diversas propostas relacionadas à AE, começando pelos líderes sem banco, que são uma etapa necessária para essa transição. Também analisaremos as primeiras propostas de design, de 2022, e avançaremos em ordem cronológica até as propostas mais recentes de "arquitetura final", que vão além da AE e incluem implementações de design para vários produtores de blocos simultâneos.

AE: visão geral de alto nível

No contexto do protocolo principal da Solana, AE se refere à abordagem arquitetônica de separar a execução do consenso para que possam operar de forma independente. A rede faz isso chegando a um consenso sobre a ordem das transações sem de fato executá-las. Depois que a ordem é acordada, qualquer pessoa pode executar as transações para revelar a verdade.

Nessa abordagem, os líderes criariam blocos sem executar as transações que não são de voto e os propagariam pela rede via Turbine. Os validadores também podem votar nos blocos sem executar transações que não são de voto. O consenso fica limitado apenas à ordem e à disponibilidade das transações, reduzindo significativamente o tempo e as etapas necessários para alcançá-lo. Parafraseando um resumo de Jon Charbonneau, da DBA: a ordenação determina a verdade, e a execução a revela.

Essa abordagem é muito diferente do funcionamento atual do consenso, no qual os líderes executam as transações antes de incluí-las em blocos, e todos os validadores reproduzem as transações de um bloco antes de votar nele.

A AE é possível porque:

1. A escolha da bifurcação não depende da execução de programas
2. Só é possível calcular um estado correto, dada uma função determinística de transição de estado. No fim, todos calcularão o mesmo estado final
3. Transações inválidas podem ser descartadas. O custo para a rede do spam de transações com falha é relativamente baixo e consiste na largura de banda do Turbine necessária para propagar as transações e no armazenamento adicional delas no ledger
4. Máquinas que exigem o cálculo do estado completo em tempo real e com baixa latência, como as operadas por provedores dedicados de serviços RPC, podem ser provisionadas especificamente para essa finalidade

A AE oferece muitas vantagens em potencial.

Yakovenko chega a afirmar: “A execução assíncrona é um dos raros casos em que praticamente não há contrapartidas.”

1. Tempos de bloco menores (200 milissegundos)
2. Tempos de bloco mais confiáveis
3. Requisitos menores para validadores
4. Melhor experiência do usuário (finalidade mais rápida)
5. Maior resistência à censura
6. Janela menor para reordenar transações
7. Transferência da capacidade não utilizada entre blocos
8. Criação de um caminho para vários produtores de blocos simultâneos (falaremos mais sobre isso adiante)

Ao longo deste artigo, veremos exatamente como a AE proporciona essas vantagens.

Outra forma de entender a AE é que ela permite que o programa de votação opere de forma independente de todos os outros programas. O programa de votação e o programa do sistema (que é sempre necessário) são os únicos programas necessários para o consenso dentro de uma época.

As discussões sobre AE na Solana vêm ocorrendo há vários anos. A proposta formal inicial de Anatoly Yakovenko, originalmente intitulada APEX (execução assíncrona de programas), remonta a abril de 2022. Os detalhes concretos de como a AE pode ser implementada na prática na Solana estão distribuídos por vários SIMDs e artigos, todos abordados aqui em uma ordem predominantemente cronológica. Yakovenko é, sem dúvida, o principal defensor público da AE na comunidade Solana e raramente perde a oportunidade de abordar o tema em entrevistas e participações em podcasts.

Terminologia

É útil definir brevemente dois termos importantes que terão destaque em nossa discussão sobre AE: líderes sem banco e vários produtores de blocos simultâneos (MCBP). Em resumo:

• Líder sem banco: um líder capaz de criar blocos sem executar transações
• Execução assíncrona (AE): separação completa entre consenso e execução
• Vários produtores de blocos simultâneos (MCBP): como o nome sugere, vários blocos produzidos simultaneamente no mesmo slot‍

Os líderes sem banco são uma etapa necessária para viabilizar a AE completa. Da mesma forma, a implementação bem-sucedida da AE é essencial para a introdução posterior de vários produtores de blocos simultâneos (MCBP), também chamados de vários líderes simultâneos (MCL). A discussão sobre AE costuma aparecer junto à discussão sobre MCBP. Yakovenko defende ambos como partes fundamentais da “arquitetura final” da Solana.

A Solana não é a única blockchain que investiga esses aprimoramentos arquitetônicos. A Monad planeja implementar a AE desacoplando consenso e execução em threads distintas. Da mesma forma, a comunidade de pesquisa da Ethereum vem explorando há algum tempo a possibilidade de introduzir vários proponentes simultâneos.

As propostas de Yakovenko ainda são objeto de debate na comunidade, pois sua implementação exigiria mudanças significativas no protocolo principal da Solana. Nem todos concordam que a AE seja o melhor caminho. Não é exagero dizer que a implementação completa da arquitetura final proposta por Yakovenko transformaria radicalmente as operações da Solana e aumentaria a complexidade geral do protocolo.

Antes de passarmos para uma análise mais detalhada da AE, precisamos recapitular como a execução e o consenso funcionam atualmente na Solana, com atenção especial aos aspectos mencionados mais adiante neste artigo. Também analisaremos dados sobre transações de voto e que não são de voto para descobrir insights adicionais que embasarão a discussão posterior. Leitores que já conhecem bem essas funções e têm segurança sobre seu funcionamento podem pular a próxima seção.

Execução síncrona (a Solana hoje)

Execução

A Solana usa a construção contínua de blocos, que envolve montar e transmitir blocos dinamicamente à medida que são criados durante um slot alocado de 400 milissegundos. Os líderes recebem quatro slots consecutivos (1,6 segundo) antes da rotação. Para que um bloco seja aceito pela rede, o líder deve verificar e executar cada transação dentro dele. Além disso, todos os outros validadores ativos que participam do consenso verificam e executam novamente todas as transações do bloco.

Um líder recebe pacotes de transações pelo Gulfstream, via QUIC, que entram na Unidade de Processamento de Transações (TPU), a lógica central do líder responsável pela produção de blocos. Há três portas abertas pelas quais a TPU recebe pacotes:

• tpu: processa transações comuns, como transferências de tokens, emissão de NFT e instruções de programas
• tpu_vote: processa exclusivamente transações de voto
• tpu_forwards: se o líder atual não conseguir processar todas as transações, encaminha os pacotes não processados ao próximo líder por essa porta‍

Antes que qualquer forma de ordenação ou execução possa começar, todos os pacotes de transações passam por rigorosas validações e verificações de integridade, incluindo a verificação de assinaturas, a conferência da quantidade correta de assinaturas e a eliminação de transações duplicadas. Vale observar que as transações de voto e as que não são de voto têm processos separados de verificação de assinatura.

A construção de blocos acontece no estágio bancário. Um banco representa o estado em um determinado bloco. As transações são processadas em paralelo e agrupadas em entradas do ledger — lotes de 64 transações sem conflito. Todas as transações incluem uma lista completa das contas que serão lidas e gravadas. Esse design permite que os validadores selecionem facilmente apenas transações sem conflito para execução em cada entrada. Há conflito entre transações quando elas gravam na mesma conta (duas gravações) ou leem e gravam na mesma conta (leitura + gravação). Transações conflitantes são colocadas em entradas diferentes e executadas sequencialmente, enquanto transações sem conflito são executadas em paralelo.

Seis threads processam transações em paralelo: quatro são dedicadas às transações que não são de voto e duas processam exclusivamente transações de voto. Os votos de consenso são tratados como transações privilegiadas no estágio bancário: têm preço uniforme de 0,000005 SOL, consomem 2.100 unidades de computação (CUs) e são executados pelo programa de votação. 

Depois que as transações são agrupadas em entradas, elas são executadas pela Solana Virtual Machine (SVM). As contas necessárias para a transação são bloqueadas; as verificações confirmam que a transação é recente, mas ainda não foi processada. As contas são carregadas, e a lógica da transação é executada, atualizando seus estados. Um hash da entrada é enviado ao serviço de Proof of History (PoH) para ser registrado. Quando a operação é bem-sucedida, todas as alterações são confirmadas no banco e os bloqueios de cada conta são liberados.

O protocolo não determina a ordem das transações válidas dentro de um bloco. O estado final da cadeia é o resultado de todas as transações confirmadas. Esse estado sempre pode ser recriado de forma determinística a partir do histórico da blockchain (ou seja, reproduzindo o ledger desde o bloco Genesis ou de um snapshot).

Cada banco tem um BankHash correspondente, um hash SHA256 dos seguintes elementos:

• BankHash pai — o BankHash do bloco pai imediato
• DeltaHash de contas — uma árvore de Merkle de base 16 raiz da árvore de Merkle de todas as contas que passaram por mudanças de estado no bloco atual
• Contagem de assinaturas — o número total de assinaturas de transações no bloco atual
• Último blockhash

hashv(&[
	parent_bankhash,
	accounts_delta_hash,
	num_sigs,
	blockhash,
])

O BankHash é o compromisso criptográfico no qual os validadores votam para cada slot.

Consenso

Os validadores precisam de três contas para viabilizar o processo de votação:

Conta de identidade

Essa conta do sistema é a signatária e pagadora de taxas de todas as transações de voto — um par de chaves ativo armazenado diretamente no hardware do servidor. Como o nome sugere, a chave pública dessa conta funciona como a identidade do validador na rede. A conta de identidade é necessária para criar uma conta de voto.

Conta de voto

Essa é a conta para a qual os delegadores delegam seus SOL. O endereço é usado para consultar a conta, não para assinar transações.

Conta de retirada

Essa conta é usada para retirar fundos da conta de voto. Ela pode alterar a conta de identidade. A chave privada dessa conta geralmente é armazenada em uma carteira multifirma segura ou cold wallet e deve ser diferente dos pares de chaves da identidade do validador e da autoridade de voto.

Cada voto (exemplo) assinado pelo validador inclui sua chave pública e um hash que identifica o bloco em que ele está votando. Quando os validadores enviam votos corretos e bem-sucedidos, recebem créditos.

A rede não espera que todos os validadores concordem com um bloco recém-produzido antes de produzir o próximo. Por isso, não é incomum que dois blocos diferentes sejam vinculados ao mesmo bloco pai, criando bifurcações. Os validadores precisam votar nessas bifurcações e usar o Tower BFT, uma variante do Practical Byzantine Fault Tolerance (pBFT) original, para decidir qual adotar. 

Quando há bifurcações concorrentes, a rede finaliza apenas uma, e os validadores abandonam os blocos das bifurcações descartadas. Cada slot tem um líder predeterminado, e somente o bloco desse líder será aceito; não pode haver dois blocos propostos para um único slot. Portanto, o número de bifurcações possíveis fica limitado a uma lista de bifurcações do tipo "presente/ausente", que podem surgir nos limites dos slots de rotação de líderes. 

Depois que um validador escolhe uma bifurcação, ele fica comprometido com ela até que um período de bloqueio expire, ou seja, precisa manter sua escolha por um período mínimo. Esse mecanismo incentiva os validadores a votar com cuidado na bifurcação que acreditam ter maior chance de ser incluída, isto é, a bifurcação “mais pesada”.

Um bloco é considerado otimisticamente confirmado quando uma supermaioria de dois terços vota nele. Ele é considerado finalizado depois que 31 blocos são construídos sobre ele. Nunca houve, na história da Solana, um caso em que um bloco otimisticamente confirmado não tenha sido finalizado.

Quando uma bifurcação é finalizada, o bloco se torna enraizado com as atualizações de contas do banco, e seus ancestrais são gravados em disco. Além disso, todas as atualizações de contas de bancos anteriores que não sejam ancestrais do banco finalizado são removidas.

Transações de voto e que não são de voto

Como vimos na Solana, os processos de execução de transações e obtenção de consenso via Tower BFT estão intimamente ligados. As transações de voto e as que não são de voto seguem o mesmo caminho: são agrupadas em entradas, executadas pela SVM, registradas no fluxo de Proof of History (PoH) e distribuídas à rede via Turbine. Esse processo unificado garante consistência na maneira como os validadores enxergam o estado do consenso, pois propagar votos apenas pelo serviço de gossip poderia gerar discrepâncias entre os validadores. Essas discrepâncias poderiam fazer com que eles tivessem perspectivas diferentes sobre qual bifurcação tem maior probabilidade de estar correta. A construção contínua de blocos exige votação contínua, sobretudo enquanto os blocos anteriores são confirmados.

Um efeito colateral desse agrupamento é a controvérsia sobre as métricas de transações por segundo (TPS) da Solana. Em sua forma bruta, elas incluem tanto transações de voto quanto transações que não são de voto, o que não ocorre na maioria das redes comparáveis do setor. Isso levou à adoção de uma métrica de “TPS real”, que exclui as transações de voto, como medida mais precisa da capacidade de processamento de transações.

Ao examinar a atividade recente da Solana, vemos que as transações de voto superam as que não são de voto, com uma média ligeiramente inferior a 1.000 por bloco.

As transações de voto representam apenas uma pequena parcela do total de unidades de computação por bloco, com média ligeiramente superior a 2 milhões de CUs por bloco e uma faixa consistente entre 2,1 e 2,3 milhões de CUs. Isso representa apenas 4,5% do limite computacional de 48 milhões de CUs dos blocos da Solana.

As transações de voto são muito previsíveis quanto ao tempo e à computação que exigem em comparação com as transações que não são de voto. Esse é um ponto crucial ao qual voltaremos mais adiante. As CUs das transações que não são de voto são inconsistentes, o que resulta em uso ineficiente do hardware. ‍

Garantir um tempo preciso de execução no runtime é difícil, pois se trata mais de uma medição aproximada. Em média, os blocos procuram se manter dentro de 400 milissegundos, mas ocorrem picos ocasionais. Esses picos podem ser considerados bugs, e há esforços contínuos para identificá-los e corrigi-los, gerando melhorias constantes.

Uma época compreende 432.000 slots. Se cada um durasse exatamente 400 milissegundos, isso resultaria em uma época de precisamente 48 horas. No entanto, como podemos observar nos dados históricos, as épocas raramente, ou nunca, atingem essa meta. No último ano, elas geralmente duraram entre 2,1 e 2,3 dias.

A execução síncrona exige que todos os validadores com stake que participam do consenso sejam superprovisionados para o pior tempo de execução possível em qualquer bloco. Por isso, os requisitos de hardware dos validadores da Solana são relativamente altos.

Isso conclui nossa análise de como o consenso e a execução funcionam atualmente na Solana, com foco principalmente nas partes relevantes para as discussões posteriores. Para visões mais abrangentes, recomendamos nossos artigos anteriores no blog da Helius sobre consenso, PoH, Turbine e como a Solana funciona. Nas próximas seções, examinaremos futuras mudanças no design do protocolo da Solana.

APEX, 2022

A primeira proposta formal de Yakovenko para AE remonta a abril de 2022 e foi intitulada APEX (execução assíncrona de programas). Essa proposta relativamente curta apresenta detalhes práticos de como o consenso pode ser separado da execução e introduz o conceito de dividir o estado em dois domínios isolados: o “Domínio 0” padrão e o “Domínio 1” do programa de votação. Essa configuração separa o programa de votação do restante do banco.‍

Todas as contas pertencem a um único domínio; as transações não podem ler nem gravar em contas de vários domínios. Qualquer transação que faça isso falha imediatamente e é ignorada. O programa do sistema existe nos dois domínios, e o programa de votação é o único outro programa no Domínio 1.

Uma instrução especial do sistema (SystemInstruction::MoveDomains) fornece um mecanismo para que as contas migrem entre domínios uma vez por época, permitindo a transferência de SOL de e para contas de voto.

A proposta também introduz o conceito de um ForkHash, uma contraparte do BankHash. O cálculo do ForkHash avalia apenas as instruções do programa de votação do Domínio 1, enquanto o BankHash avalia todas as instruções que não pertencem ao programa de votação no Domínio 0. As instruções de voto fazem referência ao ForkHash. O cálculo do BankHash ocorre fora da raiz na qual os validadores de consenso votam. Antes, selecionar uma bifurcação e votar nela exigia avaliar e executar por completo todas as transações do banco. Agora, as únicas transações avaliadas durante a seleção da bifurcação são as que envolvem o programa de votação.

Esse design inicial deixa muitas perguntas sem resposta, mas estabelece o conceito fundamental de domínios isolados, que será retomado mais adiante.

Líderes sem banco

Um líder sem banco é um líder livre para produzir blocos sem executar transações que não são de voto, um pré-requisito fundamental para implementar a AE. Em um artigo intitulado O caminho para líderes sem banco, o engenheiro da Anza Andrew Fitzgerald desenvolve uma proposta anterior sobre líderes sem banco (SIMD-005, dezembro de 2022, encerrada), de Tao Zhu, também da Anza. Fitzgerald descreve várias mudanças necessárias para introduzir líderes sem banco na Solana e identifica especificamente três categorias principais de restrições impostas pelo protocolo que limitam a implementação da AE: restrições de bloco, restrições de entrada e restrições de transação.

Atualmente, violar qualquer uma dessas restrições invalida o bloco inteiro. Ao eliminar essas restrições, o protocolo da Solana abriria caminho para a AE e aumentaria a flexibilidade do protocolo na produção e validação de blocos. Veja abaixo um resumo dos diferentes tipos de restrição:‍

Restrições de bloco

São restrições aplicadas ao bloco inteiro, incluindo: 

• Os blocos devem incluir 64 ticks
• A última entrada do bloco deve ser um tick
• As transações em todas as entradas do bloco devem respeitar os limites do bloco

Restrições de entrada

A principal restrição dessa categoria é que as entradas não podem conter transações conflitantes. Fitzgerald apresentou a SIMD 0083: flexibilização das restrições de entrada em novembro do ano passado, tratando especificamente desse problema. A SIMD foi aceita.

Restrições no nível da transação

Essa é a maior categoria e pode ser dividida em três subcategorias:

Restrições estáticas

Restrições que podem ser verificadas sem o conhecimento de qualquer estado adicional. Elas incluem a verificação de assinatura, o tamanho da transação, o número de contas listadas na lista de endereços de leitura/gravação e a conformidade com o formato dos dados da transação (ou seja, uma transação deve poder ser desserializada)‍

Essa subcategoria de restrições no nível da transação não precisa ser alterada.

Restrições do estado do banco

Elas incluem verificações da exclusividade da assinatura da transação, para garantir que ela ainda não tenha sido incluída em um bloco recente, e a verificação de idade (ou seja, as transações devem incluir um blockhash recente)

Essa subcategoria exige conhecimento do estado recente do banco.

Restrições de transação baseadas no estado da conta

A subcategoria mais restritiva, que inclui a resolução da tabela de consulta de endereços (ALT), verificações de nonce, verificações do pagador de taxas e verificações de executabilidade

Essa subcategoria exige conhecimento das transações anteriores.

Fitzgerald propôs formalmente mudanças nessa categoria de restrições na SIMD 0082: flexibilização das restrições de transação, que continua em aberto.

Como observa Fitzgerald, o principal requisito da AE é que a verificação de blocos não dependa do estado das contas. Se a verificação de um bloco exigir os resultados de transações anteriores, ele não poderá ser executado de forma assíncrona. Portanto, é necessário eliminar as dependências do estado das contas na verificação de blocos. Além disso, muitas dessas restrições são desnecessariamente rigorosas.

Por exemplo, uma transação em que o signatário não tenha lamports suficientes para pagar as taxas não deve ser executada no protocolo atual nem com as mudanças propostas. Porém, com as alterações sugeridas, incluir essa transação não tornará inválido o restante do bloco.

De modo geral, o trabalho de Fitzgerald oferece uma estrutura prática de como o estágio bancário poderia ser modificado para preparar o caminho para a AE e descreve várias etapas que alteram o consenso e são necessárias para tornar a AE uma realidade.

APExB 2023: AE encontra MCBP

Em março de 2023, quase um ano após o projeto inicial do APEX, Yakovenko apresentou uma proposta mais abrangente e detalhada, intitulada Execução e transmissão assíncronas de programas (APExB) SIMD 0023. Essa proposta vai além da implementação da AE e apresenta uma visão mais ampla, que inclui a integração de múltiplos produtores simultâneos de blocos (MCBP).

A proposta apresenta o conceito de “construtores”, que são entidades distintas dos líderes. Os construtores são nós com stake que criam UserBlocks compostos exclusivamente por transações sem voto. Esses UserBlocks são propagados pela árvore Turbine e têm seus próprios “UserBlockSlots”. Por padrão, há dois UserBlockSlots por slot regular.

Os construtores têm seu próprio cronograma, independente do cronograma dos líderes. Vários construtores podem ser programados para criar UserBlocks simultaneamente. As unidades de computação são divididas igualmente entre os construtores e os slots de UserBlock. Por exemplo, um bloco com dois construtores, dois slots de UserBlock e um limite de 48 milhões de CUs terá um limite de 12 milhões de CUs por slot de UserBlock (48/4).

Os líderes criam blocos de votos de consenso normalmente, seguindo o cronograma de líderes, enquanto os construtores produzem e transmitem simultaneamente UserBlocks de transações de usuários. Os UserBlocks especificam o número de seu slot e são assinados pelo construtor para impedir que o líder manipule ou exclua parte do bloco. Quando o líder recebe um UserBlock pela Turbine, ele gera um UserBlockEntry usando um hash do UserBlock e adiciona esse UserBlockEntry à Proof of History (PoH).

Os validadores não podem votar em blocos cujos UserBlocks correspondentes ainda não tenham recebido; caso contrário, não há como garantir que todos possam executar os dados, pois eles poderiam ser retidos. No entanto, eles podem votar nos blocos dos líderes executando apenas os votos antes de executar as transações de UserBlock. Os validadores executam UserBlocks apenas na bifurcação mais pesada e só precisam enviar seu BankHash mais recente ao votar, que pode corresponder a um slot pai mais antigo. Os validadores votam em VoteHashes, que cumprem a mesma finalidade dos ForkHashes na proposta APEX de 2022 — essencialmente, um BankHash apenas para transações de voto.

Cronograma dos construtores

Se houver dez construtores de UserBlock por bloco da rede, cada um receberá 10% dos shreds da Turbine e 10% da computação disponível. Os construtores são programados por meio de dois processos: aleatório e persistente.

No limite de cada época, os construtores aleatórios são designados com base em um processo de seleção ponderado por stake. Os slots persistentes de UserBlock são alocados por meio de um sistema de leilão holandês e concedidos aos maiores licitantes dispostos a queimar mais SOL.

Ordenação por prioridade das transações 

Presume-se que cada UserBlock tenha sido criado simultaneamente durante o UserBlockSlot em que o líder o codificou. Para cada UserBlock dentro do UserBlockSlot, as transações são ordenadas pela taxa de prioridade antes da execução. Se as transações de dois blocos diferentes tiverem a mesma prioridade, elas serão ordenadas conforme a posição em que cada UserBlock aparece no PoH do líder. Isso significa que as taxas de prioridade determinam a prioridade de execução. Transações duplicadas ou inválidas de UserBlocks são ignoradas sem alterações de estado. Se vários UserBlockEntries contiverem a mesma transação, a segunda será ignorada.

Acima: no Cenário 1, a Transação B terá prioridade apesar de chegar mais tarde ao fluxo de PoH. No Cenário 2, a Transação C terá prioridade porque possui a mesma taxa de prioridade que a Transação D, mas seu bloco aparece antes no fluxo de PoH.

Nesse projeto, os construtores capturarão todo o MEV. A proposta deixa em aberto como os construtores e líderes devem dividir as taxas das transações dos usuários.

Os construtores também podem criar BundleTransactions, que são grupos de transações dentro do UserBlock projetados para execução em um único lote ordenado. Essas transações também podem adicionar uma taxa de prioridade para que todo o pacote tenha prioridade de execução como um lote, de forma semelhante à implementação atual dos pacotes da Jito.

Limites de época

Os pesos de stake influenciam a escolha da bifurcação e são atualizados no limite de cada época. Isso tem implicações importantes para o projeto. Os validadores precisam ter concluído a execução das transações sem voto antes de continuar votando além desse limite de época.

No entanto, Yakovenko observa: “Os nós não podem ficar tão atrasados porque os limites gerais de CUs são definidos para execução síncrona. Porém, com a opção de execução assíncrona, é muito mais fácil recuperar o atraso. O processamento bruto do ledger, sem lidar com a rede, é de 20 a 30 vezes mais rápido.”

Considerações

Ter vários construtores torna o gerenciamento de recursos mais complexo. Os clientes podem escolher o construtor mais próximo, mas as taxas de prioridade podem variar para cada UserBlock, e os usuários provavelmente não saberão qual bloco poderá ficar saturado ao enviar suas transações.

Os benefícios incluem a previsibilidade do agendamento. As aplicações podem fazer ofertas pela porcentagem da largura de banda do bloco necessária à operação e criar sequenciadores dedicados que garantam a liquidação posterior na blockchain. Incluir construtores aleatórios de UserBlock é crucial, pois impede que construtores persistentes de blocos censurem transações e impeçam que elas sejam incluídas posteriormente.

APE na Solana em 2024

Em um artigo no X intitulado Execução assíncrona de programas (APE), publicado em junho deste ano, Yakovenko detalha ainda mais o conceito de domínios de execução descrito inicialmente na proposta APEX de 2022.

Os Domínios de Execução, originalmente Domínio 0 e Domínio 1, agora são chamados de Domínio de Execução de Votos (VED) e Domínio de Execução de Usuários (UED). Sua finalidade permanece a mesma: isolar completamente a votação de consenso da execução de transações.

Os Domínios de Execução são definidos como conjuntos distintos de programas, juntamente com as chaves e os valores com os quais interagem, executados de forma independente de outros conjuntos:

• Os Domínios de Execução podem ser executados em diferentes threads e núcleos e concluídos em momentos diferentes em máquinas fisicamente separadas 
• O Domínio de Execução A não pode ler nem gravar nenhum valor no Domínio de Execução B 
• Os domínios podem compartilhar um estado que permaneça consistente durante a execução de qualquer um deles
• O pagador da taxa determina o domínio no qual uma transação é executada
• É necessário um protocolo para sincronizar o estado entre os domínios e facilitar a movimentação de chaves e valores

Componentes do Domínio de Execução de Votos (VED)

• SystemProgram: usado para transferências
• VoteProgram: o programa principal de votação. Esse programa é estático e deve estar presente tanto no UED quanto no VED
• Sysvars do VoteProgram: variáveis usadas para votação
• Autoridade de voto: contas autorizadas a votar
• Pagador de taxas de voto: contas que pagam taxas relacionadas à votação
• Financiador do pagador de taxas: uma conta atualizável que pode ser usada para transferir SOL ao VED

As contas que não estão no VED são consideradas parte do UED.

As contas de voto precisam ser ativadas. Elas são incluídas no VED na época seguinte à ativação. Depois de desativadas, são removidas do VED na época seguinte. Há processos formais definidos para a movimentação de fundos para dentro e para fora do VED.

As contas registram em qual Domínio de Execução estão mapeadas seguindo uma convenção semelhante às permissões de arquivo do Linux (R para leitura, W para gravação e X para execução). Há quatro mapeamentos válidos:

Somente contas do Vote Program e do System Program podem ser movidas entre o VED e o UED. O System Program fornece uma interface para mover contas do System e contas do Vote Program para dentro e para fora do VED. Essa abordagem elimina a necessidade de uma conta FeePayerFunding explícita. Qualquer conta do System pode ser remapeada entre o VED e o UED para movimentar fundos entre domínios.

Os líderes executam apenas o domínio VED nos blocos que criam, o que significa que podem ter informações parciais ou incompletas sobre o status dos pagadores de taxas do UED. Depois que um bloco é recebido, os validadores executam primeiro as transações do VED. O estado resultante do VED é usado para calcular o Hash do VED, que os validadores usam para votar. 

A reprodução do UED ignora transações com pagadores de taxas inválidos. As atualizações de estado do UED calculam o Bankhash, conhecido como Hash do UED. Se um terço ou mais dos validadores enviar Hashes do UED diferentes, todos os nós deverão parar e alertar os operadores.

Ativação de novos recursos

Agora que o consenso está desacoplado da execução, o VoteProgram precisa ser projetado para lidar com cenários em que votos do VED possam ultrapassar os limites de época, fazendo com que novas ativações de recursos ocorram em momentos diferentes das transações que interagem com o VoteProgram no UED.

Arquitetura de estágio final de 2024

No início de 2024, Yakovenko publicou Arquitetura de estágio final, um documento que apresenta uma visão ousada do futuro da Solana como uma rede de 10.000 nós com tempos de bloco de 120 milissegundos. O documento reafirma e amplia propostas de projeto anteriores, destacando a adoção da AE como o caminho para concretizar essa visão ambiciosa.

Líderes sem Bank

Em resumo:

● Os líderes mantêm um cache dos saldos das contas pagadoras de taxas

● Se um pagador de taxas for usado como uma conta gravável na origem de uma transferência do sistema ou passado como conta gravável junto ao programa do sistema para outro programa, o saldo do pagador de taxas será definido como 0

● Os blocos são preenchidos com base nas CUs declaradas até ficarem cheios, seguindo a ordenação local por prioridade de taxas e subtraindo as taxas das transações do cache de saldo do pagador de taxas 

● O cache de saldo das contas pagadoras de taxas é reabastecido pelo cálculo do BankHash 

Inicialmente, os líderes podem obter os saldos das contas dos pagadores de taxas consultando vários nós completos ou RPCs. No caso raro de os nós fornecerem dados incorretos, o resultado seriam transações com falha, e não uma falha de consenso. Se os saldos dos pagadores de taxas estiverem desatualizados, isso poderá causar spam dentro dos blocos sem afetar o consenso. O custo do spam de transações com falha é relativamente baixo e envolve principalmente a largura de banda da Turbine necessária para propagar as transações e o espaço adicional de armazenamento que elas ocupam no ledger. Além disso, as equipes da Temporal e da Firedancer trabalham ativamente em ferramentas que reduzem o spam antes que ele chegue aos blocos, implementando mecanismos como filtragem de transações inválidas, desduplicação e bloqueio de transações destinadas a falhar devido a conflitos de bloqueio de leitura/gravação.

Esse problema é fácil de detectar e monitorar. Os operadores podem acompanhar o desempenho dos líderes e avaliar o nível de spam nos blocos, o que permite resolver problemas rapidamente e mudar para uma fonte de dados alternativa, se necessário. Como os validadores buscam maximizar seus ganhos, eles têm incentivo para manter um cache preciso dos saldos das contas pagadoras de taxas.

Subcomitês de tamanho fixo

Implementar a AE em uma grande rede de 10.000 nós exige a introdução de comitês rotativos de votação com tamanho fixo, o que representa uma mudança significativa no mecanismo de consenso. Essa alteração estabiliza os custos de recursos da votação de consenso, independentemente do número total de nós com stake. Yakovenko propõe que um comitê rotativo de 200 ou 400 nós seria suficiente. Essa configuração permite que os validadores participem da votação de consenso com requisitos mínimos de estado, limitados ao quórum, aos pesos de stake e aos saldos das contas de voto. A ocupação de memória é pequena, e o arquivo de snapshot correspondente pode ser facilmente distribuído e reinicializado após uma reinicialização.

O uso de subcomitês rotativos de tamanho fixo em protocolos tolerantes a falhas bizantinas (BFT) é um conceito estabelecido, já implementado em produção por redes semelhantes, como a Tron em produção. Ele se baseia na abordagem de amostragem de comitês, que seleciona um comitê menor para cuidar do consenso e transmite os resultados para toda a rede de réplicas.

Uma abordagem inicial para a Solana poderia simplesmente alocar um número definido de CUs aos votos, selecionando em cada época os principais validadores por stake que coubessem nessas CUs para acompanhar a escolha da bifurcação. Os demais validadores ainda votariam e receberiam recompensas, mas seus votos não seriam considerados na escolha da bifurcação.

Contas de voto

● As contas de voto precisam ter SOL suficiente para cobrir duas épocas de votos 

● As transações de voto devem ser votos simples

● É permitido sacar SOL da conta de voto se o saldo exceder o equivalente a uma época de votos

● Para remover todos os lamports, a instrução Vote CLOSE deve exigir que uma época inteira transcorra. As contas de voto são marcadas para CLOSE na primeira época, mas só podem ser CLOSE na segunda época

CLOSE permite sacar todo o SOL e excluir a conta de voto. Depois que uma conta é marcada para CLOSE, ela só pode ser excluída e não pode ser reaberta

● Os votos contêm um VoteBankHash em vez de um BankHash regular 

BankHashes

Os validadores calculam um VoteBankHash para transações de voto simples usando o mesmo formato do BankHash atual e desconsiderando todas as outras transações. Esses VoteBankHashes incorporam o VoteBankHash anterior, em vez do BankHash completo.

Para blocos confirmados de forma otimista por uma supermaioria de dois terços, os validadores também começam a calcular o UserBankHash, que inclui todas as transições de estado, exceto as já consideradas no VoteBankHash.

Um BankHash é calculado para cada slot combinando o VoteBankHash, o UserBankHash e o BankHash anterior. Os 99,5% principais validadores enviam esse BankHash como parte de seu voto a cada 100 slots. Além disso, alguns nós podem transmitir o BankHash pela rede de gossip para sinalizar que nenhum não determinismo foi detectado.

Suponha que menos de dois terços dos validadores enviem o BankHash completo. Nesse caso, os líderes podem reduzir em 50% o espaço do bloco para transações de usuários e contas graváveis, evitando exploits que poderiam aumentar excessivamente o tempo de reprodução.

O estado só precisa ser calculado uma vez por época para estabelecer o próximo quórum, garantindo que os nós de consenso e os líderes permaneçam sincronizados. A execução pode ser agregada e processada em lotes em máquinas separadas dos nós de consenso. Os usuários que precisam de execução síncrona — a maioria das aplicações e RPCs — podem dedicar recursos de hardware para processar cada transição de estado em tempo real sem esperar pela rede mais ampla.

Considerações

Os provedores de RPC que oferecem dados de estado em tempo real aos usuários não têm uma assinatura para verificar se o estado calculado localmente corresponde ao estado calculado pela rede mais ampla. No entanto, após a finalização de uma bifurcação, a rede converge para um único estado canônico correto, que pode ser calculado de forma determinística. Para minimizar o risco de bugs em runtime ou corrupção de dados, os nós que buscam fornecer dados de estado precisos devem operar vários nós. Se qualquer divergência na execução do estado for detectada, as operações deverão ser interrompidas imediatamente.

Além disso, os usuários podem enviar transações que confirmem o BankHash ou acionem uma interrupção. A rede só processará essas transações se o BankHash calculado corresponder ao fornecido ao usuário por seu provedor de RPC.

Conclusão

Yakovenko imagina um futuro ousado para a Solana, com tempos de bloco reduzidos a 120 milissegundos e um aumento expressivo no número de nós, viabilizado pela adoção da AE. No entanto, concretizar esse futuro exige alinhar equipes distintas de clientes e a comunidade mais ampla de desenvolvedores da Solana em torno dessa visão, além de enfrentar os grandes desafios de engenharia envolvidos na implementação dessas mudanças. 

Membros proeminentes da comunidade expressaram preocupação com muitas dessas mudanças propostas. Richard Patel, da equipe da Firedancer, alertou que "implementar a execução assíncrona para produtores de blocos é bastante complexo e envolve riscos significativos."

Embora apoie a AE, Zano Sherwani, da Jito Labs, criticou o MCBP, afirmando: “Múltiplos proponentes simultâneos são uma solução terrível em busca de um problema para resolver. O nível de complexidade que isso adiciona ao protocolo não é justificado pelo que tenta resolver, se é que resolve alguma coisa.”

Em um podcast recente, ao ser questionado sobre vários construtores de blocos, Mert Mumtaz, da Helius, respondeu: “Não estou totalmente convencido.”

Sem dúvida, a AE tem potencial para gerar benefícios significativos de desempenho. Tempos de bloco menores resultam em confirmações mais rápidas e uma experiência do usuário melhor, além de aumentar a resistência à censura e reduzir a janela para reordenação de transações.

No entanto, também precisamos avaliar cuidadosamente as desvantagens, incluindo o possível aumento da complexidade do protocolo e uma dependência maior de provedores de RPC. Em cenários específicos, esses provedores podem ser os únicos participantes com uma visão atualizada e em tempo real do estado da blockchain.

A AE representa uma grande atualização para a Solana. Com este artigo, buscamos ampliar o conhecimento da comunidade de desenvolvedores da Solana sobre as mudanças empolgantes que a AE introduzirá e incentivar uma discussão mais bem informada sobre esse tema importante.

Agradecemos muito a 0xIchigo e Anatoly Yakovenko pela revisão das versões anteriores deste trabalho.

Recursos adicionais

• Consenso na Solana - Blog da Helius
• Visão geral executiva da Solana - Blog da Helius
• O caminho para uma arquitetura sem Bank - A. Fitzgerald
• Execução assíncrona de programas (APE) - A.Yakovenko
• Arquitetura de estágio final - A.Yakovenko
• Execução e transmissão assíncronas de programas (APExB) SIMD 0023