Peran Penting Developer dalam Peningkatan Performa Jaringan Solana Lewat Optimasi Blok
Halo SOLdier! Penggunaan Jaringan Solana belakangan sedang mengalami kenaikan cukup signifikan, yang membuat hal tersebut rentan berpengaruh pada komponen penting di jaringan, terutama penerapan biaya prioritas dan transaction scheduler. Dua hal ini memainkan peranan penting dalam optimalisasi blok.
Meskipun jaringan tetap stabil selama kenaikan penggunaan, hal tersebut berkat tools yang digunakan developer dan operator untuk memastikan kinerja tinggi yang berkelanjutan, serta nantinya akan ada update tambahan yang sedang dikerjakan untuk rilis software mendatang dalam upaya meningkatkan kinerja aplikasi jaringan.
Berikut merupakan hal apa saja yang perlu dilakukan developer dalam upaya untuk peningkatan performa Jaringan Solana:
Penerapan Biaya Prioritas
Banyaknya aplikasi berbasis Solana yang belum menggunakan biaya prioritas sering mengakibatkan transaksi tertunda atau terhenti. Integrasi biaya prioritas dinamis ke dalam dApps membantu mengatasi masalah pengalaman pengguna. Berikut panduannya: https://solana.com/developers/guides/advanced/how-to-use-priority-fees
Biaya prioritas juga diintegrasikan ke dalam CLI untuk digunakan dalam deployment program. Proyek exchange dapat menggunakan panduan terbaru di bawah ini untuk menghitung biaya prioritas:
https://solana.com/docs/more/exchange#prioritization-fees-and-compute-units
Optimalisasi Penggunaan CU Program
Ketika transaksi dikonfirmasi di jaringan, transaksi tersebut mengurangi jumlah total compute unit (CU) yang tersedia dalam satu blok.
Saat ini, total batas komputasi pada sebuah blok adalah 48 juta CU, yang seringkali mencapai batas pada saat congestion. Mengurangi jumlah CU yang digunakan dalam program Anda dapat meningkatkan jumlah transaksi yang dapat masuk ke jaringan. Baca selengkapnya: https://solana.com/developers/guides/advanced/how-to-optimize-compute
Alokasi Budget Request CU
Saat transaksi dikirimkan ke jaringan, developer harus menentukan budget compute unit untuk transaksi secara spesifik. Jika tidak, maka default value akan menjafd lebih tinggi dari yang dibutuhkan dalam proses transaksi.
Karena saat ini tidak ada penalti budget request ketika budget yang dialokasikan dalam sebuah transaksi tidak digunakan secara maksimal mengakibatkan penjadwalan transaksi berjalan dengan tidak efisien.
Alhasil scheduler tidak dapat mendeteksi secara akurat berapa banyak komputasi yang tersisa dalam satu blok hingga transaksi dieksekusi. Developer harus menggunakan scoped CU request dengan optimal dan sesuai dengan persyaratan transaksi.
Menggunakan Stake-Weighted QoS
Penyedia infrastruktur harus mengadopsi Stake-Weighted QoS, sebuah fitur core protocol yang diluncukan tahun lalu. Fitur ini memungkinkan pembuat blok untuk mengidentifikasi dan memprioritaskan transaksi proxied transaction melalui staked validator, sebagai mekanisme tambahan untuk sybil resistance. Panduan untuk Stake-Weighted QoS akan segera dirilis.
Perubahan Core Protocol v1.8
Transaction Scheduler
Update software komponen validator stack yang membantu mengisi blok secara efisien dan ekonomis dijadwalkan rilis dengan v1.18 pada pertengahan April.
Implementasi scheduler baru ini akan diperkenalkan sebagai upgrade dari scheduler saat ini, namun tidak akan diaktifkan secara default. Validator Operator dapat mengaktifkan dan monitoring kinerja scheduler baru dan dengan mudah melakukan failover kembali ke scheduler versi lama apabila ada kendala teknis.
