Semua yang Perlu Anda Ketahui Tentang Pembaruan v1.16 Solana

Apa yang dibahas dalam artikel ini?

Jaringan validator Solana telah berhasil mencapai supermayoritas dalam adopsi versi 1.16, peningkatan terbaru untuk klien validator Solana Labs. Setelah periode audit menyeluruh yang didukung oleh upaya khusus para sukarelawan dan node canary, pencapaian ini menjadi puncak dari hampir sepuluh bulan pengembangan intensif.

Pada bagian berikut, kita akan membahas cara v1.16 diuji serta sistem gerbang fitur Solana, yaitu kerangka kerja yang mengatur penerapan fitur baru secara bertahap ke jaringan. Setelah itu, kita akan melihat fitur-fitur baru yang diimplementasikan dalam v1.16.

Bagaimana v1.16 diuji?

v1.16 telah menjalani pengujian ketat selama beberapa bulan terakhir. Rilis v1.16 telah berjalan di testnet sejak 7 Juni 2023 dan telah melewati berbagai stress test. Selain itu, sekelompok kecil node sukarelawan mulai memperbarui ke v1.16 pada 23 Agustus 2023. Para sukarelawan ini berhasil mengidentifikasi dan mengatasi berbagai masalah, seperti proses startup yang lambat untuk node RPC serta general protection fault. Solana Labs juga menerapkan beberapa node canary ke mainnet-beta. Langkah ini dilakukan untuk memantau stabilitas node v1.16 dalam kondisi dunia nyata. Untuk melihat aktivitas dan progres sebelumnya dari node canary tersebut, kunjungi kanal #canaries-monitoring di Discord Solana Tech.

Untuk menemukan kasus ekstrem atau race condition yang jarang terjadi, beberapa runtime fuzzer telah digunakan untuk mengeksekusi transaksi yang sebagian diacak. Transaksi ini dieksekusi di berbagai versi runtime guna memastikan performa yang konsisten. v1.16 juga telah diaudit secara menyeluruh oleh Halborn. Laporan audit dipublikasikan ke repositori ini saat tersedia.

Gerbang Fitur

Penting untuk diperhatikan bahwa beberapa fitur yang akan dibahas pada bagian berikut saat ini belum aktif. Sebagai gantinya, fitur diterapkan secara bertahap menggunakan sistem gerbang fitur. Fitur diaktifkan pada epoch tertentu berdasarkan prioritas relatif dan urutan pengaktifannya di jaringan lain. Sejauh ini, penjadwalan aktivasi gerbang fitur dilakukan secara ad hoc berdasarkan sejumlah kriteria yang dapat Anda lihat di sini. Pada dasarnya, gerbang ini harus diaktifkan terlebih dahulu di testnet, kemudian devnet, dan terakhir mainnet-beta. Untuk mengaktifkan fitur, seorang engineer yang memiliki keypair aktivasi yang diperlukan mengirimkan transaksi yang akan diproses, sehingga fitur tersebut aktif pada epoch berikutnya. Hanya satu gerbang fitur yang boleh diaktifkan pada satu waktu di setiap jaringan untuk memastikan performa yang tepat. Perlu diperhatikan bahwa beberapa fitur mungkin memerlukan periode “soak”, yang dapat menunda aktivasi gerbang berprioritas lebih rendah.

Sistem gerbang fitur ini diterapkan untuk memastikan bahwa perubahan yang merusak konsensus tidak menyebabkan validator yang menjalankan versi lebih baru bercabang dari chain kanonis dan terus memproduksi blok. Sebagai contoh, validator v1.14 tidak mengetahui fitur baru v1.16 dan dapat menyebabkan jaringan mengalami crash saat terjadi perselisihan. Sebuah commit yang digabungkan minggu ini ke basis kode Solana mendorong agar semua perubahan yang merusak konsensus memiliki Solana Improvement Document (SIMD). Templat issue gerbang fitur kini akan menyertakan permintaan untuk SIMD issue tersebut. Hal ini membantu menstandarkan proses pengembangan dan memberikan transparansi yang lebih baik melalui dokumentasi perubahan baru.

Transfer Rahasia

Confidential Transfers, fitur yang diperkenalkan oleh Token2022, menggunakan zero-knowledge proof untuk mengenkripsi saldo dan jumlah transaksi token SPL. Fokus utama fitur ini adalah meningkatkan privasi pengguna dengan menekankan kerahasiaan, bukan anonimitas.

Confidential Transfers memanfaatkan Enkripsi Twisted ElGamal untuk operasi matematika pada jumlah yang dienkripsi. Transfer ini divalidasi menggunakan Sigma Protocols, kategori khusus zero-knowledge proof yang memungkinkan satu pihak (pembukti) menunjukkan kepada pihak lain (pemverifikasi) bahwa mereka mengetahui rahasia tertentu tanpa benar-benar mengungkapkan rahasia tersebut. Pastikan Anda membaca artikel kami, Apa itu Token2022?, untuk memahami seluk-beluk Confidential Transfers secara lebih mendalam.

Fitur pelengkap yang berguna untuk peluncuran Confidential Transfers adalah penambahan dukungan Command Line Interface (CLI). Perintah create-token telah diperluas dengan menyertakan flag --enable-confidential-transfers, yang memungkinkan pengguna mencetak token dengan transfer rahasia diaktifkan. Selain itu, perintah update-confidential-transfer-settings telah ditambahkan agar konfigurasi transfer rahasia untuk mint tertentu dapat diubah secara dinamis. Dengan demikian, kunci auditor dan pengaturan persetujuan dapat diperbarui.

Dukungan Runtime yang Lebih Baik untuk Zero-Knowledge Proof

Rilis v1.16 meningkatkan kemampuan zero-knowledge Solana melalui dukungan runtime yang lebih baik untuk komputasi zero-knowledge, khususnya operasi kurva eliptik 128-bit. v1.16 memperkenalkan syscall alt_bn128, yang sangat penting untuk menghasilkan proof secara efisien.

alt_bn128 mengacu pada implementasi khusus kurva eliptik yang digunakan untuk operasi kriptografi dan dikenal sebagai kurva Barreto-Naehrig (BN-128). BN-128 adalah jenis khusus kurva eliptik yang mendukung pairing dan memungkinkan implementasi zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) secara efisien. Sebagai tambahan, kurva eliptik dianggap “mendukung pairing” jika memungkinkan perhitungan tertentu dilakukan dengan lebih efisien. Jadi, dalam kasus ini, penggunaan kurva BN-128 membuat operasi matematika dan proof zero-knowledge jauh lebih cepat.

Syscall, atau system call, digunakan untuk meminta layanan dari kernel sistem operasi. Dalam konteks Solana, syscall memungkinkan program yang berjalan di Solana Virtual Machine (SVM) berinteraksi dengan sumber daya eksternal.

Dengan demikian, syscall alt_bn128 adalah panggilan yang dapat digunakan program Solana untuk berinteraksi dengan kurva BN-128 yang sangat efisien. Hal ini menyederhanakan verifikasi zero-knowledge proof sekaligus menawarkan fitur keamanan dan privasi yang lebih baik di Solana. Syscall alt_bn128 g1 dan g2 juga baru-baru ini ditambahkan, sehingga proof Groth16 dapat dikompresi. Ini penting karena jenis proof tersebut menggunakan 256 byte data instruksi per proof, sedangkan program Solana privat (PSP) saat ini perlu memverifikasi dua proof Groth16. Dengan kompresi g1 dan g2, jumlah byte yang diperlukan per proof dapat dikurangi setengahnya menjadi 128 byte, yang sangat penting untuk efisiensi ruang.

Selain itu, kontrak berbasis Solidity menghadapi masalah kompatibilitas dengan Solana jika berisi panggilan ke kontrak prapengompilasian berikut untuk operasi kurva eliptik:

• bn256Add - Melakukan penambahan dalam operasi kurva eliptik
• bn256ScalarMult - Melakukan perkalian skalar dalam operasi kurva eliptik
• bn256Pairing - Operasi pairing kurva eliptik untuk melakukan verifikasi zkSNARKs dalam batas gas blok

Operasi ini distandardisasi di Ethereum melalui EIP-196, EIP-197, dan EIP-198. Pengenalan syscall alt_bn128 merupakan langkah besar untuk menjembatani kesenjangan kompatibilitas. Kontrak Solidity yang bergantung pada operasi kurva eliptik ini kini dapat lebih mudah bertransisi ke atau bahkan berinteroperasi dengan Solana.

Penyertaan syscall alt_bn128 dalam pembaruan v1.16 Solana menandai kemajuan besar dalam kemampuan Solana menangani zero-knowledge proof secara efisien dan aman. Lihat pull request berikut jika Anda ingin mempelajari syscall alt_bn128 lebih lanjut:

• Menambahkan syscall alt_bn
• Menambahkan pengujian syscall alt_bn128 (dan memperbaiki masalah terkait)
• Fitur(syscall): menambahkan kompresi altbn128 g1 & g2

Validator

Pembaruan v1.16 secara drastis mengurangi penggunaan RAM oleh validator. Sebelumnya, Solana mengandalkan RAM untuk mengindeks akun. Sistem tersebut kini telah dikonfigurasi ulang agar mengindeks akun di disk secara default, sehingga penggunaan RAM berkurang secara signifikan. Yanshu dari Luganodes menyatakan bahwa sejak rilis v1.16, validator mereka berjalan lancar hanya dengan RAM sebesar ~39 GB, dibandingkan dengan ~120 GB pada versi sebelumnya:

Rilis v1.16 juga memperkenalkan sistem peer sampling yang dirancang ulang untuk gossip pull-request. Sistem baru ini efektif mengurangi bandwidth startup bagi validator. Pada versi sebelumnya, validator dapat mengalami keterbatasan bandwidth akibat tingginya volume gossip pull-request. Hal ini dapat memperlambat atau bahkan membebani validator secara berlebihan. v1.16 mengatasi masalah ini dengan memperkenalkan variabel waktu sejak permintaan terakhir. Variabel ini digunakan untuk mengukur tingkat lalu lintas masuk dan menerapkan pembatasan laju agar validator tidak terbebani secara berlebihan saat melakukan startup.

Validator yang telah melakukan staking dan tertinggal dari jaringan kini dapat mengejar status terkini dengan lebih cepat berkat fitur repair request baru yang sebanding dengan stake masing-masing. Ketika validator dengan stake besar bercabang dari jaringan, validator tersebut akan membuat repair request. Validator ini kemudian akan menerima shred lebih cepat karena memiliki stake yang besar. Hal ini memastikan validator tersebut tidak lagi bercabang dari jaringan dan dapat terus berkontribusi. Validator yang telah melakukan staking memiliki prioritas lebih tinggi daripada node RPC untuk repair request karena node RPC tidak memproduksi blok.

Ambang penundaan untuk menerbitkan perbaikan shred juga telah ditingkatkan dari 100ms menjadi 200ms. Perubahan ini dilakukan untuk mengurangi jumlah repair request bagi shred yang pada akhirnya akan disediakan melalui Turbine. Sebagai tambahan, Turbine mengacu pada mekanisme propagasi blok berlapis yang digunakan Solana untuk menyiarkan entri ledger ke seluruh node. Dalam mekanisme ini, cluster Solana membagi dirinya menjadi beberapa lapisan node, dan setiap node dalam lapisan tertentu bertanggung jawab menyebarkan data ke lapisan berikutnya di bagian hilir. Penyesuaian ini sangat penting karena meminimalkan repair request yang tidak diperlukan, sehingga meningkatkan efisiensi propagasi data Turbine.

Menjalankan validator Anda sendiri kini lebih mudah dari sebelumnya. Bagi Anda yang ingin mengoperasikan validator sendiri, Solana menyediakan Edukasi Validator Solana, rangkaian lokakarya validator yang tersedia di kanal YouTube mereka.

Dukungan untuk Akun yang Dapat Diubah Ukurannya

Saat menerapkan program di Solana, jumlah ruang yang dialokasikan untuk program selalu dua kali ukuran program tersebut. v1.16 memungkinkan Anda menerapkan program dengan akun data yang dapat diubah ukurannya. Artinya, Anda dapat menerapkan program dengan akun yang lebih kecil, lalu memperbesar ukurannya nanti dengan membayar selisih memori. Dukungan untuk akun yang dapat diubah ukurannya memberikan fleksibilitas dan alokasi sumber daya yang lebih baik bagi developer yang menerapkan aplikasi di Solana.

Epoch Accounts Hash

Pada versi sebelumnya, terdapat masalah terkait blok dan verifikasi seluruh akun dalam state. Jika validator tidak berinteraksi dengan akun tertentu dalam waktu lama, validator tersebut mungkin memiliki versi akun yang rusak tanpa menyadarinya. Hal ini terjadi karena state akun tidak akan dibandingkan dengan state yang disimpan oleh node validator lain selama tidak ada transaksi yang mengubah state tersebut.

v1.16 mengatasi masalah ini dengan memperkenalkan Epoch Accounts Hash. Ini adalah hash dari seluruh akun yang dihasilkan pada akhir setiap epoch, meskipun akun tersebut tidak pernah berinteraksi. Epoch Accounts Hash memungkinkan jaringan mengidentifikasi dan memisahkan node dengan data rusak, sehingga meningkatkan integritas dan keamanan Solana.

Penyetelan Sistem

Penyetelan sistem adalah proses mengoptimalkan sistem operasi dan konfigurasi hardware validator untuk mencapai performa optimal. Dalam rilis v1.16, solana-sys-tuner telah dihapus dan kini pengujian manual direkomendasikan. Fitur ini dihapus karena pada versi sebelumnya, kolom TransactionStatus dan AddressSignature di RocksDB tidak dibersihkan dengan benar. Selain itu, pemadatan berkala, yaitu proses untuk memperoleh kembali ruang penyimpanan, dinonaktifkan secara default. Akibatnya, kolom-kolom ini terus membesar tanpa batas pada node yang menjalankan flag --enable-rpc-transaction-history. Berkat commit berikut, validator yang menggunakan flag ini kini akan mengelola ruang penyimpanannya dengan lebih efisien. Ini merupakan peningkatan signifikan dalam menyederhanakan kebutuhan penyimpanan validator karena tidak perlu lagi menyimpan status transaksi dan tanda tangan alamat yang tidak diperlukan.

Kesimpulan

Rilis v1.16 Solana menandai pencapaian penting yang merangkum sepuluh bulan pengembangan. Rilis ini berjalan lambat karena QUIC diprioritaskan, sehingga kemajuan dalam transfer rahasia, dukungan zero-knowledge, dan optimalisasi validator ini sudah lama dinantikan. Meski demikian, peningkatan ini benar-benar revolusioner. Rilis ini menghadirkan tingkat efisiensi dan privasi baru bagi Solana.

Ke depannya, Solana Labs beralih ke siklus rilis yang lebih agile, dengan target satu rilis baru kira-kira setiap tiga bulan. Rilis mendatang akan jauh lebih kecil dibandingkan v1.16. Hal ini memungkinkan iterasi lebih cepat dan mengurangi risiko saat penerapan. Jadwal rilis v1.17 dapat dilihat di sini, dan rilis ini diperkirakan kembali sangat dinantikan karena menawarkan dukungan zero-knowledge yang lebih baik serta potensi pengenalan syscall Posidon.

Jika Anda sudah membaca sampai sejauh ini, anon, terima kasih! Dengan siklus rilis yang lebih agile serta berbagai fitur dan peningkatan baru, masa depan Solana tampak lebih cerah dari sebelumnya. Baik Anda seorang developer, investor, validator, maupun penggemar Solana, pastikan untuk terus mengikuti rilis mendatang! Perjalanan Solana Anda baru saja dimulai.

Sumber Daya Tambahan / Bacaan Lebih Lanjut

• Jadwal Aktivasi Gerbang Fitur
• Proses Aktivasi Gerbang Fitur
• Audit Keamanan Solana
• Solana Beach - Halaman Validator

‍