Semua yang Perlu Anda Ketahui tentang Pembaruan Solana v1.18

Pendahuluan

Adopsi supermayoritas atas pembaruan Solana 1.18 merupakan pencapaian penting. Pembaruan ini menghadirkan beragam peningkatan dan fitur baru yang dirancang untuk meningkatkan performa, keandalan, dan efisiensi jaringan. Salah satu perubahan yang paling menonjol adalah diperkenalkannya scheduler terpusat. Scheduler baru ini bertujuan menyederhanakan penanganan transaksi serta memastikan penghitungan prioritas yang lebih akurat dan efisien. Peningkatan lain pada lingkungan runtime dan deployment program, misalnya, membantu memberikan performa yang lebih andal bahkan saat beban jaringan mencapai puncaknya.

Artikel ini membahas pembaruan dan peningkatan yang dihadirkan oleh rilis 1.18. Kita akan mengulas motivasi di balik perubahan ini, detail fitur-fitur baru tersebut, dan perkiraan dampaknya terhadap peningkatan jaringan. Baik Anda operator validator, developer, maupun pengguna Solana pada umumnya, ikhtisar lengkap pembaruan 1.18 ini akan memberi Anda informasi yang diperlukan untuk memahami dan memanfaatkan berbagai peningkatan baru tersebut.

Pertama-tama, kita perlu membahas Anza, perusahaan pengembangan yang baru didirikan dan mendorong perubahan ini, serta perannya dalam pengembangan Solana yang berkelanjutan.

Apa itu Anza?

Anza adalah perusahaan pengembangan perangkat lunak yang baru didirikan oleh mantan eksekutif dan engineer inti dari Solana Labs. Pembentukannya merupakan langkah strategis untuk memperkuat ekosistem Solana dengan meningkatkan keandalan, desentralisasi, dan kekuatan jaringannya. Anza didirikan untuk menyempurnakan ekosistem Solana dengan mengembangkan infrastruktur penting, berkontribusi pada protokol utama, dan mendorong inovasi alat baru.

Tim pendirinya mencakup Jeff Washington, Stephen Akridge, Jed Halfon, Amber Christiansen, Pankaj Garg, Jon Cinque, dan beberapa engineer inti dari Solana Labs.

Anza berfokus pada pengembangan dan penyempurnaan klien validator Solana melalui pembuatan Agave — fork dari klien validator Solana Labs. Ambisi Anza melampaui pengembangan klien validator mereka dan mencakup komitmen terhadap peningkatan di seluruh ekosistem. Hal ini mencakup pengembangan Token Extensions dan toolchain Rust / Clang khusus. Dengan mendorong pendekatan pengembangan yang kolaboratif dan terbuka, Anza berkomitmen mempercepat dan meningkatkan ekosistem Solana.

Apa itu Agave?

Seperti disebutkan secara singkat pada bagian sebelumnya, Agave adalah fork dari klien validator Solana Labs yang dipelopori oleh Anza. Dalam konteks ini, istilah “fork” berarti tim pengembangan Anza mengambil kode yang sudah ada dari repositori Solana Labs dan memulai jalur pengembangan baru yang terpisah dari basis kode aslinya. Hal ini memungkinkan Anza menerapkan peningkatan, fitur, dan pengoptimalannya sendiri pada klien Solana Labs.

Proses Migrasi

Migrasi klien ke organisasi GitHub milik Anza dimulai pada 1 Maret. Pada awalnya, Agave akan mencerminkan repositori Solana Labs agar komunitas memiliki waktu untuk menyesuaikan diri. Selama periode ini, Anza akan menangani penutupan pull request (PR) dan memigrasikan issue yang relevan ke repositori Agave. Agave dan klien Solana Labs versi 1.17 serta 1.18 akan memiliki fungsionalitas yang identik. Anza menargetkan perilisan Agave v2.0 pada musim panas ini, yang mencakup pengarsipan klien Solana Labs dan rekomendasi agar 100% jaringan bermigrasi ke klien Agave yang baru.

Proses migrasi Solana Labs ke Agave dilacak secara publik di GitHub mereka.

Agave Runtime

Agave Runtime mewarisi arsitektur dasarnya dari Solana Virtual Machine (SVM) dan menjadi fondasi untuk menjalankan fungsionalitas inti yang ditentukan oleh runtime Sealevel. 

Protokol Solana menetapkan runtime sebagai komponen penting untuk memproses transaksi dan memperbarui state dalam database account. Spesifikasi ini telah diadopsi dan disempurnakan lebih lanjut oleh klien Agave dan Firedancer. Inti SVM adalah kemampuannya untuk menjalankan semua program Solana dan mengubah state account secara paralel.

Konsep bank merupakan kunci untuk memproses transaksi dan memahami perubahan yang akan hadir di 1.18. Sebuah bank merupakan bagian logika sekaligus representasi state ledger pada titik waktu tertentu. Bank bertindak sebagai pengontrol canggih yang mengelola database account, mengawasi pelacakan account klien, mengelola eksekusi program, serta menjaga integritas dan perkembangan ledger Solana. Bank merangkum state yang dihasilkan dari transaksi dalam suatu blok, dan berfungsi sebagai snapshot ledger pada saat tersebut.

Setiap bank dilengkapi cache dan referensi yang diperlukan untuk mengeksekusi transaksi, sehingga dapat diinisialisasi dari snapshot sebelumnya atau blok genesis. Selama Banking Stage, ketika validator memproses transaksi, bank digunakan untuk menyusun blok dan kemudian memverifikasi integritasnya. Siklus ini mencakup pemuatan account, pemrosesan transaksi, pembekuan bank untuk memfinalisasi state, dan akhirnya menjadikannya rooted demi memastikan permanensinya.

Secara umum, mesin pemrosesan transaksi dalam Agave Runtime bertugas memuat, mengompilasi, dan menjalankan program. Mesin ini menggunakan kompilasi Just-In-Time (JIT) dan menyimpan program yang telah dikompilasi dalam cache untuk mengoptimalkan efisiensi eksekusi serta mengurangi kompilasi ulang yang tidak diperlukan. Program dikompilasi ke format eBPF sebelum deployment. Runtime kemudian menggunakan toolkit rBPF untuk membuat mesin virtual eBPF yang melakukan kompilasi JIT dari eBPF menjadi instruksi kode mesin x86_64, sehingga memanfaatkan sepenuhnya perangkat keras yang tersedia. Hal ini memastikan program dijalankan secara efisien.

Pembaruan 1.18 memperkenalkan scheduler transaksi terpusat yang sangat terkait dengan efisiensi operasional yang dihadirkan oleh Agave Runtime. Dengan meningkatkan cara transaksi dikompilasi, dieksekusi, dan dikelola melalui bank, pembaruan 1.18 memungkinkan proses scheduling yang lebih ringkas dan efisien. Hasilnya adalah waktu pemrosesan transaksi yang lebih cepat dan throughput yang lebih tinggi. Agave Runtime baru dan kliennya menjadi fondasi peningkatan ini, sehingga penting bagi kita untuk memiliki pemahaman umum sebelum mendalami seluk-beluk scheduler baru tersebut. 

Jika Anda ingin mempelajari Agave Runtime lebih lanjut, saya menyarankan untuk membaca artikel dari Joe Caulfield mengenai topik tersebut. Artikel itu membahasnya dengan sangat mendetail dan menyertakan cuplikan kode yang bermanfaat di berbagai bagian.

Scheduler Transaksi yang Lebih Efisien

Implementasi Saat Ini

Dalam pipeline pemrosesan transaksi, paket transaksi pertama-tama masuk ke sistem melalui ingress paket. Paket-paket ini kemudian menjalani verifikasi tanda tangan selama tahap SigVerify. Langkah ini memastikan setiap transaksi valid dan diotorisasi oleh pengirim.

Setelah verifikasi tanda tangan, transaksi dikirim ke Banking Stage. Banking Stage memiliki enam thread—dua dikhususkan untuk memproses transaksi vote dari Transaction Processing Unit (TPU) atau Gossip, sedangkan empat lainnya berfokus pada transaksi non-vote. Setiap thread bersifat independen dan menerima paket dari channel bersama. Artinya, SigVerify akan mengirim paket dalam batch, lalu setiap thread mengambil transaksi dari channel bersama tersebut dan menyimpannya dalam buffer lokal. 

Buffer lokal menerima transaksi, menentukan prioritasnya, dan mengurutkannya berdasarkan prioritas tersebut. Antrean ini bersifat dinamis dan terus diperbarui untuk mencerminkan perubahan status transaksi serta kebutuhan jaringan secara real-time. Saat transaksi ditambahkan ke antrean, urutannya dievaluasi ulang untuk memastikan transaksi dengan prioritas tertinggi siap diproses terlebih dahulu.

Proses ini berlangsung terus-menerus, dan apa yang terjadi pada paket transaksi tersebut bergantung pada posisi validator dalam jadwal leader. Jika validator tidak dijadwalkan menjadi leader dalam waktu dekat, validator akan meneruskan paket kepada leader berikutnya lalu menghapusnya. Ketika validator semakin dekat dengan slot kepemimpinannya yang telah dijadwalkan (sekitar ~20 slot lagi), validator akan terus meneruskan paket tetapi tidak lagi menghapusnya. Hal ini dilakukan agar paket tersebut dapat dimasukkan ke salah satu bloknya sendiri jika leader lain tidak memprosesnya. Ketika validator tinggal 2 slot lagi sebelum menjadi leader, validator mulai menahan paket — menerimanya tanpa melakukan apa pun agar paket dapat diproses ketika validator menjadi leader.

Selama produksi blok, setiap thread mengambil 128 transaksi teratas dari antrean lokalnya, mencoba memperoleh lock, lalu memeriksa, memuat, mengeksekusi, mencatat, dan melakukan commit atas transaksi tersebut. Jika upaya memperoleh lock gagal, transaksi akan dicoba kembali nanti. Mari kita uraikan setiap langkahnya:

• Lock: Langkah ini memeriksa transaksi mana yang dapat memperoleh lock oleh thread. Setiap transaksi akan membaca dan menulis sejumlah account, sehingga validator perlu memastikan tidak ada konflik
• Pemeriksaan: Langkah ini memeriksa apakah transaksi sudah terlalu lama atau telah diproses. Perhatikan bahwa bank memiliki cache status yang melacak transaksi dari 150-300 slot terakhir
• Pemuatan: Langkah ini memuat account yang diperlukan untuk mengeksekusi transaksi tertentu. Langkah ini juga memeriksa apakah pembayar biaya benar-benar mampu membayar biaya dan apakah program yang dipanggil merupakan program yang valid. Pada dasarnya, langkah ini memuat account dan melakukan penyiapan awal
• Eksekusi: Langkah ini mengeksekusi setiap transaksi
• Pencatatan: Hasil transaksi yang dieksekusi dikirim ke Proof of History Service untuk di-hash. Di sinilah tanda tangan transaksi dikirim
• Commit: Jika langkah pencatatan berhasil, transaksi di-commit. Langkah ini juga menerapkan kembali perubahan ke sistem account sehingga transaksi berikutnya dalam slot ini atau slot selanjutnya akan memiliki tampilan terbaru dari setiap account‍
• Unlock: Lock untuk setiap account yang diterapkan pada langkah pertama dilepas

Banking Stage menggunakan pendekatan multi-iterator untuk membuat batch transaksi ini. Multi-iterator adalah pola pemrograman yang memungkinkan penelusuran dataset secara bersamaan dalam beberapa urutan. Bayangkan beberapa pembaca membaca satu buku yang sama, masing-masing dimulai dari bab berbeda, lalu berkoordinasi agar tidak membaca halaman yang sama pada waktu bersamaan jika pemahaman mereka terhadap isinya dapat saling mengganggu. Dalam Banking Stage, “pembaca” ini adalah iterator, sedangkan “buku” adalah kumpulan transaksi yang menunggu untuk diproses. Tujuan multi-iterator adalah menyaring transaksi secara efisien dan mengelompokkannya menjadi batch yang dapat diproses tanpa konflik lock.

Awalnya, transaksi diserialisasi ke dalam sebuah vector berdasarkan prioritas. Hal ini memberi multi-iterator urutan terstruktur untuk membagi transaksi tersebut menjadi batch yang tidak saling bertentangan. Multi-iterator dimulai dari awal vector yang telah diserialisasi dan menempatkan iterator pada titik-titik ketika transaksi tidak saling bertentangan. Dengan cara ini, multi-iterator membuat batch berisi 128 transaksi tanpa konflik baca-tulis atau tulis-tulis. Jika suatu transaksi bertentangan dengan batch yang sedang dibentuk, transaksi tersebut dilewati dan dibiarkan tanpa tanda sehingga dapat dimasukkan ke batch berikutnya ketika konflik sudah tidak ada. Proses iteratif ini menyesuaikan secara dinamis seiring transaksi terus diproses. 

Setelah batch berhasil dibentuk, transaksi dieksekusi dan, jika berhasil, dicatat dalam Proof of History Service serta disiarkan ke jaringan.

Masalah pada Implementasi Saat Ini

Implementasi saat ini memiliki beberapa area yang dapat berdampak buruk pada performa, sehingga berpotensi menyebabkan bottleneck dalam pemrosesan transaksi dan inkonsistensi prioritas. Tantangan ini terutama berasal dari arsitektur Banking Stage dan sifat penanganan transaksi dalam sistem.

Masalah mendasarnya adalah empat thread independen yang memproses transaksi non-vote memiliki pandangan masing-masing mengenai prioritas transaksi di dalam thread mereka sendiri. Perbedaan ini dapat menyebabkan jitter atau inkonsistensi dalam urutan transaksi. Perbedaan tersebut menjadi lebih jelas ketika semua transaksi berprioritas tinggi saling bertentangan. Karena paket pada dasarnya diambil secara acak oleh setiap thread dari channel bersama SigVerify, setiap thread akan memiliki kumpulan acak dari seluruh transaksi. Selama peristiwa kompetitif, seperti pencetakan NFT populer, banyak transaksi berprioritas tinggi kemungkinan berada di beberapa thread Banking Stage. Hal ini bermasalah karena dapat menyebabkan konflik lock antar-thread. Thread yang bekerja dengan kumpulan prioritas berbeda dapat saling berlomba untuk memproses transaksi berprioritas tinggi tersebut, sehingga tanpa sengaja membuang waktu pemrosesan akibat upaya lock yang gagal.

Bayangkan Banking Stage sebagai orkestra dengan setiap thread sebagai bagian berbeda — alat musik gesek, tiup logam, tiup kayu, dan perkusi. Idealnya, seorang dirigen mengoordinasikan bagian-bagian ini untuk memastikan pertunjukan yang harmonis. Namun, sistem saat ini menyerupai orkestra yang mencoba membawakan komposisi rumit tanpa dirigen. Setiap bagian memainkan melodinya sendiri dan kerap berbenturan satu sama lain. Transaksi berprioritas tinggi adalah bagian solo yang coba dimainkan semua bagian secara bersamaan sehingga menimbulkan kebingungan. Kurangnya koordinasi ini menyoroti kebutuhan akan “dirigen” terpusat untuk memastikan efisiensi dan keselarasan dalam pemrosesan transaksi Solana, layaknya dirigen yang memimpin orkestra.

Scheduler Transaksi Baru

Pembaruan 1.18 memperkenalkan thread scheduling terpusat yang menggantikan model sebelumnya dengan empat thread banking independen, yang masing-masing mengelola prioritas dan pemrosesan transaksinya sendiri. Dalam struktur baru ini, scheduler terpusat menjadi satu-satunya penerima transaksi dari tahap SigVerify. Scheduler tersebut membuat antrean prioritas dan menggunakan graf dependensi untuk mengelola prioritas serta pemrosesan transaksi.

Graf dependensi ini dikenal sebagai prio-graph. Ini merupakan graf berarah asiklik yang dievaluasi secara lazy ketika transaksi baru ditambahkan. Transaksi dimasukkan ke graf untuk membuat rantai eksekusi, lalu dikeluarkan berdasarkan urutan prioritas waktu. Saat menangani transaksi yang saling bertentangan, transaksi yang dimasukkan lebih dahulu akan selalu memiliki prioritas lebih tinggi. Dalam contoh di atas, terdapat transaksi A hingga H. Perhatikan bahwa transaksi A dan E memiliki prioritas tertinggi dalam rantainya masing-masing dan tidak saling bertentangan. Scheduler bergerak dari kiri ke kanan dan memproses transaksi dalam batch:

Transaksi A dan E diproses sebagai batch pertama; kemudian B dan F; lalu C, D, G; serta H sebagai batch terakhir. Seperti yang dapat Anda lihat, transaksi berprioritas tertinggi berada di bagian atas graf (yaitu, paling kiri). Saat scheduler memeriksa transaksi dalam urutan menurun, scheduler akan mengidentifikasi konflik. Jika sebuah transaksi bertentangan dengan transaksi berprioritas lebih tinggi, edge dibuat dalam graf untuk merepresentasikan dependensi ini (misalnya, C dan D bertentangan dengan B).

Model scheduler baru ini mengatasi beberapa masalah utama yang melekat pada pendekatan multi-iterator:

• Konsistensi dalam Penanganan Prioritas: Sistem baru memastikan semua transaksi diproses dalam urutan prioritas yang konsisten dengan memusatkan penerimaan dan scheduling transaksi. Hal ini menghilangkan jitter yang sebelumnya disebabkan oleh beberapa thread dengan pandangan berbeda tentang prioritas transaksi
• Pengurangan Penundaan Pemrosesan: Prio-graph memastikan batch yang disiapkan untuk dieksekusi memiliki peluang sangat tinggi untuk berhasil tanpa konflik lock, sehingga mengurangi waktu pemrosesan dan penundaan akibat perebutan lock. Perhatikan penggunaan frasa “memiliki peluang sangat tinggi untuk berhasil” — tidak sepenuhnya benar bahwa prio-graph membuat batch yang tidak mungkin gagal memperoleh lock karena batch tersebut dapat bertentangan dengan thread vote, meskipun ini merupakan edge case yang sangat jarang terjadi
• Skalabilitas dan Fleksibilitas: Desain scheduler baru ini memungkinkan peningkatan jumlah thread tanpa kekhawatiran sebelumnya terkait meningkatnya konflik lock. Hal ini dimungkinkan oleh tampilan lock yang terpusat dan distribusi transaksi yang lebih terkendali di antara worker 

Pengenalan scheduler terpusat di 1.18 diperkirakan akan meningkatkan penanganan transaksi secara signifikan serta mengurangi kompleksitas dan overhead yang terkait dengan sistem sebelumnya. Hal ini kemungkinan akan menghasilkan waktu pemrosesan transaksi yang lebih cepat, peningkatan throughput, dan jaringan yang lebih stabil. Karena perilisan 1.18 tertunda, scheduler telah mengalami peningkatan sejak pertama kali dibuat. Misalnya, verifikasi precompile untuk transaksi telah dipindahkan ke thread worker guna meningkatkan efisiensi. Selain itu, batas CU kini lebih wajar, dengan rasio estimasi/aktual yang jauh lebih rendah dibandingkan scheduler lama. Scheduler baru kini dapat menggunakan CU untuk membatasi antrean pekerjaan terjadwal, sehingga mencegah terlalu banyak pekerjaan masuk antrean akibat konflik account.

Perhatikan bahwa scheduler terpusat tidak diaktifkan secara default dan harus diaktifkan menggunakan flag baru --block-production-method central-scheduler saat memulai validator. Saat ini fitur tersebut hanya dapat digunakan dengan memilih untuk mengaktifkannya, tetapi akan menjadi scheduler default pada rilis mendatang. Perhatikan juga bahwa scheduler lama dapat diaktifkan menggunakan flag --block-production-method thread-local-multi-iterator (flag ini diaktifkan secara default, tetapi jangan lakukan ini pada rilis mendatang — scheduler terpusat jauh lebih efisien dan mengatasi masalah yang dimiliki scheduler lama).

Penghitungan Prioritas yang Lebih Efektif 

1.18 juga menyempurnakan cara penentuan prioritas transaksi, sehingga prosesnya menjadi lebih adil dan efisien dalam penggunaan resource serta pemulihan biaya. Sebelumnya, prioritas transaksi terutama didasarkan pada prioritas compute budget, yang terkadang menghasilkan penetapan harga compute unit yang tidak optimal. Hal ini terjadi karena penentuan prioritas tidak mempertimbangkan base fee yang dikumpulkan secara memadai, sehingga resource dapat dihargai terlalu rendah dan memengaruhi efisiensi operasional jaringan.

Pendekatan baru menyesuaikan penghitungan prioritas transaksi dengan mempertimbangkan biaya transaksi dan biaya terkait menggunakan rumus Prioritas = Biaya / (Cost + 1). Di sini, biaya mewakili biaya transaksi yang terkait dengan transaksi tertentu, sedangkan cost mewakili konsumsi komputasi dan resource yang ditentukan oleh model biaya Solana. Penambahan “1” pada penyebut merupakan langkah pengamanan untuk mencegah pembagian dengan nol. 

Kita dapat menguraikan rumus tersebut lebih lanjut agar Biaya dan Cost menjadi lebih jelas:

Biaya transaksi kini dihitung secara menyeluruh dengan mempertimbangkan semua biaya komputasi dan operasional yang terkait. Hal ini memastikan penghitungan prioritas mencerminkan konsumsi resource transaksi yang sebenarnya. Artinya, developer dan pengguna akan memperoleh prioritas lebih tinggi jika meminta lebih sedikit compute unit. Ini juga berarti transfer sederhana tanpa priority fee tetap akan memiliki prioritas dalam antrean.

Deployment Program yang Lebih Baik

1.18 juga meningkatkan deployment program secara signifikan dalam hal keandalan deployment dan efisiensi eksekusi. 

Pembaruan baru ini mengatasi masalah ketika program yang di-deploy pada slot terakhir suatu epoch tidak menerapkan perubahan lingkungan runtime yang direncanakan untuk epoch berikutnya dengan benar. Akibatnya, program yang di-deploy selama periode transisi ini secara keliru menggunakan lingkungan runtime lama. 1.18 menyesuaikan proses deployment untuk memastikan lingkungan runtime bagi setiap program yang di-deploy pada akhir epoch selaras dengan lingkungan epoch berikutnya.

1.18 juga mengatasi ketidakmampuan untuk menetapkan harga atau batas compute unit pada transaksi deployment dengan menambahkan flag --with-compute-unit-price ke perintah deployment program CLI. Flag ini dapat digunakan dengan perintah solana program deploy dan solana program write-buffer. Batas compute unit ditetapkan dengan menyimulasikan setiap jenis transaksi deployment dan mengaturnya ke jumlah compute unit yang digunakan.  

Peningkatan penting lainnya berkaitan dengan cara penanganan blockhash untuk deployment program berukuran besar. Sebelum 1.18, transaksi yang dikirim dengan sign_all_messages_and_send dibatasi hingga 100 TPS. Untuk program yang lebih besar, jumlah transaksi deployment dapat mencapai ribuan. Artinya, transaksi dapat tertunda dan berisiko menggunakan blockhash yang kedaluwarsa karena banyak transaksi tersebut akan tertunda selama lebih dari 10 detik. 1.18 menunda penandatanganan transaksi deployment dengan blockhash terbaru hingga setelah penundaan pembatasan. Blockhash kini diperbarui setiap 5 detik, sehingga deployment dengan lebih dari 500 transaksi akan diuntungkan karena menggunakan blockhash yang lebih baru.

Selain itu, 1.18 memperkenalkan peningkatan pada cara jaringan menangani deployment program dan memverifikasi transaksi. Sebelumnya, beberapa program secara keliru ditandai sebagai FailedVerification akibat kesalahan dalam mengidentifikasi status account. Hal ini dapat memberi label yang salah pada program yang sebenarnya tidak gagal dalam pemeriksaan apa pun. Program tersebut kini diidentifikasi dengan benar sebagai Closed jika memang tidak seharusnya aktif. Perubahan ini memastikan hanya program bermasalah yang ditandai untuk diperiksa ulang dan membantu mencegah verifikasi ulang yang tidak diperlukan.

Proses pembaruan state program juga telah disempurnakan. Program kini dapat beralih dari state Closed ke state aktif dalam slot waktu yang sama dengan saat deployment. Artinya, program dapat beroperasi dengan lebih cepat dan andal, yang sangat penting saat permintaan tinggi. Namun, penting untuk diperhatikan bahwa peningkatan ini masih tunduk pada masa tunggu satu slot untuk un-/re-/deployment dan penundaan visibilitas satu slot. Akibatnya, meskipun penyesuaian ini membantu mengelola beban jaringan secara lebih efektif dan mencegah jenis kongesti tertentu, alur kerja developer dApp tidak berubah secara signifikan.

“Patch Kongesti” — Menangani Kongesti dengan Lebih Baik

Testnet versi 1.18.11, yang disebut sebagai “Patch Kongesti,” mengusulkan perubahan untuk mengatasi kongesti Solana baru-baru ini. Perhatikan bahwa rilis ini tidak khusus untuk 1.18 dan telah di-backport ke 1.17.31. Meski demikian, penting bagi kita untuk membahasnya.

Perubahan besarnya adalah QUIC kini memperlakukan peer dengan stake sangat rendah sebagai peer tanpa stake dalam Stake-Weighted Quality of Service (SWQoS). Hal ini dilakukan untuk mengatasi fakta bahwa node dengan stake dalam jumlah sangat kecil dapat menyalahgunakan sistem untuk memperoleh bandwidth yang tidak proporsional. Selain itu, metrik saat ini tidak dapat menunjukkan proporsi paket yang dikirim dan dibatasi dari node dengan stake dibandingkan node tanpa stake. Karena itu, metrik tersebut ditambahkan untuk memberikan visibilitas yang lebih baik. Cara chunk paket ditangani juga dioptimalkan dengan mengganti instance vec dengan smallvec untuk menghemat satu alokasi per paket. Hal ini dimungkinkan karena stream berukuran sebesar paket, sehingga jumlahnya diperkirakan sedikit. 

Sebelumnya, dalam Banking Stage, semua paket diteruskan ke node berikutnya. Namun, 1.18 mengubahnya sehingga hanya paket dari node dengan stake yang diteruskan. Pembaruan ini secara efektif membuat koneksi dengan stake menjadi semakin penting karena memiliki bobot lebih besar dalam penghitungan prioritas dan penerusan transaksi.

Dokumentasi yang Lebih Baik

Pembaruan 1.18 juga meningkatkan dukungan terjemahan untuk dokumentasi resmi Solana secara signifikan guna memastikan aksesibilitas yang lebih baik bagi audiens global. Pembaruan tersebut mencakup peningkatan CLI dan konfigurasi Crowdin (yang menyederhanakan sinkronisasi dokumen antarbahasa) serta pengenalan perintah serve baru untuk pengujian lokal yang lebih baik melalui Docusaurus. Dokumentasi tersebut juga meningkatkan cara penanganan konten statis dengan menautkan file PDF secara langsung ke blob GitHub untuk menghindari masalah jalur relatif dalam build terjemahan.

Bagi developer, proses berkontribusi pada terjemahan diperjelas melalui README yang diperbarui tentang penanganan masalah umum seperti environment variable yang diperlukan dan error build yang umum terjadi. Hal ini dilengkapi dengan peningkatan alur continuous integration, yang kini hanya menyertakan terjemahan dalam build channel stabil. Dengan demikian, hanya dokumentasi yang telah ditinjau dan stabil yang sampai kepada pengguna akhir. Perubahan ini bertujuan menyederhanakan kontribusi, meningkatkan kualitas dokumentasi resmi, dan memberi semua pengguna akses ke informasi yang andal dan akurat.

Kesimpulan

Didorong oleh Anza, pembaruan 1.18 meningkatkan penanganan transaksi, penghitungan prioritas, deployment program, dokumentasi resmi, dan performa jaringan secara keseluruhan dengan signifikan. Dengan diperkenalkannya scheduler terpusat dan berbagai perbaikan untuk mengatasi kongesti baru-baru ini, Solana lebih siap menangani beban puncak serta memastikan perilaku jaringan yang efisien dan andal. Solana merupakan peluang terbaik untuk mewujudkan blockchain yang skalabel, dan pembaruan ini menegaskan potensinya.

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

Referensi Tambahan

• Klien Agave
• Jadwal Transisi Agave
• Anza
• Crate Prio-graph
• Banking Stage dan Scheduler Solana
• Sorotan: Scheduler Solana