Quality of Service Berbobot Stake: Semua yang Perlu Anda Ketahui

Pendahuluan

Solana berada di garis depan teknologi blockchain sebagai jaringan ber-throughput tinggi dan berlatensi rendah, yang terus mendorong batas kemampuan jaringan terdesentralisasi. Namun, hal ini menimbulkan tantangan besar. Salah satu momen penting dalam perkembangan Solana adalah gangguan pada 30 April 2022, yang menegaskan perlunya mekanisme lebih tangguh untuk menangani volume transaksi tinggi dan mempertahankan performa jaringan di bawah beban berat.

Stake-Weighted Quality of Service (SWQoS) dibuat sebagai respons terhadap peristiwa tersebut. Mekanisme ini memprioritaskan lalu lintas jaringan berdasarkan stake yang dimiliki validator, sehingga validator dengan stake lebih besar dapat mengirim transaksi dengan prioritas lebih tinggi. SWQoS dirancang untuk mencegah validator dengan stake rendah membanjiri jaringan, sekaligus meningkatkan ketahanan dan efisiensi Solana.

Artikel ini membahas SWQoS, model pemrosesan transaksi Solana, dan bagaimana SWQoS memengaruhinya. Artikel ini juga membahas koneksi ber-stake, cara menyiapkannya, serta perbedaan antara SWQoS dan biaya prioritas. Selain itu, artikel ini mengulas implikasi masa depan, khususnya meningkatnya peran validator dan liquid staking token (LST), hambatan masuk, serta asumsi kepercayaan yang melekat pada sistem ini.

Artikel ini mengasumsikan bahwa Anda memahami model pemrograman Solana dan QUIC. Jika belum memahami topik tersebut, sebaiknya baca artikel berikut sebelum mendalami artikel ini:

• Model Pemrograman Solana: Pengantar untuk Mengembangkan di Solana
• Cara Mengatasi Spam dengan QUIC: Semua yang Perlu Anda Ketahui tentang Solana dan QUIC

Meski demikian, konteks akan diberikan bila diperlukan.

Apa Itu Quality of Service Berbobot Stake?

Stake-Weighted Quality of Service (SWQoS) adalah mekanisme yang memprioritaskan lalu lintas jaringan berdasarkan stake yang dimiliki validator. Mekanisme ini memastikan bahwa validator dengan stake lebih besar dapat mengirim transaksi secara lebih efektif, sehingga meningkatkan kualitas layanan mereka.

Karena Solana merupakan jaringan Proof of Stake, menerapkan pembobotan stake pada performa transaksi adalah langkah yang wajar. Sederhananya, Solana menggunakan stake (yaitu dana yang dikunci pada validator untuk mengamankan jaringan) sebagai indikator tingkat kepercayaan suatu validator. Semakin besar stake yang dimiliki validator, semakin besar pula kepentingan mereka terhadap keamanan dan keandalan jaringan. Selain itu, quality of service adalah konsep jaringan yang memprioritaskan paket tertentu agar performanya di jaringan lebih andal. Dengan demikian, Solana memberi validator ber-stake performa yang lebih andal saat mengirim transaksi dengan merutekannya melalui koneksi yang diprioritaskan.

Tujuan utama SWQoS adalah mencegah validator dengan stake rendah membanjiri jaringan dengan transaksi yang dapat menyingkirkan transaksi dari validator berkualitas lebih tinggi atau dengan stake lebih besar. Misalnya, jika suatu validator memegang 5% dari total stake, validator tersebut dapat mengirim 5% dari total paket kepada leader. SWQoS dapat dianggap sebagai mekanisme ketahanan terhadap Sybil, yang mempersulit pelaku jahat membanjiri jaringan dengan transaksi “berkualitas rendah”.

Bayangkan Anda berada di acara populer, seperti konser atau taman hiburan, dengan jumlah tiket terbatas. Ada antrean tiket reguler tempat siapa pun dapat mengantre untuk membeli tiket, tetapi antrean ini bisa menjadi panjang dan lambat. Namun, tersedia juga antrean VIP bagi pelanggan yang membayar lebih. Antrean VIP jauh lebih pendek dan cepat karena aksesnya dibatasi untuk mereka yang memenuhi kriteria tertentu, seperti memiliki keanggotaan khusus, dan sejumlah orang dijamin dapat masuk pada satu waktu. Dalam konteks Solana, SWQoS menyerupai antrean VIP ini, dengan akses yang ditentukan oleh jumlah stake milik validator. Semakin besar stake Anda, semakin banyak akses VIP (yaitu koneksi yang diprioritaskan) yang Anda dapatkan, sehingga pemrosesan tiket (transaksi) menjadi lebih cepat dan andal.

Lalu, bagaimana cara kerjanya dalam praktik? Pertama, penting untuk memahami cara Solana memproses transaksi.

Cara Solana Memproses Transaksi

Transaction Processing Unit (TPU) Solana menangani dan mengeksekusi transaksi secara efisien. Pemrosesan berlangsung melalui beberapa tahap berbeda untuk memastikan transaksi divalidasi, dieksekusi, dan disebarkan ke seluruh jaringan. Tahap-tahap tersebut adalah Fetch Stage, SigVerify Stage, Banking Stage, layanan Proof of History (PoH), dan Broadcast Stage.

Fetch Stage

Fetch Stage menerima transaksi masuk dari klien melalui jaringan. Tahap ini mengelompokkan input dari socket UDP ke dalam batch dan mengategorikannya ke dalam tiga socket utama:

• tpu: Untuk transaksi reguler seperti transfer token, pencetakan NFT, dan interaksi program
• tpu_vote: Untuk transaksi vote
• tpu_forwards: Meneruskan paket yang belum diproses kepada leader berikutnya jika leader saat ini tidak dapat memproses semua transaksi.

Socket ini dibuat di Gossip dan disimpan dalam struct ContactInfo, serta ditandai berdasarkan socket masing-masing.

Fetch Stage menggunakan mekanisme untuk menggabungkan paket yang diterima secara bersamaan, sehingga mengurangi jumlah operasi pemrosesan paket individual sekaligus meningkatkan throughput. Saat menerima paket yang diteruskan, tahap ini menandainya dengan flag FORWARDED agar paket tersebut dikenali sebagaimana mestinya pada tahap berikutnya. Jika node bukan leader saat ini, paket yang diteruskan ini akan dibuang untuk mencegah pemrosesan yang tidak diperlukan. Namun, jika node tersebut adalah leader, paket ini akan diterima dan diproses sebagaimana mestinya.

Fetch Stage membuat channel tanpa batas (misalnya, packet_sender, packet_receiver) untuk meneruskan transaksi ke tahap berikutnya, yaitu SigVerify Stage. Channel ini memisahkan tahap-tahap TPU sehingga setiap tahap dapat berjalan secara bersamaan tanpa saling memblokir. Fungsi unbounded membuat channel dengan kapasitas tak terbatas untuk memastikan paket tidak dibuang akibat channel meluap. 

Transaksi dikelompokkan ke dalam batch berisi 128 paket sebelum diteruskan ke SigVerify Stage. Pengelompokan ini membantu memproses transaksi secara lebih efisien dan mengurangi overhead penanganan setiap paket. 

Perlu diperhatikan bahwa Fetch Stage berjalan dalam beberapa thread untuk menangani throughput tinggi. Setiap thread bertanggung jawab atas tugas tertentu, seperti menerima paket, memproses batch, dan meneruskan transaksi. Satu thread untuk setiap jenis socket (yaitu tpu, tpu_vote, tpu_forwards) dibuat menggunakan fungsi streamer::receiver. Setiap thread memantau socket yang ditetapkan, memproses paket masuk, lalu mengirimkannya melalui channel yang sesuai.

Dengan mengelola penerimaan dan kategorisasi transaksi secara efisien, Fetch Stage membangun fondasi bagi semua tahap pemrosesan berikutnya dalam TPU Solana.

SigVerify Stage

SigVerify Stage adalah tahap kedua dalam alur pemrosesan transaksi Solana. Tahap ini sangat penting untuk memastikan integritas dan keaslian transaksi. 

Pada tahap ini, TPU menerima transaksi dalam batch dari Fetch Stage melalui channel tanpa batas. Tugas utamanya adalah memverifikasi tanda tangan transaksi menggunakan skema tanda tangan Ed25519. Validasi kriptografis ini mengonfirmasi bahwa pemilik sah akun yang terlibat telah menandatangani transaksi tersebut.

SigVerify Stage dirancang untuk menghasilkan performa tinggi dengan memanfaatkan kemampuan pemrosesan paralel CPU dan GPU modern untuk memverifikasi tanda tangan. Secara default, CPU melakukan seluruh pemrosesan. Namun, berkat sifatnya yang terparalelisasi, pemindahan beban ke GPU mempercepat proses secara signifikan ketika pustaka performa tersedia.

Proses dimulai dengan fungsi new, yang menginisialisasi SigVerify Stage dan menyiapkan channel penerima yang diperlukan untuk menerima paket dari Fetch Stage. Fungsi verifier bertanggung jawab menerima batch dan memverifikasi tanda tangan. Fungsi ini menangani deduplikasi, membuang paket berlebih, dan memverifikasi paket yang tersisa. Fungsi tersebut menggunakan metode verifikasi tanda tangan ed25519_verify. Pada periode volume transaksi tinggi, load shedding diterapkan. Dalam proses ini, SigVerify Stage membuang paket yang berlebihan. Tahap ini melakukannya dengan mengelompokkan paket berdasarkan alamat IP sumber dan menetapkan jumlah maksimum paket yang dapat diproses untuk setiap alamat.

Transaksi dengan tanda tangan tidak valid akan ditandai dan dibuang. Proses ini memastikan hanya transaksi valid yang diteruskan, sehingga transaksi curang atau keliru tidak dapat melanjutkan ke tahap berikutnya.

Setelah verifikasi tanda tangan, transaksi valid diteruskan ke tahap berikutnya (yaitu Banking Stage) melalui rangkaian channel tanpa batas lainnya. Hal ini memastikan setiap tahap tetap terpisah dan dapat berjalan secara bersamaan. Perlu diperhatikan bahwa tahap ini berjalan dalam beberapa thread. Setiap thread memproses sebagian transaksi, memverifikasi tanda tangan, serta melakukan deduplikasi dan shedding.

Banking Stage

Banking Stage adalah tahap ketiga dalam alur pemrosesan transaksi Solana. Tahap ini sangat penting karena di sinilah transaksi dieksekusi dan diterapkan pada status ledger saat ini. Banking Stage memanfaatkan runtime Sealevel unik milik Solana untuk memungkinkan pemrosesan transaksi paralel ber-throughput tinggi.

Banking Stage memiliki enam thread—dua didedikasikan untuk memproses transaksi vote dari TPU atau Gossip dan empat untuk transaksi non-vote. Setiap thread berjalan secara independen dan menerima paket dari channel bersama (perlu diperhatikan bahwa hal ini akan berubah setelah versi 1.18), tempat SigVerify mengirim paket dalam batch. Setiap thread mengambil transaksi dari channel bersama ini dan menyimpannya dalam buffer lokal. Buffer lokal bertindak sebagai antrean prioritas yang diperbarui secara dinamis untuk mencerminkan perubahan status transaksi dan kebutuhan jaringan secara real-time. 

Penanganan transaksi ini bergantung pada apakah validator berada dalam jadwal leader. Jika validator belum akan segera menjadi leader, validator meneruskan paket kepada leader berikutnya lalu membuangnya. Ketika giliran validator semakin dekat (sekitar ~20 slot lagi), validator terus meneruskan paket tetapi juga menyimpannya untuk mengantisipasi jika leader berikutnya gagal memproses paket tersebut. Ketika validator tinggal dua slot lagi sebelum menjadi leader, validator menahan paket untuk memastikan paket tersebut diproses saat menjadi leader.

Setiap thread memproses transaksi selama produksi blok dengan mengambil 128 transaksi teratas dari antrean lokalnya. Proses ini mencakup langkah-langkah seperti penguncian, pemeriksaan, pemuatan, eksekusi, pencatatan, commit, dan pembukaan kunci. 

Banking Stage menggunakan pendekatan multi-iterator untuk mengelompokkan transaksi ke dalam batch. Pendekatan ini memungkinkan penelusuran dataset secara bersamaan untuk mengelompokkan transaksi ke dalam batch yang tidak berkonflik. Transaksi terlebih dahulu diserialisasi ke dalam vektor berbasis prioritas. Multi-iterator kemudian menempatkan iterator pada titik-titik ketika transaksi tidak berkonflik, sehingga membentuk batch berisi 128 transaksi. Transaksi yang berkonflik akan dilewati dan dimasukkan ke batch berikutnya setelah konflik terselesaikan. Setelah batch terbentuk, transaksi dieksekusi. Transaksi yang berhasil dicatat dalam layanan Proof of History dan disiarkan ke jaringan melalui Turbine.

Layanan Proof of History (PoH)

Layanan Proof of History (PoH) merupakan komponen mendasar dalam alur pemrosesan transaksi Solana. Layanan ini menyediakan cara yang dapat diverifikasi untuk melacak waktu dan urutan peristiwa di dalam jaringan, sehingga memastikan pengurutan transaksi yang efisien dan aman. Layanan ini menghasilkan rangkaian kriptografis yang berfungsi sebagai stempel waktu transaksi melalui hash-chaining. Rantai hash berkelanjutan ini menciptakan catatan historis yang membuktikan berlalunya waktu di antara peristiwa.

Layanan PoH memastikan semua peserta jaringan dapat menyepakati urutan transaksi tanpa memerlukan pencatat waktu terpusat. Layanan ini juga membantu menyinkronkan validator di seluruh jaringan. PoH mendukung proses pemilihan leader Solana dengan menyediakan stempel waktu yang andal untuk menentukan kapan suatu validator harus menjadi leader dan menghasilkan blok berikutnya.

Layanan PoH dimulai dengan menginisialisasi nilai seed yang menghasilkan rangkaian hash. Ketika transaksi diterima, transaksi tersebut ditandai dengan hash terkini dari rangkaian PoH, sehingga mendapatkan stempel waktu unik. Validator kemudian memverifikasi rangkaian hash untuk mengonfirmasi urutan dan waktu transaksi.

Untuk mempelajari Proof of History lebih lanjut, baca artikel kami Proof of History, Proof of Stake, Proof of Work — Penjelasan. Jika kriptografi terdengar seperti bahasa asing, kami juga menyarankan Anda membaca artikel Dasar-Dasar Alat Kriptografis — Penjelasan Fungsi Hash dan Merkle Tree.

Broadcast Stage

Broadcast Stage adalah langkah terakhir dalam alur pemrosesan transaksi Solana. Tahap ini bertanggung jawab mendistribusikan transaksi yang telah divalidasi dan dikonfirmasi ke seluruh jaringan.

Setelah diproses dan di-commit selama Banking Stage, transaksi dibentuk menjadi entri. Entri ini kemudian dikemas ke dalam struktur data yang disebut shred. Broadcast Stage menyerialisasi shred tersebut, menandatanganinya, dan menghasilkan kode penghapusan untuk meningkatkan integritas serta pemulihan data. Shred dikirim kepada peer melalui proses penyebaran terstruktur berbentuk pohon yang disebut Turbine. Proses distribusi ini efisien dan redundan, sedangkan pengodean penghapusan memungkinkan validator merekonstruksi data yang hilang atau rusak.

Untuk pembahasan Turbine yang lebih menyeluruh, baca artikel kami Turbine: Propagasi Blok di Solana.

Siklus Hidup Transaksi dengan SWQoS

Tidak seperti blockchain lain, Solana tidak memiliki mempool tempat transaksi menunggu sebelum diproses. Sebaliknya, transaksi dirutekan langsung ke leader saat ini dan diproses oleh TPU miliknya. Pengguna membuat transaksi, baik secara langsung maupun tidak langsung, menggunakan dompet atau aplikasi, lalu mengirimkannya ke node RPC melalui JSON RPC API. Node ini bertindak sebagai perantara antara pengguna dan validator Solana. Yang penting, node tersebut tidak boleh memiliki stake apa pun dalam jaringan. Artinya, node RPC tidak ber-stake, tidak melakukan voting, dan karena itu tidak terlibat dalam konsensus.

Koneksi ke leader kini dibuat melalui QUIC. QUIC telah ditambahkan ke port yang menerima transaksi pengguna untuk menggantikan UDP pada TPU Solana. Karena QUIC memerlukan handshake, batasan dapat diterapkan pada lalu lintas pelaku agar jaringan dapat berfokus memproses transaksi asli sekaligus menyaring spam. Tentu saja, inilah tujuan penerapan QUIC, dan efektivitasnya saat ini tidak akan diperdebatkan dalam artikel ini. Hal penting yang perlu diperhatikan adalah bahwa koneksi ke leader dibuat melalui QUIC.

Ada dua jenis koneksi:

• 500 koneksi terbuka yang dapat diakses oleh node RPC mana pun
• 2.000 koneksi berbobot stake yang hanya dapat diakses oleh validator ber-stake. Validator mendapatkan porsi koneksi yang proporsional berdasarkan stake mereka

Agar RPC dapat meneruskan transaksi secara efektif, RPC tersebut harus terhubung sebagai peer dengan validator ber-stake. Karena RPC tidak memiliki stake dalam jaringan, validator perlu memperluas stake mereka secara virtual. Validator dapat menggunakan flag --staked-nodes-overrides untuk mengalokasikan sebagian koneksi ber-stake mereka kepada node RPC tertentu. 

Validator harus menentukan path file YAML menggunakan --staked-nodes-overrides flag untuk mengonfigurasi koneksi berbobot stake. File YAML tersebut berisi pemetaan dalam format:

staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

Setiap public key dari identitas RPC tertentu memerlukan nilai dalam lamport. Nilai ini menentukan bobot stake yang ingin Anda berikan kepada identitas RPC tersebut. Misalnya, jika Anda menentukan satu juta SOL, alokasi yang diberikan adalah satu juta SOL dibagi total stake aktif. Pada dasarnya, Anda memberikan koneksi ber-stake kepada node RPC seolah-olah node tersebut merupakan validator dengan stake sebesar itu dalam jaringan. Anda menyatakan, “Dalam pandangan lokal saya, perlakukan identitas RPC ini seolah-olah memiliki stake sebesar x saat berkomunikasi dengan validator saya.” Perlu diperhatikan bahwa penyiapan ini tidak mengharuskan validator dimulai ulang—perubahan dapat dilakukan pada file dan dimuat ulang saat sistem berjalan.

Selain itu, relayer Jito mendukung flag staked node overrides. Untuk mengoptimalkan performa, sebaiknya relayer dijalankan pada mesin yang sama dengan node ber-stake.

Untuk menggunakan koneksi ber-stake ini, operator RPC harus menggunakan flag --rpc-send-transaction-tpu-peer, yang memerlukan IP dan port TPU milik validator ber-stake. Port TPU biasanya dimulai dari rentang port dinamis ditambah tiga, sebagaimana tercantum di Gossip. Dalam kasus Jito, lalu lintas akan diarahkan ke relayer yang dijalankan operator karena relayer Jito publik tidak dapat digunakan. Operator RPC perlu memeriksa log untuk entri seperti solana_quic_client dan warm guna memverifikasi koneksi. Perlu diperhatikan bahwa penyiapan ini mengharuskan node RPC menjalankan klien Agave v1.17.28 atau lebih baru agar mendukung flag yang diperlukan.

Secara keseluruhan, siklus hidup transaksi dengan SWQoS sebagian besar tetap sama dengan transaksi reguler. Pengguna membuat dan mengirim transaksi melalui node RPC, lalu node tersebut mengirimkannya kepada leader. Namun, transaksi dikirim melalui koneksi ber-stake saat node RPC terhubung sebagai peer dengan validator ber-stake dan menggunakan flag --rpc-send-transaction-tpu-peer. Ringkasnya:

• Pembuatan Transaksi: Pengguna membuat transaksi menggunakan dompet, aplikasi, atau secara terprogram 
• Pengiriman ke Node RPC: Transaksi dikirim ke node RPC melalui JSON RPC API
• Koneksi QUIC: Node RPC membuat koneksi QUIC ke leader dengan memanfaatkan koneksi terbuka atau berbobot stake berdasarkan konfigurasinya
• QoS Berbobot Stake: Jika node RPC telah terhubung sebagai peer dengan validator ber-stake, node tersebut menggunakan koneksi ber-stake milik validator sehingga performa transaksi meningkat
• Penerusan kepada Leader: Transaksi dikirim kepada leader melalui koneksi ber-stake ini, sehingga lebih kecil kemungkinannya untuk tertunda atau dibuang
• Pemrosesan Transaksi: Transaksi melewati TPU, sebagaimana dijelaskan sebelumnya, lalu diproses oleh leader

SWQoS meningkatkan siklus hidup transaksi dengan memastikan validator ber-stake dan node RPC yang terhubung sebagai peer memiliki akses lebih baik ke leader, sehingga mengurangi kemungkinan penundaan akibat kemacetan jaringan. Mekanisme ini bekerja bersama biaya prioritas untuk meningkatkan performa transaksi.

SWQoS vs. Biaya Prioritas: Perbedaan yang Jelas

Dalam skenario kemacetan jaringan, SWQoS memastikan transaksi dari validator dengan stake tinggi lebih kecil kemungkinannya untuk tertunda atau dibuang. Sistem ini dapat, dan sering kali, dianalogikan dengan jalan tol, tempat validator dengan stake lebih besar memiliki akses ke jalur yang tidak terlalu padat, serupa dengan lebih banyak lajur di jalan raya. Perhatikan gambar di atas, misalnya. Di Colorado, pengemudi dapat tetap terjebak kemacetan atau membayar beberapa dolar ekstra untuk berkendara di jalur tol. Express Lanes adalah jaringan jalur premium di Colorado dengan harga yang terus disesuaikan agar cukup tinggi untuk menjaga kelancaran lalu lintas. Karena itu, koneksi ber-stake Solana dapat dianalogikan dengan Express Lanes di Colorado karena keduanya merupakan jalur yang diprioritaskan untuk mengurangi kemacetan bagi pengguna premium.

Namun, penting untuk membedakan SWQoS dari biaya prioritas, karena analogi umum tentang jalan tol berpotensi mengaburkan perbedaan antara kedua konsep tersebut:

• Biaya prioritas berperan selama Banking Stage ketika leader memprioritaskan transaksi berdasarkan biaya yang dibayarkan. Gagasannya adalah transaksi yang membayar biaya lebih tinggi akan diproses lebih awal, sehingga pengguna yang bersedia membayar lebih mendapatkan eksekusi lebih cepat.
• SWQoS meningkatkan akses koneksi dan tidak memengaruhi prioritas transaksi di dalam antrean transaksi leader. SWQoS memastikan validator ber-stake memiliki akses lebih baik ke jaringan, sehingga mengurangi kemungkinan transaksi tertunda atau dibuang akibat kemacetan jaringan

Biaya prioritas memengaruhi urutan dan cara transaksi diproses setelah berada dalam antrean leader, sedangkan SWQoS memastikan transaksi yang dikirim oleh validator ber-stake memiliki jalur prioritas untuk mencapai leader. Kedua mekanisme ini bertujuan meningkatkan performa jaringan, tetapi bekerja pada tahap yang berbeda dalam siklus hidup transaksi.

Perang SWQoS

Ke depannya, SWQoS akan menjadi aspek mendasar dari infrastruktur jaringan Solana. SWQoS akan sangat memengaruhi ekosistem dengan mengoptimalkan pemrosesan transaksi dan memprioritaskan koneksi dari validator ber-stake ke leader. Pentingnya fakta ini tidak dapat saya tekankan lagi.

Dapat dikatakan bahwa keunggulan menggunakan validator dengan stake tinggi mulai berkurang ketika jaringan tidak mengalami kemacetan dan transaksi tidak sensitif terhadap waktu. Alasannya, jaringan memiliki kapasitas yang cukup untuk memproses transaksi dengan cepat, terlepas dari bobot stake di baliknya. Namun, seiring meningkatnya permintaan terhadap Solana dan adopsi massal yang semakin dekat, jaringan mungkin tidak selalu memiliki kapasitas yang cukup untuk memproses setiap transaksi tanpa penundaan atau pembuangan sesekali. Ini bukan berarti Solana tidak dapat diskalakan, karena Solana bisa dibilang merupakan salah satu, jika bukan yang terbaik, dari berbagai peluang untuk mewujudkan blockchain yang dapat diskalakan. Intinya, seiring meningkatnya permintaan, SWQoS akan tetap penting untuk menghadirkan UX yang luar biasa.

Pada akhirnya, peran validator menjadi semakin penting, sehingga mendorong lebih banyak persaingan dan inovasi untuk menyediakan layanan terbaik. Bukankah ini secara alami berarti semua orang ingin menjalankan validator sendiri?   

Validator dan Liquid Staking Token (LST)

Trennya jelas: setiap protokol Solana yang serius akan menjalankan validator. Hal ini diperlukan untuk mendukung aplikasi mereka. Jika tertarik menjalankan validator sendiri, kami memiliki panduan memulai di blog Helius.

Kita berada di ambang ledakan Kambrium LST besar-besaran di Solana, yang semakin dipercepat oleh SWQoS. Pada bulan ini saja, total stake (yaitu Native + LST) naik sekitar 3,2 juta. Nilai pasar LST saja saat ini berada dalam kisaran 6 hingga 9 miliar dolar untuk bulan ini. Protokol seperti Sanctum berpotensi menjadi pemain besar karena platformnya memungkinkan validator dan aplikasi membuat LST sendiri. Selain itu, Picasso Network memungkinkan restaking di Solana dan bertindak sebagai hub agar LST memiliki lebih banyak utilitas serta imbal hasil. Dengan demikian, kemampuan membuat LST dengan utilitas tambahan sudah tersedia dan digunakan secara luas.

Namun, beberapa potensi hambatan masuk perlu dipertimbangkan.

Hambatan Masuk

Terlepas dari potensi manfaatnya, SWQoS menghadirkan beberapa hambatan masuk. Secara khusus, persyaratan stake minimum diperkenalkan pada klien Agave v1.17.31 untuk memperlakukan validator dengan stake rendah sebagai peer tanpa stake. Masalahnya adalah node ber-stake dengan stake rendah dapat menyalahgunakan koneksi ber-stake dengan menerima bandwidth yang tidak proporsional. Kini, node dengan rasio stake di bawah rumus berikut diperlakukan sebagai node tanpa stake:

stake / total_stake < 1 / (max packet per 100ms)

Artinya, klien dengan stake kurang dari sekitar 15.000 SOL kini diklasifikasikan sebagai validator tanpa stake. Persyaratan ini dapat semakin menambah tuntutan finansial dan teknis yang sudah tinggi untuk menjalankan validator Solana, sehingga berpotensi menghalangi pemain kecil dan validator independen berpartisipasi dalam jaringan. Persyaratan ini setara dengan sekitar 3 juta dolar AS, jumlah yang sekilas sangat besar. 

Namun, seperti disampaikan Austin Federa, ambang tersebut hanya sebesar 1/25.000 dari total stake, yang bisa dibilang rendah. Selain itu, jika mayoritas validator yang bersaing mendapatkan stake terus meningkatkan performa untuk menyediakan layanan terbaik dan memaksimalkan imbal hasil mereka, jaringan secara keseluruhan akan diuntungkan. Inilah tepatnya yang digambarkan Toly sebagai tujuan utama SWQoS.

Di Helius, kami menurunkan hambatan masuk untuk semua paket berbayar yang mengirim transaksi dengan biaya rekomendasi Helius. Artinya, setiap pengguna yang mengirim transaksi melalui paket bersama berbayar kini akan dirutekan melalui koneksi ber-stake kami jika mereka mengirim dengan nilai yang sama atau lebih tinggi dari nilai rekomendasi Priority Fee API kami. Kami juga telah menyederhanakan proses ini dengan fungsionalitas Smart Transactions baru yang ditambahkan ke SDK Node.js dan Rust kami. Pada tingkat paling dasar, apa pun SDK yang digunakan, pengguna cukup memberikan keypair dan instruksi yang ingin dieksekusi, lalu kami menangani sisanya. Kini, pengguna dapat mengakses koneksi ber-stake bersama hanya dengan 50 USD per bulan pada paket Developer. Perlu diperhatikan bahwa kami juga menawarkan koneksi ber-stake khusus yang menjamin bandwidth koneksi ber-stake dan direkomendasikan untuk perusahaan, analis kuantitatif, dan firma perdagangan. Jika tertarik dengan koneksi ber-stake khusus, silakan hubungi tim penjualan kami.

Penting untuk diperhatikan bahwa stake kemungkinan akan mulai terkonsentrasi pada validator yang dijalankan oleh protokol besar dan penyedia RPC yang dapat mengenakan komisi 0%. Ambil Helius sebagai contoh; kami dapat menghasilkan pendapatan dari sumber lain untuk menyubsidi biaya pengoperasian validator. Kami melakukan ini untuk meningkatkan desentralisasi jaringan dengan menjalankan validator papan atas melalui tim asli Solana, sekaligus memperoleh akses lebih besar ke koneksi ber-stake guna meningkatkan pengalaman pengguna kami.

Asumsi Kepercayaan

Jika stake kemungkinan terkonsentrasi pada validator yang dijalankan oleh protokol besar dan penyedia RPC, penting untuk melakukan staking pada validator yang mengutamakan kepentingan terbaik Solana. SWQoS menghadirkan beberapa asumsi kepercayaan.

Salah satu asumsi kepercayaan utama adalah perlunya tingkat kepercayaan tinggi antara validator dan node RPC. Seperti dijelaskan sebelumnya, SWQoS memungkinkan leader mengidentifikasi dan memprioritaskan transaksi dari validator ber-stake. Karena node RPC tidak ber-stake, tidak melakukan voting, dan tidak terlibat dalam konsensus, node tersebut tidak dapat memperoleh manfaat langsung dari transaksi yang diprioritaskan seperti validator ber-stake. Karena itu, hubungan tepercaya harus dibentuk antara validator dan node RPC agar keduanya dapat memanfaatkan SWQoS.

Hubungan kepercayaan ini sangat penting karena mengaktifkan SWQoS melibatkan pembagian konfigurasi jaringan sensitif dan memungkinkan node RPC memengaruhi prioritas transaksi. Validator harus memastikan bahwa node RPC yang terhubung sebagai peer akan bertindak demi kepentingan terbaik jaringan dan tidak menyalahgunakan stake yang diperluas untuk tujuan jahat. Validator dan node RPC perlu memiliki kesepakatan sebelumnya serta pemahaman bersama tentang bagaimana koneksi ber-stake akan digunakan. Idealnya, penyiapan ini dilakukan antara entitas dengan tingkat kepercayaan tinggi, seperti mitra jangka panjang atau pihak dalam organisasi yang sama.

Saat ini, hubungan semacam ini sering kali tersembunyi. Ke depannya, saya tidak membayangkan masa depan ketika operator RPC tidak bernegosiasi dengan validator untuk mendapatkan staked overrides. Transparansi yang lebih besar diperlukan agar pengguna biasa mengetahui RPC dan validator mana yang mereka dukung. Permintaan atas transparansi ini hanya akan terus meningkat.

Kesimpulan

SWQoS siap merevolusi infrastruktur jaringan Solana. Meskipun menawarkan banyak manfaat, termasuk peningkatan performa transaksi dan ketahanan Sybil, SWQoS juga menghadirkan tantangan serta asumsi kepercayaan baru yang harus dikelola dengan cermat. Walaupun SWQoS dirancang untuk memprioritaskan transaksi yang dikirim validator ber-stake, saat ini tidak ada mekanisme yang memberlakukan prioritas tersebut. Validator yang serius sering menimpa pengaturan default dan bahkan dapat memblokir pelaku tertentu. Hal ini menegaskan perlunya kepercayaan dan transparansi dalam hubungan antara validator dan node RPC guna memastikan penggunaan SWQoS yang adil dan efektif. Terlepas dari itu, penerapannya menandai langkah maju yang signifikan dalam evolusi Solana sebagai jaringan yang efisien dan tangguh.

Dalam artikel ini, kita telah membahas SWQoS dan bagaimana mekanisme tersebut memengaruhi pemrosesan transaksi. Kita juga membahas perbedaan penting, seperti perbedaan antara SWQoS dan biaya prioritas. Selain itu, kita mengulas meningkatnya peran validator dan LST, potensi hambatan masuk, serta asumsi kepercayaan yang terkait, sehingga menyediakan titik awal penting bagi pembahasan selanjutnya. Memahami semua elemen ini sangat penting untuk memanfaatkan SWQoS secara efektif dan meningkatkan Solana secara keseluruhan.

Jika Anda telah membaca sejauh ini, terima kasih, anon! Pastikan memasukkan alamat email Anda di bawah agar tidak pernah melewatkan kabar terbaru tentang Solana. Siap mendalami lebih jauh? Jelajahi artikel terbaru di blog Helius dan lanjutkan perjalanan Solana Anda hari ini.

Sumber Daya Tambahan

• Laporan dan Mitigasi Gangguan Solana Mainnet Beta 30-04-22
• Panduan Quality of Service Berbobot Stake di Solana
• Cara Menyiapkan Validator Solana
• Mengirim Smart Transactions
• Edukasi Validator Solana — QoS Berbobot Stake