Le Forum de coordination KCC de Kaspa a finalisé trois normes couvrant les interfaces de covenant, l'autorisation et les jetons fongibles, établissant des spécifications partagées pour les développeurs construisant des applications sur le réseau.
Résumé
- KCC-1 définit des interfaces partagées pour les portefeuilles, les compilateurs, les indexeurs et autres outils travaillant avec les covenants.
- KCC-2 spécifie cinq schémas d'autorisation standard, incluant les clés publiques, les scripts et les identifiants de covenant.
- KCC-20 établit les règles de transfert de jetons et prend en charge la réception de jetons via une sortie compatible existante.
- La finalisation établit des conventions écosystémiques sans modifier les règles de consensus ni exiger que chaque participant les adopte.
Le Forum de coordination KCC a annoncé dans une annonce du 21 octobre que KCC-1, KCC-2 et KCC-20 étaient finalisés et prêts à être adoptés dans l'ensemble de l'écosystème. Le forum a invité les constructeurs à rejoindre son canal public pour des questions, des discussions sur les implémentations et du soutien.
Le dépôt des normes canoniques de Kaspa liste les trois documents comme Finalisés. Son index identifie KCC-1 comme la spécification de covenant, KCC-2 comme la spécification d'autorité, et KCC-20 comme la norme d'application pour les covenants de jetons fongibles.
Le dépôt décrit les KCC comme des conventions partagées pour des implémentations indépendantes. Sa documentation sépare ces conventions des changements au consensus ou au comportement du nœud central, qui relèvent des propositions d'amélioration de Kaspa.
Les normes Kaspa couvrent différentes parties du développement d'applications
KCC-1 définit des termes communs, des dispositions de données et une interface binaire d'application, ou ABI, pour les covenants. La spécification décrit comment les logiciels encodent l'information, appellent les fonctions de programme et identifient l'état transporté entre les transactions.
Ses auteurs, Romain Billot, Michael Sutton et Ori Newman, identifient les compilateurs, les portefeuilles, les indexeurs et les constructeurs de transactions parmi les outils qui doivent s'accorder sur ces détails. Le document indique que les implémentations indépendantes ont besoin de formats communs au-delà de la simple production de scripts qui passent les vérifications de consensus.
La spécification KCC-1 laisse les développeurs libres de choisir leur langage de programmation, leur compilateur et leur framework. Son interface partagée couvre les points d'entrée de programme, les modèles d'état et les règles de traitement des transactions impliquant plusieurs entrées.
Dans le même document, les auteurs distinguent les règles d'interface de base des fonctionnalités qui dépendent des identifiants de covenant. Les programmes sans liaisons de covenant peuvent suivre KCC-1, mais la spécification indique qu'ils ne reçoivent pas les garanties de lignage et d'autorisation fournies par KIP-20.
KCC-2 définit qui peut autoriser une opération
KCC-2, rédigé par Billot et Sutton, spécifie comment les programmes identifient une autorité et les vérifications minimales requises pour établir son approbation. Une autorité peut être une clé publique, un engagement envers une clé, un script ou un lignage de covenant continu.
La spécification attribue des identifiants standard à cinq schémas d'autorisation. Ses options de clé publique couvrent les signatures Schnorr et ECDSA, tandis que ses autres options permettent à un script ou à un lignage de covenant de participer en tant qu'autorité.
Pour l'autorisation par hachage de clé publique, KCC-2 exige que la transaction révèle la clé publique correspondante, fasse correspondre son hachage à la valeur d'autorité stockée et fournisse une signature valide. Les spécifications de niveau supérieur définissent le message signé et toute condition supplémentaire.
Le registre d'autorité réserve des plages distinctes pour les schémas standard et personnalisés. KCC-2 permet aux participants d'adopter des schémas personnalisés sans attendre la standardisation, à condition que leurs définitions spécifient le format, la signification et les vérifications d'approbation.
Selon son schéma d'identifiant de covenant, l'approbation nécessite une entrée provenant du lignage de covenant identifié. KCC-2 indique qu'une convention de niveau supérieur peut imposer des vérifications supplémentaires sur le programme et l'état de cette entrée.
KCC-20 établit les règles de transfert et de réception des jetons
KCC-20 s'appuie sur les deux premiers standards, définissant les montants de jetons, la propriété et les interfaces de transfert. Le document nomme Sivan Helfer, Sutton, Newman et Billot comme auteurs.
Sa spécification exige que chaque covenant de jeton publie des informations de programme que les logiciels peuvent utiliser pour décoder l'état et construire des transferts. Les configurations doivent divulguer les schémas de propriété pris en charge et les limites sur les entrées et sorties de jetons.
Une fonctionnalité appelée réception empruntée permet à un expéditeur d'utiliser une sortie de jeton compatible existante d'un destinataire comme destination. KCC-20 indique que la transaction recrée cette sortie avec plus de jetons, préserve sa propriété et son état étendu, et ne peut pas réduire sa valeur en KAS.
La section sécurité avertit que le remplacement de la sortie modifie sa référence de transaction, invalidant les transactions non confirmées dépensant la référence précédente. Un portefeuille doit découvrir le remplacement avant de le dépenser, selon le document.
Le standard relie une implémentation de référence Argent avec des contrats SilverScript générés et des tests de conformité Rust.
Le statut final comporte des exigences de mise en œuvre
KCC-0, le document régissant le processus de normalisation, exige plus que l'achèvement d'une période de révision finale. Il indique qu'une convention de la voie de normalisation nécessite des vecteurs de test lisibles par l'homme et par la machine, ainsi qu'au moins une implémentation publique qui réussit les vérifications lisibles par la machine.
Les dépendances doivent être Final pour les autres KCC ou Active pour les KIP, selon les mêmes règles. KCC-0 indique que les changements de statut se produisent via des pull requests et que l'index du dépôt doit être mis à jour en conséquence.
KCC-0 décrit les vecteurs de test lisibles par la machine comme la forme faisant autorité pour les tests automatisés lorsqu'ils accompagnent des exemples lisibles par l'homme. Ses règles de soumission exigent que les considérations de sécurité traitent des menaces, des hypothèses de confiance et des problèmes potentiels de rejeu avant qu'un document de la voie de normalisation puisse entrer en Last Call.
Le document directeur déclare que la finalisation n'exige pas que chaque participant de l'écosystème implémente une convention. Les changements substantiels nécessitent généralement un KCC de remplacement, tandis que les corrections et clarifications suivent les règles d'amendement du document.
Le développement d'applications de Kaspa a précédemment inclus une infrastructure Layer 2 distincte. Gate a annoncé une intégration de Kasplex Layer 2 en avril, permettant les dépôts et retraits de KAS via le réseau compatible EVM, comme l'a rapporté crypto.news.
Dans son annonce d'intégration antérieure, Gate a déclaré que les clients pouvaient transférer des KAS du réseau de base vers un portefeuille Kasplex. Les documents du projet Kasplex décrivent un pont bidirectionnel et indiquent que les développeurs familiers avec les outils Ethereum peuvent déployer des contrats en changeant leurs points de terminaison d'appel de procédure distante.
Kasplex décrit sa conception comme un rollup léger qui place le bytecode EVM dans les transactions Kaspa et l'exécute hors chaîne. Sa documentation indique que Kaspa fournit l'ordonnancement des transactions et la disponibilité des données, tandis que les KAS pontés servent de jeton de gaz pour le Layer 2.
