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

Introdução

O Agave v3.1, a mais recente evolução do cliente Solana Agave, chegou! Esta atualização apresenta um amplo conjunto de melhorias no desempenho do cliente, nas operações de validadores e na experiência do desenvolvedor. Ela também inclui a ativação de vários feature gates importantes que estabelecem as bases para a distribuição de recompensas de bloco dentro do protocolo, reduções significativas nas garantias de estado (ou seja, aluguel) e, principalmente, a futura atualização de consenso Alpenglow.

Principais atualizações do Agave 3.1

• Menos I/O de disco durante o replay
• Reinicializações mais rápidas do cliente
• Processamento de transações 2x mais rápido
• Limites maiores de informações de contas em CPI*
• Conta de voto V4 de validadores e atualizações de comissão com atraso*
• Menos rodadas de ChaCha no Turbine*
• Novo ponteiro para dados de instrução*
• Melhorias de RPC

* atualização controlada por feature gate

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 assuntos mais relevantes para seu caso. 

No momento da publicação, o Agave 3.1.8 é considerado um candidato a atualização da mainnet (MUC), e a Anza procura voluntários para ajudar a versão a alcançar 25% do stake. Validadores: é hora de atualizar!

Ganhos de desempenho do cliente

Esta versão principal do Agave inclui diversos ganhos de desempenho. A seguir, destacamos algumas das melhorias mais importantes.

Menos I/O de disco durante o replay 

O Agave 3.1 reduz significativamente a atividade de disco durante o replay. A imagem abaixo mostra uma janela de profiling de 10 segundos do replay com o Agave 3.0 processando transações reais da mainnet. As operações de disco (indicadas por marcadores vermelhos) ultrapassam 1.100 eventos. Isso é um problema porque cada acesso ao disco introduz tempo de espera de I/O, aumentando a variação tanto no banking quanto no replay. 

Com o Agave 3.1, o I/O de disco durante o replay é drasticamente reduzido. A mesma janela de 10 segundos mostra menos de 80 operações de disco, uma queda de 93%. Isso melhora a estabilidade do replay e reduz o desgaste dos discos, ajudando a prolongar sua vida útil.

Reinicializações mais rápidas do cliente

O desempenho da reinicialização do cliente continua melhorando drasticamente, principalmente graças às otimizações no AccountsDB. Nas versões principais do Agave 1.*, as reinicializações costumavam levar mais de 30 minutos. As versões do Agave 2.* reduziram esse tempo para menos de 10 minutos. No Agave 3.1, o tempo cai ainda mais e agora normalmente fica abaixo de 1 minuto. Olhando adiante, espera-se que a próxima versão principal, o Agave 4.0, reduza o tempo de reinicialização para menos de 30 segundos, melhorando ainda mais a disponibilidade dos validadores e diminuindo o tempo de recuperação após manutenções ou falhas inesperadas.

Processamento de transações mais rápido

O Agave 3.1 inclui correções importantes que melhoram significativamente a eficiência do processamento de transações. Antes, bugs no pipeline de processamento faziam os workers de banking passar tempo demais sincronizando com o Proof of History, em vez de executar transações. Assim, no modo de líder, o cliente não agendava transações ativamente durante cerca de 61% do tempo.

Com esses problemas resolvidos no Agave 3.1, as threads dos workers de banking agora passam ~91% do tempo processando transações. Como resultado, o processamento ficou duas vezes mais rápido, melhorando consideravelmente o throughput e o aproveitamento do tempo de líder.

Outras melhorias de desempenho que merecem destaque incluem manter, por padrão, o índice de contas totalmente na memória. As transições nos limites das épocas também melhoraram significativamente e agora são concluídas em menos de 400 ms, ante mais de dois segundos, resultando em muito menos slots ignorados durante as trocas de época.

Fortalecimento da rede

A Anza investe bastante em resiliência por meio de testes de estresse contínuos, red teaming e monitoramento da situação em tempo real para o cliente Agave. Embora os detalhes desse trabalho tenham sido mantidos em sigilo anteriormente, o programa amadureceu o suficiente para que essa importante iniciativa seja reconhecida publicamente. Uma equipe dedicada de invalidadores da Anza ataca ativamente a testnet pública da Solana com um novo conjunto de testes a cada hora. 

Os testes se dividem em duas categorias principais. A primeira se concentra em cenários de negação de serviço na camada de rede, testando sob estresse o tratamento de backpressure e o descarte de carga em condições extremas. A segunda envolve a produção de blocos selecionados com transações incomuns e adversariais, criadas para levar a Solana VM ao limite.

A Anza desenvolve sistematicamente cenários de ataque e cria defesas contra eles. Esse trabalho se baseia em modelos realistas de ameaças, considerando o que um validador mal-intencionado, bem-informado e com um volume razoável de stake poderia fazer, além do que um desenvolvedor externo, sofisticado e bem-capitalizado poderia tentar.

Esse nível de preparação foi validado em dezembro, quando a Solana resistiu a um grande ataque DDoS que durou semanas e, segundo relatos, atingiu um pico de quase 6 Tbps, tornando-se um dos maiores ataques já registrados contra um sistema distribuído. Apesar da enorme escala, a rede apresentou pouco impacto mensurável, mantendo confirmações em menos de um segundo e latência de slots estável durante todo o ataque.

Limites maiores de informações de contas em CPI

A SIMD-0339: Aumentar o limite de informações de contas em CPI deve ser ativada na mainnet durante o ciclo de lançamento do Agave 3.1. Isso aumenta em quase 4x o limite de informações de contas em invocações entre programas (CPI), de 64 para 255, resolvendo um antigo problema para desenvolvedores que criam programas que precisam passar grandes listas de contas por meio de CPIs. As informações de contas são os metadados serializados das contas enviados às syscalls de CPI, permitindo que o programa chamado leia as contas fornecidas pelo chamador.

Anteriormente, as CPIs eram limitadas a apenas 64 informações de contas por syscall. Essa restrição obriga os programas a remover duplicatas e reconstruir listas de contas antes das chamadas de CPI, adicionando complexidade e overhead. Na prática, muitos programas reais excedem esse limite com frequência, como wrappers para agregadores de DEX, a exemplo da DFlow ou Jupiter.

Além de aumentar o limite, esse feature gate introduz mudanças nos custos de unidades de computação que variam conforme o número de informações de contas e contas de instrução passadas para uma CPI. Isso preserva os incentivos para que os programas minimizem o uso de contas. 

Como o limite está apenas sendo aumentado, a mudança é totalmente retrocompatível e não afeta o comportamento dos programas existentes.

Conta de voto V4 de validadores e atualizações de comissão com atraso

Duas atualizações controladas por feature gates, programadas para ativação durante o ciclo de lançamento do Agave 3.1, são especialmente importantes para operadores de validadores. A primeira é a SIMD-0185: Conta de voto V4, que introduz uma nova versão do estado da conta de voto para viabilizar futuras atualizações do protocolo, incluindo Alpenglow, distribuição da receita de blocos e melhorias nas comissões.

Hoje, as contas de voto armazenam apenas uma taxa de comissão. No entanto, com a futura possibilidade de distribuir a receita de blocos dentro do protocolo, descrita na SIMD-0123: Compartilhamento da receita de blocos, os validadores precisarão definir taxas de comissão distintas para diferentes fontes de receita.

Além disso, toda a receita de taxas de bloco, incluindo taxas básicas e prioritárias, é depositada atualmente na conta de identidade do validador. Isso pode gerar preocupações operacionais e de segurança, pois a conta de identidade não pode ser uma cold wallet, já que precisa assinar mensagens frequentemente para protocolos de rede essenciais, como Turbine e Gossip.

A Conta de Voto V4 resolve essas limitações expandindo o estado de voto com novos campos (veja o bloco de código abaixo), que permitem aos validadores configurar tanto a taxa de comissão quanto a conta coletora para recompensas de inflação e receita de blocos. A atualização também remove o campo legado prior_voters.

pub struct VoteStateV4 {
    pub node_pubkey: Pubkey,
    pub authorized_withdrawer: Pubkey,

    /// REMOVED
    /// commission: u8,

    /// NEW: the collector accounts for validator income
    pub inflation_rewards_collector: Pubkey,
    pub block_revenue_collector: Pubkey,

    /// NEW: basis points (0-10,000) that represent how much of each income
    /// source should be given to this VoteAccount
    pub inflation_rewards_commission_bps: u16,
    pub block_revenue_commission_bps: u16,

    /// NEW: reward amount pending distribution to stake delegators
    pub pending_delegator_rewards: u64,

    /// NEW: compressed bls pubkey for alpenglow
    pub bls_pubkey_compressed: Option<[u8; 48]>

    pub votes: VecDeque<LandedVote>,
    pub root_slot: Option<Slot>,

    /// UPDATED: serialization structure of the AuthorizedVoters map is
    /// unchanged but will now contain entries for the previous epoch.
    pub authorized_voters: AuthorizedVoters,

    /// REMOVED
    /// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,

    pub epoch_credits: Vec<(Epoch, u64, u64)>,
    pub last_timestamp: BlockTimestamp,
}

Como parte da atualização, os valores de comissão serão armazenados em pontos-base. No entanto, a instrução UpdateCommission existente no Vote Program aceita apenas valores inteiros de porcentagem para a comissão. Até que a SIMD-0291: Taxa de comissão em pontos-base seja adotada, as taxas de comissão continuarão limitadas a porcentagens inteiras. Portanto, por enquanto, os cálculos de comissão devem continuar usando valores percentuais inteiros.

As ferramentas ou os programas existentes que leem o estado de voto, incluindo o programa de stake, serão atualizados para oferecer suporte à nova versão da conta de voto.

Atualizações de comissão com atraso

A segunda atualização controlada por feature gate importante para operadores de validadores é a SIMD-0249: Adiar atualizações de comissão. Essa mudança permite que os validadores enviem atualizações de comissão a qualquer momento, garantindo que elas só entrem em vigor após pelo menos uma época completa.

O programa de voto será modificado para remover a restrição atual que impede aumentos de comissão durante a primeira metade de uma época. Em vez de limitar quando uma mudança de comissão pode ser enviada, o protocolo impõe um atraso antes de sua ativação. Isso significa que os validadores podem ajustar livremente as taxas de comissão, mas precisam esperar pelo menos uma época completa para que a nova taxa entre em vigor.

Esse atraso também beneficia os delegadores de stake, dando a eles uma época completa de antecedência para reagir às futuras mudanças de comissão. Mais importante: ele impede o “golpe da comissão”, prática em que validadores mal-intencionados aumentam temporariamente suas comissões para 100% pouco antes do limite de uma época para capturar as recompensas e voltam rapidamente ao valor normal logo depois.

Redução da garantia de estado (aluguel)

Os altos requisitos de garantia de estado, geralmente chamados de “aluguel”, continuam sendo uma das principais limitações de escalabilidade de longo prazo para desenvolvedores da Solana. Hoje, as garantias de estado na mainnet são caras: o armazenamento custa cerca de US$ 1 milhão por gigabyte. Por exemplo, criar uma única conta de token nova (ATA) exige pouco mais de 0,002 SOL, o que, nos preços atuais, equivale a aproximadamente US$ 0,25. Isso torna airdrops diretos de tokens em grande escala proibitivamente caros e cria obstáculos para micropagamentos e aplicações de pagamento com stablecoins, que precisam subsidiar a criação de contas de token ou repassar esse custo aos usuários finais.

Um primeiro passo para reduzir esse encargo é a SIMD-0194: Descontinuar o limite de isenção de aluguel, programada para ativação no ciclo de lançamento do Agave 3.1. Isso marca o início de um esforço mais amplo para reduzir e simplificar significativamente os custos de armazenamento, permitindo que aplicações alcancem milhões de usuários sem requisitos proibitivos de capital relacionados ao estado. Além disso, mais três SIMDs estão em desenvolvimento para tratar diretamente dos custos de garantia de estado e reduzir ainda mais o aluguel.

A SIMD-0194 simplifica futuras atualizações do aluguel. Hoje, calcular se uma conta é isenta de aluguel é relativamente caro para programas on-chain. O cálculo atual de `Rent::minimum_balance` usa matemática de ponto flutuante (f64) e consome cerca de 256 unidades de computação por chamada. Com a SIMD-0194, esse valor cai para apenas 8 CUs ao remover as operações de ponto flutuante da lógica de isenção de aluguel.

Isso é obtido com a descontinuação do campo exempt_threshold (f64), eliminando a necessidade de os programas realizarem cálculos de ponto flutuante ao determinar o status de isenção de aluguel.

Como parte da mudança, lamports_per_byte_year passa a se chamar lamports_per_byte, e o valor padrão é duplicado de 3480 para 6960, refletindo o fato de que a isenção de aluguel historicamente é definida pela manutenção do equivalente a dois anos de aluguel. É importante destacar que essa atualização não altera o valor necessário para que uma conta seja isenta de aluguel; ela apenas simplifica e padroniza como esse valor é representado e calculado.

A atualização é totalmente retrocompatível, e os programas já implantados não serão afetados.

Próximos passos: SIMD-0437

Entre as outras SIMDs relacionadas a aluguel esperadas para este ano, a mais relevante é a SIMD-0437: Reduzir gradualmente `lamports_per_byte` para 696. Essa proposta apresenta um cronograma estruturado para reduzir os custos de garantia de estado de longo prazo, diminuindo gradualmente `lamports_per_byte` de 6960 para 696, uma redução de 10x.

A SIMD-0437 substitui a SIMD-0436 anterior, que propunha uma única redução de 50%. Em vez disso, a SIMD-0437 introduz um cronograma de redução mais granular em cinco etapas: 6333 → 5080 → 2575 → 1322 → 696.

Dividir a mudança em várias fases permite que a rede observe e avalie o crescimento do estado ao longo do tempo, além de separar as reduções mais controversas em etapas distintas para facilitar a discussão e a governança.

Outras atualizações relevantes do ciclo de lançamento do Agave 3.1

Aplicação rigorosa de 32 shreds de dados e 32 shreds de codificação

Hoje, o Turbine aceita uma quantidade variável de shreds por conjunto FEC. Esse comportamento adiciona complexidade desnecessária sem oferecer benefícios significativos. A validação dos índices dos shreds fica mais difícil porque os receptores precisam dos shreds de codificação para determinar os limites dos índices. A futura ativação do feature gate da SIMD-0317: Exigir 32 shreds de dados + 32 shreds de codificação padroniza esse comportamento ao exigir exatamente 32 shreds de dados e 32 shreds de codificação por conjunto FEC. Essa mudança também fortalece a detecção de equivocation, que futuramente orientará mecanismos de aplicação como penalidades de slashing.

Limites estáticos de instruções

Hoje, transações com mais de 64 instruções de nível superior passam pelas verificações iniciais de sanitização, mas falham em runtime. Isso gera trabalho desnecessário para o scheduler, pois permite que transações destinadas a falhar entrem no pipeline e consumam seus recursos.

A futura ativação do feature gate da SIMD-0160: Limite estático de instruções resolve o problema ao aplicar o limite de 64 instruções durante a sanitização da transação. Com essa mudança, qualquer transação que exceda 64 instruções de nível superior (incluindo chamadas de CPI) falhará na sanitização e será rejeitada imediatamente.

Menos rodadas de ChaCha no Turbine

A SIMD-0332: Reduzir as rodadas de ChaCha do Turbine de 20 para 8 oferece uma melhoria pequena, mas relevante, no desempenho da propagação de dados de bloco pelo Turbine. Hoje, o Turbine usa ChaCha20 para embaralhar de forma determinística os validadores ponderados por stake ao construir árvores de propagação de blocos. Essa ordem aleatória é importante para impedir ataques de censura, mas adiciona overhead computacional.

As rodadas de ChaCha funcionam como um embaralhador determinístico, em que cada rodada aplica transformações para tornar a saída ainda mais aleatória. Mais rodadas oferecem maior segurança criptográfica, mas também aumentam o custo computacional.

Com a transição do Agave para XDP, os envios de retransmissão se tornaram quase instantâneos, o que significa que a etapa de embaralhamento ponderado agora domina o tempo de execução. Com cerca de ~1 microssegundo por shred, reduzir o embaralhamento de ChaCha20 para ChaCha8 mantém o processo suficientemente aleatório para resistir à censura e evita que ele se torne um gargalo.

Novo ponteiro para dados de instrução

Hoje, programas sBPF precisam analisar a seção de contas da região de entrada serializada para localizar os dados de instrução. Como o layout de serialização posiciona as contas antes dos dados de instrução, os programas precisam percorrer todas as entradas de contas antes de chegar ao segmento de dados de instrução. Isso impõe trabalho desnecessário aos programas que operam principalmente (ou exclusivamente) com dados de instrução.

A futura ativação do feature gate da SIMD-0321: Ponteiro para dados de instrução no registrador 2 da VM melhora esse processo ao fornecer um ponteiro de 64 bits para os dados de instrução no registrador r2 da VM no ponto de entrada do programa. Esse ponteiro referencia diretamente o início da seção de dados de instrução na região de entrada, permitindo que os programas acessem esses dados imediatamente, sem antes analisar a seção de contas. Isso reduz o consumo de unidades de computação ao eliminar o overhead da análise.

Observação de compatibilidade: esse recurso só é retrocompatível com programas que atualmente não leem r2 no ponto de entrada. Qualquer programa que dependa incorretamente do valor não inicializado/lixo anteriormente presente em r2 no ponto de entrada deixará de funcionar quando esse recurso for ativado.

Melhorias de RPC

O endpoint RPC getProgramAccounts agora retorna erros JSON-RPC adequados quando filtros malformados são fornecidos. Antes, filtros inválidos eram ignorados silenciosamente, fazendo com que a chamada RPC recorresse a uma consulta sem filtros, o que muitas vezes gerava solicitações inesperadamente caras e carga desnecessária nos nodes RPC. Com essa melhoria, filtros inválidos agora retornam um erro claro, evitando consultas acidentais que consomem muitos recursos e facilitando significativamente a depuração.

Além disso, falhas de verificação de assinatura em simulateTransaction() e na etapa de preflight de sendTransaction() agora serão retornadas como TransactionError::SignatureFailure no campo err do resultado da simulação, em vez de serem lançadas como um erro da API JSON-RPC (-32003).

Como resultado, aplicações que antes dependiam da captura de exceções JSON-RPC para falhas de verificação de assinatura agora devem esperar que esses erros apareçam diretamente na resposta da simulação. Aplicações que já materializam e tratam valores TransactionError nos resultados de simulação agora podem esperar receber TransactionError::SignatureFailure nesses pontos de verificação.

Conclusão

O Agave v3.1 é uma atualização significativa do cliente que oferece diversos ganhos e otimizações de desempenho, incluindo menos I/O de disco, processamento mais rápido de transações e melhor tratamento de erros de RPC. O Agave avançou de forma perceptível no fortalecimento da rede, com maior resiliência em condições adversariais. Esta versão também marca o primeiro passo rumo a reduções significativas nas garantias de estado.

A Anza continua se diferenciando como a única equipe de desenvolvimento central do setor que entrega melhorias em toda a stack, incluindo o envio de patches para o kernel do Linux. Com o Agave 3.1 prestes a impulsionar a rede, a Solana continua demonstrando sua capacidade de escalar.

Olhando adiante, o próximo marco é o Agave 4.0 e o lançamento do Alpenglow na testnet, atualmente programado para o início de maio.

Recursos adicionais

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