Solana lançará o Transaction v1 nesta semana: o tamanho máximo das transações será ampliado para 4.096 bytes

A Solana lançará oficialmente o recurso Transaction v1 na mainnet em 9 de setembro (quarta-feira), ampliando o tamanho máximo das transações de 1.232 bytes para 4.096 bytes, um aumento de mais de três vezes. A atualização é definida por duas propostas de melhoria da Solana: a SIMD-0296 (transações maiores) e a SIMD-0385 (formato Transaction v1).

Especificações técnicas da Transaction v1

A Transaction v1 é definida conjuntamente por duas propostas de melhoria da Solana: a SIMD-0296 estabelece um limite maior para as transações, enquanto a SIMD-0385 define o formato da Transaction v1. Ambas foram redigidas em conjunto por Jacob Creech e Andrew Fitzgerald. O novo recurso está funcionando de forma estável na testnet e na devnet há algum tempo e entrará oficialmente em operação na mainnet em 9 de setembro de 2026.

A Transaction v1 adota um design compatível com versões anteriores, e o formato v0 existente continuará válido. Carteiras e aplicações só adotarão o formato v1 quando precisarem de mais espaço para as transações, sem necessidade de migração.

Três tipos de transações que mais se beneficiarão diretamente da Transaction v1

Com o aumento do tamanho máximo de 1.232 bytes para 4.096 bytes, os três tipos de transação a seguir serão os mais beneficiados:

Grandes provas criptográficas: dados de verificação, como provas ZK, frequentemente precisavam ser divididos em várias transações por excederem o limite de 1.232 bytes. A Transaction v1 permite enviar todos os dados de verificação ZK em uma única transação.

Processos de aprovação com múltiplas assinaturas: transferências de fundos que exigem a aprovação de vários signatários, como as de tesourarias corporativas ou propostas de DAOs, ocupam espaço com cada assinatura. A v1 permite concluir o processo de aprovação com múltiplas assinaturas em uma única transação.

Transferências confidenciais: alguns mecanismos de transações privadas exigem camadas adicionais de criptografia, e a capacidade original insuficiente fazia com que as transações falhassem ou tivessem sua eficiência reduzida. Os 4.096 bytes oferecem espaço suficiente para esse tipo de operação.

Por que o limite foi definido em 4.096 bytes

A definição do limite em 4.096 bytes (4 KB) considera aspectos de hardware: esse é o tamanho padrão das páginas de memória usadas pelos nós validadores. Se uma única transação atravessar várias páginas de memória, o custo de processamento aumentará significativamente, prejudicando a manutenção do alto TPS (transações por segundo) da Solana. Por isso, 4 KB é o ponto de equilíbrio entre ampliar a capacidade e manter o desempenho da rede.

O antigo limite de 1.232 bytes teve origem no design de rede inicial da Solana: cada transação precisava caber em um pacote IP de aproximadamente 1.280 bytes. Em 2022, a Solana ajustou a forma de transmissão do tráfego de transações, tornando desnecessário esse teto rígido. O lançamento da Transaction v1 representa a remoção formal dessa limitação histórica de design.

Atualizações necessárias nos nós RPC e nos serviços de leitura

A Transaction v1 afeta mais os serviços que leem dados on-chain do que as transações que os gravam. Todos os serviços que coletam dados de blocos e transações — incluindo nós RPC, provedores de dados on-chain e backends de carteiras — devem atualizar seu código. Caso contrário, retornarão um erro ao encontrar transações no formato v1.

Outro impacto concreto está na posição do campo da taxa de prioridade: a v1 armazena as informações da taxa de prioridade em um campo diferente daquele usado pela v0. Softwares antigos, ao lerem transações v1, exibirão “taxa de prioridade zero”, mesmo que o usuário tenha efetivamente pago a taxa de prioridade. Se as interfaces de carteiras, os exploradores de blockchain e os aplicativos de transações não forem atualizados, os usuários verão informações imprecisas sobre as taxas.

Comparação de capacidade com a Ethereum

Em termos de design de protocolo, a rede Ethereum não possui um limite de tamanho de transação no nível do protocolo. Os desenvolvedores podem executar operações com uso intensivo de dados em uma única transação, desde que paguem uma taxa de gas mais alta. No passado, a Solana apresentava limitações significativas quanto à quantidade de instruções que uma única transação podia comportar. Após a Transaction v1 elevar o limite para 4.096 bytes, a diferença entre as duas redes diminuiu, mas 4.096 bytes ainda não representam um tamanho muito grande para a Ethereum L1. Uma transação complexa de composição DeFi na Ethereum, como uma arbitragem entre vários pools ou empréstimos e devoluções de vários ativos, frequentemente ultrapassa esse número.

Na prática, o significado técnico para o ecossistema da Solana está na eliminação das soluções alternativas para desenvolvedores. Quando era necessário dividir as operações em várias transações, era preciso lidar com dependências de estado entre transações e problemas de reversão em caso de falha. A Transaction v1 permite concluir lógicas complexas em uma única operação atômica, aproximando-se mais dos padrões tradicionais de programação.

Perguntas frequentes

Qual é a data de lançamento da Solana Transaction v1, como mudou o tamanho máximo e quais propostas a definem?

A Solana Transaction v1 será lançada na mainnet em 9 de setembro de 2026 (quarta-feira), com o tamanho máximo das transações aumentando de 1.232 bytes para 4.096 bytes (mais de três vezes). A atualização é definida pelas propostas SIMD-0296 e SIMD-0385, redigidas em conjunto por Jacob Creech e Andrew Fitzgerald, e já estava funcionando de forma estável na testnet e na devnet.

Por que o limite de 4.096 bytes foi definido nesse número, e não em um valor maior?

4.096 bytes é o tamanho padrão das páginas de memória usadas pelos nós validadores. Se uma única transação atravessar várias páginas de memória, o custo de processamento aumentará significativamente, prejudicando a manutenção do alto TPS da Solana. Assim, 4 KB é o ponto de equilíbrio entre ampliar a capacidade e manter o desempenho da rede.

Como os nós RPC e os serviços de leitura precisam ser atualizados, e qual é o impacto concreto da mudança no campo da taxa de prioridade?

Todos os serviços que coletam dados de blocos e transações devem atualizar seu código. Caso contrário, retornarão um erro ao encontrar transações v1. A posição do campo da taxa de prioridade na v1 é diferente daquela usada pela v0, e softwares antigos exibirão “taxa de prioridade zero” ao lerem transações v1, mesmo que o usuário tenha pago a taxa de prioridade. Se as carteiras e os exploradores de blockchain não forem atualizados, exibirão informações imprecisas sobre as taxas.