Biaya Solana dalam Teori dan Praktik

Pendahuluan

Struktur biaya Solana dirancang untuk mempertahankan kinerja jaringan sekaligus menyeimbangkan guncangan penawaran dan permintaan yang tidak merata. Biaya pada blockchain berfungsi untuk mencegah spam dan memberikan insentif kepada validator. Di Solana, beberapa biaya ini disesuaikan secara dinamis berdasarkan kondisi jaringan sehingga jaringan dapat menetapkan harga permintaan secara lebih akurat pada waktu tertentu.

Biaya di Solana merupakan topik hangat, dengan “pasar biaya lokal” yang memberikan fleksibilitas bagi Solana untuk menetapkan harga ruang blok dan akun tertentu secara lebih akurat. Implementasi saat ini masih jauh dari sempurna, tetapi memberikan jaminan longgar mengenai pengurutan berdasarkan masing-masing akun. Meski Solana masih berada pada tahap awal, bertambahnya stake dan aktivitas dalam jaringan memerlukan pembahasan serta analisis lebih mendalam mengenai dampak langsung dan tidak langsung dari setiap perubahan dalam protokol, seperti perubahan model biaya.

Dalam artikel ini, kami akan membahas biaya secara teoretis serta bagaimana biaya tersebut terwujud secara on-chain. Meski sebagian pihak mengkritik Solana karena dianggap tersentralisasi dan memiliki kekuatan sentralisasi melalui desain QoS berbobot stake serta Turbine, terdapat perbedaan yang jelas antara anggapan tersebut dan apa yang benar-benar terjadi, bahkan setelah bertahun-tahun. Demikian pula, kami bertujuan menganalisis secara menyeluruh bagaimana biaya terwujud melalui perilaku on-chain.

Biaya dalam Teori

Sistem biaya Solana terdiri dari dua komponen: biaya dasar dan biaya prioritas. Secara umum, setiap komponen biaya idealnya memiliki tujuan berikut:

• Biaya dasar: hak untuk menggunakan sumber daya jaringan
• Biaya prioritas: menentukan urutan dalam antrean transaksi pemimpin

Biaya Dasar

Biaya dasar, yang saat ini ditetapkan sebesar 0,000005 SOL (5.000 lamport) per tanda tangan, menjadi dasar biaya transaksi. Biaya ini dibayarkan oleh suatu alamat untuk memperoleh hak menggunakan sumber daya jaringan. Biaya ini merupakan pembayaran sekaligus yang dibayarkan di muka kepada jaringan, terlepas dari jumlah sumber daya aktual yang digunakan untuk mengeksekusi transaksi (atau apakah transaksi tersebut benar-benar dieksekusi). Transaksi Solana meminta sejumlah unit komputasi (CU) tertentu di muka, dan jika jumlah tersebut terlampaui, transaksi akan gagal. Artinya, saat ini pengembang hanya memiliki sedikit atau bahkan tidak memiliki insentif finansial untuk meminimalkan permintaan unit komputasi.

Biaya Prioritas

Selain itu, pengguna dapat membayar biaya prioritas untuk mempercepat transaksi mereka agar peluang disertakan dalam blok lebih tinggi. Ini merupakan jaminan non-deterministik bagi pengguna yang membayar untuk mendapatkan prioritas. Upaya untuk meningkatkan determinisme transaksi sedang berlangsung, dengan perubahan besar pada scheduler yang diperkirakan hadir dalam versi 1.18.

Sebagai catatan tambahan, transaksi voting tidak memiliki biaya prioritas terkait dan diperlakukan secara berbeda dari transaksi standar.

Insentif bagi validator untuk menyertakan transaksi dengan biaya prioritas berada di luar runtime. Pemimpin menerima 50% dari biaya prioritas karena menyertakan transaksi ke dalam bloknya, sedangkan 50% lainnya dibakar.

Saat ini, sebagian besar validator (80%+) menjalankan versi klien Solana Labs atau Jito-Solana yang tidak dimodifikasi. Artinya, validator tersebut menyerahkan “produksi blok” kepada scheduler default (sebagian orang di Solana menyebut “pengurutan blok” sebagai “produksi blok”, padahal istilah tersebut memiliki arti yang sama sekali berbeda di Ethereum). Beberapa tim telah memodifikasi kode klien dan menerapkan scheduler yang lebih kompleks sehingga memberikan kontrol lebih besar atas alur pengurutan. Hal ini memungkinkan sebagian pihak mengekstraksi MEV dengan mengurutkan ulang atau melakukan sandwiching terhadap transaksi.

Indeterminisme Biaya Prioritas

Implementasi scheduler saat ini tidak menjamin bahwa transaksi dengan biaya prioritas lebih tinggi akan disertakan dalam blok tertentu. Sebaliknya, implementasi tersebut hanya memberikan jaminan longgar bahwa transaksi dengan biaya prioritas memiliki peluang lebih besar untuk disertakan dalam blok tertentu. Implementasi scheduler saat ini menggunakan 4 inti eksekusi (2 inti tambahan dicadangkan untuk transaksi voting).

Setiap thread mengoperasikan antreannya sendiri dan memprioritaskan paket secara independen tanpa mengetahui paket yang sedang diproses oleh thread lain. Setiap thread terus menjalankan siklus dari awal hingga akhir untuk mencoba mengunci dan mengeksekusi transaksi. Saat suatu thread menyelesaikan siklusnya, thread tersebut akan mengumpulkan lebih banyak paket dan memulai kembali siklusnya.

Akibatnya, transaksi berprioritas tinggi dapat sedang diproses di posisi teratas antrean satu thread, sementara pada saat yang sama thread lain mungkin sedang menyelesaikan antreannya sendiri dengan memproses transaksi yang melibatkan akun yang sama.

Detail spesifik mengenai implementasi scheduler saat ini dan mendatang akan dibahas dalam artikel terpisah. Untuk memahami bahwa biaya prioritas hanya bekerja secara intra-thread (dalam jalurnya sendiri), bukan inter-thread (antarjalur), cukup dipahami bahwa scheduler masih jauh dari sempurna dan menunjukkan “jitter”.

Biaya dalam Praktik

Keberhasilan Transaksi

Meski biaya merupakan faktor utama yang menentukan apakah transaksi berhasil masuk, biaya bukanlah satu-satunya faktor penentu. Misalnya, transaksi mungkin tidak berhasil masuk hanya karena hilangnya paket jaringan UDP. Selama periode aktivitas jaringan yang tinggi, validator dapat dibanjiri lebih banyak transaksi daripada yang mampu mereka tangani. Meski validator dapat meneruskan kelebihan transaksi melalui mekanisme tpu_forwards, mereka hanya dapat menangani volume data yang terbatas, dan setiap transaksi hanya dapat diteruskan beberapa kali (hingga blockhash kedaluwarsa). Kualitas layanan berbobot stake mengurangi sebagian masalah ini untuk alamat dengan stake lebih tinggi dengan menyediakan bandwidth khusus dan meningkatkan peluang transaksi untuk disertakan.

Terdapat pula dua penyebab transaksi gagal masuk yang lebih jarang dibahas. Penyebab pertama berkaitan dengan perbedaan dalam pool RPC. Satu segmen pool RPC dapat melaju lebih cepat daripada segmen lainnya sehingga menimbulkan masalah koordinasi. Misalnya, jika recentBlockhash suatu transaksi diambil dari segmen yang lebih baru lalu dikirimkan ke segmen yang lebih lambat, segmen tersebut mungkin tidak mengenali blockhash terbaru dan akibatnya membuang transaksi. Pengembang dapat mendeteksi masalah seperti ini saat pengiriman jika pemeriksaan preflight diaktifkan dalam fungsi sendTransaction.

Masalah lain muncul akibat fork jaringan sementara. Jika validator tertinggal dalam memproses bloknya, transaksi dapat berakhir pada fork minoritas yang tidak menjadi kanonis. Ketika klien merujuk recentBlockhash dalam transaksinya yang hanya ada pada fork minoritas tersebut, lalu jaringan meninggalkan fork itu sebelum memproses transaksi, transaksi akan dibuang karena blockhash tidak lagi dapat ditemukan.

Biaya Prioritas

Dalam praktiknya, kami melihat bukti bahwa meski biaya prioritas masih jauh dari sempurna, biaya tersebut bekerja pada skala makro. Transaksi yang menyertakan biaya prioritas memiliki peluang lebih besar untuk disertakan dalam blok, dan transaksi yang menetapkan biaya prioritas lebih tinggi memiliki peluang penyertaan yang lebih besar.

Berdasarkan data Helius RPC, kami melihat bahwa transaksi dengan biaya prioritas memiliki peluang lebih besar untuk berhasil masuk. Ketika berhasil, transaksi tersebut juga masuk lebih cepat secara keseluruhan:

Pada 21 Januari, terjadi lonjakan rata-rata biaya prioritas akibat airdrop mockJUP sebagai persiapan untuk airdrop JUP yang sebenarnya pada minggu berikutnya. Meski permintaan ruang blok mengalami perubahan signifikan, pengguna sebenarnya hanya merasakan perubahan yang relatif kecil pada tingkat dan waktu keberhasilan transaksi.

UX ini terutama didukung oleh metode Solana RPC getRecentPrioritizationFees, yang memungkinkan pengembang menentukan secara akurat biaya prioritas yang akan ditambahkan ke transaksi. Endpoint ini mengembalikan daftar biaya prioritas dari 150 blok terakhir yang berhasil digunakan untuk memasukkan setidaknya satu transaksi dengan alamat dan parameter input terkait. Data ini memberikan gambaran singkat mengenai nilai minimum yang perlu ditetapkan untuk biaya prioritas, tetapi kegunaannya relatif terbatas. Sebagai alternatif, Helius menawarkan Priority Fee API yang melakukan perhitungan tambahan untuk memberikan estimasi biaya prioritas yang lebih baik.

Meski secara teori biaya prioritas bekerja kurang lebih sesuai tujuan, perubahan scheduler mendatang dalam versi 1.18 akan meningkatkan determinisme penyertaan transaksi melalui penyempurnaan scheduler. Hal ini seharusnya mengurangi jumlah spam yang masuk secara on-chain karena strategi dominan tidak lagi mengharuskan spam pada chain agar transaksi dapat disertakan.

Biaya Dasar

Biaya dasar di Solana jelas terlalu rendah. Blok menjadi jenuh dan biayanya tidak dinamis sehingga biaya dasar tidak dapat mencapai harga keseimbangan pasar untuk ruang blok. Di Ethereum, biaya dasar dinamis diwujudkan melalui mekanisme pengendali EIP-1559, yang mengamati blok terbaru dan menargetkan tingkat penggunaan sebesar 50%.

Solana menetapkan harga statis sebesar 5.000 lamport per tanda tangan (biasanya 1 tanda tangan per transaksi). Artinya, biaya ini tidak efektif karena biaya dasar tidak mencerminkan perubahan apa pun dalam permintaan ruang blok dan penggunaan sumber daya validator. Kondisi ini secara efektif mengalihkan fungsi penetapan harga berbasis pasar kepada biaya prioritas sehingga semakin memadati jaringan saat validator memproses transaksi tambahan yang kemungkinan besar tidak akan pernah disertakan. Selain itu, strategi dominannya adalah mengirimkan transaksi dalam jumlah besar dengan biaya prioritas minimal agar dapat disertakan. Hal ini menimbulkan eksternalitas besar terhadap UX bagi seluruh peserta jaringan.

Insentif

RPC mendapatkan insentif untuk meneruskan informasi yang benar ke downstream agar dapat menawarkan tingkat penyertaan transaksi tertinggi dengan biaya minimal. Integrasi dengan validator yang memiliki stake terbesar memungkinkan RPC memperoleh gambaran lebih akurat mengenai kondisi jaringan saat ini karena banyak mekanisme Solana menggunakan pembobotan stake. Hubungan simbiosis pun terbentuk: validator dengan stake signifikan dan RPC yang terintegrasi dapat meningkatkan efisiensi serta keandalan pemrosesan transaksi. Hal ini berpotensi menciptakan siklus umpan balik yang semakin memperkuat posisi validator dengan stake terbesar.

Selain itu, RPC—yang saat ini diperlakukan sebagai validator tanpa stake—nantinya juga akan diberi bobot berdasarkan stake. RPC dapat berupaya menarik stake sendiri tanpa bermitra dengan validator. Aplikasi juga umum menjalankan validatornya sendiri untuk mencapai integrasi vertikal yang lebih tinggi sehingga memiliki kontrol tambahan atas pengalaman pengguna akhir dan rantai pasok transaksi/MEV.

Meski insentif ekonomi menunjukkan kecenderungan menuju sentralisasi stake, Solana belum mengalami aglomerasi modal berskala besar untuk memperoleh keuntungan berbobot stake. Hal ini dapat disebabkan oleh sejumlah alasan:

• Individu mungkin memandang upaya memaksimalkan desentralisasi secara lokal sebagai strategi dominan untuk memperoleh manfaat jangka panjang bagi jaringan, yang terutama didorong oleh budaya dan lapisan sosial Solana.
• Peserta Solana sebagian besar merupakan pengguna ritel dan prosumer yang tidak sesensitif perusahaan profesional terhadap imbal hasil. Seiring meningkatnya tingkat aktivitas dan imbal hasil absolut, hal ini dapat mendorong perubahan demografi peserta dan sensitivitas mereka terhadap imbal hasil.
• Koordinasi antarindividu dalam memasarkan produk terdiferensiasi mereka masih kurang baik.

Kesimpulan

Dalam artikel ini, kami telah menjelaskan secara mendetail teori tingkat tinggi mengenai mekanisme biaya Solana dan dampaknya terhadap jaringan secara on-chain. Biaya mendorong insentif yang menimbulkan eksternalitas besar dan memengaruhi perilaku semua peserta di Solana.

Mekanisme seperti biaya dasar dan biaya prioritas di Solana belum sempurna dalam implementasinya saat ini. Biaya dasar tidak dapat disesuaikan dan tidak mencerminkan keseimbangan penawaran dan permintaan saat ini. Hal ini menimbulkan masalah seperti kemacetan jaringan dan alokasi sumber daya yang tidak efisien. Biaya prioritas menunjukkan tingkat indeterminisme tertentu akibat implementasi scheduler saat ini. Pembaruan mendatang, seperti perubahan scheduler yang telah diantisipasi, menjanjikan determinisme dan efisiensi lebih tinggi dalam pemrosesan transaksi serta berpotensi membentuk ulang perilaku on-chain yang kita amati saat ini.

Proposal baru mulai bermunculan, seperti biaya eksponensial untuk akun dengan write lock, yang bertujuan menetapkan biaya transaksi secara lebih akurat dengan mengunci akses ke akun secara arbitrer. Diskusi tambahan juga berlangsung mengenai mekanisme biaya dasar dinamis yang menetapkan harga akses ke state secara lebih akurat.

Interaksi antara biaya, validator, dan RPC merupakan jaringan insentif yang kompleks. Secara teori, validator dan RPC mendapat insentif untuk berintegrasi dan meningkatkan bobot stake mereka, yang berpotensi menimbulkan kekhawatiran mengenai sentralisasi. Namun, pada kenyataannya, Solana berhasil mempertahankan sekumpulan operator dan stake yang terdesentralisasi. Hal ini kemungkinan disebabkan oleh tata kelola berbasis komunitas, hambatan teknis, kontra-insentif ekonomi, serta fungsi optimasi yang saat ini tidak terutama didorong oleh imbal hasil.