Pembaruan Agave v2.2: Semua yang Perlu Anda Ketahui

Pembaruan Penting dalam Siklus Rilis Agave 2.2 

• Optimalisasi performa secara ekstensif
• Peningkatan batas blok sebesar 20% dari 50 juta menjadi 60 juta CU
• Pengenalan Accounts Lattice Hash (ALH)
• Verifikasi tanda tangan Secp256r1 (ditunda dari siklus rilis Agave 2.1)
• Deployment dan eksekusi program SBPFv1, v2, dan v3
• Penghapusan Pembatasan Pemanggil CPI
• Loader-v4

Setiap bagian artikel ini berdiri sendiri sehingga pembaca dapat dengan mudah menjelajahi topik yang paling relevan. Baik Anda operator validator, developer, maupun pengguna aktif, panduan lengkap Agave 2.2 ini menawarkan wawasan utama yang diperlukan untuk memanfaatkan peningkatan terbaru secara maksimal.

Peluncuran Fitur

Saat artikel ini ditulis, 19,8% dari total stake menjalankan Agave v2.2.*, yang menunjukkan dukungan kuat terhadap adopsi di seluruh jaringan. Aktivasi feature gate mainnet dihentikan sementara selama periode upgrade dan diperkirakan akan segera dilanjutkan sesuai urutan aktivasi yang direncanakan.

Sebagian besar fitur utama yang diperkenalkan dalam Agave 2.2 saat ini masih dibatasi oleh feature gate dan belum aktif di mainnet. Fitur-fitur tersebut akan diaktifkan secara bertahap sepanjang siklus rilis 2.2 melalui sistem feature gate Solana. Waktu aktivasi ditentukan berdasarkan prioritas fitur dan urutan peluncurannya pada klaster testnet dan devnet. Lihat pelacak feature gate Agave untuk pembaruan terbaru.

Menaikkan Batas Blok menjadi 60 Juta CU

Anza telah menetapkan target ambisius untuk 2025: menggandakan ruang blok yang tersedia di Solana. Sebagai bagian dari upaya ini, SIMD-0256: Menaikkan Batas Blok menjadi 60 Juta dijadwalkan untuk disertakan dalam rilis Solana 2.2 mendatang, yang berarti peningkatan sebesar 20% dari batas blok saat ini.

Langkah ini menyusul upgrade sebelumnya yang meningkatkan batas blok dari 48 juta menjadi 50 juta compute unit (CU). Setelah peningkatan tersebut, waktu blok secara konsisten berada di bawah target 400 ms. Data terbaru menunjukkan bahwa blok secara rutin mencapai batas maksimum 50 juta CU, yang menandakan kesiapan untuk penskalaan lebih lanjut.

Catatan: Beberapa blok tampak terisi 104% karena adanya konstanta yang di-hardcode dalam logika pelaporan dasbor Firedancer.

Batas protokol lainnya tetap sama dalam pembaruan ini:

• Anggaran komputasi per account per blok tetap sebesar 12 juta CU.
• Komputasi maksimum per transaction tetap dibatasi sebesar 1,4 juta CU.
• Batas komputasi agregat untuk transaction voting per blok tetap sebesar 36 juta CU.
• Alokasi data account baru maksimum per blok tetap dibatasi sebesar 100 MB.

Menaikkan batas blok berdampak langsung pada pengalaman pengguna: throughput jaringan yang lebih tinggi menghasilkan median biaya transaction yang lebih rendah dan meningkatkan peluang keberhasilan masuknya transaction selama periode kemacetan.

Tantangan dalam Menaikkan Batas Blok

Saat meningkatkan throughput, batas blok sebaiknya dinaikkan dengan pendekatan yang cermat dan bertahap karena ada dua tantangan utama yang harus diatasi:

1. Kesiapan Infrastruktur

Infrastruktur ekosistem yang lebih luas harus mengimbangi optimalisasi klien inti. Secara khusus, lapisan tulis tidak boleh melampaui lapisan baca (misalnya node RPC, pengindeks, dan layanan arsip) karena dapat menurunkan kualitas pengalaman pengguna.

2. Propagasi Blok yang Tepat Waktu

Hambatan lainnya terletak pada pengiriman blok dari node leader ke seluruh klaster. Blok yang jauh lebih besar dapat menyebabkan waktu distribusi blok melampaui target 400 ms, terutama saat beban tinggi.

Salah satu tantangan mendesak adalah tahap retransmisi pada Transaction Validation Unit (TVU), yang mendistribusikan shred ke seluruh klaster. Validator besar mendekati 150.000 paket keluar per detik (PPS) karena faktor fanout agresif Turbine sebesar 200 (yaitu, setiap node bertanggung jawab meneruskan shred ke 200 node lainnya). Jika tidak ditangani secara efisien, hal ini dapat menyebabkan penumpukan shred, pergantian leader yang tidak stabil, dan tampilan state yang tidak konsisten di seluruh jaringan.

Untuk mengatasinya, engineer Anza sedang merombak pipeline distribusi blok. Tim saat ini sedang mengerjakan transisi ke XDP (eXpress Data Path), yang memungkinkan kernel dilewati dengan mengekspos penanganan paket secara langsung ke ruang pengguna. Pendekatan ini menghilangkan penyalinan perantara yang mahal sehingga perangkat lunak validator dapat berkomunikasi langsung dengan network interface card (NIC).

Accounts Lattice Hash (ALH)

Untuk mendukung miliaran account, Solana memerlukan pendekatan yang lebih skalabel dalam melakukan hashing terhadap state account global. Accounts Lattice Hash (ALH) yang baru diperkenalkan akan menggantikan hash account berbasis Merkle sebelumnya dengan alternatif yang lebih efisien dan skalabel berdasarkan hashing homomorfik. Metode ini memungkinkan pembuatan hash baru dari hash yang sudah ada tanpa harus menghitung ulang dari awal.

Saat ini, Solana mempertahankan dua hash state account:

• Epoch Accounts Hash (EAH): Root Merkle dari seluruh state account yang dihitung satu kali per epoch.
• Accounts Delta Hash (ADH): Root Merkle dari account yang diubah dalam satu blok dan dihitung ulang pada setiap blok.

Keduanya mengandalkan pengurutan account berdasarkan public key dan pembuatan pohon Merkle, yang menimbulkan tantangan performa serta skalabilitas, terutama seiring bertambahnya kumpulan account. Model hash ganda muncul sebagai kompromi: EAH akurat (mencakup seluruh state account), tetapi jarang dihitung, sedangkan ADH sering dihitung, tetapi hanya sebagian (hanya account yang diubah). Idealnya, setiap blok berisi hash yang lengkap dan terbaru dari seluruh state account tanpa overhead penghitungan ulang pohon Merkle.

Cara Kerja Accounts Lattice Hash

ALH mencapai tujuan ini dengan menggunakan fungsi hashing homomorfik yang memungkinkan pembaruan inkremental. Alih-alih membangun ulang pohon Merkle setiap kali, ALH cukup menambahkan atau mengurangi hash masing-masing account (LtHash) saat account ditulisi. Hasil akhirnya adalah satu hash berukuran 2.048 byte yang merangkum state seluruh account. Yang terpenting, hash ini dapat diperbarui dari blok ke blok tanpa harus dihitung ulang dari awal.

Pendekatan ini menawarkan kompleksitas O(n), peningkatan signifikan dibandingkan kompleksitas O(n log n) pada pohon Merkle. Setiap blok dapat menyertakan hash dari seluruh state account tanpa penghitungan ulang yang mahal.

Integrasi dan Hash yang Dinonaktifkan

Peluncuran ini mencakup tiga SIMD terpisah, masing-masing dengan aktivasi feature gate independen sepanjang siklus rilis Agave 2.2.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: Snapshot menggunakan Accounts Lattice Hash
• SIMD-0223: Menghapus Accounts Delta Hash

Dengan perubahan ini, Accounts Lattice Hash menggantikan ADH dan EAH. ALH akan diintegrasikan ke bank hash setiap blok sehingga hashing state lengkap dapat dilakukan pada frekuensi blok, bukan frekuensi epoch.

Performa dan Kompromi

Peralihan ke ALH memberikan manfaat performa yang besar bagi validator dengan menghapus hashing berbasis Merkle pada setiap blok. Hal ini akan menyederhanakan konsensus dan pembuatan snapshot. Misalnya, validator tidak perlu lagi mengurutkan account atau membangun ulang pohon saat finalisasi blok atau pembuatan snapshot—pembaruan ALH hanya berupa operasi penambahan sederhana.

Namun, pendekatan ini tidak mendukung bukti inklusi atau eksklusi, tidak seperti pohon Merkle atau Verkle. Meskipun hal ini berdampak pada kasus penggunaan verifikasi kriptografis tertentu, seperti klien ringan dan Simple Payment Verification (SPV), kompromi tersebut dianggap sepadan dengan peningkatan efisiensi yang sangat besar. Diskusi mengenai metode alternatif untuk bukti inklusi tersedia di sini.

Integrasi Snapshot

Karena penghitungan Accounts Lattice Hash awal membutuhkan biaya besar, nilai ALH kini disimpan dalam snapshot validator dan dipulihkan saat startup jika tersedia. Snapshot akan menggunakan format ALH yang diperbarui, bukan Snapshot Hash berbasis Merkle, sehingga model penyimpanan dan hashing Solana makin selaras dengan desain baru ini.

Verifikasi Tanda Tangan Secp256r1 Native

Solana menambahkan dukungan native untuk verifikasi tanda tangan kurva eliptik secp256r1, sebuah upgrade penting yang memungkinkan kompatibilitas on-chain dengan Passkeys, standar WebAuthn, dan model abstraksi account tingkat lanjut, termasuk autentikasi dua faktor (2FA). Pembaruan ini menghadirkan autentikasi tanpa kata sandi, yang sudah digunakan secara luas di Web2, ke ranah Web3 sehingga meningkatkan keamanan dan kemudahan penggunaan aplikasi on-chain.

Awalnya dijadwalkan untuk rilis Agave 2.1, fitur ini ditunda hingga 2.2. Untuk informasi selengkapnya, lihat uraian lengkap kami tentang Verifikasi Tanda Tangan Secp256r1 dalam pembaruan Agave 2.1.

Bug Penyelarasan Precompile

Tak lama setelah peluncuran awal Agave 2.2, ditemukan bug kritis dalam implementasi program precompile Secp256r1 dan Ed25519. Bug tersebut terpicu di bawah flag tampilan `--transaction-structure` yang baru, yang mengekspos tata letak transaction mentah tanpa menjamin penyelarasan. Precompile secara keliru mengasumsikan penyelarasan 2 byte untuk data instruksi, yang menyebabkan hasil eksekusi tidak konsisten antara produsen blok dan validator. Hal ini menimbulkan ketidakcocokan bank hash sehingga leader terpaksa membatalkan proses dan menyebabkan hilangnya ketersediaan. Masalah yang pertama kali dilaporkan pada 9 April ini segera diperbaiki pada 11 April. Bug tersebut tidak berdampak pada dana pengguna. Detail selengkapnya tersedia dalam Analisis Akar Masalah yang diterbitkan tak lama setelahnya.

Deployment dan Eksekusi Program SBPFv1, v2, dan v3

Solana Berkeley Packet Filter (SBPF) adalah mesin virtual khusus yang dirancang untuk mengeksekusi program Solana secara efisien dan aman. Ini merupakan fork extended Berkeley Packet Filter (eBPF) berbasis Rust yang awalnya dibuat untuk Linux. 

Upgrade pada Solana Berkeley Packet Filter (SBPF) sangat penting untuk meningkatkan performa, memperkuat keamanan, dan membuka kemampuan baru bagi developer aplikasi. Agave 2.2 membangun fondasi untuk kemudahan pemeliharaan jangka panjang dan peningkatan performa dengan memperkenalkan sistem versioning formal untuk mesin virtual SBPF, yang pertama kali diuraikan dalam SIMD-0161. Perubahan ini memungkinkan deployment dan eksekusi program SBPFv1 (SIMD-0166), SBPFv2 (SIMD-0173, SIMD-0174), dan SBPFv3 (SIMD-0178, SIMD-0179, SIMD-0189). Dengan demikian, terbentuk kerangka kerja berkelanjutan untuk mengembangkan lingkungan eksekusi program secara bertahap tanpa memerlukan deployment ulang di seluruh jaringan.

Hingga saat ini, semua upgrade SBPF harus diperkenalkan melalui feature gate global sehingga evolusi runtime menjadi rumit dan koordinasi deployment nyaris mustahil. Versioning mengatasi masalah ini dengan memisahkan perilaku program dari runtime global, lalu mengaitkannya dengan tag versi per program yang dienkode dalam bidang e_flags pada header file Executable and Linkable Format (ELF). Pendekatan ini memungkinkan hal-hal berikut:

Perilaku runtime yang eksplisit

Setiap program menandai arsitektur set instruksi (yaitu versi SBPF) yang diharapkannya. Berdasarkan versi ini, runtime program akan menyesuaikan perilakunya.

Peluncuran terkontrol

Feature gate akan mengaktifkan deployment dan eksekusi versi SBPF baru secara independen, sekaligus menghapus versi lama secara bertahap. Kumpulan perubahan lengkap digabungkan ke dalam versi SBPF yang berbeda sehingga upgrade menjadi lebih rapi dan mudah dikelola.

Penghentian bertahap

Dukungan untuk versi SBPF lama pada akhirnya dapat dihentikan setelah versi tersebut dinyatakan usang sehingga logika mesin virtual menjadi lebih sederhana. Proses penghentian ini akan berlangsung perlahan agar developer memiliki cukup waktu untuk memigrasikan atau men-deploy ulang program mereka dan beradaptasi dengan versi yang lebih baru.

Diskriminator versi

Saat ini, protokol memperlakukan setiap nilai e_flags selain 0x0020 sebagai SBPF v0, dan hal tersebut valid dalam sistem yang ada. Namun, pendekatan ini tidak skalabel untuk mendukung beberapa versi SBPF dan harus diperbarui.

Setelah feature gate pertama yang mengaktifkan versi SBPF baru diaktifkan, protokol akan mengubah cara interpretasi e_flags dan secara langsung memetakan nilainya ke nomor versi SBPF yang sesuai. Dalam sistem ini, 0x0000 akan mewakili SBPF v0, 0x0001 akan mewakili SBPF v1, dan seterusnya.

Menghapus Pembatasan Pemanggil CPI

Siklus rilis Agave 2.2 mencakup peningkatan yang telah lama dinantikan untuk menghapus batasan historis pada Cross-Program Invocation (CPI). Saat ini, setiap program yang dipanggil melalui CPI harus diteruskan secara eksplisit sebagai account instruksi oleh pemanggil. Hal ini menyebabkan penyusunan transaction yang rumit dan overhead komputasi yang besar, terutama pada CPI yang bertingkat dalam. Namun, batasan ini semata-mata bersifat historis dan tidak diperlukan oleh protokol saat ini.

SIMD-0163 menghapus batasan ini dengan mengizinkan instruksi CPI mereferensikan account program secara langsung dari daftar account tingkat teratas transaction, alih-alih mengharuskan account tersebut diteruskan secara rekursif melalui setiap tingkat pemanggilan. Perubahan ini memberikan manfaat berikut:

• Mengurangi penggunaan CU secara drastis dengan menghindari serialisasi dan deserialisasi account program yang berulang (kecuali program loader-v3 yang menyimpan executable-nya dalam account terpisah), yang sangat mahal karena ukurannya besar (binary ~10 MB).
• Menyederhanakan penyusunan transaction dengan menghilangkan kebutuhan untuk meneruskan account program callee melalui tumpukan instruksi.
• Meningkatkan composability sehingga arsitektur program modular dan bertingkat dalam lebih mudah dibuat.

Kompatibilitas Mundur

Program yang sudah ada tidak akan terpengaruh kecuali ingin memanfaatkan perubahan ini. Jika demikian, program dapat melakukan salah satu hal berikut:

Program yang telah meng-hardcode callee secara statis dan hanya membutuhkannya sebagai account instruksi apa pun untuk memenuhi batasan yang diberlakukan runtime dapat diberi placeholder seperti NativeLoader1111111111111111111111111111111 agar indeks account instruksi lainnya tidak bergeser.

Semua program lain yang sudah ada, yang secara dinamis memanggil apa pun yang diteruskan dalam account instruksi tertentu, harus diperbarui dan di-deploy ulang agar dapat memanfaatkan penghapusan batasan ini.

Optimalisasi ini tidak mengorbankan keamanan. Fitur "delay visibility" memastikan bahwa program tidak dapat memanggil program lain yang ditambahkan, diubah, atau dihapus dalam transaction yang sama.

Loader-v4

Agave 2.2 memperkenalkan dukungan untuk Loader-v4, mekanisme deployment program yang lebih sederhana dan fleksibel untuk menggantikan Loader-v3. Diaktifkan melalui SIMD-0167, Loader-v4 menyederhanakan pengelolaan account program, memperbaiki alur kerja upgrade, dan memperkenalkan fitur keamanan penting untuk program aktif, khususnya yang beroperasi di lingkungan berisiko tinggi seperti DeFi.

Fitur utama Loader-v4:

Model account tunggal: Loader-v4 menghilangkan kebutuhan akan account proxy dan buffer data program terpisah. Kini, satu account mewakili setiap program.

Mode pemeliharaan

Program kini dapat ditempatkan dalam "mode pemeliharaan" yang tidak dapat dieksekusi tanpa ditutup secara permanen atau di-deploy ulang. Hal ini mempertahankan alamat program asli sehingga developer dapat menjeda eksekusi (misalnya jika terjadi eksploitasi) tanpa melepaskan alamat tersebut.

Pengubahan ukuran bebas

Loader-v4 mendukung penambahan maupun pengurangan ukuran binary program setelah deployment sehingga alokasi resource menjadi lebih fleksibel dan dana yang terkunci dapat diperoleh kembali.

Penggunaan buffer opsional

Tidak seperti Loader-v3, yang selalu memerlukan account buffer eksternal untuk deployment ulang, Loader-v4 menjadikan buffer bersifat opsional. Program kini dapat langsung di-deploy ulang ke account program utama sehingga dana yang harus dikunci selama upload berkurang setengahnya.

Deployment ulang parsial

Loader-v3 mengharuskan binary program lengkap di-upload ulang untuk setiap upgrade. Sebaliknya, Loader-v4 mendukung upload parsial sehingga developer hanya perlu melakukan patch pada bagian program tertentu. Hal ini sangat berguna untuk pembaruan kecil.

Migrasi mulus dari Loader-v3

Program yang di-deploy dengan Loader-v3 dapat dimigrasikan ke Loader-v4 tanpa mengubah alamat programnya. Hal ini difasilitasi melalui instruksi Migrate baru di Loader-v3. Tindakan ini akan menunda visibilitas, yang berarti program tidak akan tersedia selama sisa slot saat ini.

Setelah Loader-v4 diaktifkan, feature gate terpisah akan dipicu untuk menonaktifkan deployment baru ke Loader-v3. Program Loader-v3 yang sudah ada akan tetap berfungsi, tetapi seluruh deployment mendatang diharapkan menggunakan Loader-v4.

Saat memfinalisasi program loader-v4, alamat versi berikutnya dapat disarankan, yang berpotensi membentuk linked list. Hal ini menyediakan alternatif untuk men-deploy ulang program dan memungkinkan antarmuka pengguna menawarkan daftar versi program yang telah difinalisasi untuk dipilih pengguna.

Mekanisme pengelolaan otoritas dan penutupan account tetap sama dalam Loader-v4. Semua ini akan tersedia melalui subperintah CLI program-v4 yang baru.

Kesimpulan

Agave 2.2 merupakan tonggak penting bagi protokol Solana karena menghadirkan peningkatan runtime yang krusial dan kemampuan baru yang memperluas batas teknis jaringan. Rilis ini memperkenalkan beberapa perubahan utama: peningkatan kapasitas blok sebesar 20%, integrasi Accounts Lattice Hash (ALH) untuk hashing state yang skalabel, berbagai upgrade pengembangan program, serta dukungan verifikasi tanda tangan Secp256r1 yang sangat penting untuk memungkinkan integrasi kriptografis arus utama. Secara keseluruhan, peningkatan ini menambah throughput, memperbaiki pengalaman developer, dan meningkatkan kemampuan jaringan untuk mendukung cakupan aplikasi yang lebih luas.

Baik Anda membuat program, mengoperasikan validator, maupun berinteraksi dengan jaringan, Agave 2.2 menghadirkan performa, fleksibilitas, dan ketangguhan yang lebih tinggi bagi Solana.

Referensi Lebih Lanjut

• Repositori Klien Agave
• Jadwal Rilis Agave v2.2
• Log Perubahan Agave v2.2
• Pull Request Bertag Agave v2.2