Kaspas bevorstehender Covenant-zentrierter Hardfork: Was wir wissen

Was ist Kaspas Covenant-zentrierter Hardfork?

Gemäß Terahs Thread, Kasp bereitet einen auf Bündnisse ausgerichteten Hardfork vor, der für geplant ist Mainnet-Aktivierung am 5. Mai 2026. Das Upgrade erweitert Schicht 1 (L1) Programmierbarkeit durch die Einführung nativer Assets und erweiterter Covenant-Funktionalität. Es schafft außerdem die Grundlage für verifizierbare Programme (vProgs) und Zero-Knowledge (ZK)-Integrationen.

Kaspa funktioniert als Proof-of-Work-Blockchain unter Verwendung einer BlockDAG-Architektur. Crescendo-Upgrade Im Mai 2025 wurde der Durchsatz auf 10 Blöcke pro Sekunde (BPS) erhöht. Der bevorstehende Hardfork baut somit auf dieser Grundlage auf, ohne die Anforderungen an die Knoten oder die Konsensmechanismen zu verändern.

Die Kernentwickler beschreiben das Release als ein eingeschränktes Upgrade. Es konzentriert sich auf die Aktivierung der nativen Token-Ausgabe, programmierbarer Ausgabenregeln und der ZK-Verifizierung auf L1. 

Wie sieht der Zeitplan für den Hardfork am 5. Mai 2026 aus?

Laut Terahs Thread gehen der Aktivierung des Hauptnetzes mehrere Meilensteine ​​voraus:

• Testnet 12 (TN12) Reset: Geplant für Anfang Februar 2026 zur Unterstützung von Covenant- und Native-Asset-Tests.
   
• Sequencer Commitment KIP: Voraussichtlich um den 12. Februar 2026. Dieser Vorschlag führt Payload-Commitments für Miner ein, um die Dezentralisierung in Echtzeit zu stärken.
   
• SilverScript-Veröffentlichung: Eine höhere Programmiersprache zum Schreiben von Programmen auf Kaspa. Sie wurde von Ori Newman und Mitwirkenden entwickelt und vereinfacht die Covenant-Entwicklung.
   
• Mainnet Hardfork: Mai 5, 2026.

Zu den nach dem Hardfork vorgenommenen Verbesserungen gehören DAGKnight, das Ziel eines adaptiven Konsensmechanismus und eines Durchsatzes von über 100 BPS sowie die vollständige Implementierung von vProgs.

Wie funktionieren indigene Vermögenswerte und Vereinbarungen auf Kaspa?

Native Assets auf Ebene 1

Der Hardfork führt native Assets ein, einschließlich Unterstützung für KRC20-TokenDiese Assets existieren direkt auf L1 und können atomar übertragen werden.

Atomare Transfers gelten für:

• Regelmäßige Inline-Vereinbarungen
• ZK- und Nicht-ZK-Pakt-Hinrichtungen
• KRC20-Token-Transfers

Inline-Covenants erzeugen sofortige Nachweise innerhalb der Wallet. Es gibt keine Entkopplung zwischen Transaktionsdaten und Zustandsübergang. Dieses Design unterstützt Atomarität und deterministische Ausführung.

Erweiterte Bündnisse (Bündnisse++)

Kaspas Covenant-System basiert auf der Bitcoin-Forschung zu programmierbaren UTXO-Ausgabebedingungen. Covenants++ erweitert dieses System, um ausdrucksstärkere Transaktionsregeln zu ermöglichen.

Entdecken Sie vielversprechende Projekte...

Vielversprechende Projekte...

(Werbung)

Artikel wird fortgesetzt...

Zu den Anwendungsfällen gehören:

• Sicherheitskontrollen im Tresorstil
• Treuhandmechanismen
• Bedingte Transfers
• Strukturierte Token-Logik

Das System verwendet ein UTXO-Modell anstelle vollständig kontobasierter Smart Contracts.

Was ist ein computergestützter DAG (CDAG)?

Der Hardfork führt den Computational DAG (CDAG) ein.). CDAG protokolliert alle Lese- und Schreibanweisungen von Programmen.

Diese Struktur:

• Verfolgt die Ressourcennutzung
• Regelt Abhängigkeiten zwischen Programmen
• Setzt Gaslieferverpflichtungen durch

Das Design ist vergleichbar mit Ausführungsmodellen in Blockchains wie Solana und Sui, wurde aber vollständig in Kaspas blockDAG-Umgebung implementiert.

CDAG spielt eine zentrale Rolle bei der Ermöglichung der Souveränität von vProgs.

Was sind vProgs und wie unterscheiden sie sich von Smart Contracts?

vProgs sind souveräne Programme, die außerhalb der L1-Ebene ausgeführt werden, während die Ergebnisse auf der L1-Ebene durch Beweise festgelegt werden.

Schlüsseleigenschaften:

• Souveräne Vollstreckung: Jedes vProg definiert seine eigenen Durchsatz- und Abhängigkeitsregeln.
• Gasbasierte Abhängigkeitskontrolle: Ein vProg kann den Zustand eines anderen vProg nur dann lesen, wenn er für den Ressourcenverbrauch Gas bezahlt.
• Nichtatomare Übertragungen: vProgs sind für L1 nicht so transparent wie native Assets. Übertragungen erfolgen asynchron und nicht atomar.
• Umfasste KAS-Anforderung: Jede nicht-inline-basierte Vereinbarung muss umschlossenes KAS über eine kanonische Brücke verwenden. Natives L1 KAS kann nicht direkt verwendet werden.

Dieses Design trennt Berechnung und Zustand von L1, wobei die gemeinsame Sequenzierung und die gemeinsame Abfolge erhalten bleiben.

Wer sollte vProgs entwickeln?

Laut Diskussionen in der Community benötigen die meisten regulären Anwendungsentwickler vProgs möglicherweise nicht.

Allerdings könnten vProgs folgende Zielgruppen ansprechen:

• Appchain-Architekten
• Teams, die Rollup-Systeme evaluieren
• Projekte, die KI-Agenten mit einem großen On-Chain-Zustand entwickeln
• Systemdesigner vergleichen L1-Verträge, L2-Rollups und Hybridmodelle

vProgs kombinieren einheitliche L1-Sequenzierung mit externalisierter Zustands- und Berechnungsverarbeitung.

Welche Rolle spielt Zero-Knowledge (ZK)?

Der Hardfork integriert die ZK-Verifizierung auf L1 und erweitert damit frühere Vorschläge wie beispielsweise KIP-16.

Unterstützte Funktionen umfassen:

• Groth16-Beweisverifizierung
• Vertrauenslose Brücken zu L2-Systemen
• Mögliche datenschutzorientierte Anwendungen

Die ersten Anwendungen sollen direkt im System laufen, wobei die Wallets die Nachweise direkt generieren. Selbst die von Mitwirkenden wie Hans und Maxim entwickelten, auf dem Covenant basierenden ZK-Implementierungen sollen auf Standardhardware lauffähig sein. Für die ersten Bereitstellungen ist keine spezielle Nachweisinfrastruktur erforderlich.

Ein Standard-Laptop kann unter den gegenwärtigen Annahmen Beweise generieren.

Datenschutzorientierte Programme sind nach dem Hardfork technisch möglich. Datenschutz ist jedoch nicht als primärer Schwerpunkt der Roadmap aufgeführt.

In welcher Beziehung steht Sparkle zu vProgs?

Sparkle ist eine von Anton vorgeschlagene Architektur zur Kombination von berechneten DAGs und ZK-Beweisen. Obwohl sowohl Sparkle als auch vProgs CDAG- und ZK-Komponenten verwenden, behandeln sie unterschiedliche Designfragen.

Das charakteristische Merkmal von vProgs ist die Abhängigkeitsregulierung. Jedes Programm kontrolliert seinen Durchsatz und vermeidet beliebige externe Abhängigkeiten. Dieses Modell unterstützt die Kompositionsfähigkeit bei gleichzeitiger Wahrung der Isolation.

Wird der Hardfork Auswirkungen auf die Sicherheit, MEV oder die Knotenanforderungen haben?

• Sicherheitsbudget: Kurzfristig sind keine direkten Auswirkungen zu erwarten. Verbesserungen hängen eher von der tatsächlichen Produktakzeptanz als von Infrastrukturänderungen ab.
   
• Knotenanforderungen: Keine Änderungen.
   
• MEV-Kickback-Auktionen: Angesichts des aktuellen Entwicklungsstands des Ökosystems wird dies als verfrüht angesehen.
   
• PoW-Grinding für STARKs: In den Diskussionen wurde auf das historische Verhalten im frühen Ethereum-Netzwerk verwiesen, wo Adressen mit führenden Nullen die Gaskosten reduzierten, was wiederum zu einem Anstieg der Proof-of-Work-Einsätze führte. Diese Erwähnung erfolgte im Kontext und bezog sich nicht auf ein aktuelles Merkmal.

Was fügt SilverScript hinzu?

SilverScript ist eine höhere Programmiersprache, die für Kaspa-Programme entwickelt wurde. Sie zielt darauf ab, die Entwicklung von Verträgen und Programmen zu vereinfachen.

Zu den Designzielen gehören:

• Lesbare Syntax
• Barrierefreiheit für neue Entwickler
• Kompatibilität mit automatisierten Werkzeugen

Es wird erwartet, dass SilverScript die Hürde für die Entwicklung von Covenant-basierten Anwendungen senken wird, sobald native Assets verfügbar sind.

Fazit

Kaspas Covenant-zentrierter Hardfork erweitert die Layer-1-Funktionalität durch native Assets, erweiterte Covenants und ZK-Verifizierung. Er führt CDAG für die strukturierte Abhängigkeitsverfolgung ein und legt den Grundstein für souveräne vProgs. Das Upgrade erhält die bestehenden Node-Anforderungen und den Proof-of-Work-Konsens und ermöglicht gleichzeitig die programmierbare Token-Ausgabe und atomare Transfers.

Die Aktivierung am 5. Mai 2026 markiert einen technischen Schritt in Kaspas Roadmap. Sie fügt strukturierte Programmierbarkeit auf Protokollebene hinzu und bereitet das Netzwerk auf weitere Upgrades vor, einschließlich DAGKnight und der vollständigen vProgs-Implementierung.

Quellen:

• Kaspa Convenant-zentrierter Hard ForkCountdown auf Kas.live
• Terah X Thread: Bevorstehende Meilensteine ​​und Covenant-zentrierter Hard Fork
• Kaspa-ForschungEin formales Backbone-Modell für den vProg-Berechnungs-DAG