A Solana está organizando uma sequência de melhorias que atacam três limitações diferentes da rede: capacidade de transação, capital imobilizado em contas e velocidade de confirmação. A primeira data confirmada é 9 de setembro, quando Transaction V1 está programada para entrar em operação. Antes disso, a rede espera iniciar durante a semana de 31 de agosto a primeira fase de uma redução de rent que, ao final de cinco etapas, pode diminuir esse requisito em até 90%.

Jacob Creech, vice-presidente de tecnologia da Solana Foundation, também indicou que o trabalho para encurtar os slots continuará e que outubro permanece como alvo para Alpenglow. No entanto, esses projetos não fazem parte de uma única ativação. Cada mudança possui seu próprio feature gate, seus próprios testes e seu próprio processo de adoção pelos validadores. Isso permite que a Solana aumente desempenho de forma progressiva, sem transformar toda a evolução do protocolo em um único ponto de risco.

Transaction V1 amplia o espaço disponível para aplicações mais complexas

A maior mudança imediata será o aumento do tamanho máximo serializado das transações. O limite atual de 1.232 bytes passará para 4.096 bytes, aproximadamente 3,3 vezes mais.

O objetivo não é apenas permitir transações maiores por si só, mas criar espaço para operações que hoje encontram restrições técnicas mais fortes. Provas zero-knowledge, instruções multisig complexas e outras operações intensivas em dados estão entre os usos citados. A proposta SIMD-0296 também menciona assinaturas BLS e operações cross-chain como possibilidades.

Para desenvolvedores de protocolos mais complexos, esse aumento pode reduzir a necessidade de fragmentar determinadas operações em várias transações. Isso pode simplificar certos fluxos, embora o benefício dependa de como cada aplicação é estruturada.

Transaction V1 será opcional. Aplicações existentes poderão continuar usando transações legacy ou version-zero normalmente, evitando uma migração obrigatória em toda a rede.

O novo formato exige escolhas diferentes da infraestrutura existente

A flexibilidade também traz algumas limitações. Transaction V1 não dará suporte a address lookup tables. Desenvolvedores precisarão decidir qual formato oferece a melhor combinação de tamanho, referências e eficiência para cada tipo de operação.

Além disso, uma transação maior representa mais dados trafegando pela rede. Wallets, APIs e outros serviços precisarão estar preparados para lidar com payloads de até 4.096 bytes. A própria proposta reconhece que esse crescimento pode aumentar riscos relacionados a largura de banda e fragmentação.

Por esse motivo, a mudança não deve ser avaliada apenas pela capacidade adicional. O impacto sobre a propagação das transações e o comportamento dos validadores também será importante. A decisão de manter os formatos anteriores disponíveis permite que o ecossistema adote V1 apenas quando a vantagem compensar o custo adicional.

O rent será reduzido gradualmente para evitar uma mudança brusca

A segunda frente da atualização envolve os saldos rent-exempt. A Solana pretende reduzir o cálculo atual de 6.960 lamports por byte para 696 lamports por byte, mas não fará isso em uma única etapa. O plano prevê cinco reduções progressivas.

Esse mecanismo existe para controlar o crescimento do estado onchain. Quando uma aplicação cria uma conta que armazena dados, uma quantidade de SOL precisa permanecer bloqueada para que a conta seja considerada rent-exempt. Como esse valor normalmente pode ser recuperado quando a conta é encerrada, ele funciona mais como capital temporariamente imobilizado do que como uma cobrança recorrente.

Quanto mais contas uma aplicação precisa criar, maior pode ser esse capital bloqueado. Reduzir o requisito pode, portanto, fazer diferença para plataformas que gerenciam grandes bases de usuários, contas de tokens e estados de programas.

Menos SOL bloqueado pode melhorar a economia operacional dos protocolos

Se a redução total de 90% for concluída, projetos poderão criar contas com uma quantidade muito menor de SOL imobilizado. O impacto não é o mesmo que reduzir taxas de transação, mas pode melhorar a eficiência de capital para aplicações que dependem de grande volume de contas.

Isso pode ser particularmente relevante para produtos que precisam criar contas individuais para muitos usuários ou manter uma quantidade elevada de estado onchain. Menos capital preso significa maior flexibilidade para alocar recursos em outras partes da aplicação.

Ao mesmo tempo, a mudança precisa preservar o objetivo de evitar crescimento descontrolado de dados permanentes. Por isso, a Solana está adotando um rollout em cinco fases em vez de implementar imediatamente a redução máxima.

Agave 4.2 já inclui o código necessário, mas as alterações foram mantidas atrás de feature gates independentes.

Slots mais curtos avançam em ritmo separado

A terceira frente é velocidade. A Solana já reduziu o target de slot de 400 para 350 milissegundos. O roadmap prevê novas etapas em 300, 250 e, posteriormente, 200 milissegundos.

Não existem datas confirmadas para essas próximas reduções. Cada uma precisa ser ativada separadamente, permitindo que o desempenho dos validadores seja observado antes de avançar para o próximo estágio.

Slots menores aumentam a frequência com que os validadores produzem blocos e podem melhorar a velocidade percebida de confirmação. Porém, também reduzem o tempo disponível para comunicação e processamento entre os participantes do consenso.

Isso exige infraestrutura capaz de acompanhar o ritmo maior. A Solana pretende ajustar limites de recursos proporcionalmente durante o rollout para evitar que a busca por velocidade pressione excessivamente a rede.

O dia 9 de setembro não representa uma atualização completa de velocidade

É importante separar o calendário. Transaction V1 e os slots menores fazem parte da mesma estratégia geral de desempenho, mas não são o mesmo upgrade. A ativação de V1 em 9 de setembro não reduzirá automaticamente os slots e também não colocará Alpenglow em produção.

Essa distinção evita criar expectativas incorretas sobre o impacto imediato da data. O principal efeito previsto para 9 de setembro é a ampliação da capacidade de dados das transações. Outras melhorias seguirão seus próprios cronogramas.

Esse modelo de implementação também reduz o risco de uma alteração problemática afetar toda a evolução da rede de uma só vez.

Alpenglow representa uma mudança mais profunda no consenso

O Alpenglow é o componente mais ambicioso dessa sequência porque propõe uma reformulação do sistema de consenso da Solana. A meta apresentada é chegar a aproximadamente 150 milissegundos de finality após uma eventual ativação na mainnet.

A melhoria seria diferente de simplesmente produzir slots mais rapidamente. Finality se refere ao momento em que uma transação pode ser considerada definitivamente confirmada pela rede. Reduzir esse intervalo para cerca de 150 milissegundos representaria uma mudança relevante na experiência de aplicações que dependem de confirmações rápidas.

Por enquanto, o roadmap oficial mantém Alpenglow como “in development”. Agave 4.3 é esperado para outubro, e Creech apontou o mesmo mês como alvo atual. Isso, porém, não equivale a uma promessa de ativação mainnet em uma data específica.

O avanço depende de testes e apoio dos validadores

Antes que Alpenglow possa entrar em operação, a rede ainda precisa atravessar várias etapas. Transaction V1 precisa ser ativada, a redução de rent deve começar, os novos targets de slot precisam ser testados e o novo consenso terá de concluir seu próprio processo de validação.

O uso de feature gates separados permite que essas decisões sejam tomadas de maneira independente. Um atraso em Alpenglow não exige necessariamente adiar Transaction V1, da mesma forma que uma etapa de rent pode avançar mesmo que a próxima redução de slot ainda não esteja pronta.

Essa modularidade é uma parte importante da estratégia de engenharia. Em vez de atrelar toda a evolução da rede a um único hard fork de grande escala, Solana pode medir o efeito de cada modificação antes de combinar todos os ganhos.

O impacto inicial é técnico, não necessariamente de mercado

No momento da publicação, nenhum movimento verificado no preço da SOL havia sido atribuído diretamente ao anúncio de Creech. Isso significa que ainda não há base para relacionar os upgrades a uma reação específica do mercado.

O impacto mais imediato deve ser observado entre desenvolvedores, wallets, provedores de infraestrutura e validadores. A adoção de Transaction V1, a redução real de capital bloqueado e a capacidade dos validadores de operar com slots mais curtos serão indicadores mais concretos da eficácia do roadmap.

Conclusão

A Solana está avançando em várias mudanças estruturais, começando com Transaction V1 em 9 de setembro. O novo formato ampliará o tamanho das transações para 4.096 bytes, enquanto a primeira etapa da redução de rent deve começar antes e iniciar um caminho de cinco fases até uma economia potencial de 90%.

Paralelamente, a rede já reduziu os slots para 350 milissegundos e pretende avançar posteriormente para 300, 250 e 200 milissegundos. Alpenglow continua como alvo de outubro, mas sem uma data garantida de ativação na mainnet.

Ponto-chave final

O principal valor do roadmap está na combinação de melhorias diferentes, não em uma única atualização. Transaction V1 amplia capacidade, o rent menor reduz capital imobilizado, os slots mais curtos buscam acelerar produção de blocos e Alpenglow mira uma finality muito mais rápida. Se essas etapas forem implementadas sem comprometer estabilidade ou pressionar excessivamente os validadores, a Solana poderá melhorar desempenho e eficiência de forma mais ampla do que qualquer uma dessas mudanças isoladamente.