< Wróć do aktualności

Kaspa trafi do SSP, a biblioteka, która to umożliwia, jest open source

·4 min czytania·Autor: SSP Editorial Team
Okładka newsroomu SSP: Kaspa trafi do SSP

Kaspa trafi do SSP, a biblioteka, która to umożliwia, jest open source

Obsługa Kaspa jest w drodze do SSP. Będzie to ten sam multisig 2 z 2, którego już używasz dla Bitcoina, Ethereum i Solany: jeden klucz w SSP Wallet, drugi w SSP Key, i nic się nie ruszy, dopóki oba się nie zgodzą. Skarbce firmowe również otrzymają Kaspa.

Żeby do tego dojść, musieliśmy zbudować coś, czego nie było. Dziś możemy udostępnić część, która jest już publiczna: @runonflux/kaspa-core, otwartoźródłową bibliotekę TypeScript do transakcji i multisig w Kaspa, wydaną na licencji MIT.

Dlaczego najpierw zbudowaliśmy bibliotekę

Kiedy zaczęliśmy myśleć o dodaniu Kaspa, przejrzeliśmy każdy pakiet JavaScript dla Kaspa, jaki udało nam się znaleźć. Żaden nie potrafił faktycznie zbudować i podpisać transakcji multisig Kaspa od początku do końca, a to jest dokładnie to, czego SSP potrzebuje ponad wszystko.

Oficjalna droga to kod Kaspa w Rust skompilowany do WebAssembly. To świetne oprogramowanie, ale słabo pasuje do SSP. SSP Key działa na React Native, gdzie WebAssembly nie jest dostępne, a rozszerzenie przeglądarki musi pozostać lekkie: sam pakiet WebAssembly waży ponad 11 MB.

Dlatego napisaliśmy reguły transakcji Kaspa od zera w czystym TypeScript: adresy, skrypty, multisig M z N, hashe podpisów, podpisy Schnorra, obliczanie opłat i „masy” oraz wybór wejść. Biblioteka ma dwie zależności uruchomieniowe, szeroko stosowane i audytowane biblioteki kryptograficzne @noble, i działa bez zmian w przeglądarkach, rozszerzeniach, Node i React Native.

Jak ją sprawdziliśmy

W kodzie portfela „wygląda na to, że działa” nie jest żadnym standardem. Biblioteka została zbudowana tak, by dało się wykazać, że działa identycznie jak sam węzeł Kaspa:

  • Sprawdzona względem kodu samego Kaspa. Zestaw testów uruchamia każdą funkcję krytyczną dla konsensusu względem rusty-kaspa, referencyjnej implementacji węzła, i przepuszcza transakcje podpisane przez bibliotekę przez jego prawdziwy silnik skryptów, łącznie z każdą kombinacją M z N od 1 z 1 aż do 15 z 15.
  • Prawdziwe dane z mainnetu. Istniejące identyfikatory transakcji i podpisy z mainnetu są odtwarzane dokładnie.
  • Zasilone transakcje w mainnecie. Piętnaście prawdziwych transakcji, w tym wydatki 2 z 2 w stylu SSP, jeden 2 z 3 oraz firmowe multisigi 4 z 7, 6 z 10 i 10 z 15, zostało zbudowanych i podpisanych biblioteką i przyjętych przez sieć. W każdym przypadku obliczenie masy transakcji przez węzeł dokładnie zgadzało się z naszym.
  • Przegląd adwersaryjny. Kilka rund przeglądu bezpieczeństwa szukało konkretnie sposobów, by oszukać podpisującego lub zawyżyć opłatę. Nie znaleziono krytycznych problemów, a każde ustalenie zostało naprawione wraz z testem regresyjnym. Raport jest opublikowany razem z kodem.

Otwarty kod to część tej samej zasady co odtwarzalne kompilacje: nie powinieneś musieć wierzyć nam na słowo, co podpisuje twoje transakcje.

Jak Kaspa będzie wyglądać w SSP

Twój skarbiec Kaspa będzie adresem multisig Kaspa (zaczyna się od kaspa:p), wyprowadzonym z obu twoich urządzeń na standardowej ścieżce derywacji SSP. Wysyłanie działa tak jak w innych sieciach: SSP Wallet przygotowuje i podpisuje swoją połowę, SSP Key pokazuje ci odbiorców, kwotę i opłatę, i dopiero gdy zatwierdzisz tam transakcję, trafia ona do sieci. To ten sam model 2 z 2, w nowej sieci.

Kilka szczegółów specyficznych dla Kaspa wpłynęło na projekt:

  • Każde urządzenie samo sprawdza kwoty. Podpis Kaspa obejmuje tylko kwotę wejścia, które podpisuje, więc urządzenie ufające przekazanym mu kwotom mogłoby zostać wprowadzone w błąd co do opłaty. W SSP każde urządzenie przed podpisaniem samodzielnie sprawdza wydawane monety i podpisuje wyłącznie dla własnego skarbca.
  • Identyfikator transakcji jest znany przed podpisaniem. Identyfikator transakcji Kaspa nie obejmuje podpisów, więc SSP może przypiąć transakcję do jej ostatecznego identyfikatora, zanim którykolwiek z kluczy ją podpisze.
  • Limity opłat są wbudowane. Opłaty mają górny limit, więc błędne oszacowanie opłaty nie może zamienić się w kosztowną pomyłkę.

Dla firm skarbce SSP Enterprise będą obsługiwać Kaspa z zatwierdzaniem M z N, do standardowego limitu Kaspa wynoszącego 15 kluczy na skarbiec.

Czego nie ma w pierwszym wydaniu

Wolimy dobrze wydać coś małego niż byle jak coś dużego. Pierwsze wydanie obejmuje samo KAS w mainnecie. Tokeny KRC-20, testnet Kaspa, podpisywanie wiadomości Kaspa i WalletConnect dla Kaspa nie będą dostępne na start.

Kiedy

Obsługa Kaspa jest zaimplementowana w SSP Wallet, SSP Key i SSP Enterprise i przechodzi teraz końcowe testy. Ogłosimy ją tutaj, wraz z informacjami o wydaniu, gdy będzie dostępna. Do tego czasu nie ma nic do włączenia ani nic do pobrania, a jeśli ktoś twierdzi inaczej, to nie jesteśmy my.

W międzyczasie programiści mogą korzystać z biblioteki już dziś: jest w npm jako @runonflux/kaspa-core i na GitHubie pod adresem RunOnFlux/kaspa-core.

Udostępnij ten artykuł

Powiązane artykuły