Hard Fork Toccata Kaspa: Perjanjian, Opcode ZK, dan Target Juni Baru

kaspaHard fork Toccata mendatang akan menambahkan dua jalur pemrograman baru ke jaringan: pemrograman perjanjian L1 asli dan infrastruktur aplikasi berbasis zero-knowledge (zk), dengan aktivasi mainnet yang sekarang dijadwalkan pada 5–20 Juni 2026, diundur dari target awal 5 Mei.

Michael Sutton dari Kaspa Core menerbitkan sebuah pembaruan detail Tentang apa saja yang termasuk dalam hard fork, mengapa tanggalnya diundur, dan bagaimana beberapa bulan ke depan diperkirakan akan berjalan. Hard fork ini awalnya diprakarsai oleh Ori Newman sebagai upaya untuk memasukkan perjanjian ke dalam mesin skrip Kaspa, sebagian sebagai tanggapan terhadap diskusi OP_CAT di kalangan Bitcoin. Sejak itu, hard fork ini telah berkembang menjadi sesuatu yang jauh lebih besar.

Apa itu hard fork Toccata?

Toccata adalah hard fork terjadwal untuk jaringan Kaspa yang memperkenalkan kemampuan baru langsung ke lapisan dasar. Hard fork, bagi yang kurang familiar, adalah peningkatan protokol yang tidak kompatibel dengan versi sebelumnya. Semua node harus melakukan peningkatan untuk terus berpartisipasi dalam jaringan.

Nama tersebut mengikuti tradisi Kaspa dalam menggunakan referensi musik untuk peningkatan besar. Yang satu ini mengambil namanya dari bentuk musik klasik, toccata, sebuah karya yang dirancang untuk memamerkan keterampilan teknis pada instrumen keyboard.

Secara garis besar, Toccata menambahkan dua hal pada Kaspa:

• Pemrograman perjanjian L1 asli melalui kompiler baru bernama Silverscript
• Infrastruktur aplikasi berbasis zk, dibangun di atas fondasi perjanjian yang sama tersebut

Sistem-sistem ini tidak dapat saling menggantikan. Mereka melayani kasus penggunaan yang berbeda dan menargetkan audiens pengembang yang berbeda.

Apa Itu Perjanjian dan Mengapa Perjanjian Penting Bagi Kaspa?

Perjanjian (Covenants) adalah kondisi yang dikenakan pada bagaimana dana dalam output transaksi dapat dibelanjakan di masa mendatang. Dalam transaksi Bitcoin atau Kaspa standar, setelah koin dikirim, penerima dapat melakukan apa pun yang mereka inginkan dengan koin tersebut. Perjanjian mengubah hal itu dengan menyematkan aturan pengeluaran langsung ke dalam skrip.

Kaspa menggunakan model UTXO, mirip dengan Bitcoin, di mana setiap transaksi mengkonsumsi output yang ada dan menciptakan output baru. Perjanjian dalam sistem UTXO memungkinkan pengembang untuk membangun alur multi-kontrak yang sangat kompleks dan memiliki status, meskipun komputasi yang mendasarinya tetap lokal untuk setiap UTXO.

Untuk membuat pengembangan perjanjian lebih mudah diakses, Kaspa Core sedang menyelesaikan Silverscript, sebuah kompiler yang diprakarsai oleh Ori Newman, Michael Sutton, IzioDev, dan Manyfest. Silverscript dirancang untuk mempermudah dan memperaman penulisan dan penyebaran perjanjian kompleks secara langsung di Kaspa L1, tanpa pengembang perlu bekerja pada tingkat mesin skrip mentah.

Apa Itu Aplikasi Berbasis ZK?

Pilar pemrograman kedua yang diperkenalkan di Toccata didasarkan pada aplikasi zk. Ini adalah pilar yang lebih padat secara teknis dari keduanya dan perlu diuraikan dengan cermat.

Temukan Proyek yang Menjanjikan...

Proyek yang Menjanjikan...

(Iklan)

Artikel berlanjut...

ZK adalah singkatan dari zero-knowledge, sebuah metode kriptografi yang memungkinkan satu pihak membuktikan sesuatu itu benar tanpa mengungkapkan data yang mendasarinya. Bukti ZK semakin banyak digunakan dalam penskalaan blockchain karena memungkinkan komputasi di luar rantai (off-chain) untuk diverifikasi di dalam rantai (on-chain) dengan murah dan aman.

Dalam konteks ini, "berbasis" berarti sistem zk sepenuhnya mengikuti urutan L1. Aplikasi zk berbasis tidak dapat menambah atau menghapus transaksi secara independen. Aplikasi ini terikat pada urutan transaksi Kaspa sendiri, yang membuatnya dapat dipercaya tanpa sequencer terpisah.

Toccata memperkenalkan beberapa komponen untuk mendukung hal ini:

• Kode operasi verifikasi ZKtermasuk verifikator Groth16 yang fleksibel dan verifikator RISC Zero STARK.
• Kode operasi akses komitmen pengurutan, memungkinkan aplikasi berbasis untuk menambatkan diri pada pengurutan L1
• KIP-21, sebuah arsitektur komitmen pengurutan terpartisi yang memastikan biaya pembuktian aplikasi zk meningkat seiring dengan aktivitasnya sendiri, bukan dengan aktivitas DAG secara keseluruhan.

Verifikator RISC Zero STARK sudah diimplementasikan dan diaktifkan pada testnet 12. Apakah akan diaktifkan pada mainnet masih dalam proses pengambilan keputusan.

Mengapa Pembuktian Biaya Itu Penting

Agar aplikasi zk praktis, biaya pembuatan bukti harus tetap proporsional dengan apa yang dilakukan aplikasi itu sendiri. Jika aplikasi zk harus membuktikan pekerjaan yang berkaitan dengan semua aktivitas pada DAG yang lebih luas, biaya akan menjadi tidak terduga dan tidak terkendali. KIP-21 memecahkan masalah ini dengan mempartisi komitmen pengurutan, menjaga agar beban kerja setiap aplikasi tetap mandiri.

Apa yang Sudah Ada?

Sebagian besar dari hard fork tersebut sudah diimplementasikan. Fitur-fitur berikut sudah dibangun:

• Dukungan opcode mesin skrip yang diperluas, tulang punggung perjanjian inti, di bawah KIP-17
• ID Perjanjian untuk manajemen silsilah sebagai fitur konsensus dan mesin, di bawah KIP-20
• Kode operasi ZK dengan subsistem pra-kompilasi zk-verifier, di bawah KIP-16, yang ditulis oleh Alexander Safstrom.
• Kode operasi akses komitmen pengurutan
• KIP-21, yang disusun oleh Sutton dan diimplementasikan oleh Maxim Biryukov, telah sepenuhnya diimplementasikan dan sedang menunggu peninjauan.

Tahapan pembuktian konsep, termasuk perjanjian zk inline dan perjanjian zk berbasis dengan jembatan kanonik KAS, juga telah diselesaikan oleh Maxim dan berperan penting dalam membentuk desain akhir dari fork tersebut.

Mengapa Tanggal Hard Fork Dipindahkan ke Bulan Juni?

Target awal peluncuran mainnet adalah 5 Mei 2026. Namun, target tersebut kemudian diundur ke rentang waktu 5–20 Juni 2026.

Alasannya bersifat arsitektural. Begitu sirkuit dan runtime zk terikat pada struktur hashing komitmen sekuens, setiap perubahan struktural setelahnya akan menjadi perubahan yang merusak. Kesalahan desain dan menambalnya nanti akan jauh lebih mengganggu daripada meluangkan waktu ekstra sekarang.

KIP-21 sudah dirancang agar kompatibel dengan skema komitmen yang pada akhirnya akan dibutuhkan oleh vprogs, peta jalan jangka panjang Kaspa untuk program terverifikasi yang dapat disusun secara sinkron. Mengunci struktur yang tepat sebelum aktivasi mainnet menghindari migrasi yang mahal di kemudian hari.

Pembekuan fitur diperkirakan akan terjadi pada 15 April 2026.

Apa yang Terjadi Antara Pembekuan Fitur dan Mainnet?

Setelah pembekuan fitur pada 15 April, Kaspa Core berencana untuk memulai ulang jaringan uji khusus, TN12, dengan menyertakan seluruh rangkaian fitur final. Ini bukan simulasi transisi hard fork. Ini adalah jaringan yang bersih untuk menguji rangkaian fitur lengkap dalam bentuk finalnya.

Dari situ, tim akan menggabungkan akumulasi pekerjaan selama berbulan-bulan dari cabang yang tertunda dalam jangka waktu lama kembali ke basis kode utama. Proses tersebut meliputi audit akhir, menutup item yang masih terbuka, menyempurnakan logika aktivasi hard-fork, dan menangani kemampuan peningkatan basis data.

Setelah pekerjaan itu selesai, hard fork uji coba akan dijalankan di TN10, testnet jangka panjang, untuk mensimulasikan transisi penuh ala mainnet. Tanggal mainnet hanya akan ditetapkan secara pasti setelah uji coba tersebut berjalan sesuai harapan tim.

Apa yang Harus Diharapkan oleh Operator Node

Bagi penambang dan operator node, peningkatan ini dirancang agar mudah dilakukan. Node perlu diperbarui, dan fungsi yang ada seharusnya tetap berjalan. Kebutuhan ruang disk diperkirakan akan meningkat sekitar 20 hingga 50 persen. Tidak ada perubahan infrastruktur yang dramatis yang diperkirakan akan terjadi.

Apa yang Sebenarnya Diberikan Toccata untuk Kaspa?

Toccata menambahkan dua sistem pemrograman yang berfungsi ke lapisan dasar Kaspa: skrip perjanjian L1 asli melalui Silverscript, dan infrastruktur aplikasi zk berbasis melalui KIP-16, KIP-20, dan KIP-21. Sebagian besar pekerjaan teknis telah selesai. Yang tersisa adalah menyelesaikan antarmuka, menggabungkan cabang yang tertunda ke master, dan menjalankan uji coba penuh pada TN10 sebelum tanggal mainnet dikonfirmasi.

Jendela waktu 5–20 Juni 2026 ada karena tim memilih untuk memastikan arsitektur komitmen pengurutan sudah benar sejak awal daripada memperbaikinya nanti dalam kondisi operasional. Bagi operator node, peningkatan ini dirancang agar mudah dilakukan, tanpa perubahan infrastruktur besar selain peningkatan ruang disk yang sederhana.

Publikasi

1. Kaspa di X: Postingan (April, 2026)

2. Artikel blog oleh Michael Sutton: Perjanjian Kaspa++ Outlook Hard-Fork “Toccata”.