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

Atualizações de destaque no ciclo de lançamento do Agave 2.1 

• Amplas otimizações de desempenho
• Aumento dos limites de bloco
• Introdução do agendador guloso (experimental)
• Suporte nativo à verificação de assinaturas Secp256r1 (Atualização: adiado para o Agave 2.2)
• Desativação da cobrança de taxas de aluguel e das regravações de aluguel
• Flexibilização das restrições para falhas no carregamento de transações
• Migração dos programas de configuração e de tabelas de consulta de endereços para o BPF principal

Cada seção deste artigo foi criada para ser independente, permitindo que você navegue livremente e se concentre nos temas que mais interessam. Seja você operador de validador, desenvolvedor ou usuário ativo, esta visão detalhada do Agave 2.1 fornecerá os insights necessários para aproveitar esses avanços com eficiência.

Implementação dos recursos

No momento da redação deste artigo, 88% do stake já executa a versão 2.1.11 do Agave. As ativações de feature gates na mainnet foram temporariamente pausadas para permitir uma adoção mais ampla da v2.1 e devem ser retomadas em breve, de acordo com a ordem de ativação programada. 

A maioria dos novos recursos completos abordados nas seções seguintes ainda não está ativa e deve ser implementada ao longo do ciclo de lançamento da versão 2.1 por meio do sistema de feature gates. Os recursos são ativados em determinadas épocas com base na prioridade relativa e na ordem em que foram ativados nos clusters de testnet e devnet.

Melhorias de desempenho

Operadores de validadores e RPC relataram ganhos perceptíveis de estabilidade e desempenho com o Agave 2.1. No último ano, a Anza priorizou a eliminação de gargalos, a otimização da eficiência dos recursos e a melhoria do desempenho geral. Novas versões do cliente buscam tanto aprimorar fundamentos essenciais — aumentar a largura de banda e reduzir a latência — quanto introduzir novos recursos. Antes de entrarmos nos detalhes da atualização 2.1, vale recuar um pouco e quantificar as melhorias significativas de desempenho obtidas na sequência mais recente de atualizações do cliente.

Tempos de bloco

Tempos de bloco mais rápidos na Solana estão reduzindo o tempo médio de slot para menos de 400 ms, e as épocas recentes estão a caminho de serem concluídas em pouco menos de dois dias — o menor tempo da história da rede. Ambos os clientes estão preparados para tempos de bloco mais curtos. Essa aceleração tem implicações que vão além do aumento do volume de transações processadas. Como as recompensas de staking estão vinculadas às emissões inflacionárias, calculadas com base em "anos de época" e não em anos-calendário, validadores e participantes de staking podem se beneficiar. Um ano de época pressupõe 182,5 épocas por ano, com base na duração padrão de dois dias por época. Quando as épocas ficam mais curtas, mais delas cabem no mesmo período, aumentando efetivamente a frequência de distribuição das recompensas de staking.

Disponibilidade

A Solana demonstrou confiabilidade quase perfeita durante 2024 e o início de 2025, mantendo 100% de disponibilidade por mais de um ano. A última interrupção registrada ocorreu em 6 de fevereiro de 2024, quando um bug conhecido interrompeu temporariamente a finalização de blocos na Mainnet. O problema foi rapidamente identificado e corrigido. Desde então, a Solana tem produzido blocos sem interrupções, mesmo durante períodos de intensa atividade na rede — como o recente aumento impulsionado pelos lançamentos de tokens da família Trump — comprovando sua resiliência sob alta carga.

Taxas de slots ignorados

A taxa de slots ignorados mede a frequência com que um validador designado como líder de determinado slot deixa de produzir um bloco dentro do tempo alocado. Desde aproximadamente a época 700, em novembro de 2024, as taxas de slots ignorados caíram drasticamente. Depois de oscilarem entre 2% e 5% por vários anos, essas taxas agora estão próximas de zero para a maioria dos validadores bem otimizados.  

Um dos fatores que contribuíram para essa melhoria foi a introdução das recompensas de época particionadas na mainnet durante a época 707. Ao distribuir as recompensas de stake entre vários blocos, essa mudança reduz os gargalos de desempenho causados pela concentração da distribuição de recompensas no primeiro bloco de cada nova época, tornando a operação da rede mais fluida.

Além disso, os Timely Vote Credits (TVC), introduzidos em novembro de 2024, incentivam os validadores a votar prontamente e desestimulam votos atrasados. Ao reduzir o número de validadores que retêm votos intencionalmente, o TVC melhora a convergência do cluster, acelerando a confirmação e a finalidade. Esse mecanismo ajuda a minimizar bifurcações e reduzir sua duração. Como a pontuação do TVC agora influencia as classificações dos pools de stake, os operadores reagiram atualizando o hardware e otimizando as configurações dos validadores para melhorar o desempenho.

Transações por segundo (TPS)

Um número maior de transações por segundo (TPS) indica maior capacidade de processamento da blockchain, e o TPS sem votos da Solana (também conhecido como “TPS real”) mantém uma trajetória constante de crescimento desde o fim de 2023. Os dados mais recentes da primeira semana de fevereiro de 2025 mostram que a rede registrou uma média de 1.228 TPS no percentil 50, com o pico de desempenho no percentil 99 chegando a 2.520 TPS.  

O maior TPS de todos os tempos foi observado durante a semana do airdrop do token PENGU, encerrada em 23 de dezembro de 2024, quando o percentil 50 apresentou média de 1.260 TPS e o percentil 99 atingiu o pico de 3.252 TPS. Esse crescimento contínuo destaca a escalabilidade constante da Solana e a melhoria da eficiência no processamento de transações.

Taxas de prioridade

Por fim, uma comparação da cobrança de taxas de prioridade entre o Agave 2.1 e a versão 2.0 anterior, de 27 de janeiro a 4 de fevereiro de 2025, mostra que o Agave 2.1 cobra consistentemente taxas de prioridade um pouco maiores.

Aumento dos limites de bloco

Um aumento dos limites de bloco, proposto no SIMD-0207: aumentar o limite de bloco para 50M, está programado para o ciclo de lançamento 2.1 da Solana. Atualmente, o protocolo limita o total de recursos computacionais por bloco a 48 milhões de unidades de computação (CUs). Os limites de bloco garantem que os nós consigam acompanhar a rede ao restringir a quantidade de trabalho que um líder pode incluir em um bloco. A equipe fundadora escolheu empiricamente o limite atual com base no volume que os validadores conseguem processar de forma razoável para atingir tempos de bloco de 400 milissegundos. 

No entanto, a atividade atual da mainnet não está limitada pelos tempos de execução, o que significa que os blocos poderiam comportar mais transações sem ultrapassar a meta de 400 ms. Esta atualização introduz um aumento moderado de 4% para expandir gradualmente a capacidade da rede, elevando o limite de computação por bloco de 48M para 50M CUs. Embora um aumento mais agressivo — como dobrar o limite — possa ser viável, ele foi considerado arriscado demais para uma mudança inicial. A expansão dos limites de bloco afeta não apenas os validadores, mas também infraestruturas essenciais, como nós RPC, indexadores e serviços de arquivamento, que precisam escalar de acordo.

Os demais limites do protocolo permanecem inalterados:

• O limite de computação por conta em cada bloco permanece em 12M CUs.
• O limite máximo de computação por transação permanece em 1,4M CUs.

Outros aumentos nos limites de bloco são esperados e devem ocorrer por meio do processo formal de SIMD.

Agendador guloso

Contexto: o agendador central

A última grande atualização do agendador — o agendador central — foi introduzida no Agave 1.18 em maio do ano passado. Esse agendador constrói um grafo de dependências das N transações de maior prioridade, sendo N atualmente definido como 256. Em seguida, ele tenta agendar as transações por ordem de prioridade, garantindo que transações sem conflitos sejam processadas primeiro. Depois de agendadas, essas transações são removidas do grafo, permitindo priorizar transações que antes apresentavam conflitos. O agendador então preenche novamente o grafo para manter uma fila de N transações.

Essa abordagem foi projetada principalmente para otimizar o processamento de lotes maiores e melhorar o volume geral de transações processadas. No entanto, uma grande desvantagem é que a construção do grafo de dependências e a ordenação das transações consomem um tempo considerável, criando um gargalo. 

Consulte nosso artigo anterior no blog da Helius para obter uma visão mais detalhada do Agave 1.18 e da implementação do agendador central.

O novo agendador guloso

Ao contrário do agendador central, o agendador guloso não constrói um grafo de dependências. Em vez disso, ele adota uma abordagem mais direta:

• Primeiro, seleciona a transação de maior prioridade.
• Se a transação não entrar em conflito com um lote em andamento, ela será adicionada a uma das quatro filas de threads de trabalho.
• Se surgirem conflitos, o lote atual será finalizado e despachado, e a transação será adicionada a um novo lote.

Esse método acelera significativamente o agendamento de transações, mas resulta em lotes menores, o que aumenta a sobrecarga por transação. No entanto, em condições reais da mainnet, essa compensação vale a pena, pois o tempo de execução é dominado pelo processamento BPF, e não pela formação de lotes.

O agendador central enfrenta dificuldades sob alta carga da rede, principalmente porque precisa de tempo para ordenar as transações e construir o grafo de dependências. Ao eliminar essa sobrecarga, o agendador guloso melhora a capacidade de resposta em troca de uma menor eficiência na formação de lotes.

Considere um cenário em que as transações são divididas em três grupos de conflito: A, B e C. As transações entram em conflito quando uma delas deseja gravar em uma conta que outra deseja ler ou na qual deseja gravar. As transações em A têm taxas de prioridade maiores que as de B ou C.

• O agendador central agruparia as transações sem conflito A1, B1 e C1 em um único lote: [A1, B1, C1].
• O agendador guloso prioriza primeiro as transações com as maiores taxas, agendando A1 como um lote separado e passando para A2 no lote seguinte.

Essa priorização garante um agendamento mais rápido, mas pode resultar em lotes menores que os do agendador central.

Programa nativo para verificar assinaturas Secp256r1

A Solana está introduzindo um novo programa nativo para verificar assinaturas da curva elíptica secp256r1, viabilizando suporte on-chain para Passkeys, o padrão WebAuthn e novos modelos de abstração de contas, incluindo autenticação de dois fatores (2FA). Essa melhoria abre caminho para que a autenticação sem senha, já amplamente usada na Web2, funcione como um segundo fator de segurança on-chain.

A curva elíptica secp256r1 é uma curva criptográfica padronizada pelo NIST e conta com amplo suporte em dispositivos modernos, incluindo:

• WebAuthn: um padrão do W3C para autenticação baseada em criptografia de chave pública, compatível com todos os principais navegadores.
• Secure Enclave da Apple: um Ambiente de Execução Confiável (TEE) baseado em hardware que assina mensagens e só pode ser acessado por meio de autenticação biométrica.
• Android Keystore: uma API para gerenciar chaves privadas e métodos de assinatura, aproveitando o TEE do dispositivo para armazenar chaves com segurança.
• Passkeys: um padrão da FIDO Alliance e do W3C que substitui senhas por pares de chaves criptográficas e é compatível com criptografia de curva elíptica.

Várias outras redes, incluindo a Ethereum (EIP-7212), também exploraram a integração de suporte à curva secp256r1.

Detalhes do programa Secp256r1

O novo programa será implantado com o ID: Secp256r1SigVerify1111111111111111111111111

Estrutura da instrução:

• Um contador u8 especifica o número de assinaturas a verificar.
• Em seguida, há um único byte de preenchimento.
• Para cada assinatura, a seguinte struct serializada é usada:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Esta atualização tem origem no SIMD-0048: programa nativo para verificação de assinaturas Secp256r1, proposto pela equipe da Bunkr. O programa pré-compilado Secp256r1 SigVerify funcionará de maneira semelhante ao suporte existente da Solana para secp256k1 e às assinaturas ed25519.

Desativação da cobrança de taxas de aluguel e das regravações de aluguel

Duas atualizações relacionadas, propostas no SIMD-0084: desativar a cobrança de taxas de aluguel e no SIMD-0183: ignorar regravações de aluguel, eliminarão grande parte da sobrecarga legada associada às contas que pagam aluguel.

A cobrança de taxas de aluguel é um componente complexo do Bank. Sua desativação simplificará a base de código do cliente de validador e agilizará o desenvolvimento de todas as implementações de clientes de validador, pois eles não precisarão mais reproduzir a lógica de cobrança de aluguel. O aluguel não será mais deduzido das contas, e as taxas de aluguel cobradas não serão mais distribuídas aos validadores. Já não é possível criar novas contas que paguem aluguel — qualquer tentativa resultará em erro de transação.

Atualmente, a cobrança de aluguel verifica cada conta pelo menos uma vez por época, carregando e armazenando contas mesmo que permaneçam inalteradas. Como todas as contas da Solana já são isentas de aluguel, manter esse processo representa trabalho computacional desnecessário.

As regravações de contas relacionadas ao aluguel serão eliminadas, reduzindo o número de contas armazenadas por slot. Como resultado, os validadores terão ganhos de desempenho, pois menos contas serão incluídas nos cálculos do hash delta de contas e do hash incremental de contas. Essa mudança também reduz o tamanho dos snapshots incrementais, diminuindo ainda mais o consumo de recursos.

Flexibilização das restrições de transações: falhas de carregamento

Atualmente, as transações da Solana estão sujeitas a restrições rígidas que podem fazê-las falhar antes de serem incluídas em um bloco. Essas falhas anteriores ao bloco resultam em desperdício de computação dos validadores, pois recursos são consumidos sem gerar taxas de transação — na prática, trabalho sem remuneração.

A produção de blocos é ainda mais complicada pela necessidade de filtrar transações que invocam programas inválidos ou excedem o limite máximo de 64 MiB (~67,11 MB) de dados de contas carregados. Essas restrições aumentam a complexidade da montagem dos blocos e dificultam a determinação de sua validade. Ao flexibilizar essas restrições, as transações poderiam ser incluídas em um bloco e ter taxas cobradas sem exigir que os dados do programa fossem carregados e verificados previamente. Essa mudança busca eliminar a dependência do estado das contas para a validação de blocos.

Essas mudanças, propostas no SIMD-0191, podem afetar ferramentas como exploradores de blockchain, que pressupõem que todas as transações tentam ser executadas. Além disso, os usuários devem garantir que suas transações possam ser executadas para evitar gastos desnecessários com taxas.

Migração dos programas de configuração e de tabelas de consulta de endereços para o BPF principal

Como parte da transição em andamento de programas nativos consagrados para programas Berkeley Packet Filter (BPF), os programas Config e Address Lookup Table serão migrados para programas BPF principais. Essa mudança desvincula esses programas essenciais do runtime do validador, permitindo atualizações mais flexíveis e manutenção mais simples.

Os programas BPF são menos complexos que seus equivalentes nativos, o que simplifica o desenvolvimento e a manutenção em diferentes clientes de validador. Com essa mudança, as equipes que trabalham no Firedancer e na Anza não precisarão mais acompanhar e implementar separadamente as alterações dos programas em seus runtimes. Em vez disso, as atualizações serão aplicadas de forma universal a todos os clientes. 

Os programas reimplementados manterão ABIs idênticas às versões nativas, garantindo compatibilidade total e diferindo apenas no uso de computação.

Conclusão

A atualização do Agave 2.1 representa um grande avanço para a Solana, introduzindo melhorias importantes nos recursos e otimizações do runtime. Esta versão fortalece a rede ao ampliar a funcionalidade, aprimorar o desempenho e expandir os limites do que a Solana pode alcançar. Com suporte nativo à verificação de assinaturas Secp256r1, aumento dos limites de bloco, amplas melhorias de desempenho e a futura introdução do agendador guloso, o Agave 2.1 melhora tanto a eficiência quanto a escalabilidade. Seja você desenvolvedor, validador ou usuário ativo, esta atualização abre novas possibilidades e torna a Solana mais rápida, flexível e poderosa do que nunca.

Recursos adicionais

• Repositório do cliente Agave
• Cronograma de lançamento do Agave v2.1
• Pull requests com a tag Agave v2.1