Skip to main content
Metode RPC getRecentPrioritizationFees memberikan informasi tentang biaya prioritas yang dibayarkan dalam blok terbaru di jaringan Solana. Dengan memeriksa biaya ini, developer dapat membuat keputusan yang lebih tepat mengenai biaya tambahan (biaya prioritas) yang akan ditambahkan ke transaksi mereka untuk meningkatkan kemungkinan transaksi diproses dengan cepat, terutama selama periode aktivitas jaringan yang tinggi. Node biasanya menyimpan data biaya prioritas dalam cache hingga 150 blok terbaru.

Kasus Penggunaan Umum

  • Estimasi Biaya Dinamis: Tentukan biaya prioritas yang kompetitif untuk suatu transaksi dengan mengamati biaya yang baru-baru ini berhasil digunakan.
  • Analisis Kemacetan: Pahami kondisi kemacetan jaringan saat ini dengan melihat tingkat biaya prioritas yang dibayarkan.
  • Integrasi Dompet: Memungkinkan dompet menyarankan biaya prioritas yang sesuai kepada pengguna berdasarkan kondisi jaringan terbaru.
  • Bot Arbitrase: Untuk operasi yang sensitif terhadap waktu seperti arbitrase, menetapkan biaya prioritas yang optimal sangat penting agar eksekusi berlangsung tepat waktu.

Parameter Permintaan

  1. lockedWritableAccounts (array dari string, opsional):
    • Array berisi kunci publik akun yang dikodekan dalam base-58 dan ingin dikunci untuk penulisan oleh transaksi Anda.
    • Maksimal 128 alamat dapat diberikan.
    • Jika diberikan, metode ini mengembalikan biaya prioritas yang dibayarkan oleh transaksi yang mengunci semua akun yang ditentukan sebagai dapat ditulis.
    • Jika tidak diberikan atau array kosong diteruskan, metode ini mengembalikan gambaran yang lebih umum tentang biaya prioritas yang diamati di berbagai blok terbaru, tanpa terbatas pada kumpulan akun tertentu.

Struktur Respons

Kolom result dalam respons JSON-RPC adalah array objek biaya prioritas. Setiap objek merinci biaya dari slot terbaru tertentu dan memiliki struktur berikut:
  • slot (u64): Nomor slot tempat transaksi yang berkontribusi pada data biaya ini diproses.
  • prioritizationFee (u64): Biaya prioritas minimum (dalam mikro-Lamport per Compute Unit) yang dibayarkan oleh setidaknya satu transaksi dalam slot ini (dan sesuai dengan filter lockedWritableAccounts, jika ada). Nilai 0 sering kali berarti tidak ada transaksi dalam slot tersebut (yang sesuai dengan kriteria) yang membayar biaya prioritas tambahan di luar biaya dasar, atau node tidak mengamati transaksi semacam itu untuk akun yang diberikan.

Contoh

1. Mendapatkan Biaya Prioritas Global Terbaru

Contoh ini mengambil daftar umum biaya prioritas terbaru tanpa menentukan akun yang dikunci.

2. Mendapatkan Biaya Prioritas Terbaru untuk Akun Tertentu yang Dapat Ditulis

Contoh ini mengambil biaya prioritas yang relevan untuk transaksi yang perlu mengunci dua akun tertentu untuk penulisan.

Tips untuk Developer

  • Satuan Biaya: Biaya prioritas dinyatakan dalam mikro-Lamport (0,000001 Lamport) per Compute Unit (CU).
  • Rentang Cache: Node RPC biasanya menyimpan biaya ini dalam cache selama sekitar 150 blok. Artinya, Anda melihat rentang historis yang relatif singkat (sekitar 1–2 menit).
  • Biaya Nol: prioritizationFee dengan nilai 0 tidak selalu berarti tidak ada biaya yang dibayarkan, tetapi untuk slot dan akun yang diberikan, transaksi yang dijadikan sampel tidak menyertakan biaya prioritas atau berada di bawah ambang batas yang dianggap signifikan oleh node.
  • Penggunaan Strategis: Jangan hanya memilih biaya terbaru yang tertinggi. Analisis distribusinya (misalnya, median atau persentil ke-75 dari biaya yang bukan nol) untuk membuat pilihan yang hemat biaya. Membayar terlalu mahal tidak menjamin penyertaan yang lebih cepat setelah titik tertentu jika blok sudah penuh dengan transaksi berprioritas tinggi.
  • Compute Unit: Total biaya prioritas untuk transaksi Anda adalah prioritizationFee_per_CU * your_transaction_compute_units. Anda juga perlu menetapkan batas compute unit untuk transaksi Anda (ComputeBudgetProgram.setComputeUnitLimit) dan harganya (ComputeBudgetProgram.setComputeUnitPrice).
Menggunakan getRecentPrioritizationFees secara efektif dapat meningkatkan keandalan konfirmasi transaksi secara signifikan dalam kondisi jaringan yang dinamis.