Prossimo hardfork incentrato sui patti di Kaspa: cosa sappiamo

Cos'è l'hardfork incentrato sui patti di Kaspa?

Secondo Il filo di Terah, Caspa sta preparando un hardfork incentrato sui patti previsto per attivazione della rete principale il 5 maggio 2026. L'aggiornamento si espande Livello 1 (L1) programmabilità introducendo risorse native e funzionalità di covenant estese. Pone inoltre le basi per programmi verificabili (vProgs) e integrazioni a conoscenza zero (ZK).

Kaspa opera come una blockchain proof-of-work utilizzando un'architettura blockDAG. Il suo Aggiornamento Crescendo a maggio 2025 ha aumentato la capacità di elaborazione a 10 blocchi al secondo (BPS). Pertanto, il prossimo hardfork si basa su questa base senza modificare i requisiti dei nodi o i principi fondamentali del consenso.

Gli sviluppatori principali descrivono la release come un aggiornamento mirato. Si concentra sull'abilitazione dell'emissione nativa di token, regole di spesa programmabili e verifica ZK su L1. 

Qual è la tempistica per l'hardfork del 5 maggio 2026?

Secondo il thread di Terah, l'attivazione della rete principale è preceduta da diverse tappe fondamentali:

• Reimpostazione Testnet 12 (TN12): Previsto per l'inizio di febbraio 2026 per supportare i test sui patti e sulle risorse native.
   
• KIP di impegno del sequenziatore: Previsto per il 12 febbraio 2026. Questa proposta introduce impegni di carico utile per i miner per rafforzare la decentralizzazione in tempo reale.
   
• Versione SilverScript: Un linguaggio di programmazione di alto livello per scrivere programmi su Kaspa. Sviluppato da Ori Newman e collaboratori, semplifica lo sviluppo di covenant.
   
• Hardfork della rete principale: 5 Maggio 2026.

Gli aggiornamenti post-hardfork includono DAGKnight, che punta al consenso adattivo e a una produttività superiore a 100 BPS, e la distribuzione completa di vProgs.

Come funzionano le risorse native e i patti su Kaspa?

Risorse native sul livello 1

L'hardfork introduce risorse native, incluso il supporto per Token KRC20Queste risorse esistono direttamente su L1 e possono essere trasferite atomicamente.

I trasferimenti atomici si applicano a:

• Patti in linea regolari
• Esecuzioni di patti ZK e non ZK
• Trasferimenti di token KRC20

I patti inline generano prove immediate all'interno del portafoglio. Non vi è alcun disaccoppiamento tra i dati delle transazioni e la transizione di stato. Questa progettazione supporta l'atomicità e l'esecuzione deterministica.

Patti estesi (Covenants++)

Il sistema di patti di Kaspa si ispira alla ricerca di Bitcoin sulle condizioni di spesa UTXO programmabili. Covenants++ estende questo sistema per consentire regole di transazione più esplicite.

Scopri progetti promettenti...

Progetti promettenti...

(Annuncio pubblicitario)

L'articolo continua...

I casi d'uso includono:

• Controlli di sicurezza in stile Vault
• Meccanismi di deposito a garanzia
• Trasferimenti condizionati
• Logica del token strutturato

Il sistema mantiene un modello UTXO anziché contratti intelligenti basati su account completi.

Che cos'è il Computational DAG (CDAG)?

L'hardfork introduce il Computational DAG (CDAG). CDAG registra tutte le dichiarazioni di lettura e scrittura effettuate dai programmi.

Questa struttura:

• Tiene traccia dell'utilizzo delle risorse
• Regola le dipendenze tra i programmi
• Fa rispettare gli impegni sul gas

Il design è paragonabile ai modelli di esecuzione di blockchain come Solana e Sui, ma implementato nella sua forma completa nell'ambiente blockDAG di Kaspa.

CDAG svolge un ruolo centrale nel garantire la sovranità di vProgs.

Cosa sono i vProg e in che modo differiscono dagli Smart Contract?

I vProg sono programmi sovrani che vengono eseguiti al di fuori di L1, mentre stabiliscono i risultati su L1 tramite dimostrazioni.

Proprietà chiave:

• Esecuzione sovrana: Ogni vProg definisce le proprie regole di throughput e di dipendenza.
• Controllo della dipendenza basato sul gas: Un vProg non può leggere lo stato di un altro vProg a meno che non paghi gas per il consumo di risorse.
• Trasferimenti non atomici: I vProg non sono trasparenti a L1 come gli asset nativi. I trasferimenti sono asincroni e non atomici.
• Requisito KAS avvolto: Qualsiasi patto non in linea deve utilizzare il KAS incapsulato tramite un bridge canonico. Il KAS L1 nativo non può essere utilizzato direttamente.

Questa progettazione separa il calcolo e lo stato da L1, preservando al contempo la sequenza e la risoluzione condivise.

Chi dovrebbe sviluppare vProgs?

Secondo le discussioni della comunità, la maggior parte degli sviluppatori di applicazioni tradizionali potrebbe non aver bisogno di vProgs.

Tuttavia, vProgs potrebbe interessare:

• Architetti di Appchain
• Team che valutano sistemi in stile rollup
• Progetti che costruiscono agenti di intelligenza artificiale con un ampio stato on-chain
• Progettisti di sistemi che confrontano contratti L1, rollup L2 e modelli ibridi

vProgs combina il sequenziamento L1 unificato con stato e calcolo esternalizzati.

Quale ruolo gioca la conoscenza zero (ZK)?

L'hardfork integra la verifica ZK su L1, estendendo proposte precedenti come KIP-16.

Le funzionalità supportate includono:

• Verifica della prova Groth16
• Ponti senza fiducia verso i sistemi L2
• Potenziali applicazioni orientate alla privacy

Si prevede che le applicazioni iniziali funzionino in-line, con i wallet che generano le prove direttamente. Anche le implementazioni ZK basate su covenant sviluppate da contributori come Hans e Maxim dovrebbero funzionare su hardware di base. Non è richiesta alcuna infrastruttura di prova specializzata per le prime implementazioni.

Un normale computer portatile può generare dimostrazioni in base alle ipotesi attuali.

I programmi incentrati sulla privacy saranno tecnicamente possibili dopo l'hardfork. Tuttavia, la privacy non è elencata come obiettivo primario della roadmap.

Qual è il rapporto tra Sparkle e vProgs?

Sparkle è un'architettura proposta da Anton per combinare DAG computazionali e dimostrazioni ZK. Sebbene Sparkle e vProgs utilizzino componenti CDAG e ZK, affrontano problematiche progettuali diverse.

La caratteristica distintiva di vProgs è la regolazione delle dipendenze. Ogni programma controlla la propria produttività ed evita dipendenze esterne arbitrarie. Questo modello supporta la componibilità preservando l'isolamento.

L'hardfork influirà sui requisiti di sicurezza, MEV o dei nodi?

• Bilancio per la sicurezza: Non si prevede alcun impatto diretto nel breve termine. I miglioramenti dipenderanno dall'effettiva adozione del prodotto, piuttosto che da modifiche infrastrutturali.
   
• Requisiti del nodo: Nessun cambiamento.
   
• Aste di tangenti MEV: Considerato prematuro, data l'attuale fase di sviluppo dell'ecosistema.
   
• Rettifica PoW per STARK: Le discussioni fanno riferimento al comportamento storico dei primi Ethereum, dove gli indirizzi con zeri iniziali riducevano i costi del gas, il che a sua volta portava a un'inversione di tendenza dei mercati basata sulla proof-of-work. La menzione era contestuale, non una caratteristica attuale.

Cosa aggiunge SilverScript?

SilverScript è un linguaggio di alto livello progettato per i programmi Kaspa. Il suo obiettivo è semplificare lo sviluppo di convenzioni e programmi.

I suoi obiettivi di progettazione includono:

• Sintassi leggibile
• Accessibilità per i nuovi sviluppatori
• Compatibilità con utensili automatizzati

Si prevede che SilverScript abbasserà le barriere per la scrittura di applicazioni basate su covenant una volta che le risorse native saranno attive.

Conclusione

L'hardfork di Kaspa, incentrato sui covenant, espande le funzionalità del Layer 1 attraverso asset nativi, covenant estesi e verifica ZK. Introduce il CDAG per il tracciamento strutturato delle dipendenze e getta le basi per vProgs sovrani. L'aggiornamento preserva i requisiti dei nodi esistenti e il consenso proof-of-work, consentendo al contempo l'emissione di token programmabili e i trasferimenti atomici.

L'attivazione del 5 maggio 2026 segna una tappa tecnica nella roadmap di Kaspa. Aggiunge programmabilità strutturata a livello di protocollo e prepara la rete per ulteriori aggiornamenti, tra cui DAGKnight e l'implementazione completa di vProgs.

Fonti:

• Hard Fork Kaspa Convenant-centrico: Conto alla rovescia su Kas.live
• Terah X Thread: Prossimi traguardi e hard fork incentrato sui patti
• Ricerca Kaspa: Un modello formale di backbone per il DAG di calcolo vProg