Skip to main content
O Agave 4.2 introduz a transação v1 (SIMD-0385). Assim que o gate de funcionalidades é ativado na mainnet, carteiras e programas começam a enviar transações v1, e qualquer solicitação que busca dados completos de transações deve optar por recebê-las. Esta página cobre o que muda, quais endpoints Helius são afetados e como atualizar seu código. Para a lista completa do Agave 4.2, incluindo tipos de recompensas, semântica de atualização de contas e temporização de slots, veja a lista de verificação de migração Agave 4.2.

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: 1 e 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 transactionConfig com computeUnitLimit, heapSize, loadedAccountsDataSizeLimit, e priorityFee. Não há instruções de programa ComputeBudget em uma transação v1.
O formato de transmissão também muda (um novo byte de versão e assinaturas no final da transação), mas isso só afeta o código que decodifica bytes de transações brutas. Veja Decode raw transaction bytes abaixo. Em respostas JSON, uma transação v1 relata "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. Defina maxSupportedTransactionVersion: 1 em: Uma solicitação que omite o parâmetro, ou o define como 0, falha com erro JSON-RPC -32015 assim que toca uma transação v1:
Para 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

Definir maxSupportedTransactionVersion: 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
Filtre em 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 RPC base64. 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 com 0x80.
  • 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 bincode que esperam um array de assinatura líder falham em bytes v1.
Layout byte a byte de uma transação Solana v1: byte de versão, cabeçalho, máscara de configuração, especificador de vida útil, contagens de endereço e instrução, três endereços de 32 bytes, configuração de unidade de computação, cabeçalho de instrução, índices, identificadores, lamports e uma assinatura de 64 bytes no final

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.

Para um passo a passo campo a campo do formato de fio v1, veja Transaction v1 in the Solana transaction versions article. Use um decodificador que entenda o layout v1:
  • Rust: agave-transaction-view analisa legados, v0 e v1 no lugar. wincode, o serializador compatível com bincode usado por SDKs Solana atuais, também decodifica v1 em VersionedTransaction.
  • JavaScript / TypeScript: @solana/kit 8.0+ ou @solana/web3.js v3.
Decodificadores personalizados precisam verificar o primeiro byte: 0x81 significa v1 e as assinaturas seguem a mensagem em vez de precedê-la.

Lista de Verificação

  1. Pesquise getBlock, getTransaction, getTransactionsForAddress, transactionSubscribe, e blockSubscribe, incluindo corpos JSON-RPC brutos e wrappers SDK como connection.getParsedTransaction.
  2. Atualize para um SDK compatível com v1.
  3. Defina maxSupportedTransactionVersion: 1 em cada chamada encontrada na etapa 1.
  4. Substitua a varredura de instruções ComputeBudget por uma verificação transactionConfig e trate priorityFee como lamports totais.
  5. Substitua decodificadores brutos estilo bincode por agave-transaction-view ou um SDK atualizado.
  6. Aumente as dependências de streaming para as versões na tabela acima.
  7. Verifique logs para -32015 após a mudança para confirmar que nada ainda falha.
Para um mergulho técnico nas especificações de versão de transações Solana, formatos de fio e exemplos, leia nosso artigo, Solana Transaction Versioning: Legacy, v0 and v1.

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.