Forum Koordynacyjne KCC Kaspa sfinalizowało trzy standardy obejmujące interfejsy covenantów, autoryzację i tokeny zamienne, ustanawiając wspólne specyfikacje dla deweloperów budujących aplikacje w sieci.
Podsumowanie
- KCC-1 definiuje wspólne interfejsy dla portfeli, kompilatorów, indekserów i innych narzędzi 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 obsługuje odbieranie tokenów poprzez istniejące kompatybilne wyjście.
- Finalizacja ustanawia konwencje ekosystemu bez zmiany reguł konsensusu ani wymagania, by każdy uczestnik je przyjął.
Forum Koordynacyjne KCC ogłosiło w komunikacie z 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 publicznego kanału w celu zadawania pytań, omawiania implementacji i uzyskania wsparcia.
Kanoniczne repozytorium standardów Kaspa wymienia wszystkie trzy dokumenty jako Ostateczne. Jego indeks identyfikuje KCC-1 jako specyfikację covenantów, KCC-2 jako specyfikację autoryzacji, a KCC-20 jako standard aplikacji dla covenantów tokenów zamiennych.
Repozytorium opisuje KCC jako wspólne konwencje dla niezależnych implementacji. Jego dokumentacja oddziela te konwencje od zmian w konsensusie lub zachowaniu węzłów podstawowych, które należą do Kaspa Improvement Proposals.
Standardy Kaspa obejmują różne części tworzenia aplikacji
KCC-1 definiuje wspólne terminy, układy danych oraz interfejs binarny aplikacji, czyli ABI, dla covenantów. Specyfikacja opisuje, w jaki sposób oprogramowanie koduje informacje, wywołuje funkcje programu i identyfikuje stan przenoszony między transakcjami.
Jej autorzy, Romain Billot, Michael Sutton i Ori Newman, wskazują kompilatory, portfele, indeksery i konstruktory transakcji wśród narzędzi, które muszą uzgodnić te szczegóły. Dokument stwierdza, że niezależne implementacje potrzebują wspólnych formatów wykraczających poza samo tworzenie skryptów przechodzących 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 obsługi transakcji obejmujących wiele wejść.
W tym samym dokumencie autorzy odróżniają podstawowe zasady interfejsu od funkcji zależnych od identyfikatorów covenantów. Programy bez powiązań covenantowych mogą stosować KCC-1, ale specyfikacja stwierdza, że nie otrzymują 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, w jaki sposób programy identyfikują autorytet i minimalne kontrole wymagane do ustalenia jego zatwierdzenia. Autorytetem może być klucz publiczny, zobowiązanie do klucza, skrypt lub kontynuowane pochodzenie covenantu.
Specyfikacja przypisuje standardowe identyfikatory pięciu schematom autoryzacji. Opcje klucza publicznego obejmują podpisy Schnorr i ECDSA, podczas gdy pozostałe opcje pozwalają skryptowi lub pochodzeniu covenantu uczestniczyć jako autorytet.
W przypadku autoryzacji za pomocą skrótu klucza publicznego KCC-2 wymaga, aby transakcja ujawniła odpowiedni klucz publiczny, dopasowała jego skrót do przechowywanej wartości autorytetu i dostarczyła ważny podpis. Specyfikacje wyższego poziomu definiują podpisaną wiadomość i wszelkie dalsze warunki.
Rejestr autorytetów rezerwuje oddzielne zakresy dla schematów standardowych i niestandardowych. KCC-2 pozwala uczestnikom przyjmować schematy niestandardowe bez oczekiwania na standaryzację, pod warunkiem że ich definicje określają format, znaczenie i kontrole zatwierdzenia.
W ramach schematu identyfikatora covenantu zatwierdzenie wymaga wejścia z identyfikowanego pochodzenia covenantu. KCC-2 stwierdza, że konwencja wyższego poziomu może nałożyć dalsze kontrole na program i stan tego wejścia.
KCC-20 określa zasady transferu i odbioru tokenów
KCC-20 opiera się na dwóch pierwszych standardach, definiując ilości tokenów, własność i interfejsy transferu. Dokument wymienia Sivana Helfera, Suttona, Newmana i Billota jako autorów.
Jego specyfikacja wymaga, aby każdy kontrakt tokena publikował informacje o programie, których oprogramowanie może użyć do dekodowania stanu i konstruowania transferów. Konfiguracje muszą ujawniać obsługiwane schematy własności oraz limity wejść i wyjść tokenów.
Funkcja zwana pożyczonym odbiorem pozwala nadawcy użyć istniejącego, kompatybilnego wyjścia tokena odbiorcy jako miejsca docelowego. KCC-20 mówi, że transakcja odtwarza to wyjście z większą liczbą tokenów, zachowuje jego własność i rozszerzony stan oraz nie może zmniejszyć jego wartości KAS.
Sekcja dotycząca bezpieczeństwa ostrzega, że zastąpienie wyjścia zmienia jego referencję transakcji, unieważniając niepotwierdzone transakcje wydające poprzednią referencję. Według dokumentu portfel musi odkryć zastąpienie przed jego wydaniem.
Standard łączy referencyjną implementację Argent z wygenerowanymi kontraktami SilverScript i testami zgodności w Rust.
Ostateczny status wiąże się z wymogami implementacyjnymi
KCC-0, dokument regulujący proces standaryzacji, wymaga więcej niż zakończenia końcowego okresu przeglądu. Mówi, że konwencja ścieżki standaryzacyjnej wymaga wektorów testowych czytelnych dla człowieka i maszyn oraz co najmniej jednej publicznej implementacji, która przechodzi testy maszynowe.
Zależności muszą mieć status Final dla innych KCC lub Active dla KIP, zgodnie z tymi samymi zasadami. KCC-0 mówi, że zmiany statusu następują poprzez pull requesty, a indeks repozytorium musi być wraz z nimi aktualizowany.
KCC-0 opisuje maszynowe wektory testowe jako autorytatywną formę do automatycznego testowania, gdy towarzyszą im przykłady czytelne dla człowieka. Jego zasady zgłaszania wymagają, aby rozważania dotyczące bezpieczeństwa odnosiły się do zagrożeń, założeń zaufania i potencjalnych problemów z powtórzeniem, zanim dokument ścieżki standaryzacyjnej będzie mógł wejść do Last Call.
Dokument regulujący stwierdza, że finalizacja nie wymaga, aby każdy uczestnik ekosystemu implementował konwencję. Istotne zmiany zazwyczaj wymagają zastępczego KCC, podczas gdy poprawki i wyjaśnienia podlegają zasadom amendacji dokumentu.
Rozwój aplikacji Kaspa obejmował wcześniej oddzielną infrastrukturę Layer 2. Gate ogłosił w kwietniu integrację Kasplex Layer 2, umożliwiając depozyty i wypłaty KAS przez sieć kompatybilną z EVM, jak podało crypto.news.
W swoim wcześniejszym ogłoszeniu o integracji Gate poinformował, że klienci mogą przenosić KAS z sieci bazowej 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 punkty końcowe zdalnego wywołania procedur.
Kasplex opisuje swoją konstrukcję jako lekkie rollup, które umieszcza bajtkod EVM w transakcjach Kaspa i wykonuje go poza łańcuchem. Jego dokumentacja mówi, że Kaspa zapewnia porządkowanie transakcji i dostępność danych, podczas gdy pomostowany KAS służy jako token gazu Layer 2.
