Transações Solana V1 chegam à testnet, visando consolidar operações multi-etapa em uma única

Em 1º de setembro, a Anza iniciou a Transação V1 na testnet da Solana, permitindo o ensaio final desta atualização antes do seu lançamento em 9 de setembro.

A alteração visa permitir que cargas de trabalho criptográficas e DeFi, que inicialmente precisavam ser fragmentadas em diferentes transações, sejam agora processadas em uma única transação atômica, conforme declarado pela Solana Compass.

Tarefas que antes eram divididas agora cabem em uma única chamada

A alteração mais notável é o aumento no espaço. O tamanho máximo de uma transação serializada da Solana aumentou de 1.232 bytes para 4.096 bytes, um incremento de 3,3 vezes, entrando em vigor na epoch 1025 da testnet.

De acordo com o site dedicado à grande atualização de transações da Fundação Solana, esse tamanho maior de transação permitirá a implementação de provas de conhecimento zero, grandes transações multissignatura e vários esquemas de assinatura que antes não eram possíveis dentro de uma única transação.

Como resultado, menos transações precisam ser processadas, há menor necessidade de fundos para pagar por assinaturas e não é necessário aguardar uma cadeia de confirmações. Esquemas de assinatura BLS, bem como transações confidenciais e configurações multisig, se beneficiarão desta atualização.

Existem duas propostas principais essenciais para a melhoria. A SIMD-0296 aumenta o tamanho da transação de 1.232 bytes para 4.096 bytes, enquanto a SIMD-0385 define o formato de mensagem V1 e move a configuração da transação para o próprio message.

Menos de um dia após a ativação da atualização, o CEO da Anza, Brennan Watt, fez uma postagem no X mencionando uma grande transação no explorador da testnet com a mensagem: “ATENÇÃO: grandes transações chegaram à testnet.”

Por que uma transação supera um pacote

A importância da atomicidade decorre do fato de que, às vezes, os desenvolvedores contornavam o antigo limite de tamanho da Solana usando bundles Jito. Na verdade, a SIMD-0296 explica essa solução alternativa e menciona que os bundles carecem de atomicidade ao nível do protocolo, como ocorre com uma transação nativa.

De acordo com a documentação da Jito, os bundles podem incluir até cinco transações processadas sequencialmente em uma base de tudo ou nada. No entanto, os bundles operam dentro do block-engine da Jito e competem entre as gorjetas dos validadores. A transação V1, por outro lado, refere-se a uma única transação nativa da Solana, que carrega a garantia de atomicidade ao nível da transação da Solana.

Para desenvolvedores DeFi, isso pode ajudar a simplificar a criação de rotas de swap, provas e outros tipos de transações multietapas. Se a operação for totalmente coberta pela transação V1, ela ou será concluída com sucesso ou retornada como uma transação nativa única, em vez de depender de um pacote de transações.

O que o DeFi ganha além de bytes extras

A V1 também modifica a estrutura da transação. Enquanto o Legacy e o V0 processam taxas de prioridade e solicitações de recursos usando instruções ComputeBudget, a SIMD-0385 incorpora essas configurações nas configurações de transação da V1, simplificando assim a tarefa dos validadores ao identificar necessidades de recursos sem precisar buscar ativamente na lista de instruções.

A V1 também elimina as Tabelas de Consulta de Endereços (ALTs), utilizadas pelo V0 para encurtar endereços de contas. De acordo com a análise da Fundação sobre a compensação das ALTs na V1, a V1 realiza a inserção de endereços diretamente no código. Isso torna a entrada do validador mais fácil em comparação com o método usado em aplicações pesadas de contas na V0, que consomem mais bytes quando convertidos.

O benefício prático para roteadores e agregadores DEX é que agora há mais espaço para rotas atômicas complexas. No entanto, essa melhoria não vem sem limitações. De fato, a capacidade máxima do Solana de 64 contas diferentes permanece inalterada, e assim aplicações que exigem uso intensivo de contas ainda podem sofrer com essa limitação, mesmo que a capacidade baseada em limite de bytes não seja mais um problema.

A atualização está sendo introduzida enquanto a Solana dá um salto rumo às finanças on-chain. O relatório sobre a Solana para o segundo trimestre de 2026 fornecido pela Galaxy destaca o aumento da atividade de stablecoins, ações tokenizadas e ativos do mundo real.

De acordo com a Galaxy, no futuro, o potencial da Solana dependerá em grande parte da capacidade de usar ativos em empréstimos, colateralização, margem e rendimento, em vez de apenas emissão ou negociação. Com base nos dados da DeFiLlama sobre a Solana, a plataforma parece ter uma forte presença em DeFi.

Além disso, o momento do upgrade coincide com a fase de atualização Agave 4.2. Informativamente, a Cryptopolitan afirmou que o plano para implementação gradual da redução de custos deveria levar a economias de cerca de 90%, juntamente com a diminuição do tempo necessário para processamento de 500 para 200 milissegundos, gerando benefícios para emissores de stablecoins, provedores de carteiras e sistemas de pagamento.

Operadores de RPC têm uma semana para atualizar

A V1 é opcional, portanto as transações Legacy e V0 continuam funcionando. A questão é se a infraestrutura que lê o tráfego da V1 está preparada.

A Anza obrigou os provedores RPC a migrarem para Agave v4.2.2 ou v4.3.0-beta.3. O checklist de migração Helius Agave 4.2 também enfatiza que consumidores RPC que não declararem conformidade V1 podem experimentar falhas de chamada, como getBlock, quando uma transação V1 é utilizada.

O processo começou com testes locais da V1 em 24 de agosto, pouco depois dos quais a data da mainnet foi confirmada como 9 de setembro em 29 de agosto. A V1 habilitou a Testnet em 1º de setembro no epoch 1025, com ativação agendada na mainnet em 9 de setembro.

Esta última execução da testnet serve como o último passo preparatório para provedores de RPC, indexadores, carteiras, SDKs e plataformas analíticas antes do lançamento da mainnet.