Kaspas Toccata Hard Fork: Vereinbarungen, ZK-Opcodes und ein neues Juni-Ziel

KaspMit dem bevorstehenden Toccata Hard Fork werden zwei neue Programmierbarkeitspfade zum Netzwerk hinzugefügt: native L1 Covenant Programmierung und auf Zero-Knowledge (zk) basierende Anwendungsinfrastruktur. Die Aktivierung des Mainnets ist nun für den 5. bis 20. Juni 2026 geplant und wurde vom ursprünglichen Zieltermin am 5. Mai verschoben.

Michael Sutton von Kaspa Core veröffentlichte einen detailliertes Update Was die Hard Fork beinhaltet, warum das Datum verschoben wurde und wie sich die nächsten Monate voraussichtlich entwickeln werden. Die Fork wurde ursprünglich von Ori Newman initiiert, um Covenants in Kaspas Script-Engine zu integrieren, unter anderem als Reaktion auf die OP_CAT-Diskussion in Bitcoin-Kreisen. Inzwischen hat sie sich zu etwas deutlich Größerem entwickelt.

Was ist die Toccata Hard Fork?

Toccata ist ein geplanter Hard Fork des Kaspa-Netzwerks, der neue Funktionen direkt in die Basisschicht einführt. Ein Hard Fork ist, für diejenigen, die damit weniger vertraut sind, ein Protokoll-Upgrade, das nicht abwärtskompatibel ist. Alle Knoten müssen das Upgrade durchführen, um weiterhin am Netzwerk teilnehmen zu können.

Der Name folgt Kaspas Tradition, für größere Upgrades musikalische Bezüge zu verwenden. Dieser Name stammt von einer klassischen Musikform, der Toccata, einem Stück, das die technische Virtuosität an einem Tasteninstrument demonstriert.

Im Großen und Ganzen fügt Toccata Kaspa zwei Dinge hinzu:

• Native L1-Covenant-Programmierung über einen neuen Compiler namens Silverscript
• Basierend auf der zk-Anwendungsinfrastruktur, erbaut auf denselben Fundamenten des Bundes

Es handelt sich hierbei nicht um austauschbare Systeme. Sie dienen unterschiedlichen Anwendungsfällen und zielen auf unterschiedliche Entwicklerzielgruppen ab.

Was sind Bündnisse und warum sind sie für Kaspa wichtig?

Covenants sind Bedingungen, die festlegen, wie Gelder aus einer Transaktion zukünftig verwendet werden dürfen. Bei einer herkömmlichen Bitcoin- oder Kaspa-Transaktion kann der Empfänger nach dem Senden der Coins damit machen, was er will. Covenants ändern dies, indem sie Ausgabenregeln direkt in das Skript einbetten.

Kaspa verwendet ein UTXO-Modell, ähnlich wie Bitcoin, bei dem jede Transaktion bestehende Ausgaben verbraucht und neue erzeugt. Die Vereinbarungen in einem UTXO-System ermöglichen es Entwicklern, überraschend komplexe zustandsbehaftete Multi-Contract-Abläufe zu erstellen, obwohl die zugrunde liegende Berechnung lokal auf jeden einzelnen UTXO beschränkt bleibt.

Um die Entwicklung von Covenants zugänglicher zu gestalten, finalisiert Kaspa Core Silverscript, einen Compiler, der von Ori Newman, Michael Sutton, IzioDev und Manyfest initiiert wurde. Silverscript vereinfacht und sichert das Schreiben und Bereitstellen komplexer Covenants direkt auf Kaspa L1, ohne dass Entwickler auf der Ebene der Skript-Engine arbeiten müssen.

Was sind ZK-basierte Anwendungen?

Die zweite Programmierbarkeitssäule, die in Toccata eingeführt wurde, basiert auf zk-Anwendungen. Diese ist die technisch anspruchsvollere der beiden und verdient eine sorgfältige Erläuterung.

Entdecken Sie vielversprechende Projekte...

Vielversprechende Projekte...

(Werbung)

Artikel wird fortgesetzt...

ZK steht für Zero-Knowledge, ein kryptografisches Verfahren, mit dem eine Partei die Richtigkeit einer Aussage beweisen kann, ohne die zugrundeliegenden Daten preiszugeben. ZK-Beweise werden zunehmend bei der Skalierung von Blockchains eingesetzt, da sie eine kostengünstige und sichere Überprüfung von Off-Chain-Berechnungen auf der Blockchain ermöglichen.

„Basierend“ bedeutet in diesem Kontext, dass das zk-System die L1-Sequenzierung vollständig befolgt. Eine solche Anwendung kann Transaktionen nicht selbstständig hinzufügen oder entfernen. Sie ist an die Transaktionsreihenfolge von Kaspa gebunden, wodurch sie ohne separaten Sequenzer vertrauenswürdig ist.

Toccata führt mehrere Komponenten ein, um dies zu unterstützen:

• ZK-Verifizierungs-Opcodeseinschließlich eines flexiblen Groth16-Verifizierers und eines RISC Zero STARK-Verifizierers
• Ein Sequenzierungs-Commitment-Zugriffs-Opcodewodurch es Anwendungen ermöglicht wird, sich an die L1-Ordnung anzubinden
• KIP-21, eine partitionierte Sequenzierungs-Commitment-Architektur, die sicherstellt, dass die Nachweiskosten einer zk-Anwendung mit ihrer eigenen Aktivität skalieren, nicht mit der Gesamtaktivität des DAG.

Der RISC Zero STARK-Verifizierer ist bereits im Testnetz 12 implementiert und aktiviert. Ob er auch im Hauptnetz aktiviert wird, wird noch entschieden.

Warum der Nachweis von Kosten wichtig ist

Damit eine ZK-Anwendung praktikabel ist, müssen die Kosten für die Generierung von Proofs proportional zum tatsächlichen Arbeitsaufwand der Anwendung sein. Müsste eine ZK-Anwendung den Arbeitsaufwand für alle Aktivitäten im übergeordneten DAG nachweisen, würden die Kosten unvorhersehbar und unkontrollierbar. KIP-21 löst dieses Problem durch die Partitionierung von Sequenzierungsverpflichtungen, wodurch die Arbeitslast jeder Anwendung in sich abgeschlossen bleibt.

Was ist bereits vorhanden?

Ein wesentlicher Teil des Hard Forks ist bereits implementiert. Folgende Funktionen sind bereits entwickelt:

• Erweiterte Unterstützung für Skript-Engine-Opcodes, das Rückgrat der Kernvereinbarungen, unter KIP-17
• Covenant-IDs für das Lineage-Management als Konsens- und Engine-Funktion im Rahmen von KIP-20
• ZK-Opcodes mit einem zk-Verifizierer-Präkompilierungssubsystem, unter KIP-16, verfasst von Alexander Safstrom
• Sequenzierungsverpflichtungszugriffs-Opcode
• KIP-21, entworfen von Sutton und implementiert von Maxim Biryukov, ist vollständig implementiert und befindet sich im Überprüfungsprozess.

Die Meilensteine ​​des Machbarkeitsnachweises, einschließlich Inline-ZK-Covenants und basierender ZK-Covenants mit einer KAS-kanonischen Brücke, wurden ebenfalls von Maxim abgeschlossen und waren maßgeblich an der Gestaltung des endgültigen Designs der Gabel beteiligt.

Warum wurde der Termin für die Hard Fork auf Juni verschoben?

Als ursprünglicher Zieltermin für den Start des Hauptnetzes war der 5. Mai 2026 vorgesehen. Dieser wurde inzwischen auf den Zeitraum vom 5. bis 20. Juni 2026 verschoben.

Der Grund ist architektonischer Natur. Sobald zk-Schaltungen und Laufzeitumgebungen an eine Sequenzierungs-Commitment-Hashing-Struktur gebunden sind, führen nachträgliche Strukturänderungen zu inkompatiblen Änderungen. Ein fehlerhaftes Design mit anschließender Korrektur wäre deutlich störender, als jetzt die zusätzliche Zeit zu investieren.

KIP-21 ist bereits so konzipiert, dass es mit dem Commitment-Schema kompatibel ist, das letztendlich von vprogs, Kaspas langfristiger Roadmap für synchron zusammensetzbare, verifizierbare Programme, benötigt wird. Die Festlegung der richtigen Struktur vor der Mainnet-Aktivierung vermeidet spätere, kostspielige Migrationen.

Die Einstellung der neuen Funktionen wird voraussichtlich am 15. April 2026 erfolgen.

Was geschieht zwischen dem Feature Freeze und dem Mainnet?

Nach dem Feature-Freeze am 15. April plant Kaspa Core einen kompletten Neustart des dedizierten Testnetzes TN12 mit dem vollständigen finalen Funktionsumfang. Dies ist keine Simulation des Hard-Fork-Übergangs, sondern ein sauberes Netzwerk zum Testen des vollständigen Funktionsumfangs in seiner finalen Form.

Anschließend wird das Team die monatelang angesammelte Arbeit aus einem lange bestehenden Entwicklungszweig wieder in den Hauptcode einbinden. Dieser Prozess umfasst die abschließende Prüfung, das Schließen offener Punkte, die Optimierung der Logik zur Aktivierung von Hard Forks und die Sicherstellung der Aktualisierbarkeit der Datenbank.

Sobald diese Arbeiten abgeschlossen sind, wird ein Test-Hardfork über TN10, das Langzeit-Testnetz, durchgeführt, um einen vollständigen Übergang zum Mainnet zu simulieren. Das Mainnet-Datum wird erst dann fest im Code verankert, wenn dieser Testlauf für das Team zufriedenstellend verlaufen ist.

Was Knotenbetreiber erwarten sollten

Für Miner und Node-Betreiber ist das Upgrade so konzipiert, dass es unkompliziert ist. Die Nodes müssen lediglich aktualisiert werden, und die bestehende Funktionalität bleibt erhalten. Der Speicherplatzbedarf wird voraussichtlich um etwa 20 bis 50 Prozent steigen. Es sind keine grundlegenden Infrastrukturänderungen zu erwarten.

Was Toccata Kaspa tatsächlich bietet

Toccata erweitert Kaspas Basisschicht um zwei programmierbare Systeme: natives L1-Covenant-Scripting mit Silverscript und zk-basierte Anwendungsinfrastruktur mit KIP-16, KIP-20 und KIP-21. Ein Großteil der technischen Arbeit ist bereits abgeschlossen. Es müssen nur noch die Schnittstellen finalisiert, der ausstehende Branch in den Master-Branch integriert und ein vollständiger Testlauf auf TN10 durchgeführt werden, bevor der Mainnet-Starttermin feststeht.

Das Zeitfenster vom 5. bis 20. Juni 2026 besteht, weil das Team die Architektur für die Sequenzierungszusagen von Anfang an korrekt implementieren wollte, anstatt sie später im laufenden Betrieb zu korrigieren. Für Knotenbetreiber ist das Upgrade so konzipiert, dass es unkompliziert ist und außer einer geringfügigen Erweiterung des Speicherplatzes keine größeren Infrastrukturänderungen erfordert.

Ressourcen

1. Kaspa auf X: Beitrag (April 2026)

2. Blogartikel von Michael Sutton: Kaspa Covenants++ „Toccata“ Hard-Fork-Ausblick