Muitos agradecimentos a 0xIchigo e Brian Wong por revisar versões anteriores deste trabalho.

Introdução

A grande versão 3.0 do Agave marca mais um marco para Solana, introduzindo uma série de melhorias destinadas a melhorar o desempenho da rede, as operações dos validadores e a experiência do desenvolvedor.

Atualizações Notáveis do Agave 3.0

• Reformulação de Cache: entregando processamento de transações 30–40% mais rápido

• Limite de Cálculo por Conta Única Maior: aumenta o limite de conta única para 40% dos CUs de um bloco

• Nova Estrutura de Visualização de Transação do Agendador: melhorando a eficiência do agendamento

• Caminho de Dados eXpress (XDP) para Turbine: um pré-requisito para blocos de 100 milhões de CUs

• Aumento da Profundidade de Aninhamento de CPI: aumenta o limite de aninhamento de CPI de 4 para 8

• Relaxe as Restrições de Entrada: simplifica a lógica de agendamento e é necessária para a execução assíncrona

• Tempos de Inicialização Mais Rápidos: os nós agora voltam online mais rápido

• Especificação do Tamanho dos Dados da Transação Carregada: padroniza como os dados da transação carregada são calculados

• Melhorias de RPC: atualizações em tempo real mais rápidas e confiáveis para dApps usando WebSockets PubSub

Cada seção deste artigo é autônoma, permitindo que os leitores se concentrem nos tópicos mais relevantes para eles. Seja você um operador de validador, desenvolvedor ou membro ativo da comunidade, este guia para o Agave v3.0 oferece as principais atualizações e insights necessários para aproveitar ao máximo as melhorias mais recentes.

Tendências Relacionadas ao Cliente

Antes de explorar os detalhes das novas funcionalidades do Agave v3.0, vamos ver como os dados recentes destacam o progresso feito pela rede Solana e pelo cliente Agave, mostrando ciclos de lançamento mais rápidos, adoção mais ampla de clientes e desempenho robusto sob pressão.

Cadência de Lançamento do Agave

A Anza acelerou notavelmente seu ritmo de lançamento este ano, reduzindo o intervalo entre versões menores do Agave para menos de três meses. A série Agave 2.2.* permaneceu como a versão supermaioritária por apenas 11 semanas, com o Agave 2.3 seguindo uma linha do tempo semelhante.

Rede Multi-Cliente

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

Isso marca um marco significativo para a estratégia multi-cliente do Solana, um objetivo de longa data visando melhorar a segurança, a vivacidade e a resiliência da rede. Aumentar a diversidade de clientes oferece maior escolha para operadores de validadores, promove uma competição saudável entre as equipes de clientes e traz mais atenção para os códigos dos clientes. Também mitiga o risco de um único bug crítico desencadear uma falha na rede inteira.

É também notável que o stake rodando o cliente Agave vanilla, ou seja, Agave sem modificações MEV de terceiros como 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, agora representando cerca de 6% do stake total.

Teste de Estresse da Rede

Em 10 de outubro, o mercado de cripto experimentou o maior evento de liquidação de sua história, desencadeando uma volatilidade extrema em todas as principais blockchains. Apesar do aumento recorde na atividade da rede, a rede Solana e o cliente validador Agave demonstraram notável resiliência e estabilidade sob pressão.

Durante o pico, o Solana sustentou seis vezes seus níveis normais de tráfego, com os líderes processando cerca de 100.000 pacotes de transação por segundo, enquanto produziam blocos completos no limite de 60 milhões de CUs.

Mesmo sob essas condições, o Solana exibiu a dinâmica de taxas mais estável de qualquer rede principal enquanto processava uma ordem de magnitude maior de throughput. O TPS verdadeiro (transações não-voto) excedeu 3.200 no auge da atividade.

Durante a janela de pico de aproximadamente duas horas, a taxa de transação mediana (P50) do Solana subiu apenas para $0.007, menos de um centavo. As taxas médias alcançaram brevemente $0.10, e o top 1% das transações (P99) atingiu pouco mais de $1.00. Esse padrão demonstra a eficácia dos mercados de taxas locais, que restringiram altas taxas apenas para aquelas transações interagindo com contas quentes contestadas, enquanto usuários comuns realizando transferências simples (por exemplo, pagamentos em stablecoin) não foram afetados.

Para comparação, a mainnet do Ethereum e Arbitrum viu taxas medianas subirem brevemente acima de $100 por transação durante o mesmo período. A Base, L2 operada pela Coinbase, também experimentou picos de taxas com taxas medianas alcançando mais de $3. Essas redes carecem de mercados de taxas locais, aplicando ajustes de taxas globais que aumentam uniformemente os custos para todos os usuários durante o estresse da rede.

Crescimento do Estado

O Solana recentemente cruzou um marco importante no crescimento do estado em cadeia, superando 1 bilhão de contas totais. Quase 67% dessas contas são de propriedade do Programa Token, das quais 89,45% são contas de token associadas e 10,55% contas de mint de token.

Essa expansão constante do estado tem implicações de longo prazo para os clientes e provedores de infraestrutura do Solana. À medida que o número de contas cresce, também cresce a demanda por armazenamento, tamanho de instantâneo e indexação de contas, todos os quais podem impactar o desempenho e os requisitos de hardware. Soluções como a Compressão ZK oferecem um caminho promissor a longo prazo para reduzir a sobrecarga do estado.

Atualizações do Ciclo de Lançamento do Agave

Reformulação do Cache

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

Aumentar o Limite de Contas para 40% do CU do Bloco

Como parte do ciclo de lançamento do Agave 3.0, o Solana ativará SIMD-0306: Aumentar os Limites de CU da Conta. Isso aumenta o limite de CU por conta de um constante fixa de 12M para 40% do limite de CU do bloco. Atualmente, cada conta pode consumir até 12 milhões de CUs por bloco. Como mostrado no gráfico abaixo da Anza, as contas mais contestadas frequentemente atingem esse teto.

Com essa mudança, o limite por conta aumentará inicialmente de 12 milhões para 24 milhões de CUs, e eventualmente para 40 milhões de CUs uma vez que SIMD-0286 (blocos de 100M CU) seja ativado. Combinado com atualizações como a introdução do programa P-token, essa atualização aumentará significativamente o throughput para contas quentes que são frequentemente acessadas dentro de cada bloco.

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

• Unidades Máximas de Voto: o limite total de CUs de transações de voto por bloco, em 36 milhões de CUs

• Delta do Tamanho dos Dados de Contas Máximas por Bloco: o limite nas mudanças totais de dados das contas por bloco, em 100 megabytes.

Embora aumentar o limite de CU por conta melhore o throughput para o estado quente, isso também pode aumentar o tempo de execução serializado no pior caso, potencialmente prolongando a verificação de blocos ou a duração do slot em cenários de alta carga.

Finalmente, vale a pena notar a proposta recente SIMD-0370: Remover o Limite de Bloco da Unidade de Cálculo, que explora a eliminação total dos limites de bloco baseados em CU, uma direção que provavelmente será revisitada após a atualização Alpenglow.

Caminho de Dados eXpress (XDP) para Turbine

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

O suporte ao XDP no Turbine foi introduzido pela primeira vez no Agave v2.3.8 e será ativado por padrão a partir do Agave 3.1. O Turbine é o principal gargalo de escalabilidade à medida que os limites de bloco aumentam para 100M CUs. Os líderes retransmitem seus fragmentos para 200 pares, gerando uma carga pesada na rede. Validadores grandes com mais slots de líder podem se aproximar de 150.000 pacotes de saída por segundo nas condições atuais. O XDP aborda diretamente esse gargalo, tornando a distribuição de pacotes até 100 vezes mais rápida, permitindo que validadores propagam blocos maiores de forma muito mais eficiente.

Leitores interessados em um olhar mais profundo sobre a implementação do XDP no Agave podem consultar o guia de configuração do validador e nossa entrevista anterior com o engenheiro da Anza, Alessandro Decina, que liderou a integração do XDP no cliente Agave.

Especificação do Tamanho dos Dados da Transação Carregada

Como parte dos esforços contínuos para simplificar e padronizar o modelo de execução do Solana, SIMD-0186: Especificação do Tamanho dos Dados da Transação Carregada, está programado para ativar na mainnet durante o ciclo de lançamento do Agave 3.0.

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

Atualmente, a lógica de dimensionamento dos dados de transação do Solana está excessivamente complexa. A implementação existente é idiossincrática na forma como lida com os programas LoaderV3 e BPF Upgradeable Loader, ambos frequentemente subestimando o tamanho real dos dados do programa carregado. Essas discrepâncias dificultaram a implementação de lógica compatível pelas equipes de clientes independentes.

Sob SIMD-0186, as regras de dimensionamento agora são explícitas e fáceis de entender:

• Cada conta carregada é contada exatamente uma vez

• Programas que usam o BPF Upgradeable Loader incluem seus 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

• Tabelas de Consulta de Endereços (ALTs) adicionam um total de 8.248 bytes cada

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

O limite de tamanho dos dados carregados serve a um papel semelhante ao limite de CU por transação, fornecendo contabilidade de recursos previsível para nós validadores. Por padrão, cada transação pode carregar até 64MB de dados de conta, consumindo oito unidades de computação (CUs) por 32KB carregado, equivalente a um custo base de 16.000 CUs, mesmo que menos dados sejam realmente carregados. Os desenvolvedores podem reduzir esse limite através da instrução setLoadedAccountsDataSizeLimit para reduzir o custo computacional e melhorar a eficiência do agendamento.

Como o novo método de dimensionamento pode produzir valores variados com base na estrutura da transação, os desenvolvedores podem precisar ajustar o limite do tamanho dos dados da conta carregada especificado em suas instruções de orçamento de computação.

Estrutura de TransactionView do Agendador

Com o Agave 3.0, o agendador introduz uma nova estrutura de dados leve chamada TransactionView, projetada para simplificar como as transações são analisadas e processadas. Ao contrário dos tipos de transação mais antigos do SDK, que exigiam desserialização e múltiplas alocações de memória, o TransactionView fornece uma visão direta de uma transação serializada. Ele analisa e armazena em cache os metadados sobre o layout da transação sem realmente desserializá-la.

Tempos de Inicialização Mais Rápidos

O desempenho de inicialização do cliente continua a melhorar com o lançamento do Agave v3.0, marcando uma atualização notável na qualidade de vida para operadores de validadores e RPC. Seja reiniciando após uma falha, atualização ou manutenção programada, os nós agora podem voltar online significativamente mais rápido.

Começando a partir de um arquivo de instantâneo, os tempos de inicialização foram reduzidos para menos de três minutos e meio, menos da metade da duração exigida sob 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 melhora diretamente a resiliência da rede e o tempo de atividade do validador, reduzindo o tempo necessário para que os nós reentrem no consenso.

Olhando para o futuro, o Agave v3.1 agilizará 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 da reprodução.

Aumentar o Limite de Aninhamento de CPI

SIMD-0268: Aumentar o Limite de Aninhamento de CPI aumenta a profundidade máxima das chamadas de Invocação de Programa Cruzado (CPI) de 4 para 8. Isso efetivamente 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. É uma característica fundamental do runtime do Solana que permite que programas construam sobre a lógica uns dos outros.

Protocolos complexos em cadeia, como swaps perpétuos, carteiras inteligentes e sistemas de margem cruzada, frequentemente dependem de múltiplas camadas de interações de programas para gerenciar posições, liquidações e risco. O limite anterior de 4 níveis de CPI restringia esses designs, em alguns casos forçando os desenvolvedores a dividir a lógica em várias transações.

Aplicativos existentes continuarão a funcionar como antes (a menos que dependam do antigo limite em sua lógica para falhar transações). No geral, essa mudança frequentemente solicitada amplia o espaço de design para desenvolvedores e fortalece a composabilidade do Solana.

Relaxe as Restrições de Entrada

SIMD-0083: Relaxe as Restrições de Entrada, programado para ativação durante o Agave 3.0, remove a regra de que transações dentro de uma entrada de bloco não devem entrar em conflito umas com as outras. Anteriormente, qualquer entrada contendo transações conflitantes (ou seja, aquelas que escrevem na mesma conta ou onde uma lê enquanto outra escreve) invalidaria o bloco inteiro.

Com essa atualização, tais conflitos agora são permitidos. Quando ocorrem, as transações são simplesmente executadas sequencialmente na ordem em que aparecem. Essa mudança simplifica as regras de empacotamento de blocos, dando aos líderes maior flexibilidade na ordenação de transações e construção de blocos. É também uma mudança necessária para o Solana implementar a execução assíncrona.

Melhorias de RPC

O Agave v3.0 introduz melhorias de responsividade no servidor de assinatura, que agora prioriza mensagens recebidas, como solicitações de assinatura e PINGs, sobre notificações de saída. Essa mudança proporciona atualizações em tempo real mais rápidas e confiáveis para dApps usando WebSockets PubSub.

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

Outras Mudanças

• A partir do Agave v3.0.0, a Anza descontinuou a publicação de binários pré-compilados do validador Agave. Os operadores de validador agora devem compilar os binários a partir do código-fonte seguindo as instruções de construção fornecidas.

• Com o Agave v3.0, o intervalo padrão de instantâneo foi estendido para cada 100.000 slots, subindo de 50.000 em v2.3 e 25.000 em v2.2. Aumentar o intervalo melhora significativamente o desempenho do disco, reduzindo picos em IOPS (operações de entrada/saída por segundo) durante a criação de instantâneos.

• Numerosos argumentos e flags antigos da CLI foram removidos (lista completa aqui).

• Atualmente, uma instrução de nonce avançada em uma transação pode especificar qualquer conta na transação como a conta a ser avançada. Após a ativação do gate de recurso para SIMD-0242: Apenas Conta de Nonce Estática, isso restringirá a instrução de nonce avançada para poder avançar apenas uma conta incluída estaticamente.

Conclusão

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

Dados recentes reforçam ainda mais esse progresso: ritmos de lançamento mais rápidos, crescente diversidade de clientes e excepcional estabilidade da rede sob demanda máxima destacam a maturação do Solana. Com o Agave 3.0 agora alimentando a rede, o Solana continua a provar sua capacidade de escalar.