L'hard fork Toccata di Kaspa: alleanze, codici operativi ZK e un nuovo obiettivo di giugno

CaspaIl prossimo hard fork di Toccata aggiungerà due nuovi percorsi di programmabilità alla rete: la programmazione nativa L1 covenant e l'infrastruttura applicativa basata su zero-knowledge (zk), con l'attivazione della mainnet ora prevista tra il 5 e il 20 giugno 2026, posticipata rispetto alla data originaria del 5 maggio.

Michael Sutton di Kaspa Core ha pubblicato un aggiornamento dettagliato Su cosa include l'hard fork, perché la data è stata spostata e come ci si aspetta che si evolvano i prossimi mesi. Il fork è stato inizialmente avviato da Ori Newman nel tentativo di introdurre i covenant nel motore di script di Kaspa, in parte in risposta alla discussione su OP_CAT negli ambienti Bitcoin. Da allora si è evoluto in qualcosa di considerevolmente più grande.

Cos'è la Toccata Hard Fork?

Toccata è un hard fork programmato per la rete Kaspa che introduce nuove funzionalità direttamente nel livello base. Un hard fork, per chi non lo sapesse, è un aggiornamento del protocollo non retrocompatibile. Tutti i nodi devono essere aggiornati per continuare a partecipare alla rete.

Il nome segue la tradizione di Kaspa di utilizzare riferimenti musicali per gli aggiornamenti più importanti. Questo modello prende il nome da una forma musicale classica, la toccata, un brano concepito per mettere in mostra l'abilità tecnica su uno strumento a tastiera.

In linea generale, Toccata aggiunge due elementi a Kaspa:

• Programmazione nativa L1 del patto tramite un nuovo compilatore chiamato Silverscript
• Infrastruttura applicativa basata su zk, costruito sulle stesse fondamenta dell'alleanza

Questi sistemi non sono intercambiabili. Servono a casi d'uso diversi e si rivolgono a pubblici di sviluppatori differenti.

Che cosa sono i patti e perché sono importanti per Kaspa?

I covenant sono condizioni imposte che regolano le modalità di utilizzo dei fondi in una transazione. In una transazione Bitcoin o Kaspa standard, una volta inviate le monete, il destinatario può farne ciò che vuole. I covenant cambiano questa situazione, incorporando le regole di spesa direttamente nello script.

Kaspa utilizza un modello UTXO, simile a Bitcoin, in cui ogni transazione consuma output esistenti e ne crea di nuovi. I covenant in un sistema UTXO consentono agli sviluppatori di costruire flussi multi-contratto con stato sorprendentemente complessi, anche se il calcolo sottostante rimane locale a ciascun UTXO.

Per rendere lo sviluppo di covenant più accessibile, Kaspa Core sta finalizzando Silverscript, un compilatore ideato da Ori Newman, Michael Sutton, IzioDev e Manyfest. Silverscript è progettato per semplificare e rendere più sicura la scrittura e la distribuzione di covenant complessi direttamente su Kaspa L1, senza che gli sviluppatori debbano lavorare a livello del motore di scripting.

Quali sono le applicazioni basate su ZK?

Il secondo pilastro di programmabilità introdotto in Toccata si basa sulle applicazioni zk. Questo è il più complesso dal punto di vista tecnico dei due e merita un'analisi approfondita.

Scopri progetti promettenti...

Progetti promettenti...

(Annuncio pubblicitario)

L'articolo continua...

ZK sta per zero-knowledge, un metodo crittografico che permette a una parte di dimostrare la veridicità di qualcosa senza rivelare i dati sottostanti. Le prove ZK sono sempre più utilizzate nella scalabilità delle blockchain perché consentono di verificare in modo economico e sicuro i calcoli off-chain.

In questo contesto, "basato" significa che il sistema zk segue completamente la sequenza L1. Un'applicazione zk basata non può aggiungere o eliminare transazioni in modo indipendente. È ancorata all'ordine delle transazioni di Kaspa, ed è questo che la rende affidabile senza bisogno di un sequencer separato.

Toccata introduce diversi componenti a supporto di ciò:

• Codici operativi di verifica ZK, tra cui un verificatore Groth16 flessibile e un verificatore RISC Zero STARK
• Un opcode di accesso all'impegno di sequenziamento, consentendo alle applicazioni basate di ancorarsi all'ordinamento L1
• KIP-21, un'architettura di impegno di sequenziamento partizionata che garantisce che i costi di dimostrazione di un'app zk siano scalabili in base alla sua attività, non all'attività complessiva del DAG.

Il verificatore RISC Zero STARK è già stato implementato e attivato sulla testnet 12. La sua attivazione sulla mainnet è ancora in fase di valutazione.

Perché dimostrare i costi è importante

Affinché un'applicazione zk sia pratica, il costo di generazione delle prove deve rimanere proporzionale alle attività svolte dall'applicazione stessa. Se un'applicazione zk dovesse dimostrare il lavoro svolto rispetto a tutte le attività sul DAG più ampio, i costi diventerebbero imprevedibili e ingestibili. KIP-21 risolve questo problema suddividendo gli impegni di sequenziamento, mantenendo il carico di lavoro di ciascuna applicazione autonomo.

Cosa è già presente?

Una parte significativa dell'hard fork è già stata implementata. Le seguenti funzionalità sono già state realizzate:

• Supporto esteso per gli opcode del motore di script, la spina dorsale dei patti principali, ai sensi del KIP-17
• ID di patto per la gestione del lignaggio come funzionalità di consenso e motore, nell'ambito di KIP-20
• Codici operativi ZK con un sottosistema di precompilazione zk-verifier, sotto KIP-16, a cura di Alexander Safstrom
• Codice operativo di accesso all'impegno di sequenziamento
• KIP-21, elaborato da Sutton e implementato da Maxim Biryukov, è stato completamente implementato ed è in attesa di revisione.

Maxim ha inoltre completato le fasi di verifica del concetto, tra cui i covenant zk in linea e i covenant zk basati su un ponte canonico KAS, che sono state determinanti nella definizione del design finale della forcella.

Perché la data dell'hard fork è stata spostata a giugno?

La data di lancio della mainnet era inizialmente prevista per il 5 maggio 2026. Successivamente, è stata posticipata al periodo compreso tra il 5 e il 20 giugno 2026.

Il motivo è di natura architettonica. Una volta che i circuiti e i runtime di zk si legano a una struttura di hashing per l'impegno di sequenziamento, qualsiasi modifica strutturale successiva diventa una modifica incompatibile con le versioni precedenti. Commettere un errore di progettazione e correggerlo in seguito sarebbe molto più problematico che prendersi il tempo necessario ora.

KIP-21 è già stato progettato per essere compatibile in futuro con lo schema di impegno che sarà richiesto da vprogs, la roadmap a lungo termine di Kaspa per i programmi verificabili componibili in modo sincrono. Definire la struttura corretta prima dell'attivazione della mainnet evita costose migrazioni successive.

Il blocco delle nuove funzionalità è previsto per il 15 aprile 2026.

Cosa succede tra il blocco delle funzionalità e la rete principale?

Dopo il blocco delle funzionalità del 15 aprile, Kaspa Core prevede un riavvio pulito della testnet dedicata, TN12, con l'intero set di funzionalità finali incluso. Non si tratta di una simulazione della transizione all'hard fork, bensì di una rete pulita per testare l'intero set di funzionalità nella sua forma definitiva.

A partire da lì, il team integrerà nel codice sorgente principale il lavoro accumulato in mesi di sviluppo su un ramo in sospeso da tempo. Questo processo prevede la verifica finale, la chiusura delle attività in sospeso, il perfezionamento della logica di attivazione dell'hard fork e la gestione dell'aggiornabilità del database.

Una volta completato questo lavoro, verrà eseguito un hard fork di prova su TN10, la testnet a lungo termine, per simulare una transizione completa in stile mainnet. La data di lancio della mainnet verrà definita in modo definitivo solo dopo che questa prova avrà dato esito positivo al team.

Cosa dovrebbero aspettarsi gli operatori dei nodi

Per i miner e gli operatori dei nodi, l'aggiornamento è progettato per essere semplice. I nodi devono essere aggiornati e le funzionalità esistenti dovrebbero continuare a funzionare. Si prevede un aumento dello spazio su disco richiesto di circa il 20-50%. Non sono previsti cambiamenti infrastrutturali drastici.

Cosa Toccata effettivamente offre a Kaspa

Toccata aggiunge due sistemi di programmabilità funzionanti al livello base di Kaspa: lo scripting nativo L1 Covenant tramite Silverscript e l'infrastruttura applicativa basata su zk tramite KIP-16, KIP-20 e KIP-21. Gran parte del lavoro tecnico è già stato completato. Ciò che resta da fare è finalizzare le interfacce, unire il ramo in sospeso al ramo master ed eseguire una prova completa su TN10 prima che venga confermata la data di rilascio sulla mainnet.

La finestra temporale dal 5 al 20 giugno 2026 è stata scelta perché il team ha deciso di definire correttamente l'architettura di sequenziamento fin da subito, anziché correggerla in seguito in condizioni operative. Per gli operatori dei nodi, l'aggiornamento è progettato per essere semplice, senza modifiche sostanziali all'infrastruttura, a parte un modesto aumento dello spazio su disco.

Risorse

1. Kaspa su XPost (aprile 2026)

2. Articolo del blog di Michael Sutton: Kaspa Covenants++ “Toccata” Hard-Fork Outlook