Pembaruan Agave 4.2: Semua yang Perlu Anda Ketahui

Pendahuluan

Dengan Agave 4.2, klien validator inti Solana terus menghadirkan terobosan baru. Rilis utama ini berfokus pada tiga peningkatan yang sangat dinantikan dan dikendalikan oleh feature gate: waktu slot 200 milidetik, pengurangan jaminan state sebesar 90%, dan transaksi berukuran 4.096 byte melalui format transaction v1 yang baru. Rilis ini juga menghadirkan Alpenglow dengan fitur lengkap sebelum aktivasi yang direncanakan pada rilis berikutnya, sementara XDP transmit kini diaktifkan secara default.

Pembaruan Penting

• Transaksi 3,3× Lebih Besar dengan standar Transaction v1 baru *
• Pengurangan Jaminan State (Rent) sebesar 90% *
• Waktu Slot Dipangkas menjadi 200 Milidetik *
• Alpenglow dengan fitur lengkap
• Perangkat Governance Baru (terkait SIMD)

* Peningkatan yang dikendalikan oleh feature gate

Transaksi Lebih Besar (Transaction v1)

Siklus rilis Agave 4.2 mencakup aktivasi feature gate untuk transaksi yang lebih besar hingga 4.096 byte, naik dari batas lama sebesar 1.232 byte. Batas yang lebih tinggi ini, yang didefinisikan secara formal dalam SIMD-0296: Ukuran Transaksi Lebih Besar, merupakan peningkatan sekitar 3,3× dan berlaku khusus untuk format transaction v1 baru yang diperkenalkan oleh SIMD-0385: Format Transaction V1. Transaksi legacy dan v0 tetap berfungsi tanpa perubahan dan tetap tunduk pada batas 1.232 byte yang ada.

Bagi developer, ini bukan sekadar ruang tambahan untuk data instruksi. Bukti kriptografis, persetujuan multisig, daftar akun berukuran besar, dan payload lain yang sebelumnya tidak dapat dimuat dalam satu transaksi kini dapat dieksekusi dalam satu operasi atomik native protokol. Perubahan ini tidak meningkatkan batas komputasi, akun, tanda tangan, atau jumlah instruksi Solana.

Batas awal sebesar 1.232 byte diwarisi dari arsitektur jaringan Solana sebelumnya. Transaksi dikirim sebagai datagram UDP individual dan harus muat dalam maximum transmission unit (MTU) minimum IPv6 sebesar 1.280 byte. Setelah memperhitungkan header IPv6 sebesar 40 byte dan header UDP sebesar delapan byte, tersisa 1.232 byte untuk transaksi itu sendiri. Mempertahankan setiap transaksi dalam satu paket mengurangi fragmentasi dan membuat transmisi lebih mudah diprediksi.

Solana telah lama bermigrasi dari UDP ke QUIC untuk penerimaan transaksi. Stream QUIC tidak dibatasi oleh payload satu datagram jaringan, sehingga batas lama sebesar 1.232 byte tidak lagi diperlukan. Klien tetap memerlukan batas atas yang eksplisit untuk kontrol penerimaan, alokasi memori, dan validasi konsensus, tetapi batas tersebut kini dapat ditentukan berdasarkan kebutuhan runtime dan aplikasi, bukan MTU IPv6.

Daftar akun sering kali menggunakan sebagian besar alokasi ukuran yang tersedia. Setiap public key Ed25519 atau program-derived address memerlukan 32 byte, dan transaksi harus mengidentifikasi setiap akun yang dibaca atau diubah oleh instruksinya. Sebelumnya, hal ini menghasilkan batas efektif sekitar 32 key akun lengkap. Untuk mengatasinya, transaksi V0 memperkenalkan Address Lookup Tables (ALT), yang mengganti setiap key 32 byte dengan indeks tabel satu byte sehingga transaksi dapat mencapai batas runtime sebesar 64 akun.

Meskipun ALT merupakan bentuk kompresi yang efektif, ALT juga menambah kompleksitas. Aplikasi harus membuat dan mengelola lookup table secara onchain. Layanan RPC dan indexer yang mendekode pesan v0 mentah harus menyusun ulang daftar akun lengkapnya menggunakan metadata transaksi atau state tabel yang relevan. Hal ini menimbulkan tantangan saat mengurai transaksi yang merujuk pada ALT yang kemudian telah ditutup dan tidak lagi tersedia secara onchain. 

Kendala bagi developer ini diatasi dengan transaksi v1, yang cukup besar untuk memuat kumpulan akun lengkap yang saat ini didukung melalui ALT (64 public key lengkap yang menggunakan 2.048 byte). Dengan demikian, aplikasi yang bermigrasi dari v0 dapat me-resolve entri lookup table dan menyertakan alamat yang dihasilkan secara langsung dalam transaksi v1.

Selain itu, ukuran transaksi 1.232 byte sangat membatasi fungsi kriptografis seperti zero-knowledge proof dan implementasi BLS yang tidak memiliki precompile native. Workload ini dapat membawa ratusan atau ribuan byte data bukti atau tanda tangan. Batas 4.096 byte mencakup banyak kasus penggunaan kriptografis umum tersebut. 

Spesifikasi Transaction V1

Transaksi v1 yang diserialisasi dimulai dengan byte versi 0x81. Setelahnya terdapat header pesan bergaya legacy sepanjang tiga byte, mask konfigurasi transaksi 32-bit, penentu masa berlaku sepanjang 32 byte, jumlah instruksi dan alamat, array lengkap alamat 32 byte, nilai konfigurasi, header instruksi berukuran tetap, payload instruksi yang berurutan, dan terakhir tanda tangan. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Header instruksi secara eksplisit mengidentifikasi indeks akun program, jumlah akun instruksi, dan panjang data instruksi, sehingga batas pesan dapat diketahui tanpa menafsirkan payload setiap instruksi.

Transaksi V1 tetap dibatasi hingga 12 tanda tangan, 64 alamat akun, 64 instruksi, dan 255 indeks akun per instruksi. Transaksi besar tetap harus sesuai dengan batas compute unit yang diminta, batas data akun yang dimuat, aturan penguncian akun, dan kapasitas eksekusi blok yang tersedia.

Parser yang ada tidak dapat memperlakukan v1 sebagai v0 dengan panjang maksimum yang lebih besar. Indexer, RPC, SDK, dan infrastruktur penandatanganan yang memeriksa transaksi terserialisasi harus mengenali prefiks 0x81 dan menerapkan urutan field yang baru. Perlu diperhatikan bahwa tanda tangan v1 muncul di akhir transaksi, bukan mendahului pesan seperti pada transaksi legacy dan v0.

Transaction v1 mengganti instruksi konfigurasi Compute Budget program dengan field dalam header transaksi. `TransactionConfigMask` awal dapat mendeklarasikan:

• total priority fee dalam lamport
• batas compute unit
• batas ukuran data akun yang dimuat
• ukuran heap yang diminta

Setiap bit yang disetel mengidentifikasi nilai konfigurasi empat byte yang menyertainya, sedangkan priority fee 64-bit menggunakan dua posisi mask. Mask ini dirancang agar dapat diperluas dalam versi transaksi mendatang.

Pengurangan Jaminan State (Rent)

Persyaratan jaminan state yang tinggi, biasanya disebut “rent”, tetap menjadi salah satu sumber hambatan terbesar di Solana bagi aplikasi yang menggunakan banyak akun. Istilah tersebut agak menyesatkan karena rent bukanlah biaya penyimpanan berulang, melainkan jaminan yang dapat dikembalikan dan harus disimpan oleh akun selama state-nya tetap berada secara onchain. Lamport biasanya dapat diperoleh kembali saat akun ditutup, tetapi hingga saat itu, lamport tersebut merupakan modal yang harus disediakan di muka oleh developer atau pengguna dan tidak dapat digunakan.

Agave 4.2 memperkenalkan implementasi SIMD-0437: Mengurangi lamports_per_byte Secara Bertahap menjadi 696 yang dikendalikan oleh feature gate. Implementasi ini mengurangi konstanta `lamports_per_byte` dari 6.960 menjadi 696. Ini merupakan pengurangan rent sebesar 90% (atau lebih tepatnya saldo minimum bebas rent), yang diterapkan melalui lima feature gate independen: 6.960 → 6.333 → 5.080 → 2.575 → 1.322 → 696. 

Saat salah satu gate diaktifkan, Agave memperbarui konfigurasi rent Bank dan memublikasikan nilai baru melalui Rent sysvar. Peluncuran bertahap memungkinkan jaringan mengamati respons aplikasi pada setiap tingkat harga dan berhenti sebelum pengurangan berikutnya jika pertumbuhan state atau penggunaan resource validator mulai mengkhawatirkan.

Saldo minimum bebas rent sebuah akun dihitung dari ukuran data yang dialokasikan ditambah overhead penyimpanan tetap sebesar 128 byte:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Dalam perubahan ini, mekanisme rent itu sendiri tidak berubah: akun tetap memerlukan saldo minimum, dan saldo tersebut tetap dapat diperoleh kembali saat akun ditutup. Hanya jumlah SOL yang harus dijaminkan yang berubah.

Akun SPL Token standar berukuran 165 byte. Dengan menyertakan overhead 128 byte, ukuran efektifnya menjadi 293 byte. Pengurangan rent sebesar 90% menurunkan SOL yang diperlukan untuk akun tersebut dari sekitar ~$0,16 menjadi kurang dari 2 sen. 

Hal ini berdampak sangat penting bagi pembayaran stablecoin, distribusi token, sistem loyalitas, dan airdrop langsung. Wallet tidak menyimpan SPL token secara langsung; biasanya diperlukan Associated Token Account (ATA) untuk setiap mint. Jika penerima belum memiliki ATA yang diperlukan, pengirim dapat membuatnya bersamaan dengan transfer, tetapi juga harus mendanai saldo bebas rent milik penerima. Secara umum, ini merupakan biaya onboarding satu kali untuk setiap pasangan wallet dan mint, bukan biaya yang dibayarkan pada setiap pembayaran berikutnya. Namun, dalam skala besar, jumlahnya dapat cukup signifikan untuk menentukan apakah bisnis menyubsidi onboarding atau membebankan biayanya kepada pengguna.

Pertumbuhan State Solana

Pengurangan bertahap penting karena menurunkan jaminan state juga mengurangi jumlah modal yang harus ditahan penyerang untuk membuat dan mempertahankan state yang tidak diinginkan. State Solana direplikasi, diindeks, disertakan dalam snapshot, dan dipelihara oleh setiap validator. Karena itu, pertumbuhan state yang berkelanjutan pada akhirnya memengaruhi kebutuhan disk, operasi AccountsDB, dan biaya operasional.

Menurut analisis terbaru Solana Foundation, file penyimpanan AccountsDB menggunakan sekitar 495 GB dari alokasi yang disarankan sebesar 1 TB. Setelah pengurangan rent yang direncanakan, untuk menghabiskan ruang tersisa tersebut, penyerang perlu menyediakan SOL senilai sekitar $17,2 juta. Menggandakan alokasi penyimpanan validator yang disarankan menjadi 2 TB meningkatkan kebutuhan modal penyerang menjadi $51 juta.

Setelah memperhitungkan pembuatan akun baru dan penutupan akun lama, state diketahui bertambah sekitar 0,3 GB per hari.

Snapshot state yang diambil pada epoch 997 menunjukkan bahwa penggunaan state sangat terkonsentrasi. Akun SPL Token merupakan kategori terbesar, sementara akun OpenBook dan Serum menggunakan sekitar 30% state aktif, yang mencerminkan arsitektur kompleks order book onchain. Analisis tersebut juga memperkirakan bahwa sekitar 30% ruang SPL Token terkait dengan aset bergaya launchpad token Pump.fun.

Langkah Pengamanan

Mengurangi jaminan state secara aman memerlukan jalur yang layak untuk bergerak ke arah sebaliknya. Tanpa perubahan runtime tambahan, menaikkan saldo minimum bebas rent di kemudian hari akan langsung membuat akun yang ada berada di bawah ambang baru. Transaksi yang melakukan write-lock pada akun tersebut dapat gagal meskipun tidak mengalokasikan state tambahan, sehingga berpotensi menimbulkan gangguan luas.

Di sinilah SIMD-0392: Menyesuaikan Runtime untuk Kenaikan Rent mengubah aturan saldo minimum setelah eksekusi agar akun yang ada dapat dikecualikan saat rent naik. Jika akun sudah ada, ukurannya tidak bertambah, dan pemiliknya tetap sama, saldo minimum yang diizinkan menjadi nilai yang lebih rendah dari:

1. saldo minimum berdasarkan tarif rent saat ini
2. saldo akun sebelum eksekusi

Akun baru tetap harus memenuhi saldo minimum bebas rent saat ini. Hal yang sama berlaku bagi akun yang memperbesar ukuran alokasinya atau mengganti pemilik. Saldo nol tetap menandakan penutupan akun. Dengan demikian, state yang ada dapat terus beroperasi dengan jumlah jaminan sebelumnya, sekaligus memastikan bahwa state yang baru dialokasikan membayar tarif terbaru.

SIMD-0438: Perlindungan untuk kenaikan saldo minimum bebas rent menambahkan feature gate perlindungan terpisah yang mengembalikan `lamports_per_byte` ke nilai legacy sebesar 6.960. Gate ini dimaksudkan untuk diaktifkan hanya jika penurunan rent menyebabkan pertumbuhan state berlebihan atau masalah operasional signifikan lainnya. Karena gate sudah tersedia sebelum pengurangan dimulai, developer inti tidak perlu merancang, meninjau, dan menerapkan perubahan konsensus baru di tengah insiden pertumbuhan state yang sedang berkembang.

Secara keseluruhan, lima gate pengurangan, aturan pengecualian akun lama dalam SIMD-0392, dan mekanisme fallback dalam SIMD-0438 membuat peluncuran dapat dibalik pada tingkat protokol. Jaringan dapat menurunkan jaminan secara bertahap, mengamati perilaku state aktif dan penyimpanan validator, berhenti pada nilai perantara, atau memulihkan persyaratan awal tanpa mengharuskan setiap akun yang ada segera menambah saldo.

Waktu Slot Dipangkas menjadi 200 Milidetik

Salah satu peningkatan performa Solana yang paling dinantikan adalah pengurangan target waktu slot dari 400 milidetik menjadi 200 milidetik. Manfaat utamanya adalah latensi yang lebih rendah. Dengan slot 200 milidetik, jendela leader empat slot Solana menyusut dari 1,6 detik menjadi 800 milidetik, sehingga mengurangi waktu konfirmasi dan membatasi durasi leader berbahaya dapat menunda, mengubah urutan, atau menyertakan transaksi secara selektif. Slot yang lebih singkat juga memberikan pengaturan waktu onchain yang lebih terperinci bagi aplikasi seperti pengguna oracle dan market maker.

Proposal ini dirancang untuk mempertahankan ekonomi dan throughput Solana yang ada. Parameter inflasi, biaya Validator Admission Ticket dalam Alpenglow, dan batas pekerjaan per slot disesuaikan secara proporsional. Namun, jika slot 200 milidetik diterapkan sebelum Alpenglow, biaya voting validator dapat meningkat sekitar dua kali lipat karena validator harus melakukan voting dua kali lebih sering.

Untuk pembahasan lebih mendalam tentang slot 200 milidetik, baca ulasan kami sebelumnya dalam pembahasan Agave 4.1.

Pembaruan Penting Lainnya

Beberapa peningkatan yang lebih kecil tetapi penting dijadwalkan untuk diaktifkan selama siklus rilis Agave 4.2.

Kesiapan Alpenglow

Agave 4.2 menghadirkan Alpenglow dengan fitur lengkap, tetapi tidak akan mengaktifkan protokol konsensus baru tersebut di mainnet. Tim engineering inti menggunakan siklus rilis ini untuk pengujian, audit, dan penguatan lebih lanjut menjelang migrasi konsensus yang kini diperkirakan berlangsung bersama Agave 4.3. Karena itu, validator yang menjalankan 4.2 sudah membawa implementasi Alpenglow lengkap, termasuk mesin voting Votor dan komponen verifikasi sertifikat BLS-nya. 

Untuk memperluas tinjauan keamanan kode, Anza juga mengadakan kompetisi bug bounty Alpenglow dengan total hadiah hingga 50.000 SOL dan periode pengiriman dari 5 hingga 19 Agustus. Sebelumnya, Alpenglow dikecualikan dari bounty Agave yang sedang berlangsung selama pengembangan, migrasi monorepo, dan audit internal. Kompetisi ini menandai dimulainya kelayakan Alpenglow untuk bounty dan ditujukan untuk menemukan masalah yang mungkin terlewat dalam tinjauan sebelumnya.

Stake Program dari Floating-Point ke Fixed-Point

Siklus rilis Agave 4.2 juga mencakup implementasi SIMD-0391: Stake Program dari Floating-Point ke Fixed-Point yang dikendalikan oleh feature gate. Implementasi ini mengganti aritmetika floating-point IEEE-754 dalam perhitungan warmup dan cooldown Stake Program dengan matematika bilangan bulat fixed-point yang deterministik. Motivasi utamanya adalah kompatibilitas dengan toolchain eBPF standar, yang tidak mendukung operasi floating-point. Toolchain SBF Solana dapat mengemulasikannya menggunakan routine soft-float deterministik, tetapi pendekatan ini tidak efisien dan menghambat migrasi Stake Program menuju implementasi `no_std`.

Sebagian besar aplikasi tidak memerlukan perubahan. Namun, indexer dan perangkat staking yang secara mandiri mereproduksi stake efektif, yang sedang diaktifkan, atau yang sedang dinonaktifkan harus menerapkan aturan bilangan bulat baru setelah fitur tersebut diaktifkan.

Perangkat Governance Baru

Siklus rilis Agave 4.2 juga menandai peluncuran perangkat governance baru yang telah dikembangkan sejak tahun lalu. Perangkat ini menyediakan proses onchain bagi validator dan staker native untuk menyatakan posisi mereka terkait keputusan ekonomi dan tingkat protokol yang besar. 

Komponen utamanya, svmgov, adalah program berbasis Anchor yang mengelola pembuatan proposal, dukungan, voting berbobot stake, dan finalisasi. Bobot voting berasal dari snapshot stake khusus epoch yang dihasilkan oleh Node Consensus Network (NCN). Operator independen menghasilkan snapshot, mencapai konsensus atas Merkle root kanonis, lalu memublikasikannya secara onchain. Validator kemudian membuktikan stake aktif mereka menggunakan Merkle proof. 

Validator dengan stake aktif minimal 100.000 SOL dapat membuat proposal, sedangkan proposal memerlukan dukungan dari 15% stake cluster sebelum melanjutkan proses voting. Repositori governance juga menyertakan CLI Rust dan frontend web untuk voting serta pelacakan dukungan.

Dokumen proposal lengkap berada di repositori Solana Governance Proposals yang terpisah dan disematkan ke commit Git tertentu, sedangkan akun proposal onchain menyimpan tautan, status siklus hidup, dan penghitungan suara. Awalnya, validator melakukan voting dengan seluruh stake yang didelegasikan kepada mereka, tetapi delegator individu tetap memiliki kendali penuh atas SOL mereka. Staker dapat mengirimkan override untuk akun stake tertentu, menghapus stake tersebut dari penghitungan validator, dan mengalokasikannya kembali berdasarkan suara staker sendiri.

Solana Governance Proposals (SGP) ditujukan untuk melengkapi, bukan menggantikan, SIMD: SGP menjawab pertanyaan arah tentang apakah jaringan perlu menjalankan suatu perubahan, sedangkan SIMD terkait menentukan cara perubahan tersebut harus diterapkan.

Tiga SGP telah melewati tahap dukungan dan akan menjadi putaran pertama voting governance dalam sistem baru:

• SGP-0001: Konstitusi Solana mengusulkan ratifikasi kontrak sosial governance kanonis yang mendefinisikan peran developer, validator, dan staker, serta menetapkan proses SGP secara formal.
• SGP-0002: Disinflasi Ganda meminta jaringan menggandakan tingkat disinflasi tahunan SOL dari 15% menjadi 30% tanpa mengubah tingkat inflasi terminal sebesar 1,5%, sehingga estimasi waktu untuk mencapai tingkat terminal tersebut berkurang dari sekitar 5,7 tahun menjadi 2,8 tahun. 
• SGP-0003: Biaya Resource dan Inklusi mengusulkan penggantian struktur biaya dasar tetap yang ada dengan biaya inklusi sebesar 2.500 lamport yang dibayarkan kepada leader dan biaya resource terpisah berdasarkan unit biaya transaksi yang diminta dan dibakar sepenuhnya, tanpa mengubah distribusi priority fee.

Kesimpulan

Agave 4.2 merupakan salah satu rilis Solana dengan dampak terbesar dalam beberapa tahun terakhir. Slot 200 milidetik yang lebih cepat membawa jaringan semakin dekat ke respons real-time, rencana pengurangan jaminan state sebesar 90% membuat pembuatan akun jauh lebih terjangkau, dan transaction v1 berukuran 4.096 byte membuka lebih banyak ruang untuk instruksi kompleks, bukti kriptografis, dan aplikasi yang menggunakan banyak akun. Secara keseluruhan, perubahan ini membuat Solana lebih cepat, lebih murah, dan lebih ekspresif bagi developer maupun pengguna.

Referensi Lebih Lanjut

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