Ringkasan Agave 2.0

Rilis klien validator Agave v2.0 menandai tonggak penting dalam perjalanan Solana menuju ekosistem multi-klien yang lebih kuat. Pembaharuan ini memperkenalkan beberapa perbaikan kritis untuk meningkatkan kinerja, keandalan, dan efisiensi jaringan. Perubahan kunci dalam pembaruan ini termasuk:

‍

• Refaktorisasi kode yang luas dan optimisasi
• Imbalan epoch yang dipartisi
• Memberikan biaya prioritas penuh kepada validator
• Penjadwal pusat baru sekarang secara default aktif
• Program Bukti ZK ElGamal Gate
• Dapatkan-Sysvar Syscall
• GetEpochStake Syscall
• MoveStake dan MoveLamports
• Penghapusan metode RPC yang sudah tidak digunakan lagi
• Penggantian nama peti kemas

‍

Apakah Anda menjalankan validator, membangun di platform, atau aktif menggunakan Solana, tinjauan komprehensif tentang pembaruan Agave 2.0 ini akan memberi Anda wawasan yang diperlukan untuk memahami dan memanfaatkan inovasi terbaru ini.

Apa yang membuat 2.0 menjadi Pembaruan Versi Utama?

Tidak ada lagi 'Solana validator' tunggal. Agave 2.0 merangkul dunia multi-klien baru Solana dan menjadi pemisahan yang jelas dari yang lama Repositori GitHub Solana Labs. Repositori Solana Labs akan diarsipkan, dan permintaan pull atau masalah baru tidak akan lagi diterima. Sebelumnya, repositori ini mencerminkan aktivitas dari repositori Agave. Pengembang sebaiknya memindahkan semua aktivitas keRepositori Anza Agave GitHubjika mereka belum melakukannya. TheProses migrasi Solana Labs ke Agavedimulai pada 1 Maret dan secara publik dilacak di GitHub mereka.

‍

Seiring berkembangnya ekosistem, operator harus beradaptasi untuk menjalankan satu atau lebih klien. Setelah pergeseran ini, beberapa peti diganti namanya, membersihkan namespace untuk mendukung beberapa klien — terutama Firedancer — yang dikelola oleh tim pengembang independen. Peti yang dikelola oleh Anza sekarang akan diawali dengan "agave," membuatnya mudah diidentifikasi sebagai dependensi khusus Anza dalam lingkungan multi-klien.

‍

‍

Kotak yang terpengaruh adalah:

‍

solana-validator, solana-ledger-tool, solana-watchtower, solana-install, solana-geyser-plugin-interface, solana-cargo-registry

‍

Seperti yang dijelaskan dalam kamipanduan transisi sebelumnya, pembaruan 2.0 memperkenalkan beberapa perubahan yang signifikan, terutama menghapus beberapa endpoint yang sudah usang dan usang—update kunci yang harus diketahui oleh semua pengembang Solana saat ini. Rincian lengkap perubahan RPC disertakan pada akhir artikel ini.

Pengguliran Fitur

Saat ini, sekitar 20,7% validator menjalankan versi 2.0.14. Aktivasi gerbang fitur pada mainnet sementara dihentikan untuk memungkinkan adopsi v2.0 lebih sejalan dengan aktivasi pada testnet dan devnet. Setelah cluster mainnet secara luas mengadopsi v2.0, aktivasi gerbang fitur diharapkan dapat dilanjutkan sesuai denganperintah aktivasi terjadwal.

‍

Fitur lengkap baru yang dibahas dalam bagian-bagian berikut ini saat ini belum aktif dan akan secara bertahap diperkenalkan selama siklus 2.0 menggunakan sistem gate fitur. Fitur-fitur diaktifkan pada epoch tertentu berdasarkan prioritas relatif dan urutan di mana mereka diaktifkan pada cluster testnet dan devnet.

‍

Reward Full Priority Fee untuk Validator

Ini sangat dinanti-nantikan danpembaruan ekonomi yang banyak diperdebatkansedang diimplementasikan mengikuti proposal,SIMD-0096, yang melalui pemungutan suara tata kelola validator pada bulan Mei. Pemungutan suara tersebut berakhir pada akhir epoch 620, dengan 51,17% dari total staking berpartisipasi dan 77,77% memberikan suara mendukung. Pembaruan yang digembok fitur ini akan mengubah secara fundamental penanganan jaringanbiaya prioritas. Alih-alih model saat ini, yang membagi biaya dengan 50% terbakar dan 50% diberikan kepada validator, model baru akan mengalokasikan 100% biaya prioritas langsung kepada validator.

Di atas: Biaya prioritas mingguan Solana dalam nilai USD (sumber)

‍

Meskipun biaya prioritas secara teknis opsional, mereka telah menjadi praktik standar seiring meningkatnya aktivitas ekonomi di Solana. Biaya ini dihitung dalam mikro-lamport (jutaan lamport) per unit komputasi menggunakan rumus:

‍

prioritization fee = harga unit komputasi (mikro-lamports) x batas unit komputasi

‍

Maju ke depannya, semua biaya prioritas akan diberikan kepada produsen blok. Ini menciptakan keterikatan insentif yang lebih kuat dan mengurangi kemungkinan validator terlibat dalam pengaturan di luar protokol untuk inklusi transaksi, yang menjadi masalah di masa lalu.

‍

Meskipun penghapusan biaya pembakaran sedikit meningkatkan tingkat inflasi bersih SOL, penerbitan token baru melalui hadiah staking memiliki dampak yang jauh lebih signifikan. Pembaca dapat merujuk ke posting blog Helius kami sebelumnya mengenaiJadwal penerbitan dan inflasi Solanauntuk pembagian yang lebih rinci dari dinamika-dinamika ini.

‍

Bagian Hadiah Epoch

Imbalan masa transisi yang dipartisibertujuan untuk mendistribusikanimbal hasil stakingmelintasi beberapa blok, mengurangi masalah kinerja yang terkait dengan konsentrasi distribusi imbalan dalam blok pertama setiap epoch baru. Engsel utama dalam proses ini adalah kebutuhan untuk menulis pembaruan kembali ke jumlah akun staking aktif yang terus bertambah di jaringan, yang kini totalnya sekitar 1,4 juta. \

Dalam pendekatan baru ini, komputasi dan distribusi hadiah staking pada batas epoch akan dibagi menjadi dua fase yang berbeda:

‍

• Fase Perhitungan Reward: Pada fase ini, reward epoch untuk semua akun staking aktif dihitung, dan distribusinya dibagi menjadi bagian-bagian yang terjadwal.
• Fase Distribusi Hadiah: Hadiah epoch yang telah dihitung sebelumnya untuk akun taruhan aktif didistribusikan sesuai dengan yang seharusnya.

‍

Untuk memfasilitasi dan memantau proses, sebuah akun Sysvar, EpochHadiah, akan melacak dan memverifikasi distribusi hadiah sepanjang fase distribusi. EpochRewards Sysvar mencatat apakah fase distribusi hadiah sedang berlangsung dan informasi yang diperlukan untuk melanjutkan distribusi saat memulai dari snapshot.

Perhitungan Hadiah

Perhitungan hadiah akan dilakukan pada blok pertama zaman. Setelah dihitung, hadiah dibagi menjadi potongan distribusi yang disimpan di bank, yang akan didistribusikan selama fase distribusi hadiah.

‍

Untuk meminimalkan dampak pada waktu pemrosesan blok selama fase distribusi hadiah dan untuk memastikan bahwa setiap blok mendistribusikan subset hadiah secara deterministik, target 4.096 hadiah taruhan akan didistribusikan per blok. Untuk melindungi dari pertumbuhan dramatis dalam jumlah akun taruhan, jumlah blok dibatasi pada 10% dari total slot dalam satu zaman. Hanya jika batas blok ini tercapai, akun per partisi diizinkan untuk melampaui target 4.096.

Distribusi Hadiah

Distribusi hadiah dimulai segera setelah fase perhitungan hadiah, dimulai dari blok kedua pada epoch. Distribusi hadiah terjadi di bagian atas blok sebelum pemrosesan transaksi normal.

‍

Akibatnya, pengguna dapat melihat reward dikreditkan ke akun stake mereka beberapa blok lebih lambat dari sebelumnya. Namun, pengalaman keseluruhan tetap sama, karena waktu blok pertama yang berkepanjangan di batas zaman sebelumnya menunda akses pengguna ke akun staking. Manfaat tambahan dari pendekatan ini adalah bahwa transaksi non-staking dapat terus diproses dengan lancar, sedangkan sebelumnya, mereka diblokir selama distribusi hadiah.

‍

Karena jumlah akun suara yang relatif rendah, sekitar 1.500, mekanisme yang ada untuk mendistribusikan imbalan suara pada blok pertama batas epoch akan tetap tidak berubah. Hanya imbalan staking yang akan didistribusikan lebih dari satu blok.

‍

Central Scheduler Sekarang Aktif Secara Default

Diperkenalkan pertama kali sebagai rilis fitur dalam pembaruan v1.18, penjadwal pusat, sebelumnya dikenal sebagai “penjadwal,” tidak diaktifkan secara default dan harus diaktifkan oleh operator menggunakan —flag metode-produksi-block central-scheduler saat memulai validator. Sekarang sudah diaktifkan secara default. Implementasi penjadwal sebelumnya memiliki beberapa isu yang dapat memengaruhi kinerja secara negatif. Engkelan dalam pemrosesan transaksi seringkali menyebabkan jitter atau ketidakkonsistenan dalam penentuan urutan dan prioritas transaksi.

‍

Implementasi baru menggantikan model sebelumnya dari empat thread perbankan independen, masing-masing mengelola prioritas dan pemrosesan transaksi sendiri. Dalam struktur yang direvisi ini, penjadwal pusat adalah satu-satunya penerima transaksi dari tahap SigVerify TPU. Ini membangun antrian prioritas dan menggunakan grafik dependensi, yang dikenal sebagai prio-graph, untuk mengelola pemrosesan dan prioritas transaksi yang saling bertentangan. Desain penjadwal baru ini meningkatkan skalabilitas dan fleksibilitas, memungkinkan peningkatan jumlah thread tanpa kekhawatiran konflik kunci yang meningkat sebelumnya. Peluncuran awal penjadwal pusat telah terbukti menghasilkan imbalan yang lebih baik, sehingga meningkatkan pendapatan bagi banyak operator. Posting Helius kami sebelumnya tentang pembaruan Solana v1.18 mencakup secara lengkapbagaimana penjadwal pusat bekerja.

‍

Program ZK ElGamal Proof

Program Token Proof ZK, yang awalnya direncanakan untuk disertakan dalam rilis 1.17, kini sudah tidak digunakan lagi dan akan digantikan oleh yang lebih serbaguna, independen aplikasiProgram Bukti ZK ElGamal. Program Bukti ZK ElGamal baru ini mempertahankan bagian-bagian dari program Bukti Token ZK yang berlaku secara luas di berbagai aplikasi, seperti memverifikasi validitas kunci publik atau rentang nilai yang dienkripsi dalam sebuah ciphertext ElGamal. Namun, program ini menghilangkan elemen-elemen yang khusus untuk aplikasi, seperti validasi bukti pengetahuan nol yang diperlukan untuk instruksi transfer Token SPL. Program Bukti ZK ElGamal baru ini akan dimasukkan ke dalam daftar program bawaan pada alamat ZkE1Gama1Proof11111111111111111111111111111.

‍

Untuk mempelajari lebih lanjut tentang Program Bukti Token ZK, bacatulisan asli di blog Helius.

Dapatkan-Sysvar Syscall

Syscalls, atau pemanggilan sistem, meminta layanan dari kernel sistem operasi. Dalam konteks Solana, sebuah Syscall memungkinkan program yang berjalan dalam Mesin Virtual Solana (SVM) untuk berinteraksi dengan sumber daya dan layanan eksternal.

‍

Sysvars mengekspos informasi status klaster, seperti hash blok terbaru dan imbalan epoch. Akun-akun ini diisi di alamat-alamat yang diketahui. Program-program dapat mengakses Sysvars melalui akun Sysvar atau mengajukan pertanyaan pada mereka melalui sebuah Syscall. Program-program on-chain menggunakan banyak Sysvars untuk berbagai kasus penggunaan, dan beberapa Sysvars tertentu sangat penting untuk operasi jaringan.

‍

Syscall Get-Sysvar, yang awalnya diusulkan dalamSIMD-127 oleh insinyur Anza Joe Caulfield, memperkenalkan antarmuka Syscall yang terpadu untuk mengakses data Sysvar. Pembaruan ini memungkinkan pengambilan data Sysvar yang sebelumnya tidak dapat diakses, termasuk SlotHashes dan StakeHistory. Dengan antarmuka baru ini, pengembang dapat mengakses fragmen khusus data Sysvar - seperti memanggil SlotHashes::get_slot(slot)danStakeHistory::get_entry(epoch)—tanpa perlu menggandakan seluruh struktur data.

‍

Pembaruan juga meminimalkan overhead saat memodifikasi tata letak data Sysvar atau menambahkan Sysvar baru. Sebelumnya, setiap Sysvar baru memerlukan penambahan Syscall yang sesuai, menciptakan hubungan yang digabungkan erat yang menggelembungkan antarmuka Syscall dari waktu ke waktu dan pemeliharaan yang rumit. Sekarang, satu sol_get_Sysvar Syscall akan melayani semua antarmuka Sysvar, memungkinkan pengambilan data yang konsisten dan efisien dari Sysvar mana pun.

‍

Memperkenalkan Syscall baru menyederhanakan proses memodifikasi dan menambahkan Sysvar baru. Ini secara signifikan mengurangi kompleksitas dan persyaratan pemeliharaan antarmuka Syscall. Selain itu, pembaruan ini membuka jalan untuk memperluas akses program BPF ke data Sysvar, memungkinkan program on-chain untuk membaca lebih lanjut informasi Sysvar tanpa mempengaruhi ukuran transaksi.

‍

GetEpochStake Syscall

Baru GetEpochStake Syscall akan memperkenalkan fitur yang sangat diminta untuk mengambil saham yang didelegasikan akun suara untuk zaman saat ini, menyediakan metode langsung yang lebih efisien untuk mengambil informasi ini secara on-chain.

‍

Saat ini, program tidak dapat mengakses data secara real-time tentang delegasi kepemilikan pada akun suara tertentu untuk epoch saat ini, menciptakan hambatan untuk kasus penggunaan seperti pengelolaan validator dan mekanisme konsensus sekunder. Memungkinkan kueri on-chain terhadap data ini akan membuka aplikasi-aplikasi ini dan membuka jalan bagi kasus penggunaan di masa depan.

‍

Dengan GetEpochStake, pengembang memberikan alamat akun suara 32-byte, dan syscall akan mengembalikan bilangan bulat u64 yang mewakili total saham aktif yang saat ini didelegasikan ke akun suara tersebut. Jika alamat yang diberikan tidak sesuai dengan akun suara yang valid atau tidak ada, Syscall hanya akan mengembalikan 0.

‍

MoveStake dan MoveLamports

Dua instruksi program staking baru, MoveStake dan MoveLamports, diperkenalkan untuk memfasilitasi transfer nilai antar akun taruhan. Instruksi ini, pertama kali diusulkan dalamSIMD-0148, membantu pengembang dengan memungkinkan perpindahan dana antara akun dengan otoritas yang cocok tanpa kontrol otoritas penarik.

‍

Sebelumnya, protokol yang mengelola taruhan pengguna menghadapi tantangan ketika membagi taruhan di antara beberapa validator dan secara teratur mere delegasikan mereka. Ketika protokol membagi taruhan pengguna untuk dinonaktifkan, ia harus membiayai lamports pengecualian sewa untuk akun baru. Protokol tidak dapat mengklaim lamports pengecualian sewa saat menggabungkan akun-akun terpisah ini.

MoveStake: Instruksi ini memungkinkan staking aktif untuk dipindahkan antara akun, mentransfernya dari satu akun aktif ke akun lainnya atau dari akun aktif ke akun tidak aktif, dengan demikian mengaktifkan kembali akun tersebut. Jika seluruh delegasi akun sumber dipindahkan, akun sumber menjadi tidak aktif. Saldo yang terbebas dari biaya sewa tetap tidak terganggu dalam semua skenario, dan aturan delegasi minimum tetap dipertahankan untuk akun-akun aktif.

‍

MoveLamports: Memindahkan lamport yang berlebihan dari satu akun aktif atau tidak aktif ke akun aktif atau tidak aktif lainnya, di mana "lamport yang berlebihan" mengacu pada lamport yang tidak diwakilkan oleh staking atau diperlukan untuk pembebasan sewa. MoveLamports memungkinkan tugas-tugas rumah tangga seperti mendapatkan kembali lamport dari akun yang digabungkan dan mengonsolidasikan dana yang tidak digunakan.

‍

Untuk menyederhanakan penerapan, perubahan ini tidak mendukung pengaktifan atau penonaktifan akun atau memengaruhi akun taruhan yang aktif sebagian. Instruksi program baru ini tidak mengubah fungsionalitas yang ada.

‍

Bonus: Kotak Solana-SVM

Dengan rilis Agave 2.0 datang sebuahkeranjang solana-svm barumenawarkan akses langsung bagi pengembang ke komponen inti SVM melalui API yang disederhanakan independen dari kerangka validator lengkap. Ini membuka akses ke pemrosesan transaksi berkinerja tinggi Solana untuk aplikasi di luar validator, seperti layanan off-chain, klien ringan, saluran keadaan, dan rollup.

‍

Dengan memisahkan API dari bagian lain runtime, kemasan ini menghilangkan kebutuhan untuk komponen seperti instance Bank, mengurangi beban operasional. Pengembang sekarang dapat memanfaatkan komponen yang tangguh yang mendukung mainnet-beta Solana untuk membangun proyek SVM kustom seperti klien ringan, saluran keadaan, rollup, dan layanan di luar rantai. Inti dari API ini adalah struct TransactionBatchProcessor, yang memungkinkan aplikasi untuk memproses batch transaksi Solana yang disanitasi dengan paket lengkap komponen downstream Agave, termasuk BPF Loader, eBPF, dan mesin virtual.

‍

Di atas: pemroses batch transaksi (sumber gambar: Anza)

‍

Baca penjelasan mendalam tentangAPI SVM Baru Anzauntuk detail lengkap tentang perkembangan menarik ini.

‍

Menghapus Titik Akhir RPC

Beberapa titik akhir v1 Agave RPC yang sudah tidak digunakan dan sudah usang telah dihapus. Tim Helius Devrel telah menghubungi semua pelanggan yang menggunakan titik akhir ini. Melalui analisis internal, kami sebelumnya telah mengidentifikasi sekelompok kecil pelanggan yang aktif menggunakan titik akhir berikut, yang akan dihapus:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Sekali lagi, kami sangat menyarankan semua pengembang untuk memeriksa referensi ke panggilan ini dan memperbarui dengan penggantian yang disarankan.

‍

Di atas: daftar lengkap titik akhir RPC Agave v1 yang sudah usang dan sudah tidak digunakan yang akan dihapus

‍

N.B. Pendekatan alternatif untuk mendapatkan Informasi Akun yang ditunjukkan dalam gambar dapat menjadiditemukan di sini.

‍

Perubahan yang merusak SDK termasuk:

‍

• Dukungan untuk Borsh v0.9 dihapus, silakan gunakan v1 atau v0.10 (#1440)
• Sifat salinan tidak lagi diturunkanpada Sewa dan EpochSchedule; beralih ke menggunakan clone()
• solana-sdk: simbol yang tidak direkomendasikan) dihapus
• solana-program: simbol yang tidak digunakan lagi dihapus

‍

Untuk operator validator, beberapa argumen validator yang sudah tidak digunakan akan dihapus pada rilis Agave v2.0. Daftar lengkapnya dapat ditemukandi sini.

‍

Kesimpulan

Pembaruan Agave 2.0 menandai kemajuan signifikan bagi Solana, dengan menggabungkan banyak implementasi fitur dan optimalisasi runtime. Rilis ini terus mendorong batasan dengan Syscalls baru yang kuat, fungsionalitas yang diperluas, dan perawatan yang komprehensif, termasuk perubahan nama crate, penghapusan metode RPC yang tidak digunakan lagi, dan argumen validator yang disederhanakan. Agave 2.0 memperluas kemampuan Solana dan menyempurnakan kinerjanya serta kegunaannya. Baik Anda seorang pengembang, validator, atau pengguna aktif, pembaruan Agave 2.0 membuka peluang baru yang menarik untuk semua orang di ekosistem Solana.

‍

Sumber Daya Tambahan / Bacaan Lebih Lanjut

• Jadwal Rilis Agave v2.0
• Agave v2.0 Catatan Perubahan
• Versi Rilis Agave

Disclaimer：

1. Artikel ini dicetak ulang dari [helius)]. Semua hak cipta milik penulis asli [Tersesat]. Jika ada keberatan terhadap cetakan ulang ini, silahkan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Learn gate. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.