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

Introdução

Com o Agave 4.2, o principal cliente validador da Solana continua inovando. Esta grande versão se concentra em três atualizações muito aguardadas, controladas por feature gates: slots de 200 ms, redução de 90% nas cauções de estado e transações de 4.096 bytes por meio do novo formato transaction v1. Ela também inclui todos os recursos do Alpenglow antes da ativação planejada para a versão seguinte, enquanto a transmissão por XDP agora vem habilitada por padrão.

Atualizações de destaque

• Transações 3,3× maiores com um novo padrão Transaction v1 *
• Redução de 90% na caução de estado (aluguel) *
• Tempos de slot reduzidos para 200 ms *
• Todos os recursos do Alpenglow concluídos
• Novas ferramentas de governança (relacionadas a SIMD)

* Atualizações controladas por feature gates

Transações maiores (Transaction v1)

O ciclo de lançamento do Agave 4.2 inclui a ativação de um feature gate para transações maiores, de até 4.096 bytes, acima do antigo limite de 1.232 bytes. Definido formalmente em SIMD-0296: tamanho maior de transação, o novo limite representa um aumento de aproximadamente 3,3× e se aplica exclusivamente ao novo formato transaction v1 introduzido pela SIMD-0385: formato Transaction V1. As transações legadas e v0 continuam funcionando sem alterações e permanecem sujeitas ao limite atual de 1.232 bytes.

Para os desenvolvedores, isso significa mais do que espaço adicional para dados de instruções. Provas criptográficas, aprovações multisig, grandes listas de contas e outros payloads que antes não cabiam em uma única transação agora podem ser executados em uma única operação atômica nativa do protocolo. A mudança não aumenta os limites de computação, contas, assinaturas ou quantidade de instruções da Solana.

O limite original de 1.232 bytes foi herdado da antiga arquitetura de rede da Solana. As transações eram transmitidas como datagramas UDP individuais e precisavam caber na unidade máxima de transmissão (MTU) mínima do IPv6, de 1.280 bytes. Descontados o cabeçalho IPv6 de 40 bytes e o cabeçalho UDP de oito bytes, restavam 1.232 bytes para a própria transação. Manter cada transação em um único pacote reduzia a fragmentação e tornava a transmissão mais previsível.

Há muito tempo, a Solana migrou do UDP para o QUIC na ingestão de transações. Os streams QUIC não estão restritos ao payload de um único datagrama de rede, portanto o antigo limite de 1.232 bytes deixou de ser necessário. Os clientes ainda precisam de um limite superior explícito para controle de admissão, alocação de memória e validação de consenso, mas agora esse limite pode ser definido de acordo com os requisitos do runtime e da aplicação, em vez da MTU do IPv6.

As listas de contas costumam consumir uma parte significativa do espaço disponível. Cada chave pública Ed25519 ou endereço derivado de programa ocupa 32 bytes, e uma transação precisa identificar todas as contas que suas instruções leem ou modificam. Isso estabelecia um limite efetivo de aproximadamente 32 chaves de conta completas. Para contornar essa restrição, as transações V0 introduziram as Address Lookup Tables (ALTs), que substituem cada chave de 32 bytes por um índice de tabela de um único byte, permitindo que as transações alcancem o limite de 64 contas do runtime.

Embora as ALTs sejam uma forma eficaz de compactação, elas também introduzem complexidades. As aplicações precisam criar e gerenciar tabelas de consulta onchain. Serviços RPC e indexadores que decodificam uma mensagem v0 bruta precisam reconstruir sua lista completa de contas usando os metadados da transação ou o estado da tabela relevante. Isso cria um desafio ao analisar transações que fazem referência a uma ALT que já foi encerrada e não está mais disponível onchain. 

Esse problema para desenvolvedores é resolvido pelas transações v1, que são grandes o suficiente para carregar o conjunto completo de contas atualmente compatível por meio de ALTs (64 chaves públicas completas ocupando 2.048 bytes). Assim, uma aplicação que migra da v0 pode resolver as entradas de sua tabela de consulta e incluir os endereços resultantes diretamente em uma transação v1.

Além disso, transações de 1.232 bytes são especialmente restritivas para funções criptográficas, como provas de conhecimento zero e implementações BLS sem precompiles nativos. Essas cargas de trabalho podem transportar centenas ou milhares de bytes de dados de prova ou assinatura. Um limite de 4.096 bytes cobre muitos desses casos de uso criptográfico comuns. 

Especificação da Transaction V1

Uma transação v1 serializada começa com o byte de versão 0x81. Em seguida, vêm um cabeçalho de mensagem de três bytes no estilo legado, uma máscara de configuração de transação de 32 bits, um especificador de validade de 32 bytes, contagens de instruções e endereços, o array completo de endereços de 32 bytes, valores de configuração, cabeçalhos de instrução de tamanho fixo, payloads contíguos de instruções e, por fim, as assinaturas. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Os cabeçalhos de instrução identificam explicitamente o índice da conta do programa, a quantidade de contas da instrução e o tamanho dos dados da instrução, disponibilizando os limites da mensagem sem a necessidade de interpretar o payload de cada instrução.

As transações V1 continuam limitadas a 12 assinaturas, 64 endereços de conta, 64 instruções e 255 índices de conta por instrução. Transações grandes ainda precisam respeitar o limite solicitado de unidades de computação, o limite de dados de contas carregados, as regras de bloqueio de contas e a capacidade de execução disponível no bloco.

Os parsers atuais não podem tratar a v1 como uma v0 com um tamanho máximo maior. Indexadores, RPCs, SDKs e infraestruturas de assinatura que inspecionam transações serializadas precisam reconhecer o prefixo 0x81 e implementar a nova ordem dos campos. Vale destacar que, nas transações v1, as assinaturas aparecem no final, e não antes da mensagem, como ocorre nas transações legadas e v0.

A Transaction v1 substitui as instruções de configuração do programa Compute Budget por campos no cabeçalho da transação. O `TransactionConfigMask` inicial pode declarar:

• taxa de prioridade total em lamports
• limite de unidades de computação
• limite do tamanho dos dados de contas carregados
• tamanho de heap solicitado

Cada bit definido identifica um valor de configuração associado de quatro bytes, com a taxa de prioridade de 64 bits ocupando duas posições da máscara. A máscara foi projetada para ser extensível em futuras versões de transação.

Redução da caução de estado (aluguel)

Os altos requisitos de caução de estado, geralmente chamados de “aluguel”, continuam sendo uma das principais fontes de atrito da Solana para aplicações que usam muitas contas. O nome pode ser um pouco enganoso, pois o aluguel não é uma taxa recorrente de armazenamento, mas uma caução reembolsável que uma conta precisa manter enquanto seu estado permanecer onchain. Normalmente, os lamports podem ser recuperados quando a conta é encerrada, mas, até lá, eles representam um capital que o desenvolvedor ou usuário precisa fornecer antecipadamente e deixar imobilizado.

O Agave 4.2 introduz a implementação controlada por feature gate da SIMD-0437: redução incremental de lamports_per_byte para 696, que reduz a constante `lamports_per_byte` de 6.960 para 696. Isso representa uma redução de 90% no aluguel (ou, mais precisamente, no saldo mínimo para isenção de aluguel), aplicada por meio de cinco feature gates independentes: 6.960 → 6.333 → 5.080 → 2.575 → 1.322 → 696. 

Quando um dos gates é ativado, o Agave atualiza a configuração de aluguel do Bank e publica o novo valor por meio da sysvar Rent. A implementação gradual permite que a rede observe como as aplicações respondem a cada nível de preço e interrompa o processo antes da próxima redução caso o crescimento do estado ou o uso de recursos pelos validadores se torne preocupante.

O saldo mínimo de uma conta para isenção de aluguel é calculado com base no tamanho de dados alocado mais uma sobrecarga fixa de armazenamento de 128 bytes:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Com essa mudança, o mecanismo de aluguel em si não muda: as contas ainda precisam de um saldo mínimo, e esse saldo continua recuperável quando a conta é encerrada. Muda apenas a quantidade de SOL que precisa ficar vinculada.

Uma conta padrão de SPL Token tem 165 bytes. Incluindo a sobrecarga de 128 bytes, seu tamanho efetivo é de 293 bytes. A redução de 90% no aluguel diminui o valor de SOL necessário para essa conta de cerca de ~US$ 0,16 para menos de 2 centavos. 

Isso traz consequências especialmente importantes para pagamentos com stablecoins, distribuições de tokens, sistemas de fidelidade e airdrops diretos. Uma carteira não mantém SPL tokens diretamente; normalmente, ela precisa de uma Associated Token Account (ATA) para cada mint. Quando o destinatário ainda não tem a ATA necessária, o remetente pode criá-la junto com a transferência, mas também precisa financiar o saldo do destinatário para isenção de aluguel. Em geral, esse é um custo único de integração para cada par de carteira e mint, e não um custo pago em cada pagamento posterior. Ainda assim, em grande escala, ele pode ser alto o suficiente para determinar se uma empresa subsidia a integração ou repassa o custo aos usuários.

Crescimento do estado da Solana

A redução gradual é importante porque diminuir a caução de estado também reduz o valor que um invasor precisa imobilizar para criar e manter estados indesejados. O estado da Solana é replicado, indexado, incluído em snapshots e mantido por todos os validadores. Portanto, o crescimento persistente do estado acaba afetando os requisitos de disco, as operações do AccountsDB e, por fim, os custos operacionais.

Segundo uma análise recente da Solana Foundation, os arquivos de armazenamento do AccountsDB ocupam aproximadamente 495 GB de uma alocação recomendada de 1 TB. Após a redução de aluguel planejada, esgotar esse espaço disponível exigiria que um invasor comprometesse aproximadamente US$ 17,2 milhões em SOL. Dobrar a alocação de armazenamento recomendada para validadores para 2 TB eleva o capital necessário do invasor para US$ 51 milhões.

Considerando tanto a criação de novas contas quanto o encerramento de contas antigas, constatou-se que o estado crescia aproximadamente 0,3 GB por dia.

Um snapshot do estado obtido na época 997 mostra que o consumo de estado é altamente concentrado. As contas de SPL Token eram a maior categoria, enquanto as contas da OpenBook e da Serum ocupavam cerca de 30% do estado ativo, refletindo a arquitetura complexa dos livros de ordens onchain. A análise também estimou que aproximadamente 30% do espaço de SPL Token estava associado a ativos no estilo da plataforma de lançamento de tokens Pump.fun.

Medidas de segurança

Reduzir as cauções de estado com segurança exige um caminho viável na direção oposta. Sem mudanças adicionais no runtime, um aumento posterior do saldo mínimo para isenção de aluguel deixaria imediatamente as contas existentes abaixo do novo limite. Transações que aplicassem bloqueio de escrita nessas contas poderiam falhar mesmo sem alocar nenhum estado adicional, causando interrupções generalizadas.

É nesse ponto que a SIMD-0392: adaptação do runtime para aumentos de aluguel altera a regra de saldo mínimo pós-execução para preservar as condições das contas existentes quando o aluguel aumenta. Quando uma conta já existe, não aumenta de tamanho e mantém o mesmo proprietário, seu mínimo permitido passa a ser o menor entre:

1. o mínimo segundo a taxa de aluguel atual
2. o saldo da conta antes da execução

Novas contas ainda precisam cumprir o saldo mínimo atual para isenção de aluguel. O mesmo vale para contas que aumentam o tamanho alocado ou mudam de proprietário. Um saldo zero continua representando o encerramento da conta. Isso permite que o estado existente continue operando com o valor anteriormente vinculado, ao mesmo tempo que garante que o estado recém-alocado pague a taxa mais recente.

A SIMD-0438: proteção para o aumento do saldo mínimo de isenção de aluguel adiciona um feature gate de proteção separado que restaura `lamports_per_byte` ao valor legado de 6.960. Ele deve ser ativado somente se a redução do aluguel provocar crescimento excessivo do estado ou outro problema operacional significativo. Como o gate existe antes do início das reduções, os principais desenvolvedores não precisariam projetar, revisar e implantar uma nova mudança de consenso durante um incidente emergente de crescimento do estado.

Em conjunto, os cinco gates de redução, as regras de preservação da SIMD-0392 e o mecanismo de reversão da SIMD-0438 tornam a implementação reversível no nível do protocolo. A rede pode reduzir a caução gradualmente, observar o comportamento do estado ativo e do armazenamento dos validadores, pausar em um valor intermediário ou restaurar o requisito original sem obrigar que todas as contas existentes recebam imediatamente fundos adicionais.

Tempos de slot reduzidos para 200 ms

Uma das atualizações de desempenho mais aguardadas da Solana é a redução do tempo-alvo dos slots de 400 ms para 200 ms. O principal benefício é a menor latência. Com slots de 200 ms, a janela de liderança de quatro slots da Solana cairia de 1,6 segundo para 800 ms, reduzindo os tempos de confirmação e limitando por quanto tempo um líder mal-intencionado pode atrasar, reordenar ou incluir transações seletivamente. Slots mais curtos também oferecem uma temporização onchain mais granular a aplicações como consumidores de oráculos e formadores de mercado.

A proposta foi projetada para preservar a economia e o throughput atuais da Solana. Os parâmetros de inflação, os custos do Validator Admission Ticket no Alpenglow e os limites de trabalho por slot são ajustados proporcionalmente. No entanto, se os slots de 200 ms chegarem antes do Alpenglow, os custos de votação dos validadores poderão praticamente dobrar, pois eles precisarão votar com o dobro da frequência.

Para uma análise mais detalhada dos slots de 200 ms, leia nossa cobertura anterior no detalhamento do Agave 4.1.

Outras atualizações de destaque

Várias melhorias menores, mas relevantes, devem ser ativadas durante o ciclo de lançamento do Agave 4.2.

Preparação para o Alpenglow

O Agave 4.2 inclui todos os recursos do Alpenglow, mas não ativará o novo protocolo de consenso na mainnet. As principais equipes de engenharia estão usando este ciclo de lançamento para testes, auditorias e reforço adicionais antes da migração de consenso, agora prevista para o Agave 4.3. Portanto, os validadores que executam a versão 4.2 já têm a implementação completa do Alpenglow, incluindo o mecanismo de votação Votor e seus componentes de verificação de certificados BLS. 

Para ampliar a revisão de segurança do código, a Anza também está promovendo uma competição de bug bounty do Alpenglow, com premiação de até 50.000 SOL e período de envio de 5 a 19 de agosto. Anteriormente, o Alpenglow havia sido excluído do programa permanente de recompensas do Agave durante o desenvolvimento, a migração do monorepo e as auditorias internas. A competição marca sua inclusão no programa de recompensas e busca descobrir problemas que possam ter escapado das análises anteriores.

Conversão de ponto flutuante para ponto fixo no Stake Program

O ciclo de lançamento do Agave 4.2 também inclui a implementação, controlada por feature gate, da SIMD-0391: conversão de ponto flutuante para ponto fixo no Stake Program, que substitui a aritmética de ponto flutuante IEEE-754 nos cálculos de aquecimento e resfriamento do Stake Program por matemática determinística de inteiros de ponto fixo. A principal motivação é a compatibilidade com o conjunto de ferramentas eBPF padrão, que não oferece suporte a operações de ponto flutuante. O conjunto de ferramentas SBF da Solana pode emulá-las usando rotinas determinísticas de soft-float, mas isso é ineficiente e impede a migração do Stake Program para uma implementação `no_std`.

A maioria das aplicações não exige mudanças. No entanto, indexadores e ferramentas de staking que reproduzem de forma independente o stake efetivo, em ativação ou em desativação devem implementar as novas regras de inteiros assim que o recurso for ativado.

Novas ferramentas de governança

O ciclo de lançamento do Agave 4.2 também marca a chegada de novas ferramentas de governança desenvolvidas desde o ano passado. Essas ferramentas oferecem um processo onchain para que validadores e stakers nativos sinalizem suas posições sobre decisões econômicas e de protocolo importantes. 

Seu componente central, o svmgov, é um programa baseado em Anchor que gerencia a criação de propostas, o apoio, a votação ponderada por stake e a finalização. Os pesos dos votos vêm de um snapshot de stake específico da época, produzido pela Node Consensus Network (NCN). Operadores independentes derivam o snapshot, chegam a um consenso sobre uma raiz de Merkle canônica e a publicam onchain. Em seguida, os validadores comprovam seu stake ativo usando provas de Merkle. 

Validadores com pelo menos 100.000 SOL em stake ativo podem criar propostas, enquanto as propostas precisam do apoio de 15% do stake do cluster antes de avançar no processo de votação. O repositório de governança também inclui uma CLI em Rust e um frontend web para votar e acompanhar o apoio.

Os documentos completos das propostas ficam no repositório Solana Governance Proposals, separado, e são vinculados a um commit específico do Git, enquanto a conta onchain da proposta armazena o link, o estado do ciclo de vida e a contagem de votos. Inicialmente, os validadores votam com todo o stake delegado a eles, mas cada delegador mantém a soberania sobre seus SOL. Um staker pode enviar uma substituição para uma conta de stake específica, removendo esse stake da contagem do validador e realocando-o de acordo com o próprio voto do staker.

As Solana Governance Proposals (SGPs) foram criadas para complementar, e não substituir, as SIMDs: uma SGP responde à questão direcional sobre se a rede deve buscar uma mudança, enquanto a SIMD associada especifica como essa mudança deve ser implementada.

Três SGPs já passaram pela fase de apoio e formarão a primeira rodada de votações de governança no novo sistema:

• A SGP-0001: Constituição da Solana propõe ratificar um contrato social canônico de governança que define as funções de desenvolvedores, validadores e stakers e estabelece formalmente o processo de SGP.
• A SGP-0002: desinflação em dobro pede que a rede dobre a taxa anual de desinflação do SOL de 15% para 30%, mantendo inalterada a taxa de inflação terminal de 1,5% e reduzindo o prazo estimado para alcançar essa taxa terminal de aproximadamente 5,7 anos para 2,8 anos. 
• A SGP-0003: taxa de recursos e inclusão propõe substituir a estrutura atual de taxa-base fixa por uma taxa de inclusão de 2.500 lamports paga ao líder e uma taxa de recursos separada, baseada nas unidades de custo de transação solicitadas e totalmente queimada, mantendo inalterada a distribuição das taxas de prioridade.

Conclusão

O Agave 4.2 é uma das versões mais importantes da Solana dos últimos tempos. Slots mais rápidos, de 200 ms, aproximam a rede de uma capacidade de resposta em tempo real. A redução planejada de 90% nas cauções de estado torna a criação de contas muito mais acessível. E a Transaction v1 de 4.096 bytes libera muito mais espaço para instruções complexas, provas criptográficas e aplicações que usam muitas contas. Juntas, essas mudanças tornam a Solana mais rápida, mais barata e mais flexível para desenvolvedores e usuários.

Recursos adicionais

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