O que muda na transação v1
Transações legadas e v0 não são alteradas. Para a maioria das integrações, duas coisas sobre a transação v1 são importantes:- Você deve optar por recebê-la. Solicitações para dados completos de transações precisam
maxSupportedTransactionVersion: 1e sua biblioteca cliente precisa de uma versão que possa desserializar v1. - O orçamento de computação move-se para o cabeçalho da mensagem. Uma mensagem v1 carrega um objeto
transactionConfigcomcomputeUnitLimit,heapSize,loadedAccountsDataSizeLimit, epriorityFee. Não há instruções de programa ComputeBudget em uma transação v1.
"version": 1 e seu message inclui transactionConfig:
"priorityFee": 50000 significa que essa transação paga 50.000 lamports no total. Um campo null significa que o remetente não o definiu. Mensagens legadas e v0 omitem transactionConfig completamente.
Defina maxSupportedTransactionVersion para 1
Toda solicitação que retorna dados completos de transações deve declarar a maior versão de transação que pode lidar. DefinamaxSupportedTransactionVersion: 1 em:
getTransactiongetBlockgetTransactionsForAddresscomtransactionDetails: "full"transactionSubscribecomtransactionDetails: "accounts"ou"full"blockSubscribe
0, falha com erro JSON-RPC -32015 assim que toca uma transação v1:
getBlock, uma transação v1 em qualquer lugar do bloco falha em toda a solicitação. Se você ver -32015 nos seus logs, o projeto já está falhando em transações com versão.
Atualize seu SDK antes de aumentar o valor
DefinirmaxSupportedTransactionVersion: 1 informa ao nó para retornar transações v1. Sua biblioteca cliente ainda tem que desserializá-las. Atualize primeiro, depois mude o parâmetro:
Implementações mais antigas
VersionedTransaction.deserialize em JavaScript lidam apenas com legado e v0 e lançam em um byte líder 0x81. Protos mais antigos do Yellowstone são anteriores aos campos de mensagem v1, então consumidores gRPC nessas versões nunca veem transactionConfig. Para clientes gRPC em Go, regenere a partir dos protos Yellowstone mais recentes e solana-storage-proto.
Leia taxas prioritárias de transactionConfig
O código que estima a taxa prioritária de uma transação ao escanear instruções de programa ComputeBudget (ComputeBudget111111111111111111111111111111, setComputeUnitPrice, setComputeUnitLimit) lê toda transação v1 como pagando zero. No v1 os valores estão em message.transactionConfig, e as unidades diferem:
Não porte a matemática legada
price × computeUnitLimit ÷ 1e6 para priorityFee. Já é o total.
priority-fee.ts
transactionConfig (ou em version === 1) em vez de na presença de instruções ComputeBudget, já que uma transação legada sem taxa prioritária também não tem nenhuma.
Decodifique bytes de transações brutas com um parser compatível com v1
Esta seção só se aplica se você consumir bytes de transações brutas, por exemplo, de preconfSubscribe, preprocessedSubscribe, ou uma resposta codificada RPCbase64. Se você trabalhar com respostas json ou jsonParsed, ignore.
A transação v1 altera o layout do fio de duas maneiras:
- Byte de versão. Uma transação v1 começa com
0x81(decimal 129). Uma transação v0 começa com0x80. - Assinaturas movem-se para o final. Legado e v0 colocam assinaturas primeiro, depois a mensagem. A transação v1 coloca a mensagem primeiro e as assinaturas por último, assim decodificadores
bincodeque esperam um array de assinatura líder falham em bytes v1.

Layout em bytes de uma transação v1 com três endereços e uma instrução. A assinatura fica no final, após a mensagem.
- Rust:
agave-transaction-viewanalisa legados, v0 e v1 no lugar.wincode, o serializador compatível com bincode usado por SDKs Solana atuais, também decodifica v1 emVersionedTransaction. - JavaScript / TypeScript:
@solana/kit8.0+ ou@solana/web3.jsv3.
0x81 significa v1 e as assinaturas seguem a mensagem em vez de precedê-la.
Lista de Verificação
- Pesquise
getBlock,getTransaction,getTransactionsForAddress,transactionSubscribe, eblockSubscribe, incluindo corpos JSON-RPC brutos e wrappers SDK comoconnection.getParsedTransaction. - Atualize para um SDK compatível com v1.
- Defina
maxSupportedTransactionVersion: 1em cada chamada encontrada na etapa 1. - Substitua a varredura de instruções ComputeBudget por uma verificação
transactionConfige tratepriorityFeecomo lamports totais. - Substitua decodificadores brutos estilo
bincodeporagave-transaction-viewou um SDK atualizado. - Aumente as dependências de streaming para as versões na tabela acima.
- Verifique logs para
-32015após a mudança para confirmar que nada ainda falha.
Relacionado
Guia getTransaction
Parâmetros, formato de resposta e exemplos para buscar uma única transação.
Guia getBlock
Busque um bloco completo, incluindo todas as transações que ele contém.
getTransactionsForAddress
Histórico de transações filtrado e paginado para qualquer endereço em uma chamada.
Lista de verificação de migração Agave 4.2
Todas as mudanças de quebra do Agave 4.2, com etapas de remediação.