Fakta tentang Pasar Biaya Lokal Solana

Wawasan yang Dapat Ditindaklanjuti

• Pasar Biaya Lokal (Local Fee Markets/LFM) memungkinkan Solana menetapkan biaya terperinci untuk setiap bagian state berdasarkan tingkat persaingannya. Transaksi membayar biaya berdasarkan state spesifik yang ditulis, sehingga hotspot lokal tidak menaikkan biaya di seluruh blockchain. 
• LFM sangat penting untuk mewujudkan visi Solana sebagai base layer terpadu yang skalabel, tempat semua aplikasi dapat hidup berdampingan dengan mulus. Tanpa LFM, lonjakan biaya di satu bagian chain akan menaikkan biaya semua transaksi—masalah yang umum terjadi pada jaringan lain yang hanya mengandalkan pasar biaya global untuk menentukan harga blockspace.
• Saat aktivitas ekonomi di Solana mulai meningkat pesat pada akhir 2023, beberapa kelemahan kritis dalam implementasi awal LFM menjadi jelas. Yang paling menonjol adalah prioritas scheduler yang nondeterministik. Transaksi terutama diurutkan berdasarkan waktu kedatangan di block builder, sedangkan biaya prioritas hanya menjadi pertimbangan sekunder.
• Dengan pembaruan klien Agave v1.18 pada Mei 2024, scheduler transaksi baru dan formula prioritas transaksi yang disempurnakan diperkenalkan. Scheduler membangun grafik dependensi untuk mengelola pemrosesan dan penentuan prioritas transaksi yang berkonflik di berbagai thread dengan lebih baik. Pembaruan besar ini secara signifikan meningkatkan kemampuan protokol untuk mengurutkan transaksi secara deterministik.
• Metrik yang berguna untuk mengevaluasi efektivitas LFM adalah perbandingan median dan rata-rata biaya prioritas transaksi. Biaya yang melibatkan state tanpa persaingan (median persentil ke-50) diperkirakan tetap rendah. Biaya untuk state yang diperebutkan seharusnya melonjak saat permintaan meningkat, sehingga mendorong naik rata-rata. Data terbaru mengonfirmasi pola ini. Pada November 2024, rata-rata biaya transaksi non-vote mencapai rekor tertinggi lebih dari 0.0003 SOL. Namun, median biaya tetap stabil pada 0.00000861 SOL, sekitar 35x lebih rendah.
• Saat ini, LFM Solana berfungsi, tetapi masih memiliki banyak ruang untuk ditingkatkan. Analisis beban kerja thread banking stage yang dilakukan engineer Anza menunjukkan adanya bug scheduler yang mencegah klien validator menggunakan kapasitas penuhnya. Akibatnya, klien Agave hanya beroperasi pada sebagian kecil potensinya. Selain itu, belum ada spesifikasi formal tentang cara transaksi harus diurutkan.
• API biaya prioritas saat ini belum cukup canggih untuk memberikan hasil deterministik kepada developer. Setiap penyedia RPC utama menawarkan API biaya prioritas kustomnya sendiri, yang dapat menjadi bentuk vendor lock-in terselubung. Implementasi API RPC open-source inti gagal mempertimbangkan dinamika jaringan penting, seperti pengaruh Jito, sehingga menghasilkan estimasi biaya yang tidak akurat.
• Tanpa metode deterministik untuk menghitung biaya prioritas, developer sering mengambil pendekatan hati-hati dengan membayar lebih agar transaksi mereka diproses. Sebagai alternatif, mereka mungkin menggunakan tip Jito secara berlebihan, bahkan untuk transaksi yang tidak perlu mendapatkan posisi teratas dalam blok.
• Berbagai strategi telah diusulkan untuk lebih menyempurnakan struktur biaya Solana. Strategi ini mencakup biaya write lock eksponensial dan biaya dasar dinamis. Jaringan masih perlu menemukan cara menerapkan tekanan balik ekonomi untuk mengurangi insentif spam sekaligus mempertahankan biaya rendah bagi pengguna manusia yang sebenarnya.

Pendahuluan

Pasar biaya adalah mekanisme ekonomi yang dirancang untuk mengalokasikan blockspace yang terbatas secara efisien kepada transaksi bernilai tertinggi melalui penyesuaian biaya transaksi secara dinamis. Kesediaan suatu transaksi untuk membayar biaya menjadi proksi nilainya. LFM menyempurnakan konsep umum ini dengan menetapkan biaya terperinci untuk setiap bagian state berdasarkan tingkat persaingannya. Dua transaksi dianggap berkonflik saat mengakses state yang sama—baik dua operasi tulis maupun operasi baca dan tulis pada account yang sama.

Dengan LFM, transaksi membayar biaya berdasarkan state spesifik yang ditulis, sehingga hotspot lokal tidak menaikkan biaya di seluruh blockchain. Transaksi yang mengakses state dengan permintaan tinggi atau yang diperebutkan dikenai biaya lebih tinggi, sedangkan transaksi yang berinteraksi dengan state yang permintaannya lebih rendah membayar biaya lebih rendah. Hal ini penting karena Solana menangani transaksi yang tidak berkonflik dengan lebih baik berkat eksekusi paralel.

Sebagai perbandingan, pasar biaya global menerapkan biaya universal untuk mengakses state jaringan. Artinya, semua transaksi bersaing secara setara untuk disertakan, terlepas dari account yang berinteraksi dengannya. Model biaya Ethereum yang diterapkan dalam EIP-1559 merupakan contoh relevan dari pasar biaya global. EIP-1559 menyesuaikan biaya dasar dinamis berdasarkan permintaan jaringan untuk mempertahankan penggunaan komputasi (gas) yang optimal per blok. Saat kapasitas blok terisi, biaya meningkat untuk semua transaksi. Wallet menghitung biaya berdasarkan biaya dasar saat ini dan batas gas transaksi. Pendekatan ini diterapkan dalam protokol dan menawarkan perhitungan biaya yang dapat diprediksi. Namun, pendekatan ini gagal mengisolasi hotspot dengan permintaan tinggi dari jaringan yang lebih luas. Saat biaya melonjak, kenaikan tersebut berlaku untuk semua transaksi.

Masalah tingginya permintaan atas bagian state tertentu tidak hanya terjadi pada blockchain. Tantangan ini serupa dengan masalah hotspot key, yang sering disebut "celebrity problem," dan umum dijumpai dalam aplikasi sosial Web2.

Melalui artikel ini, kami ingin menyajikan analisis LFM Solana yang mudah dipahami. Tulisan ini dibagi menjadi bagian-bagian berikut:

• Dasar-Dasar Biaya Solana: Memberikan pemahaman dasar kepada pembaca tentang cara transaksi diproses di Solana saat ini.
• Masalah Awal Pasar Biaya Lokal: Membahas masalah awal dalam implementasi pertama LFM beserta kekurangannya.
• Pembaruan Central Scheduler v.1.18: Menyoroti pembaruan penting pada 2024 yang secara signifikan meningkatkan fungsi LFM.
• Mengukur Efektivitas Pasar Biaya Lokal: Menyajikan data yang relevan untuk memahami kondisi operasional LFM di Solana saat ini.
• Masalah yang Masih Berlangsung dan Area Peningkatan: Bagian ini membahas masalah yang belum terselesaikan dan area yang perlu diperhatikan agar LFM dapat mencapai potensi penuhnya.
• Solusi yang Diusulkan: Mengulas solusi yang diusulkan untuk menyempurnakan LFM dan memperkenalkan insentif ekonomi yang lebih baik untuk penetapan harga blockspace yang lebih bernuansa.

Pembaca yang telah memahami struktur biaya transaksi Solana dapat melewati bagian berikut tentang dasar-dasar biaya.

Dasar-Dasar Biaya Solana

Transaksi Solana terdiri dari dua biaya—biaya dasar dan biaya prioritas. Biaya dasar saat ini ditetapkan sebesar 5.000 lamport per tanda tangan. Sebagian besar transaksi Solana memiliki satu tanda tangan. Biaya prioritas dinyatakan dalam microlamport (yaitu, sepersejuta lamport) per compute unit (CU) yang diminta. Biaya didebit dari account pembayar biaya (penanda tangan). Transaksi akan dibatalkan jika pembayar tidak memiliki cukup lamport untuk membayar transaksi. Saat artikel ini ditulis, 50% dari biaya dasar dan biaya prioritas disimpan oleh block builder sebagai insentif untuk menyertakan transaksi ke dalam blok. Sebanyak 50% lainnya dibakar. Setelah pemungutan suara tata kelola atas proposal SIMD-096 berhasil pada Mei tahun lalu, ketentuan ini akan berubah sehingga 100% biaya prioritas disimpan oleh block builder. Sebagai contoh: 

Sebuah transaksi memiliki satu tanda tangan dan meminta 500.000 CU. Pengirim menetapkan biaya prioritas sebesar 50.000 microlamport per CU yang diminta. Total biaya transaksi adalah 5.000 lamport + (500.000 CU yang diminta * 50.000 microlamport per CU yang diminta) = 25.000 lamport, atau 0.000025 SOL.

Validator memiliki sumber daya komputasi yang terbatas, dan protokol membatasi total sumber daya komputasi per blok hingga 48 juta CU. Angka ini ditentukan secara empiris berdasarkan jumlah yang dapat diproses validator secara wajar untuk mencapai waktu blok 400 milidetik. CU maksimum per account per blok dibatasi hingga 12 juta, sedangkan komputasi maksimum per transaksi ditetapkan sebesar 1,4 juta CU. Ukuran pesan transaksi juga dibatasi hingga maksimum 1.232 byte, yaitu unit transmisi minimum IPv6 (1280 byte) dikurangi header.

Untuk mencegah penyalahgunaan sumber daya komputasi, setiap transaksi di Solana diberi anggaran komputasi. Secara default, jaringan menetapkan batas maksimum 200.000 compute unit (CU) per instruksi. Namun, transaksi dapat menentukan batas compute unit khusus dengan menyertakan instruksi `SetComputeUnitLimit`, sehingga alokasi sumber daya menjadi lebih efisien. Basis kode klien Agave mencantumkan biaya CU untuk berbagai operasi.

Solana mewajibkan semua transaksi mencantumkan daftar lengkap alamat account yang akan dibaca atau ditulis selama transaksi. Ukuran maksimum daftar ini adalah 35 alamat dan dapat diperluas melalui Address Lookup Tables on-chain. Penyusunan daftar alamat menambah beban kerja developer, tetapi menjadi kunci untuk memanfaatkan berbagai pengoptimalan Solana, termasuk eksekusi transaksi paralel dan pasar biaya lokal.

Masalah Awal Pasar Biaya Lokal Solana

Saat aktivitas ekonomi di Solana mulai meningkat pesat pada akhir 2023, beberapa kelemahan kritis dalam implementasi awal LFM menjadi jelas. Pada waktu itu, Eugene Chen dari Ellipsis Labs memberikan analisis komprehensif mengenai tantangan tersebut dalam artikel Umbra Research, Solana Fees, Part 1. Berikut adalah ringkasan poin-poin utama yang dikemukakan Chen.

Kurangnya Insentif untuk Meminta CU secara Akurat

Struktur biaya Solana mengenakan biaya dasar per tanda tangan tanpa mempertimbangkan compute unit (CU) yang digunakan atau diminta. Sementara itu, biaya prioritas hanya memberikan insentif terbatas untuk mengurangi penggunaan CU selama periode kemacetan. Desain ini membuat pengirim transaksi memiliki sedikit motivasi untuk mengoptimalkan penggunaan komputasi atau menyesuaikan permintaan CU dengan kebutuhan sebenarnya. Akibatnya, transaksi sering meminta CU secara berlebihan, sehingga menimbulkan inefisiensi dalam proses penjadwalan jaringan.

Insentif untuk Menggunakan Mekanisme Prioritas di Luar Protokol

Pembakaran 50% biaya prioritas mendorong pengirim transaksi untuk melewati protokol dengan berkolusi bersama block builder dan mengatur pembayaran off-chain demi akses prioritas. Perilaku ini terlihat dari meningkatnya penggunaan lelang Jito. Validator yang menjalankan klien Jito-Agave memperoleh keuntungan dari pendapatan biaya yang lebih tinggi dan dapat mendistribusikan laba tersebut secara efisien kepada staker yang mendelegasikan aset melalui imbalan komisi Jito MEV. Seiring meningkatnya adopsi klien Jito-Agave, bundle Jito terbukti menjadi layanan pengiriman transaksi yang lebih unggul dalam banyak skenario. 

Penentuan Prioritas Scheduler yang Nondeterministik

Baik konsensus Solana maupun scheduler tidak memberlakukan pengurutan transaksi yang ketat berdasarkan biaya prioritas. Transaksi terutama diurutkan berdasarkan waktu kedatangan di block builder, sedangkan biaya prioritas hanya menjadi pertimbangan sekunder. Biaya prioritas yang lebih tinggi dapat meningkatkan peluang penyertaan ketika state diperebutkan, tetapi proses pengurutannya tetap nondeterministik. Jitter jaringan sebelum mencapai transaction processing unit (TPU) dan jitter internal di dalam scheduler semakin menambah ketidakpastian.

Kurangnya determinisme ini mengurangi prediktabilitas dan keandalan eksekusi transaksi, sehingga mendorong pengguna membanjiri jaringan dengan spam transaksi untuk meningkatkan peluang penyertaan yang lebih cepat. Namun, menaikkan biaya prioritas memberikan manfaat yang semakin kecil setelah ambang tertentu, sehingga mengurangi efektivitasnya sebagai mekanisme untuk memperoleh penempatan transaksi yang lebih baik. Blockspace bersama Solana pada akhirnya menjadi korban "tragedy of the commons" klasik. Pelaku individual yang bertindak demi kepentingannya sendiri telah berkontribusi terhadap penggunaan berlebihan dan inefisiensi sumber daya publik ini.

Pembaruan Central Scheduler v.1.18

Implementasi awal scheduler klien Agave hanya memberikan jaminan longgar bahwa transaksi dengan biaya prioritas tinggi akan memiliki peluang lebih besar untuk disertakan dalam blok tertentu. Transaction Processing Unit (TPU) milik leader beroperasi menggunakan enam thread paralel: empat menangani transaksi non-vote, sedangkan dua dicadangkan untuk transaksi vote. Masing-masing dari empat thread transaksi non-vote memiliki antreannya sendiri, tempat transaksi masuk menunggu untuk dikelompokkan menjadi entri yang akan dieksekusi. Sebelumnya, transaksi ditetapkan secara acak ke thread-thread ini, dan setiap antrean menentukan prioritas paket secara independen tanpa mengetahui paket yang diproses thread lain.

Dalam sistem ini, setiap thread menjalankan siklus pada antreannya serta mencoba mengunci dan mengeksekusi transaksi. Setelah menyelesaikan siklus saat ini, thread mengumpulkan paket tambahan dan memulai proses kembali. Struktur ini menimbulkan tantangan bagi penggunaan biaya prioritas secara efektif. Misalnya, ketika transaksi berprioritas tinggi berada di bagian teratas antrean suatu thread, thread lain dapat secara bersamaan memproses transaksi dengan biaya prioritas lebih rendah yang melibatkan account yang sama dari bagian akhir antreannya. Biaya prioritas hanya memengaruhi pengurutan transaksi di dalam setiap thread (intra-thread), bukan di seluruh thread (inter-thread). Akibatnya, setiap antrean menerapkan mekanisme pengurutan hibrida yang memadukan pemrosesan first-in-first-out (FIFO) dengan pertimbangan biaya prioritas. Namun, tidak ada pengurutan global yang diterapkan di seluruh thread.

Saat sebuah thread bersiap mengeksekusi transaksi, thread tersebut harus terlebih dahulu mendapatkan account lock yang diperlukan. Jika write lock yang dibutuhkan tidak tersedia, transaksi dimasukkan kembali ke antrean. Penetapan transaksi ke thread secara acak memperburuk masalah ini karena jenis transaksi yang sama dapat menempati posisi berbeda-beda dalam sistem penjadwalan multi-thread. Sifat stokastik scheduler ini menimbulkan jitter dan menyebabkan variasi posisi transaksi di dalam blok.

Pembaruan klien Agave v1.18 pada Mei 2024 menghadirkan scheduler transaksi baru, yang juga disebut central scheduler. Dalam struktur yang direvisi ini, central scheduler membangun grafik dependensi bernama prio-graph untuk mengelola pemrosesan dan penentuan prioritas transaksi yang berkonflik di seluruh thread dengan lebih baik. Pembaruan besar ini secara signifikan meningkatkan kemampuan Solana untuk mengurutkan transaksi secara deterministik; transaksi dengan biaya prioritas lebih tinggi memiliki peluang lebih besar untuk disertakan dalam blok.

Prio-graph adalah directed acyclic graph (DAG) yang diperbarui secara dinamis saat transaksi baru ditambahkan. Transaksi diatur dalam grafik untuk membentuk rantai eksekusi yang diproses berdasarkan urutan prioritas waktu. Untuk transaksi yang berkonflik, biaya prioritas menentukan urutan penyisipan. Pendekatan ini meminimalkan persaingan lock, sehingga batch transaksi dapat dieksekusi dengan lancar dan penundaan akibat konflik sumber daya berkurang. Verifikasi prakompilasi transaksi telah dialihkan ke worker thread untuk meningkatkan performa dan memungkinkan pemrosesan yang lebih efisien. 

Desain scheduler yang diperbarui secara signifikan meningkatkan skalabilitas dan fleksibilitas, sehingga jumlah thread berpotensi ditambah tanpa risiko meningkatnya konflik lock. Selain itu, pendekatan penjadwalan terpusat telah meningkatkan perolehan imbalan dan menambah pendapatan banyak operator validator.

Untuk uraian central scheduler yang lebih terperinci, pembaca dapat melihat artikel blog Helius kami sebelumnya yang membahas pembaruan Agave 1.18.

Perhitungan Prioritas yang Lebih Efektif

Bersamaan dengan pembaruan scheduler, formula prioritas transaksi disempurnakan untuk memberikan keunggulan kepada transaksi dengan kebutuhan komputasi lebih rendah. Hal ini menguntungkan developer dan transaksi yang menggunakan sumber daya minimal. 

Formula yang direvisi adalah:

Prioritas = (Biaya Prioritas * Compute Unit yang Diminta) + Biaya Dasar / 

(1 + CU Eksekusi yang Diminta + CU Tanda Tangan + CU Write Lock)

Perhitungan baru ini memperhitungkan semua biaya komputasi dan operasional yang terkait dengan transaksi, sehingga tingkat prioritas secara akurat merepresentasikan konsumsi sumber daya sebenarnya. Dengan demikian, transfer token sederhana atau transaksi SOL native tanpa biaya prioritas tambahan dijamin memiliki tingkat prioritas dasar dalam antrean. Untuk transaksi yang lebih kompleks, developer yang tidak menentukan batas CU khusus menggunakan instruksi `SetComputeUnitLimit` akan dirugikan dalam penentuan prioritas transaksi dibandingkan mereka yang melakukannya.

Mengukur Efektivitas Pasar Biaya Lokal

Bagian ini akan membahas data yang relevan dengan LFM Solana. 

Median Vs. Rata-Rata Biaya Transaksi

Dengan LFM yang berfungsi efektif, biaya transaksi yang melibatkan state tanpa persaingan, seperti transfer stablecoin sederhana, diperkirakan tetap rendah. Sementara itu, biaya transaksi yang mengakses state yang diperebutkan, seperti token spekulatif dengan likuiditas rendah, seharusnya melonjak seiring meningkatnya permintaan. Metrik yang berguna untuk mengevaluasi dinamika ini adalah perbandingan median dan rata-rata biaya prioritas transaksi. Median biaya mewakili biaya yang dibayar pengguna pada persentil ke-50 dan mencerminkan biaya umum, sedangkan rata-rata biaya memperhitungkan seluruh biaya yang dibagi dengan jumlah total transaksi untuk menyoroti tren keseluruhan.

Data terbaru mengonfirmasi pola yang diharapkan ini. November 2024 menandai tingkat aktivitas ekonomi tertinggi di Solana hingga saat ini, dengan rata-rata biaya transaksi non-vote mencapai rekor tertinggi lebih dari 0.0003 SOL. Meskipun demikian, median biaya tetap stabil pada 0.00000861 SOL, sekitar 35x lebih rendah. Kondisi ini berbeda dengan April 2024, ketika lonjakan aktivitas ekonomi serupa menyebabkan rata-rata biaya naik melampaui 0.0002 SOL, disertai kenaikan median biaya menjadi 0.00001862 SOL, sekitar 10x lebih rendah. Perbedaan ini menegaskan efektivitas isolasi biaya dalam melindungi pengguna umum dari lonjakan biaya selama periode permintaan tinggi dan menjaga pengalaman pengguna untuk kasus penggunaan yang tidak didorong spekulasi.

Kami mengamati korelasi kuat antara median dan rata-rata biaya transaksi saat menganalisis data serupa dari jaringan berbasis EVM, seperti Ethereum L2 Base yang dioperasikan Coinbase dan tidak memiliki LFM. Rata-rata dan median biaya bergerak relatif beriringan karena biaya dasar global meningkat saat permintaan bertambah. Selain itu, selisih antara median dan rata-rata biaya transaksi jauh lebih kecil. Misalnya, pada 5 Desember 2024, rata-rata biaya transaksi di Base melonjak menjadi $0.1115, sedangkan median biaya juga naik hingga $0.0228—sekitar lima kali lebih rendah.

Tingkat Transaksi yang Dikembalikan

Tren lain yang berguna untuk diteliti adalah tingkat transaksi yang dikembalikan. Selama periode aktivitas ekonomi tinggi pada April dan Mei 2024, pengguna Solana banyak melaporkan penurunan pengalaman pengguna karena chain terbebani spam dalam jumlah besar. Kurangnya determinisme mengurangi prediktabilitas dan keandalan eksekusi transaksi, sehingga mendorong pengguna membanjiri jaringan dengan spam transaksi untuk meningkatkan peluang penyertaan yang lebih cepat. 

Searcher sering mengirimkan transaksi untuk perdagangan oportunistis tanpa mempertimbangkan peluang keberhasilannya. Transaksi arbitrase dengan biaya prioritas yang terlalu rendah tetap valid. Protokol akan memprosesnya setelah transaksi lain dengan biaya prioritas lebih tinggi, dan transaksi tersebut kemungkinan akan dikembalikan akibat logika slippage. 

Transaksi yang dikembalikan mencapai puncaknya pada April 2024 dan mencakup 75,7% dari seluruh transaksi non-vote. Persentase ini turun secara signifikan setelah peluncuran pembaruan utama, termasuk central scheduler Agave 1.18.

Analisis kohor dari Blockworks Research yang mencakup tujuh hari terakhir (6–13 Januari 2024) menunjukkan tingkat pengembalian yang berbeda pada berbagai tingkat aktivitas. Alamat yang melakukan 1–5 transaksi harian (terutama pengguna retail) mengalami tingkat pengembalian 1,4%, yang meningkat menjadi 4,6% bagi alamat dengan 6–50 transaksi harian. Khususnya, alamat yang melakukan lebih dari 10.000 transaksi harian memiliki tingkat pengembalian yang melonjak hingga 66,7%. Selain itu, alamat beraktivitas tinggi dengan lebih dari 100.000 transaksi harian (bot) bertanggung jawab atas 95,2% dari seluruh transaksi yang dikembalikan. Untuk Desember 2024, tingkat pengembalian keseluruhan bagi semua transaksi non-vote adalah 41,2%. Angka ini menunjukkan bahwa sebagian besar sumber daya komputasi jaringan digunakan untuk memproses arbitrase yang gagal.

Masalah yang Masih Berlangsung dan Area Peningkatan

Meskipun mengalami kemajuan penting, scheduler klien validator Agave masih menghadapi tantangan. Analisis beban kerja thread banking stage berikut yang dilakukan engineer Anza, Alessandro Decina, menyoroti inefisiensi yang ada dan area yang perlu ditingkatkan.

Thread Scheduler: Ini adalah thread paling penting untuk menghasilkan blok. Scheduler menerima semua transaksi masuk, lalu mengurutkan dan menjadwalkannya untuk dieksekusi. 

Thread Transaksi Vote: Dua thread khusus menangani transaksi vote dan memastikan transaksi tersebut diproses secara terpisah dari transaksi pengguna.

Thread Transaksi Non-vote: Empat thread yang menerima transaksi sesuai jadwal dari scheduler dan memproses transaksi pengguna.

Thread Ingest QUIC: Thread Tokio mengelola penerimaan transaksi melalui protokol QUIC saat validator menjadi leader. Selama periode kemacetan pada awal 2024, thread-thread ini menjadi bottleneck yang signifikan.

Visualisasi di atas menunjukkan bahwa meskipun semua worker thread mengeksekusi transaksi secara paralel pada awal blok pertama leader, paralelisme ini dengan cepat menurun menjadi eksekusi berurutan. Secara khusus, hanya satu thread transaksi non-vote (thread tiga) yang terus memproses transaksi, sedangkan thread lainnya tidak aktif.

Perilaku ini menunjukkan adanya bug scheduler yang mencegah klien validator menggunakan kapasitas penuhnya. Akibatnya, sistem hanya beroperasi pada sebagian kecil potensinya. Jika masalah ini diselesaikan, validator diperkirakan dapat memproses hingga empat kali beban saat ini.

Observabilitas

API biaya saat ini untuk memperkirakan pendaratan transaksi secara konsisten belum cukup canggih untuk memberikan hasil deterministik. Setiap penyedia RPC utama menawarkan API biaya prioritas kustomnya sendiri, sedangkan implementasi API RPC open-source inti masih belum optimal. Implementasi tersebut gagal mempertimbangkan dinamika jaringan penting, seperti pengaruh Jito, sehingga estimasi biayanya kurang akurat. 

Helius menawarkan metode RPC `getPriorityFeeEstimate`, yang memberikan rekomendasi biaya berdasarkan data historis dari pasar global dan LFM. Developer dapat memasukkan transaksi bertanda tangan yang diserialisasi atau daftar account key yang terlibat dalam transaksi. Metode ini mendukung tingkat biaya prioritas khusus yang dikategorikan menjadi enam persentil: min, low, medium, high, very high, dan unsafe max. Medium (persentil ke-50) ditetapkan sebagai rekomendasi default. Biaya dihitung menggunakan data dari 50 slot terbaru.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Di atas: Contoh payload untuk getPriorityFeeEstimate yang menggunakan transaksi terserialisasi dengan encoding base58.

Tanpa metode deterministik untuk menghitung biaya prioritas, developer sering mengambil pendekatan hati-hati dengan membayar lebih agar transaksi mereka diproses. Sebagai alternatif, mereka dapat menggunakan tip Jito secara berlebihan, bahkan untuk transaksi yang tidak perlu mendapatkan posisi teratas dalam blok. Tip ini sering digunakan sebagai pengganti biaya prioritas. Khususnya, sebagian besar tip yang diamati pada 2024 tidak terkait dengan aktivitas MEV tradisional, seperti arbitrase atau sandwiching, tetapi ditujukan untuk mempercepat penyertaan transaksi. Validator memperoleh manfaat dari inefisiensi ini dengan mengumpulkan imbalan blok dan komisi MEV yang lebih tinggi.

Tantangan lain muncul ketika developer tidak menerapkan logika untuk menyesuaikan biaya prioritas secara dinamis sebagai respons terhadap perubahan kondisi on-chain. Selama peristiwa besar, seperti pergerakan pasar yang signifikan, biaya untuk mengakses state account tertentu dapat melonjak drastis. Aplikasi yang tidak memiliki mekanisme biaya dinamis akan kesulitan dalam skenario ini karena pengaturan biaya statisnya tidak cukup untuk memastikan eksekusi tepat waktu.

Solusi yang Diusulkan

Berbagai strategi telah diusulkan untuk lebih menyempurnakan struktur biaya Solana. Proposal-proposal ini bertujuan mengoptimalkan alokasi sumber daya jaringan dan mengurangi insentif untuk melakukan spam.

Biaya Write Lock Eksponensial

Diusulkan pada Januari 2023 oleh Tao Zhu (Anza) dan Anatoly Yakavenko, SIMD-0110 mengajukan mekanisme baru untuk mengelola kemacetan dengan mengenakan biaya dinamis pada account yang diperebutkan. Mekanisme ini melacak Exponential Moving Average (EMA) penggunaan compute unit (CU) untuk account yang di-write-lock dan meningkatkan biaya write lock pada account yang secara konsisten memiliki penggunaan tinggi.

Untuk menerapkan sistem tersebut, runtime Solana menyimpan cache LRU (Least Recently Used) berisi public key untuk account yang diperebutkan beserta Compute Unit Pricer (CUP) terkait. CUP memantau EMA penggunaan CU suatu account dan memberikan tarif biaya terbaru saat diminta.

Mekanisme ini menyesuaikan biaya write lock secara dinamis. Tarif biaya write lock meningkat jika EMA penggunaan CU suatu account melampaui ambang target. Sebaliknya, jika penggunaan turun di bawah target, tarif biaya akan menurun. Parameter awal mencakup:

• Target penggunaan sebesar 25% dari batas CU maksimum account.
• Tarif awal biaya write lock sebesar 1.000 micro-lamport per CU.
• Tingkat penyesuaian biaya sebesar 1% per blok.

Biaya write lock untuk suatu account dihitung dengan mengalikan tarif biayanya dengan CU yang diminta transaksi. Dalam sistem ini, total biaya transaksi adalah jumlah dari tiga komponen: biaya dasar tanda tangan, biaya prioritas, dan biaya write lock. Biaya write lock dibakar 100%.

Saat dirilis, SIMD-0110 memicu perdebatan hangat dalam komunitas. Namun, proposal tersebut kini tidak aktif dan telah ditandai sebagai ditutup.

Biaya Dasar Dinamis

Solusi jangka panjang lainnya untuk meningkatkan LFM Solana adalah memperkenalkan biaya dasar dinamis (dynamic base fees/DBF) secara global dan per account. Jarry Xiao dan Eugene Chen dari Ellipsis Labs adalah pendukung terkemuka pendekatan ini.

Biaya prioritas bersifat opsional, sedangkan biaya dasar bersifat wajib. Saat ini, biaya dasar Solana ditetapkan sebesar 5000 lamport per tanda tangan. Pengguna yang mengirimkan transfer token sederhana membayar biaya dasar yang sama dengan pengguna yang melakukan swap kompleks di banyak venue atau searcher yang mencoba mengeksekusi arbitrase MEV yang rumit. Biaya dasar tidak mencerminkan penggunaan komputasi transaksi secara akurat.

Dengan biaya dasar dinamis, transaksi arbitrase yang memiliki biaya dasar tidak sesuai dapat dianggap tidak valid dan dibatalkan sebelum mencapai scheduler. Menaikkan biaya dasar mendorong pelaku spam untuk mengirimkan lebih sedikit transaksi.

Biaya dasar pada akhirnya akan mencapai keseimbangan, dan harga transaksi akan ditentukan berdasarkan nilai pasar blockspace. Karena biaya dasar terus meningkat, biaya tersebut pada akhirnya akan mencapai biaya marjinal ketika pengiriman transaksi tidak lagi sebanding dengan biaya peluang perdagangan. Biaya tidak boleh terlalu tinggi karena akan memengaruhi aktivitas pengguna. Batas maksimum yang terlalu tinggi bagi bot tetapi secara umum masih dapat diterima pengguna adalah kondisi ideal. Dalam sistem seperti ini, account yang melakukan spam transaksi agar disertakan akan membakar seluruh SOL miliknya.

Waktu blok Solana yang cepat memungkinkan algoritma agresif untuk menetapkan biaya dasar. Selama periode permintaan tinggi, biaya dapat disesuaikan dengan cepat—bahkan berpotensi berlipat ganda pada setiap blok—untuk mencerminkan kemacetan jaringan. Sebaliknya, saat permintaan menurun, biaya dapat dikurangi secara lebih bertahap. Berkat waktu blok Solana yang singkat, penurunan biaya tetap terjadi relatif cepat, sehingga jaringan dapat segera beradaptasi terhadap perubahan kondisi.

Contoh bentuk tekanan balik ekonomi serupa adalah program Metaplex Candy Machine, yang memberlakukan pajak bot sebagai mekanisme anti-spam pada 2022. Pajak bot adalah biaya opsional untuk transaksi yang tidak valid. Biasanya, jumlahnya cukup kecil agar tidak memengaruhi pengguna nyata yang melakukan kesalahan wajar. Pajak ini terbukti efektif; dana mint sniper cepat terkuras dan spam pun berhenti.

Kesimpulan

LFM Solana berfungsi, tetapi masih memiliki banyak ruang untuk ditingkatkan:

• Meningkatkan Mekanisme Biaya Prioritas: Panggilan RPC biaya prioritas perlu ditingkatkan. Idealnya, developer memiliki cara sederhana dan deterministik untuk menetapkan biaya yang menjamin transaksi disertakan dalam beberapa blok berikutnya.
• Mengurangi Insentif Ekonomi untuk Spam: Jaringan harus menemukan cara menerapkan tekanan balik ekonomi terhadap bot selama periode aktivitas ekonomi tinggi sekaligus mempertahankan biaya rendah bagi pengguna manusia yang sebenarnya.
• Mengedukasi Developer: Developer perlu berhenti menetapkan biaya transaksi aplikasi secara statis dan mengurangi ketergantungan pada mekanisme di luar protokol seperti Jito untuk transaksi rutin.
• Pengoptimalan Scheduler Lebih Lanjut: Scheduler transaksi memerlukan pengoptimalan lebih lanjut untuk memastikan semua worker thread digunakan selama periode permintaan tinggi.

Seperti yang disampaikan co-founder Solana Anatoly Yakovenko, tantangan-tantangan ini pada dasarnya “hanyalah masalah rekayasa”—dan dapat diselesaikan dengan fokus teknis yang tepat.

Referensi Tambahan

• Biaya Solana, Bagian 1 - Umbra Research
• Menuju Biaya Solana Multidimensi - Umbra Research
• Pasar Biaya Lokal Diperlukan untuk Menskalakan Ethereum - Eclipse Labs
• Pasar Biaya Lokal Solana Tidak Nyata | Eugene Chen - Lightspeed Podcast
• Banking Stage dan Scheduler Solana - A.Fitzgerald