Cara Memastikan Transaksi Berhasil Masuk di Solana

Transaksi

Eksekusi program dimulai dengan transaksi yang dikirim ke cluster. Sebuah transaksi berisi:

• Array berisi semua account yang akan dibaca atau ditulisi
• Satu atau beberapa instruksi (yaitu unit eksekusi terkecil)
• Blockhash terbaru
• Satu atau beberapa tanda tangan

Runtime akan memproses setiap instruksi dalam transaksi secara berurutan dan atomik. Jika salah satu bagian instruksi gagal, seluruh transaksi akan gagal.

Apa itu blockhash?

"Blockhash" adalah hash Proof of History (PoH) terbaru untuk sebuah slot. Karena Solana mengandalkan PoH sebagai jam tepercaya, recent blockhash suatu transaksi dapat dianggap sebagai stempel waktu. Blockhash mencegah duplikasi dan memberikan masa berlaku bagi transaksi. Jika blockhash transaksi terlalu lama, transaksi tersebut akan ditolak. Usia maksimum blockhash adalah 150 blok atau ~1 menit 19 detik.

Bagaimana transaksi dikirim?

Solana dikelola oleh sekelompok validator yang memvalidasi transaksi yang ditambahkan ke ledger. Sebuah validator leader dipilih dari kelompok ini untuk menambahkan entri ke ledger. Entri pada ledger dapat berupa tick atau entri transaksi. Ledger menyimpan daftar entri yang berisi transaksi yang ditandatangani oleh klien. Secara konseptual, genesis block dapat ditelusuri kembali melalui ledger. Namun, ledger validator yang sebenarnya mungkin hanya menyimpan blok-blok terbaru untuk mengurangi penyimpanan karena blok lama memang tidak diperlukan untuk memvalidasi blok mendatang.

Validator leader hanya dapat menghasilkan satu blok per slot, dan blockhash merupakan pengidentifikasi unik untuk setiap blok. Blockhash adalah hash dari seluruh entri dalam suatu blok, termasuk hash blok terakhir. Jadwal leader ditentukan sebelum setiap epoch, biasanya sekitar dua hari sebelumnya, untuk menetapkan validator yang akan menjadi leader pada waktu tertentu. Saat transaksi dimulai, transaksi tersebut diteruskan ke validator leader saat ini dan berikutnya.

Transaksi dapat dikirim ke leader melalui: 

1. Server RPC: Transaksi dapat dikirim oleh penyedia RPC melalui metode JSON-RPC sendTransaction. Node RPC penerima akan mencoba mengirimnya sebagai paket UDP kepada leader saat ini dan berikutnya setiap dua detik hingga transaksi diselesaikan atau blockhash transaksi kedaluwarsa (setelah 150 blok atau ~1 menit 19 detik). Hingga saat itu, tidak ada catatan transaksi selain yang diketahui oleh klien dan node RPC penerus. 
2. Klien TPU: Klien TPU hanya mengirimkan transaksi. Software klien perlu menangani penyiaran ulang dan penerusan ke leader.

Untuk menggunakan metode sendTransaction, Anda perlu meneruskan objek transaksi yang dienkode sebagai string. Parameter opsional lainnya meliputi:

1. encoding: Encoding yang digunakan untuk data transaksi adalah base58 atau base64. 
2. skipPreflight: Pemeriksaan preflight mencakup verifikasi tanda tangan transaksi dan simulasi transaksi terhadap bank slot yang ditentukan oleh preflight commitment. Jika pemeriksaan preflight gagal, error akan ditampilkan. Pengaturan default fitur ini adalah false, yang berarti pemeriksaan preflight tidak dilewati.
3. preflightCommitment: Menentukan tingkat commitment yang digunakan saat menjalankan pemeriksaan preflight. Secara default, tingkat commitment diatur ke finalized, tetapi dapat diubah dengan menentukan string. Sebaiknya gunakan commitment dan preflight commitment yang sama untuk menghindari perilaku yang membingungkan.
4. maxRetries: Parameter maxRetries menentukan jumlah maksimum percobaan ulang yang harus dilakukan node RPC untuk mengirim transaksi kepada leader. Jika parameter ini tidak diberikan, node RPC akan mencoba ulang transaksi hingga transaksi diselesaikan atau blockhash kedaluwarsa. 
5. minContextSlot: Parameter minContextSlot menentukan slot minimum untuk menjalankan pemeriksaan preflight transaksi.

Bagaimana transaksi diproses?

Transaction Processing Unit (TPU) milik validator menerima transaksi, memverifikasi tanda tangan, mengeksekusinya, lalu membagikannya kepada validator lain dalam jaringan.

TPU memproses transaksi dalam lima tahap berbeda:

Tahap Fetch

Tahap Fetch bertanggung jawab menerima transaksi. Tahap ini mengategorikan transaksi masuk berdasarkan tiga port:

• tpu: menangani transaksi biasa seperti transfer token, pencetakan NFT, dan instruksi program
• tpu_vote: khusus menangani transaksi voting
• tpu_forwards: jika leader saat ini tidak mampu memproses semua transaksi, port ini meneruskan paket yang belum diproses kepada leader berikutnya

Paket dikelompokkan dalam batch berisi 128 paket dan diteruskan ke Tahap SigVerify.

Tahap SigVerify

Tahap SigVerify memverifikasi tanda tangan pada paket dan membuangnya jika verifikasi gagal. Paket voting dan paket biasa berjalan dalam dua pipeline terpisah. Dari perspektif software, paket yang diterima memuat sejumlah metadata, tetapi belum dapat dipastikan apakah paket tersebut merupakan transaksi.

Jika GPU terpasang, GPU tersebut akan digunakan untuk verifikasi tanda tangan. Selain itu, terdapat logika untuk menangani paket berlebih saat traffic meningkat dengan menggunakan alamat IP untuk membuang paket.

Tahap Banking

Tahap ini bertanggung jawab memfilter dan memproses transaksi. Saat ini, tahap ini terdiri dari 6 thread worker independen, yaitu 2 thread voting dan 4 thread non-voting. Transaksi biasa ditambahkan ke thread non-voting. Setiap thread memiliki buffer lokal yang dapat menampung hingga 64 transaksi yang tidak saling berkonflik dalam antrean prioritas. Transaksi ini kemudian diproses secara paralel berkat Sealevel. Anda dapat menonton video ini untuk mempelajari tahap banking lebih lanjut.

Layanan Proof of History

Modul Layanan PoH mencatat berlalunya tick. Setiap tick merepresentasikan satu unit waktu, dan terdapat 64 tick dalam satu slot. Hash dihasilkan berulang kali hingga sebuah catatan diterima dari Tahap Banking:

next_hash = hash(prev_hash, hash(transaction_ids))

Catatan ini kemudian dikonversi menjadi entri dan disiarkan ke jaringan melalui Tahap Broadcast.

Tahap Broadcast

Entri dari layanan PoH dikonversi menjadi shred, yang merepresentasikan unit terkecil sebuah blok, lalu dikirim ke seluruh jaringan menggunakan teknik propagasi blok bernama Turbine. Secara umum, Turbine membagi blok menjadi bagian-bagian lebih kecil dan mendistribusikannya melalui struktur node hierarkis. Setiap node tidak perlu terhubung dengan semua node lain. Node hanya perlu berkomunikasi dengan beberapa node tertentu. Baca artikel ini untuk mempelajari lebih lanjut tentang Turbine dan cara kerjanya. 

Mengapa transaksi gagal?

Selain kegagalan akibat instruksi yang salah atau error program kustom, kemungkinan penyebab kegagalan transaksi meliputi:

Transaksi Hilang di Jaringan

Lapisan jaringan dapat membuang transaksi bahkan sebelum leader memprosesnya. Kehilangan paket UDP adalah alasan paling sederhana mengapa hal ini dapat terjadi. Alasan lainnya berkaitan dengan fetch stage pada TPU. Saat beban jaringan tinggi, validator dapat kewalahan dengan banyaknya transaksi yang harus diproses. Validator dapat meneruskan transaksi tambahan ke port tpu_forward milik validator berikutnya. Namun, jumlah data yang dapat diteruskan terbatas, dan setiap penerusan dibatasi hanya satu lompatan ant validator. Artinya, transaksi yang diterima pada port tpu_forwards tidak diteruskan ke validator lain. Jika ukuran antrean penyiaran ulang yang tertunda melebihi 10.000 transaksi, transaksi yang baru dikirim akan dibuang.

Blockhash Usang/Salah 

Setiap transaksi memiliki "recent blockhash" yang berfungsi sebagai stempel waktu untuk jam Proof of History (PoH). Blockhash ini membantu validator menghindari pemrosesan transaksi yang sama dua kali serta melacak waktu dan urutan pemrosesan transaksi. Validator akan menolak transaksi akibat blockhash yang tidak valid saat pemrosesan.

Blockhash Kedaluwarsa

Blockhash transaksi kedaluwarsa setelah tidak lagi dianggap cukup "baru". Untuk memproses transaksi, validator Solana mencari nomor slot dari blockhash yang sesuai dalam sebuah blok. Jika validator tidak dapat menemukan nomor slot untuk blockhash tersebut, atau jika nomor slot yang ditemukan lebih dari 151 slot di bawah nomor slot blok yang sedang diproses, transaksi akan ditolak. Secara default, transaksi Solana kedaluwarsa jika tidak dimasukkan ke blok dalam jangka waktu tertentu (~1 menit 19 detik).

Node RPC yang tertinggal

Saat Anda mengirim transaksi melalui RPC, RPC Pool mungkin lebih maju daripada bagian lainnya. Hal ini dapat menimbulkan masalah ketika node dalam pool perlu bekerja sama. Misalnya, jika recentBlockhash suatu transaksi diminta dari bagian pool yang lebih maju lalu dikirim ke bagian pool yang tertinggal, node tidak akan mengenali blockhash yang lebih maju tersebut dan akan menolak transaksi. Anda dapat mendeteksinya saat mengirim transaksi dengan mengaktifkan pemeriksaan preflight pada sendTransaction.

Fork Jaringan Sementara

Fork jaringan sementara juga dapat menyebabkan transaksi dibuang. Jika validator lambat memutar ulang bloknya dalam Tahap Banking, validator tersebut dapat membuat minority fork. Saat klien menyusun transaksi, transaksi tersebut mungkin merujuk pada recentBlockhash yang hanya ada di minority fork. Setelah transaksi dikirim, cluster dapat meninggalkan minority fork sebelum transaksi diproses. Dalam skenario ini, transaksi dibuang karena blockhash tidak ditemukan.

Bagaimana cara memastikan transaksi berhasil masuk?

Untuk mendiagnosis masalah konfirmasi, Anda perlu memahami kedaluwarsa transaksi. Ikuti langkah-langkah berikut untuk meningkatkan peluang keberhasilan transaksi:

Ringkasan

• Ambil blockhash terbaru dengan commitment “confirmed” atau “finalized”
• Atur skipPreflight ke true
• Optimalkan jumlah Compute Unit yang diminta
• Tambahkan dan hitung priority fee secara dinamis
• Atur maxRetries ke 0, lalu tambahkan logika percobaan ulang kustom untuk mengirim transaksi.
• Pelajari staked connection
• Jika transaksi tidak sensitif terhadap waktu, gunakan durable nonce

Blockhash

Transaksi memiliki waktu terbatas untuk diproses oleh validator. Jika blockhash yang terkait dengan transaksi kedaluwarsa sebelum validator memprosesnya, transaksi akan dibatalkan. Agar transaksi berhasil, Anda perlu mengirimnya dengan blockhash terbaru. Jika blockhash kedaluwarsa sebelum validator memproses transaksi Anda, Anda dapat mencoba kembali transaksi tersebut dengan blockhash baru agar berhasil diproses. Hal ini dapat dilakukan dengan dua cara: 

1. Tetapkan tingkat commitment baru:

Metode RPC API yang direkomendasikan untuk mengambil blockhash terbaru adalah getLatestBlockhash. Secara default, metode ini menggunakan tingkat commitment finalized untuk menampilkan blockhash dari blok terbaru yang telah diselesaikan. Tingkat commitment ini menunjukkan bahwa setidaknya 31 blok terkonfirmasi telah ditambahkan di atas blok tersebut. Hal ini menghilangkan risiko penggunaan blockhash milik fork yang dibuang. Namun, biasanya terdapat selisih setidaknya 32 slot antara blok terkonfirmasi terbaru dan blok finalized terbaru. Kompromi ini mengurangi waktu kedaluwarsa transaksi sekitar 13 detik, bahkan bisa lebih lama saat kondisi cluster tidak stabil. 

Anda dapat mengganti commitment blockhash dengan mengatur parameter commitment ke tingkat lain. Tingkat commitment confirmed direkomendasikan untuk permintaan RPC karena biasanya hanya tertinggal beberapa slot dari tingkat commitment processed dan kecil kemungkinannya berasal dari fork yang dibuang. Meskipun tingkat commitment processed mengambil blockhash paling baru dibandingkan tingkat commitment lainnya, tingkat ini tidak direkomendasikan karena sekitar 5% blok tidak diselesaikan oleh cluster akibat fork dalam protokol Solana. Jika transaksi Anda menggunakan blockhash milik fork yang dibuang, blockhash tersebut tidak akan dianggap baru oleh blok mana pun dalam blockchain yang telah diselesaikan.

2. Lakukan polling blockhash terbaru secara berkala:

Tambahkan skrip untuk mengambil dan menyimpan blockhash terbaru secara berkala (setiap 60 detik) menggunakan metode getLatestBlockhash. Dengan demikian, setiap kali pengguna memicu transaksi, aplikasi telah menyiapkan blockhash baru. Wallet juga harus sering melakukan polling blockhash baru dan mengganti recent blockhash transaksi tepat sebelum menandatangani transaksi agar blockhash tersebut tetap sebaru mungkin.

Lewati Preflight

Sebelum transaksi dikirim, pemeriksaan preflight berikut dijalankan:

• Tanda tangan transaksi diverifikasi.
• Transaksi disimulasikan terhadap bank slot yang ditentukan oleh preflight commitment. Jika gagal, error akan ditampilkan. 

Jika blok yang dipilih untuk simulasi lebih lama daripada blok yang digunakan untuk blockhash transaksi Anda, simulasi akan gagal dengan error “blockhash not found” yang ditakuti. 

Jika Anda yakin tanda tangan transaksi telah diverifikasi dan tidak ada error lain, Anda dapat melewati pemeriksaan preflight. Meskipun menggunakan parameter skipPreflight, selalu atur parameter preflightCommitment ke tingkat commitment yang sama dengan yang digunakan untuk mengambil blockhash transaksi Anda bagi permintaan sendTransaction dan simulateTransaction.

Compute Unit

Saat transaksi dikonfirmasi di jaringan, transaksi tersebut menggunakan sebagian dari total compute unit (CU) yang tersedia dalam sebuah blok. Saat ini, total batas compute pada satu blok adalah 48 juta CU. Developer dapat menentukan anggaran compute unit untuk transaksi mereka. Jika tidak menetapkan anggaran, nilai default 200.000 akan digunakan. Banyak transaksi tidak menggunakan seluruh anggaran CU karena tidak ada penalti untuk meminta anggaran yang lebih besar daripada yang dibutuhkan. Namun, meminta terlalu banyak compute unit di awal dapat mempersulit penjadwalan transaksi secara efisien karena scheduler tidak mengetahui sisa compute dalam sebuah blok hingga transaksi dieksekusi. Untuk menghindarinya, developer harus menetapkan permintaan CU dengan cakupan yang lebih tepat sesuai kebutuhan transaksi. Lihat panduan ini untuk mengoptimalkan anggaran compute unit. Dalam pembaruan klien Solana v1.18 mendatang, transaksi yang membutuhkan lebih sedikit Compute Unit akan mendapat prioritas lebih tinggi.

Mengoptimalkan penggunaan Compute Unit (CU) memberikan manfaat berikut:

• Transaksi yang lebih kecil lebih mungkin dimasukkan ke dalam blok.
• Instruksi yang lebih murah membuat program Anda lebih mudah dikomposisikan.
• Mengurangi penggunaan blok secara keseluruhan sehingga lebih banyak transaksi dapat dimasukkan ke dalam blok.

Terapkan Priority Fee

Priority fee dapat ditambahkan di atas biaya transaksi dasar agar validator memprioritaskan transaksi. Biaya ini dihitung dalam micro-lamport per Compute Unit (misalnya, sejumlah kecil SOL). Biaya tersebut ditambahkan ke transaksi agar secara ekonomi menarik bagi node validator untuk memasukkannya ke blok dalam jaringan.

Namun, perlu diperhatikan bahwa ada batas jumlah priority fee yang sebaiknya dibayarkan. Membayar lebih dari biaya umum tidak akan meningkatkan peluang keberhasilan transaksi Anda. Karena itu, sebaiknya hitung priority fee secara dinamis agar Anda membayar jumlah yang tepat untuk tetap kompetitif tanpa membayar berlebihan. Integrasi ini mudah dilakukan. Anda dapat melihat dokumentasi resmi tentang priority fee atau menggunakan Helius API yang siap digunakan.

Terapkan Logika Percobaan Ulang yang Andal

Jika jaringan padat, terapkan logika kustom dalam kode Anda untuk menangani kegagalan transaksi dan mencoba ulang secara manual. Untuk melakukannya, atur parameter maxRetries ke 0 saat menggunakan sendTransaction untuk mengirim transaksi. Anda dapat menggunakan beberapa metode untuk mencoba ulang transaksi:

• Lakukan polling transaction status dengan tingkat commitment yang berbeda dan terus gunakan transaksi bertanda tangan yang sama hingga terkonfirmasi. Gunakan mekanisme exponential backoff untuk menghindari spam. Sebagai alternatif, Anda dapat mengirim transaksi pada interval tetap hingga terjadi timeout.
• Simpan lastValidBlockHeight yang berasal dari getLatestBlockhash method. Kemudian, lakukan polling ketinggian blok cluster dan coba ulang transaksi secara manual setelah ketinggian blok saat ini melampaui lastValidBlockHeight. Saat melakukan polling melalui getLatestBlockhash, sebaiknya tentukan tingkat commitment yang Anda inginkan. Dengan mengatur commitment ke confirmed (telah mendapat voting) atau finalized (~30 blok setelah confirmed), Anda dapat menghindari polling blockhash dari minority fork.

Staked Connection

Kapasitas bandwidth jaringan leader terbatas. Agar dapat digunakan secara efektif, pembobotan berdasarkan stake diperlukan untuk menghindari penerimaan transaksi secara buta berdasarkan urutan kedatangan tanpa mempertimbangkan sumbernya. Solana beroperasi sebagai jaringan proof-of-stake sehingga penggunaan pembobotan berdasarkan stake dapat diperluas secara alami untuk meningkatkan kualitas layanan transaksi. Artinya, node dengan stake 0,5% dapat mengirim setidaknya 0,5% paket kepada leader. Sementara itu, bagian jaringan lainnya—atau kombinasi stake yang tersisa—tidak dapat sepenuhnya menyingkirkan paket tersebut. Mekanisme ini dikenal sebagai Stake-Weighted Quality of Service (SWQoS).

Helius menawarkan staked connection untuk paket berbayar. Untuk mempelajari lebih lanjut, kunjungi dokumentasi kami: Mengirim Transaksi di Solana.

Durable Nonce

Durable nonce memungkinkan pembuatan dan penandatanganan transaksi yang dapat dikirim kapan saja di masa mendatang. Durable nonce digunakan dalam berbagai kasus, seperti layanan kustodian yang membutuhkan lebih banyak waktu untuk menghasilkan tanda tangan transaksi. Jika transaksi Anda tidak sensitif terhadap waktu, Anda dapat menggunakan metode ini untuk mengatasi singkatnya masa berlaku recentBlockhash milik transaksi.

Untuk mulai menggunakan durable transaction, Anda perlu mengirim transaksi yang memanggil instruksi guna membuat account "nonce" khusus secara on-chain dan menyimpan "durable blockhash" di dalamnya. Account Nonce menyimpan nilai nonce. Selama account nonce belum digunakan, Anda dapat membuat durable transaction dengan mengikuti dua aturan berikut:

• Daftar instruksi harus diawali dengan instruksi sistem "advance nonce", yang memuat account nonce on-chain Anda.
• Blockhash transaksi harus sama dengan durable blockhash yang tersimpan dalam account nonce on-chain.

Pelajari cara menerapkan durable nonce melalui CLI dan Web3.js dengan membaca artikel ini.

Pendekatan Helius untuk Mengirim Transaksi

Permintaan sendTransaction secara otomatis diarahkan ke node RPC terdekat kami. Jika maxRetries tidak ditentukan, transaksi akan dicoba ulang setiap 2 detik hingga blockhash kedaluwarsa. Kami menyarankan Anda mengatur maxRetries ke 0 dan menyiarkan ulang transaksi sendiri setiap 2 detik hingga terkonfirmasi. 

Untuk mengatasi kepadatan jaringan saat ini, kami bekerja tanpa henti guna meningkatkan tingkat keberhasilan transaksi pengguna. Kami telah menurunkan rate limit untuk permintaan sendTransaction. Langkah ini diterapkan untuk mengelola kepadatan dan mencegah spam ke validator. Anda dapat melihat batasnya di sini.

Selanjutnya, kami mengarahkan traffic berkualitas tinggi untuk paket berbayar melalui staked connection. Kami memanfaatkan validator kami untuk staked connection ini. Traffic dianggap berkualitas tinggi jika total priority fee setidaknya 10.000 Lamport (median cluster).

Kami mewajibkan total biaya di atas 10.000 Lamport untuk memastikan validator menerima traffic berkualitas tinggi. Validator mulai membatasi laju (atau bahkan memblokir sepenuhnya) sumber traffic yang mengirim transaksi berbiaya rendah.

Penggunaan staked connection dapat meningkatkan tingkat keberhasilan transaksi Anda secara signifikan. Baca artikel ini untuk mempelajari lebih lanjut cara mengatur priority fee saat membuat transaksi.

Rekomendasi Kami

Pengguna Pemula/Menengah

Kami menyarankan Anda mengatur skipPreflight sebagai false. Pemeriksaan preflight mencakup verifikasi tanda tangan transaksi dan simulasi transaksi terhadap bank slot yang ditentukan oleh preflight commitment. Jika pemeriksaan preflight gagal, error akan ditampilkan. Tanpa pemeriksaan preflight, transaksi Anda dapat dibuang akibat kesalahan konfigurasi.

Pengguna Tingkat Lanjut

Bagi pengguna tingkat lanjut yang membutuhkan latensi serendah mungkin, Anda sebaiknya mengatur skipPreflight ke true. Namun, Anda bertanggung jawab memastikan transaksi dikonfigurasi dengan benar. 

Kesimpulan

Agar transaksi berhasil masuk ke jaringan Solana saat terjadi kepadatan, diperlukan pemahaman mendalam tentang arsitektur jaringan dan mekanisme pemrosesan transaksi. Dengan memahami konsep inti seperti peran blockhash dalam keunikan dan ketepatan waktu transaksi, proses pengiriman transaksi melalui server RPC atau klien TPU, serta pentingnya menetapkan parameter yang tepat (seperti skipPreflight, preflightCommitment, dan maxRetries), pengguna dapat meningkatkan performa transaksi secara signifikan. Penerapan mekanisme percobaan ulang kustom dan pemanfaatan staked connection dapat membantu meningkatkan tingkat keberhasilan.

Selain itu, Anda perlu memahami keterbatasan jaringan saat ini dan upaya berkelanjutan Anza untuk mengatasinya, seperti yang terlihat dalam rilis klien v1.18 mendatang. Seiring jaringan berkembang dan diskalakan, mengikuti informasi terbaru dan tetap adaptif akan menjadi kunci untuk berinteraksi secara efektif dengannya. 

Jika membutuhkan bantuan atau dukungan, jangan ragu menghubungi kami di Discord. Pastikan Anda memasukkan alamat email di bawah agar tidak melewatkan kabar terbaru tentang Solana. Siap mempelajari lebih jauh? Jelajahi artikel terbaru di blog Helius dan lanjutkan perjalanan Solana Anda hari ini.

Referensi

• Transaksi – Solana Cookbook
• Optimalisasi Blok di Solana
• Solana Validator 101: Pemrosesan Transaksi oleh Jito Labs
• Transaction Processing Unit dalam Validator Solana
• Scheduler Solana
• Konfirmasi Transaksi oleh Solana
• Mencoba Ulang Transaksi oleh Solana
• Cara menggunakan Priority Fee
• Cara mengoptimalkan compute
• Prioritization Fee dan Compute Unit
• Durable Transaction Nonce
• Penandatanganan Transaksi Durable & Offline menggunakan Nonce
• Transaksi Solana: Durable Nonce oleh Helius