Kaspa's Toccata Hard Fork: Covenants, ZK Opcodes és egy új júniusi cél

AmikorA közelgő Toccata hard forkja két új programozhatósági útvonalat ad hozzá a hálózathoz: natív L1 szövetségi programozást és alapú nulla tudású (zk) alkalmazásinfrastruktúrát, a mainnet aktiválása pedig most 2026. június 5-20. között lesz ütemezve, szemben az eredeti május 5-i céllal.

Michael Sutton, a Kaspa Core munkatársa publikált egy részletes frissítés arról, hogy mit tartalmaz a hard fork, miért változott a dátum, és hogyan várható a következő néhány hónap. Az elágazást eredetileg Ori Newman kezdeményezte azzal a céllal, hogy szerződéseket vigyenek be a Kaspa szkriptmotorjába, részben válaszul a Bitcoin körökben zajló OP_CAT vitára. Azóta valami lényegesen nagyobbá nőtte ki magát.

Mi az a Toccata Hard Fork?

A Toccata egy ütemezett hard fork a Kaspa hálózathoz, amely új képességeket vezet be közvetlenül az alap rétegbe. A hard fork, a kevésbé ismerősek számára, egy olyan protokollfrissítés, amely nem visszafelé kompatibilis. Minden csomópontnak frissítenie kell ahhoz, hogy továbbra is részt vehessen a hálózatban.

A név Kaspa hagyományát követi, miszerint zenei utalásokat használ a nagyobb fejlesztésekhez. Ez a darab egy klasszikus zenei formából, a toccatából kapta a nevét, amely egy billentyűs hangszeren használt technikai tudás bemutatására szolgál.

Magas szinten a Toccata két dolgot ad hozzá a Kaspához:

• Natív L1 szövetségi programozás egy új, Silverscript nevű fordítóprogramon keresztül
• zk alapú alkalmazásinfrastruktúra, ugyanazon szövetségi alapokra építve

Ezek nem felcserélhető rendszerek. Különböző felhasználási eseteket szolgálnak ki, és különböző fejlesztői közönségeket céloznak meg.

Mik azok a szövetségek és miért fontosak Kaspa számára?

A szerződéskötési feltételek olyan feltételek, amelyek meghatározzák, hogy egy tranzakció kimenetén lévő pénzeszközöket hogyan lehet a jövőben elkölteni. Egy szabványos Bitcoin vagy Kaspa tranzakcióban, miután a coinok elküldésre kerültek, a címzett azt tehet velük, amit akar. A szerződéskötési feltételek ezt megváltoztatják azáltal, hogy a költési szabályokat közvetlenül a szkriptbe ágyazzák.

A Kaspa egy UTXO modellt használ, hasonlóan a Bitcoinhoz, ahol minden tranzakció felhasználja a meglévő kimeneteket, és újakat hoz létre. Az UTXO rendszerben a szerződéskötések lehetővé teszik a fejlesztők számára, hogy meglepően összetett, állapotalapú, több szerződéses folyamatokat hozzanak létre, annak ellenére, hogy az alapul szolgáló számítás lokális marad az egyes UTXO-khoz képest.

A szerződéskötések fejlesztésének könnyebbé tétele érdekében a Kaspa Core véglegesíti a Silverscript fordítóprogramot, amelyet Ori Newman, Michael Sutton, az IzioDev és a Manyfest kezdeményezett. A Silverscript célja, hogy megkönnyítse és biztonságosabbá tegye az összetett szerződések írását és telepítését közvetlenül a Kaspa L1-en anélkül, hogy a fejlesztőknek a nyers szkriptmotor szintjén kellene dolgozniuk.

Mik azok a ZK-alapú alkalmazások?

A Toccata-ban bevezetett második programozhatósági pillér a zk-alapú alkalmazások. Ez a kettő közül a technikailag bonyolultabb, és érdemes alaposan kibontani.

Fedezze fel az ígéretes projekteket...

Ígéretes projektek...

(Hirdetés)

A cikk folytatódik...

A ZK a nulla tudást jelenti, egy kriptográfiai módszert, amely lehetővé teszi az egyik fél számára, hogy bebizonyítson valamit anélkül, hogy felfedné az alapul szolgáló adatokat. A ZK-bizonyításokat egyre inkább használják a blokklánc skálázásában, mivel lehetővé teszik a láncon kívüli számítások olcsó és biztonságos ellenőrzését a láncon.

Az „alap” ebben az összefüggésben azt jelenti, hogy a zk rendszer teljes mértékben követi az L1 szekvenálást. Egy alapú zk alkalmazás nem tud önállóan tranzakciókat hozzáadni vagy elvenni. A Kaspa saját tranzakciós sorrendjéhez van rögzítve, ami külön szekvencer nélkül is megbízhatóvá teszi.

A Toccata számos komponenst vezet be ennek támogatására:

• ZK ellenőrző műveleti kódok, beleértve egy rugalmas Groth16 ellenőrzőt és egy RISC Zero STARK ellenőrzőt
• Egy szekvenálási kötelezettségvállalási hozzáférési opkód, lehetővé téve az alkalmazások számára, hogy az L1 sorrendhez rögzítsék magukat
• KIP-21, egy particionált szekvenálási kötelezettségvállalási architektúra, amely biztosítja, hogy egy zk alkalmazás bizonyítási költségei a saját tevékenységével skálázódjanak, ne pedig a teljes DAG-tevékenységgel

A RISC Zero STARK ellenőrző már implementálva és aktiválva van a 12-es teszthálózaton. Az, hogy aktiválódik-e a főhálózaton, még nem eldöntött.

Miért fontosak a költségek bizonyítása?

Ahhoz, hogy egy zk alkalmazás praktikus legyen, a bizonyítások generálásának költségének arányosnak kell maradnia azzal, amit maga az alkalmazás tesz. Ha egy zk alkalmazásnak a tágabb DAG-on végzett összes tevékenységhez képest kellene bizonyítania a működését, a költségek kiszámíthatatlanná és kezelhetetlenné válnának. A KIP-21 ezt a szekvenálási kötelezettségek particionálásával oldja meg, így az egyes alkalmazások munkaterhelése önálló marad.

Mi van már a helyén?

A hard fork jelentős része már implementálva van. A következő funkciók már kiépültek:

• Kiterjesztett szkriptmotor-opkód támogatás, a központi szövetségi gerinc, KIP-17 alatt
• Szövetségi azonosítók a leszármazás-kezeléshez konszenzusos és motorfunkcióként, a KIP-20 keretében
• ZK opkódok egy zk-verifier előfordítási alrendszerrel, KIP-16 alatt, Alexander Safstrom szerzője
• Szekvenálási kötelezettségvállalási hozzáférési opkód
• KIP-21, Sutton alkotása és Maxim Biryukov megvalósítása, teljes mértékben megvalósítva és felülvizsgálat alatt áll.

A Maxim által kidolgozott koncepcióbizonyítási mérföldkövek, beleértve az inline zk kovenánsokat és az alapú zk kovenánsokat egy KAS kanonikus híddal, szintén fontos szerepet játszottak a fork végső kialakításában.

Miért halasztották júniusra a Hard Fork dátumát?

Az eredeti főhálózati célpont 2026. május 5. volt. Azóta ez egy 2026. június 5–20. közötti időszakra váltott.

Az ok architektúrális. Miután a zk áramkörök és futási környezetek egy szekvenálási kötelezettségvállalási hashelési struktúrához kapcsolódnak, az utólagos strukturális változtatások hibás változásokká válnak. A rossz tervezés és a későbbi javítás sokkal nagyobb zavart okozna, mint most rászánni a plusz időt.

A KIP-21-et már úgy tervezték, hogy jövőkompatibilis legyen a vprogs által végül megkövetelt kötelezettségvállalási rendszerrel, amely a Kaspa szinkron módon komponálható, ellenőrizhető programok hosszú távú ütemterve. A megfelelő struktúra rögzítése a főhálózat aktiválása előtt elkerüli a későbbi költséges migrációkat.

A funkciók befagyasztására várhatóan 2026. április 15-én kerül sor.

Mi történik a funkciók befagyasztása és a mainnet között?

Az április 15-i funkcióbefagyasztás után a Kaspa Core a dedikált teszthálózat, a TN12 tiszta újraindítását tervezi, a teljes végleges funkciókészlettel együtt. Ez nem a hard fork átmenet szimulációja. Ez egy tiszta hálózat a teljes funkciókészlet végleges formájában történő tesztelésére.

Innentől kezdve a csapat egy régóta függőben lévő ág felhalmozódott hónapok munkáját egyesíti vissza a fő kódbázisba. Ez a folyamat magában foglalja a végső auditálást, a nyitott elemek lezárását, a hard fork aktiválási logikájának tökéletesítését és az adatbázis frissíthetőségének kezelését.

Miután ez a munka befejeződött, egy teszt hard fork fut majd a TN10-en, a hosszú távú teszthálózaton, hogy szimulálja a teljes mainnet stílusú átmenetet. A mainnet dátuma csak azután kerül fix kódba, hogy a próba a csapat megelégedésére lefutott.

Mire számíthatnak a csomópont-üzemeltetők

A bányászok és a csomópont-üzemeltetők számára a frissítés egyszerű. A csomópontokat frissíteni kell, és a meglévő funkcióknak továbbra is működniük kell. A lemezterület-igény várhatóan nagyjából 20-50 százalékkal fog növekedni. Nem várhatók drámai infrastrukturális változások.

Mit nyújt valójában a Toccata Kaspának?

A Toccata két működő programozhatósági rendszert ad a Kaspa alaprétegéhez: natív L1 szövetségi szkriptelést Silverscript segítségével, valamint zk-alapú alkalmazásinfrastruktúrát KIP-16, KIP-20 és KIP-21 segítségével. A technikai munka nagy része már elvégezve van. Már csak az interfészek véglegesítése, a függőben lévő ág masterbe való egyesítése és egy teljes próba futtatása van hátra a TN10-en, mielőtt a mainnet dátumát megerősítik.

A 2026. június 5–20. közötti időszak azért létezik, mert a csapat úgy döntött, hogy elsőre helyesen kezeli a szekvenálási kötelezettségvállalási architektúrát, ahelyett, hogy később, éles körülmények között javítaná. A csomópont-üzemeltetők számára a frissítést egyszerűnek tervezték, a lemezterület szerény növelésén túl semmilyen nagyobb infrastrukturális változással.

Tudástár

1. Kaspa az X-enBejegyzés (2026. április)

2. Michael Sutton blogbejegyzése: Kaspa Covenants++ „Toccata” Hard-Fork Outlook