Pembaruan Agave 4.3: Semua yang Perlu Anda Ketahui

Pendahuluan

Dengan Agave 4.3, Solana bersiap untuk menjalani peningkatan protokol yang bisa dibilang terbesar sepanjang sejarahnya. Siklus rilis 4.3 akan menghadirkan Alpenglow, mekanisme konsensus baru Solana yang sangat dinantikan, dan mencapai puncaknya pada "Alpenswitch": transisi mainnet terkoordinasi untuk meninggalkan TowerBFT.

Sejak diluncurkan, arsitektur konsensus Solana dibangun di atas Proof of History dan TowerBFT. Validator memberikan suara dengan mengirimkan transaksi yang diproses dan dimasukkan ke dalam blok bersama transaksi pengguna biasa. Finalitas kemudian terakumulasi seiring bertambahnya suara tersebut sepanjang 32 slot, sehingga Solana memiliki waktu finalitas sekitar 12,8 detik (dengan asumsi waktu slot 400 milidetik).

Proof of History (PoH) merupakan salah satu inovasi arsitektur utama Solana saat diluncurkan, dengan pendekatan uniknya untuk mengurutkan peristiwa dan mengoordinasikan waktu. Karena itu, penghentiannya menandai berakhirnya sebuah era sekaligus menunjukkan seberapa jauh protokol ini telah berkembang dari teknologi yang dahulu membuatnya berbeda.

Alpenglow menggantikan 'PoH + TowerBFT' dengan Votor, protokol yang memungkinkan validator bertukar suara di luar pipeline transaksi inti. Protokol ini mengagregasi suara tersebut menjadi sertifikat kriptografis. Desainnya menargetkan finalitas dalam ~150 milidetik.

Bagi pengguna dan aplikasi yang mengirimkan transaksi serta membaca status akun, hanya ada sedikit atau bahkan tidak ada hal yang perlu dimigrasikan. Transaksi dan mekanisme biaya tetap sama. Validator dan infrastruktur yang menggunakan blok, suara, stream, atau data commitment akan mengalami penyesuaian terbesar.

Transaksi suara menghilang dari blok, confirmed dan finalized secara efektif menyatu, dan infrastruktur streaming memperoleh informasi baru untuk membedakan bank yang bersaing dalam slot yang sama.

Dalam artikel ini, kita akan membahas cara kerja Alpenglow, termasuk perubahan yang dibawa Votor terhadap produksi blok dan finalitas. Kita juga akan membahas perubahan penting lain yang hadir sepanjang siklus rilis Agave 4.3.

Peluncuran Bertahap: Votor Terlebih Dahulu, Kemudian Rotor

Alpenglow dirancang berdasarkan dua komponen utama: Votor, yang menggantikan mekanisme pemungutan suara dan finalitas Solana, serta Rotor, yang merancang ulang cara blok disebarkan di seluruh jaringan. Kedua mekanisme ini akan diluncurkan secara bertahap, dimulai dengan Votor.

Agave 4.3 memperkenalkan Votor sambil mempertahankan protokol penyebaran blok yang ada, yaitu Turbine. Rotor secara eksplisit dikecualikan dari SIMD-0326, proposal yang mengatur aktivasi awal Alpenglow. Rotor memerlukan SIMD tersendiri sebelum dapat diterapkan. Peluncuran awal mengubah cara validator mencapai konsensus, tetapi belum mengubah cara data blok bergerak di seluruh jaringan.

Votor

Votor menggantikan transaksi suara dan sistem lockout TowerBFT dengan protokol langsung antarvalidator. Dalam TowerBFT, validator memberikan suara dengan mengirimkan transaksi yang dimasukkan ke dalam blok, lalu secara bertahap mengakumulasi kedalaman lockout yang cukup agar sebuah blok menjadi final. Dalam Votor, validator bertukar pesan suara bertanda tangan secara langsung, dan protokol mengagregasi tanda tangan tersebut menjadi sertifikat ringkas.

Alih-alih menunggu suara terakumulasi sepanjang 32 slot, Votor dapat memfinalisasi blok setelah satu atau dua putaran pemungutan suara. Protokol ini menargetkan finalitas ~150 milidetik, dibandingkan dengan ~12,8 detik pada TowerBFT.

Votor memiliki dua jalur menuju finalitas yang berjalan secara bersamaan.

Jika setidaknya 80% stake menotariskan sebuah blok pada putaran pertama, suara tersebut dapat diagregasi menjadi Fast-Finalization Certificate, dan blok tersebut langsung menjadi final. Ini adalah jalur cepat protokol dan hanya memerlukan satu putaran pemungutan suara.

Jika ambang 80% tidak tercapai, sebuah blok masih dapat dilanjutkan jika lebih dari 60% stake telah memberikan suara untuk menotariskannya. Ini menghasilkan Notarization Certificate yang memungkinkan putaran pemungutan suara kedua. Setelah lebih dari 60% stake memberikan suara finalisasi melalui jalur dua putaran, proses ini membentuk Finalization Certificate, sehingga blok menjadi final.

Dengan demikian, protokol lengkapnya memiliki lima jenis suara: Notarization, Notarization Fallback, Skip, Skip Fallback, dan Final. Berbagai kombinasi suara ini menghasilkan sertifikat notarisasi, fallback, skip, atau finalisasi. Sertifikat tersebut berfungsi sebagai bukti kriptografis ringkas bahwa stake yang memadai telah menyepakati hasil sebuah slot.

Votor dirancang agar tetap dapat membuat kemajuan hanya dengan 60% stake jujur yang responsif. Ini memungkinkan hingga 20% stake bertindak secara adversarial sementara 20% lainnya offline atau tidak responsif. Konsekuensi ini disengaja: Alpenglow melepaskan ambang Byzantine tradisional sebesar sepertiga pada desain BFT demi model ketahanan 20+20 yang lebih toleran terhadap validator yang berhenti berfungsi atau tidak tersedia.

Votor juga menghapus penggunaan Proof of History sebagai jam konsensus. Sebagai gantinya, validator menggunakan timer timeout lokal. Jika validator telah menunggu cukup lama tanpa menerima blok yang dapat diterima, validator dapat memberikan suara skip dan memungkinkan konsensus berlanjut. Hal ini menyederhanakan hubungan antara pencatatan waktu dan konsensus dibandingkan dengan TowerBFT.

Rotor

Rotor bukan bagian dari Agave 4.3, dan saat ini belum ada tanggal aktivasi yang dipublikasikan. Karena itu, Turbine akan terus membawa data blok saat Votor diaktifkan. Rotor, beserta mekanisme smart-sampling yang digunakan untuk memilih relay-nya, akan melalui proposal dan peluncuran terpisah di kemudian hari.

Yang penting, ini tidak berarti Solana harus menunggu Rotor untuk mencapai finalitas di bawah satu detik. Peluncuran Alpenglow saat ini menargetkan finalitas ~150 ms dengan Votor di Agave 4.3 sementara Turbine tetap digunakan. Rotor ditujukan untuk semakin meningkatkan penyebaran blok dan membuat arsitektur Alpenglow secara keseluruhan lebih efisien, tetapi Rotor bukan prasyarat bagi model finalitas baru Votor.

Tidak Ada Lagi Transaksi Suara

Salah satu konsekuensi Alpenglow yang paling terlihat adalah hilangnya transaksi suara dari blok Solana. Validator membayar biaya transaksi untuk suara tersebut, sementara jaringan menggunakan bandwidth, komputasi, dan ruang ledger untuk memproses serta menyimpannya.

Secara historis, transaksi suara mencakup sekitar tiga perempat dari seluruh transaksi yang tercatat secara onchain, meski rasio ini menurun seiring meningkatnya kapasitas blok. Walaupun transaksi suara murah (5.000 lamport) dan hanya mencakup sebagian kecil (~5%) dari keseluruhan komputasi, transaksi tersebut memperbesar jumlah transaksi mentah dan jejak ledger jaringan.

Dengan Alpenglow, validator justru bertukar pesan suara bertanda tangan BLS secara langsung satu sama lain. ConsensusPool milik Agave melacak suara yang diamatinya dan mengagregasi stake yang memadai menjadi sertifikat yang digunakan Votor untuk melanjutkan atau memfinalisasi konsensus.

Namun, bukti partisipasi validator tidak hilang dari ledger. Blok Alpenglow memperkenalkan footer blok baru yang berisi informasi konsensus. Dalam implementasi Agave saat ini, BlockFooterV1 dapat memuat sertifikat finalisasi terbaru serta notar_reward_cert dan skip_reward_cert. Sertifikat reward mencakup tanda tangan BLS agregat dan bitmap yang mengidentifikasi validator yang telah memberikan suara.

Sistem yang saat ini menentukan apakah validator telah memberikan suara dengan mengindeks transaksi Vote Program harus beralih menggunakan sertifikat dan data terkait suara milik Alpenglow. Pipeline transaksi yang hanya memfilter transaksi suara umumnya dapat terus beroperasi; setelah Alpenswitch, filter tersebut tidak akan memiliki apa pun untuk dihapus.

Peralihan ini juga menciptakan diskontinuitas pada statistik TPS Solana yang umum digunakan. Setelah Alpenglow aktif, pengukuran TPS mentah yang mencakup transaksi suara akan turun tajam meskipun aktivitas pengguna sama sekali tidak berubah. Karena itu, TPS non-suara adalah metrik yang relevan untuk membandingkan aktivitas sebelum dan sesudah Alpenswitch. Penghapusan transaksi suara menghilangkan sumber kebingungan yang telah lama ada terkait throughput Solana yang sebenarnya dan akan mempermudah perbandingan dengan jaringan lain.

Penghapusan transaksi suara mengembalikan sebagian kapasitas kepada pengguna, tetapi dampaknya tidak boleh dilebih-lebihkan karena suara hanya mencakup porsi yang relatif kecil dari beban komputasi jaringan.

Tingkat Commitment

Alpenglow juga menghapus salah satu perbedaan yang telah lama ada di Solana: kesenjangan antara commitment confirmed dan finalized.

Saat ini, aplikasi memilih di antara tiga tingkat commitment. processed memberikan tampilan terbaru, tetapi tidak memiliki jaminan di seluruh cluster. confirmed berarti mayoritas super stake telah memberikan suara untuk blok tersebut, yang biasanya tercapai dalam satu atau dua slot. finalized memberikan finalitas deterministik, tetapi pada TowerBFT mengharuskan blok mencapai lockout suara maksimum, sehingga menciptakan jeda sekitar 32 slot antara konfirmasi dan finalisasi. Secara umum, confirmed direkomendasikan untuk permintaan RPC yang sensitif terhadap latensi, sedangkan finalized digunakan ketika diperlukan jaminan yang lebih kuat.

Dalam praktiknya, confirmed terbukti sangat andal: belum pernah ada blok Solana yang dikonfirmasi secara optimistis kemudian gagal difinalisasi. Namun, jaminan protokolnya tetap lebih lemah. Blok yang dikonfirmasi belum final secara deterministik, sehingga aplikasi seperti bridge, bursa, dan sistem penyelesaian yang tidak dapat menoleransi sisa tail risk tersebut secara historis harus menunggu finalized.

Alpenglow menghapus kompromi ini. Setelah Votor menghasilkan sertifikat finalisasi cepat atau finalisasi, blok tersebut menjadi final. Ketika Votor memilih bank yang telah difinalisasi sebagai root, validator memperbarui slot terkonfirmasi tertinggi, root, dan root mayoritas super tertinggi secara bersamaan.

Bagi developer, ini berarti confirmed dan finalized secara efektif mengarah ke status konsensus yang sama setelah Alpenswitch. Aplikasi yang ada tidak perlu mengubah pengaturan commitment pada hari aktivasi, karena antarmuka RPC tetap menerima processed, confirmed, dan finalized, tetapi perbedaan latensi antara dua pilihan terakhir menghilang.

Perbedaan antara dua jalur finalisasi Votor tidak terlihat oleh pengguna RPC biasa. Baik sebuah blok mencapai ambang finalisasi cepat 80% dalam satu putaran maupun difinalisasi melalui jalur dua putaran dengan ambang 60%, hasil yang terlihat dari luar tetap sama.

Beberapa Blok Kandidat

Perubahan penting lain dalam Alpenglow menyasar penyedia RPC, pengindeks, dan infrastruktur lain yang menggunakan data validator. Slot tidak lagi dapat dianggap sebagai pengidentifikasi blok yang unik.

Slot Solana adalah jendela waktu ketika leader dapat menghasilkan blok. Sementara itu, bank adalah representasi lokal validator atas status yang dihasilkan dengan mengeksekusi blok kandidat tertentu. Konsep ini selalu berbeda, dan bank yang bersaing bukanlah hal baru, tetapi banyak infrastruktur produksi selama ini memperlakukan slot dan blok sebagai hal yang sama.

Alpenglow membuat asumsi tersebut semakin tidak aman.

Agave 4.3 memperluas Geyser (antarmuka validator yang digunakan untuk melakukan stream pembaruan akun, transaksi, entri, dan blok) dengan pengidentifikasi baru: bank_id. Callback baru yang memahami bank, termasuk update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank, dan notify_block_metadata_for_bank, mengaitkan suatu peristiwa dengan bank tertentu yang menghasilkannya. Notifikasi status dengan cakupan bank juga membawa bank_id. Callback lama tetap tersedia untuk kompatibilitas di versi 4.3, tetapi sudah dihentikan penggunaannya dan dijadwalkan untuk dihapus pada rilis mayor Agave berikutnya.

Hal pentingnya adalah bank_id mengidentifikasi instance bank lokal, bukan blok yang disepakati secara global. Agave membuat ID bank dari penghitung atomik lokal yang dikelola runtime validator, sehingga dua validator yang memutar ulang blok yang sama tidak dapat diharapkan menetapkan bank_id yang sama. Karena itu, infrastruktur harus menggunakan (slot, bank_id) untuk memisahkan stream yang bersaing dari satu validator, tetapi menggunakan ID blok atau blockhash saat merekonsiliasi data di antara validator atau koneksi yang berbeda.

Tahap Alpenglow mendatang menjadikan keberadaan beberapa bank untuk slot yang sama sebagai bagian normal dari operasi validator.

Contoh paling jelas adalah serah terima leader cepat, salah satu komponen Alpenglow yang diluncurkan setelah aktivasi awal Votor. Leader dapat mulai membangun secara optimistis di atas parent yang diperkirakan akan diterima oleh konsensus. Jika Votor justru memutuskan bahwa parent tersebut harus dilewati, leader dapat mengganti parent dan membangun ulang selama sisa jendela leader-nya. Secara internal, hal ini berarti mengganti satu bank dengan bank lain untuk slot yang sama. Agave sudah memiliki mekanisme UpdateParent yang diperlukan untuk merepresentasikan peralihan ini. Serah terima leader cepat bukan bagian dari aktivasi awal Alpenglow pada Agave 4.3 dan diperkirakan akan diluncurkan selama versi 4.4.

Ekuivokasi leader dapat menghasilkan dampak umum yang sama. Jika leader menandatangani dan mendistribusikan dua blok berbeda untuk slot yang sama, validator mungkin perlu menyimpan dan mempertimbangkan kedua kandidat tersebut untuk sementara. Bagian jaringan yang berbeda dapat melihat kandidat tersebut dalam urutan yang berbeda karena Votor bersifat asinkron dan validator bertindak atas blok, suara, sertifikat, serta timeout lokal sesuai urutan kedatangannya.

Perubahan terbaru mengurangi MAX_ALTERNATE_BLOCKS_PER_SLOT dari 11 menjadi 6. Karena itu, validator perlu menyimpan maksimal tujuh blok kandidat untuk sebuah slot. Konsensus pada akhirnya menetapkan kandidat tersebut menjadi satu riwayat. Dalam Votor, notarisasi memerlukan lebih dari 60% stake. Dua blok yang bertentangan tidak dapat sama-sama memperoleh sertifikat notarisasi yang valid tanpa sebagian besar stake memberikan suara untuk keduanya. Berdasarkan asumsi Alpenglow bahwa kurang dari 20% stake bertindak Byzantine, sertifikat notarisasi yang bertentangan tidak mungkin ada tanpa melanggar asumsi keamanan protokol.

Bagi pengguna Geyser, pelajaran praktisnya jelas: jangan lagi menetapkan kunci status sementara hanya berdasarkan slot. Perubahan akun, transaksi, entri, dan metadata blok harus dilacak per (slot, bank_id) hingga konsensus menentukan bank yang bertahan. Jika bank lain muncul untuk slot yang sama, peristiwanya termasuk dalam status kandidat terpisah dan tidak boleh diam-diam menimpa peristiwa dari bank pertama.

Tiket Penerimaan Validator

Transaksi suara saat ini merupakan biaya terbesar dalam menjalankan validator Solana. Dalam TowerBFT, validator membayar biaya transaksi standar setiap kali mengirimkan suara, dengan total sekitar 2 SOL per epoch. Alpenglow mengganti biaya transaksi dengan biaya yang dibebankan sekali per epoch kepada validator yang diterima dalam set konsensus aktif, yang dikenal sebagai Validator Admission Ticket (VAT).

Landasan untuk transisi ini sudah aktif. Pendaftaran kunci publik BLS, yang ditetapkan dalam SIMD-0387, diaktifkan di mainnet pada bulan Juli, lalu segera disusul oleh feature gate VAT, SIMD-0357. Votor menggunakan tanda tangan BLS agar tanda tangan dari banyak validator dapat diagregasi menjadi satu sertifikat ringkas. Setiap validator harus mendaftarkan kunci publik BLS di akun suaranya sebelum dapat berpartisipasi dalam Alpenglow. Sejak gate VAT diaktifkan, validator tanpa kunci tersebut sudah dikecualikan dari set pemungutan suara.

Sebelum Alpenglow, validator terus mengirimkan transaksi suara biasa dan membayar biaya terkait. Pada tahap ini, VAT terutama berfungsi sebagai filter penerimaan. Validator yang memenuhi syarat harus memiliki kunci BLS dan termasuk dalam 2.000 validator teratas yang memenuhi kualifikasi berdasarkan stake. VAT mulai berlaku setelah Alpenglow diaktifkan dan transaksi suara menghilang.

Setelah Alpenglow aktif, penerimaan dihitung ulang di sekitar batas epoch. Akun suara validator harus berisi kunci BLS terdaftar dan SOL yang cukup untuk menanggung tiket serta pengecualian sewa. Jika lebih dari 2.000 akun memenuhi syarat, sistem mengurutkannya berdasarkan stake dan menerima validator dengan stake tertinggi. Sistem kemudian memotong biaya tiket langsung dari akun suara setiap validator yang diterima dan mengirimkannya ke akun incinerator Solana. Karena itu, validator harus memastikan akun suaranya tetap memiliki dana; dalam sistem lama, biaya transaksi suara dipotong dari akun identitas validator.

Proposal awal Alpenglow dan VAT menetapkan tiket sebesar 1,6 SOL per epoch, sekitar 80% dari kurang lebih 2 SOL yang sebelumnya dikeluarkan validator untuk transaksi suara. Angka tersebut mengasumsikan target waktu slot historis Solana sebesar 400 milidetik. Sebaliknya, SIMD-0525 menyesuaikan VAT berdasarkan durasi slot. Biaya penerimaan pada waktu slot 200 milidetik akan menjadi 0,8 SOL.

VAT juga mengubah tujuan biaya ini. Saat ini, biaya dasar 5.000 lamport yang dibayarkan oleh transaksi suara dibagi menjadi dua: 50% dibakar dan 50% diberikan kepada leader blok. Sebaliknya, VAT dikirim seluruhnya ke incinerator. Namun, tujuan VAT yang lebih luas bukanlah membuat SOL jauh lebih deflasioner. Tujuannya adalah mempertahankan biaya ekonomi untuk bergabung dengan set konsensus setelah biaya transaksi suara dihapus.

Keamanan dan Kesiapan

Mengganti protokol konsensus jaringan yang aktif merupakan operasi dengan risiko luar biasa tinggi. Karena itu, Alpenglow memiliki proses pengujian dan migrasi yang jauh lebih luas daripada aktivasi fitur Agave biasa, termasuk cluster pengujian khusus komunitas dan bug bounty.

Sejak Mei, operator validator telah menjalankan Alpenglow Community Cluster khusus yang berkembang hingga mencakup lebih dari 100 node. Operator menggunakan hardware validator dan konfigurasi jaringan nyata, sehingga Alpenglow dapat diuji dalam kondisi persebaran geografis, variasi latensi, konfigurasi software, restart, dan kesalahan operasional yang sulit direproduksi di lingkungan terkendali.

Salah satu tujuan terpentingnya adalah menguji Alpenswitch itu sendiri. Alih-alih hanya memeriksa apakah Votor berfungsi setelah cluster menjalankan Alpenglow, operator telah berulang kali menguji transisi dari TowerBFT ke sistem konsensus baru.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

9 Mei 2026, 6.59 PM

Alpenglow juga telah menjalani peninjauan adversarial khusus. Pada bulan Agustus, Anza membuka Kompetisi Bug Bounty Alpenglow selama dua minggu dengan total hadiah hingga 50.000 SOL. Berbeda dengan bounty Agave yang selalu tersedia, cakupan kompetisi ini secara khusus berfokus pada stack konsensus baru, termasuk Votor, tanda tangan BLS dan verifikasi sertifikat, penerimaan validator, serta jalur migrasi dari TowerBFT ke Alpenglow. Partisipasinya sangat besar. Anza melaporkan lebih dari 300 pengajuan dan menyatakan bahwa lebih dari 25.000 SOL akan dibagikan sebagai bounty.

Dukungan Frankendancer berakhir dengan hadirnya Alpenglow. Frankendancer memang selalu ditujukan sebagai klien transisi yang menggabungkan komponen jaringan dan produksi blok Firedancer dengan komponen Agave untuk eksekusi dan konsensus. Mendukung sistem konsensus baru dalam arsitektur hibrida tersebut akan menambah beban pemeliharaan dan keamanan yang besar, sehingga tim Firedancer memfokuskan pengembangan pada klien Firedancer lengkap.

Panduan yang diberikan kepada validator menyatakan bahwa Frankendancer maupun Firedancer lengkap tidak akan mendukung jendela singkat migrasi TowerBFT ke Alpenglow. Karena itu, operator Firedancer harus mengatur failover ke validator Agave sebelum Alpenswitch, tetap menggunakan Agave selama serah terima, lalu kembali ke Firedancer setelah cluster beroperasi secara normal dengan Alpenglow.

Cara Alpenswitch Sebenarnya Berlangsung

Alpenglow tidak diaktifkan di semua tempat pada waktu wall-clock yang ditentukan secara arbitrer. Setelah fiturnya diaktifkan, protokol menetapkan batas migrasi 5.000 slot kemudian. TowerBFT terus beroperasi sementara validator melewati batas ini dan mencari blok dengan konfirmasi yang cukup kuat. Validator kemudian menandatangani blok genesis Alpenglow yang dipilih dengan BLS dan mendistribusikan suara genesis tersebut secara langsung satu sama lain.

Serah terima berlangsung setelah setidaknya 82% stake menandatangani blok genesis yang sama, sehingga menghasilkan sertifikat genesis Alpenglow. Validator yang menerima dan memverifikasi sertifikat tersebut menonaktifkan TowerBFT setelah blok genesis serta menginisialisasi Votor dari status yang telah disepakati. Sertifikat tersebut kemudian menyebar ke seluruh set validator, membawa node yang tersisa melewati batas migrasi.

Sertifikat ini memberi operator infrastruktur cara yang praktis untuk menentukan posisi cluster terhadap Alpenswitch.

Agave 4.3 memperkenalkan metode RPC baru getAgGenesisCert. Sebelum migrasi, node Agave 4.3 mengembalikan null. Setelah cluster beralih, node mengembalikan sertifikat genesis Alpenglow, termasuk blok genesis dan tanda tangan BLS agregat. Node lama yang tidak mendukung metode tersebut akan mengembalikan Method not found. CLI menyediakan informasi yang sama melalui: solana alpenglow-genesis-info.

Karena itu, bagi validator, penyedia RPC, dan infrastruktur lain yang perlu merespons migrasi, memeriksa sertifikat genesis lebih baik daripada mengasumsikan Alpenglow aktif pada timestamp tertentu.

Syscall Kriptografis Baru

Agave 4.3 juga memperluas perangkat kriptografis SVM dengan primitive runtime baru untuk operasi yang terlalu mahal jika dilakukan langsung dalam sBPF.

Dua penambahan pentingnya adalah hashing SHA-512 dan eksponensiasi modular bilangan bulat besar. Keduanya bersifat aditif dan dilindungi feature gate: program yang ada tidak terpengaruh, sedangkan program yang memilih menggunakannya dapat mendelegasikan kriptografi yang mahal secara komputasi ke implementasi native yang dioptimalkan dalam runtime validator.

Eksponensiasi Modular Bilangan Bulat Besar

SIMD-0529: Syscall ModExp Bilangan Bulat Besar memperkenalkan sol_big_mod_exp, sebuah syscall untuk menghitung:

result = (base ^ exponent) mod modulus

Eksponensiasi modular adalah operasi fundamental di balik verifikasi tanda tangan RSA, akumulator kriptografis, sejumlah fungsi penundaan yang dapat diverifikasi, dan protokol teori bilangan lainnya. Mengimplementasikannya dengan aritmetika bilangan bulat presisi arbitrer secara langsung di dalam program SVM memerlukan komputasi yang sangat besar, terutama pada ukuran kunci RSA umum seperti 2048, 3072, dan 4096 bit.

Syscall baru ini memindahkan aritmetika yang mahal ke runtime validator. Program menyediakan basis, eksponen, dan modulus sebagai bilangan bulat unsigned little-endian, lalu menerima hasilnya dalam memori yang disediakan pemanggil. Setiap operand pada awalnya dibatasi hingga 512 byte, cukup untuk mendukung bilangan bulat hingga 4096 bit.

Kasus penggunaan yang paling jelas adalah verifikasi RSA. Misalnya, program yang memverifikasi tanda tangan RSA konvensional dapat memanggil sol_big_mod_exp menggunakan eksponen publik umum 65537, alih-alih mengimplementasikan sendiri eksponensiasi bilangan bulat besar. Syscall ini sengaja berhenti pada primitive aritmetika: program tetap bertanggung jawab atas hashing, padding RSA seperti PKCS#1 v1.5 atau PSS, validasi kunci, dan pemisahan domain khusus protokol.

Syscall ini juga dapat melakukan reduksi modular bilangan bulat besar secara efisien. Penggunaan eksponen 1 menyederhanakan operasi menjadi:

base mod modulus

Hal ini memberi program primitive native untuk mereduksi bilangan bulat yang lebih besar daripada ukuran word mesin bawaan SVM tanpa menanggung biaya implementasi bilangan bulat besar serbaguna.

Secara konsep, desain ini mirip dengan precompile ModExp Ethereum yang diperkenalkan oleh EIP-198, dan model pengukuran komputasinya mengikuti rumus kompleksitas operasi EIP-198. Namun, desain ini tidak kompatibel dengan Ethereum secara byte-for-byte. Solana menyediakan fungsionalitas tersebut melalui ABI syscall native, menggunakan input little-endian, dan mengharuskan modulus berupa bilangan bulat ganjil yang lebih besar dari satu; modulus genap ditolak.

Hal ini membuat syscall tersebut sangat berguna untuk interoperabilitas tanpa memaksa Solana mengadopsi antarmuka precompile EVM. Program yang memverifikasi proof, tanda tangan, atau atestasi berdasarkan asumsi kriptografis bergaya Ethereum dapat menggunakan kembali aritmetika dasar yang sama sambil menyesuaikan cara pemanggilannya.

SHA-512

Penambahan kedua jauh lebih sederhana, tetapi langsung bermanfaat.

SIMD-0512: Syscall Sha512 menambahkan sol_sha512, yang memberi program onchain akses langsung ke fungsi hash SHA-512 melalui runtime validator. Antarmukanya mengikuti syscall sol_sha256, sol_keccak256, dan sol_blake3 yang sudah ada di Solana serta mengembalikan digest SHA-512 standar berukuran 64 byte.

SHA-512 merupakan salah satu primitive inti yang digunakan oleh Ed25519, skema tanda tangan yang banyak digunakan Solana. Agave dan Firedancer sudah bergantung pada SHA-512 secara internal, tetapi sebelum perubahan ini, program SVM tidak dapat mengakses implementasi yang dioptimalkan tersebut secara langsung. Program yang memerlukan SHA-512 harus mengimplementasikan algoritmanya sendiri dalam software.

Dari perspektif komputasi, perbedaannya sangat besar. SIMD memperkirakan bahwa hashing input pendek menggunakan implementasi sBPF menghabiskan ribuan CU, sedangkan operasi yang sama melalui syscall menghabiskan kurang dari 100 CU. sol_sha512 menggunakan model biaya komputasi umum yang sama dengan syscall SHA-256 Solana yang sudah ada.

Secara keseluruhan, kedua syscall ini melanjutkan tren yang lebih luas dalam SVM: memindahkan primitive kriptografis umum yang mahal secara komputasi dari masing-masing program ke operasi runtime standar dan terukur. Program tetap menentukan protokol kriptografis tingkat tinggi, tetapi validator dapat mengeksekusi komponen dasar yang mahal dengan jauh lebih efisien daripada implementasi sBPF.

Kesimpulan

Perubahan utama Agave 4.3 adalah Alpenglow, yang menggantikan TowerBFT dengan Votor, menghapus transaksi suara dari blok, memangkas finalitas dari hitungan detik menjadi milidetik, serta mengubah cara validator dan infrastruktur berinteraksi dengan konsensus.

Bagi sebagian besar pengguna dan developer aplikasi, sebagian besar transisi ini akan berlangsung tanpa terlihat. Namun, bagi validator, penyedia RPC, pengindeks, dan tim infrastruktur, Agave 4.3 menandai dimulainya perubahan besar dalam cara Solana mencapai konsensus.

Referensi Lebih Lanjut

• Whitepaper Alpenglow v1.2 (Juli 2026)
• Jadwal Rilis Agave 4.3
• Jadwal Pelacak Feature Gate
• Log Perubahan Agave 4.3
• Pull Request Agave 4.3
• Peningkatan Alpenglow - Solana Foundation