Atualização do Agave 4.1: tudo o que você precisa saber

Introdução

Com o Agave 4.1, o principal cliente validador da Solana mantém sua evolução constante, oferecendo melhorias de desempenho agora e, ao mesmo tempo, preparando o terreno para blocos maiores, slots de 200 ms e a futura implementação do Alpenglow.

Atualizações de destaque do ciclo de lançamento da versão 4.1

• Ciclo de lançamentos mais rápido, agora com versões principais a cada seis semanas
• Continuidade do trabalho de preparação para o Alpenglow, incluindo gerenciamento de chaves públicas BLS*, Validator Admission Tickets* e o cluster de testes da comunidade
• Adoção do XDP ultrapassando um limite crítico da rede
• Mais reescritas com Pinocchio, incluindo p-memo e p-ATA
• Redução do uso de RAM pelos validadores
• Preparação para slots de 200 ms**

* Atualizações controladas por feature gates

** Previsto para o Agave 4.2

Além do trabalho no cliente principal, a Anza e o ecossistema mais amplo também avançam em paralelo com várias iniciativas importantes:

• Constellation: o Constellation propõe a primeira implementação formal, no nível do protocolo, de Multiple Concurrent Proposers (MCP) em uma blockchain de produção em grande escala. Em vez de conceder a um único líder ampla autonomia sobre a inclusão de transações, o Constellation introduz proponentes e atestadores que limitam o que o líder pode excluir de um bloco válido.
• Proteção quântica: a equipe de pesquisa da Anza começou a explorar como proteger a Solana contra futuros adversários quânticos, incluindo pesquisas sobre assinaturas pós-quânticas, migração de contas, assinaturas de consenso, propagação de blocos e verificação de assinaturas onchain.
• Atualizações econômicas: uma nova onda de propostas de tokenomics também está a caminho. A SIMD-550 propõe dobrar a taxa de desinflação da Solana de -15% para -30%, enquanto a SIMD-553: taxa de recursos e inclusão propõe dividir a atual taxa de assinatura em uma taxa-base de inclusão paga ao líder e uma taxa de recursos queimada, calculada com base nas unidades de custo solicitadas.
• Novas ferramentas de governança: a próxima rodada de propostas econômicas também está sendo moldada por uma infraestrutura de governança aprimorada. As novas ferramentas permitem que não apenas validadores, mas também stakers, participem diretamente da governança da Solana, ampliando o grupo que pode opinar sobre mudanças no protocolo principal.

Há muita coisa acontecendo agora.

Seja você operador de validador ou desenvolvedor, este guia oferece as atualizações e informações necessárias para aproveitar ao máximo as melhorias mais recentes. Cada seção deste artigo é independente, permitindo que você se concentre nos tópicos mais relevantes. 

No momento em que este texto foi escrito, o Agave v4.1.0-rc.1 já era recomendado para uso geral na mainnet. Validadores, é hora de atualizar!

Preparação para o Alpenglow

Grande parte da base para a atualização de consenso Alpenglow está sendo incorporada durante o ciclo de lançamento do Agave 4.1. Essas mudanças preparam a rede para a transição do Tower BFT para o Alpenglow, incluindo o gerenciamento de chaves BLS no programa de votação, Validator Admission Tickets e marcadores de Fast Leader Handover.

Cluster de testes da comunidade

O caminho restante até a ativação do Alpenglow na mainnet agora depende bastante de testes extensivos em condições reais. Desde maio, um cluster de testes da comunidade com cerca de 100 validadores distribuídos geograficamente executa a atualização em um ambiente de rede ativo, testando a transição entre o consenso atual da Solana, baseado no Tower BFT, e o Alpenglow antes da ativação na mainnet.

O objetivo é tornar o processo de lançamento o mais tranquilo possível. Os validadores do cluster têm alternado entre o Tower BFT e o Alpenglow, exercitando o caminho de migração em condições reais de operação, em vez de depender apenas de testes internos controlados. As discussões acontecem no canal `ag-community-cluster` do Discord da Solana Tech, e a atividade do cluster em tempo real pode ser acompanhada pelos painéis da comunidade do Valid Blocks, Staking Facilities e Noders.

Gerenciamento de chaves públicas BLS

A SIMD-0387: gerenciamento de chaves públicas BLS na conta de votação será ativada durante o ciclo de lançamento do Agave 4.1. Isso adiciona a infraestrutura do programa de votação necessária para que os validadores registrem chaves públicas BLS em suas contas de votação antes do Alpenglow. O Alpenglow usa assinaturas agregadas BLS para tornar a agregação e a verificação de votos mais baratas, mas as chaves públicas BLS são diferentes das atuais chaves Ed25519 de autoridade de votação. 

Os validadores podem adicionar chaves públicas BLS às suas contas de votação enquanto continuam operando com as chaves Ed25519 de autoridade de votação existentes. Quando o Alpenglow estiver ativo, as contas de votação sem uma chave pública BLS registrada não poderão participar do novo processo de votação.

Alpenglow Validator Admission Tickets (VAT)

O ciclo de lançamento do Agave 4.1 também incluirá a ativação da SIMD-0357 na mainnet, que implementa Validator Admission Tickets (VAT). Os VATs foram projetados para preservar uma estrutura de custos semelhante para validadores à medida que a Solana abandona o atual modelo de transações de votação do Tower BFT.

Atualmente, os validadores pagam continuamente taxas de transação de votação ao votar, totalizando ~2,1 SOL por época para aqueles que votam de forma consistente. No Alpenglow, essas transações de votação são substituídas por um novo modelo de consenso. Por isso, a SIMD-0357 introduz um custo de admissão cobrado uma vez por época. Cada validador qualificado para participar da votação do Alpenglow paga um VAT de 1,6 SOL por época, mantendo uma barreira econômica comparável e reduzindo o risco de uma expansão imediata e descontrolada do conjunto de validadores após o lançamento do Alpenglow.

A implementação ocorre no limite da época. Ao entrar em uma nova época, o runtime calcula o conjunto de validadores da época seguinte, filtra as contas de votação que têm uma chave pública BLS registrada e lamports suficientes para cobrir o VAT e o aluguel e, em seguida, deduz o VAT das contas de votação dos validadores aceitos. Esses lamports são enviados diretamente para a conta incineradora. Se mais de 2.000 validadores se qualificarem, o conjunto de votação será limitado pelo peso do stake, selecionando os validadores qualificados com maior peso.

Na prática, isso muda onde os operadores de validadores precisam manter os fundos. Atualmente, as taxas de transação de votação são pagas pela conta de identidade do validador, que precisa ser um par de chaves ativo para as operações normais do validador. Com os VATs, o custo de admissão passa a ser deduzido da conta de votação.

Marcadores de Fast Leader Handover

Por fim, a ativação da SIMD-0337: marcadores para o Fast Leader Handover do Alpenglow adicionará novos marcadores de bloco que permitem a um líder do Alpenglow declarar o pai de um bloco no início dele e, quando necessário, atualizar esse pai durante a transmissão do bloco. Esses marcadores são compatíveis com o Fast Leader Handover, projetado para reduzir atrasos de sincronização entre líderes.

Maior adoção do XDP e o caminho para 100 milhões de CUs

O XDP (eXpress Data Path) é o caminho de rede de alto desempenho que o Agave usa para acelerar o Turbine. Ele permite que o Agave carregue um programa eBPF próximo à placa de interface de rede, fazendo com que o tráfego de shreds ignore grande parte do caminho padrão de processamento de pacotes do Linux. A adoção do XDP é essencial para que a rede alcance a antiga meta de blocos com 100 milhões de CUs. 

A adoção já ultrapassou um marco importante. No início deste mês, a rede passou pela “virada”, com mais líderes executando o XDP do que sem ele. Atualmente, mais de dois terços da rede ativaram o XDP. O Agave 4.1 reflete essa maturidade ao remover o rótulo experimental do suporte ao XDP e substituir as antigas flags `--experimental-retransmit-xdp-*` por `--xdp-interface`, `--xdp-cpu-cores` e `--xdp-zero-copy`. No Agave 4.2, está previsto que o XDP seja ativado por padrão.

Para operadores de validadores que ainda não fizeram a mudança, a página de atualização da Solana Foundation e o guia de configuração da Anza oferecem uma lista prática de verificação de compatibilidade que abrange suporte do kernel, hardware de rede, recursos do validador, flags de inicialização e etapas de verificação. Abaixo está um guia útil de compatibilidade de drivers e NICs.

Mais reescritas de programas com Pinocchio

O lançamento bem-sucedido do p-token comprovou recentemente que reescritas direcionadas dos programas mais usados da Solana podem gerar economias significativas de computação em toda a rede. Como substituto direto do programa SPL Token, o p-token reduz o consumo de unidades de computação (CUs) em cerca de 95%, resultando em uma melhoria de eficiência de aproximadamente 19 vezes para transações de token padrão. Antes, as instruções do programa de tokens representavam cerca de 10% do uso de CUs de todo o bloco. Ao reduzir essas instruções para aproximadamente 5% do custo anterior, o p-token liberou quase 9,5% da capacidade total do bloco.

O “p” de p-token significa Pinocchio, uma biblioteca otimizada, eficiente e sem dependências, desenvolvida pela Anza para criar programas da Solana. O Pinocchio substitui o crate solana-program padrão, que usa amplamente tipos zero-copy para processar dados de instruções e contas.

Agora, a Anza está reescrevendo outros programas principais com Pinocchio. O objetivo não é introduzir novos padrões nem forçar migrações no nível das aplicações, mas tornar a execução de programas existentes e amplamente usados muito mais barata.

Programa p-memo

O primeiro exemplo é o p-memo, uma reimplementação do programa SPL Memo com Pinocchio, que já está ativa na mainnet. O programa Memo é pequeno, mas os ganhos de eficiência ainda são impressionantes. Sem signatários, o p-memo consome 287 CUs, em comparação com 2.022 CUs do programa Memo atual, ou cerca de 14% do custo existente. Quando há signatários, a diferença se torna ainda mais evidente: com um signatário, o p-memo usa 513 CUs, em comparação com 13.525 CUs; com dois signatários, 628 CUs contra 25.111 CUs; e com três signatários, 743 CUs contra 36.406 CUs. Isso significa que, em casos com muitos signatários, o p-memo reduz o consumo de computação para apenas 2% a 4% do custo do programa atual.

Programa p-ATA

O trabalho no p-ATA, uma reimplementação do programa Associated Token Account com Pinocchio, também está em andamento. O programa ATA define o mapeamento padrão entre uma carteira, um mint de token e a conta de token usada para armazenar esse mint. Ele oferece uma forma determinística de derivar a conta de token associada de um usuário e permite que qualquer pessoa crie essa conta para um destinatário caso ela ainda não exista. 

O programa ATA é o quinto mais invocado na rede. Segundo as estimativas da equipe da Anza, ele aparece em ~11,9% de todas as transações e representa ~13,3% do consumo total de CUs. A reescrita pode reduzir o uso médio ponderado de CUs em 80,9%, com economias adicionais esperadas das novas instruções adicionadas junto ao p-ATA. Considerando o uso atual da rede, isso representaria uma economia global de cerca de 10% das CUs na mainnet. Na amostragem da Anza, o p-ATA liberou mais de 2,78 milhões de CUs por bloco.

É improvável que p-token, p-memo e p-ATA sejam o fim desse trabalho. O programa Token-2022 é outro programa muito solicitado. De forma mais ampla, o esforço da Anza para tornar os programas principais `no_std` prepara o terreno para reescrever mais programas fundamentais da Solana com menos dependências e custos de computação menores.

Redução da sobrecarga do ponto de entrada dos programas

Outra mudança relacionada, cuja ativação está prevista para o ciclo de lançamento do Agave 4.1, é a SIMD-0449: ponteiros diretos de contas na entrada do programa, que otimiza o ponto de entrada dos programas. Atualmente, programas sBPF ABIv1 precisam analisar a seção de contas serializadas da entrada do programa para encontrar os limites das contas e construir o slice de contas fornecido ao programa. A SIMD-0449 muda isso ao fazer a VM adicionar à entrada do programa um slice de ponteiros diretos para contas, usando informações de limites que a VM já conhece ao preparar a invocação.

Isso é especialmente relevante para programas no estilo Pinocchio porque a análise de contas representa uma grande parte do custo do ponto de entrada. Com ponteiros diretos para contas, o ponto de entrada pode acessar contas sem percorrer toda a seção de contas, tornando o custo de computação do ponto de entrada efetivamente constante, independentemente da quantidade de contas. 

Nos benchmarks atualizados, um ponto de entrada do Pinocchio com 64 contas cai de 504 CUs para uma estimativa de 7 CUs, enquanto conjuntos menores de contas também convergem para o mesmo custo reduzido de 7 CUs.

Tempos de slot reduzidos para 200 ms

Uma das melhorias de desempenho mais aguardadas é a redução do tempo-alvo dos slots da Solana de 400 ms para 200 ms. É improvável que ela seja implementada durante o ciclo de lançamento do Agave 4.1. O mais provável é que chegue à mainnet com o Agave 4.2. No entanto, cresce o impulso para levar essa atualização importante à mainnet o quanto antes.

A SIMD-0525: redução dos tempos de slot propõe uma implementação em etapas, passando de slots de 400 ms para 350 ms, depois 300 ms, 250 ms e, por fim, 200 ms. Cada etapa é controlada por um feature gate, permitindo que as equipes de clientes e os operadores observem a rede com slots mais curtos antes de avançar para a próxima fase. A Anza testa internamente slots de 200 ms há meses, e a equipe acredita que a rede está pronta para reduções agressivas no tempo de slot. Melhorias na etapa de replay tornaram a mudança mais viável: reproduzir um slot completo de 400 ms agora leva cerca de 40 ms.

A motivação é simples. Slots mais curtos reduzem a latência de confirmação e finalização para os usuários. Eles também encurtam a janela de cada líder. Atualmente, o período de liderança da Solana é de quatro slots consecutivos, o que dá ao líder uma janela de 1,6 segundo com slots de 400 ms. Com slots de 200 ms, essa janela cai para 800 ms. Isso melhora a estrutura do mercado ao reduzir o tempo máximo durante o qual um líder mal-intencionado pode atrasar, reordenar ou incluir transações seletivamente antes que o próximo líder tenha a oportunidade de produzir um bloco.

Slots mais curtos também proporcionam às aplicações uma visão mais granular do tempo onchain. Isso é importante para sistemas que consideram o quão recente é um slot, incluindo consumidores de oráculos e formadores de mercado proprietários no estilo AMM.

A proposta foi cuidadosamente elaborada para evitar mudanças na economia da Solana. `slots_per_year` aumenta na proporção inversa, preservando o cronograma de inflação de SOL. No Alpenglow, os custos do Validator Admission Ticket (VAT) também são ajustados conforme a etapa do tempo de slot, mantendo o custo de admissão próximo do valor pretendido de ~0,8 SOL por dia. Além disso, os limites de trabalho por slot são reduzidos proporcionalmente ao menor tempo-alvo do slot, de modo que a quantidade de trabalho que a rede pode processar por segundo permaneça praticamente inalterada. 

Várias premissas fundamentais permanecem inalteradas. Os períodos de liderança continuam com quatro slots, as épocas permanecem fixas em 432.000 slots e a quantidade de ticks por slot continua em 64. Como as épocas permanecem fixas em número de slots, os slots de 200 ms reduzem a duração de uma época de aproximadamente dois dias para um dia.

Um ponto controverso é o impacto nos custos de votação dos validadores caso os tempos de slot mais curtos sejam ativados antes do Alpenglow. Slots mais rápidos significam mais votos por dia e, portanto, custos diários de votação mais altos para os validadores. Os custos de transação de votação são a maior despesa individual dos operadores de validadores. As transações de votação têm preço uniforme de 0,000005 SOL e, por dia, esses custos de transação totalizam ~1,086 SOL. Com slots de 200 ms, esses custos praticamente dobrariam.

Outras atualizações de destaque

Várias melhorias menores, mas relevantes, devem ser ativadas durante o ciclo de lançamento do Agave 4.1. Elas vão de taxas de comissão mais precisas para validadores a novos primitivos criptográficos e à remoção de um vetor de ataque de negação de serviço no loader atualizável.

Maior precisão nas taxas de comissão dos validadores

Como parte do ciclo de lançamento do Agave 4.1, a atualização controlada por feature gate SIMD-0291: taxa de comissão em pontos-base será ativada na mainnet. Atualmente, as taxas de comissão dos validadores só podem ser definidas em pontos percentuais inteiros. Isso significa que um validador pode definir uma comissão de 5% ou 6%, mas não de 5,5%, 5,25% ou 5,01%.

Com essa atualização, os validadores ganham um controle mais granular ao definir taxas de comissão em pontos-base, sendo que 100 pontos-base equivalem a 1%. O programa de votação adiciona uma nova instrução `UpdateCommissionBps`, permitindo que o responsável autorizado por saques em uma conta de votação atualize com maior precisão a comissão do validador sobre recompensas de inflação. Para os validadores, isso torna as configurações de comissão mais flexíveis e competitivas.

Essa mudança é uma das várias atualizações vinculadas à nova Vote Account V4. Ela também ajuda a preparar a rede para a ativação prevista da SIMD-0123: distribuição da receita de blocos, que permitirá distribuir recompensas de bloco no próprio protocolo.

Syscall SHA-512

A SIMD-0512: syscall Sha512 introduz uma nova syscall que oferece aos programas onchain acesso direto ao hashing SHA-512 por meio do runtime, usando uma interface semelhante às syscalls de hash existentes, como `sol_sha256`, `sol_keccak256` e `sol_blake3`.

SHA-512 é um primitivo fundamental usado na verificação de assinaturas Ed25519 e já existe como dependência interna nos clientes validadores Agave e Firedancer. Até agora, porém, ele não estava disponível para programas onchain. Calcular diretamente o hash de uma mensagem curta onchain é caro e consome milhares de CUs, em comparação com menos de 100 CUs por meio de uma syscall.

Com `sol_sha512`, os programas podem calcular hashes SHA-512 ao custo de uma syscall e receber diretamente o digest padrão de 64 bytes. A mudança é aditiva e controlada por um feature gate. Portanto, programas que não usam a nova syscall não são afetados, e as syscalls de hash existentes permanecem inalteradas.

Reforço do loader atualizável

O ciclo de lançamento do Agave 4.1 também contará com o lançamento controlado por feature gate da SIMD-0431: Loader V3: tamanho mínimo de extensão de programa, que adiciona um tamanho mínimo de extensão à instrução `ExtendProgram` do Loader V3. Após a ativação, os programas precisarão ser estendidos em pelo menos 10.240 bytes (10 KiB), a menos que a conta de dados do programa já esteja a menos de 10 KiB do tamanho máximo de conta de 10 MiB.

Essa mudança corrige um vetor sutil de negação de serviço no loader atualizável atual. `ExtendProgram` não exige permissão, o que significa que qualquer pessoa pode estender a conta de dados de um programa atualizável, mesmo que seja em apenas um byte. Como cada extensão invalida a entrada do programa no cache do slot atual, uma extensão barata de um byte pode interromper temporariamente o acesso ao programa.

Em vez de exigir permissão para `ExtendProgram`, a mudança preserva o design sem permissão da instrução e, ao mesmo tempo, torna o abuso economicamente desvantajoso. Com o novo mínimo de 10 KiB, cada extensão custa aproximadamente 0,072 SOL em lamports isentos de aluguel.

Para atualizações legítimas de programas, o impacto deve ser limitado. Programas que precisarem de menos de 10 KiB de espaço adicional terão que ser estendidos pelo mínimo completo, mas a capacidade extra continuará disponível para futuras atualizações. A SIMD também mantém inalteradas as contas das instruções, os requisitos de signatários, as restrições de CPI e os fluxos de trabalho multisig existentes.

Conclusão

O Agave 4.1 é uma atualização significativa do cliente que reúne uma ampla variedade de melhorias e otimizações de desempenho. Olhando para o futuro, o Agave 4.2 promete ser ainda mais relevante, com transações maiores de 4.096 bytes, slots reduzidos para 200 ms e, possivelmente, a tão aguardada atualização de consenso Alpenglow.

Recursos adicionais

• Cronograma de lançamento do Agave 4.1
• Cronograma do rastreador de feature gates
• Registro de alterações do Agave 4.1
• Pull requests do Agave 4.1