Kaspa's Toccata Hard Fork: Covenants, ZK operační kódy a nový červnový cíl

KaspaNadcházející hard fork Toccata přidá do sítě dvě nové programovatelné cesty: nativní L1 covenant programování a aplikační infrastrukturu založenou na nulových znalostech (zk), přičemž aktivace hlavní sítě je nyní naplánována na 5.–20. června 2026, což je posunutí oproti původnímu cíli 5. května.

Michael Sutton z Kaspa Core publikoval podrobná aktualizace o tom, co hard fork obsahuje, proč se datum posunulo a jak se očekává vývoj v příštích několika měsících. Fork původně inicioval Ori Newman jako snahu zavést covenanty do skriptovacího enginu Kaspy, částečně v reakci na diskusi o OP_CAT v bitcoinových kruzích. Od té doby se rozrostl v něco podstatně většího.

Co je to hard fork Toccata?

Toccata je plánovaný hard fork pro síť Kaspa, který zavádí nové funkce přímo do základní vrstvy. Hard fork, pro ty méně obeznámené, je upgrade protokolu, který není zpětně kompatibilní. Všechny uzly musí provést upgrade, aby mohly nadále působit v síti.

Název navazuje na tradici Kaspy, která využívá hudební odkazy pro výrazná vylepšení. Tato skladba je pojmenována po klasické hudební formě, toccate, skladbě určené k demonstraci technické zručnosti při hře na klávesový nástroj.

Na obecné úrovni Toccata přidává ke Kaspě dvě věci:

• Nativní programování L1 smlouvy prostřednictvím nového kompilátoru s názvem Silverscript
• Infrastruktura aplikací založená na ZK, postavený na stejných základech smlouvy

Nejedná se o zaměnitelné systémy. Slouží různým případům použití a cílí na různé vývojářské publikum.

Co jsou to smlouvy a proč jsou pro Kaspu důležité?

Smlouvy (covenanty) jsou podmínky, které kladou na to, jak mohou být finanční prostředky z transakčního výstupu v budoucnu utraceny. Ve standardní transakci Bitcoin nebo Kaspa si s nimi příjemce může po odeslání mincí dělat, co chce. Smlouvy to mění vložením pravidel pro utrácení přímo do skriptu.

Kaspa používá model UTXO, podobný Bitcoinu, kde každá transakce spotřebovává stávající výstupy a vytváří nové. Smlouvy v systému UTXO umožňují vývojářům vytvářet překvapivě komplexní stavové toky s více kontrakty, i když základní výpočet zůstává lokální pro každý UTXO.

Aby byl vývoj covenantů přístupnější, Kaspa Core dokončuje Silverscript, kompilátor iniciovaný Ori Newmanem, Michaelem Suttonem, IzioDevem a Manyfestem. Silverscript je navržen tak, aby usnadnil a bezpečněji psal a nasazoval komplexní covenanty přímo na Kaspa L1, aniž by vývojáři museli pracovat na úrovni skriptovacího enginu.

Co jsou to aplikace založené na ZK?

Druhým pilířem programovatelnosti, který představuje Toccata, jsou aplikace založené na zk. Jedná se o technicky nejhustší z těchto dvou a stojí za to si ho pečlivě prozkoumat.

Objevte slibné projekty...

Slibné projekty...

(Inzerát)

Článek pokračuje...

ZK je zkratka pro zero-knowledge (nulovou znalost), kryptografickou metodu, která umožňuje jedné straně dokázat, že je něco pravdivé, aniž by odhalila podkladová data. Důkazy ZK se stále častěji používají ve škálování blockchainu, protože umožňují levné a bezpečné ověření výpočtů mimo řetězec (off-chain) v řetězci.

„Založený“ v tomto kontextu znamená, že systém zk plně dodržuje sekvenci L1. Aplikace založená na zk nemůže samostatně přidávat ani odebírat transakce. Je ukotvena k vlastnímu pořadí transakcí Kaspy, což ji činí důvěryhodnou bez samostatného sekvenceru.

Toccata zavádí několik komponent, které to podporují:

• Ověřovací opkódy ZK, včetně flexibilního ověřovače Groth16 a ověřovače RISC Zero STARK
• Opkód přístupu k závazku sekvencování, což umožňuje aplikacím založeným na L1 ukotvení se v pořadí
• KIP-21, architektura děleného sekvenování, která zajišťuje, že náklady na prověřování aplikace zk se škálují s její vlastní aktivitou, nikoli s celkovou aktivitou DAG.

Ověřovač RISC Zero STARK je již implementován a aktivován na testovací síti 12. Zda se aktivuje na mainnetu, se stále rozhoduje.

Proč na dokazování nákladů záleží

Aby byla jakákoli aplikace zk praktická, musí náklady na generování důkazů zůstat úměrné tomu, co samotná aplikace dělá. Pokud by aplikace zk musela dokazovat práci vzhledem ke všem aktivitám v širší DAG, náklady by se staly nepředvídatelnými a nezvládnutelnými. KIP-21 to řeší rozdělením závazků sekvenování, čímž se udržuje samostatná pracovní zátěž každé aplikace.

Co je již zavedeno?

Významná část hard forku je již implementována. Následující funkce jsou již vytvořeny:

• Rozšířená podpora operačního kódu skriptovacího enginu, páteř jádra covenantů, v rámci KIP-17
• ID smlouvy pro správu linie jako konsensuální a engine funkci v rámci KIP-20
• Opkódy ZK s předkompilačním subsystémem zk-verifier, pod KIP-16, autorem je Alexander Safstrom
• Opkód přístupu k závazku sekvencování
• KIP-21, jehož autorem je Sutton a implementován Maximem Birjukovem, plně implementován a čeká na přezkum

Maxim také dokončil několik milníků v testování konceptu, včetně inline zk covenantů a zk covenantů založených na kanonickém mostu KAS, které sehrály klíčovou roli při formování finálního designu vidlice.

Proč se datum hard forku přesunulo na červen?

Původním cílem hlavní sítě byl 5. května 2026. Od té doby se přesunul na období od 5. do 20. června 2026.

Důvod je architektonický. Jakmile se obvody a běhové prostředí zk navážou na hašovací strukturu sekvenčních závazků, veškeré strukturální změny po provedení se stanou zásadními. Chybný návrh a jeho pozdější oprava by byly mnohem rušivější než věnovat tomu více času nyní.

KIP-21 je již navržen tak, aby byl v budoucnu kompatibilní se schématem závazků, které bude nakonec vyžadováno vprogs, dlouhodobým plánem společnosti Kaspa pro synchronně komponovatelné a ověřitelné programy. Uzamčení správné struktury před aktivací hlavní sítě umožňuje zabránit nákladným migracím později.

Zmrazení funkcí se očekává 15. dubna 2026.

Co se stane mezi zmrazením funkcí a mainnetem?

Po zmrazení funkcí 15. dubna plánuje Kaspa Core čistý restart dedikované testovací sítě TN12 s kompletní finální sadou funkcí. Nejedná se o simulaci hard forku. Jedná se o čistou síť pro testování kompletní sady funkcí v její finální podobě.

Poté tým sloučí nashromážděné měsíce práce z dlouhodobě čekající větve zpět do hlavní kódové základny. Tento proces zahrnuje finální audit, uzavření otevřených položek, zdokonalení logiky aktivace hard forku a řešení upgradu databáze.

Jakmile bude tato práce dokončena, proběhne testovací hard fork na TN10, dlouhodobé testovací síti, aby se simuloval úplný přechod ve stylu mainnetu. Datum mainnetu bude napevno naprogramováno až po tomto zkušebním spuštění ke spokojenosti týmu.

Co by měli operátoři uzlů očekávat

Pro těžaře a provozovatele uzlů je upgrade navržen tak, aby byl jednoduchý. Uzly je třeba aktualizovat a stávající funkce by měly i nadále fungovat. Požadavky na diskový prostor se pravděpodobně zvýší zhruba o 20 až 50 procent. Neočekávají se žádné dramatické změny infrastruktury.

Co Toccata ve skutečnosti přináší pro Kaspu

Toccata přidává do základní vrstvy Kaspy dva funkční programovatelné systémy: nativní skriptování L1 covenantů prostřednictvím Silverscriptu a aplikační infrastrukturu založenou na zk prostřednictvím KIP-16, KIP-20 a KIP-21. Velká část technické práce je již hotová. Zbývá dokončit rozhraní, sloučit čekající větve s master a spustit kompletní testovací verzi na TN10 před potvrzením data mainnetu.

Okno od 5. do 20. června 2026 existuje proto, že se tým rozhodl hned napoprvé správně nastavit architekturu sekvenčních závazků, než aby ji později opravoval za provozu. Pro provozovatele uzlů je upgrade navržen tak, aby byl přímočarý a bez větších změn infrastruktury kromě mírného zvětšení disku.

Zdroje

1. Kaspa na XPříspěvek (duben 2026)

2. Článek na blogu od Michaela Suttona: Kaspa Covenants++ „Toccata“ Hard-Fork Outlook