Kaspa’s KCC-Koordinationsforum hat drei Standards finalisiert, die Covenant-Schnittstellen, Autorisierung und fungible Token abdecken und gemeinsame Spezifikationen für Entwickler festlegen, die Anwendungen auf dem Netzwerk erstellen.
Zusammenfassung
- KCC-1 definiert gemeinsame Schnittstellen für Wallets, Compiler, Indexer und andere Tools, die mit Covenants arbeiten.
- KCC-2 spezifiziert fünf Standard-Autorisierungsschemata, darunter öffentliche Schlüssel, Skripte und Covenant-Identifikatoren.
- KCC-20 legt Token-Übertragungsregeln fest und unterstützt den Empfang von Token über einen bestehenden kompatiblen Output.
- Die Finalisierung etabliert Ökosystem-Konventionen, ohne Konsensregeln zu ändern oder zu verlangen, dass jeder Teilnehmer sie übernimmt.
Das KCC-Koordinationsforum erklärte in einer Ankündigung vom 21. Oktober, dass KCC-1, KCC-2 und KCC-20 final und bereit zur Übernahme im gesamten Ökosystem seien. Das Forum lud Entwickler ein, seinem öffentlichen Kanal für Fragen, Implementierungsdiskussionen und Unterstützung beizutreten.
Das kanonische Standards-Repository von Kaspa führt alle drei Dokumente als Final auf. Sein Index identifiziert KCC-1 als die Covenant-Spezifikation, KCC-2 als die Autoritätsspezifikation und KCC-20 als den Anwendungsstandard für Fungible-Token-Covenants.
Das Repository beschreibt KCCs als gemeinsame Konventionen für unabhängige Implementierungen. Seine Dokumentation trennt diese Konventionen von Änderungen an Konsens oder Kernknotenverhalten, die in Kaspa Improvement Proposals gehören.
Kaspa-Standards decken verschiedene Teile der Anwendungsentwicklung ab
KCC-1 definiert gemeinsame Begriffe, Datenlayouts und eine Anwendungsbinärschnittstelle, oder ABI, für Covenants. Die Spezifikation beschreibt, wie Software Informationen kodiert, Programmfunkionen aufruft und den zwischen Transaktionen übertragenen Zustand identifiziert.
Ihre Autoren, Romain Billot, Michael Sutton und Ori Newman, nennen Compiler, Wallets, Indexer und Transaktions-Builder unter den Tools, die sich auf diese Details einigen müssen. Das Dokument besagt, dass unabhängige Implementierungen gemeinsame Formate benötigen, die über das bloße Erzeugen von Skripten, die Konsensprüfungen bestehen, hinausgehen.
Die KCC-1-Spezifikation lässt Entwicklern die Freiheit, ihre Programmiersprache, ihren Compiler und ihr Framework zu wählen. Ihre gemeinsame Schnittstelle umfasst Programmeinstiegspunkte, Zustandsvorlagen und Regeln für die Behandlung von Transaktionen mit mehreren Inputs.
Innerhalb desselben Dokuments unterscheiden die Autoren grundlegende Schnittstellenregeln von Funktionen, die von Covenant-Identifikatoren abhängen. Programme ohne Covenant-Bindungen können KCC-1 folgen, aber die Spezifikation besagt, dass sie nicht die von KIP-20 bereitgestellten Abstammungs- und Autorisierungsgarantien erhalten.
KCC-2 definiert, wer eine Operation autorisieren kann
KCC-2, verfasst von Billot und Sutton, spezifiziert, wie Programme eine Autorität identifizieren und welche Mindestprüfungen erforderlich sind, um deren Genehmigung festzustellen. Eine Autorität kann ein öffentlicher Schlüssel, eine Bindung an einen Schlüssel, ein Skript oder eine fortlaufende Covenant-Abstammungslinie sein.
Die Spezifikation weist fünf Autorisierungsschemata Standardidentifikatoren zu. Ihre Optionen für öffentliche Schlüssel umfassen Schnorr- und ECDSA-Signaturen, während ihre anderen Optionen es einem Skript oder einer Covenant-Abstammungslinie ermöglichen, als Autorität teilzunehmen.
Für die Autorisierung per Public-Key-Hash verlangt KCC-2, dass die Transaktion den entsprechenden öffentlichen Schlüssel offenlegt, seinen Hash mit dem gespeicherten Autoritätswert abgleicht und eine gültige Signatur bereitstellt. Übergeordnete Spezifikationen definieren die signierte Nachricht und etwaige weitere Bedingungen.
Das Autoritätsregister reserviert separate Bereiche für Standard- und benutzerdefinierte Schemata. KCC-2 erlaubt Teilnehmern, benutzerdefinierte Schemata zu übernehmen, ohne auf eine Standardisierung zu warten, sofern ihre Definitionen das Format, die Bedeutung und die Genehmigungsprüfungen spezifizieren.
Nach seinem Covenant-Identifikator-Schema erfordert die Genehmigung einen Input aus der identifizierten Covenant-Abstammungslinie. KCC-2 besagt, dass eine übergeordnete Konvention weitere Prüfungen des Programms und Zustands dieses Inputs auferlegen kann.
KCC-20 legt Regeln für Token-Übertragung und -Empfang fest
KCC-20 baut auf den ersten beiden Standards auf und definiert Token-Mengen, Eigentum und Übertragungsschnittstellen. Das Dokument nennt Sivan Helfer, Sutton, Newman und Billot als seine Autoren.
Seine Spezifikation verlangt, dass jeder Token-Covenant Programm Informationen veröffentlicht, die Software verwenden kann, um den Zustand zu dekodieren und Übertragungen zu konstruieren. Konfigurationen müssen unterstützte Eigentumsschemata und Grenzen für Token-Eingaben und -Ausgaben offenlegen.
Eine Funktion namens Borrowed Receive ermöglicht es einem Sender, eine bestehende kompatible Token-Ausgabe des Empfängers als Ziel zu verwenden. KCC-20 besagt, dass die Transaktion diese Ausgabe mit mehr Tokens neu erstellt, ihr Eigentum und ihren erweiterten Zustand bewahrt und ihren KAS-Wert nicht verringern kann.
Der Sicherheitsabschnitt warnt davor, dass das Ersetzen der Ausgabe ihre Transaktionsreferenz ändert und unbestätigte Transaktionen ungültig macht, die die vorherige Referenz ausgeben. Laut dem Dokument muss eine Wallet die Ersetzung entdecken, bevor sie sie ausgibt.
Der Standard verlinkt eine Argent-Referenzimplementierung mit generierten SilverScript-Verträgen und Rust-Konformitätstests.
Der finale Status bringt Implementierungsanforderungen mit sich
KCC-0, das Dokument, das den Standardisierungsprozess regelt, verlangt mehr als den Abschluss einer finalen Überprüfungsphase. Es besagt, dass eine Konvention auf dem Standards-Track menschenlesbare und maschinenlesbare Testvektoren sowie mindestens eine öffentliche Implementierung benötigt, die die maschinenlesbaren Prüfungen besteht.
Abhängigkeiten müssen gemäß denselben Regeln für andere KCCs Final oder für KIPs Active sein. KCC-0 besagt, dass Statusänderungen über Pull Requests erfolgen und der Repository-Index mit ihnen aktualisiert werden muss.
KCC-0 beschreibt maschinenlesbare Testvektoren als die maßgebliche Form für automatisierte Tests, wenn sie menschenlesbaren Beispielen beiliegen. Seine Einreichungsregeln verlangen, dass Sicherheitsüberlegungen Bedrohungen, Vertrauensannahmen und potenzielle Replay-Probleme behandeln, bevor ein Dokument auf dem Standards-Track in die Last Call eintreten kann.
Das maßgebliche Dokument stellt fest, dass die Finalisierung nicht erfordert, dass jeder Ökosystemteilnehmer eine Konvention implementiert. Wesentliche Änderungen erfordern im Allgemeinen einen Ersatz-KCC, während Korrekturen und Klarstellungen den Änderungsregeln des Dokuments folgen.
Die Anwendungsentwicklung von Kaspa hat zuvor separate Layer-2-Infrastruktur umfasst. Gate kündigte im April eine Kasplex-Layer-2-Integration an, die KAS-Einzahlungen und -Auszahlungen über das EVM-kompatible Netzwerk ermöglicht, wie crypto.news berichtete.
In seiner früheren Integrationsankündigung erklärte Gate, dass Kunden KAS vom Basisnetzwerk auf eine Kasplex-Wallet übertragen könnten. Die Projektmaterialien von Kasplex beschreiben eine Zwei-Wege-Brücke und besagen, dass Entwickler, die mit Ethereum-Tools vertraut sind, Verträge bereitstellen können, indem sie ihre Remote-Procedure-Call-Endpunkte ändern.
Kasplex beschreibt sein Design als einen leichtgewichtigen Rollup, der EVM-Bytecode in Kaspa-Transaktionen platziert und ihn off-chain ausführt. Seine Dokumentation besagt, dass Kaspa die Transaktionsreihenfolge und Datenverfügbarkeit liefert, während gebrückte KAS als Gas-Token der Layer 2 dienen.
