Perubahan dalam transaksi v1
Transaksi lama dan v0 tidak berubah. Untuk sebagian besar integrasi, ada dua hal penting mengenai transaksi v1:- Anda harus memilih untuk menerimanya. Permintaan data transaksi lengkap memerlukan
maxSupportedTransactionVersion: 1, dan pustaka klien Anda harus menggunakan versi yang dapat melakukan deserialisasi v1. - Anggaran komputasi dipindahkan ke header pesan. Pesan v1 membawa objek
transactionConfigdengancomputeUnitLimit,heapSize,loadedAccountsDataSizeLimit, danpriorityFee. Tidak ada instruksi program ComputeBudget dalam transaksi v1.
"version": 1 dan message-nya menyertakan transactionConfig:
"priorityFee": 50000 berarti transaksi ini membayar total 50.000 lamport. Kolom null berarti pengirim tidak menetapkannya. Pesan lama dan v0 sepenuhnya menghilangkan transactionConfig.
Atur maxSupportedTransactionVersion ke 1
Setiap permintaan yang mengembalikan data transaksi lengkap harus mendeklarasikan versi transaksi tertinggi yang dapat ditanganinya. AturmaxSupportedTransactionVersion: 1 pada:
getTransactiongetBlockgetTransactionsForAddressdengantransactionDetails: "full"transactionSubscribedengantransactionDetails: "accounts"atau"full"blockSubscribe
0, akan gagal dengan kesalahan JSON-RPC -32015 begitu permintaan tersebut menemukan transaksi v1:
getBlock, satu transaksi v1 di bagian mana pun dalam blok akan menyebabkan seluruh permintaan gagal. Jika Anda melihat -32015 dalam log, berarti proyek tersebut sudah mengalami kegagalan pada transaksi berversi.
Tingkatkan SDK Anda sebelum menaikkan nilainya
MengaturmaxSupportedTransactionVersion: 1 memberi tahu node agar mengembalikan transaksi v1. Pustaka klien Anda tetap harus dapat melakukan deserialisasi transaksi tersebut. Lakukan peningkatan terlebih dahulu, lalu ubah parameternya:
Implementasi
VersionedTransaction.deserialize lama dalam JavaScript hanya menangani transaksi lama dan v0 serta memunculkan kesalahan pada byte 0x81 di awal. Proto Yellowstone lama dibuat sebelum kolom pesan v1 tersedia, sehingga pengguna gRPC pada versi tersebut tidak pernah melihat transactionConfig. Untuk klien gRPC Go, buat ulang dari proto Yellowstone terbaru dan solana-storage-proto.
Baca biaya prioritas dari transactionConfig
Kode yang memperkirakan biaya prioritas transaksi dengan memindai instruksi program ComputeBudget (ComputeBudget111111111111111111111111111111, setComputeUnitPrice, setComputeUnitLimit) akan membaca setiap transaksi v1 seolah-olah membayar nol. Pada v1, nilainya berada di message.transactionConfig, dan satuannya berbeda:
Jangan terapkan perhitungan
price × computeUnitLimit ÷ 1e6 lama ke priorityFee. Nilai tersebut sudah merupakan total.
priority-fee.ts
transactionConfig (atau version === 1), bukan berdasarkan keberadaan instruksi ComputeBudget, karena transaksi lama tanpa biaya prioritas juga tidak memilikinya.
Dekode byte transaksi mentah dengan parser yang mendukung v1
Bagian ini hanya berlaku jika Anda menggunakan byte transaksi mentah, misalnya dari preconfSubscribe, preprocessedSubscribe, atau respons RPC yang dikodekan denganbase64. Jika Anda menggunakan respons json atau jsonParsed, lewati bagian ini.
Transaksi v1 mengubah tata letak wire dalam dua hal:
- Byte versi. Transaksi v1 dimulai dengan
0x81(desimal 129). Transaksi v0 dimulai dengan0x80. - Tanda tangan dipindahkan ke akhir. Transaksi lama dan v0 menempatkan tanda tangan terlebih dahulu, lalu pesan. Transaksi v1 menempatkan pesan terlebih dahulu dan tanda tangan di akhir, sehingga dekoder bergaya
bincodeyang mengharapkan array tanda tangan di awal akan gagal pada byte v1.

Byte layout of a transaction v1 with three addresses and one instruction. The signature sits at the end, after the message.
- Rust:
agave-transaction-viewmengurai transaksi lama, v0, dan v1 secara langsung.wincode, serializer kompatibel bincode yang digunakan oleh SDK Solana saat ini, juga mendekode v1 menjadiVersionedTransaction. - JavaScript / TypeScript:
@solana/kit8.0+ atau@solana/web3.jsv3.
0x81 berarti v1 dan tanda tangan ditempatkan setelah pesan, bukan sebelumnya.
Daftar periksa
- Cari dengan grep
getBlock,getTransaction,getTransactionsForAddress,transactionSubscribe, danblockSubscribe, termasuk isi JSON-RPC mentah dan wrapper SDK seperticonnection.getParsedTransaction. - Tingkatkan ke SDK yang mendukung v1.
- Atur
maxSupportedTransactionVersion: 1pada setiap pemanggilan yang ditemukan pada langkah 1. - Ganti pemindaian instruksi ComputeBudget dengan pemeriksaan
transactionConfig, dan perlakukanpriorityFeesebagai total lamport. - Ganti dekoder mentah bergaya
bincodedenganagave-transaction-viewatau SDK yang telah ditingkatkan. - Tingkatkan dependensi streaming ke versi dalam tabel di atas.
- Cari
-32015dalam log dengan grep setelah perubahan untuk memastikan tidak ada yang masih gagal.
Terkait
getTransaction guide
Parameter, bentuk respons, dan contoh untuk mengambil satu transaksi.
getBlock guide
Ambil blok lengkap, termasuk setiap transaksi di dalamnya.
getTransactionsForAddress
Riwayat transaksi yang difilter dan diberi paginasi untuk alamat apa pun dalam satu pemanggilan.
Agave 4.2 migration checklist
Setiap perubahan besar Agave 4.2, beserta langkah-langkah perbaikannya.