Kaspa közelgő szövetségközpontú hardforkja: Amit tudunk

Mi az a Kaspa Covenant-Centric Hardforkja?

Szerint Terah szála, Amikor egy szövetség-központú hardforkot készít elő, amelyet a következő időpontra terveznek: főhálózat aktiválása 2026. május 5-én. A frissítés kiterjed 1. réteg (L1) programozhatóságot natív eszközök és kibővített szerződési funkciók bevezetésével. Emellett megalapozza a ellenőrizhető programok (vProgs) és a nulla tudású (ZK) integrációk.

A Kaspa proof-of-work blokkláncként működik, blockDAG architektúrát használva. Crescendo frissítés 2025 májusában másodpercenként 10 blokkra (BPS) növelte az átviteli sebességet. Így a közelgő hardfork erre az alapra épít a csomópont-követelmények vagy a konszenzusos alapok megváltoztatása nélkül.

A fejlesztők a kiadást egy hatókörön belüli frissítésként írják le. A hangsúly a natív tokenkibocsátás, a programozható költési szabályok és a ZK-ellenőrzés engedélyezésén van az L1-en. 

Mi a 2026. május 5-i Hardfork idővonala?

Terah hozzászóláslánca szerint a mainnet aktiválását számos mérföldkő előzi meg:

• Teszthálózat 12 (TN12) visszaállítása: A tervezett időpont 2026. február elejére van ütemezve a szerződéses és natív eszközök tesztelésének támogatására.
   
• Szekvenszer kötelezettségvállalás KIP: Várhatóan 2026. február 12. körül. Ez a javaslat bányászprogramokra vonatkozó kötelezettségvállalásokat vezet be a valós idejű decentralizáció megerősítése érdekében.
   
• SilverScript kiadás: Magas szintű programozási nyelv Kaspa-n írt programokhoz. Ori Newman és közreműködői fejlesztették ki, leegyszerűsíti a szerződések fejlesztését.
   
• Főhálózati Hardfork: Május 5, 2026.

A hardfork utáni fejlesztések közé tartozik a DAGKnight, amely az adaptív konszenzust és a 100 BPS feletti átviteli sebességet célozza meg, valamint a vProgs teljes körű telepítése.

Hogyan működnek a Native Assets és Covenants a Kaspán?

Natív eszközök az 1. rétegen

A hardfork natív eszközöket vezet be, beleértve a támogatást a következőkhöz: KRC20 tokenekEzek az eszközök közvetlenül az L1-en találhatók, és atomi szinten átvihetők.

Az atomátvitel a következőkre vonatkozik:

• Normál soron belüli szerződések
• ZK és nem ZK szövetség végrehajtások
• KRC20 tokenátutalások

Az inline szerződések azonnali bizonyítékokat generálnak a tárcán belül. Nincs szétválasztás a tranzakciós adatok és az állapotátmenet között. Ez a kialakítás támogatja az atomicitást és a determinisztikus végrehajtást.

Kiterjesztett szövetségek (Szövetségek++)

A Kaspa szövetségi rendszerét a Bitcoin programozható UTXO költési feltételekkel kapcsolatos kutatása ihlette. A Covenants++ kiterjeszti ezt a rendszert, hogy kifejezőbb tranzakciós szabályokat tegyen lehetővé.

Fedezze fel az ígéretes projekteket...

Ígéretes projektek...

(Hirdetés)

A cikk folytatódik...

Használati esetek többek között:

• Trezor stílusú biztonsági vezérlők
• Letéti mechanizmusok
• Feltételes átutalások
• Strukturált token logika

A rendszer UTXO modellt tart fenn a teljes fiókalapú intelligens szerződések helyett.

Mi a számítási DAG (CDAG)?

A hardfork bemutatja a számítási DAG-ot (CDAG)). A CDAG rögzíti a programok által tett összes olvasási és írási deklarációt.

Ez a szerkezet:

• Erőforrás-felhasználás nyomon követése
• Szabályozza a programok közötti függőségeket
• Gázkötelezettségek érvényesítése

A felépítés összehasonlítható a blokkláncok, például a Solana és a Sui végrehajtási modelljeivel, de teljes formában a Kaspa blockDAG környezetében valósult meg.

A CDAG központi szerepet játszik a vProgs szuverenitásának biztosításában.

Mik azok a vProgs-ok és miben különböznek az intelligens szerződésektől?

A vProg-ok szuverén programok, amelyek az L1 nyelven kívül futnak, miközben az eredményeket az L1 nyelven rendezik bizonyítások segítségével.

Főbb tulajdonságok:

• Szuverén kivégzés: Minden vProg meghatározza a saját átviteli és függőségi szabályait.
• Gázalapú függőség-szabályozás: Egy vProg nem tudja olvasni egy másik vProg állapotát, hacsak nem fizet az erőforrás-fogyasztásért.
• Nem atomi átvitelek: A vProg-ok nem transzparensek az L1 számára ugyanúgy, mint a natív eszközök. Az átvitelek aszinkronok és nem atomikusak.
• Becsomagolt KAS követelmény: Bármely nem soron belüli szövetségnek becsomagolt KAS-t kell használnia egy kanonikus hídon keresztül. A natív L1 KAS nem használható közvetlenül.

Ez a kialakítás elválasztja a számítást és az állapotot az L1-től, miközben megőrzi a megosztott szekvenálást és elszámolást.

Kinek érdemes vProg-okat fejlesztenie?

A közösségi megbeszélések szerint a legtöbb átlagos alkalmazásfejlesztőnek nincs szüksége vProgs-ra.

A vProgs azonban a következőknek lehet vonzó:

• Appchain architektek
• Csapatok értékelik a rollup stílusú rendszereket
• Nagy láncon lévő állapotú AI-ügynököket építő projektek
• Rendszertervezők összehasonlítják az L1 szerződéseket, az L2 összesítéseket és a hibrid modelleket

A vProgs egyesített L1 szekvenálást kombinál a külső állapot- és számítástechnikával.

Milyen szerepet játszik a nulla tudás (ZK)?

A hardfork integrálja a ZK-ellenőrzést az L1-en, kiterjesztve a korábbi javaslatokat, mint például a KIP-16.

A támogatott funkciók a következők:

• Groth16 bizonyítás ellenőrzése
• Trustless hidak L2 rendszerekhez
• Lehetséges adatvédelmi alkalmazások

A kezdeti alkalmazások várhatóan soron belül fognak futni, a tárcák közvetlenül generálják a bizonyításokat. Még a Hans és Maximhoz hasonló közreműködők által fejlesztett, szövetségen alapuló ZK implementációk is várhatóan futni fognak hagyományos hardvereken. A korai telepítésekhez nincs szükség speciális bizonyítási infrastruktúrára.

Egy szabványos laptop képes bizonyításokat generálni a jelenlegi feltételezések mellett.

Az adatvédelemre összpontosító programok technikailag lehetségesek a hardfork után. Az adatvédelem azonban nem szerepel az ütemterv elsődleges fókuszaként.

Hogyan kapcsolódik a Sparkle a vProgs-hoz?

A Sparkle egy Anton által javasolt architektúra a számítási DAG-ok és a ZK bizonyítások kombinálására. Bár mind a Sparkle, mind a vProgs CDAG és ZK komponenseket használ, eltérő tervezési kérdéseket céloznak meg.

A vProgs meghatározó jellemzője a függőségek szabályozása. Minden program szabályozza az átviteli sebességét, és elkerüli az önkényes külső függőségeket. Ez a modell támogatja az összeállíthatóságot, miközben megőrzi az izolációt.

Befolyásolja-e a Hardfork a biztonságot, a MEV-et vagy a csomópont-követelményeket?

• Biztonsági költségvetés: Rövid távon nem várható közvetlen hatás. A fejlesztések inkább a tényleges termékelterjedéstől, mint az infrastrukturális változásoktól függenek.
   
• Csomópont követelményei: Nincs változás.
   
• MEV kenőpénzes aukciók: Az ökoszisztéma fejlődésének jelenlegi szakaszát tekintve korainak tekinthető.
   
• PoW csiszolás STARK-okhoz: A beszélgetések a korai Ethereum történelmi viselkedésére utalnak, ahol a kezdő nullákkal rendelkező címek csökkentették az üzemanyagköltségeket, ami viszont a Proof-of-Work grinding piacokhoz vezetett. Az említés inkább kontextuális, mint aktuális funkcióra vonatkozott.

Mit ad hozzá a SilverScript?

A SilverScript egy Kaspa programokhoz tervezett magas szintű nyelv. Célja a szerződések és a programfejlesztés egyszerűsítése.

Tervezési céljai többek között:

• Olvasható szintaxis
• Akadálymentesítés új fejlesztők számára
• Kompatibilitás az automatizált szerszámokkal

A SilverScript várhatóan csökkenti a szövetségen alapuló alkalmazások írásának akadályát, amint a natív eszközök élesbe kerülnek.

Összegzés

A Kaspa szerződésközpontú hardforkja kibővíti az 1. réteg funkcionalitását natív eszközökkel, kiterjesztett szerződésekkel és ZK-ellenőrzéssel. Bemutatja a CDAG-t a strukturált függőségkövetéshez, és lefekteti a szuverén vProgs alapjait. A frissítés megőrzi a meglévő csomópontkövetelményeket és a proof-of-work konszenzust, miközben lehetővé teszi a programozható tokenek kibocsátását és az atomi átviteleket.

A 2026. május 5-i aktiválás technikai lépést jelent a Kaspa terveiben. Strukturált programozhatóságot biztosít protokollszinten, és felkészíti a hálózatot a további frissítésekre, beleértve a DAGKnight és a teljes vProgs telepítését.

Források:

• Kaspa Convenant-centrikus Hard ForkVisszaszámlálás a Kas.live-on
• Terah X szálKözelgő mérföldkövek és a szövetség-központú hard fork
• Kaspa ResearchEgy formális gerincmodell a vProg számítási DAG-hoz