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

Introdução

A versão principal Agave v3.0 representa outro marco para Solana e apresenta uma série de melhorias voltadas ao desempenho da rede, às operações de validadores e à experiência do desenvolvedor.

Principais atualizações do Agave 3.0 

• Reformulação do cache: processamento de transações de 30% a 40% mais rápido
• Maior limite de computação por conta: eleva o limite por conta para 40% das CUs de um bloco
• Nova struct TransactionView do agendador: melhora a eficiência do agendamento
• eXpress Data Path (XDP) para Turbine: um pré-requisito para blocos de 100 milhões de CUs
• Maior profundidade de aninhamento de CPI: eleva o limite de aninhamento de CPI de 4 para 8
• Flexibilização das restrições de entrada: simplifica a lógica de agendamento e é necessária para a execução assíncrona
• Inicialização mais rápida: os nós agora voltam a ficar online mais rapidamente
• Especificação do tamanho dos dados carregados da transação: padroniza como os dados carregados da transação são calculados
• Melhorias de RPC: atualizações em tempo real mais rápidas e confiáveis para dApps que usam PubSub WebSockets

Cada seção deste artigo é independente, permitindo que você se concentre nos temas mais relevantes. Seja você operador de validador, desenvolvedor ou membro ativo da comunidade, este guia do Agave v3.0 apresenta as principais atualizações e informações necessárias para aproveitar ao máximo as melhorias mais recentes.

Tendências relacionadas a clientes

Antes de explorar os detalhes dos novos recursos do Agave v3.0, vamos analisar como os dados recentes destacam o progresso da rede Solana e do cliente Agave, com ciclos de lançamento mais rápidos, adoção mais ampla de clientes e desempenho robusto sob pressão.

Cadência de lançamentos do Agave

A Anza acelerou significativamente sua cadência de lançamentos neste ano, reduzindo para menos de três meses o intervalo entre versões secundárias do Agave. A série Agave 2.2.* permaneceu como a versão da supermaioria por apenas 11 semanas, e o Agave 2.3 segue um cronograma semelhante.

Rede com vários clientes

A adoção do Firedancer na mainnet avançou significativamente nos últimos meses. Atualmente, 21,6% do stake usa o cliente Jito-Frankendancer, uma proporção que cresceu de forma lenta e constante ao longo do ano (veja o gráfico abaixo). A expectativa é que a adoção permaneça em torno de 20% até que o cliente Firedancer completo esteja pronto para implantação em produção na mainnet.

Esse é um marco importante para a estratégia de múltiplos clientes da Solana, um objetivo de longa data que busca melhorar a segurança, a atividade e a resiliência da rede. Uma maior diversidade de clientes oferece mais opções aos operadores de validadores, promove uma concorrência saudável entre as equipes responsáveis pelos clientes e aumenta a quantidade de pessoas analisando suas bases de código. Ela também reduz o risco de um único bug crítico causar uma interrupção em toda a rede.

Também vale destacar que o stake que usa o cliente Agave padrão, ou seja, o Agave sem modificações de MEV de terceiros, como o Jito, caiu de cerca de 6% no início do ano para aproximadamente 2% hoje. Enquanto isso, a adoção do Paladin-Agave aumentou nos últimos meses e agora representa cerca de 6% do stake total.

Teste de estresse da rede

Em 10 de outubro, o mercado de criptoativos passou pelo maior evento de liquidação de sua história, provocando volatilidade extrema em todas as principais blockchains. Apesar do aumento recorde na atividade da rede, a rede Solana e o cliente validador Agave demonstraram resiliência e estabilidade excepcionais sob pressão.

Durante o pico, Solana sustentou um volume de tráfego seis vezes maior que o normal, com líderes recebendo cerca de 100.000 pacotes de transações por segundo, enquanto produzia blocos completos no limite de 60 milhões de CUs.

Mesmo nessas condições, Solana apresentou a dinâmica de taxas mais estável entre todas as grandes redes, processando um throughput uma ordem de magnitude maior. O TPS real (transações sem voto) ultrapassou 3.200 no auge da atividade.

Durante a janela de pico de aproximadamente duas horas, a taxa mediana (P50) das transações da Solana subiu apenas para US$ 0,007, menos de um centavo. As taxas médias chegaram brevemente a US$ 0,10, e o 1% das transações com taxas mais altas (P99) atingiu um pico pouco acima de US$ 1,00. Esse padrão demonstra a eficácia dos mercados locais de taxas, que restringiram as taxas elevadas apenas às transações que interagiam com contas muito disputadas, sem afetar usuários comuns que faziam transferências simples, como pagamentos com stablecoins.

Para comparação, a mainnet da Ethereum e a Arbitrum registraram breves picos nas taxas medianas, que ultrapassaram US$ 100 por transação durante o mesmo período. A Base, L2 operada pela Coinbase, também registrou aumentos nas taxas, com a mediana chegando a mais de US$ 3. Essas redes não têm mercados locais de taxas e aplicam ajustes globais que elevam os custos de maneira uniforme para todos os usuários durante períodos de estresse da rede.

Crescimento do estado

Solana alcançou recentemente um marco importante no crescimento do estado on-chain, ultrapassando o total de 1 bilhão de contas. Quase 67% dessas contas pertencem ao Token Program, sendo que 89,45% são contas de token associadas e 10,55% são contas de emissão de tokens.

Essa expansão contínua do estado tem implicações de longo prazo para os clientes Solana e os provedores de infraestrutura. À medida que o número de contas cresce, também aumenta a demanda por armazenamento, tamanho de snapshots e indexação de contas, o que pode afetar o desempenho e os requisitos de hardware. Soluções como ZK Compression oferecem um caminho promissor de longo prazo para reduzir o inchaço do estado.

Atualizações do ciclo de lançamento do Agave 3.0

Reformulação do cache

O Agave 3.0 reduz significativamente as operações redundantes do runtime. Uma reformulação completa do cache de programas elimina centenas de consultas desnecessárias a contas por lote de transações, resultando em um processamento de transações aproximadamente 30% a 40% mais rápido nos benchmarks internos.

Aumento do limite por conta para 40% das CUs do bloco

Como parte do ciclo de lançamento do Agave 3.0, Solana ativará a SIMD-0306: aumento dos limites de CUs por conta. Isso aumenta o limite de CUs por conta, antes uma constante fixa de 12 milhões, para 40% do limite de CUs do bloco. Atualmente, cada conta pode consumir até 12 milhões de CUs por bloco. Como mostra o gráfico da Anza abaixo, as contas mais disputadas frequentemente atingem esse limite.

Com essa mudança, o limite por conta aumentará inicialmente de 12 milhões para 24 milhões de CUs e, por fim, para 40 milhões de CUs quando a SIMD-0286 (blocos de 100 milhões de CUs) for ativada. Combinada a atualizações como a introdução do programa P-token, essa melhoria aumentará significativamente o throughput de contas muito acessadas em cada bloco.

Outras restrições permanecerão inalteradas, incluindo:

• Máximo de unidades de voto: o limite total de CUs de transações de voto por bloco, definido em 36 milhões de CUs
• Variação máxima do tamanho dos dados de contas por bloco: o limite total de alterações nos dados de contas por bloco, definido em 100 megabytes.

Embora elevar o limite de CUs por conta melhore o throughput do estado mais acessado, isso também pode aumentar o tempo de execução serializada no pior caso, possivelmente prolongando a verificação de blocos ou a duração dos slots em cenários de carga elevada.

Por fim, vale mencionar a proposta recente SIMD-0370: remoção do limite de unidades de computação por bloco, que explora a eliminação completa dos limites de bloco baseados em CUs, uma direção que provavelmente será reavaliada após a atualização Alpenglow.

eXpress Data Path (XDP) para Turbine

eXpress Data Path (XDP) é uma tecnologia do kernel Linux projetada para redes de alto desempenho. Ela permite que aplicações contornem grande parte do caminho padrão de processamento de pacotes do kernel, reduzindo tanto as cópias intermediárias de dados quanto as trocas de contexto entre o espaço do usuário e o do kernel. Ao processar pacotes diretamente com a placa de interface de rede (NIC) no espaço do usuário, XDP reduz drasticamente a sobrecarga por pacote.

O suporte a XDP no Turbine foi introduzido inicialmente no Agave v2.3.8 e será habilitado por padrão a partir do Agave 3.1. Turbine é o principal gargalo de escalabilidade à medida que os limites de bloco aumentam para 100 milhões de CUs. Os líderes retransmitem seus shreds para 200 pares, gerando uma carga intensa na rede. Nas condições atuais, grandes validadores com mais slots de liderança podem chegar a 150.000 pacotes de saída por segundo. XDP resolve diretamente esse gargalo, tornando o envio de pacotes até 100 vezes mais rápido e permitindo que os validadores propaguem blocos maiores com muito mais eficiência. 

Quem quiser conhecer melhor a implementação de XDP no Agave pode consultar o guia de configuração de validadores e nossa entrevista anterior com o engenheiro da Anza Alessandro Decina, que liderou a integração de XDP ao cliente Agave.

Especificação do tamanho dos dados carregados da transação

Como parte dos esforços contínuos para simplificar e padronizar o modelo de execução da Solana, a SIMD-0186: especificação do tamanho dos dados carregados da transação será ativada na mainnet durante o ciclo de lançamento do Agave 3.0.

Isso introduz um método seguro para o consenso calcular o total de dados de contas carregados por cada transação. O objetivo é garantir que todos os clientes validadores calculem tamanhos idênticos para os dados das transações, eliminando inconsistências sutis que poderiam causar divergências no consenso.

Atualmente, a lógica da Solana para dimensionar dados de transações é excessivamente complexa. A implementação existente adota um tratamento peculiar para os programas LoaderV3 e BPF Upgradeable Loader, que frequentemente contabilizam um tamanho menor que o real dos dados de programa carregados. Essas discrepâncias dificultavam a implementação de uma lógica compatível por equipes independentes de clientes.

Com a SIMD-0186, as regras de dimensionamento passam a ser explícitas e fáceis de entender:

• Cada conta carregada é contabilizada exatamente uma vez
• Programas que usam o BPF Upgradeable Loader incluem os dados de programa associados
• O tamanho de cada conta carregada é definido como o comprimento em bytes de seus dados antes da execução da transação, com 64 bytes adicionais para metadados
• Cada Address Lookup Table (ALT) adiciona um valor fixo de 8.248 bytes

Essa especificação padroniza o dimensionamento de transações em todos os clientes e torna o comportamento das transações mais previsível para os desenvolvedores.

O limite de tamanho dos dados carregados desempenha uma função semelhante à do limite de CUs por transação, fornecendo uma contabilização previsível de recursos para os nós validadores. Por padrão, cada transação pode carregar até 64 MB de dados de contas, consumindo oito unidades de computação (CUs) para cada 32 KB carregados, o equivalente a um custo-base de 16.000 CUs, mesmo que menos dados sejam efetivamente carregados. Os desenvolvedores podem reduzir esse limite por meio da instrução setLoadedAccountsDataSizeLimit para diminuir o custo de computação e melhorar a eficiência do agendamento.

Como o novo método de dimensionamento pode produzir valores diferentes dependendo da estrutura da transação, os desenvolvedores talvez precisem ajustar o limite de tamanho dos dados de contas carregados especificado nas instruções de orçamento de computação.

Struct TransactionView do agendador

Com o Agave 3.0, o agendador apresenta uma nova estrutura de dados leve chamada TransactionView, projetada para otimizar a análise e o processamento das transações. Ao contrário dos tipos de transação mais antigos do SDK, que exigiam desserialização e várias alocações de memória, TransactionView oferece uma visualização direta de uma transação serializada. Ela analisa e armazena em cache os metadados sobre o layout da transação sem realmente desserializá-la.

Inicialização mais rápida

O desempenho de inicialização do cliente continua melhorando com o lançamento do Agave v3.0, proporcionando um avanço significativo na experiência dos operadores de validadores e RPC. Seja após uma falha, atualização ou manutenção programada, os nós agora podem voltar a ficar online com muito mais rapidez.

Ao iniciar a partir de um arquivo de snapshot, o tempo de inicialização foi reduzido para menos de três minutos e meio, menos da metade do tempo necessário com o Agave v2.2 (veja o gráfico abaixo). Essa melhoria representa um ganho crítico de desempenho, pois uma inicialização mais rápida aumenta diretamente a resiliência da rede e o tempo de atividade dos validadores ao reduzir o tempo necessário para que os nós voltem a participar do consenso.

Olhando para o futuro, o Agave v3.1 simplificará ainda mais esse processo ao eliminar a verificação de contas em segundo plano, permitindo que os validadores comecem a votar imediatamente após o início do replay.

Aumento do limite de aninhamento de CPI

A SIMD-0268: aumento do limite de aninhamento de CPI aumenta de 4 para 8 a profundidade máxima das chamadas de invocação entre programas (CPI). Na prática, isso dobra o número de vezes que um programa Solana pode invocar outros programas dentro de uma única transação.

CPI é o mecanismo pelo qual um programa Solana chama outro. É um recurso fundamental do runtime da Solana que permite que programas aproveitem a lógica uns dos outros.

Protocolos on-chain complexos, como swaps perpétuos, carteiras inteligentes e sistemas de margem cruzada, frequentemente dependem de várias camadas de interação entre programas para gerenciar posições, liquidações e riscos. O limite anterior de quatro níveis de CPI restringia esses projetos e, em alguns casos, obrigava os desenvolvedores a dividir a lógica entre várias transações.

As aplicações existentes continuarão funcionando como antes, a menos que dependam do limite antigo em sua lógica para provocar falhas nas transações. De modo geral, essa mudança muito solicitada amplia as possibilidades de projeto para os desenvolvedores e fortalece a composabilidade da Solana.

Flexibilização das restrições de entrada

A SIMD-0083: flexibilização das restrições de entrada, com ativação prevista durante o Agave 3.0, remove a regra que proibia conflitos entre transações dentro de uma entrada de bloco. Antes, qualquer entrada contendo transações conflitantes — isto é, quando ambas gravavam na mesma conta ou quando uma lia enquanto a outra gravava — invalidava o bloco inteiro.

Com essa atualização, esses conflitos passam a ser permitidos. Quando ocorrem, as transações são simplesmente executadas de forma sequencial, na ordem em que aparecem. Essa mudança simplifica as regras de empacotamento de blocos e oferece aos líderes maior flexibilidade na ordenação de transações e na construção de blocos. Ela também é necessária para que Solana possa implementar a execução assíncrona.

Melhorias de RPC

O Agave v3.0 apresenta melhorias na capacidade de resposta do servidor de assinaturas, que agora prioriza mensagens recebidas, como solicitações de assinatura e PINGs, em vez de notificações enviadas. Essa mudança oferece atualizações em tempo real mais rápidas e confiáveis para dApps que usam PubSub WebSockets.

Além disso, propriedades de slot foram adicionadas aos dados de erro de recompensas de época, melhorando a depuração e a observabilidade para os desenvolvedores.

Outras mudanças

• A partir do Agave v3.0.0, a Anza deixou de publicar binários pré-compilados do agave-validator. Agora, os operadores de validadores precisam compilar os binários a partir do código-fonte seguindo as instruções de compilação fornecidas.
• Com o Agave v3.0, o intervalo padrão de snapshots foi ampliado para cada 100.000 slots, em vez dos 50.000 da v2.3 e dos 25.000 da v2.2. A ampliação do intervalo melhora significativamente o desempenho do disco e reduz picos de IOPS (operações de entrada/saída por segundo) durante a criação de snapshots.
• Diversos argumentos e sinalizadores antigos e obsoletos da CLI foram removidos (veja a lista completa aqui).
• Atualmente, uma instrução advance nonce em uma transação pode especificar qualquer conta da transação como a conta a ser avançada. Após a ativação do feature gate da SIMD-0242: somente conta nonce estática, a instrução advance nonce ficará restrita a avançar apenas uma conta incluída estaticamente.

Conclusão

O Agave v3.0 é uma atualização substancial do cliente que apresenta processamento de transações mais rápido, limites de computação mais altos, maior eficiência do agendador e diversas otimizações para validadores e RPC. Juntas, essas atualizações fortalecem o desempenho da rede e a experiência do desenvolvedor.

Dados recentes reforçam ainda mais esse progresso: ciclos de lançamento mais rápidos, maior diversidade de clientes e estabilidade excepcional da rede durante picos de demanda destacam o amadurecimento da Solana. Agora que o Agave 3.0 impulsiona a rede, Solana continua demonstrando sua capacidade de escalar.

Recursos adicionais

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