Kaspa arrive sur SSP, et la bibliothèque qui le rend possible est open source
La prise en charge de Kaspa arrive sur SSP. Ce sera le même multisig 2-sur-2 que vous utilisez déjà pour Bitcoin, Ethereum et Solana : une clé dans SSP Wallet, une sur SSP Key, et rien ne bouge sans l'accord des deux. Les coffres entreprise auront aussi Kaspa.
Pour y parvenir, il a fallu construire quelque chose qui n'existait pas. Aujourd'hui, nous pouvons partager la partie déjà publique : @runonflux/kaspa-core, une bibliothèque TypeScript open source pour les transactions et le multisig Kaspa, publiée sous licence MIT.
Pourquoi nous avons d'abord construit une bibliothèque
Quand nous avons envisagé d'ajouter Kaspa, nous avons passé en revue tous les paquets JavaScript Kaspa que nous avons pu trouver. Aucun n'était réellement capable de construire et de signer de bout en bout une transaction multisig Kaspa, ce dont SSP a besoin avant tout.
La voie officielle, c'est le code Rust de Kaspa compilé en WebAssembly. C'est un excellent logiciel, mais il convient mal à SSP. SSP Key tourne sous React Native, où WebAssembly n'est pas disponible, et l'extension de navigateur doit rester légère : le paquet WebAssembly pèse à lui seul plus de 11 Mo.
Nous avons donc réécrit de zéro les règles de transaction de Kaspa en TypeScript pur : adresses, scripts, multisig M-sur-N, hachages de signature, signature Schnorr, calcul des frais et de la « masse », et sélection des entrées. La bibliothèque a deux dépendances d'exécution, les bibliothèques cryptographiques @noble, largement utilisées et auditées, et fonctionne sans modification dans les navigateurs, les extensions, Node et React Native.
Comment nous l'avons vérifiée
Pour du code de portefeuille, « ça a l'air de marcher » n'est pas un critère. La bibliothèque est conçue pour être, de façon démontrable, identique au nœud Kaspa lui-même :
- Vérifiée face au code de Kaspa. La suite de tests exécute chaque fonction critique pour le consensus face à rusty-kaspa, l'implémentation de référence du nœud, et fait passer des transactions signées par la bibliothèque dans son véritable moteur de scripts, y compris toutes les combinaisons M-sur-N de 1-sur-1 à 15-sur-15.
- De vraies données du mainnet. Des identifiants de transaction et des signatures existants du mainnet sont reproduits à l'identique.
- Des transactions financées sur le mainnet. Quinze vraies transactions, dont des dépenses 2-sur-2 façon SSP, un 2-sur-3 et des multisigs de type entreprise 4-sur-7, 6-sur-10 et 10-sur-15, ont été construites et signées avec la bibliothèque puis acceptées par le réseau. Pour chacune, le calcul de la masse de la transaction par le nœud correspondait exactement au nôtre.
- Revue adverse. Plusieurs cycles de revue de sécurité ont cherché spécifiquement des moyens de tromper un signataire ou de gonfler des frais. Aucun problème critique n'a été trouvé, et chaque constat a été corrigé avec un test de non-régression. Le rapport est publié avec le code.
Le code ouvert relève du même principe que les builds reproductibles : vous ne devriez pas avoir à nous croire sur parole quant à ce qui signe vos transactions.
À quoi ressemblera Kaspa dans SSP
Votre coffre Kaspa sera une adresse multisig Kaspa (elle commence par kaspa:p), dérivée de vos deux appareils selon le chemin de dérivation habituel de SSP. L'envoi fonctionnera comme sur les autres chaînes : SSP Wallet prépare et signe sa moitié, SSP Key vous montre les destinataires, le montant et les frais, et ce n'est qu'après votre approbation sur SSP Key que la transaction atteint le réseau. C'est le même modèle 2-sur-2, sur une nouvelle chaîne.
Quelques particularités de Kaspa ont façonné la conception :
- Chaque appareil vérifie lui-même les montants. Une signature Kaspa n'engage que le montant de l'entrée qu'elle signe ; un appareil qui ferait confiance aux montants qu'on lui transmet pourrait donc être trompé sur les frais. Dans SSP, chaque appareil consulte lui-même les pièces dépensées avant de signer, et ne signe que pour son propre coffre.
- L'identifiant de transaction est connu avant la signature. L'identifiant de transaction de Kaspa n'inclut pas les signatures, si bien que SSP peut fixer une transaction à son identifiant définitif avant qu'aucune des clés ne l'ait signée.
- Des plafonds de frais sont intégrés. Les frais sont plafonnés, de sorte qu'une mauvaise estimation ne peut pas se transformer en erreur coûteuse.
Pour les entreprises, les coffres SSP Enterprise prendront en charge Kaspa avec une approbation M-sur-N, jusqu'à la limite standard de Kaspa de 15 clés par coffre.
Ce qui ne fait pas partie de la première version
Nous préférons livrer une petite chose bien faite qu'une grande chose approximative. La première version couvre KAS lui-même sur le mainnet. Les jetons KRC-20, le testnet Kaspa, la signature de messages Kaspa et WalletConnect pour Kaspa ne seront pas inclus au lancement.
Quand
La prise en charge de Kaspa est implémentée dans SSP Wallet, SSP Key et SSP Enterprise, et passe actuellement les derniers tests. Nous l'annoncerons ici, avec des notes de version, lorsqu'elle sera disponible. D'ici là, il n'y a rien à activer ni rien à télécharger, et quiconque vous affirme le contraire, ce n'est pas nous.
En attendant, les développeurs peuvent utiliser la bibliothèque dès aujourd'hui : elle est sur npm sous le nom @runonflux/kaspa-core et sur GitHub à RunOnFlux/kaspa-core.
