Pembaruan Agave v2.3: Semua yang Perlu Anda Ketahui

Pendahuluan

Rilis v2.3 dari klien validator Agave menandai kemajuan signifikan lainnya bagi Solana. Seperti pembaruan sebelumnya, versi baru ini menghadirkan peningkatan penting yang dirancang untuk meningkatkan performa jaringan sekaligus pengalaman developer.

Pembaruan Penting Agave 2.3 

• Klien TPU baru tpu-client-next
• Pengoptimalan AccountsDB dengan pengurangan penggunaan I/O disk
• Jadwal leader kini menggunakan akun vote sebagai kunci
• Verifikasi peristiwa yang dapat dikenai slashing
• Greedy scheduler diaktifkan secara default
• Penyempurnaan snapshot
• Peningkatan pada gossip
• Transisi epoch yang lebih cepat

Setiap bagian artikel ini dapat dibaca secara mandiri, sehingga pembaca dapat dengan mudah langsung menuju topik yang paling relevan. Baik Anda operator validator, developer, maupun pengguna aktif, panduan lengkap Agave 2.3 ini akan memberikan wawasan utama yang diperlukan untuk memanfaatkan peningkatan terbaru secara maksimal.

Anza mempercepat laju rilis Agave. Kurang dari tiga bulan setelah 2.2, versi 2.3 sudah aktif, dengan 13% dari total stake saat ini menjalankan versi klien baru. Adopsinya diperkirakan meningkat pesat dalam beberapa minggu mendatang. Sementara itu, aktivasi feature gate mainnet dijeda sementara selama peluncuran dan akan segera dilanjutkan sebagai bagian dari rangkaian aktivasi yang direncanakan.

Klien TPU Baru

Agave 2.3 memperkenalkan implementasi baru klien Transaction Processing Unit (TPU), yang menggantikan ConnectionCache sebelumnya. Klien TPU ini bertanggung jawab mengirimkan transaksi yang telah diserialisasi kepada validator melalui jaringan menggunakan protokol QUIC. Desain baru yang dikenal sebagai tpu-client-next ini merupakan perombakan menyeluruh yang ditujukan untuk meningkatkan performa secara signifikan, mengurangi penggunaan sumber daya, dan menyederhanakan arsitektur secara keseluruhan.

Klien TPU digunakan dalam dua skenario utama: di ForwardingStage, tempat validator meneruskan transaksi kepada leader berikutnya, dan di SendTransactionService, yang digunakan oleh RPC untuk meneruskan transaksi kepada leader.

Implementasi sebelumnya, ConnectionCache, dibuat untuk mendukung protokol UDP dan QUIC sekaligus, sehingga menjadi terlalu kompleks. ConnectionCache mengandalkan antrean asinkron internal untuk menyimpan transaksi, alih-alih channel eksplisit, dan menyertakan logika pemanasan cache yang mengirimkan paket kosong. Implementasi ini juga terus mengalami masalah terkait pengelolaan endpoint Quinn (yaitu implementasi QUIC dalam Rust).

tpu-client-next yang baru mengatasi masalah tersebut dengan desain asinkron yang lebih ringkas. Secara internal, desain ini menggunakan model berbasis agen, dengan masing-masing tugas worker menangani setiap koneksi QUIC. Para worker tersebut berkomunikasi dengan ConnectionWorkersScheduler terpusat menggunakan channel asinkron. 

Saat scheduler menerima sekumpulan transaksi, kumpulan tersebut disiarkan kepada rangkaian worker yang sesuai berdasarkan strategi yang dikonfigurasi. Arsitektur ini sepenuhnya menghilangkan multistreaming sehingga mengurangi fragmentasi traffic. Koneksi juga dibuat sebelumnya, yang menghilangkan latensi akibat pembukaan stream baru saat pengiriman.

tpu-client-next menunjukkan peningkatan performa yang jelas. 

• Dalam eksperimen RPC testnet, klien lama dan baru menghasilkan rata-rata TPS yang serupa saat dibebani; namun, tpu-client-next menunjukkan jitter yang jauh lebih rendah. 
• Dalam penggunaan validator, ForwardingStage meningkatkan volume transaksi yang diteruskan sebesar 10%, disertai pola traffic yang lebih stabil dan pengurangan penggunaan CPU sebesar 30%.
• Alat stress testing closed-source milik Anza, transaction-bench, dibuat menggunakan klien terbaru. Alat ini menghasilkan transaksi per detik dua kali lebih banyak dibandingkan alat bench testing sebelumnya, bench-tps.

tpu-client-next sepenuhnya kompatibel dengan versi sebelumnya dan kini menjadi implementasi default untuk node Agave. Jika muncul masalah, operator dapat kembali ke perilaku sebelumnya dengan menjalankan node menggunakan flag --use-connection-cache untuk memulihkan implementasi lama.

Singkatnya, tpu-client-next menghadirkan:

• Arsitektur berbasis agen yang mendukung operasi asinkron
• Traffic yang konsisten dengan jitter lebih rendah
• Penggunaan CPU dan memori yang lebih rendah
• Kebijakan penjadwalan dan antrean yang dapat dikonfigurasi
• Integrasi yang lebih sederhana dan permukaan API yang lebih bersih

Jadwal Leader Menggunakan Akun Vote sebagai Kunci

Sebagai bagian dari siklus rilis Agave 2.3, Solana akan mengaktifkan SIMD-0180: Gunakan Alamat Akun Vote sebagai Kunci Jadwal Leader. Perubahan ini mengubah cara jaringan menentukan validator yang dijadwalkan untuk memproduksi blok, dari menggunakan alamat identitas validator menjadi menggunakan alamat akun vote sebagai kunci utama dalam jadwal leader.

Migrasi ini mengatasi ambiguitas yang telah lama ada dalam protokol Solana: ketidakmampuan untuk mengaitkan validator penghasil blok dengan stake tertentu secara andal. Dalam desain saat ini, jadwal leader menggunakan alamat identitas validator sebagai kunci. Namun, beberapa akun vote dapat mendelegasikan kepada identitas validator yang sama, sehingga sulit melacak produksi blok pada slot tertentu ke sekumpulan stake yang didelegasikan secara spesifik.

Dengan menggunakan alamat akun vote sebagai kunci jadwal leader, perubahan ini membentuk hubungan yang jelas dan langsung antara stake yang didelegasikan dan peran validator sebagai leader. Perubahan yang tampak kecil ini membuka beberapa kemampuan penting.

Pertama, perubahan ini menyediakan fondasi yang diperlukan untuk distribusi reward blok, sebagaimana ditetapkan dalam SIMD-0123, yang lolos pemungutan suara tata kelola resmi pada bulan Maret. Hal ini memungkinkan validator menetapkan tingkat komisi atas biaya blok dan membagikan sisa pendapatan secara proporsional kepada para delegator. Sistem ini mencerminkan model pembagian reward yang sudah digunakan untuk reward staking inflasioner, sehingga insentif ekonomi antara validator dan para staker mereka menjadi lebih selaras.

Kedua, penggunaan alamat akun vote sebagai kunci jadwal leader sangat penting untuk memungkinkan slashing terprogram, yang menjatuhkan penalti kepada validator yang melanggar aturan jaringan dengan mengirimkan blok duplikat atau memberikan vote pada beberapa fork. Hal ini membawa kita ke pembaruan berikutnya.

Verifikasi Peristiwa yang Dapat Dikenai Slashing

Slashing adalah mekanisme untuk menjatuhkan penalti kepada validator berbahaya dengan memverifikasi pelanggaran secara on-chain dan membakar sebagian stake yang didelegasikan kepada mereka. Mekanisme ini menjadi pencegah utama terhadap perilaku yang mengancam keamanan atau stabilitas jaringan.

Ada dua model slashing utama:

Social Slashing (Sistem Solana Saat Ini)

Saat ini, Solana mengandalkan pendekatan konsensus manual berbasis komunitas yang disebut social slashing. Dalam model ini, jika validator bertindak jahat, misalnya dengan membahayakan liveness atau keamanan jaringan, peserta yang jujur dapat berkoordinasi secara off-chain untuk memulai hard fork, menjalankan ulang jaringan, dan melakukan slashing terhadap stake pelanggar. Meskipun metode ini memungkinkan penilaian yang fleksibel untuk setiap kasus, koordinasi yang diperlukan sangat besar dan sifatnya reaktif.

Slashing Terprogram (Slashing Dalam Protokol)

Sebaliknya, slashing terprogram sepenuhnya diterapkan secara on-chain. Jika validator melanggar aturan protokol, bukti kriptografis atas pelanggaran tersebut dapat dikirimkan ke program khusus, yang kemudian secara otomatis memicu slashing. Model ini mengurangi ketergantungan pada koordinasi manusia dan memungkinkan penindakan atas pelanggaran ringan tanpa mengganggu operasi jaringan, sehingga membuka jalan bagi akuntabilitas terdesentralisasi yang dapat diskalakan.

Slashing mencakup dua langkah utama:

• Deteksi dan atribusi kesalahan: mengidentifikasi pelanggaran dan validator yang bertanggung jawab.
• Penerapan penalti: menghukum pelanggar secara ekonomi dengan melakukan slashing terhadap stake mereka dan meminta pertanggungjawaban mereka.

Sebagai bagian dari siklus rilis Agave 2.3, Solana akan mengaktifkan feature gate untuk Slashing Program sebagaimana dijelaskan dalam SIMD: SIMD-0204: Verifikasi Peristiwa yang Dapat Dikenai Slashing. Ini menandai langkah pertama menuju penerapan slashing terprogram di Solana, dengan fokus pada deteksi dan atribusi kesalahan. Pembaruan ini memperkenalkan program on-chain yang memungkinkan siapa pun melaporkan dan mencatat perilaku yang dapat dikenai slashing, sekaligus menjadi fondasi untuk penindakan otomatis pada masa mendatang.

Program ini tidak mengubah stake atau reward; program ini hanya memverifikasi dan mencatat pelanggaran, sehingga berfungsi sebagai catatan on-chain atas pelanggaran validator. Prototipe awal program telah di-deploy di Testnet (misalnya, contoh transaksi DuplicateBlockProof). 

Pada tahap awal, program akan berfokus pada pendeteksian dan pencatatan produksi blok duplikat, dengan rencana dukungan untuk pelanggaran lain seperti double voting pada masa mendatang. Yang terpenting, slashing terprogram terbatas pada pelanggaran yang dapat dibuktikan dengan jelas. Karena itu, penindakan terhadap masalah yang lebih subjektif atau sistemis, seperti produksi blok yang sengaja diperlambat atau ekstraksi MEV, jauh lebih menantang dan kemungkinan besar tidak akan ditangani oleh slashing program.

Bukti yang dikirimkan mencakup dua shred yang saling bertentangan untuk slot yang sama, dan keduanya ditandatangani oleh validator yang sama. Slashing program memverifikasi bukti tersebut dengan memastikan bahwa kedua shred membentuk bukti blok duplikat yang valid, mengonfirmasi bahwa keduanya berasal dari slot yang sama dan ditandatangani dengan benar oleh validator pelanggar. Logika ini mencerminkan pendekatan yang digunakan dalam protokol gossip Solana untuk menangani bukti blok duplikat dalam proses pemilihan fork. 

Setelah bukti berhasil diverifikasi, hasilnya disimpan dalam Program-derived Address (PDA) untuk referensi pada masa mendatang. Hal ini memudahkan pembuatan dashboard yang menampilkan data terkait slashing hanya dengan menjalankan getProgramAccounts pada slashing program. Validator dapat menggunakannya untuk memeriksa apakah mereka telah dilaporkan atas pelanggaran dan mengambil tindakan korektif sesuai kebutuhan.

SIMD mendatang akan membahas penerapan ekonomi slashing, termasuk parameter seperti penalti stake untuk berbagai pelanggaran. Karena keputusan ini memengaruhi aspek ekonomi dalam menjalankan validator Solana, setiap perubahan yang diusulkan harus disetujui melalui pemungutan suara tata kelola penuh.

Transisi Epoch yang Lebih Cepat

Agave 2.3 menghadirkan peningkatan besar pada kecepatan transisi epoch. Perhitungan reward epoch kini selesai dalam waktu kurang dari 500 milidetik. Hasilnya adalah lebih sedikit slot yang dilewati dan pendaratan transaksi yang lebih andal di sekitar batas epoch.

Selain itu, jika slot leader pertama pada epoch baru dilewati, Agave 2.3 memastikan perhitungan reward tidak dijalankan ulang. Sebagai gantinya, hasil yang telah dihitung sebelumnya digunakan kembali, sehingga menghilangkan komputasi berulang dan memungkinkan awal epoch baru yang lebih lancar.

Pengoptimalan AccountsDB

Efisiensi penyimpanan mengalami peningkatan signifikan dalam rilis ini. Penggunaan I/O disk turun sekitar 75%, dan volume permintaan perbaikan berkurang sekitar 85%. Secara keseluruhan, pengoptimalan ini menghasilkan performa node yang lebih konsisten dan andal, terutama selama periode beban jaringan tinggi.

Greedy Scheduler Diaktifkan secara Default

Di Agave 2.3, greedy scheduler kini diaktifkan secara default. Scheduler pusat sebelumnya sering menjadi bottleneck saat beban jaringan tinggi karena waktu yang dibutuhkan untuk mengurutkan transaksi dan membuat graf dependensi. Pendekatan greedy yang lebih baru mempercepat penjadwalan transaksi secara signifikan melalui logika yang lebih sederhana dan ukuran batch yang lebih kecil.

Pembaca dapat mempelajari greedy scheduler lebih lanjut dalam postingan blog Helius kami sebelumnya.

Versi Shred Gossip

Agave 2.3 memberlakukan pencocokan versi shred yang lebih ketat dalam jaringan gossip. Kini, node hanya diizinkan membuat koneksi gossip masuk jika versi shred mereka cocok dengan versi cluster, sehingga node yang salah konfigurasi dapat ditolak lebih awal.

Sebelumnya, node spy dapat bergabung ke jaringan tanpa mencocokkan versi shred cluster. Dengan perubahan ini, semua node, termasuk yang berada dalam mode spy, harus memperoleh versi shred yang benar, baik dari entrypoint cluster maupun dengan menetapkannya secara eksplisit melalui command line.

Pembaruan ini melanjutkan upaya terbaru untuk mengurangi overhead gossip. Dalam beberapa bulan terakhir, traffic gossip masuk turun sekitar 61%, berkat penghentian tiga jenis pesan gossip dan penghapusan pengiklanan slot epoch dari validator tanpa stake.

Simulasi RPC Menyertakan Penggunaan Sumber Daya

Untuk meningkatkan visibilitas penggunaan sumber daya transaksi, field baru telah ditambahkan ke metode RPC `simulateTransaction` default: `loadedAccountsDataSize`. Field ini melaporkan jumlah total byte data akun yang dimuat selama simulasi.

Penambahan ini memungkinkan developer memperkirakan biaya transaksi dan menyempurnakan priority fee dengan lebih akurat. Memuat data akun menggunakan compute unit (CU) dengan rasio 8 CU per 32 KB, yang didasarkan pada ukuran alokasi halaman heap Solana. Dengan menampilkan metrik ini, developer dapat mengoptimalkan efisiensi biaya dengan lebih baik saat membuat dan mengirim transaksi.

Penyempurnaan Snapshot

Snapshot berfungsi sebagai titik penyimpanan berkala yang memungkinkan node memulihkan state. Node terus menghasilkan snapshot ini dan mengganti versi lama dengan versi yang lebih baru seiring waktu.

Rilis ini menghadirkan beberapa peningkatan praktis pada perilaku snapshot:

• Interval Default Diperbarui: Interval full snapshot default ditingkatkan dari 25.000 menjadi 50.000 slot, sehingga mengurangi frekuensi pembuatan snapshot.
• Flag Baru untuk Menonaktifkan Snapshot: Flag `--no-snapshots` baru diperkenalkan untuk menonaktifkan pembuatan snapshot secara eksplisit. Metode sebelumnya yang menggunakan `--snapshot-interval-slots 0` kini tidak digunakan lagi.
• Perilaku Geyser yang Lebih Baik: Saat memulihkan dari snapshot, notifikasi akun yang dikirim melalui Geyser tidak lagi dideduplikasi.

Manfaat tambahan dari perpanjangan interval snapshot adalah performa disk yang lebih stabil dan pengurangan lonjakan IOPS (operasi input/output per detik).

Peningkatan Toolchain SBPF

Agave 2.3 menghadirkan beberapa peningkatan praktis bagi developer yang menggunakan toolchain SBPF:

• Penargetan Versi: Developer kini dapat secara eksplisit menargetkan versi BPF VM tertentu (v0–v3) saat mengompilasi program, sehingga memberikan kontrol yang lebih besar.
• Hanya Rust untuk SBPFv3: Mulai SBPFv3, hanya toolchain berbasis Rust yang didukung. Toolchain C lama tidak lagi kompatibel dengan versi mendatang.
• Flag Pengoptimalan Baru: Flag build `--optimize-size` baru telah ditambahkan untuk menghasilkan binary program yang lebih kecil saat deployment. Ini dapat membantu mengurangi penyimpanan, meskipun mungkin sedikit meningkatkan penggunaan compute unit (CU).

Perubahan Lainnya

Pembaruan tambahan yang disertakan dalam rilis ini:

• Pemulihan Cluster Otomatis: Fitur pemulihan cluster baru, `wen-restart`, diperkenalkan untuk secara otomatis memicu restart cluster jika terjadi crash pada chain.
• ABI Logging yang Diperbarui: ABI logging `TimedTracedEvent` telah diperbarui dengan beberapa diagnostik baru. Karena itu, validator harus memperbarui alat tracing atau analitik eksternal yang bergantung pada log tersebut untuk memastikan kompatibilitas. Data trace yang ada harus dihapus setelah upgrade untuk menghindari ketidakcocokan format.
• Peningkatan CLI: Menambahkan withdraw-stake AVAILABLE untuk menyederhanakan penarikan semua lamport yang tidak di-stake, serta memperbarui solana-test-validator agar secara default mengikat layanan RPC ke localhost (127.0.0.1) demi meningkatkan keamanan.
• Startup Lebih Cepat: Waktu startup validator telah berkurang secara signifikan. Kini, node membutuhkan sekitar 3 menit untuk dimulai dan memuat ledger, serta sekitar 5 menit untuk menyusul ujung chain. Namun, fastboot kini memerlukan shutdown yang tertib menggunakan flag --wait-for-exit baru. Operator harus membiarkan proses validator berhenti sepenuhnya dengan sendirinya sebelum memulai ulang, alih-alih langsung menjalankan perintah restart.

Kesimpulan

Agave 2.3 menandai pencapaian penting lainnya bagi protokol Solana. Sorotan utamanya mencakup peluncuran klien TPU baru (`tpu-client-next`), pengurangan I/O disk secara signifikan melalui pengoptimalan AccountsDB, peningkatan performa snapshot, perbaikan jaringan gossip, serta transisi epoch dan waktu startup yang lebih cepat. Secara keseluruhan, pembaruan ini membuat jaringan lebih tangguh sekaligus meningkatkan pengalaman developer dan operator validator.

Solana terus membuat kemajuan stabil menuju jaringan multi-klien yang tangguh, dengan lebih dari 8% total stake menjalankan Firedancer dan terus bertambah. Hampir satu setengah tahun uptime tanpa gangguan mencerminkan kematangan dan stabilitas software inti jaringan yang terus meningkat. Sementara itu, laju rilis mayor dan minor terus meningkat.

Berikutnya: Agave 3.0!

Referensi Lebih Lanjut

• Jadwal Rilis Agave 2.3
• Log Perubahan Agave 2.3
• Pull Request Agave 2.3
• Catatan Patch Agave 2.3 - Blog Anza 
• Presentasi tpu-client-next - Solana Core Community Call, 20 Juni 2025