Pembaruan Agave 4.0: Semua yang Perlu Anda Ketahui

Pengantar

Dengan Agave 4.0, klien validator inti Solana kembali melangkah maju dengan meningkatkan jalur performa inti sekaligus mempersiapkan jaringan untuk blok yang lebih besar dan pembaruan konsensus Alpenglow yang sangat dinantikan.

Pembaruan Penting dalam Siklus Rilis Agave 4.0

• XDP mempercepat retransmisi Turbine secara drastis
• Replay Stage dengan latensi lebih rendah
• Kesiapan Alpenglow: penanda serah terima leader yang cepat dan validasi ID blok berantai*
• Dukungan kriptografi yang diperluas: aritmetika G2 dan syscall BLS12-381*
• Serialisasi yang lebih baik dengan Wincode
• Peningkatan delegasi stake minimum dengan Stake Program v5*
• Pengaktifan kembali program pembuktian ZK ElGamal*
• Dukungan program SBPFv3*

* peningkatan yang dikendalikan feature gate

Baik Anda operator validator maupun developer, panduan ini menyajikan pembaruan dan wawasan yang diperlukan untuk memaksimalkan peningkatan terbaru. Setiap bagian artikel ini berdiri sendiri sehingga pembaca dapat berfokus pada topik yang paling relevan bagi mereka. 

Saat artikel ini ditulis, Agave v4.0.0-rc.0 dianggap sebagai kandidat peningkatan mainnet (MUC), dan Anza mencari sukarelawan untuk membantu meningkatkan penggunaan rilis ini hingga mencakup 25% stake. Para validator, saatnya melakukan upgrade!

XDP Siap Diadopsi Lebih Luas

XDP (singkatan dari eXpress Data Path) adalah jalur jaringan berperforma tinggi yang digunakan Agave untuk mempercepat Turbine. XDP memungkinkan Agave memuat program eBPF di dekat kartu antarmuka jaringan sehingga lalu lintas shred dapat melewati sebagian besar jalur pemrosesan paket Linux standar.

Hal ini penting karena Turbine menjadi hambatan utama saat Solana bergerak menuju batas blok yang lebih tinggi. Leader harus menyebarkan shred ke ratusan peer, dan validator besar dalam kondisi saat ini sudah dapat mendekati 150.000 paket keluar per detik. Seiring jaringan bergerak menuju target jangka panjang berupa blok 100 juta CU, performa pengiriman dan retransmisi paket harus dapat ditingkatkan seiring throughput eksekusi. XDP menyediakan ruang tersebut dengan mempercepat propagasi blok secara luar biasa.

Dengan Agave 4.0, XDP kini siap diadopsi lebih luas oleh validator. XDP telah menjalani stress test dalam berbagai konfigurasi, diperkuat lebih lanjut, dan mendapatkan peningkatan perutean tambahan. Hasil di lingkungan produksi sangat menggembirakan, dengan retransmisi Turbine yang beberapa orde magnitudo lebih cepat.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

22 Apr 2026, 5.25 AM

Untuk konteks lebih lanjut mengenai alasan XDP menjadi peningkatan yang begitu signifikan, lihat wawancara kami sebelumnya dengan engineer Anza, Alessandro Decina.

Replay Stage yang Lebih Cepat

Agave 4.0 mempercepat replay dengan memindahkan dua langkah verifikasi yang mahal dari jalur kritis thread replay. Dalam v4.0, verifikasi entri dan verifikasi tanda tangan transaksi sama-sama dikirim secara asinkron sehingga replay dapat terus diproses sementara tugas latar belakang mengonfirmasi bahwa slot tersebut valid.

Perubahan pertama memindahkan verifikasi entri PoH ke latar belakang. Sebelumnya, replay memverifikasi rantai hash entri secara inline sebelum melanjutkan. Perubahan kedua menerapkan pendekatan yang sama pada tanda tangan transaksi, tetapi dengan pemisahan penting: Agave kini memisahkan verifikasi hash/pesan transaksi dari verifikasi tanda tangan Ed25519. Jalur hash tetap dijalankan terlebih dahulu agar transaksi dapat disanitasi dan dieksekusi dengan aman, sementara pemeriksaan tanda tangan yang lebih mahal berjalan di latar belakang dan digabungkan sebelum blok diterima.

Dampak praktisnya adalah replay stage yang jauh lebih jarang terblokir, terutama selama slot sibuk ketika pemeriksaan tanda tangan meningkat seiring jumlah transaksi.

Adopsi Wincode Lebih Lanjut

Wincode adalah pustaka serialisasi dan deserialisasi yang dikembangkan oleh Anza, dirancang untuk inisialisasi langsung di lokasi dan penulisan langsung ke memori guna meminimalkan buffering perantara. Wincode menghadirkan performa kelas atas di antara serializer Rust sekaligus tetap sepenuhnya kompatibel dengan bincode yang lebih populer.

Di Agave 4.0, lebih banyak jalur serialisasi yang sangat memengaruhi performa beralih dari bincode ke wincode. Karena hampir semua data yang ditulis ke disk atau dikirim melalui jaringan di Solana bergantung pada bincode, pengoptimalan jalur ini memberikan dampak luas.

Peningkatan Delegasi Stake Minimum (Stake Program v5)

Pembaruan signifikan untuk Stake Program akan hadir bersama Agave 4.0. Perubahan yang dikendalikan feature gate ini, sebagaimana dijelaskan dalam SIMD-0490, merupakan persiapan untuk upaya Solana yang lebih luas dalam mengurangi obligasi stake (atau rent).

Perubahan yang paling penting adalah delegasi stake minimum naik dari 1 lamport menjadi 1 SOL. Ini mencegah biaya pembuatan dan pemeliharaan akun stake menjadi terlalu rendah saat persyaratan rent menurun, yang dapat menghadirkan potensi vektor serangan. Meski terdapat banyak akun stake kecil di bawah ambang ini, semuanya hanya mencakup 0,02% dari total stake aktif dan akan dikecualikan dari aturan baru setelah pembaruan diluncurkan.

Peningkatan ini juga merapikan beberapa bagian dalam penanganan akun stake. Perubahan ini mengalihkan penghitungan rent agar menggunakan Rent sysvar, bukan mengandalkan rent_exempt_reserve yang tersimpan di setiap akun, menjadikan input akun sysvar opsional untuk operasi stake program, dan menulis ulang implementasi Split untuk memperbaiki kasus khusus yang telah lama ada. 

Komunitas operator validator menyatakan tidak keberatan dengan batas minimum baru sebesar 1 SOL. Tooling dan dapp yang berinteraksi dengan stake program perlu memeriksa logikanya agar memperhitungkan batas minimum baru tersebut.

Dukungan Kriptografi yang Lebih Baik 

Sejumlah aktivasi fitur sepanjang siklus rilis Agave 4.0 bertujuan memperluas kemampuan kriptografi native Solana sehingga mendukung kasus penggunaan modern dengan lebih baik, termasuk pembuktian ZK dan tanda tangan BLS.

Mengaktifkan Kembali ZK ElGamal Proof Program

ZK ElGamal Proof program adalah program native Solana yang memverifikasi pembuktian zero-knowledge yang digunakan dalam transfer rahasia Token-2022. Program ini memungkinkan validasi saldo dan transaksi terenkripsi tanpa mengungkapkan data dasarnya. Program tersebut berfungsi sebagai verifier serbaguna untuk pembuktian kriptografi berbasis ElGamal dan menjadi komponen utama dalam fungsionalitas token Solana yang menjaga privasi. 

Program ini dinonaktifkan di mainnet setelah insiden keamanan pada Juni 2025. Dalam insiden tersebut, kelemahan pada logika verifikasi pembuktian, khususnya elemen yang hilang dalam hashing transkrip Fiat-Shamir, memungkinkan pembuatan pembuktian palsu yang dapat lolos verifikasi. Meski tidak ada eksploitasi yang ditemukan terjadi, potensi dampaknya membuat program dinonaktifkan melalui feature gate dan transfer rahasia dijeda selagi perbaikan dan audit diselesaikan. Setelah masalah tersebut diatasi dan implementasinya diperkuat, program ini kini dijadwalkan untuk diaktifkan kembali di mainnet.

Aritmetika G2 untuk alt_bn128

SIMD-0302: Menambahkan Syscall G2 alt_bn128 memperluas syscall kriptografi BN254 (alt_bn128) Solana yang sudah ada agar mendukung operasi native pada titik kurva G2, termasuk penjumlahan, pengurangan, dan perkalian skalar. G1 dan G2 adalah dua grup kurva eliptik yang digunakan dalam kriptografi berbasis pairing, dengan G2 didefinisikan pada extension field yang lebih besar.

Hal ini mengisi kesenjangan utama dalam kumpulan syscall saat ini, yang terutama berfokus pada operasi G1, serta menghadirkan dukungan yang lebih lengkap untuk kriptografi berbasis pairing secara langsung secara on-chain, khususnya untuk kasus penggunaan seperti verifikasi tanda tangan BLS dan sistem pembuktian ZK tingkat lanjut.

Tanpa dukungan native G2, beberapa proyek mengandalkan implementasi khusus seperti solana-alt-bn128-bls, sebuah pustaka tanda tangan BLS menyeluruh yang dibuat oleh Dean Little dari Blueshift di atas syscall yang sudah ada. Mengaktifkan operasi G2 pada level syscall akan meniadakan kebutuhan atas solusi sementara ini, sehingga protokol kriptografi kelas produksi dapat dibuat secara native di Solana dengan lebih mudah.

Dukungan Little-Endian untuk alt_bn128

SIMD-0284: Menambahkan Kompatibilitas Little-Endian untuk alt_bn128 memperluas syscall kriptografi alt_bn128 Solana yang sudah ada agar mendukung format input dan output little-endian. Sebelumnya, syscall ini hanya menerima encoding big-endian sehingga menyulitkan developer yang menggunakan tooling dan pustaka, khususnya dari ekosistem Ethereum, karena sebagian besar tim ZK di Solana menggunakan ark-bn254 yang beroperasi dalam little-endian. Perubahan ini kompatibel dengan versi sebelumnya dan memperluas dukungan untuk kasus penggunaan yang sudah ada terkait operasi kurva eliptik pada alt_bn128.

Syscall BLS12-381

Terakhir, SIMD-0388: Syscall BLS12-381 menghadirkan dukungan native untuk operasi kriptografi pada kurva eliptik BLS12-381, sehingga program Solana dapat menggunakan kurva modern ramah pairing dengan keamanan 128-bit. Hingga saat ini, Solana mengandalkan BN254 (alt_bn128) untuk kriptografi berbasis pairing, yang tidak memenuhi standar keamanan ini dan membatasi kompatibilitas dengan ekosistem lain yang telah diadopsi secara luas seperti Ethereum.

Alih-alih menghadirkan antarmuka syscall yang sepenuhnya baru, peningkatan ini memperluas syscall kurva yang sudah ada dengan identifier baru untuk operasi G1 dan G2 BLS12-381. Dengan demikian, developer dapat melakukan aritmetika grup, validasi titik, dekompresi, dan pemeriksaan batch pairing menggunakan antarmuka yang sudah dikenal, sekaligus memperluas kemampuan kriptografi secara signifikan.

Selain peningkatan umum untuk pembuktian zero-knowledge dan verifikasi tanda tangan BLS, pekerjaan ini juga menjadi pendukung utama konsensus Alpenglow. Secara khusus, hal ini memungkinkan validator memverifikasi BLS Proofs of Possession secara on-chain, sehingga mencegah serangan rogue-key. Ini membawa kita ke bagian berikutnya.

Kesiapan Alpenglow

Syscall BLS12-381 hanyalah salah satu dari beberapa aktivasi feature gate sepanjang siklus rilis Agave 4.0 yang menjadi landasan bagi peningkatan konsensus Alpenglow. Berikut adalah aktivasi tambahan yang mendukung peluncuran tersebut, yang saat ini dijadwalkan hadir di mainnet pada Q3 2026 bersama Agave 4.1.

Validasi ID Blok Berantai

SIMD-0340: Memvalidasi ID Blok Berantai menentukan cara validator harus memverifikasi hubungan asal-usul blok untuk memastikan rantai kanonis yang konsisten di bawah konsensus TowerBFT maupun Alpenglow. Karena nomor slot saja tidak mengidentifikasi blok secara unik, terutama dalam kasus ekuivokasi ketika beberapa blok dapat diproduksi untuk slot yang sama, klien tidak dapat mengandalkan urutan slot untuk menentukan hubungan induk-anak yang benar.

Perubahan ini menghadirkan aturan validasi rantai yang eksplisit untuk memastikan setiap blok mereferensikan induknya dengan benar, mencegah divergensi, dan membantu jaringan mencapai satu riwayat tunggal. Di bawah TowerBFT, hal ini diterapkan dengan mewajibkan kumpulan FEC mereferensikan root Merkle induknya, baik di dalam maupun lintas slot. Alpenglow menggunakan konstruksi root Merkle ganda atas semua kumpulan FEC dalam satu slot. Jika pemeriksaan ini gagal, blok atau slot tersebut ditandai mati. Penerapan aturan ini memperkuat keamanan konsensus dan memastikan validator dapat pulih setelah menerima blok yang salah atau saling bertentangan.

Penanda Serah Terima Leader yang Cepat

SIMD-0337: Penanda untuk Serah Terima Leader Cepat Alpenglow menentukan aturan pemberian sinyal eksplisit yang memungkinkan validator menentukan kapan slot induk telah sepenuhnya selesai dan aman untuk dijadikan dasar pembangunan, yang merupakan prasyarat bagi transisi leader yang cepat. Perubahan ini menghadirkan persyaratan penempatan yang lebih ketat untuk DATA_COMPLETE_SHRED dan penanda baru “induk siap”, sehingga kelengkapan blok dapat dideteksi tanpa ambiguitas dari stream shred itu sendiri.

Saat ini, ambiguitas mengenai apakah suatu slot telah dikirim sepenuhnya dapat memperlambat leader berikutnya karena mereka mungkin harus menunggu shred tambahan atau mengambil risiko membangun di atas data yang belum lengkap. Dengan menstandardisasi cara penyelesaian diberi sinyal, perubahan ini memungkinkan leader berikutnya mulai memproduksi blok lebih awal dengan yakin, tanpa koordinasi tambahan atau perkiraan.

Ini merupakan elemen dasar utama dalam desain serah terima leader cepat Alpenglow, yang meningkatkan throughput jaringan secara langsung dengan meminimalkan jeda antarleader.

Pembaruan Model Biaya Transaksi Vote

SIMD-0458: Berhenti Menggunakan Biaya Transaksi SimpleVote Statis menghapus penggunaan biaya CU tetap untuk transaksi vote sehingga menyelaraskannya dengan model biaya transaksi standar yang digunakan untuk transaksi non-vote. 

Saat ini, transaksi vote sederhana dikenai biaya tetap sebesar 3.428 CU berdasarkan asumsi lama mengenai biaya eksekusi deterministik. Dalam model baru, transaksi vote akan diukur secara dinamis seperti transaksi lainnya, sehingga penghitungan biaya menjadi lebih konsisten dan batas CU Vote terpisah tidak lagi diperlukan.

Meski konsumsi CU runtime aktual untuk transaksi vote tetap sama, cara penghitungannya selama pengemasan blok akan berubah. Secara khusus, vote kini akan mencakup tambahan perkiraan sebesar ~16 ribu CU, seperti biaya pemuatan data akun, sehingga reservasi CU awal menjadi lebih tinggi saat leader membuat blok.

Perubahan ini mengikuti SIMD-0387 (pengelolaan pubkey BLS dalam akun vote), yang menghapus asumsi bahwa Vote program memiliki profil eksekusi statis.

Peningkatan Penting Lainnya

Sorotan tambahan dari siklus rilis Agave 4.0 mencakup dukungan untuk program SBPFv3, kemampuan membuat akun yang telah didanai, dan I/O langsung untuk mengekstrak snapshot.

Dukungan Program SBPFv3

Siklus rilis Agave 4.0 mencakup feature gate yang memungkinkan deployment dan eksekusi program SBPFv3. Solana Berkeley Packet Filter (SBPF) adalah fork eBPF berbasis Rust milik Solana: format bytecode tingkat rendah dan mesin virtual yang menjadi target kompilasi program on-chain sebelum dieksekusi. Pembaruan ini menggabungkan pekerjaan yang dijelaskan dalam tiga SIMD: SIMD-0178, SIMD-0189, dan SIMD-0377. 

SIMD-0178 menghadirkan syscall statis sehingga referensi syscall dapat di-resolve saat linking, bukan melalui relokasi ELF pada runtime. Saat ini, relokasi tersebut menambah kompleksitas pada program loader; menghapusnya akan menyederhanakan eksekusi dan mengurangi risiko keamanan.

SIMD-0189 kemudian memperketat tata letak ELF yang diizinkan untuk program, dengan mewajibkan struktur file yang lebih ketat agar validator menghadapi lebih sedikit kasus khusus untuk di-parse dan lebih sedikit data tak terduga untuk ditangani. Hal ini seharusnya transparan bagi developer karena toolchain linker diharapkan menghasilkan binary yang sesuai secara otomatis.

Terakhir, SIMD-0377 memperbarui mesin virtual SBPF agar lebih selaras dengan set instruksi eBPF modern yang dihasilkan LLVM, termasuk dukungan untuk instruksi tambahan seperti operasi jump 32-bit. Tujuannya adalah membuat VM Solana lebih kompatibel dengan tooling upstream sekaligus memungkinkan program dikompilasi menjadi bytecode yang lebih efisien. Bagi developer, hasil praktisnya adalah pemuatan program yang lebih cepat, permukaan serangan yang lebih kecil, dan potensi penggunaan komputasi yang lebih rendah tanpa mengubah logika aplikasi.

Pembuatan Akun yang Telah Didanai

SIMD-0312: CreateAccountAllowPrefund dijadwalkan aktif di mainnet selama siklus rilis Agave 4.0. Perubahan ini menghadirkan instruksi baru dalam system program yang menghapus persyaratan bahwa akun yang baru dibuat harus memiliki saldo awal nol lamport. Dengan demikian, akun dapat didanai sebelum dibuat, yang menyederhanakan alur kerja umum developer dan mengurangi instruksi yang tidak diperlukan.

Sebelumnya, instruksi CreateAccount akan gagal jika akun tujuan sudah memiliki lamport. Akibatnya, developer harus membagi inisialisasi akun menjadi beberapa langkah, biasanya transfer yang diikuti allocate dan assign. Hal ini meningkatkan kompleksitas dan menambah biaya komputasi. Pola ini sangat umum dalam program yang mendanai akun terlebih dahulu.

Instruksi baru ini menyatukan langkah-langkah tersebut ke dalam satu panggilan dengan memungkinkan akun yang telah didanai untuk langsung diinisialisasi. Dalam praktiknya, hal ini mengurangi overhead CPI dan dapat menghemat ribuan unit komputasi dalam alur umum, sehingga ke depannya developer mendapatkan jalur yang lebih sederhana dan berperforma lebih tinggi. Karena dihadirkan sebagai instruksi baru, bukan perubahan pada instruksi yang sudah ada, fitur ini tetap sepenuhnya kompatibel dengan versi sebelumnya.

I/O Langsung untuk Mengekstrak Snapshot 

Agave 4.0 mengubah proses ekstraksi snapshot agar secara default menggunakan I/O langsung, alih-alih mengarahkan penulisan snapshot melalui page cache sistem operasi. Perubahan ini mempercepat waktu startup dan meningkatkan performa pemulihan snapshot. Fitur ini sangat berguna karena data snapshot biasanya dialirkan ke disk dan tidak perlu menggantikan data validator yang lebih sering diakses dari memori. Operator dapat menonaktifkannya dengan --no-accounts-db-snapshots-direct-io jika filesystem mereka tidak mendukung O_DIRECT. I/O langsung diperkirakan akan diperluas ke pembuatan snapshot dalam rilis mendatang. 

Kesimpulan

Agave v4.0 adalah peningkatan klien yang substansial dengan berbagai peningkatan performa dan pengoptimalan runtime. Perubahan ini dirancang untuk membuat jaringan lebih cepat, lebih aman, dan lebih mudah digunakan sebagai platform pengembangan.

Ke depannya, tonggak berikutnya adalah Agave 4.1 dan pembaruan konsensus Apenglow.

Referensi Lebih Lanjut

• Jadwal Rilis Agave 4.0
• Jadwal Pelacak Feature Gate
• Log Perubahan Agave 4.0
• Pull Request Agave 4.0