Solana lança o Transaction v1 esta semana: a capacidade máxima das transações aumenta para 4096 bytes

A Solana lançará oficialmente a funcionalidade Transaction v1 na rede principal a 9 de setembro (quarta-feira), aumentando a capacidade máxima das transações de 1 232 bytes para 4 096 bytes — um aumento superior a três vezes. Esta 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. A nova funcionalidade tem funcionado de forma estável na rede de testes e na rede de desenvolvimento há algum tempo e será lançada oficialmente na rede principal a 9 de setembro de 2026.

A Transaction v1 foi concebida para manter a compatibilidade com versões anteriores, pelo que o formato v0 existente continuará válido. As carteiras e aplicações só adotarão o formato v1 quando precisarem de mais espaço para as transações, não havendo qualquer requisito de migração obrigatória.

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

Após o aumento da capacidade de 1 232 bytes para 4 096 bytes, os três tipos de transações seguintes serão os que mais beneficiarão diretamente:

Provas criptográficas de grandes dimensões: os dados de verificação, como as provas ZK, eram frequentemente divididos por várias transações por excederem o limite de 1 232 bytes. A Transaction v1 permite enviar todos os dados de verificação ZK numa única transação.

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

Transferências confidenciais: alguns mecanismos de transações privadas exigem camadas adicionais de encriptação, e a capacidade anterior era insuficiente, causando falhas ou reduzindo a eficiência das transações. Os 4 096 bytes proporcionam espaço suficiente para este tipo de operações.

Razões para estabelecer o limite em 4 096 bytes

O limite de 4 096 bytes (4 KB) resulta de considerações ao nível do hardware: este é o tamanho padrão das páginas de memória utilizadas pelos nós validadores. Se uma única transação atravessar várias páginas de memória, o custo de processamento aumenta significativamente, o que prejudica a manutenção do elevado TPS (transações por segundo) da Solana. Por isso, 4 KB representa um ponto de equilíbrio entre aumentar a capacidade e manter o desempenho da rede.

O antigo limite de 1 232 bytes tinha origem no design inicial da rede Solana — cada transação tinha de caber num 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 limite rígido. O lançamento da Transaction v1 representa a remoção formal desta limitação histórica de design.

Atualizações necessárias para nós RPC e serviços de consulta

A Transaction v1 tem um impacto maior nos serviços que leem dados da cadeia do que nas operações de escrita de transações. Todos os serviços que obtêm dados de blocos e transações — nós RPC, fornecedores de dados on-chain e backends de carteiras — têm de atualizar o código; caso contrário, devolverão diretamente um erro ao encontrar transações no formato v1.

Outro impacto concreto está na localização do campo da taxa de prioridade: a v1 armazena as informações relativas à taxa de prioridade num campo diferente do utilizado pela v0. Ao ler transações v1, o software antigo apresentará uma «taxa zero», mesmo que o utilizador tenha efetivamente pago uma taxa de prioridade. Se as interfaces das carteiras, os exploradores de blockchain e as aplicações de transações não forem atualizados, os utilizadores verão informações imprecisas sobre as taxas.

Comparação de capacidade com a Ethereum

Ao nível do design do protocolo, a Ethereum não tem um limite de tamanho das transações ao nível do protocolo: desde que paguem taxas de gas mais elevadas, os programadores podem executar operações com grandes volumes de dados numa única transação. No passado, a Solana tinha limitações evidentes quanto ao número de instruções que uma única transação podia conter. Após a Transaction v1 elevar o limite para 4 096 bytes, a diferença entre as duas cadeias diminuiu, mas 4 096 bytes ainda não é um valor elevado para a Ethereum L1 — uma operação complexa de composição DeFi na Ethereum, como uma arbitragem entre várias pools ou operações de empréstimo e reembolso com vários ativos, ultrapassa frequentemente esse número.

O significado técnico prático para o ecossistema Solana é a eliminação dos workarounds dos programadores: quando tinham de dividir as operações por várias transações, era necessário gerir dependências de estado entre transações e problemas de reversão após falhas. A Transaction v1 permite concluir lógicas complexas numa ú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, qual é a alteração da capacidade máxima e quais são as propostas que a definem?

A Solana Transaction v1 foi lançada na rede principal a 9 de setembro de 2026 (quarta-feira), aumentando a capacidade máxima das transações de 1 232 bytes para 4 096 bytes (mais de três vezes). A atualização foi definida pelas propostas SIMD-0296 e SIMD-0385, redigidas em conjunto por Jacob Creech e Andrew Fitzgerald, após um período de funcionamento estável na rede de testes e na rede de desenvolvimento.

Por que razão o limite de 4 096 bytes foi estabelecido neste valor, em vez de ser superior?

Os 4 096 bytes correspondem ao tamanho padrão das páginas de memória utilizadas pelos nós validadores. Se uma única transação atravessar várias páginas de memória, o custo de processamento aumenta significativamente, o que prejudica a manutenção do elevado TPS da Solana. Por isso, 4 KB representa um ponto de equilíbrio entre aumentar a capacidade e manter o desempenho da rede.

Como devem ser atualizados os nós RPC e os serviços de consulta, e qual é o impacto concreto da alteração do campo da taxa de prioridade?

Todos os serviços que obtêm dados de blocos e transações têm de atualizar o código; caso contrário, devolverão diretamente um erro ao encontrar transações v1. A localização do campo da taxa de prioridade da v1 é diferente da da v0, pelo que o software antigo apresentará uma «taxa zero» ao ler transações v1, mesmo que o utilizador tenha pago uma taxa de prioridade. Se as carteiras e os exploradores de blockchain não forem atualizados, apresentarão informações imprecisas sobre as taxas.