Kaspa finalizuje 3 standardy dla natywnych tokenów i aplikacji covenant

Forum Koordynacyjne KCC Kaspa sfinalizowało trzy standardy dotyczące interfejsów covenant, autoryzacji i tokenów wymiennych, ustanawiając wspólne specyfikacje dla deweloperów budujących aplikacje w sieci.

Podsumowanie

• KCC-1 definiuje wspólne interfejsy dla portfeli, kompilatorów, indeksatorów i innych narzędzi współpracujących z covenantami.
• KCC-2 określa pięć standardowych schematów autoryzacji, w tym klucze publiczne, skrypty i identyfikatory covenantów.
• KCC-20 ustala zasady transferu tokenów i wspiera odbieranie tokenów za pośrednictwem istniejącego kompatybilnego wyjścia.
• Sfinalizowanie ustanawia konwencje ekosystemowe bez zmiany zasad konsensusu ani wymagania, aby każdy uczestnik je przyjął.

Forum Koordynacyjne KCC ogłosiło 21 października, że KCC-1, KCC-2 i KCC-20 są ostateczne i gotowe do przyjęcia w całym ekosystemie. Forum zaprosiło twórców do dołączenia do swojego publicznego kanału w celu zadawania pytań, dyskusji na temat wdrożeń i uzyskania wsparcia.

Pozdrowienia $KAS. KCC-1, KCC-2 i KCC-20 są teraz ostateczne, co oznacza, że są gotowe do pełnego przyjęcia w całym ekosystemie.

Zapraszamy twórców Kaspa do dołączenia do publicznego kanału KCC, aby zadawać pytania, uzyskać wsparcie, omawiać wdrożenia i dzielić się tym, co budujecie.

Przyjdźcie budować z nami. --- Forum Koordynacyjne KCC (@kccforum) 21 października 2026

Repozytorium standardów kanonicznych Kaspa wymienia wszystkie trzy dokumenty jako ostateczne. Jego indeks identyfikuje KCC-1 jako specyfikację covenantów, KCC-2 jako specyfikację autorytetu, a KCC-20 jako standard aplikacji dla covenantów tokenów wymiennych.

Repozytorium opisuje KCC jako wspólne konwencje dla niezależnych wdrożeń. Jego dokumentacja oddziela te konwencje od zmian w konsensusie lub zachowaniu rdzenia węzła, które należą do Propozycji Ulepszeń Kaspa.

Standardy Kaspa obejmują różne części rozwoju aplikacji

KCC-1 definiuje wspólne terminy, układy danych i interfejs binarny aplikacji, czyli ABI, dla covenantów. Specyfikacja opisuje, jak oprogramowanie koduje informacje, wywołuje funkcje programowe i identyfikuje stan przenoszony między transakcjami.

Jej autorzy, Romain Billot, Michael Sutton i Ori Newman, identyfikują kompilatory, portfele, indeksatory i budowniczych transakcji jako narzędzia, które muszą zgodzić się na te szczegóły. Dokument stwierdza, że niezależne wdrożenia potrzebują wspólnych formatów, które wykraczają poza proste produkowanie skryptów, które przechodzą kontrole konsensusu.

Specyfikacja KCC-1 pozostawia deweloperom swobodę wyboru języka programowania, kompilatora i frameworka. Jej wspólny interfejs obejmuje punkty wejścia programu, szablony stanu i zasady dotyczące obsługi transakcji z wieloma wejściami.

W tym samym dokumencie autorzy rozróżniają podstawowe zasady interfejsu od funkcji, które zależą od identyfikatorów covenantów. Programy bez powiązań covenant mogą stosować się do KCC-1, ale specyfikacja stwierdza, że nie otrzymują one gwarancji pochodzenia i autoryzacji dostarczanych przez KIP-20.

KCC-2 definiuje, kto może autoryzować operację

KCC-2, napisany przez Billota i Suttona, określa, jak programy identyfikują autorytet i minimalne kontrole wymagane do ustalenia jego zatwierdzenia. Autorytet może być kluczem publicznym, zobowiązaniem do klucza, skryptem lub kontynuującą linią covenant.

Specyfikacja przypisuje standardowe identyfikatory pięciu schematom autoryzacji. Jej opcje klucza publicznego obejmują podpisy Schnorra i ECDSA, podczas gdy inne opcje pozwalają skryptowi lub linii covenant uczestniczyć jako autorytet.

Dla autoryzacji opartej na hashu klucza publicznego KCC-2 wymaga, aby transakcja ujawniała odpowiadający klucz publiczny, porównywała jego hash z przechowywaną wartością autorytetu i dostarczała ważny podpis. Wyższe specyfikacje definiują podpisaną wiadomość i wszelkie dodatkowe warunki.

Rejestr autorytetów rezerwuje oddzielne zakresy dla standardowych i niestandardowych schematów. KCC-2 pozwala uczestnikom przyjmować niestandardowe schematy bez czekania na standaryzację, pod warunkiem, że ich definicje określają format, znaczenie i kontrole zatwierdzające.

W ramach schematu identyfikacji przymierza, zatwierdzenie wymaga wkładu od zidentyfikowanej linii przymierza. KCC-2 mówi, że wyższy poziom konwencji może nałożyć dodatkowe kontrole na program i stan tego wkładu.

KCC-20 ustala zasady transferu i odbioru tokenów

KCC-20 opiera się na pierwszych dwóch standardach, definiując ilości tokenów, własność i interfejsy transferu. Dokument wymienia Sivan Helfer, Sutton, Newman i Billot jako jego autorów.

Jego specyfikacja wymaga, aby każde przymierze tokenów publikowało informacje o programie, które oprogramowanie może wykorzystać do dekodowania stanu i konstruowania transferów. Konfiguracje muszą ujawniać wspierane schematy własności oraz ograniczenia dotyczące wkładów i wypłat tokenów.

Funkcja zwana pożyczonym odbiorem pozwala nadawcy użyć istniejącego kompatybilnego wyjścia tokenu odbiorcy jako celu. KCC-20 mówi, że transakcja odtwarza to wyjście z większą ilością tokenów, zachowuje jego własność i rozszerzony stan, a także nie może zmniejszyć jego wartości KAS.

Sekcja bezpieczeństwa ostrzega, że zastąpienie wyjścia zmienia jego odniesienie transakcyjne, unieważniając niepotwierdzone transakcje wydające poprzednie odniesienie. Portfel musi odkryć zastąpienie przed jego wydaniem, zgodnie z dokumentem.

Standard łączy implementację odniesienia Argent z generowanymi kontraktami SilverScript i testami zgodności Rust.

Ostateczny status niesie wymagania dotyczące implementacji

KCC-0, dokument regulujący proces standardów, wymaga więcej niż zakończenia ostatecznego okresu przeglądu. Mówi, że konwencja na ścieżce standardów potrzebuje testów czytelnych dla ludzi i maszyn, plus przynajmniej jednej publicznej implementacji, która przechodzi kontrole czytelne dla maszyn.

Zależności muszą być Final dla innych KCC lub Active dla KIP, zgodnie z tymi samymi zasadami. KCC-0 mówi, że zmiany statusu zachodzą poprzez pull requesty, a indeks repozytorium musi być zaktualizowany o nie.

KCC-0 opisuje testy czytelne dla maszyn jako autorytatywną formę do automatycznego testowania, gdy towarzyszą im przykłady czytelne dla ludzi. Jego zasady składania wymagają, aby kwestie bezpieczeństwa dotyczyły zagrożeń, założeń zaufania i potencjalnych problemów z powtórkami, zanim dokument na ścieżce standardów może wejść w Ostateczne Wezwanie.

Dokument regulujący stwierdza, że finalizacja nie wymaga, aby każdy uczestnik ekosystemu wdrożył konwencję. Zmiany substancjalne zazwyczaj wymagają zastąpienia KCC, podczas gdy poprawki i wyjaśnienia podlegają zasadom nowelizacji dokumentu.

Rozwój aplikacji Kaspa wcześniej obejmował oddzielną infrastrukturę warstwy 2. Gate ogłosił integrację Kasplex Layer 2 w kwietniu, umożliwiając wpłaty i wypłaty KAS przez sieć kompatybilną z EVM, jak donosi crypto.news.

W swoim wcześniejszym ogłoszeniu o integracji, Gate powiedział, że klienci mogą przenosić KAS z sieci podstawowej do portfela Kasplex. Materiały projektowe Kasplex opisują dwukierunkowy most i mówią, że deweloperzy zaznajomieni z narzędziami Ethereum mogą wdrażać kontrakty, zmieniając swoje punkty końcowe zdalnego wywołania procedur.

Kasplex opisuje swój projekt jako lekką rollup, która umieszcza bajtkod EVM w transakcjach Kaspa i wykonuje go poza łańcuchem. Jego dokumentacja mówi, że Kaspa dostarcza porządkowanie transakcji i dostępność danych, podczas gdy mostkowane KAS służy jako token gazowy warstwy 2.