Kaspa kommt zu SSP – und die Bibliothek dahinter ist Open Source
Kaspa-Unterstützung für SSP ist unterwegs. Es wird dasselbe 2-von-2-Multisig sein, das du bereits für Bitcoin, Ethereum und Solana nutzt: ein Schlüssel in SSP Wallet, einer in SSP Key, und nichts bewegt sich, solange nicht beide zustimmen. Auch Enterprise-Vaults bekommen Kaspa.
Um dorthin zu kommen, mussten wir etwas bauen, das es noch nicht gab. Heute können wir den Teil teilen, der bereits öffentlich ist: @runonflux/kaspa-core, eine Open-Source-TypeScript-Bibliothek für Kaspa-Transaktionen und Multisig, veröffentlicht unter der MIT-Lizenz.
Warum wir zuerst eine Bibliothek gebaut haben
Als wir uns Kaspa vorgenommen haben, haben wir jedes JavaScript-Paket für Kaspa geprüft, das wir finden konnten. Keines davon konnte eine Kaspa-Multisig-Transaktion tatsächlich vollständig erstellen und signieren – genau das, was SSP mehr als alles andere braucht.
Der offizielle Weg ist Kaspas Rust-Code, kompiliert zu WebAssembly. Das ist hervorragende Software, passt aber schlecht zu SSP. SSP Key läuft auf React Native, wo WebAssembly nicht verfügbar ist, und die Browser-Erweiterung muss schlank bleiben – allein das WebAssembly-Paket ist größer als 11 MB.
Also haben wir Kaspas Transaktionsregeln von Grund auf in reinem TypeScript geschrieben: Adressen, Skripte, M-von-N-Multisig, Signatur-Hashes, Schnorr-Signaturen, Gebühren- und „Mass“-Berechnung sowie Input-Auswahl. Die Bibliothek hat zwei Laufzeitabhängigkeiten – die weit verbreiteten, auditierten @noble-Kryptografiebibliotheken – und läuft unverändert in Browsern, Erweiterungen, Node und React Native.
Wie wir sie geprüft haben
Bei Wallet-Code ist „scheint zu funktionieren“ kein Maßstab. Die Bibliothek ist darauf ausgelegt, nachweislich identisch mit dem Kaspa-Node selbst zu sein:
- Geprüft gegen Kaspas eigenen Code. Die Testsuite lässt jede konsenskritische Funktion gegen rusty-kaspa laufen, die Referenzimplementierung des Nodes, und führt von der Bibliothek signierte Transaktionen durch dessen echte Script-Engine – einschließlich jeder M-von-N-Kombination von 1-von-1 bis 15-von-15.
- Echte Mainnet-Daten. Bestehende Transaktions-IDs und Signaturen aus dem Mainnet werden exakt reproduziert.
- Finanzierte Mainnet-Transaktionen. Fünfzehn echte Transaktionen – darunter 2-von-2-Ausgaben im SSP-Stil, ein 2-von-3 sowie Multisigs im Enterprise-Stil mit 4-von-7, 6-von-10 und 10-von-15 – wurden mit der Bibliothek erstellt und signiert und vom Netzwerk akzeptiert. Bei jeder einzelnen stimmte die Berechnung der Transaktions-Mass durch den Node exakt mit unserer überein.
- Adversariales Review. Mehrere Runden Sicherheitsreview suchten gezielt nach Wegen, einen Signierer zu täuschen oder eine Gebühr aufzublähen. Es wurden keine kritischen Probleme gefunden, und jeder Befund wurde mit einem Regressionstest behoben. Der Bericht ist zusammen mit dem Code veröffentlicht.
Offener Code folgt demselben Prinzip wie reproduzierbare Builds: Du solltest dich nicht auf unser Wort verlassen müssen, was deine Transaktionen signiert.
So wird Kaspa in SSP aussehen
Dein Kaspa-Vault wird eine Kaspa-Multisig-Adresse sein (sie beginnt mit kaspa:p), abgeleitet aus beiden deiner Geräte über SSPs üblichen Ableitungspfad. Senden funktioniert wie bei anderen Chains: SSP Wallet bereitet seine Hälfte vor und signiert sie, SSP Key zeigt dir Empfänger, Betrag und Gebühr, und erst wenn du dort zustimmst, erreicht die Transaktion das Netzwerk. Es ist dasselbe 2-von-2-Modell, auf einer neuen Chain.
Einige Kaspa-spezifische Details haben das Design geprägt:
- Jedes Gerät prüft die Beträge selbst. Eine Kaspa-Signatur bezieht sich nur auf den Betrag des Inputs, den sie signiert. Ein Gerät, das ihm übergebenen Beträgen vertraut, könnte also über die Gebühr getäuscht werden. In SSP ruft jedes Gerät die ausgegebenen Coins vor dem Signieren selbst ab und signiert nur für seinen eigenen Vault.
- Die Transaktions-ID ist vor dem Signieren bekannt. Kaspas Transaktions-ID enthält die Signaturen nicht, daher kann SSP eine Transaktion auf ihre endgültige ID festlegen, bevor einer der beiden Schlüssel sie signiert hat.
- Gebührenobergrenzen sind eingebaut. Gebühren sind gedeckelt, sodass eine schlechte Gebührenschätzung nicht zu einem teuren Fehler werden kann.
Für Unternehmen werden SSP-Enterprise-Vaults Kaspa mit M-von-N-Freigabe unterstützen, bis zu Kaspas Standardlimit von 15 Schlüsseln pro Vault.
Was im ersten Release nicht enthalten ist
Wir liefern lieber etwas Kleines gut als etwas Großes halbherzig. Das erste Release umfasst KAS selbst im Mainnet. KRC-20-Token, das Kaspa-Testnet, Kaspa-Nachrichtensignierung und WalletConnect für Kaspa sind zum Start nicht enthalten.
Wann
Die Kaspa-Unterstützung ist in SSP Wallet, SSP Key und SSP Enterprise implementiert und befindet sich gerade in den abschließenden Tests. Wir kündigen sie hier mit Release Notes an, sobald sie verfügbar ist – bis dahin gibt es nichts zu aktivieren und nichts herunterzuladen, und wer dir etwas anderes erzählt, sind nicht wir.
In der Zwischenzeit können Entwickler die Bibliothek schon heute nutzen: Sie ist auf npm als @runonflux/kaspa-core und auf GitHub unter RunOnFlux/kaspa-core verfügbar.
