INDOPOS
INDOPOS-Ditulis oleh Michael Sutton Dengan bantuan coderofstuff, Shai Wyborski dan lainnya
Dengan keberhasilan penerapan perangkat lunak simpul Rusty Kaspa (RK) ( rilis stabil ), dan penerapannya secara luas oleh jaringan P2P Kaspa dan komunitas penambangan (~ 97% blok Kaspa ditambang melalui simpul RK), tim pengembangan sumber terbuka inti kini mulai mempersiapkan hard-fork¹ yang akan, antara lain², meningkatkan laju blok jaringan dari 1 menjadi 10 blok per detik (BPS). Dalam posting ini, saya menguraikan peta jalan sementara untuk hard-fork mendatang, yang dengan ini dinamakan Crescendo , apa saja yang mungkin akan disertakan, dan proses penerapannya.
Ringkasan
Secara garis besar, berikut ini adalah cara kami membayangkan langkah-langkah yang diperlukan untuk menerapkan percepatan tersebut pada jaringan utama Kaspa. Proses ini melibatkan beberapa fase berulang berikut:
Peluncuran & stabilisasi: Luncurkan testnet dengan laju blok yang diinginkan dan pengaturan jaringan terkait, dan lakukan stabilisasi. Hal ini telah dilakukan dengan TN11 , testnet Kaspa 10-BPS yang sudah ada, yang telah beroperasi sejak 7 Januari 2024. ( Selesai )
Mengidentifikasi hambatan: Mengidentifikasi hambatan pemrosesan secara berulang dan melakukan optimasi kinerja untuk menurunkan spesifikasi perangkat keras yang diperlukan untuk menjalankan node. ( Selesai )
Peningkatan berulang : Ulangi langkah di atas hingga spesifikasi minimal cukup terjangkau dan cukup rendah untuk memenuhi desentralisasi yang dibutuhkan untuk mainnet. ( Kita di sini , semakin dekat dengan konvergensi loop pengoptimalan ini. Perkiraan jangka waktu: ~2 bulan dari sekarang.)
Pengalaman pengguna yang ditingkatkan : Setelah persyaratan kinerja ditetapkan, sempurnakan perangkat lunak node ke tingkat pengalaman pengguna yang dibutuhkan oleh operator mainnet. Artinya, beberapa masalah kecil yang dapat diabaikan dalam pengaturan testnet perlu ditangani di sini (~3 bulan dari sekarang). ( Berikutnya )
Fitur tambahan : Terapkan fitur hardfork tambahan dan sebarkan pada TN11. (Target jangka waktu: ~4–5 bulan dari sekarang. Beberapa fitur mungkin dikecualikan agar sesuai dengan jangka waktu.)
Pembekuan fitur.
Versi hardfork: Terapkan versi transisi hardfork
Terapkan uji coba transisi : Terapkan versi transisi pada TN10 (uji coba 1 BPS) untuk mensimulasikan transisi mainnet.
Penerapan mainnet dengan transisi hardfork diaktifkan 1–2 bulan kemudian
Panduan lebih rinci
Saat ini, pengembang RK sedang sibuk mempersiapkan versi mainnet yang difokuskan pada pengenalan banyak fitur mempool yang kebutuhannya dirinci oleh peluncuran beta KRC-20. Ini termasuk fitur-fitur rumit seperti RBF (replace-by-fee) dan API estimasi biaya, yang keduanya memerlukan kerja hati-hati dengan pengembang ekosistem.
Setelah versi ini dirilis³, fokus akan beralih ke pembuatan versi berorientasi kinerja yang dimaksudkan untuk menstabilkan node TN11. Versi ini akan digunakan untuk menyelaraskan partisipan TN11 di belakang versi yang diharapkan dapat mengatasi semua hambatan pemrosesan saat ini dan menyediakan operasi jaringan yang lancar secara keseluruhan.
Pekerjaan utama adalah menggabungkan PR yang ada berikut ini:
Menghitung GHOSTDAG pada level yang lebih tinggi hanya sesuai permintaan sambil membuat bukti pemangkasan. Ini adalah PR yang signifikan namun rumit yang masih memerlukan tinjauan menyeluruh sebelum digabungkan.
Validasi input paralel , memperkenalkan ketelitian yang lebih baik saat memproses transaksi dengan memvalidasi input secara paralel.
Meningkatkan formula KIP9 pada TN11 ke bentuk akhirnya (TN11 diluncurkan dengan versi KIP9 yang prematur).
Implementasi KIP10 , penggabungan alamat, yang memungkinkan transaksi mikro dengan KIP9, lihat di sini .
Logika yang ditingkatkan untuk pengambilan sampel transaksi saat membangun templat blok
Setelah fitur-fitur ini digabungkan, TN11 akan diluncurkan dengan versi baru ini, dan berjalan dengan beban maksimum selama beberapa minggu. Ini akan memungkinkan kita untuk memahami persyaratan sistem yang diperlukan untuk menjalankan node tersebut. Jika persyaratan sistem minimal dianggap terlalu tinggi, beberapa parameter (seperti ukuran jendela penyesuaian kesulitan dan laju sampel, kedalaman finalitas, dll.) harus disesuaikan, diikuti dengan pengujian selama beberapa minggu lagi. Atau, siklus kinerja lebih lanjut dapat dipertimbangkan.
Selama periode pengujian, pekerjaan akan dilanjutkan pada beberapa fitur lainnya termasuk:
Meningkatkan dan menyempurnakan proses IBD, menangani beberapa kasus tepi dalam proses sinkronisasi node baru yang sangat jarang terjadi di mainnet, tetapi akan diperburuk dengan BPS yang lebih tinggi dan periode pemangkasan yang lebih pendek.
Peningkatan aturan finalitas dan proses validasi bukti header node baru ( KIP7 , KIP8 ).
Tanda terima kriptografi ( KIP6 ), modifikasi yang memungkinkan pembuktian yang jauh lebih kecil dan lebih sederhana bahwa transaksi lama yang sembarangan telah dikonfirmasi.
Mengaktifkan muatan transaksi, yang akan menyederhanakan spesifikasi seperti KRC-20.
Setelah semua hal di atas selesai, kita dapat memulai proses penulisan versi mainnet dari hard-fork ini. Versi ini harus menyertakan logika untuk transisi dari parameter protokol saat ini ke yang baru. Ini adalah proses rumit yang harus diuji secara ketat dan melibatkan pengambilan beberapa keputusan penting seperti kapan HF akan berlaku, dan apakah harus dilakukan secara bertahap atau sekaligus.
Kami tegaskan bahwa rencana yang diuraikan di atas masih tentatif. Tujuan dari tulisan ini bukan untuk menyajikan peta jalan yang sudah final dan pasti, tetapi untuk menyoroti bahwa hard-fork 10BPS adalah fokus utama berikutnya bagi tim inti dan bahwa upaya signifikan akan dicurahkan untuk memenuhi target ini. Di atas segalanya, prinsip panduan kami tetap tidak berubah: keamanan dan stabilitas jaringan, dan memberikan waktu yang cukup bagi ekosistem untuk beradaptasi. Dengan semangat yang sama, kami mencatat bahwa meskipun perincian di atas berkaitan dengan tanggung jawab pengembang inti, ekosistem yang lebih luas – termasuk pengembang dompet, pool, bursa, penjelajah blok, dan lainnya – juga perlu melakukan penyesuaian, dan harus terlibat aktif dalam upaya ini dengan menguji komponen perangkat lunak mereka melalui testnet 10-BPS.
¹Dalam konteks kami, “hard fork” merujuk pada perubahan yang disetujui dan dijadwalkan oleh komunitas dalam protokol konsensus, bukan percabangan yang kontroversial akibat ketidaksepakatan dalam jaringan.
²Tidak ada perubahan yang termasuk dalam hard-fork ini yang akan memengaruhi dana pengguna atau jadwal emisi. Peningkatan menjadi 10 BPS akan menghasilkan hadiah sepuluh kali lebih banyak, tetapi hadiah per blok akan dikurangi dengan faktor yang sama, mempertahankan laju emisi yang sama per detik.
³Versi kandidat rilis mainnet yang berfokus pada mempool diharapkan tersedia pada akhir minggu ini (~25 Agustus).
