Το Kaspa's Toccata Hard Fork: Covenants, ZK Opcodes και Ένας νέος στόχος Ιουνίου

ΚάσπαΤο επερχόμενο hard fork Toccata της εταιρείας θα προσθέσει δύο νέες διαδρομές προγραμματισμού στο δίκτυο: εγγενή προγραμματισμό L1 covenant και υποδομή εφαρμογών μηδενικής γνώσης (zk), με την ενεργοποίηση του mainnet να έχει προγραμματιστεί πλέον για τις 5-20 Ιουνίου 2026, μετατιθέμενη σε σχέση με τον αρχικό στόχο της 5ης Μαΐου.

Ο Michael Sutton της Kaspa Core δημοσίευσε ένα λεπτομερής ενημέρωση σχετικά με το τι περιλαμβάνει το hard fork, γιατί μετακινήθηκε η ημερομηνία και πώς αναμένεται να εξελιχθούν οι επόμενοι μήνες. Το fork ξεκίνησε αρχικά από την Ori Newman ως μια προσπάθεια να ενσωματωθούν συμφωνίες στη μηχανή σεναρίων της Kaspa, εν μέρει ως απάντηση στη συζήτηση OP_CAT στους κύκλους του Bitcoin. Έκτοτε έχει εξελιχθεί σε κάτι πολύ μεγαλύτερο.

Τι είναι το σκληρό πιρούνι Toccata;

Το Toccata είναι ένα προγραμματισμένο hard fork για το δίκτυο Kaspa που εισάγει νέες δυνατότητες απευθείας στο βασικό επίπεδο. Ένα hard fork, για όσους δεν είναι εξοικειωμένοι, είναι μια αναβάθμιση πρωτοκόλλου που δεν είναι συμβατή με παλαιότερες εκδόσεις. Όλοι οι κόμβοι πρέπει να αναβαθμιστούν για να συνεχίσουν να συμμετέχουν στο δίκτυο.

Το όνομα ακολουθεί την παράδοση του Kaspa να χρησιμοποιεί μουσικές αναφορές για σημαντικές αναβαθμίσεις. Αυτό το κομμάτι παίρνει το όνομά του από μια κλασική μουσική μορφή, την τοκάτα, ένα κομμάτι σχεδιασμένο για να αναδεικνύει την τεχνική δεξιοτεχνία σε ένα πληκτροφόρο όργανο.

Σε υψηλό επίπεδο, ο Τοκάτας προσθέτει δύο πράγματα στην Κάσπα:

• Εγγενής προγραμματισμός L1 με συμβόλαιο μέσω ενός νέου μεταγλωττιστή που ονομάζεται Silverscript
• Βασισμένη σε υποδομή εφαρμογών zk, χτισμένο πάνω στα ίδια θεμέλια της διαθήκης

Αυτά δεν είναι εναλλάξιμα συστήματα. Εξυπηρετούν διαφορετικές περιπτώσεις χρήσης και στοχεύουν σε διαφορετικά κοινά προγραμματιστών.

Τι είναι οι Διαθήκες και γιατί είναι σημαντικές για την Κάσπα;

Οι συμφωνίες είναι όροι που τίθενται σχετικά με τον τρόπο με τον οποίο τα κεφάλαια μιας συναλλαγής μπορούν να δαπανηθούν στο μέλλον. Σε μια τυπική συναλλαγή Bitcoin ή Kaspa, μόλις αποσταλούν τα κέρματα, ο παραλήπτης μπορεί να κάνει ό,τι θέλει με αυτά. Οι συμφωνίες αλλάζουν αυτό ενσωματώνοντας κανόνες δαπανών απευθείας στο σενάριο.

Το Kaspa χρησιμοποιεί ένα μοντέλο UTXO, παρόμοιο με το Bitcoin, όπου κάθε συναλλαγή καταναλώνει υπάρχουσες εξόδους και δημιουργεί νέες. Οι συμφωνίες σε ένα σύστημα UTXO επιτρέπουν στους προγραμματιστές να δημιουργούν εκπληκτικά πολύπλοκες ροές πολλαπλών συμβολαίων με καταστάσεις, παρόλο που ο υποκείμενος υπολογισμός παραμένει τοπικός σε κάθε UTXO.

Για να γίνει η ανάπτυξη συμβάσεων πιο προσιτή, η Kaspa Core ολοκληρώνει το Silverscript, έναν μεταγλωττιστή που ξεκίνησε από τους Ori Newman, Michael Sutton, IzioDev και Manyfest. Το Silverscript έχει σχεδιαστεί για να διευκολύνει και να ασφαλίζει τη σύνταξη και την ανάπτυξη σύνθετων συμβάσεων απευθείας στο Kaspa L1, χωρίς να χρειάζεται οι προγραμματιστές να εργάζονται σε επίπεδο μηχανής σεναρίων.

Τι είναι οι εφαρμογές που βασίζονται στο ZK;

Ο δεύτερος πυλώνας προγραμματισμού που εισήχθη στο Toccata βασίζεται σε εφαρμογές zk. Αυτός είναι ο πιο τεχνικά πυκνός από τους δύο και αξίζει να τον αναλύσουμε προσεκτικά.

Ανακαλύψτε πολλά υποσχόμενα έργα...

Πολλά υποσχόμενα έργα...

(Διαφήμιση)

Το άρθρο συνεχίζεται...

Το ZK σημαίνει μηδενική γνώση, μια κρυπτογραφική μέθοδος που επιτρέπει σε ένα μέρος να αποδείξει ότι κάτι είναι αληθές χωρίς να αποκαλύψει τα υποκείμενα δεδομένα. Οι αποδείξεις ZK χρησιμοποιούνται όλο και περισσότερο στην κλιμάκωση blockchain επειδή επιτρέπουν την επαλήθευση υπολογισμών εκτός αλυσίδας εντός της αλυσίδας με χαμηλό και ασφαλή τρόπο.

«Βασισμένο» σε αυτό το πλαίσιο σημαίνει ότι το σύστημα zk ακολουθεί πλήρως την αλληλούχιση L1. Μια εφαρμογή zk που βασίζεται σε αυτήν δεν μπορεί να προσθέσει ή να αφαιρέσει συναλλαγές ανεξάρτητα. Είναι αγκυροβολημένη στη δική της σειρά συναλλαγών της Kaspa, γεγονός που την καθιστά αξιόπιστη χωρίς ξεχωριστό sequencer.

Το Toccata εισάγει διάφορα στοιχεία για να το υποστηρίξει αυτό:

• Κωδικοί λειτουργίας επαλήθευσης ZK, συμπεριλαμβανομένου ενός ευέλικτου επαληθευτή Groth16 και ενός επαληθευτή RISC Zero STARK
• Ένας κωδικός λειτουργίας (opercode) πρόσβασης δέσμευσης αλληλούχισης, επιτρέποντας στις εφαρμογές που βασίζονται σε αυτά να αγκυροβολούν στην παραγγελία L1
• ΚΙΡ-21, μια αρχιτεκτονική δέσμευσης διαμερισμένης αλληλούχισης που διασφαλίζει ότι το κόστος απόδειξης μιας εφαρμογής zk κλιμακώνεται με τη δική της δραστηριότητα, όχι με τη συνολική δραστηριότητα DAG

Ο επαληθευτής RISC Zero STARK έχει ήδη υλοποιηθεί και ενεργοποιηθεί στο testnet 12. Το αν θα ενεργοποιηθεί στο mainnet δεν έχει ακόμη αποφασιστεί.

Γιατί η απόδειξη των εξόδων έχει σημασία

Για να είναι πρακτική οποιαδήποτε εφαρμογή zk, το κόστος δημιουργίας αποδείξεων πρέπει να παραμένει ανάλογο με αυτό που κάνει η ίδια η εφαρμογή. Εάν μια εφαρμογή zk έπρεπε να αποδείξει την εργασία σε σχέση με όλη τη δραστηριότητα στο ευρύτερο DAG, το κόστος θα γινόταν απρόβλεπτο και μη διαχειρίσιμο. Το KIP-21 λύνει αυτό το πρόβλημα διαμερίζοντας τις δεσμεύσεις αλληλούχισης, διατηρώντας το φόρτο εργασίας κάθε εφαρμογής αυτόνομο.

Τι υπάρχει ήδη στη θέση του;

Ένα σημαντικό μέρος του hard fork έχει ήδη υλοποιηθεί. Τα ακόλουθα χαρακτηριστικά έχουν ήδη ενσωματωθεί:

• Εκτεταμένη υποστήριξη κώδικα λειτουργίας μηχανής σεναρίων, ο βασικός κορμός συμβάσεων, στο πλαίσιο του KIP-17
• Αναγνωριστικά Συμφώνων για τη διαχείριση γενεαλογικών γραμμών ως χαρακτηριστικό συναίνεσης και μηχανής, στο πλαίσιο του KIP-20
• Κώδικες λειτουργίας ZK με υποσύστημα προμεταγλώττισης zk-verifier, στο πλαίσιο του KIP-16, με συγγραφέα τον Alexander Safstrom
• Αλληλουχία κώδικα λειτουργίας πρόσβασης δέσμευσης
• KIP-21, με συγγραφέα τον Sutton και εφαρμογή από τον Maxim Biryukov, πλήρως υλοποιημένο και εκκρεμεί αναθεώρηση

Ο Maxim ολοκλήρωσε επίσης ορόσημα απόδειξης της ιδέας, συμπεριλαμβανομένων των ενσωματωμένων συμβάσεων zk και των βασισμένων συμβάσεων zk με μια κανονική γέφυρα KAS, τα οποία έπαιξαν καθοριστικό ρόλο στη διαμόρφωση του τελικού σχεδιασμού του fork.

Γιατί η ημερομηνία του The Hard Fork μεταφέρθηκε στον Ιούνιο;

Ο αρχικός στόχος για το mainnet ήταν η 5η Μαΐου 2026. Έκτοτε, έχει μετακινηθεί σε ένα χρονικό διάστημα 5-20 Ιουνίου 2026.

Ο λόγος είναι αρχιτεκτονικός. Μόλις τα κυκλώματα και οι χρόνοι εκτέλεσης zk συνδεθούν με μια δομή κατακερματισμού δέσμευσης αλληλουχίας, τυχόν δομικές αλλαγές εκ των υστέρων μετατρέπονται σε αλλαγές που προκαλούν προβλήματα. Το να κάνουμε λάθος στο σχεδιασμό και να το διορθώσουμε αργότερα θα ήταν πολύ πιο ανατρεπτικό από το να αφιερώσουμε επιπλέον χρόνο τώρα.

Το KIP-21 έχει ήδη σχεδιαστεί ώστε να είναι συμβατό με το μελλοντικό σχήμα δέσμευσης που τελικά θα απαιτηθεί από το vprogs, τον μακροπρόθεσμο οδικό χάρτη της Kaspa για συγχρονισμένα επαληθεύσιμα προγράμματα. Το κλείδωμα της σωστής δομής πριν από την ενεργοποίηση του mainnet αποφεύγει τις δαπανηρές μετεγκαταστάσεις αργότερα.

Το πάγωμα των λειτουργιών αναμένεται στις 15 Απριλίου 2026.

Τι συμβαίνει μεταξύ του Feature Freeze και του Mainnet;

Μετά το πάγωμα των χαρακτηριστικών στις 15 Απριλίου, η Kaspa Core σχεδιάζει μια καθαρή επανεκκίνηση του αποκλειστικού δικτύου δοκιμών, TN12, με το πλήρες τελικό σύνολο χαρακτηριστικών να περιλαμβάνεται. Δεν πρόκειται για προσομοίωση της μετάβασης σε hard fork. Πρόκειται για ένα καθαρό δίκτυο για τη δοκιμή ολόκληρου του συνόλου χαρακτηριστικών στην τελική του μορφή.

Από εκεί, η ομάδα θα συγχωνεύσει τους συσσωρευμένους μήνες εργασίας από έναν εκκρεμή κλάδο μακράς διάρκειας πίσω στην κύρια βάση κώδικα. Αυτή η διαδικασία περιλαμβάνει τον τελικό έλεγχο, το κλείσιμο ανοιχτών στοιχείων, την τελειοποίηση της λογικής ενεργοποίησης hard-fork και τον χειρισμό της δυνατότητας αναβάθμισης της βάσης δεδομένων.

Μόλις ολοκληρωθεί αυτή η εργασία, μια δοκιμαστική hard fork θα εκτελεστεί μέσω του TN10, του μακροπρόθεσμου testnet, για να προσομοιώσει μια πλήρη μετάβαση σε στυλ mainnet. Η ημερομηνία mainnet θα κωδικοποιηθεί μόνο αφού εκτελεστεί αυτή η πρόβα προς ικανοποίηση της ομάδας.

Τι πρέπει να περιμένουν οι χειριστές κόμβων

Για τους miners και τους χειριστές nodes, η αναβάθμιση έχει σχεδιαστεί για να είναι απλή. Οι nodes πρέπει να ενημερωθούν και η υπάρχουσα λειτουργικότητα θα πρέπει να συνεχίσει να λειτουργεί. Οι απαιτήσεις χώρου στο δίσκο αναμένεται να αυξηθούν κατά περίπου 20 έως 50 τοις εκατό. Δεν αναμένονται δραματικές αλλαγές στην υποδομή.

Τι προσφέρει στην πραγματικότητα η Τοκάτα στον Κάσπα

Το Toccata προσθέτει δύο λειτουργικά συστήματα προγραμματισμού στο βασικό επίπεδο του Kaspa: εγγενή σενάρια L1 μέσω του Silverscript και βασισμένη υποδομή εφαρμογών zk μέσω των KIP-16, KIP-20 και KIP-21. Ένα μεγάλο μέρος της τεχνικής εργασίας έχει ήδη ολοκληρωθεί. Αυτό που απομένει είναι η οριστικοποίηση των διεπαφών, η συγχώνευση του εκκρεμούς κλάδου με τον κύριο κλάδο και η εκτέλεση μιας πλήρους πρόβας στο TN10 πριν επιβεβαιωθεί η ημερομηνία του mainnet.

Το χρονικό διάστημα 5-20 Ιουνίου 2026 υπάρχει επειδή η ομάδα επέλεξε να κάνει σωστά την αρχιτεκτονική δέσμευσης αλληλούχισης την πρώτη φορά αντί να την διορθώσει αργότερα σε πραγματικές συνθήκες. Για τους χειριστές κόμβων, η αναβάθμιση έχει σχεδιαστεί ώστε να είναι απλή, χωρίς σημαντικές αλλαγές στην υποδομή πέρα ​​από μια μέτρια αύξηση του χώρου στο δίσκο.

Υποστηρικτικό υλικό

1. Κάσπα στο X: Δημοσίευση (Απρίλιος, 2026)

2. Άρθρο ιστολογίου από τον Michael Sutton: Kaspa Covenants++ «Toccata» Hard-Fork Outlook