Hard Fork Toccata Kaspy: Przymierza, kody ZK i nowy czerwcowy cel

KaspaNadchodzący hard fork Toccata doda do sieci dwie nowe ścieżki programowalności: natywne programowanie przymierza L1 i opartą na zerowej wiedzy infrastrukturę aplikacji (zk). Aktywacja sieci głównej jest obecnie zaplanowana na 5–20 czerwca 2026 r., przesunięta z pierwotnego terminu 5 maja.

Michael Sutton z Kaspa Core opublikował szczegółowa aktualizacja O tym, co obejmuje hard fork, dlaczego data została przesunięta i jak ma się rozwijać w ciągu najbliższych kilku miesięcy. Fork został pierwotnie zainicjowany przez Oriego Newmana jako próba wprowadzenia kowenów do silnika skryptowego Kaspy, częściowo w odpowiedzi na dyskusję OP_CAT w kręgach Bitcoina. Od tego czasu rozwinął się w coś znacznie większego.

Czym jest Toccata Hard Fork?

Toccata to zaplanowany hard fork dla sieci Kaspa, który wprowadza nowe możliwości bezpośrednio do warstwy bazowej. Hard fork, dla mniej zaznajomionych, to aktualizacja protokołu, która nie jest wstecznie kompatybilna. Wszystkie węzły muszą dokonać aktualizacji, aby nadal uczestniczyć w sieci.

Nazwa nawiązuje do tradycji Kaspy, polegającej na wykorzystywaniu muzycznych odniesień do istotnych ulepszeń. Ta płyta zaczerpnięta jest z klasycznej formy muzycznej, toccaty, utworu mającego na celu zaprezentowanie technicznych umiejętności gry na instrumencie klawiszowym.

Ogólnie rzecz biorąc, Toccata dodaje do Kaspy dwie rzeczy:

• Natywne programowanie przymierzy L1 za pośrednictwem nowego kompilatora o nazwie Silverscript
• Infrastruktura aplikacji oparta na ZK, zbudowane na fundamentach tego samego przymierza

Nie są to systemy zamienne. Służą różnym przypadkom użycia i są skierowane do różnych grup odbiorców.

Czym są przymierza i dlaczego są ważne dla Kaspy?

Przymierze to warunki określające, jak środki z transakcji wyjściowej mogą być wydatkowane w przyszłości. W standardowej transakcji Bitcoin lub Kaspa, po wysłaniu monet, odbiorca może z nimi zrobić, co zechce. Przymierze zmieniają to, osadzając reguły wydawania bezpośrednio w skrypcie.

Kaspa wykorzystuje model UTXO, podobny do Bitcoina, w którym każda transakcja zużywa istniejące dane wyjściowe i tworzy nowe. Przymierza w systemie UTXO pozwalają programistom budować zaskakująco złożone przepływy stanowe z wieloma kontraktami, mimo że podstawowe obliczenia pozostają lokalne dla każdego UTXO.

Aby uczynić tworzenie kowenów bardziej przystępnym, Kaspa Core finalizuje prace nad Silverscriptem, kompilatorem zainicjowanym przez Oriego Newmana, Michaela Suttona, IzioDeva i Manyfesta. Silverscript został zaprojektowany, aby ułatwić i zwiększyć bezpieczeństwo pisania i wdrażania złożonych kowenów bezpośrednio w Kaspa L1, bez konieczności pracy na poziomie silnika skryptowego przez programistów.

Czym są aplikacje oparte na ZK?

Drugi filar programowalności wprowadzony w Toccacie opiera się na aplikacjach zk. Jest on bardziej złożony technicznie z dwóch i warto go dokładnie omówić.

Odkryj obiecujące projekty...

Obiecujące projekty...

(Reklama)

Artykuł ciąg dalszy...

ZK to skrót od „zero-knowledge”, czyli metody kryptograficznej pozwalającej jednej ze stron udowodnić prawdziwość czegoś bez ujawniania danych źródłowych. Dowody ZK są coraz częściej wykorzystywane w skalowaniu blockchainów, ponieważ pozwalają na tanią i bezpieczną weryfikację obliczeń poza łańcuchem w łańcuchu.

„Oparty” w tym kontekście oznacza, że ​​system zk w pełni przestrzega sekwencjonowania L1. Aplikacja oparta na zk nie może samodzielnie dodawać ani usuwać transakcji. Jest zakotwiczona w kolejności transakcji systemu Kaspa, co czyni ją wiarygodną bez konieczności korzystania z oddzielnego sekwencera.

Toccata wprowadza kilka komponentów wspierających tę funkcję:

• Kody operacji weryfikacji ZK, w tym elastyczny weryfikator Groth16 i weryfikator RISC Zero STARK
• Kod operacji dostępu do zobowiązania sekwencyjnego, umożliwiając aplikacjom opartym na zakotwiczeniu się w kolejności L1
• KIP-21, architektura zobowiązań sekwencjonowania partycjonowanego, która zapewnia, że ​​koszty dowodzenia aplikacji zk są skalowane w zależności od jej własnej aktywności, a nie od ogólnej aktywności DAG

Weryfikator RISC Zero STARK został już wdrożony i aktywowany w sieci testowej 12. Nie wiadomo jeszcze, czy zostanie aktywowany w sieci głównej.

Dlaczego udowodnienie kosztów ma znaczenie

Aby jakakolwiek aplikacja zk była praktyczna, koszt generowania dowodów musi być proporcjonalny do tego, co sama aplikacja robi. Gdyby aplikacja zk musiała udowadniać swoją pracę w odniesieniu do całej aktywności w szerszej grupie DAG, koszty stałyby się nieprzewidywalne i niemożliwe do opanowania. KIP-21 rozwiązuje ten problem poprzez partycjonowanie zobowiązań sekwencyjnych, dzięki czemu obciążenie każdej aplikacji pozostaje niezależne.

Co już jest na miejscu?

Znaczna część hard forka jest już zaimplementowana. Następujące funkcje są już wbudowane:

• Rozszerzona obsługa kodu operacyjnego silnika skryptowego, szkielet głównych umów, zgodnie z KIP-17
• Identyfikatory przymierzy do zarządzania linią jako funkcja konsensusu i silnika zgodnie z KIP-20
• Kody operacji ZK z podsystemem prekompilacji zk-verifier, zgodnie z KIP-16, autorstwa Alexandra Safstroma
• Kod operacji dostępu do zobowiązania sekwencyjnego
• KIP-21, autorstwa Suttona i wdrożony przez Maxima Biryukova, w pełni wdrożony i oczekuje na przegląd

Maxim ukończył również prace nad kamieniami milowymi w zakresie dowodu koncepcji, w tym nad wbudowanymi klauzulami zk i klauzulami zk opartymi na kanonicznym moście KAS, które odegrały kluczową rolę w ukształtowaniu ostatecznego projektu forka.

Dlaczego data Hard Fork została przesunięta na czerwiec?

Pierwotnym terminem uruchomienia sieci głównej był 5 maja 2026 r. Jednak termin ten został przesunięty na okres od 5 do 20 czerwca 2026 r.

Powód jest architektoniczny. Gdy obwody zk i środowiska wykonawcze połączą się ze strukturą haszującą potwierdzenia sekwencyjnego, wszelkie późniejsze zmiany strukturalne staną się zmianami powodującymi awarię. Błędne zaprojektowanie i późniejsze wprowadzenie poprawek byłoby o wiele bardziej uciążliwe niż poświęcenie dodatkowego czasu teraz.

KIP-21 został już zaprojektowany tak, aby zapewnić kompatybilność w przyszłości ze schematem zobowiązań, który ostatecznie będzie wymagany przez vprogs, długoterminowy plan działania firmy Kaspa dla synchronicznie komponowalnych i weryfikowalnych programów. Zablokowanie odpowiedniej struktury przed aktywacją sieci głównej pozwala uniknąć kosztownych migracji w przyszłości.

Zamrożenie funkcji spodziewane jest 15 kwietnia 2026 r.

Co się dzieje pomiędzy zamrożeniem funkcji a siecią główną?

Po zamrożeniu funkcji 15 kwietnia, Kaspa Core planuje czysty restart dedykowanej sieci testowej TN12 z pełnym, finalnym zestawem funkcji. Nie jest to symulacja przejścia na hard fork. To czysta sieć do testowania pełnego zestawu funkcji w jego ostatecznej formie.

Następnie zespół scali nagromadzone miesiące pracy z długo oczekiwanej gałęzi z powrotem do głównej bazy kodu. Proces ten obejmuje końcowy audyt, zamknięcie otwartych elementów, udoskonalenie logiki aktywacji hard fork oraz obsługę aktualizacji bazy danych.

Po zakończeniu tych prac, w sieci testowej TN10, długoterminowej sieci testowej, zostanie przeprowadzony test hard fork, aby zasymulować pełną transformację w stylu sieci głównej. Data przejścia do sieci głównej zostanie ustalona na stałe dopiero po zakończeniu prób i uzyskaniu satysfakcjonującego wyniku od zespołu.

Czego powinni oczekiwać operatorzy węzłów

Dla górników i operatorów węzłów aktualizacja ma być prosta. Węzły wymagają aktualizacji, a istniejące funkcje powinny nadal działać. Przewiduje się, że zapotrzebowanie na miejsce na dysku wzrośnie o około 20 do 50 procent. Nie przewiduje się drastycznych zmian w infrastrukturze.

Co Toccata tak naprawdę oferuje Kaspie

Toccata dodaje dwa działające systemy programowalności do warstwy bazowej Kaspy: natywne skryptowanie L1 za pośrednictwem Silverscript oraz infrastrukturę aplikacji bazującej na ZK za pośrednictwem KIP-16, KIP-20 i KIP-21. Znaczna część prac technicznych została już wykonana. Pozostaje sfinalizowanie interfejsów, scalenie oczekującej gałęzi z gałęzią główną i przeprowadzenie pełnej próby na TN10 przed potwierdzeniem daty sieci głównej.

Okno czasowe 5–20 czerwca 2026 r. istnieje, ponieważ zespół zdecydował się na uzyskanie poprawnej architektury zatwierdzania sekwencjonowania za pierwszym razem, zamiast poprawiać ją później, w warunkach rzeczywistych. Dla operatorów węzłów aktualizacja została zaprojektowana tak, aby była prosta i nie wymagała żadnych istotnych zmian w infrastrukturze, poza niewielkim zwiększeniem przestrzeni dyskowej.

Zasoby

1. Kaspa na X:Post (kwiecień 2026)

2. Artykuł na blogu Michaela Suttona: Kaspa Covenants++ „Toccata” – perspektywa hard-forku