Pembaruan Agave v2.0: Semua yang Perlu Anda Ketahui

Ringkasan Agave 2.0

Peluncuran klien validator Agave v2.0 menandai pencapaian penting dalam perjalanan Solana menuju ekosistem multiklien yang lebih tangguh. Pembaruan ini menghadirkan sejumlah peningkatan penting untuk memperkuat performa, keandalan, dan efisiensi jaringan. Perubahan utama dalam pembaruan ini meliputi:

• Refaktorisasi dan pengoptimalan codebase secara ekstensif
• Imbalan epoch yang dipartisi
• Pemberian seluruh priority fee kepada validator
• Central scheduler baru kini aktif secara default
• Program ZK ElGamal Proof
• Syscall Get-Sysvar
• Syscall GetEpochStake
• MoveStake dan MoveLamports
• Penghapusan metode RPC yang tidak digunakan lagi
• Penggantian nama crate

Baik Anda menjalankan validator, membangun di platform ini, maupun aktif menggunakan Solana, ringkasan menyeluruh tentang pembaruan Agave 2.0 ini akan membekali Anda dengan wawasan yang diperlukan untuk memahami dan memanfaatkan inovasi terbaru tersebut.

Apa yang menjadikan Agave 2.0 pembaruan versi mayor?

Tidak ada lagi satu ‘validator Solana’ saja. Agave 2.0 merangkul dunia multiklien baru Solana dan menandai pemisahan penuh dari repositori GitHub Solana Labs yang lama. Repositori Solana Labs akan diarsipkan dan tidak lagi menerima pull request atau issue baru. Sebelumnya, repositori ini mencerminkan aktivitas dari repositori Agave. Jika belum melakukannya, developer harus memindahkan seluruh aktivitas ke repositori GitHub Anza Agave. Proses migrasi Solana Labs ke Agave dimulai pada 1 Maret dan dilacak secara publik di GitHub mereka.

Seiring berkembangnya ekosistem, operator harus beradaptasi untuk menjalankan satu atau beberapa klien. Menyusul peralihan ini, sejumlah crate diganti namanya untuk mengosongkan namespace demi mendukung banyak klien—terutama Firedancer — yang dikelola oleh tim developer independen. Crate yang dikelola Anza kini akan menggunakan awalan "agave", sehingga mudah dikenali sebagai dependensi khusus Anza dalam lingkungan multiklien.

‍Crate yang terdampak adalah: 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Seperti dijelaskan dalam panduan transisi sebelumnya, pembaruan 2.0 menghadirkan sejumlah breaking change, terutama penghapusan beberapa endpoint usang yang tidak digunakan lagi—pembaruan penting yang semestinya sudah diketahui semua developer Solana. Detail lengkap perubahan RPC disertakan di akhir artikel ini.

Peluncuran Fitur

Saat artikel ini ditulis, ~20,7% validator menjalankan versi 2.0.14. Aktivasi feature gate di mainnet dihentikan sementara agar adopsi v2.0 dapat lebih selaras dengan aktivasi di testnet dan devnet. Setelah klaster mainnet mengadopsi v2.0 secara luas, aktivasi feature gate diperkirakan akan dilanjutkan sesuai urutan aktivasi terjadwal. 

Fitur-fitur lengkap baru yang dibahas di bagian berikut saat ini belum aktif dan akan diluncurkan secara bertahap sepanjang siklus hidup 2.0 menggunakan sistem feature gate. Fitur diaktifkan pada epoch tertentu berdasarkan prioritas relatif dan urutan aktivasinya di klaster testnet dan devnet.

Memberikan Seluruh Priority Fee kepada Validator

Pembaruan ekonomi yang sangat dinantikan dan banyak diperdebatkan ini kini diterapkan menyusul proposal SIMD-0096, yang melalui pemungutan suara tata kelola validator pada bulan Mei. Pemungutan suara berakhir pada penghujung epoch 620, dengan partisipasi 51,17% stake dan 77,77% suara mendukung. Pembaruan yang dikendalikan feature gate ini akan mengubah secara mendasar cara jaringan menangani priority fee. Berbeda dengan model saat ini yang membakar 50% biaya dan memberikan 50% kepada validator, model baru akan mengalokasikan 100% priority fee langsung kepada validator.

Walaupun secara teknis bersifat opsional, priority fee telah menjadi praktik standar seiring meningkatnya aktivitas ekonomi di Solana. Biaya ini dihitung dalam micro-lamport (sepersejuta lamport) per compute unit menggunakan rumus:

‍biaya prioritas = harga compute unit (micro-lamport) x batas compute unit

Ke depannya, seluruh priority fee akan diberikan kepada produsen blok. Hal ini menciptakan keselarasan insentif yang lebih kuat dan mengurangi kemungkinan validator membuat kesepakatan di luar protokol untuk memasukkan transaksi, yang pernah menjadi masalah sebelumnya.

Meskipun penghapusan pembakaran biaya sedikit meningkatkan tingkat inflasi bersih SOL, penerbitan token baru melalui imbalan staking memberikan dampak yang jauh lebih besar. Untuk uraian lebih mendetail tentang dinamika ini, pembaca dapat merujuk ke artikel blog Helius kami sebelumnya mengenai jadwal penerbitan dan inflasi Solana.

Imbalan Epoch yang Dipartisi

Imbalan epoch yang dipartisi bertujuan mendistribusikan imbalan stake ke beberapa blok, sehingga mengurangi masalah performa akibat pemusatan distribusi imbalan pada blok pertama setiap epoch baru. Hambatan utama dalam proses ini adalah keharusan menuliskan kembali pembaruan ke jumlah akun stake aktif yang terus bertambah di jaringan, yang kini mencapai sekitar 1,4 juta.

Dengan pendekatan baru ini, penghitungan dan distribusi imbalan stake pada batas epoch akan dibagi menjadi dua fase berbeda:

• Fase Penghitungan Imbalan: Dalam fase ini, imbalan epoch untuk seluruh akun stake aktif dihitung, lalu distribusinya dibagi menjadi bagian-bagian terjadwal.
• Fase Distribusi Imbalan: Imbalan epoch yang telah dihitung sebelumnya untuk akun stake aktif didistribusikan sebagaimana mestinya.

Untuk memfasilitasi dan memantau proses ini, akun Sysvar EpochRewards akan melacak dan memverifikasi distribusi imbalan sepanjang fase distribusi. Sysvar EpochRewards mencatat apakah fase distribusi imbalan sedang berlangsung serta informasi yang diperlukan untuk melanjutkan distribusi ketika memulai dari snapshot. 

Penghitungan Imbalan

Penghitungan imbalan akan dilakukan pada blok pertama epoch. Setelah dihitung, imbalan dipartisi menjadi bagian-bagian distribusi yang disimpan di bank, lalu didistribusikan selama fase distribusi imbalan.

Untuk meminimalkan dampak terhadap waktu pemrosesan blok selama fase distribusi imbalan dan memastikan setiap blok mendistribusikan sebagian imbalan secara deterministik, target sebanyak 4.096 imbalan stake akan didistribusikan per blok. Untuk mengantisipasi pertumbuhan drastis jumlah akun stake, jumlah blok dibatasi hingga 10% dari total slot dalam satu epoch. Jumlah akun per partisi hanya boleh melampaui target 4.096 jika batas blok ini tercapai.

Distribusi Imbalan

Distribusi imbalan dimulai segera setelah fase penghitungan imbalan, mulai dari blok kedua epoch. Distribusi imbalan berlangsung di awal blok sebelum pemrosesan transaksi normal.

Akibatnya, pengguna mungkin melihat imbalan masuk ke akun stake mereka beberapa blok lebih lambat dibandingkan sebelumnya. Namun, pengalaman secara keseluruhan tetap serupa karena waktu blok pertama yang lebih lama pada batas epoch sebelumnya juga menunda akses pengguna ke akun stake. Manfaat tambahan pendekatan ini adalah transaksi non-staking dapat terus diproses dengan lancar, sedangkan sebelumnya transaksi tersebut terhambat selama distribusi imbalan.‍

Karena jumlah akun vote relatif sedikit, sekitar 1.500, mekanisme yang ada untuk mendistribusikan imbalan vote pada blok pertama batas epoch tidak akan berubah. Hanya imbalan stake yang akan didistribusikan ke beberapa blok.

Central Scheduler Kini Aktif secara Default

Pertama kali diperkenalkan sebagai rilis fitur dalam pembaruan v1.18, central scheduler, yang sebelumnya dikenal sebagai “the scheduler”, tidak diaktifkan secara default dan harus diaktifkan oleh operator menggunakan flag --block-production-method central-scheduler saat memulai validator. Kini fitur tersebut aktif secara default. Implementasi scheduler sebelumnya memiliki sejumlah masalah yang dapat berdampak buruk terhadap performa. Hambatan dalam pemrosesan transaksi sering kali menimbulkan jitter atau inkonsistensi dalam pengurutan dan penentuan prioritas transaksi.

Implementasi yang lebih baru menggantikan model sebelumnya yang menggunakan empat thread banking independen, yang masing-masing mengelola penentuan prioritas dan pemrosesan transaksinya sendiri. Dalam struktur yang diperbarui ini, central scheduler menjadi satu-satunya penerima transaksi dari tahap SigVerify milik TPU. Central scheduler membuat antrean prioritas dan menerapkan grafik dependensi yang disebut prio-graph untuk mengelola pemrosesan dan penentuan prioritas transaksi yang berkonflik dengan lebih baik. Desain scheduler baru ini meningkatkan skalabilitas dan fleksibilitas, sehingga jumlah thread dapat ditingkatkan tanpa kekhawatiran sebelumnya tentang meningkatnya konflik lock. Peluncuran awal central scheduler terbukti menghasilkan imbalan yang lebih baik, sehingga meningkatkan pendapatan banyak operator. Artikel Helius kami sebelumnya tentang pembaruan Solana v1.18 telah membahas secara mendalam cara kerja central scheduler.

Program ZK ElGamal Proof

Program ZK Token Proof, yang awalnya direncanakan untuk disertakan dalam rilis 1.17, kini tidak digunakan lagi dan akan digantikan oleh program ZK ElGamal Proof yang lebih serbaguna dan independen dari aplikasi. Program ZK ElGamal Proof baru mempertahankan bagian-bagian program ZK Token Proof yang berlaku secara luas di berbagai aplikasi, seperti memverifikasi validitas public key atau rentang nilai yang dienkripsi dalam ciphertext ElGamal. Namun, program ini tidak menyertakan elemen khusus aplikasi seperti validasi zero-knowledge proof yang diperlukan untuk instruksi transfer SPL Token. Program ZK ElGamal Proof baru akan ditambahkan ke daftar program bawaan pada alamat ZkE1Gama1Proof11111111111111111111111111111

Untuk mempelajari lebih lanjut tentang ZK Token Proof Program, baca ulasan awal kami di blog Helius.

Syscall Get-Sysvar

Syscalls, atau system call, meminta layanan dari kernel sistem operasi. Dalam konteks Solana, Syscall memungkinkan program yang berjalan di dalam Solana Virtual Machine (SVM) berinteraksi dengan sumber daya dan layanan eksternal. 

Sysvars mengekspos informasi status klaster, seperti hash blok terbaru dan imbalan epoch. Akun-akun ini ditempatkan pada alamat yang telah diketahui. Program dapat mengakses Sysvar melalui akun Sysvar atau membuat kueri melalui Syscall. Program on-chain menggunakan banyak Sysvar untuk beragam kasus penggunaan, dan Sysvar tertentu sangat penting bagi operasional jaringan.

Syscall Get-Sysvar, yang awalnya diusulkan dalam SIMD-127 oleh engineer Anza Joe Caulfield, menghadirkan antarmuka Syscall terpadu untuk mengakses data Sysvar. Peningkatan ini memungkinkan pengambilan data Sysvar yang sebelumnya tidak dapat diakses, termasuk SlotHashes dan StakeHistory. Dengan antarmuka baru ini, developer dapat mengakses fragmen tertentu dari data Sysvar—seperti memanggil SlotHashes::get_slot(slot) dan StakeHistory::get_entry(epoch)—tanpa harus menduplikasi seluruh struktur data.

Pembaruan ini juga meminimalkan overhead saat mengubah tata letak data Sysvar atau menambahkan Sysvar baru. Sebelumnya, setiap Sysvar baru memerlukan penambahan Syscall terkait, sehingga menciptakan hubungan erat yang seiring waktu memperbesar antarmuka Syscall dan menyulitkan pemeliharaan. Kini, satu Syscall sol_get_Sysvar akan melayani seluruh antarmuka Sysvar, sehingga data dari Sysvar mana pun dapat diambil secara konsisten dan efisien.

Pengenalan Syscall baru ini menyederhanakan proses perubahan dan penambahan Sysvar baru. Hal ini secara signifikan mengurangi kompleksitas dan kebutuhan pemeliharaan antarmuka Syscall. Selain itu, pembaruan ini membuka jalan untuk memperluas akses program BPF ke data Sysvar, sehingga program on-chain dapat membaca lebih banyak informasi Sysvar tanpa memengaruhi ukuran transaksi.

Syscall GetEpochStake

Syscall GetEpochStake baru akan menghadirkan fitur yang sangat dinantikan untuk mengambil stake yang didelegasikan ke akun vote pada epoch saat ini, dengan menyediakan metode on-chain yang lebih efisien dan langsung untuk mengambil informasi tersebut.

Saat ini, program tidak dapat mengakses data real-time mengenai stake yang didelegasikan ke akun vote tertentu untuk epoch saat ini. Hal ini menjadi penghalang bagi kasus penggunaan seperti tata kelola validator dan mekanisme konsensus sekunder. Dengan memungkinkan kueri on-chain atas data ini, aplikasi tersebut dapat diwujudkan dan jalan bagi kasus penggunaan mendatang akan terbuka.

Dengan GetEpochStake, developer memberikan alamat akun vote berukuran 32 byte, lalu syscall akan mengembalikan bilangan bulat u64 yang menunjukkan total stake aktif yang saat ini didelegasikan ke akun vote tersebut. Jika alamat yang diberikan tidak merujuk pada akun vote yang valid atau tidak ada, Syscall hanya akan mengembalikan 0.

MoveStake dan MoveLamports

Dua instruksi program stake baru, MoveStake dan MoveLamports, diperkenalkan untuk memfasilitasi transfer nilai antar-akun stake. Instruksi yang pertama kali diusulkan dalam SIMD-0148 ini membantu developer dengan memungkinkan pemindahan dana antar-akun yang memiliki authority sesuai tanpa kendali withdrawer authority.

Sebelumnya, protokol yang mengelola stake pengguna menghadapi kesulitan saat membagi stake ke beberapa validator dan secara rutin mendelegasikannya kembali di antara validator tersebut. Saat protokol membagi stake pengguna untuk dinonaktifkan, protokol harus mendanai lamport pengecualian rent untuk akun baru. Protokol tidak dapat memperoleh kembali lamport pengecualian rent ketika akun-akun yang dipisahkan tersebut digabungkan.

MoveStake

MoveStake: Instruksi ini memungkinkan stake aktif dipindahkan antar-akun, baik dari satu akun aktif ke akun aktif lainnya maupun dari akun aktif ke akun tidak aktif, sehingga mengaktifkan kembali akun tersebut. Jika seluruh delegasi akun sumber dipindahkan, akun sumber menjadi tidak aktif. Saldo bebas rent tetap tidak tersentuh dalam semua skenario, dan aturan delegasi minimum tetap berlaku untuk akun aktif.

MoveLamports

MoveLamports: Memindahkan kelebihan lamport dari satu akun aktif atau tidak aktif ke akun aktif atau tidak aktif lainnya. "Kelebihan lamport" berarti lamport yang bukan merupakan stake yang didelegasikan maupun diperlukan untuk pengecualian rent. MoveLamports memungkinkan tugas pemeliharaan seperti mengambil kembali lamport dari akun yang digabungkan dan mengonsolidasikan dana yang tidak digunakan.

Untuk menyederhanakan implementasi, perubahan ini tidak mendukung aktivasi atau penonaktifan akun maupun memengaruhi akun stake yang aktif sebagian. Instruksi program baru ini tidak mengubah fungsionalitas yang sudah ada.

Bonus: Crate Solana-SVM

Rilis Agave 2.0 menghadirkan crate solana-svm baru yang memberi developer akses langsung ke komponen inti SVM melalui API ringkas yang independen dari framework validator lengkap. Hal ini membuka pemrosesan transaksi berperforma tinggi Solana untuk aplikasi di luar validator, seperti layanan off-chain, klien ringan, state channel, dan rollup.

Dengan memisahkan API dari bagian runtime lainnya, crate ini meniadakan kebutuhan akan komponen seperti instance Bank, sehingga mengurangi overhead operasional. Developer kini dapat memanfaatkan komponen tangguh yang sama dengan yang mendukung mainnet-beta Solana untuk membangun proyek SVM khusus seperti klien ringan, state channel, rollup, dan layanan off-chain. Inti API ini adalah struct TransactionBatchProcessor, yang memungkinkan aplikasi memproses batch transaksi Solana yang telah disanitasi dengan rangkaian lengkap komponen Agave downstream, termasuk BPF Loader, eBPF, dan virtual machine.

Baca pembahasan mendalam tentang API SVM Baru Anza untuk mengetahui detail lengkap perkembangan menarik ini.

Endpoint RPC yang Dihapus 

Sejumlah endpoint RPC Agave v1 yang usang dan tidak digunakan lagi telah dihapus. Tim Devrel Helius telah menghubungi semua pelanggan yang menggunakan endpoint tersebut. Melalui analisis internal, sebelumnya kami mengidentifikasi sekelompok kecil pelanggan yang aktif menggunakan endpoint berikut, yang akan dihapus:

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

Catatan: Pendekatan alternatif untuk getAccountInfo yang ditampilkan dalam gambar dapat ditemukan di sini.

Breaking change pada SDK meliputi:

• Dukungan untuk Borsh v0.9 dihapus, gunakan v1 atau v0.10 (#1440)
• Copy trait tidak lagi diturunkan pada Rent dan EpochSchedule; beralihlah menggunakan clone()
• solana-sdk: simbol yang tidak digunakan lagi) dihapus 
• solana-program: simbol yang tidak digunakan lagi dihapus

Bagi operator validator, sejumlah argumen validator yang tidak digunakan lagi akan dihapus saat Agave v2.0 dirilis. Daftar lengkapnya dapat ditemukan di sini.‍

Kesimpulan

Pembaruan Agave 2.0 menandai kemajuan besar bagi Solana dengan menghadirkan banyak implementasi fitur dan pengoptimalan runtime. Rilis ini terus mendobrak batas melalui Syscall baru yang canggih, fungsionalitas yang diperluas, dan pemeliharaan menyeluruh, termasuk penggantian nama crate, penghapusan metode RPC yang tidak digunakan lagi, serta penyederhanaan argumen validator. Agave 2.0 memperluas kemampuan Solana sekaligus menyempurnakan performa dan kemudahan penggunaannya. Baik Anda seorang developer, validator, maupun pengguna aktif, pembaruan Agave 2.0 membuka berbagai kemungkinan baru yang menarik bagi semua orang di ekosistem Solana.

Referensi Tambahan

• Jadwal Rilis Agave v2.0
• Log Perubahan Agave v2.0
• Versi Rilis Agave