O formato de transação v1 da Solana eleva o teto de payload por transação de 1.232 bytes para 4.096 bytes, um salto de cerca de 3,3x, e já está em execução na testnet e na devnet (epoch 1140). A ativação na mainnet continua pendente na página oficial de upgrades da Solana, com um changelog de 28 de agosto a indicar que as transações v1 estavam "a chegar". Esta janela é a antecâmara de duas armadilhas de compatibilidade muito diferentes para a infraestrutura circundante: clientes RPC que não forem atualizados podem congelar logo ao deparar-se com uma transação v1, enquanto indexers, relayers e patrocinadores de taxas podem continuar a correr e reportar silenciosamente limites de recursos errados.
Por que importa
O aumento de payload que aparece nos títulos é o argumento de venda do upgrade, mas os modos de falha estão nas tubagens que a maioria dos utilizadores nunca vê. Clientes RPC que não passem maxSupportedTransactionVersion: 1 recebem o erro -32015 em pedidos v1 getTransaction, veem getBlock falhar por completo quando uma transação v1 cai num bloco, e assistem a blockSubscribe emitir block: null e parar de avançar no primeiro slot afetado. O risco mais silencioso mora no tratamento de ComputeBudget. A v1 move os limites de compute units, os limites de dados de contas carregadas e as priority fees para um objeto transactionConfig, pelo que qualquer indexer que continue a ler instruções ComputeBudget reportará um orçamento zero sem qualquer erro, e qualquer relayer que aplique um limite de taxa lendo essas instruções vê-as executar como no-ops, retirando o limite vinculativo que julgava estar a aplicar. Consumidores Geyser e gRPC enfrentam uma armadilha relacionada de etiqueta de versão porque o flag versioned do protobuf é true tanto para v0 como para v1, permitindo que stubs desatualizados persistam um orçamento vazio.
Impacto no mercado
A Solana enquadra isto como uma falha de controlo da aplicação e não como uma falha de consenso, pelo que os fundos não estão automaticamente em risco. O raio de impacto, porém, cobre todos os paymasters, explorers, stacks de custódia e programas on-chain que introspetam ComputeBudget, uma vez que nenhum sysvar ou syscall atual expõe a configuração de mensagens v1.
Perguntas frequentes
-
O que é o formato de transação v1 da Solana?
É um formato de transação melhorado que eleva o teto de payload por transação da Solana de 1.232 bytes para 4.096 bytes, um aumento de cerca de 3,3x. As transações legacy e v0 mantêm os seus limites e comportamento atuais, pelo que as aplicações que permanecem nesses formatos não precisam de migrar.
-
Como é que o bug de congelamento da v1 afeta os clientes RPC?
Clientes RPC que não passam maxSupportedTransactionVersion: 1 recebem o erro -32015 em pedidos v1 getTransaction, partem getBlock por completo quando uma transação v1 cai num bloco, e veem blockSubscribe emitir block: null e congelar no primeiro slot afetado.
-
Por que estão as verificações de limite de taxa da v1 a falhar silenciosamente?
A v1 move os limites de compute units, os limites de dados de contas carregadas e as priority fees para um objeto transactionConfig. Relayers e paymasters que aplicam limites de taxa lendo instruções ComputeBudget veem essas instruções executar como no-ops na v1, pelo que o limite deixa de vincular sem gerar qualquer…
-
Os fundos dos utilizadores estão em risco com o upgrade Solana v1?
Não. A análise enquadra isto como uma falha de controlo da aplicação e não como uma falha de consenso, e os fundos dos utilizadores não estão automaticamente em risco. O risco reside em relayers, explorers, stacks de custódia e programas on-chain que introspetam ComputeBudget e precisam de atualizações antes de a v1…
-
Que versões de software tratam a Solana v1 corretamente?
As versões com capacidade de leitura incluem @solana/kit 8.0.0, @solana/web3.js 3.0.0-rc.3, Rust solana-* 4.2.x, Python solders 0.29.0, solana-go 1.23.0, yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1 e gRPC client 12.0.0, consoante a stack.
WatcherGuru
Crypto News
CoinTelegraph
TheBlock
WuBlockchain