Pembaruan Agave 4.4: Semua yang Perlu Anda Ketahui

Pendahuluan

Dengan Agave 4.4, klien validator inti Solana melanjutkan peluncuran Alpenglow, menyederhanakan validasi blok, merampingkan penghitungan imbalan staking, dan mengurangi jumlah SOL yang diperlukan untuk menyimpan program serta data akun. Perubahan ini meningkatkan efisiensi operasional sehari-hari sekaligus memperkuat fondasi untuk eksekusi asinkron. Pengurangan target waktu slot menjadi 200 ms baru-baru ini memangkas durasi epoch menjadi sekitar satu hari, sehingga aktivasi feature gate dapat dilakukan dengan frekuensi yang lebih tinggi.

Pembaruan Penting dalam Siklus Rilis Agave 4.4

• Mengizinkan Pembayar Biaya yang Tidak Valid: Langkah penting menuju penerapan eksekusi asinkron
• Pengubahan Ukuran Program Otomatis: Mengembalikan kelebihan biaya sewa selama peningkatan program
• Standardisasi Shred: Protokol kini memberlakukan set FEC dengan 32 data dan 32 coding
• Pembersihan Stake Tidak Aktif: Mengecualikan stake tidak aktif dari penghitungan imbalan
• Pengurangan Biaya Sewa: Tiga tahap terakhir yang direncanakan dari pengurangan deposit state sebesar 90%

Mengizinkan Pembayar Biaya yang Tidak Valid

Aktivasi feature gate SIMD-0290: Melonggarkan Batasan Pembayar Biaya diperkirakan mulai berlaku selama siklus rilis Agave 4.4. Ini mengubah apa yang terjadi ketika sebuah blok berisi transaksi dengan pembayar biaya yang gagal divalidasi, misalnya karena jumlah SOL tidak mencukupi. Sebelumnya, penyertaan transaksi semacam itu membuat seluruh blok tidak valid. Berdasarkan aturan konsensus baru, transaksi tetap berada di dalam blok dan validator melewati eksekusinya tanpa mengubah state akun.

Saldo pembayar biaya dapat berubah ketika transaksi sebelumnya dieksekusi. Karena itu, persyaratan bahwa setiap transaksi harus memiliki pembayar biaya yang valid mengharuskan validator mengeksekusi beberapa transaksi sebelumnya sebelum dapat menentukan validitas suatu blok. Memperlakukan kegagalan pembayar biaya sebagai transaksi yang dilewati menghilangkan dependensi khusus ini.

Ini menjadi fondasi bagi eksekusi asinkron, yang memungkinkan validator menyepakati blok dan urutan transaksi sebelum menyelesaikan eksekusi. Eksekusi berlangsung secara terpisah dengan menerapkan transaksi yang telah disepakati ke state akun. Solana bergerak menuju desain ini untuk mendukung peningkatan mendatang, seperti waktu blok yang lebih singkat dan beberapa pengusul blok secara bersamaan.

Agave merepresentasikan transaksi yang dilewati ini sebagai no-op: transaksi tersebut tidak mengeksekusi instruksi dan tidak membayar biaya. Transaksi ini tetap menggunakan kapasitas blok sesuai seluruh anggaran resource yang diminta atau anggaran default, sehingga membatasi jumlah yang dapat disertakan oleh leader. Implementasinya juga mempertahankan kemampuan leader untuk memfilternya selama produksi blok, meskipun validator dapat menerimanya saat memutar ulang blok.

SIMD-0290 berlaku secara khusus untuk transaksi yang menggunakan blockhash terbaru sebagai penentu masa berlakunya. Transaksi durable nonce memerlukan penanganan tambahan, yang dibahas secara terpisah dalam SIMD-0297: Melonggarkan Batasan Transaksi Nonce yang Tidak Valid. Perubahan ini sepenuhnya kompatibel dengan versi sebelumnya, sehingga semua transaksi dan blok yang sebelumnya valid tetap valid.

Mengubah Ukuran Program Secara Otomatis saat Peningkatan

Agave 4.4 akan menyertakan aktivasi feature gate untuk SIMD-0433: Loader V3: Menetapkan Data Program Sesuai Panjang ELF, yang membuat proses peningkatan program secara otomatis mengubah ukuran akun tempat kode program yang telah dikompilasi disimpan.

Loader v3 (yaitu loader default saat ini untuk menerapkan dan meningkatkan program Solana) menyimpan biner ELF program yang telah dikompilasi dalam akun ProgramData, bersama metadata seperti otoritas peningkatannya. Sebelumnya, developer hanya dapat memperbesar akun ini, tetapi tidak dapat memperkecilnya. Karena itu, peningkatan ke biner yang lebih kecil menyisakan ruang yang tidak terpakai, sementara SOL yang diperlukan agar ruang tersebut tetap bebas sewa terus terkunci di dalam akun.

Dengan perubahan ini, instruksi Upgrade mengubah ukuran akun agar sesuai dengan header metadata ditambah panjang ELF baru. Biner yang lebih kecil melepaskan kelebihan lamport ke akun spill peningkatan, yaitu penerima yang ditetapkan untuk dana tersisa. Biner yang lebih besar secara otomatis memperluas akun, sehingga tahap perluasan terpisah tidak lagi diperlukan untuk peningkatan biasa. Akun ProgramData dan akun buffer harus sudah memiliki lamport yang cukup untuk memenuhi persyaratan sewa baru; jika tidak, peningkatan akan gagal.

Dengan demikian, developer yang menggunakan biner lebih kecil dapat memperoleh kembali SOL saat melakukan peningkatan berikutnya. Kapasitas cadangan yang sebelumnya dialokasikan juga akan dihapus. Untuk peningkatan yang dipanggil melalui CPI, batas pertumbuhan akun sebesar 10 KiB tetap berlaku: peningkatan yang lebih besar memerlukan perluasan terlebih dahulu atau instruksi peningkatan tingkat teratas. Developer harus memeriksa tujuan akun spill sebelum melakukan peningkatan untuk memastikan pengembalian dana diterima oleh pihak yang dituju.

Perubahan ini mendorong developer untuk meningkatkan ke library dan framework yang lebih baru serta lebih berperforma tinggi, seperti Pinocchio. Perubahan ini juga mengurangi ruang yang digunakan program di Accounts DB.

Standardisasi Shred

Agave 4.4 memperketat aturan propagasi blok Solana yang diuraikan dalam SIMD-0317: Memberlakukan 32 Data + 32 Coding Shred. Perubahan ini menstandardisasi struktur yang digunakan validator untuk mendistribusikan dan merekonstruksi data blok.

Solana mendistribusikan blok melalui Turbine, yang membagi data blok menjadi shred dan meneruskannya melalui beberapa lapisan validator. Shred dikelompokkan ke dalam set forward error correction (FEC), yang menggabungkan shred data dengan shred coding berisi informasi pemulihan. Dengan set 32 data dan 32 coding yang disusun dengan benar, penerima dapat merekonstruksi data asli dari 32 shred mana pun di antara total 64 shred, sehingga membantu mengatasi kehilangan paket.

Setiap shred juga membawa bukti Merkle yang menghubungkannya ke root Merkle set tersebut, yang diautentikasi dengan tanda tangan leader. Untuk set berisi 64 shred, bukti tersebut memiliki enam entri, sesuai dengan enam tingkat antara leaf dan root. Pemeriksaan ukuran bukti Agave mensyaratkan ukuran yang sesuai dengan struktur tetap 32:32 ini.

Klien saat ini sudah menghasilkan 32 shred data dan 32 shred coding per set, tetapi validator penerima secara historis menerima konfigurasi yang lebih fleksibel. SIMD-0317 menutup kesenjangan tersebut dengan menjadikan struktur tetap 32:32 sebagai persyaratan protokol. Ini menyederhanakan validasi: penerima dapat menentukan batas indeks shred yang valid tanpa menunggu shred coding untuk mengungkapkan dimensi set.

Struktur tetap ini juga menyederhanakan deteksi ekuivokasi, yaitu ketika leader mendistribusikan versi yang saling bertentangan dari data yang sama. Dua shred yang termasuk dalam set FEC yang sama, tetapi memiliki root Merkle berbeda dan tanda tangan leader yang valid, menjadi bukti konflik tersebut. Dengan demikian, standardisasi format mengurangi kompleksitas implementasi sekaligus mempermudah identifikasi ekuivokasi.

Menghapus Stake Tidak Aktif dari Penghitungan Imbalan

Siklus rilis Agave 4.4 akan mencakup aktivasi feature gate untuk SIMD-0599: Menghapus Stake Tidak Aktif dari Delegasi Stake, yang menyederhanakan cara validator menangani akun stake tidak aktif selama pembagian imbalan epoch pada awal setiap epoch. Akun stake tidak aktif dapat menyimpan SOL di atas saldo minimum bebas sewa, tetapi tidak memiliki stake aktif atau yang sedang diaktifkan. SOL di dalamnya tidak didelegasikan atau telah sepenuhnya menyelesaikan proses deaktivasi.

Akun ini tidak memperoleh imbalan protokol, tetapi penyertaannya dapat memengaruhi jumlah partisi distribusi imbalan dan lattice hash yang digunakan untuk melacak state akun. Setiap klien validator harus mereproduksi perilaku ini secara presisi, sehingga menambah kompleksitas yang tidak diperlukan pada kode kritis bagi konsensus.

Perubahan ini mengecualikan stake yang tidak aktif selama epoch yang menerima imbalan, tetapi tetap menyertakan stake yang sedang diaktifkan, aktif, dan sedang dinonaktifkan. Dengan demikian, akun stake yang menjadi tidak aktif pada awal epoch baru tetap menerima imbalan yang diperoleh selama epoch sebelumnya ketika stake tersebut sedang dinonaktifkan.

Pengurangan Biaya Sewa Lebih Lanjut

Agave 4.4 diperkirakan menghadirkan tiga aktivasi terakhir dalam pengurangan biaya sewa Solana secara bertahap. Berdasarkan rencana dalam SIMD-0437, saldo minimum yang diperlukan per byte penyimpanan akun turun dari nilai awal 6.960 lamport menjadi 696 dalam lima tahap (yaitu pengurangan sebesar 90%).

Setiap aktivasi memiliki feature gate sendiri, sehingga jaringan dapat menilai dampaknya terhadap pembuatan akun dan pertumbuhan state sebelum melanjutkan.

Penurunan persyaratan ini mengurangi modal yang harus dialokasikan developer dan pengguna saat membuat akun token, PDA, serta state onchain lainnya. Ini sangat berguna bagi aplikasi yang mendanai pembuatan akun untuk pengguna, seperti layanan pembayaran berskala besar.

Estimasi dari Ghost menunjukkan bahwa lebih dari 3 juta SOL (~$300 juta) dapat ditarik kembali. Sejumlah alat telah dikembangkan untuk membantu pengguna memperoleh kembali kelebihan SOL dari akun mereka.

Kesimpulan

Perubahan utama Agave 4.4 melanjutkan fondasi Alpenglow sekaligus menghadirkan peningkatan yang telah lama dinantikan pada imbalan staking, penerapan program, dan biaya akun. Bersama-sama, perubahan ini meneruskan upaya Solana untuk membangun jaringan yang lebih cepat dan lebih mudah diakses. Berikutnya adalah Breakpoint London, disusul Agave 4.5.

Referensi Lebih Lanjut

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