Kaspa erklärt: ein BlockDAG, zehn Blöcke pro Sekunde und wie Multisig funktioniert

Die meisten Proof-of-Work-Chains erzeugen Blöcke einen nach dem anderen: Ein Miner findet einen Block, alle bauen darauf auf, und jeder konkurrierende Block, der im selben Moment gefunden wurde, wird verworfen. Kaspa geht von einer anderen Frage aus: Was wäre, wenn parallele Blöcke gar nicht verschwendet würden?

Die Antwort ist ein BlockDAG – und er ist der Grund, warum Kaspa zehn Blöcke pro Sekunde erzeugen kann und trotzdem Proof of Work bleibt. Da Kaspa-Unterstützung für SSP in Arbeit ist, sehen wir uns an, was Kaspa anders macht und wie Multisig dort funktioniert.

Von der Chain zum DAG

Wenn bei Bitcoin zwei Miner fast gleichzeitig einen Block finden, spaltet sich das Netzwerk vorübergehend. Am Ende setzt sich ein Block durch, der andere wird zum Orphan – die Arbeit, die in ihm steckt, ist schlicht verloren. Damit Orphans selten bleiben, peilt Bitcoin einen Block alle zehn Minuten an: lang genug, damit jeder Block das gesamte Netzwerk erreicht, bevor der nächste gefunden wird.

Kaspa hebt diese Beschränkung auf. Jeder neue Block kann auf mehrere vorherige Blöcke verweisen statt nur auf einen, sodass parallel entstandene Blöcke alle Teil des Ledgers werden. Die Struktur ist dann keine einzelne Kette mehr, sondern ein gerichteter azyklischer Graph – ein DAG.

Ein DAG allein hat allerdings ein Problem: Wenn zwei parallele Blöcke widersprüchliche Transaktionen enthalten, welche zählt? Kaspas Konsensprotokoll GHOSTDAG löst das, indem es alle Blöcke einheitlich ordnet. Es erkennt die gut vernetzte Mehrheit der Blöcke, die von ehrlichen Minern stammen, und bringt alles in eine einzige, gemeinsam anerkannte Reihenfolge – so kommt jeder Node zum selben Urteil darüber, welche Transaktion zuerst kam.

Das Ergebnis: Kaspa kann mit zehn Blöcken pro Sekunde laufen – dem Takt seit dem Crescendo-Upgrade von 2025 –, ohne die Orphan-Verschwendung, die eine Chain bei diesem Tempo lahmlegen würde. Zur Absicherung des Ledgers setzt Kaspa weiterhin auf Proof of Work.

Was das in der Praxis bedeutet

• Schnelle Bestätigungen. Transaktionen werden innerhalb von etwa einer Sekunde aufgenommen. Wie bei jeder Chain gilt: Die Bestätigungstiefe zählt weiterhin, gerade bei größeren Beträgen – jeder darauf aufbauende Block macht eine Transaktion schwerer rückgängig zu machen –, aber diese Tiefe wächst schnell.
• Coins statt Konten. Kaspa nutzt wie Bitcoin das UTXO-Modell: Dein Guthaben besteht aus einzelnen Coins, und beim Ausgeben werden einige davon kombiniert und das Wechselgeld an dich zurückgeschickt.
• Pruning. Kaspa-Nodes speichern nicht die gesamte Historie für immer; ältere Blockdaten werden nach etwa anderthalb Tagen gelöscht. Der aktuelle Zustand ist jederzeit überprüfbar, doch die langfristige Transaktionshistorie liegt bei Indexern und Explorern statt bei jedem Node.
• Kleine Einheiten. Ein KAS entspricht 100.000.000 sompi, der kleinsten Einheit von Kaspa.

Gebühren werden in „Masse“ gemessen

Bitcoin bepreist Blockplatz in Bytes. Kaspa bepreist ihn in Masse, die mehrere Kosten kombiniert:

• Größe – wie viele Bytes die Transaktion belegt.
• Signaturoperationen – jede Signaturprüfung schlägt mit einem festen Betrag zu Buche, daher wiegt eine Multisig-Ausgabe mehr als eine mit nur einem Schlüssel.
• Speicher – eine Regel namens KIP-9 macht Transaktionen teuer, die viele winzige Outputs erzeugen, damit der Ledger nicht mit Dust gefüllt wird.

Bei alltäglichen Überweisungen merkt man davon nichts: Die Gebühren sind gering. Es erklärt aber einige Eigenheiten von Kaspa – etwa, warum das Zurücksenden eines sehr kleinen Wechselgeldbetrags an dich selbst abgelehnt werden kann und warum Wallets vor einer großen Zahlung manchmal viele kleine Coins zusammenführen müssen.

Wie Multisig bei Kaspa funktioniert

Kaspa hat bewusst nur wenige Adresstypen. Eine kaspa:q-Adresse wird von einem einzelnen Schlüssel kontrolliert. Eine kaspa:p-Adresse ist eine Pay-to-Script-Hash-Adresse: Sie legt sich auf ein Skript fest, und zum Ausgeben muss dieses Skript offengelegt und erfüllt werden.

Ein Multisig-Vault ist eine kaspa:p-Adresse, deren Skript besagt: „M dieser N Schlüssel müssen signieren.“ Kaspa verwendet Schnorr-Signaturen, unterstützt auf Konsensebene bis zu 20 Schlüssel pro Skript und leitet Standardtransaktionen mit bis zu 15 weiter. Zwei Details machen die Arbeit damit angenehm:

• Die Transaktions-ID enthält keine Signaturen. Du kennst die endgültige ID einer Transaktion, bevor irgendjemand sie signiert hat – das vereinfacht die Koordination von Signaturen über mehrere Geräte.
• Es gibt keine SegWit- oder Taproot-Schicht. Kaspa hat nur drei Standard-Output-Typen – Einzelschlüssel, dessen ECDSA-Variante und Pay-to-Script-Hash –, also gibt es nur eine Art von Multisig-Vault, die man richtig umsetzen muss.

Eine Feinheit ist für die Sicherheit wichtig. Eine Kaspa-Signatur legt sich nur auf den Betrag des konkreten Inputs fest, den sie signiert, nicht auf die Beträge aller Inputs. Eine sorgfältige Multisig-Wallet lässt daher jeden Unterzeichner die auszugebenden Coins selbst nachschlagen, statt Beträgen zu vertrauen, die ein anderes Gerät liefert.

Kaspa in SSP

SSP fügt Kaspa mit demselben 2-von-2-Modell hinzu wie jede andere Chain: Dein Vault ist eine kaspa:p-Adresse, gebildet aus einem Schlüssel in SSP Wallet und einem auf SSP Key, und jedes Gerät prüft unabhängig, was es signiert. SSP Enterprise wird Kaspa-Vaults mit M-von-N-Freigabe unterstützen.

Noch ist es nicht verfügbar – die Kaspa-Unterstützung befindet sich in den letzten Tests und wird mit Release Notes angekündigt, sobald sie erscheint. Die zugrunde liegende Bibliothek, @runonflux/kaspa-core, ist bereits Open Source für alle, die sie lesen oder wiederverwenden möchten.

Die ehrliche Zusammenfassung

Kaspa nimmt eine vertraute Idee – Proof of Work, der einen UTXO-Ledger absichert – und beseitigt den Engpass „ein Block nach dem anderen“, indem Blöcke einen DAG bilden dürfen. Das Ergebnis sind schnelle Blöcke, Gebühren auf Basis von Masse statt Bytes und ein sauberes Multisig-Design rund um einen einzigen Skripttyp.

Wie bei jeder Chain gilt: Was deine Coins schützt, ist nicht die Blockrate. Es ist, wer die Schlüssel kontrolliert – und bei Multisig, wie viele davon zustimmen müssen.