Kaspa spiegato: un blockDAG, dieci blocchi al secondo e come funziona il multisig
La maggior parte delle catene proof-of-work produce i blocchi uno alla volta: un miner trova un blocco, tutti ci costruiscono sopra e qualsiasi blocco concorrente trovato nello stesso momento viene scartato. Kaspa parte da una domanda diversa: e se i blocchi paralleli non andassero sprecati affatto?
La risposta è un blockDAG, ed è il motivo per cui Kaspa può produrre dieci blocchi al secondo pur restando proof-of-work. Ora che il supporto a Kaspa sta arrivando in SSP, ecco cosa lo rende diverso e come vi funziona il multisig.
Dalla catena al DAG
In Bitcoin, se due miner trovano un blocco quasi nello stesso momento, la rete si biforca temporaneamente. Alla fine un blocco prevale e l'altro diventa orfano: il lavoro che c'è dietro va semplicemente perso. Per mantenere rari gli orfani, Bitcoin punta a un blocco ogni dieci minuti, un tempo sufficiente perché ogni blocco raggiunga tutta la rete prima che venga trovato il successivo.
Kaspa elimina questo vincolo. Ogni nuovo blocco può fare riferimento a più blocchi precedenti invece che a uno solo, così tutti i blocchi creati in parallelo entrano a far parte del registro. La struttura smette di essere una singola catena e diventa un grafo aciclico diretto: un DAG.
Un DAG da solo ha però un problema: se due blocchi paralleli contengono transazioni in conflitto, quale vale? Il protocollo di consenso di Kaspa, GHOSTDAG, lo risolve ordinando tutti i blocchi in modo coerente. Individua la maggioranza ben connessa di blocchi prodotti da miner onesti e mette tutto in un unico ordine condiviso, così ogni nodo arriva allo stesso verdetto su quale transazione sia venuta prima.
Il risultato è che Kaspa può funzionare a dieci blocchi al secondo — il ritmo in vigore dall'aggiornamento Crescendo del 2025 — senza lo spreco di orfani che paralizzerebbe una catena a quella velocità. Per proteggere il registro continua a usare la proof-of-work.
Cosa significa in pratica
- Conferme rapide. Le transazioni vengono incluse nel giro di un secondo circa. Come su qualsiasi catena, la profondità di conferma conta ancora per gli importi più grandi — ogni blocco costruito sopra rende una transazione più difficile da annullare — ma quella profondità si accumula in fretta.
- Monete, non conti. Kaspa usa il modello UTXO, come Bitcoin: il tuo saldo è un insieme di singole monete, e una spesa ne combina alcune e ti rimanda il resto.
- Pruning. I nodi di Kaspa non conservano per sempre l'intera cronologia; i dati dei blocchi più vecchi vengono eliminati dopo circa un giorno e mezzo. Lo stato attuale è sempre verificabile, ma la cronologia delle transazioni a lungo termine è custodita da indicizzatori ed explorer anziché da ogni nodo.
- Unità piccole. Un KAS equivale a 100.000.000 sompi, l'unità più piccola di Kaspa.
Le commissioni si misurano in «massa»
Bitcoin dà un prezzo allo spazio nei blocchi in byte. Kaspa lo fa in massa, che combina diversi costi:
- Dimensione — quanti byte occupa la transazione.
- Operazioni di firma — ogni verifica di firma aggiunge una quantità fissa, quindi una spesa multisig pesa più di una a chiave singola.
- Archiviazione — una regola nota come KIP-9 rende costose le transazioni che creano molti output minuscoli, per evitare che il registro si riempia di polvere.
Per gli invii di tutti i giorni tutto questo è invisibile: le commissioni sono basse. Ma spiega alcune particolarità di Kaspa, per esempio perché rimandare a te stesso un resto molto piccolo può essere rifiutato, e perché a volte i wallet devono consolidare molte piccole monete prima di un pagamento importante.
Come funziona il multisig su Kaspa
Kaspa ha volutamente pochi tipi di indirizzo. Un indirizzo kaspa:q è controllato da una singola chiave. Un indirizzo kaspa:p è un indirizzo pay-to-script-hash: si impegna su uno script, e per spendere occorre rivelare quello script e soddisfarlo.
Un vault multisig è un indirizzo kaspa:p il cui script dice «M di queste N chiavi devono firmare». Kaspa usa firme Schnorr, supporta fino a 20 chiavi per script a livello di consenso e inoltra transazioni standard con un massimo di 15. Due dettagli lo rendono piacevole da usare:
- L'ID della transazione non include le firme. Conosci l'ID definitivo di una transazione prima che qualcuno l'abbia firmata, il che semplifica il coordinamento delle firme tra dispositivi.
- Non c'è un livello SegWit o Taproot. Kaspa ha solo tre tipi di output standard — a chiave singola, la sua variante ECDSA e pay-to-script-hash — quindi c'è un solo tipo di vault multisig da realizzare correttamente.
C'è una sottigliezza importante per la sicurezza. Una firma Kaspa si impegna solo sull'importo dello specifico input che firma, non sugli importi di tutti gli input. Un wallet multisig scrupoloso fa quindi verificare a ciascun firmatario, per conto proprio, le monete che vengono spese, invece di fidarsi degli importi forniti da un altro dispositivo.
Kaspa in SSP
SSP sta aggiungendo Kaspa con lo stesso modello 2-di-2 di tutte le altre catene: il tuo vault è un indirizzo kaspa:p costruito a partire da una chiave in SSP Wallet e una su SSP Key, e ogni dispositivo verifica in modo indipendente ciò che sta firmando. SSP Enterprise supporterà i vault Kaspa con approvazione M-di-N.
Non è ancora disponibile: il supporto a Kaspa è nella fase finale di test e verrà annunciato con le note di rilascio al momento dell'uscita. La libreria su cui si basa, @runonflux/kaspa-core, è già open source per chiunque voglia leggerla o riutilizzarla.
Il riassunto onesto
Kaspa prende un'idea familiare — la proof-of-work che protegge un registro UTXO — ed elimina il collo di bottiglia del blocco-alla-volta lasciando che i blocchi formino un DAG. Il risultato sono blocchi veloci, commissioni basate sulla massa anziché sui byte e un design multisig pulito costruito attorno a un solo tipo di script.
Come su qualsiasi catena, a proteggere le tue monete non è la frequenza dei blocchi. È chi controlla le chiavi e, con il multisig, quante di esse devono essere d'accordo.
