Skip to main content
Agave 4.2 memperkenalkan transaksi v1 (SIMD-0385). Setelah gerbang fitur aktif di mainnet, dompet dan program akan mulai mengirimkan transaksi v1, dan setiap permintaan yang mengambil data transaksi lengkap harus memilih untuk menerimanya. Halaman ini membahas perubahan yang terjadi, endpoint Helius yang terdampak, dan cara memperbarui kode Anda. Untuk daftar periksa lengkap Agave 4.2, termasuk jenis reward, semantik pembaruan akun, dan waktu slot, lihat daftar periksa migrasi Agave 4.2.

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 transactionConfig dengan computeUnitLimit, heapSize, loadedAccountsDataSizeLimit, dan priorityFee. Tidak ada instruksi program ComputeBudget dalam transaksi v1.
Format wire juga berubah (byte versi baru dan tanda tangan di akhir transaksi), tetapi hal ini hanya memengaruhi kode yang mendekode byte transaksi mentah. Lihat Mendekode byte transaksi mentah di bawah ini. Dalam respons JSON, transaksi v1 melaporkan "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. Atur maxSupportedTransactionVersion: 1 pada: Permintaan yang menghilangkan parameter tersebut, atau mengaturnya ke 0, akan gagal dengan kesalahan JSON-RPC -32015 begitu permintaan tersebut menemukan transaksi v1:
Untuk 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

Mengatur maxSupportedTransactionVersion: 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
Buat percabangan berdasarkan 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 dengan base64. 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 dengan 0x80.
  • 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 bincode yang mengharapkan array tanda tangan di awal akan gagal pada byte v1.
Byte-by-byte layout of a Solana transaction v1: version byte, header, config mask, lifetime specifier, address and instruction counts, three 32-byte addresses, compute unit config, instruction header, indices, discriminators, lamports, and a 64-byte signature at the end

Byte layout of a transaction v1 with three addresses and one instruction. The signature sits at the end, after the message.

Untuk panduan setiap kolom dalam format wire v1, lihat Transaksi v1 dalam artikel versi transaksi Solana. Gunakan dekoder yang memahami tata letak v1:
  • Rust: agave-transaction-view mengurai transaksi lama, v0, dan v1 secara langsung. wincode, serializer kompatibel bincode yang digunakan oleh SDK Solana saat ini, juga mendekode v1 menjadi VersionedTransaction.
  • JavaScript / TypeScript: @solana/kit 8.0+ atau @solana/web3.js v3.
Dekoder khusus perlu memeriksa byte pertama: 0x81 berarti v1 dan tanda tangan ditempatkan setelah pesan, bukan sebelumnya.

Daftar periksa

  1. Cari dengan grep getBlock, getTransaction, getTransactionsForAddress, transactionSubscribe, dan blockSubscribe, termasuk isi JSON-RPC mentah dan wrapper SDK seperti connection.getParsedTransaction.
  2. Tingkatkan ke SDK yang mendukung v1.
  3. Atur maxSupportedTransactionVersion: 1 pada setiap pemanggilan yang ditemukan pada langkah 1.
  4. Ganti pemindaian instruksi ComputeBudget dengan pemeriksaan transactionConfig, dan perlakukan priorityFee sebagai total lamport.
  5. Ganti dekoder mentah bergaya bincode dengan agave-transaction-view atau SDK yang telah ditingkatkan.
  6. Tingkatkan dependensi streaming ke versi dalam tabel di atas.
  7. Cari -32015 dalam log dengan grep setelah perubahan untuk memastikan tidak ada yang masih gagal.
Untuk pembahasan teknis mendalam mengenai spesifikasi versi transaksi Solana, format wire, dan contoh, baca artikel kami, Pembuatan Versi Transaksi Solana: Lama, v0, dan v1.

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.