Atualização do Agave v2.3: tudo o que você precisa saber

Introdução

A versão v2.3 do cliente validador Agave representa mais um avanço significativo para a Solana. Assim como nas atualizações anteriores, esta nova versão apresenta melhorias essenciais para aprimorar o desempenho da rede e a experiência do desenvolvedor.

Principais atualizações do Agave 2.3 

• Novo cliente TPU tpu-client-next
• Otimizações no AccountsDB com redução no uso de E/S de disco
• Cronograma de líderes agora indexado pelas contas de voto dos validadores
• Verificação de eventos passíveis de penalização
• Agendador guloso ativado por padrão
• Melhorias nos snapshots
• Atualizações no gossip
• Transições de época mais rápidas

Cada seção deste artigo é independente, permitindo que você avance facilmente para os tópicos mais relevantes. Seja você operador de validador, desenvolvedor ou usuário ativo, este guia completo do Agave 2.3 oferece os principais insights necessários para aproveitar ao máximo as melhorias mais recentes.

A Anza está acelerando o ritmo de lançamentos do Agave. Menos de três meses após a versão 2.2, a versão 2.3 já está em produção, com 13% do stake total atualmente executando versões do novo cliente. A expectativa é que a adoção cresça rapidamente nas próximas semanas. Enquanto isso, as ativações de feature gates na mainnet foram temporariamente pausadas durante a implantação e serão retomadas em breve como parte da sequência de ativação planejada.

Novo cliente TPU

O Agave 2.3 apresenta uma nova implementação do cliente da Transaction Processing Unit (TPU), substituindo o ConnectionCache anterior. Esse cliente TPU é responsável por enviar transações serializadas aos validadores pela rede usando o protocolo QUIC. O novo design, conhecido como tpu-client-next, foi totalmente reformulado para melhorar significativamente o desempenho, reduzir o uso de recursos e simplificar a arquitetura geral.

O cliente TPU é usado em dois cenários principais: no ForwardingStage, em que os validadores encaminham transações ao próximo líder, e no SendTransactionService, usado por RPCs para retransmitir transações ao líder.

A implementação anterior, ConnectionCache, foi criada para oferecer suporte aos protocolos UDP e QUIC, o que a tornava desnecessariamente complexa. O ConnectionCache usava uma fila assíncrona interna para armazenar transações, em vez de um canal explícito, e incluía uma lógica de aquecimento de cache que enviava pacotes vazios. Ela também apresentava problemas persistentes relacionados ao gerenciamento de endpoints do Quinn (ou seja, uma implementação de QUIC em Rust).

O novo tpu-client-next resolve esses problemas com um design assíncrono e simplificado. Internamente, ele segue um modelo baseado em agentes, no qual tarefas de trabalho individuais processam cada conexão QUIC. Esses workers se comunicam com um ConnectionWorkersScheduler centralizado usando canais assíncronos. 

Quando o agendador recebe um lote de transações, ele o transmite ao conjunto apropriado de workers de acordo com a estratégia configurada. A arquitetura elimina completamente o multistreaming, reduzindo a fragmentação do tráfego. As conexões também são pré-estabelecidas, eliminando a latência associada à abertura de novos streams no momento do envio.

O tpu-client-next apresenta ganhos claros de desempenho. 

• Em experimentos com RPC na testnet, os clientes antigo e novo atingiram TPS médios semelhantes sob carga; no entanto, o tpu-client-next apresentou uma variação perceptivelmente menor. 
• Em casos de uso de validadores, o ForwardingStage obteve um aumento de 10% no volume de transações encaminhadas, acompanhado por padrões de tráfego mais estáveis e uma redução de 30% no uso de CPU.
• A ferramenta de teste de estresse de código fechado da Anza, transaction-bench, foi criada usando o cliente mais recente. Ela gera o dobro de transações por segundo em comparação com a ferramenta de benchmark anterior, bench-tps.

O tpu-client-next é totalmente retrocompatível e agora é a implementação padrão para nós Agave. Se surgirem problemas, os operadores poderão reverter ao comportamento anterior iniciando o nó com a flag --use-connection-cache para restaurar a implementação antiga.

Em resumo, o tpu-client-next oferece:

• Uma arquitetura compatível com operações assíncronas e baseada em agentes
• Tráfego consistente com menor variação
• Menor uso de CPU e memória
• Políticas configuráveis de agendamento e enfileiramento
• Integração simplificada e uma superfície de API mais limpa

Cronograma de líderes indexado por contas de voto

Como parte do ciclo de lançamento do Agave 2.3, a Solana ativará a SIMD-0180: usar o endereço da conta de voto como chave do cronograma de líderes. Essa mudança altera a forma como a rede determina quais validadores estão programados para produzir blocos, substituindo os endereços de identidade dos validadores pelos endereços das contas de voto como chave principal do cronograma de líderes.

Essa migração resolve uma ambiguidade antiga no protocolo da Solana: a impossibilidade de associar de forma confiável um validador produtor de blocos a um stake específico. No design atual, o cronograma de líderes é indexado pelos endereços de identidade dos validadores. No entanto, várias contas de voto podem delegar ao mesmo endereço de identidade de validador, dificultando o rastreamento da produção de blocos de um slot específico até um conjunto específico de stake delegado.

Ao indexar o cronograma de líderes pelos endereços das contas de voto, essa mudança estabelece uma ligação clara e direta entre o stake delegado e a função de liderança do validador. Essa modificação aparentemente pequena viabiliza vários recursos importantes.

Primeiro, ela fornece a base necessária para a distribuição de recompensas por bloco, conforme especificado na SIMD-0123, que foi aprovada em uma votação formal de governança em março. Isso permite que os validadores definam uma taxa de comissão sobre as tarifas dos blocos e distribuam a receita restante proporcionalmente entre os delegadores. Esse sistema reproduz o modelo de compartilhamento de recompensas já usado para recompensas inflacionárias de staking, promovendo um maior alinhamento dos incentivos econômicos entre validadores e seus stakers.

Segundo, usar endereços de contas de voto para indexar o cronograma de líderes é essencial para viabilizar a penalização programática, que pune validadores que violam as regras da rede ao enviar blocos duplicados ou votar em vários forks. Isso nos leva à próxima atualização.

Verificação de eventos passíveis de penalização

A penalização é um mecanismo para punir validadores mal-intencionados, verificando a má conduta on-chain e queimando uma parte do stake delegado a eles. Ela funciona como um importante fator de dissuasão contra comportamentos que ameaçam a segurança ou a estabilidade da rede.

Existem dois modelos principais de penalização:

Penalização social (sistema atual da Solana)

Atualmente, a Solana depende de uma abordagem de consenso manual e orientada pela comunidade, chamada de penalização social. Nesse modelo, se um validador agir de forma mal-intencionada — por exemplo, comprometendo a disponibilidade ou a segurança da rede —, os participantes honestos poderão se coordenar off-chain para iniciar um hard fork, reiniciar a rede e penalizar o stake do infrator. Embora esse método permita uma avaliação flexível de cada caso, ele gera uma sobrecarga significativa de coordenação e é inerentemente reativo.

Penalização programática (penalização no protocolo)

Em contraste, a penalização programática é aplicada inteiramente on-chain. Se um validador violar as regras do protocolo, uma prova criptográfica da infração poderá ser enviada a um programa dedicado, que acionará a penalização automaticamente. Esse modelo reduz a dependência da coordenação humana e permite punir infrações menores sem interromper as operações da rede, abrindo caminho para uma responsabilização descentralizada e escalável.

A penalização envolve duas etapas principais:

• Detecção e atribuição da falha: identificar a conduta indevida e o validador responsável.
• Aplicação da penalidade: punir economicamente o infrator por meio da redução do stake e responsabilizá-lo.

Como parte do ciclo de lançamento do Agave 2.3, a Solana ativará uma feature gate para o Slashing Program, conforme descrito na SIMD: SIMD-0204: verificação de eventos passíveis de penalização. Isso representa o primeiro passo para viabilizar a penalização programática na Solana, com foco na detecção e atribuição de falhas. A atualização apresenta um programa on-chain que permite a qualquer pessoa denunciar e registrar comportamentos passíveis de penalização, estabelecendo a base para uma aplicação automatizada no futuro.

Esse programa não altera stakes nem recompensas; ele apenas verifica e registra infrações, funcionando como um registro on-chain de condutas indevidas dos validadores. Um protótipo inicial do programa foi implantado na Testnet (por exemplo, uma transação DuplicateBlockProof de exemplo). 

Inicialmente, o programa se concentrará em detectar e registrar a produção de blocos duplicados. No futuro, está previsto o suporte a outras violações, como o voto duplo. É importante destacar que a penalização programática está limitada a condutas indevidas que possam ser claramente comprovadas. Por isso, aplicar penalidades a problemas mais subjetivos ou sistêmicos, como a produção deliberadamente lenta de blocos ou a extração de MEV, é muito mais difícil e provavelmente não será contemplado pelo programa de penalização.

As provas enviadas incluem dois shreds conflitantes para o mesmo slot, ambos assinados pelo mesmo validador. O programa de penalização verifica a prova garantindo que os shreds formem uma prova válida de bloco duplicado, confirmando que pertencem ao mesmo slot e estão corretamente assinados pelo validador infrator. Essa lógica segue a abordagem usada no protocolo gossip da Solana para processar provas de blocos duplicados durante a escolha de forks. 

Depois que uma prova é verificada com sucesso, os resultados são armazenados em um Program-derived Address (PDA) para consulta futura. Isso facilita a criação de dashboards que exibem dados relacionados a penalizações simplesmente executando getProgramAccounts no programa de penalização. Os validadores podem usar esse recurso para verificar se foram denunciados por violações e tomar as medidas corretivas necessárias.

Uma futura SIMD tratará da aplicação econômica das penalizações, incluindo parâmetros como a redução de stake para diferentes infrações. Como essas decisões afetam a economia da operação de um validador da Solana, qualquer alteração proposta precisará ser aprovada por meio de uma votação completa de governança.

Transições de época mais rápidas

O Agave 2.3 apresenta uma grande melhoria na velocidade das transições de época. Agora, os cálculos de recompensas de época são concluídos em menos de 500 milissegundos. Isso resulta em menos slots ignorados e uma inclusão de transações mais confiável perto do limite entre épocas.

Além disso, se o primeiro slot de líder de uma nova época for ignorado, o Agave 2.3 garante que os cálculos de recompensas não sejam executados novamente. Em vez disso, os resultados calculados anteriormente são reutilizados, eliminando cálculos redundantes e permitindo um início mais fluido da nova época.

Otimizações no AccountsDB

A eficiência de armazenamento melhorou significativamente nesta versão. O uso de E/S de disco caiu aproximadamente 75%, e o volume de solicitações de reparo foi reduzido em cerca de 85%. Em conjunto, essas otimizações resultam em um desempenho mais consistente e confiável dos nós, principalmente durante períodos de alta carga na rede.

Agendador guloso ativado por padrão

No Agave 2.3, o agendador guloso agora vem ativado por padrão. O agendador central anterior frequentemente se tornava um gargalo sob cargas intensas na rede devido ao tempo necessário para ordenar as transações e construir um grafo de dependências. A abordagem gulosa mais recente acelera significativamente o agendamento de transações por meio de uma lógica simplificada e lotes menores.

Você pode saber mais sobre o agendador guloso em nosso artigo anterior no blog da Helius.

Versão de shred no gossip

O Agave 2.3 introduz uma aplicação mais rigorosa da correspondência de versões de shred na rede gossip. Agora, os nós só podem estabelecer conexões gossip de entrada se a versão de shred corresponder à do cluster, ajudando a rejeitar antecipadamente os nós configurados incorretamente.

Antes, os nós espiões podiam entrar na rede sem que sua versão de shred correspondesse à do cluster. Com essa mudança, todos os nós, inclusive os que operam no modo espião, precisam obter a versão correta de shred, seja por um ponto de entrada do cluster ou pela definição explícita na linha de comando.

Essa atualização amplia os esforços recentes para reduzir a sobrecarga do gossip. Nos últimos meses, o tráfego gossip de entrada caiu aproximadamente 61%, graças à descontinuação de três tipos de mensagens gossip e à remoção da divulgação de slots de época por validadores sem stake.

Simulações RPC incluem uso de recursos

Para oferecer mais visibilidade sobre o uso de recursos das transações, um novo campo foi adicionado ao método RPC `simulateTransaction` padrão: `loadedAccountsDataSize`. Esse campo informa o número total de bytes de dados de contas carregados durante a simulação.

Essa adição permite que os desenvolvedores estimem os custos das transações e ajustem as taxas de prioridade com mais precisão. O carregamento de dados de contas consome unidades de computação (CUs) a uma taxa de 8 CUs por 32 KB, com base no tamanho de alocação de página do heap da Solana. Ao expor essa métrica, os desenvolvedores podem otimizar melhor a eficiência de custos ao criar e enviar transações.

Melhorias nos snapshots

Os snapshots funcionam como pontos de salvamento periódicos, permitindo que os nós restaurem seu estado. Os nós geram esses snapshots continuamente, substituindo versões antigas por novas ao longo do tempo.

Esta versão apresenta várias melhorias práticas no comportamento dos snapshots:

• Intervalo padrão atualizado: o intervalo padrão de snapshots completos aumentou de 25.000 para 50.000 slots, reduzindo a frequência de criação de snapshots.
• Nova flag para desativar snapshots: uma nova flag `--no-snapshots` foi introduzida para desativar explicitamente a geração de snapshots. O método anterior, que usava `--snapshot-interval-slots 0`, agora está obsoleto.
• Comportamento aprimorado do Geyser: ao restaurar a partir de um snapshot, as notificações de contas enviadas pelo Geyser não são mais desduplicadas.

Um benefício adicional de ampliar o intervalo dos snapshots é um desempenho de disco mais estável, com redução dos picos de IOPS (operações de entrada/saída por segundo).

Melhorias na cadeia de ferramentas SBPF

O Agave 2.3 apresenta várias melhorias práticas para desenvolvedores que trabalham com a cadeia de ferramentas SBPF:

• Seleção de versão: agora, os desenvolvedores podem selecionar explicitamente versões específicas da BPF VM (v0–v3) ao compilar programas, oferecendo maior controle.
• Somente Rust no SBPFv3: a partir do SBPFv3, há suporte apenas para a cadeia de ferramentas baseada em Rust. A cadeia de ferramentas C legada não é mais compatível com versões futuras.
• Nova flag de otimização: uma nova flag de compilação `--optimize-size` foi adicionada para gerar binários de programa menores para implantação. Isso pode ajudar a reduzir o armazenamento, embora possa aumentar ligeiramente o uso de unidades de computação (CU).

Outras mudanças

Outras atualizações incluídas nesta versão:

• Recuperação automática do cluster: um novo recurso de recuperação de cluster, `wen-restart`, foi introduzido para acionar automaticamente a reinicialização do cluster em caso de falha da cadeia.
• ABI de logs atualizada: a ABI de logs `TimedTracedEvent` foi atualizada para incluir novos diagnósticos. Como resultado, os validadores precisam atualizar todas as ferramentas externas de rastreamento ou análise que dependem desses logs para garantir a compatibilidade. Os dados de rastreamento existentes devem ser apagados após a atualização para evitar incompatibilidades de formato.
• Melhorias na CLI: foi adicionado withdraw-stake AVAILABLE para simplificar a retirada de todos os lamports sem stake, e o solana-test-validator foi atualizado para vincular os serviços RPC ao localhost (127.0.0.1) por padrão, aumentando a segurança.
• Inicialização mais rápida: os tempos de inicialização dos validadores foram reduzidos significativamente. Agora, os nós levam aproximadamente 3 minutos para iniciar e carregar o ledger, e cerca de 5 minutos para alcançar a ponta da cadeia. No entanto, o fastboot agora exige um encerramento normal usando a nova flag --wait-for-exit. Os operadores devem permitir que o processo do validador seja totalmente encerrado por conta própria antes de reiniciá-lo, em vez de emitir um comando de reinicialização imediata.

Conclusão

O Agave 2.3 representa outro marco importante para o protocolo da Solana. Os principais destaques incluem o lançamento de um novo cliente TPU (`tpu-client-next`), reduções significativas na E/S de disco por meio de otimizações no AccountsDB, melhor desempenho dos snapshots, melhorias na rede gossip e transições de época e tempos de inicialização mais rápidos. Em conjunto, essas atualizações tornam a rede mais robusta e aprimoram a experiência de desenvolvedores e operadores de validadores.

A Solana continua avançando de forma consistente rumo a uma rede robusta com vários clientes, com mais de 8% do stake total executando Firedancer — e esse número continua crescendo. Quase um ano e meio de operação ininterrupta reflete a crescente maturidade e estabilidade do software central da rede. Enquanto isso, o ritmo dos lançamentos principais e secundários está aumentando.

A seguir: Agave 3.0!

Recursos adicionais

• Cronograma de lançamento do Agave 2.3
• Registro de alterações do Agave 2.3
• Pull requests do Agave 2.3
• Notas de patch do Agave 2.3 - Blog da Anza 
• Apresentação do tpu-client-next - Solana Core Community Call, 20 de junho de 2025