Semua yang Perlu Anda Ketahui tentang Pembaruan v1.17 Solana

Apa yang dibahas dalam artikel ini?

Jaringan Solana telah mencapai tonggak penting dengan adopsi supermayoritas atas 1.17, versi terbaru klien validator Solana Labs. Setelah gangguan jaringan baru-baru ini, validator dimulai ulang menggunakan versi 1.17.20. Saat artikel ini ditulis, ~68,6% validator menjalankan versi 1.17.21, dan ~31,3% menjalankan versi 1.17.20.  Versi baru ini menghadirkan serangkaian peningkatan yang dirancang untuk memperkuat efisiensi, skalabilitas, dan kasus penggunaan jaringan. Mulai dari kemajuan inovatif dalam bukti zero-knowledge hingga penyempurnaan protokol Gossip, v1.17 menandai langkah penting dalam pengembangan Solana yang berkelanjutan.

Artikel ini mencakup semua yang perlu Anda ketahui tentang pembaruan versi 1.17 untuk klien validator Solana Labs. Kita akan membahas ketatnya pengujian v1.17, gangguan jaringan baru-baru ini, dan fitur-fitur baru yang diterapkan melalui pembaruan ini.

Bagaimana v1.17 diuji?

v1.17 telah berjalan di testnet sejak 3 Oktober 2023. Versi ini rutin menjalani uji stres dengan beban transaksi tinggi. Solana Labs juga menerapkan beberapa node canary mainnet-beta yang menjalankan v1.17 untuk memantau stabilitas versi tersebut dalam kondisi dunia nyata. Node-node ini tetap stabil selama beberapa bulan terakhir. Aktivitas dan perkembangan sebelumnya dari node canary ini dapat dilihat dengan mengunjungi kanal #canaries-monitoring di Discord Solana Tech. Selain itu, mulai 4 Desember 2023, sebagian kecil node mainnet-beta sukarela melakukan peningkatan ke v1.17. 

Beberapa fuzzer runtime dikembangkan untuk mengeksekusi transaksi yang diacak sebagian guna menemukan kasus ekstrem atau race condition yang jarang terjadi. Transaksi ini dieksekusi di beberapa versi untuk memastikan performa yang konsisten. v1.17 telah diaudit beberapa kali oleh auditor eksternal, dan hasilnya akan dipublikasikan di repositori GitHub Audit Keamanan Solana setelah tersedia.

Gangguan pada Februari

Pada 6 Februari 2024 pukul 09.53 UTC, mainnet-beta mengalami gangguan yang menghentikan finalisasi blok untuk sementara. Aktivitas jaringan terganggu selama sekitar lima jam hingga konsensus kembali berjalan pada pukul 14.55 UTC. Gangguan ini disebabkan oleh bug terkait cara jaringan mengompilasi dan menyimpan kode program dalam cache untuk dieksekusi, yang secara khusus memengaruhi versi lama program loader.

Penyebab utamanya berasal dari cara validator menangani output terkompilasi Just-in-time (JIT) dari program yang sering digunakan. Sistem caching baru yang dimaksudkan untuk mengoptimalkan proses ini tanpa sengaja menghadirkan bug fatal tersebut. Sistem baru ini dapat memasuki loop kompilasi ulang tanpa batas untuk program lama tertentu. Hal ini menghentikan mekanisme konsensus Solana karena sebagian besar validator mengalami masalah tersebut dan tidak dapat melanjutkan pemrosesan transaksi.

Penyebab utama ditemukan dengan cepat karena bug tersebut memiliki sejumlah kemiripan dengan gangguan devnet baru-baru ini. 1.17.20 dimodifikasi untuk mengatasi masalah secara langsung, lalu para validator mengoordinasikan dimulainya ulang jaringan. Perbaikannya terdiri dari dua bagian: solusi jangka pendek yang menonaktifkan kemampuan untuk memicu loop tanpa batas dengan menghentikan penggunaan dua loader lama yang dapat memicu loop, serta penyesuaian lebih menyeluruh pada sistem caching program baru untuk mencegah masalah serupa di masa mendatang. 

Laporan resmi, yang awalnya diterbitkan oleh Anza, dapat ditemukan di sini.

ZK Token Proof Program

ZK Token Proof Program semula dijadwalkan rilis bersama pembaruan 1.16. Namun, aktivasinya ditunda karena audit ekstensif. Jadwal Aktivasi Feature Gate menandai program tersebut sebagai Menunggu Aktivasi Testnet dengan versi minimum 1.17.12. 

Transfer Rahasia

Dengan aktivasi ZK Token Proof Program, Transfer Rahasia akhirnya akan tersedia. Transfer Rahasia menggunakan bukti zero-knowledge untuk mengenkripsi saldo token dan jumlah transfer bagi token SPL. Tujuan utamanya adalah kerahasiaan, bukan anonimitas. Enkripsi homomorfik memungkinkan komputasi dilakukan pada data terenkripsi tanpa mendekripsinya. Misalnya, saldo dapat ditambahkan atau dikurangi tanpa mendekripsi dan mengenkripsi ulang jumlah yang ditentukan dalam operasi tersebut. Dengan demikian, komputasi ini dienkripsi dengan cara yang sama seperti jika diterapkan pada teks biasa.

Transfer Rahasia menggunakan Twisted ElGamal Encryption dan Sigma Protocols untuk transaksi yang aman dan privat tanpa mengungkapkan informasi sensitif. 

Sebagai catatan tambahan:

• Twisted ElGamal Encryption adalah varian sederhana dari skema enkripsi ElGamal standar, dengan ciphertext dibagi menjadi komitmen Pedersen untuk pesan terenkripsi dan handle dekripsi agar operasi matematika tersembunyi dapat dilakukan pada ciphertext
• Sigma Protocols digunakan untuk memvalidasi Transfer Rahasia. Ini adalah kelas khusus bukti zero-knowledge yang memungkinkan satu pihak (yaitu pembukti) membuktikan kepada pihak lain (yaitu pemverifikasi) bahwa mereka mengetahui informasi tertentu tanpa mengungkapkannya

Transfer Rahasia hanya mengizinkan akun yang memegang kunci dekripsi untuk melihat saldo terenkripsinya. Sistem Auditor Global diterapkan untuk situasi yang memerlukan peninjauan pihak ketiga (misalnya pemeriksaan kepatuhan atau audit). Sistem ini memungkinkan pemegang akun memberikan akses baca selektif ke akun tertentu melalui kunci dekripsi terpisah dan menyertakan “kunci enkripsi auditor” untuk mint guna memfasilitasi audit yang aman.

Transaksi menggunakan parameter terenkripsi untuk jumlah pengirim, penerima, dan auditor beserta bukti untuk memastikan privasi dan integritas. Saldo akun dibagi menjadi “Tertunda” dan “Tersedia” untuk mencegah serangan front-running. Jika tidak, pengguna berbahaya dapat mengirim token ke suatu akun untuk membatalkan bukti yang dibuat menggunakan saldo terenkripsi.

Penting untuk diperhatikan bahwa Transfer Rahasia memerlukan penggunaan pasangan kunci baru. 

Dukungan Baris Perintah

Dukungan Command Line Interface (CLI) untuk Transfer Rahasia melalui crate spl-token juga tersedia. Setelah diaktifkan, perintah create-token diperluas dengan menyertakan flag –enable-confidential-transfers auto. Ini memungkinkan pengguna melakukan mint token dengan ekstensi Transfer Rahasia yang diaktifkan. Tersedia pula sejumlah perintah berguna lainnya, seperti:

• configure-confidential-transfer-account - mengonfigurasi akun yang sudah ada untuk Transfer Rahasia. Hanya pemilik akun yang dapat mengonfigurasi Transfer Rahasia untuk akun tersebut
• deposit-confidential-tokens - menyetorkan token dari akun nonrahasia ke akun rahasia. Perhatikan bahwa token yang disetorkan tidak akan lagi ada dalam saldo nonrahasia akun karena seluruhnya telah dipindahkan ke saldo rahasia
• apply-pending-balance - memindahkan saldo dari “Tertunda” ke “Tersedia.” Ini diperlukan karena setiap kali akun menerima token rahasia dari transfer atau setoran, saldo tersebut muncul dalam saldo “Tertunda” akun. Karena itu, pengguna tidak dapat langsung mengakses dana dan perlu menerapkan saldo tertunda
• transfer (dengan flag –confidential diaktifkan) - mentransfer token ke akun lain yang dikonfigurasi untuk transfer rahasia. Perhatikan bahwa operasi ini dapat memerlukan waktu lebih lama daripada transfer token biasa karena membutuhkan beberapa transaksi yang saling bergantung
• withdraw-confidential-tokens - menarik token dari saldo rahasia akun ke saldo nonrahasianya. Pastikan semua saldo tertunda telah diterapkan sebelum menjalankan perintah ini untuk menarik seluruh token yang diharapkan
• update-confidential-transfer-settings - memperbarui konfigurasi transfer rahasia untuk mint token tertentu. Perintah ini menyediakan opsi untuk menetapkan kebijakan persetujuan transfer rahasia secara otomatis (yaitu flag –aprove-policy) dan menetapkan kunci publik auditor (yaitu flag –auditor-pubkey). Perintah ini juga memiliki flag tambahan untuk menentukan blockhash, otoritas Transfer Rahasia, file konfigurasi, detail pembayar biaya, URL JSON RPC, detail akun nonce, format output, dan ID program token

Kompatibilitas 

Perhatikan bahwa kombinasi ekstensi berikut tidak berfungsi atau tidak masuk akal untuk digabungkan dengan Transfer Rahasia:

• Transfer Rahasia + Tidak dapat ditransfer
• Transfer Rahasia + biaya (tidak akan berfungsi hingga 1.18)
• Transfer Rahasia + Transfer Hooks (karena transfer ini hanya dapat melihat akun sumber atau tujuan sehingga tidak dapat mengambil tindakan berdasarkan jumlah yang ditransfer)

Audit

Transfer Rahasia, dan Token-2022 Program secara umum, telah diaudit secara ekstensif oleh firma seperti Halborn, Zellic, Trail of Bits, NCC Group, dan OtterSec (dua kali—audit pertama berfokus pada Token-2022, sedangkan audit kedua berfokus secara khusus pada Transfer Rahasia).

Syscall Poseidon

Poseidon adalah keluarga fungsi hash yang ramah terhadap bukti zero-knowledge. Fungsi hashing Poseidon digunakan oleh sebagian besar proyek blockchain berbasis ZK, termasuk Zcash, Mina, dan Light Protocol milik Solana. Saat ini, menghitung hash Poseidon di Solana terlalu mahal untuk dilakukan dalam satu transaksi. Syscall Poseidon siap mengubah hal tersebut. Saat ini, syscall ini dijadwalkan rilis bersama v1.17.5 dan menunggu aktivasi testnet.

Penjelasan Sederhana

Bayangkan Anda menggunakan kalkulator canggih yang secara efisien memecahkan jenis teka-teki tertentu untuk komunikasi aman. Kalkulator ini bekerja dengan menerima potongan informasi, memecahnya, lalu mencampurkannya dengan cara yang unik. Informasi tersebut dicampur sedemikian rupa sehingga konten aslinya sepenuhnya tersembunyi, tetapi tetap dapat diverifikasi.

Proses pencampuran ini menggunakan metode khusus yang menjumlahkan angka dan memangkatkannya dengan eksponen tertentu yang termasuk dalam himpunan angka yang telah ditentukan sebelumnya. Metode ini memastikan pencampuran dilakukan secara menyeluruh dan konsisten setiap saat.

Poseidon melakukan hal yang persis sama seperti kalkulator canggih ini. Jenis fungsi hash ini sangat baik untuk membuat sirkuit zero-knowledge. Sirkuit pada dasarnya adalah sekumpulan operasi matematika. Secara matematis, sirkuit menggambarkan satu pihak (pembukti) yang membuktikan kepada pihak lain (pemverifikasi) bahwa mereka mengetahui informasi tertentu tanpa mengungkapkannya. Secara umum, bayangkan Anda membuktikan bahwa Anda mengetahui isi kotak tertutup tanpa benar-benar membukanya. Anda dapat membuktikannya kepada orang yang menyegel kotak melalui serangkaian ketukan atau langkah. Ketukan/langkah ini dirancang agar tidak mengungkapkan detail apa pun tentang isi kotak atau cara membukanya, dan hanya dapat dipahami jika Anda telah membuka kotak tersebut.

Hal ini berguna bagi blockchain karena menjaga privasi transaksi sekaligus tetap dapat memverifikasi keasliannya sangatlah penting. 

Karakteristik yang Ramah ZK

Fungsi hash Poseidon dianggap ramah terhadap zero-knowledge karena beberapa alasan. Di antaranya,

• Poseidon dirancang untuk menjalankan operasi aritmetika yang umum dalam komputasi bukti zero-knowledge (yaitu penjumlahan, perkalian, dan eksponensiasi) secara efisien
• Sistem bukti zero-knowledge perlu mengubah logika komputasi menjadi bukti kriptografis. Desain Poseidon menghasilkan kompleksitas sirkuit yang lebih rendah dibandingkan fungsi hashing lain karena desainnya yang ramah aritmetika, S-box yang dioptimalkan, parameter yang dapat disesuaikan, dan jumlah putaran yang rendah (yaitu urutan operasi yang diterapkan secara iteratif pada data input atau status internal fungsi hash). Artinya, lebih sedikit langkah yang diperlukan untuk menghasilkan bukti bagi suatu data
• Fungsi hash Poseidon didasarkan pada konstruksi spons. Artinya, Poseidon dirancang menggunakan kelas algoritma yang menerima rangkaian bit dengan panjang berapa pun dan menghasilkan output dengan panjang berapa pun. Hal ini membuat fungsi hash Poseidon sangat mudah diintegrasikan ke berbagai aplikasi zero-knowledge.

Perbandingan dengan Fungsi Hashing Tradisional

Efisiensi komputasi Poseidon yang disesuaikan untuk bukti zero-knowledge menawarkan keunggulan tersendiri dibandingkan operasi fungsi hashing tradisional yang lebih umum dan intensif secara komputasi, seperti SHA-256. 

Meskipun aman dan andal, fungsi hashing tradisional sering kali menghasilkan sirkuit yang lebih besar dan kompleks dalam bukti zero-knowledge. Penyebabnya adalah fungsi hashing tersebut sejak awal tidak dirancang dengan mempertimbangkan batasan khusus sistem bukti zero-knowledge. Di blockchain, bukti zero-knowledge menjalankan komputasinya dalam finite field. Finite field adalah himpunan angka tempat semua operasi aritmetika (penjumlahan, pengurangan, perkalian, dan pembagian) dilakukan secara modulo terhadap bilangan prima. Hal ini membuat nilainya “berputar kembali” di dalam himpunan dan memastikan setiap operasi tetap berada dalam himpunan angka tersebut. 

Fungsi hashing tradisional, seperti SHA-256, sangat bergantung pada operasi bitwise dan urutan operasi yang telah ditentukan. Fungsionalitas ini tidak kompatibel secara langsung dengan operasi aritmetika yang digunakan dalam finite field. Penerapan operasi tersebut dalam konteks finite field memerlukan langkah tambahan yang pada akhirnya meningkatkan kompleksitas sirkuit.

Selain itu, fungsi hashing tradisional biasanya menggunakan aritmetika modular berdasarkan pangkat 2. Ini berbeda dari aritmetika modular finite field yang digunakan dalam bukti zero-knowledge, yang sering didasarkan pada bilangan prima. Ketidakcocokan ini memerlukan lebih banyak langkah sehingga meningkatkan ukuran dan kompleksitas sirkuit.

Tujuan pembuatan bukti zero-knowledge adalah membuat representasi matematis dari logika komputasi yang membuktikan pengetahuan atas informasi tertentu tanpa mengungkapkannya. Representasi pengetahuan yang efisien dan sederhana sangat penting bagi skalabilitas bukti ini. Keluarga fungsi hashing Poseidon secara langsung memenuhi kebutuhan tersebut dengan menggunakan operasi yang efisien dalam finite field, sehingga secara signifikan mengurangi langkah pembuatan sirkuit yang diperlukan. Hasilnya adalah sirkuit yang lebih kecil dan tidak terlalu kompleks. Fungsi hashing tradisional tidak disesuaikan untuk memenuhi kebutuhan pembuatan sirkuit secara langsung—fungsi tersebut dirancang untuk tujuan umum. 

Integrasi syscall Poseidon dalam v1.17 menunjukkan peralihan menuju penggunaan alat kriptografis khusus untuk menyederhanakan pembuatan dan validasi bukti zero-knowledge di Solana. Hasilnya adalah pemrosesan transaksi yang lebih cepat, biaya lebih rendah, dan skalabilitas yang lebih baik untuk komputasi zero-knowledge. Ditambah fleksibilitas dan kemampuan penyesuaian Poseidon, pembuatan dan validasi bukti zero-knowledge di Solana menjadi jauh lebih mudah.

Implementasi Spesifik

v1.17 memperkenalkan syscall sol_poseidon—sebuah system call yang menerima input slice byte 2D dan menghitung hash Poseidon yang sesuai sebagai output. Syscall ini menggunakan kurva BN254 dan menerima parameter Poseidon berikut:

• S-box x^5 (yaitu kotak substitusi)
• Input dengan 1 ≤ n ≤ 12
• Lebar dengan 2 ≤ t ≤ 13
• 8 putaran penuh dan putaran parsial bergantung pada t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Penghitungan hash Poseidon ini akan dilakukan dengan crate light-posiedon, yang telah diaudit dan kompatibel dengan Circom. 

Perhatikan bahwa pada bagian berikutnya, kita membahas penambahan syscall alt_bn128. BN254 dalam percakapan sehari-hari disebut BN128 (berdasarkan bit keamanannya) dan alt_bn128 atau alt_bn_128. Di sini, semuanya merujuk pada kurva yang sama.

Syscall alt_bn128

v1.16 mengusulkan dukungan runtime yang lebih baik untuk komputasi zero-knowledge, khususnya operasi kurva eliptik 128-bit. Syscall alt_bn128, yang sangat penting untuk menghasilkan bukti secara efisien, semula dijadwalkan rilis bersama v1.16. Namun, perilisannya ditunda. Jadwal Aktivasi Feature Gate saat ini menjadwalkan syscall alt_bn128 untuk v1.17.15 sambil menunggu aktivasi mainnet-beta, dan kompresi alt_bn128 untuk v1.17.15 sambil menunggu aktivasi testnet.

Sebagai catatan tambahan bagi mereka yang tertarik, alt_bn128 merujuk pada implementasi kurva eliptik Barreto-Naehrig (BN-128). Ini adalah kurva eliptik khusus yang ramah pairing dan memungkinkan zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) yang efisien. Kurva ini dianggap “ramah pairing” karena memungkinkan komputasi dan bukti zero-knowledge tertentu dilakukan secara lebih efisien. Di Solana, syscall alt_bn128 memungkinkan program memanfaatkan kurva ini untuk menyederhanakan verifikasi bukti zero-knowledge serta meningkatkan keamanan dan privasi. Penambahan syscall g1 dan g2 alt_bn128 membantu memfasilitasi kompresi bukti Groth16. Hal ini secara signifikan mengurangi ruang yang diperlukan per bukti dan mengoptimalkan penggunaan ruang untuk program Solana.

Pengenalan syscall alt_bn128 membantu mempersempit kesenjangan kompatibilitas antara Solana dan kontrak berbasis Solidity yang mengandalkan kontrak prakompilasi untuk operasi kurva eliptik yang ditentukan dalam EIP-196, EIP-197, dan EIP-198. Operasi ini (bn256Add, bn256ScalarMult, bn256Pairing) memfasilitasi verifikasi zk-SNARK dalam batas gas Ethereum. Kontrak Solidity yang mengandalkan operasi kurva eliptik ini kini dapat lebih mudah beralih ke atau bahkan berinteroperasi dengan Solana.

Peningkatan Gossip

v1.17 meningkatkan efisiensi propagasi pesan Gossip dengan menyempurnakan propagasi pesan push dan mengurangi ketergantungan pada permintaan pull. Penyederhanaan operasi protokol gossip membantu mengurangi penggunaan sumber daya bagi validator konsensus.

Sebagai konteks, Gossip Service Solana sangat penting untuk pertukaran informasi antarvalidator. Ini mencakup informasi seperti tinggi ledger, detail kontak, dan suara konsensus. Layanan ini menggunakan pesan “push” dan “pull” untuk membagikan serta memverifikasi informasi di seluruh jaringan. Sistem pesan ini memastikan semua node tetap tersinkronisasi. 

Secara tradisional, AccountsHashVerifier mendorong hash akunnya ke gossip. Namun, tidak ada komponen jaringan yang pernah menarik data ini sehingga proses tersebut menjadi redundan. Operasi historis, seperti membandingkan hash akun dari gossip dengan nilai milik validator yang dikenal, telah dihapus setelah diperkenalkannya EpochAccountsHash.  Metode RPC getHealth juga ditulis ulang agar tidak lagi bergantung pada hash akun dari gossip—kita akan membahasnya pada bagian berikut. Karena itu, mulai v1.17, tidak ada lagi yang menarik hash akun dari gossip. AccountsHashVerifier telah dimodifikasi agar berhenti mendorong akun ke gossip, dan fungsi yang bertanggung jawab untuk mendorong serta menarik hash akun dari gossip juga telah dihapus.

getHealth 

Sebelumnya, panggilan RPC getHealth dapat mencerminkan status yang salah untuk node tertentu. Hal ini disebabkan oleh perbedaan antara perintah CLI solana catchup dan panggilan RPC getHealth, yang membuat suatu node dapat terlihat telah mengejar ketertinggalan sekaligus tertinggal. Akibatnya, node yang sehat dapat keliru ditandai sebagai tidak sehat dan berpotensi dihapus dari kumpulan RPC.

Sebelumnya, kesehatan ditentukan dengan membandingkan slot hash akun lokal yang dipublikasikan di gossip dengan milik node lain menggunakan nilai perbandingan default 100 slot. Cara ini bisa tidak akurat, terutama untuk node yang dikonfigurasi dengan nilai lebih dari 100 slot. getHealth telah ditulis ulang untuk menggunakan slot terbaru dari klaster yang dikonfirmasi secara optimistis (yaitu slot terakhir yang telah diproses oleh semua validator dan dikonfirmasi oleh supermayoritas, tetapi belum difinalisasi). Ini memberikan perbandingan yang lebih akurat karena slot yang dikonfirmasi klaster dapat dibandingkan dengan bank terbaru yang dikonfirmasi secara optimistis untuk menentukan seberapa jauh node tertinggal. Perubahan ini menawarkan pemeriksaan yang lebih terperinci, mengurangi kemungkinan negatif palsu (yaitu node sehat yang ditandai tidak sehat), dan memberikan perlindungan terhadap masalah yang memengaruhi validator yang dikenal agar tidak menimbulkan efek domino. 

Flag –skip-health-check juga telah ditambahkan untuk perintah wait-for-restart-window dan exit guna mengatasi masalah pada getHealth. Ini memungkinkan validator melewati pemeriksaan kesehatan node.

QUIC

v1.17 memperkenalkan kemampuan untuk menyiarkan shred dan melakukan perbaikan menggunakan QUIC. Endpoint QUIC Turbine dan perbaikan saat ini dinonaktifkan karena belum diperlukan hingga testnet sepenuhnya bermigrasi ke QUIC. Namun, ini membangun fondasi untuk memigrasikan protokol tersebut ke QUIC. Beberapa PR telah digabungkan untuk memperkenalkan fungsionalitas dasarnya, termasuk:

• Menambahkan eviksi tertunda untuk memperbaiki koneksi QUIC agar jumlah koneksi aktif tidak terus bertambah tanpa batas
• Menambahkan metrik untuk memantau endpoint QUIC Turbine
• Menambahkan metrik untuk memantau perbaikan endpoint QUIC
• Mencegah koneksi QUIC mengalami timeout akibat jarangnya permintaan perbaikan

Koneksi TPU Asinkron

v1.17 memperkenalkan koneksi klien TPU asinkron yang secara signifikan meningkatkan mekanisme cache koneksi. Pembaruan ini dirancang untuk mengurangi latensi transaksi dengan memungkinkan penyiapan koneksi di latar belakang, dengan ukuran kumpulan koneksi default sebanyak empat. Koneksi klien TPU asinkron memastikan pemrosesan transaksi yang lebih lancar tanpa waktu tunggu yang diperlukan pada koneksi sinkron. 

Penyederhanaan Startup Validator dan Pembaruan Format Snapshot

v1.17 menyederhanakan proses startup validator dengan memperkenalkan flag baru dan memperbarui format file snapshot yang didukung. Hasilnya adalah waktu startup validator yang lebih cepat, yang penting karena turut meningkatkan ketahanan jaringan dengan mengurangi downtime.

v1.17 memperkenalkan flag –use-snapshot-archives-at-startup baru. Flag ini memungkinkan validator mempercepat proses startup dengan memilih antara snapshot lokal, status lokal pada disk, atau secara otomatis menggunakan yang paling baru di antara keduanya. Flag ini menghilangkan kebutuhan untuk memproses snapshot ketika status pada disk lebih baru sehingga waktu mulai ulang menjadi lebih cepat.

Sebelumnya, Solana mendukung berbagai format kompresi untuk snapshot—format arsip mencakup bz2, gzip, zstd, lz4, tar, dan tanpa kompresi. Namun, pembaruan terbaru mempersempit pilihan menjadi zstd dan lz4 untuk mengoptimalkan efisiensi dan mengurangi kompleksitas dukungan. Format lainnya telah dihentikan penggunaannya untuk argumen –snapshot-archive-format, meskipun validator masih dapat membaca snapshot lama dalam format tersebut untuk memastikan kompatibilitas mundur. Hal ini secara inheren menyederhanakan command line interface untuk solana-validator dan solana-ledger-tool. 

Kesimpulan

Dengan berbagai implementasi fitur dan penyelesaian cepat atas gangguan jaringan baru-baru ini, pembaruan v1.17 Solana merupakan lompatan besar ke depan. Pembaruan ini menghadirkan dukungan dan kemampuan zero-knowledge yang belum pernah ada sebelumnya melalui perilisan ZK Token Program, syscall Poseidon, dan syscall alt_bn128. Bersama peningkatan pada validator dan efisiensi jaringan, pembaruan ini membangun fondasi kuat untuk pembaruan versi berikutnya. Pembaruan ini lebih kecil daripada v1.16 dan sejalan dengan target perilisan versi baru setiap tiga bulan. Jadwal rilis 1.18 dapat ditemukan di sini.

Jika Anda sudah membaca sejauh ini, terima kasih, anon! Pastikan untuk memasukkan alamat email Anda di bawah agar tidak pernah melewatkan informasi terbaru tentang Solana. Siap mempelajari lebih dalam? Jelajahi artikel terbaru di blog Helius dan lanjutkan perjalanan Solana Anda hari ini.

Sumber Daya Tambahan

• Laporan Gangguan Mainnet Beta Solana 02-06-24
• Jadwal Rilis v1.17
• Poseidon: Hashing yang Ramah ZK
• Akun Twitter Status Solana
• Validator Solana Mengadopsi Pembaruan v1.17