Kaspa w pigułce: blockDAG, dziesięć bloków na sekundę i jak działa multisig

Większość łańcuchów proof-of-work tworzy bloki jeden po drugim: górnik znajduje blok, wszyscy budują na nim dalej, a każdy konkurencyjny blok znaleziony w tym samym momencie trafia do kosza. Kaspa wychodzi od innego pytania: co by było, gdyby równoległe bloki w ogóle się nie marnowały?

Odpowiedzią jest blockDAG – i to dzięki niemu Kaspa może tworzyć dziesięć bloków na sekundę, pozostając przy proof-of-work. Skoro obsługa Kaspa trafia do SSP, zobaczmy, co ją wyróżnia i jak działa w niej multisig.

Od łańcucha do DAG

W Bitcoinie, gdy dwóch górników znajdzie bloki niemal jednocześnie, sieć tymczasowo się rozwidla. W końcu jeden blok wygrywa, a drugi staje się sierotą – praca, która za nim stała, po prostu przepada. Aby sieroty zdarzały się rzadko, Bitcoin celuje w jeden blok co dziesięć minut – na tyle długo, by każdy blok dotarł do całej sieci, zanim zostanie znaleziony następny.

Kaspa usuwa to ograniczenie. Każdy nowy blok może wskazywać na kilka poprzednich bloków zamiast na jeden, więc wszystkie bloki utworzone równolegle stają się częścią rejestru. Struktura przestaje być pojedynczym łańcuchem i staje się skierowanym grafem acyklicznym – DAG.

Sam DAG ma jednak problem: jeśli dwa równoległe bloki zawierają sprzeczne transakcje, która się liczy? Protokół konsensusu Kaspa, GHOSTDAG, rozwiązuje to, porządkując wszystkie bloki w spójny sposób. Wyodrębnia dobrze połączoną większość bloków zbudowanych przez uczciwych górników i układa wszystko w jedną uzgodnioną kolejność, dzięki czemu każdy węzeł dochodzi do tego samego werdyktu co do tego, która transakcja była pierwsza.

W efekcie Kaspa może działać w tempie dziesięciu bloków na sekundę – takim od aktualizacji Crescendo z 2025 roku – bez marnowania sierot, które sparaliżowałoby łańcuch przy takiej prędkości. Do zabezpieczenia rejestru nadal używa proof-of-work.

Co to oznacza w praktyce

• Szybkie potwierdzenia. Transakcje są wychwytywane w ciągu mniej więcej sekundy. Jak w każdym łańcuchu, głębokość potwierdzeń wciąż ma znaczenie przy większych kwotach – każdy kolejny blok zbudowany na wierzchu utrudnia cofnięcie transakcji – ale ta głębokość rośnie szybko.
• Monety, nie konta. Kaspa korzysta z modelu UTXO, tak jak Bitcoin: twoje saldo to zbiór pojedynczych monet, a wydatek łączy część z nich i odsyła ci resztę.
• Przycinanie. Węzły Kaspa nie przechowują całej historii na zawsze; starsze dane bloków są usuwane po mniej więcej półtora dnia. Bieżący stan zawsze da się zweryfikować, ale długoterminowa historia transakcji jest przechowywana przez indeksery i eksploratory, a nie przez każdy węzeł.
• Małe jednostki. Jeden KAS to 100 000 000 sompi, najmniejszej jednostki Kaspa.

Opłaty mierzy się w „masie”

Bitcoin wycenia miejsce w bloku w bajtach. Kaspa wycenia je w masie, która łączy kilka kosztów:

• Rozmiar – ile bajtów zajmuje transakcja.
• Operacje podpisu – każda weryfikacja podpisu dodaje stałą wartość, więc wydatek multisig waży więcej niż wydatek z jednego klucza.
• Przechowywanie – reguła znana jako KIP-9 sprawia, że transakcje tworzące wiele drobnych wyjść są drogie, aby rejestr nie zapełnił się pyłem.

Przy codziennych przelewach nie widać tego wcale: opłaty są niewielkie. Wyjaśnia to jednak kilka osobliwości Kaspa, na przykład dlaczego odesłanie sobie bardzo małej reszty może zostać odrzucone i dlaczego portfele czasem muszą skonsolidować wiele drobnych monet przed dużą płatnością.

Jak działa multisig w Kaspa

Kaspa celowo ma niewiele typów adresów. Adres kaspa:q jest kontrolowany przez jeden klucz. Adres kaspa:p to adres typu pay-to-script-hash: zobowiązuje się do skryptu, a wydanie środków wymaga ujawnienia tego skryptu i spełnienia jego warunków.

Sejf multisig to adres kaspa:p, którego skrypt mówi: „M z tych N kluczy musi podpisać”. Kaspa używa podpisów Schnorra, na poziomie konsensusu obsługuje do 20 kluczy na skrypt, a standardowe transakcje przekazuje z maksymalnie 15. Dwa szczegóły sprawiają, że pracuje się z nią przyjemnie:

• Identyfikator transakcji nie obejmuje podpisów. Znasz ostateczny identyfikator transakcji, zanim ktokolwiek ją podpisze, co upraszcza koordynowanie podpisów między urządzeniami.
• Nie ma warstwy SegWit ani Taproot. Kaspa ma tylko trzy standardowe typy wyjść – z jednym kluczem, jego wariant ECDSA i pay-to-script-hash – więc jest tylko jeden rodzaj sejfu multisig, który trzeba dobrze zaprojektować.

Jedna subtelność ma znaczenie dla bezpieczeństwa. Podpis w Kaspa obejmuje tylko kwotę konkretnego wejścia, które podpisuje, a nie kwoty wszystkich wejść. Staranny portfel multisig sprawia więc, że każdy sygnatariusz samodzielnie sprawdza wydawane monety, zamiast ufać kwotom podanym przez inne urządzenie.

Kaspa w SSP

SSP dodaje Kaspa w tym samym modelu 2 z 2 co każdy inny łańcuch: twój sejf to adres kaspa:p zbudowany z jednego klucza w SSP Wallet i jednego w SSP Key, a każde urządzenie niezależnie sprawdza, co podpisuje. SSP Enterprise będzie obsługiwać sejfy Kaspa z zatwierdzaniem M z N.

Nie jest to jeszcze dostępne – obsługa Kaspa przechodzi końcowe testy i zostanie ogłoszona wraz z informacjami o wydaniu, gdy się pojawi. Biblioteka, na której się opiera, @runonflux/kaspa-core, jest już open source dla każdego, kto chce ją przejrzeć lub ponownie wykorzystać.

Uczciwe podsumowanie

Kaspa bierze znany pomysł – proof-of-work zabezpieczający rejestr UTXO – i usuwa wąskie gardło „jeden blok na raz”, pozwalając blokom tworzyć DAG. Efektem są szybkie bloki, opłaty oparte na masie zamiast bajtów i przejrzysta konstrukcja multisig zbudowana wokół jednego typu skryptu.

Jak w każdym łańcuchu, twoich monet nie chroni tempo bloków. Chroni je to, kto kontroluje klucze – a w przypadku multisig, ile z nich musi się zgodzić.