Nadchodzący hardfork Kaspy skupiony na Przymierzu: co wiemy

Na czym polega hardfork Kaspy skoncentrowany na Przymierzu?

Zgodnie z Nić Teracha, Kaspa przygotowuje hardfork skoncentrowany na przymierzu, zaplanowany na aktywacja sieci głównej 5 maja 2026 r. Aktualizacja rozszerza Warstwa 1 (L1) programowalność poprzez wprowadzenie natywnych zasobów i rozszerzonej funkcjonalności kowenantów. Stanowi to również podstawę dla weryfikowalne programy (vProgs) i integracji zerowej wiedzy (ZK).

Kaspa działa jako blockchain typu proof-of-work, wykorzystując architekturę blockDAG. Ulepszenie Crescendo W maju 2025 roku przepustowość wzrosła do 10 bloków na sekundę (BPS). Zatem nadchodzący hardfork bazuje na tym fundamencie, nie zmieniając wymagań dotyczących węzłów ani podstawowych zasad konsensusu.

Główni twórcy opisują tę wersję jako aktualizację o ograniczonym zakresie. Koncentruje się ona na umożliwieniu natywnego wydawania tokenów, programowalnych reguł wydatkowania oraz weryfikacji ZK na poziomie L1. 

Jaki jest harmonogram Hardforka z 5 maja 2026 r.?

Według wątku Terah, aktywację sieci głównej poprzedza kilka kamieni milowych:

• Reset sieci testowej 12 (TN12): Zaplanowano na początek lutego 2026 r. w celu wsparcia testowania zasobów natywnych i kowenantów.
   
• Zaangażowanie sekwencera KIP: Oczekuje się, że nastąpi to około 12 lutego 2026 r. Propozycja ta wprowadza zobowiązania dotyczące ładunku kopacza w celu wzmocnienia decentralizacji w czasie rzeczywistym.
   
• Wydanie SilverScript: Język programowania wysokiego poziomu do pisania programów w systemie Kaspa. Stworzony przez Oriego Newmana i współpracowników, upraszcza tworzenie przymierzy.
   
• Hardfork sieci głównej: May 5, 2026.

Uaktualnienia po hardforku obejmują DAGKnight, ukierunkowany na adaptacyjny konsensus i przepustowość powyżej 100 BPS, a także pełne wdrożenie vProgs.

Jak działają rodzime zasoby i przymierza w systemie Kaspa?

Zasoby natywne na warstwie 1

Hardfork wprowadza zasoby natywne, w tym obsługę Tokeny KRC20. Zasoby te istnieją bezpośrednio na poziomie L1 i mogą być przenoszone atomowo.

Transfery atomowe dotyczą:

• Zwykłe przymierza inline
• Egzekucje w ramach przymierza ZK i bez niego
• Transfery tokenów KRC20

Przymierza inline generują natychmiastowe dowody w portfelu. Nie ma rozłączenia między danymi transakcji a zmianą stanu. Ta konstrukcja obsługuje atomowość i deterministyczne wykonywanie.

Rozszerzone Przymierza (Przymierza++)

System umów Kaspy jest inspirowany badaniami Bitcoina nad programowalnymi warunkami wydawania środków w UTXO. Covenants++ rozszerza ten system, umożliwiając bardziej ekspresyjne reguły transakcji.

Odkryj obiecujące projekty...

Obiecujące projekty...

(Reklama)

Artykuł ciąg dalszy...

Przykłady zastosowań obejmują:

• Kontrola bezpieczeństwa w stylu skarbca
• Mechanizmy powiernicze
• Przelewy warunkowe
• Ustrukturyzowana logika tokenów

System wykorzystuje model UTXO zamiast w pełni opartych na kontach inteligentnych kontraktów.

Czym jest obliczeniowy DAG (CDAG)?

Hardfork wprowadza obliczeniową DAG (CDAG)). CDAG rejestruje wszystkie deklaracje odczytu i zapisu składane przez programy.

Ta struktura:

• Śledzi wykorzystanie zasobów
• Reguluje zależności między programami
• Egzekwuje zobowiązania gazowe

Projekt jest porównywalny z modelami wykonywania w blockchainach, takich jak Solana i Sui, ale w pełnej formie zaimplementowano go w środowisku blockDAG firmy Kaspa.

CDAG odgrywa kluczową rolę w zapewnianiu suwerenności vProgs.

Czym są vProgs i czym różnią się od inteligentnych kontraktów?

vProgs to suwerenne programy, które wykonują się poza L1, ustalając wyniki na L1 za pomocą dowodów.

Kluczowe właściwości:

• Egzekucja suwerenna: Każdy vProg definiuje własne reguły przepustowości i zależności.
• Kontrola zależności oparta na gazie: vProg nie może odczytać stanu innego vProg, dopóki nie zapłaci za zużycie zasobów.
• Transfery nieatomowe: vProgs nie są transparentne dla L1 w taki sam sposób, jak zasoby natywne. Transfery są asynchroniczne i nieatomowe.
• Wymagania dotyczące pakietu KAS: Każdy kowenant nieinline musi używać opakowanego KAS poprzez most kanoniczny. Natywnego KAS L1 nie można używać bezpośrednio.

Ta konstrukcja oddziela obliczenia i stan od L1, jednocześnie zachowując współdzielone sekwencjonowanie i rozliczenia.

Kto powinien tworzyć vProgs?

Jak wynika z dyskusji społeczności, większość zwykłych programistów aplikacji może nie potrzebować vProgs.

Jednakże vProgs może być atrakcyjny dla:

• Architekci Appchain
• Zespoły oceniające systemy typu rollup
• Projekty tworzące agentów AI z dużym stanem w łańcuchu
• Projektanci systemów porównują kontrakty L1, zestawienia L2 i modele hybrydowe

vProgs łączy w sobie ujednolicone sekwencjonowanie L1 z zewnętrznym stanem i obliczeniami.

Jaką rolę odgrywa wiedza zerowa (ZK)?

Hardfork integruje weryfikację ZK na poziomie L1, rozszerzając wcześniejsze propozycje, takie jak KIP-16.

Obsługiwane możliwości obejmują:

• Weryfikacja dowodu Groth16
• Mosty bez zaufania do systemów L2
• Potencjalne zastosowania zorientowane na prywatność

Oczekuje się, że wstępne aplikacje będą działać w trybie inline, a portfele będą generować dowody bezpośrednio. Nawet implementacje ZK oparte na umowach, opracowane przez takich współpracowników jak Hans i Maxim, będą działać na sprzęcie komercyjnym. Wczesne wdrożenia nie wymagają specjalistycznej infrastruktury do weryfikacji.

Standardowy laptop może generować dowody przy obecnych założeniach.

Programy skoncentrowane na prywatności są technicznie możliwe po hardforku. Jednak prywatność nie jest wymieniona jako główny cel planu działania.

Jaki jest związek Sparkle z vProgs?

Sparkle to architektura zaproponowana przez Antona, która łączy obliczeniowe DAG-i i dowody ZK. Chociaż zarówno Sparkle, jak i vProgs wykorzystują komponenty CDAG i ZK, rozwiązują one różne problemy projektowe.

Cechą charakterystyczną vProgs jest regulacja zależności. Każdy program kontroluje swoją przepustowość i unika dowolnych zależności zewnętrznych. Model ten wspiera kompozycyjność przy jednoczesnym zachowaniu izolacji.

Czy Hardfork wpłynie na bezpieczeństwo, MEV lub wymagania dotyczące węzłów?

• Budżet bezpieczeństwa: W krótkim okresie nie przewiduje się bezpośredniego wpływu. Poprawa zależy od faktycznego wdrożenia produktu, a nie od zmian w infrastrukturze.
   
• Wymagania węzła: Bez zmian
   
• Aukcje łapówek MEV: Uważa się, że jest to przedwczesne, biorąc pod uwagę obecny etap rozwoju ekosystemu.
   
• Grindowanie PoW dla STARKów: Dyskusje odwołują się do historycznych zachowań na wczesnym etapie istnienia Ethereum, gdzie adresy z zerami na początku obniżały koszty gazu, co z kolei prowadziło do mielenia kryptowalut na rynku proof-of-work. Wspomnienie miało charakter kontekstowy, a nie dotyczyło bieżącej funkcji.

Co dodaje SilverScript?

SilverScript to język wysokiego poziomu przeznaczony dla programów Kaspa. Jego celem jest uproszczenie tworzenia umów i programów.

Cele projektu obejmują:

• Czytelna składnia
• Dostępność dla nowych programistów
• Zgodność z narzędziami automatycznymi

Oczekuje się, że SilverScript obniży barierę tworzenia aplikacji opartych na umowach, gdy tylko zasoby natywne staną się dostępne.

Podsumowanie

Hardfork Kaspy, skoncentrowany na klauzulach, rozszerza funkcjonalność warstwy 1 poprzez natywne zasoby, rozszerzone klauzule i weryfikację ZK. Wprowadza CDAG do ustrukturyzowanego śledzenia zależności i kładzie podwaliny pod suwerenne vProgs. Aktualizacja zachowuje istniejące wymagania dotyczące węzłów i konsensus proof-of-work, umożliwiając jednocześnie programowalne wydawanie tokenów i transfery atomowe.

Aktywacja z 5 maja 2026 roku stanowi techniczny krok w planie rozwoju firmy Kaspa. Dodaje ona ustrukturyzowaną programowalność na poziomie protokołu i przygotowuje sieć do dalszych aktualizacji, w tym DAGKnight i pełnego wdrożenia vProgs.

Źródła:

• Hard Fork skupiony na Konwencji Kaspa:Odliczanie na Kas.live
• Wątek Terah X: Nadchodzące kamienie milowe i twardy widelec skoncentrowany na Przymierzu
• Badania Kaspy:Formalny model szkieletowy dla DAG obliczeniowego vProg