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

Introdução

Com o Agave 4.0, o principal cliente validador da Solana dá mais um passo à frente, aprimorando os principais fluxos de desempenho enquanto prepara a rede para blocos maiores e para a tão aguardada atualização de consenso Alpenglow.

Principais atualizações do ciclo de lançamento do Agave 4.0

• XDP acelera drasticamente a retransmissão do Turbine
• Replay Stage com menor latência
• Preparação para o Alpenglow: marcadores de transferência rápida de líder e validação encadeada de ID de bloco*
• Suporte criptográfico ampliado: aritmética G2 e syscalls BLS12-381*
• Serialização aprimorada com Wincode
• Aumento da delegação mínima de stake com o Stake Program v5*
• Reativação do programa de provas ZK ElGamal*
• Suporte a programas SBPFv3*

* atualizações controladas por feature gates

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

No momento da publicação, o Agave v4.0.0-rc.0 é considerado um candidato a atualização da mainnet (MUC), e a Anza busca voluntários para ajudar o lançamento a alcançar 25% do stake. Validadores: é hora de atualizar!

XDP pronto para adoção mais ampla

XDP (abreviação de eXpress Data Path) é o caminho de rede de alto desempenho usado pelo Agave para acelerar o Turbine. Ele permite que o Agave carregue um programa eBPF próximo à placa de interface de rede, permitindo que o tráfego de shreds ignore grande parte do fluxo padrão de processamento de pacotes do Linux.

Isso é importante porque o Turbine se torna o principal gargalo à medida que a Solana avança para limites de bloco maiores. Os líderes precisam distribuir shreds para centenas de pares, e os grandes validadores já podem chegar a 150.000 pacotes de saída por segundo nas condições atuais. Conforme a rede avança em direção à meta de longa data de blocos com 100 milhões de CUs, o desempenho do envio e da retransmissão de pacotes precisa acompanhar a capacidade de execução. O XDP cria essa margem ao tornar a propagação de blocos imensamente mais rápida.

Com o Agave 4.0, o XDP agora está pronto para uma adoção mais ampla entre os validadores. Ele passou por testes de estresse em várias configurações, recebeu mais reforços e passou por melhorias adicionais de roteamento. Os resultados em produção são extremamente animadores, com a retransmissão do Turbine várias ordens de grandeza mais rápida.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

22 de abr. de 2026, 5:25 AM

Para entender melhor por que o XDP representa uma melhoria tão significativa, confira nossa entrevista anterior com o engenheiro da Anza, Alessandro Decina.

Replay Stage mais rápido

O Agave 4.0 acelera o replay ao remover duas etapas custosas de verificação do caminho crítico das threads de replay. Na v4.0, a verificação de entradas e a verificação de assinaturas de transações são executadas de forma assíncrona, permitindo que o replay continue processando enquanto tarefas em segundo plano confirmam a validade do slot.

A primeira mudança transfere a verificação de entradas PoH para segundo plano. Antes, o replay verificava em linha a cadeia de hashes das entradas antes de continuar. Uma segunda mudança aplica a mesma ideia às assinaturas de transações, mas com uma divisão importante: agora, o Agave separa a verificação do hash e da mensagem da transação da verificação da assinatura Ed25519. O caminho do hash ainda é executado primeiro para que as transações possam ser sanitizadas e executadas com segurança, enquanto as verificações de assinatura, mais custosas, são realizadas em segundo plano e reunidas antes que o bloco seja aceito.

Na prática, isso deixa o estágio de replay muito menos bloqueado, principalmente em slots movimentados, nos quais as verificações de assinatura crescem de acordo com o número de transações.

Maior adoção do Wincode

Wincode é uma biblioteca de serialização e desserialização desenvolvida pela Anza, criada para inicialização no local e gravações diretas na memória, minimizando o uso de buffers intermediários. Ela oferece desempenho de alto nível entre os serializadores Rust, mantendo compatibilidade total com o bincode, que é mais popular.

No Agave 4.0, mais caminhos de serialização críticos para o desempenho estão migrando do bincode para o wincode. Como quase todos os dados gravados em disco ou enviados pela rede na Solana dependem do bincode, a otimização desses caminhos gera um impacto amplo.

Aumento da delegação mínima de stake (Stake Program v5)

Uma atualização significativa do Stake Program chega com o Agave 4.0. Essa mudança controlada por feature gate, descrita na SIMD-0490, prepara a iniciativa mais ampla da Solana para reduzir os depósitos de stake, também conhecidos como rent.

A mudança mais importante é que a delegação mínima de stake aumenta de 1 lamport para 1 SOL. Isso evita que o custo de criação e manutenção de contas de stake fique baixo demais à medida que os requisitos de rent diminuem, o que poderia criar um possível vetor de ataque. Embora existam muitas contas de stake menores abaixo desse limite, elas representam apenas 0,02% do stake ativo total e serão mantidas pelas regras anteriores quando a atualização entrar em vigor.

A atualização também simplifica várias partes do processamento de contas de stake. Ela passa a usar a sysvar Rent nos cálculos de rent, em vez de depender do rent_exempt_reserve armazenado em cada conta, torna opcionais as entradas de contas sysvar nas operações do programa de stake e reescreve a implementação de Split para corrigir casos extremos antigos. 

A comunidade de operadores de validadores demonstrou estar confortável com o novo mínimo de 1 SOL. Ferramentas e dapps que interagem com o programa de stake precisarão verificar sua lógica para considerar o novo mínimo.

Suporte criptográfico aprimorado 

Diversas ativações de recursos ao longo do ciclo de lançamento do Agave 4.0 buscam ampliar os recursos criptográficos nativos da Solana, oferecendo melhor suporte a casos de uso modernos, incluindo provas ZK e assinaturas BLS.

Reativação do programa de provas ZK ElGamal

O programa de provas ZK ElGamal é um programa nativo da Solana que verifica provas de conhecimento zero usadas em transferências confidenciais do Token-2022, permitindo validar saldos e transações criptografados sem revelar os dados subjacentes. Ele funciona como um verificador generalizado de provas criptográficas baseadas em ElGamal, compondo uma parte essencial da funcionalidade de tokens com preservação de privacidade da Solana. 

O programa foi desativado na mainnet após um incidente de segurança em junho de 2025, no qual uma falha na lógica de verificação de provas — especificamente, a ausência de um elemento no hash da transcrição Fiat-Shamir — possibilitava a criação de provas forjadas que poderiam passar pela verificação. Embora nenhum exploit tenha sido observado em uso real, o possível impacto levou à desativação do programa por meio de um feature gate e à suspensão das transferências confidenciais até a conclusão das correções e auditorias. Com os problemas resolvidos e a implementação reforçada, o programa agora está previsto para ser reativado na mainnet.

Aritmética G2 para alt_bn128

A SIMD-0302: adicionar syscalls G2 de alt_bn128 amplia as syscalls criptográficas BN254 (alt_bn128) existentes na Solana para oferecer suporte a operações nativas sobre pontos da curva G2, incluindo adição, subtração e multiplicação escalar. G1 e G2 são os dois grupos de curvas elípticas usados em criptografia baseada em emparelhamento, com G2 definido sobre um campo de extensão maior.

Isso preenche uma lacuna importante no conjunto atual de syscalls, que se concentra principalmente em operações G1, e viabiliza um suporte mais completo à criptografia baseada em emparelhamento diretamente onchain, principalmente em casos de uso como verificação de assinaturas BLS e sistemas avançados de provas ZK.

Sem suporte nativo a G2, alguns projetos recorreram a implementações personalizadas, como a solana-alt-bn128-bls, uma biblioteca completa de assinaturas BLS criada por Dean Little, da Blueshift, sobre as syscalls existentes. Habilitar operações G2 no nível das syscalls eliminaria a necessidade dessas soluções alternativas, facilitando a criação de protocolos criptográficos prontos para produção de forma nativa na Solana.

Suporte a little-endian para alt_bn128

A SIMD-0284: adicionar compatibilidade little-endian para alt_bn128 amplia as syscalls criptográficas alt_bn128 existentes na Solana para oferecer suporte a formatos de entrada e saída little-endian. Antes, essas syscalls aceitavam apenas a codificação big-endian, criando obstáculos para desenvolvedores que usavam ferramentas e bibliotecas, principalmente do ecossistema Ethereum, já que a maioria das equipes de ZK na Solana usa ark-bn254, que opera em little-endian. A mudança é retrocompatível e amplia o suporte a casos de uso existentes que envolvem operações de curvas elípticas em alt_bn128.

Syscalls BLS12-381

Por fim, a SIMD-0388: syscalls BLS12-381 introduz suporte nativo a operações criptográficas na curva elíptica BLS12-381, disponibilizando aos programas da Solana uma curva moderna, compatível com emparelhamento e com segurança de 128 bits. Até agora, a Solana dependia da BN254 (alt_bn128) para criptografia baseada em emparelhamento, que não atende a esse padrão de segurança e limita a compatibilidade com outros ecossistemas amplamente adotados, como o Ethereum.

Em vez de introduzir uma interface de syscall totalmente nova, essa atualização amplia as syscalls de curva existentes com novos identificadores para operações G1 e G2 da BLS12-381. Isso permite que os desenvolvedores realizem aritmética de grupo, validação de pontos, descompactação e verificações de emparelhamento em lote usando uma interface conhecida, ao mesmo tempo que amplia significativamente os recursos criptográficos.

Além das melhorias gerais para provas de conhecimento zero e verificação de assinaturas BLS, este trabalho também é um recurso essencial para o consenso Alpenglow. Especificamente, ele permite que os validadores verifiquem provas de posse BLS onchain, evitando ataques de chaves maliciosas. Isso nos leva à próxima seção.

Preparação para o Alpenglow

As syscalls BLS12-381 são apenas uma das várias ativações de feature gates ao longo do ciclo de lançamento do Agave 4.0 que estabelecem as bases para a atualização de consenso Alpenglow. Abaixo estão outras ativações que contribuem para o lançamento, atualmente programado para chegar à mainnet no terceiro trimestre de 2026 junto com o Agave 4.1.

Validação encadeada de ID de bloco

A SIMD-0340: validar ID de bloco encadeado define como os validadores devem verificar a ancestralidade dos blocos para garantir uma cadeia canônica e consistente tanto no consenso TowerBFT quanto no Alpenglow. Como os números de slot não identificam blocos de forma exclusiva, principalmente em casos de equivocation, quando vários blocos podem ser produzidos para o mesmo slot, os clientes não podem depender da ordem dos slots para determinar a relação correta entre pai e filho.

Essa mudança introduz regras explícitas de validação da cadeia para garantir que cada bloco referencie corretamente seu pai, evitando divergências e ajudando a rede a convergir para um único histórico. No TowerBFT, isso é aplicado exigindo que os conjuntos FEC referenciem a raiz de Merkle do pai dentro dos slots e entre eles. O Alpenglow usa uma estrutura de raiz de Merkle dupla sobre todos os conjuntos FEC de um slot. Se essas verificações falharem, o bloco, ou slot, será marcado como inativo. A aplicação dessas regras reforça a segurança do consenso e garante que os validadores possam se recuperar após receber blocos incorretos ou conflitantes.

Marcadores de transferência rápida de líder

A SIMD-0337: marcadores para transferência rápida de líder no Alpenglow define regras explícitas de sinalização que permitem aos validadores determinar quando um slot pai está totalmente concluído e é seguro construir sobre ele, um pré-requisito para transições rápidas de líder. A mudança introduz requisitos mais rígidos de posicionamento para DATA_COMPLETE_SHRED e um novo marcador “parent ready”, garantindo que a integridade de um bloco possa ser detectada de forma inequívoca no próprio fluxo de shreds.

Atualmente, a ambiguidade sobre se um slot foi totalmente transmitido pode atrasar o próximo líder, pois ele talvez precise aguardar shreds adicionais ou correr o risco de construir sobre dados incompletos. Ao padronizar como a conclusão é sinalizada, essa mudança permite que o próximo líder comece a produzir blocos mais cedo e com confiança, sem coordenação adicional nem suposições.

Esse é um componente essencial do design de transferência rápida de líder do Alpenglow, no qual minimizar o intervalo entre líderes melhora diretamente a capacidade de processamento da rede.

Atualização do modelo de custo das transações de voto

A SIMD-0458: interromper o uso do custo estático de transações SimpleVote elimina o uso de um custo fixo em CUs para transações de voto, alinhando-as ao modelo padrão de custo de transações usado para transações que não são de voto. 

Atualmente, as transações de voto simples recebem uma cobrança constante de 3.428 CUs, com base em suposições antigas sobre o custo determinístico de execução. Com o novo modelo, as transações de voto serão medidas dinamicamente como qualquer outra transação, tornando a contabilização de custos mais consistente e eliminando a necessidade de um limite separado de CUs de voto.

Embora o consumo real de CUs em runtime para transações de voto permaneça o mesmo, a forma como elas são contabilizadas durante o empacotamento de blocos muda. Especificamente, os votos agora incluirão cerca de ~16 mil CUs estimadas adicionais, como custos de carregamento dos dados da conta, resultando em reservas iniciais de CUs maiores quando os líderes constroem blocos.

Essa mudança sucede a SIMD-0387 (gerenciamento de chave pública BLS na conta de voto), que eliminou a suposição de que o programa Vote tem um perfil de execução estático.

Outras atualizações importantes

Outros destaques do ciclo de lançamento do Agave 4.0 incluem suporte ao programa SBPFv3, a capacidade de criar contas pré-financiadas e I/O direto para descompactar snapshots.

Suporte a programas SBPFv3

O ciclo de lançamento do Agave 4.0 inclui um feature gate que permite a implantação e a execução de programas SBPFv3. O Solana Berkeley Packet Filter (SBPF) é o fork baseado em Rust do eBPF da Solana: o formato de bytecode de baixo nível e a máquina virtual para os quais os programas onchain são compilados antes da execução. Essa atualização reúne o trabalho descrito em três SIMDs: SIMD-0178, SIMD-0189 e SIMD-0377. 

A SIMD-0178 introduz syscalls estáticas, permitindo que as referências a syscalls sejam resolvidas no momento da vinculação, em vez de por meio de realocações ELF em runtime. Atualmente, essas realocações tornam o carregador de programas mais complexo; removê-las simplifica a execução e reduz o risco de segurança.

A SIMD-0189 torna mais rígido o layout ELF permitido para programas, exigindo uma estrutura de arquivos mais estrita para que os validadores tenham menos casos extremos para analisar e menos dados inesperados para processar. Isso deve ser transparente para os desenvolvedores, pois espera-se que o conjunto de ferramentas do linker gere binários compatíveis automaticamente.

Por fim, a SIMD-0377 atualiza a máquina virtual SBPF para alinhá-la melhor ao conjunto moderno de instruções eBPF gerado pelo LLVM, incluindo suporte a instruções adicionais, como operações de salto de 32 bits. O objetivo é tornar a VM da Solana mais compatível com as ferramentas upstream e permitir que os programas sejam compilados em bytecode mais eficiente. Para os desenvolvedores, o resultado prático é um carregamento mais rápido dos programas, uma superfície de ataque menor e a possibilidade de reduzir o uso de computação sem alterar a lógica da aplicação.

Criação de contas pré-financiadas

A SIMD-0312: CreateAccountAllowPrefund está programada para ser ativada na mainnet durante o ciclo de lançamento do Agave 4.0. Ela introduz uma nova instrução no programa de sistema que elimina o requisito de que contas recém-criadas comecem com saldo zero em lamports. Isso permite que as contas sejam pré-financiadas antes da criação, simplificando um fluxo de trabalho comum para desenvolvedores e reduzindo instruções desnecessárias.

Antes, a instrução CreateAccount falhava se a conta de destino já tivesse lamports. Por isso, os desenvolvedores precisavam dividir a inicialização da conta em várias etapas, normalmente uma transferência seguida de allocate e assign, o que aumenta a complexidade e adiciona custos computacionais. Esse padrão é especialmente comum em programas que financiam contas antecipadamente.

A nova instrução consolida essas etapas em uma única chamada ao permitir que contas pré-financiadas sejam inicializadas diretamente. Na prática, isso reduz a sobrecarga de CPI e pode economizar milhares de unidades de computação em fluxos comuns, oferecendo aos desenvolvedores um caminho mais simples e eficiente. Como isso é introduzido como uma nova instrução, em vez de uma modificação das instruções existentes, a retrocompatibilidade é total.

I/O direto para descompactar snapshots 

O Agave 4.0 passa a usar I/O direto por padrão na descompactação de snapshots, em vez de encaminhar as gravações de snapshots pelo cache de páginas do sistema operacional, melhorando o tempo de inicialização e o desempenho da restauração de snapshots. Isso é especialmente útil porque os dados dos snapshots normalmente são transmitidos diretamente para o disco e não precisam remover da memória os dados de validador acessados com mais frequência. Os operadores podem desativar essa opção com --no-accounts-db-snapshots-direct-io caso o sistema de arquivos não seja compatível com O_DIRECT. Espera-se que o I/O direto seja ampliado para a criação de snapshots em uma versão futura. 

Conclusão

O Agave v4.0 é uma atualização substancial do cliente que oferece diversos aprimoramentos de desempenho e otimizações de runtime. Essas mudanças foram projetadas para tornar a rede mais rápida, segura e fácil de usar como base de desenvolvimento.

O próximo marco será o Agave 4.1 e a atualização de consenso Apenglow.

Outros recursos

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