Pembaruan Agave v2.1: Semua yang Perlu Anda Ketahui

Pembaruan Penting dalam Siklus Rilis Agave 2.1 

• Pengoptimalan performa secara ekstensif
• Peningkatan batas blok
• Pengenalan greedy scheduler (eksperimental)
• Dukungan native untuk verifikasi tanda tangan Secp256r1 (Pembaruan: ditunda hingga Agave 2.2)
• Penonaktifan pemungutan biaya sewa dan penulisan ulang sewa
• Pelonggaran batasan untuk kegagalan pemuatan transaksi
• Migrasi program config dan address look-up table ke core BPF

Setiap bagian dalam artikel ini dirancang agar dapat dibaca secara mandiri sehingga pembaca dapat menjelajah dengan bebas dan berfokus pada topik yang paling menarik bagi mereka. Baik Anda operator validator, developer, maupun pengguna aktif, ulasan mendalam mengenai Agave 2.1 ini akan memberikan wawasan yang Anda perlukan untuk memanfaatkan berbagai kemajuan tersebut secara efektif.

Peluncuran Fitur

Saat tulisan ini dibuat, 88% stake telah menjalankan Agave versi 2.1.11. Aktivasi feature gate di mainnet dihentikan sementara agar adopsi v2.1 dapat diperluas dan diperkirakan segera dilanjutkan sesuai urutan aktivasi yang dijadwalkan. 

Sebagian besar fitur lengkap baru yang dibahas di bagian berikutnya saat ini belum aktif dan diperkirakan akan diluncurkan sepanjang siklus rilis 2.1 menggunakan sistem feature gate. Fitur diaktifkan pada epoch tertentu berdasarkan prioritas relatif dan urutan aktivasinya di cluster testnet dan devnet.

Peningkatan Performa

Operator validator dan RPC telah melaporkan peningkatan nyata pada stabilitas dan performa Agave 2.1. Selama setahun terakhir, Anza memprioritaskan penghapusan bottleneck, pengoptimalan efisiensi sumber daya, dan peningkatan performa secara keseluruhan. Rilis klien baru tidak hanya memperkenalkan fitur baru, tetapi juga menyempurnakan fondasi utama—meningkatkan bandwidth, mengurangi latensi. Sebelum membahas detail pembaruan 2.1, ada baiknya kita melihat gambaran yang lebih luas dan mengukur peningkatan performa signifikan yang dicapai dalam rangkaian pembaruan klien terbaru.

Waktu Blok

Waktu blok yang lebih cepat di Solana mendorong rata-rata waktu slot ke bawah 400 md, dengan epoch terbaru berpotensi selesai dalam waktu kurang dari dua hari—yang tercepat dalam sejarah jaringan. Kedua klien siap untuk waktu blok yang lebih singkat. Percepatan ini berdampak lebih luas dari sekadar peningkatan throughput transaksi. Karena imbalan staking terkait dengan emisi inflasi yang dihitung menggunakan "tahun epoch", bukan tahun kalender, validator dan pelaku staking berpotensi memperoleh manfaat. Satu tahun epoch mengasumsikan 182,5 epoch per tahun berdasarkan durasi standar dua hari per epoch. Ketika epoch menjadi lebih singkat, lebih banyak epoch dapat berlangsung dalam jangka waktu yang sama sehingga secara efektif meningkatkan laju distribusi imbalan staking.

Uptime

Solana menunjukkan keandalan yang nyaris sempurna sepanjang 2024 dan awal 2025 dengan mempertahankan uptime 100% selama lebih dari satu tahun. Gangguan terakhir yang tercatat terjadi pada 6 Februari 2024, ketika bug yang telah diketahui untuk sementara mengganggu finalisasi blok di Mainnet. Masalah ini segera diidentifikasi dan diperbaiki. Sejak saat itu, Solana terus menghasilkan blok tanpa hambatan, bahkan selama periode aktivitas jaringan yang sangat tinggi—seperti lonjakan baru-baru ini yang dipicu oleh peluncuran token keluarga Trump—yang membuktikan ketangguhannya di bawah beban berat.

Tingkat Slot yang Terlewat

Tingkat slot yang terlewat mengukur seberapa sering validator yang ditunjuk sebagai leader untuk slot tertentu gagal menghasilkan blok dalam waktu yang dialokasikan. Sejak sekitar epoch 700 pada November 2024, tingkat slot yang terlewat telah menurun drastis. Setelah selama beberapa tahun berfluktuasi antara 2% hingga 5%, tingkat ini kini turun hingga mendekati nol bagi sebagian besar validator yang dioptimalkan dengan baik.  

Salah satu faktor yang berkontribusi terhadap peningkatan ini adalah diperkenalkannya imbalan epoch terpartisi di mainnet pada epoch 707. Dengan menyebarkan imbalan stake ke beberapa blok, perubahan ini mengurangi bottleneck performa akibat distribusi imbalan yang terkonsentrasi pada blok pertama setiap epoch baru sehingga operasi jaringan menjadi lebih lancar.

Selain itu, Timely Vote Credits (TVC), yang diperkenalkan pada November 2024, memberikan insentif kepada validator agar segera memberikan suara sekaligus mencegah pemberian suara yang terlambat. Dengan mengurangi jumlah validator yang sengaja menahan suara, TVC meningkatkan konvergensi cluster sehingga konfirmasi dan finalitas berlangsung lebih cepat. Mekanisme ini membantu meminimalkan fork dan memperpendek durasinya. Karena penilaian TVC kini memengaruhi peringkat stake pool, para operator merespons dengan meningkatkan hardware dan mengoptimalkan konfigurasi validator mereka demi performa yang lebih baik.

Transaksi per Detik (TPS)

Jumlah transaksi per detik (TPS) yang lebih tinggi menunjukkan peningkatan throughput chain, dan TPS non-vote Solana (alias ‘TPS Sebenarnya’) terus menunjukkan tren naik sejak akhir 2023. Data terbaru untuk minggu pertama Februari 2025 menunjukkan bahwa jaringan mencatat rata-rata persentil ke-50 sebesar 1.228 TPS, dengan performa puncak pada persentil ke-99 mencapai 2.520 TPS.  

TPS tertinggi sepanjang masa tercatat selama pekan airdrop token PENGU yang berakhir pada 23 Desember 2024, ketika rata-rata persentil ke-50 mencapai 1.260 TPS, sedangkan persentil ke-99 mencapai puncak 3.252 TPS. Pertumbuhan berkelanjutan ini menegaskan skalabilitas Solana yang terus berkembang serta peningkatan efisiensi pemrosesan transaksi.

Biaya Prioritas

Terakhir, perbandingan pemungutan biaya prioritas antara Agave 2.1 dan versi 2.0 sebelumnya dari 27 Januari hingga 4 Februari 2025 menunjukkan bahwa Agave 2.1 secara konsisten memungut biaya prioritas yang sedikit lebih tinggi.

Menaikkan Batas Blok

Peningkatan batas blok yang diusulkan dalam SIMD-0207: Naikkan Batas Blok menjadi 50M dijadwalkan untuk siklus rilis Solana 2.1. Saat ini, protokol membatasi total sumber daya komputasi per blok hingga 48 juta Compute Units (CU). Batas blok memastikan node dapat mengimbangi jaringan dengan membatasi jumlah pekerjaan yang dapat dimasukkan leader ke dalam satu blok. Tim pendiri memilih batas saat ini secara empiris berdasarkan jumlah yang secara wajar dapat diproses validator untuk mencapai waktu blok 400 milidetik. 

Namun, aktivitas mainnet saat ini tidak dibatasi oleh waktu eksekusi. Artinya, blok dapat menampung lebih banyak transaksi tanpa melampaui target 400 md. Pembaruan ini memperkenalkan peningkatan moderat sebesar 4% untuk memperluas kapasitas jaringan secara bertahap, dengan menaikkan batas komputasi per blok dari 48M menjadi 50M CU. Meski peningkatan yang lebih agresif—seperti menggandakan batas—mungkin dilakukan, langkah tersebut dinilai terlalu berisiko sebagai perubahan awal. Perluasan batas blok tidak hanya memengaruhi validator, tetapi juga infrastruktur penting seperti node RPC, pengindeks, dan layanan arsip, yang harus ditingkatkan skalanya sesuai kebutuhan.

Batas protokol lainnya tetap sama:

• Batas komputasi per akun per blok tetap sebesar 12M CU.
• Komputasi maksimum per transaksi tetap sebesar 1,4M CU.

Peningkatan lebih lanjut pada batas blok diperkirakan akan dilakukan melalui proses SIMD formal.

Greedy Scheduler

Latar Belakang: Central Scheduler

Pembaruan scheduler besar terakhir—central scheduler—diperkenalkan di Agave 1.18 pada Mei tahun lalu. Scheduler ini membuat graf dependensi dari N transaksi prioritas teratas, dengan N saat ini ditetapkan sebesar 256. Scheduler kemudian mencoba menjadwalkan transaksi berdasarkan urutan prioritas, untuk memastikan transaksi yang tidak berkonflik diproses terlebih dahulu. Setelah dijadwalkan, transaksi tersebut dihapus dari graf sehingga transaksi yang sebelumnya berkonflik dapat diprioritaskan. Scheduler kemudian mengisi ulang graf untuk mempertahankan antrean sebanyak N transaksi.

Pendekatan ini terutama dirancang untuk mengoptimalkan pemrosesan batch yang lebih besar dan meningkatkan throughput transaksi secara keseluruhan. Namun, salah satu kelemahan utamanya adalah pembuatan graf dependensi dan pengurutan transaksi membutuhkan waktu yang cukup lama sehingga menciptakan bottleneck. 

Lihat postingan blog Helius kami sebelumnya untuk ulasan yang lebih mendetail mengenai Agave 1.18 dan implementasi central scheduler.

Greedy Scheduler Baru

Tidak seperti central scheduler, greedy scheduler tidak membuat graf dependensi. Sebaliknya, scheduler ini menggunakan pendekatan yang lebih sederhana:

• Pertama, pilih transaksi dengan prioritas tertinggi.
• Jika transaksi tidak berkonflik dengan batch yang sedang berjalan, transaksi tersebut ditambahkan ke salah satu dari empat antrean thread worker.
• Jika terjadi konflik, batch saat ini difinalisasi dan dikirim, lalu transaksi ditambahkan ke batch baru.

Metode ini mempercepat penjadwalan transaksi secara signifikan, tetapi menghasilkan ukuran batch yang lebih kecil sehingga meningkatkan overhead per transaksi. Namun, dalam kondisi mainnet nyata, kompromi ini sepadan karena waktu eksekusi didominasi oleh pemrosesan BPF, bukan batching.

Central scheduler mengalami kesulitan saat beban jaringan tinggi, terutama karena membutuhkan waktu untuk mengurutkan transaksi dan membuat graf dependensi. Dengan menghapus overhead ini, greedy scheduler meningkatkan responsivitas dengan konsekuensi berkurangnya efisiensi batching.

Bayangkan skenario ketika transaksi terbagi dalam tiga kelompok konflik: A, B, dan C. Transaksi berkonflik ketika satu transaksi ingin menulis ke akun yang ingin dibaca atau ditulisi oleh transaksi lain. Transaksi dalam A memiliki biaya prioritas yang lebih tinggi daripada transaksi dalam B atau C.

• Central scheduler akan menjadwalkan transaksi A1, B1, dan C1 yang tidak berkonflik secara bersamaan dalam satu batch: [A1, B1, C1].
• Greedy scheduler memprioritaskan transaksi dengan biaya tertinggi terlebih dahulu, menjadwalkan A1 sebagai batch terpisah, lalu beralih ke A2 pada batch berikutnya.

Prioritas ini memastikan penjadwalan yang lebih cepat, tetapi dapat menghasilkan batch yang lebih kecil dibandingkan central scheduler.

Program Native untuk Memverifikasi Tanda Tangan Secp256r1

Solana memperkenalkan program native baru untuk memverifikasi tanda tangan kurva eliptik secp256r1, yang memungkinkan dukungan on-chain untuk Passkeys, standar WebAuthn, dan model abstraksi akun baru, termasuk autentikasi dua faktor (2FA). Peningkatan ini membuka jalan agar autentikasi tanpa kata sandi, yang sudah banyak digunakan di Web2, dapat berfungsi sebagai faktor kedua untuk keamanan on-chain.

Kurva eliptik secp256r1 adalah kurva kriptografi yang distandardisasi NIST dan didukung secara luas di berbagai perangkat modern, termasuk:

• WebAuthn: Standar W3C untuk autentikasi berbasis kriptografi kunci publik yang didukung oleh semua browser web utama.
• Secure Enclave milik Apple: Trusted Execution Environment (TEE) berbasis hardware yang menandatangani pesan dan hanya dapat diakses melalui autentikasi biometrik.
• Android Keystore: API untuk mengelola kunci privat dan metode penandatanganan dengan memanfaatkan TEE perangkat untuk penyimpanan kunci yang aman.
• Passkeys: Standar FIDO Alliance dan W3C yang menggantikan kata sandi dengan pasangan kunci kriptografis serta kompatibel dengan kriptografi kurva eliptik.

Beberapa jaringan lain, termasuk Ethereum (EIP-7212), juga telah menjajaki integrasi dukungan untuk kurva secp256r1.

Detail Program Secp256r1

Program baru ini akan diterapkan dengan ID: Secp256r1SigVerify1111111111111111111111111

Struktur Instruksi:

• Penghitung u8 menentukan jumlah tanda tangan yang akan diverifikasi.
• Diikuti satu byte padding.
• Untuk setiap tanda tangan, struct terserialisasi berikut digunakan:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Pembaruan ini berasal dari SIMD-0048: Program Native untuk Sigverify Secp256r1, yang diusulkan oleh tim Bunkr. Secp256r1 SigVerify Precompile Program akan berfungsi serupa dengan dukungan Solana yang sudah ada untuk secp256k1 dan tanda tangan ed25519.

Menonaktifkan Pemungutan Biaya Sewa dan Melewati Penulisan Ulang Sewa

Dua pembaruan terkait yang diusulkan dalam SIMD-0084: Menonaktifkan Pemungutan Biaya Sewa dan SIMD-0183: Melewati Penulisan Ulang Sewa akan menghilangkan sebagian besar overhead lama yang terkait dengan akun pembayar sewa.

Pemungutan biaya sewa merupakan komponen kompleks dalam Bank. Menonaktifkannya akan menyederhanakan codebase klien validator dan merampingkan pengembangan semua implementasi klien validator karena implementasi tersebut tidak perlu lagi mereplikasi logika pemungutan sewa. Sewa tidak akan lagi dipotong dari akun, dan biaya sewa yang terkumpul tidak akan lagi didistribusikan kepada validator. Saat ini akun pembayar sewa baru sudah tidak dapat dibuat—setiap upaya akan menghasilkan kesalahan transaksi.

Saat ini, pemungutan sewa memeriksa setiap akun setidaknya satu kali per epoch, dengan memuat dan menyimpan akun meskipun tidak berubah. Karena semua akun Solana sudah bebas sewa, mempertahankan proses ini merupakan pekerjaan komputasi yang tidak diperlukan.

Penulisan ulang akun terkait sewa akan dihapus sehingga mengurangi jumlah akun yang disimpan per slot. Hasilnya, validator akan mengalami peningkatan performa karena lebih sedikit akun yang disertakan dalam perhitungan accounts delta hash dan incremental account hash. Perubahan ini juga memperkecil ukuran incremental snapshot sehingga semakin mengurangi konsumsi sumber daya.

Melonggarkan Batasan Transaksi: Kegagalan Pemuatan

Saat ini, transaksi Solana tunduk pada batasan ketat yang dapat menyebabkannya gagal sebelum dimasukkan ke dalam blok. Kegagalan sebelum blok ini membuang komputasi validator karena sumber daya digunakan tanpa menghasilkan biaya transaksi—yang pada dasarnya berarti melakukan pekerjaan tanpa kompensasi.

Produksi blok menjadi semakin rumit karena perlu menyaring transaksi yang memanggil program tidak valid atau melampaui batas maksimum data akun termuat sebesar 64 MiB (~67,11 MB). Batasan ini meningkatkan kompleksitas perakitan blok dan mempersulit penentuan validitas blok. Dengan melonggarkan batasan ini, transaksi dapat dimasukkan ke dalam blok dan dikenai biaya tanpa mengharuskan data program dimuat dan diverifikasi terlebih dahulu. Perubahan ini bertujuan menghilangkan ketergantungan pada status akun untuk validasi blok.

Perubahan yang diusulkan dalam SIMD-0191 ini dapat memengaruhi alat seperti penjelajah blockchain yang mengasumsikan bahwa semua transaksi mencoba dieksekusi. Selain itu, pengguna harus memastikan transaksi mereka dapat dieksekusi untuk menghindari pengeluaran biaya yang tidak diperlukan.

Migrasi Program Config & Address Look-Up Table ke Core BPF

Sebagai bagian dari transisi berkelanjutan dari native enshrined programs ke program Berkeley Packet Filter (BPF), program Config dan Address Lookup Table akan dimigrasikan ke program Core BPF. Perubahan ini memisahkan program-program penting tersebut dari runtime validator sehingga memungkinkan pembaruan yang lebih fleksibel dan pemeliharaan yang lebih mudah.

Program BPF tidak sekompleks program native sehingga menyederhanakan pengembangan dan pemeliharaan di berbagai klien validator. Dengan perubahan ini, tim yang menangani Firedancer dan Anza tidak perlu lagi melacak dan mengimplementasikan perubahan program secara terpisah di runtime masing-masing. Sebagai gantinya, pembaruan akan diterapkan secara universal di seluruh klien. 

Program yang diimplementasikan ulang akan mempertahankan ABI yang identik dengan versi native-nya sehingga memastikan kompatibilitas penuh dan hanya berbeda dalam penggunaan komputasi.

Kesimpulan

Pembaruan Agave 2.1 menandai langkah maju yang penting bagi Solana dengan menghadirkan peningkatan fitur utama dan pengoptimalan runtime. Rilis ini memperkuat jaringan dengan memperluas fungsionalitas, menyempurnakan performa, dan mendorong batas kemampuan Solana. Dengan dukungan native untuk verifikasi tanda tangan Secp256r1, peningkatan batas blok, peningkatan performa yang ekstensif, dan pengenalan greedy scheduler di masa mendatang, Agave 2.1 meningkatkan efisiensi sekaligus skalabilitas. Baik Anda seorang developer, validator, maupun pengguna aktif, pembaruan ini membuka berbagai kemungkinan baru serta menjadikan Solana lebih cepat, lebih fleksibel, dan lebih andal dari sebelumnya.

Referensi Lebih Lanjut

• Repositori Klien Agave
• Jadwal Rilis Agave v2.1
• Pull Request Agave v2.1 yang Ditandai