Viitoarea hardfork centrată pe covenant a Kaspa: Ce știm

Ce este Hardfork-ul centrat pe Covenant al lui Kaspa?

În conformitate cu Firul lui Terah, mătreaţă pregătește un hardfork centrat pe covenant, programat pentru activarea rețelei principale pe 5 mai 2026. Actualizarea se extinde Stratul 1 (L1) programabilitate prin introducerea de resurse native și funcționalități extinse de convenție. De asemenea, pune bazele pentru programe verificabile (vProgs) și integrări cu cunoștințe zero (ZK).

Kaspa funcționează ca un blockchain proof-of-work folosind o arhitectură blockDAG. Actualizare Crescendo În mai 2025, a crescut debitul la 10 blocuri pe secundă (BPS). Astfel, viitorul hardfork se bazează pe această fundație fără a modifica cerințele nodurilor sau principiile fundamentale ale consensului.

Dezvoltatorii principali descriu lansarea ca pe o actualizare cu scop limitat. Aceasta se concentrează pe permiterea emiterii native de token-uri, a regulilor de cheltuieli programabile și a verificării ZK pe L1. 

Care este cronologia pentru Hardfork-ul din 5 mai 2026?

Activarea rețelei principale a avut loc în mai multe etape importante, conform firului de discuție al lui Terah:

• Resetare Testnet 12 (TN12): Programat pentru începutul lunii februarie 2026 pentru a susține testarea covenantului și a activelor native.
   
• KIP-ul de angajament al secvențiatorului: Așteptată în jurul datei de 12 februarie 2026. Această propunere introduce angajamente privind sarcina utilă a minerilor pentru a consolida descentralizarea în timp real.
   
• Lansare SilverScript: Un limbaj de programare de nivel înalt pentru scrierea de programe pe Kaspa. Dezvoltat de Ori Newman și colaboratori, simplifică dezvoltarea convențiilor.
   
• Hardfork-ul rețelei principale: Mai 5, 2026.

Actualizările post-hardfork includ DAGKnight, care vizează consensul adaptiv și un debit peste 100 BPS, precum și implementarea completă a vProgs.

Cum funcționează activele și convențiile native pe Kaspa?

Active native pe nivelul 1

Hardfork-ul introduce resurse native, inclusiv suport pentru Jetoane KRC20Aceste active există direct pe L1 și pot fi transferate atomic.

Transferurile atomice se aplică la:

• Convenții regulate în linie
• Execuții ale convenției ZK și non-ZK
• Transferuri de tokenuri KRC20

Clauzele inline generează dovezi imediate în cadrul portofelului. Nu există decuplare între datele tranzacțiilor și tranziția de stare. Acest design susține atomicitatea și execuția deterministă.

Legăminte extinse (Covenants++)

Sistemul de covenante Kaspa este inspirat de cercetările Bitcoin privind condițiile programabile de cheltuieli UTXO. Covenants++ extinde acest sistem pentru a permite reguli de tranzacție mai expresive.

Descoperă proiecte promițătoare...

Proiecte promițătoare...

(Publicitate)

Articolul continuă...

Cazurile de utilizare includ:

• Controale de securitate în stil Vault
• Mecanisme de escrow
• Transferuri condiționate
• Logică structurată a jetoanelor

Sistemul menține un model UTXO, în loc de contracte inteligente bazate complet pe conturi.

Ce este DAG-ul computațional (CDAG)?

Hardfork introduce DAG-ul computațional (CDAG)). CDAG înregistrează toate declarațiile de citire și scriere făcute de programe.

Această structură:

• Urmărește utilizarea resurselor
• Reglează dependențele dintre programe
• Pune în aplicare angajamentele privind gazele

Designul este comparabil cu modelele de execuție din blockchain-uri precum Solana și Sui, dar implementat complet în mediul blockDAG al Kaspa.

CDAG joacă un rol central în activarea suveranității vProgs.

Ce sunt vProg-urile și cum diferă de contractele inteligente?

vProg-urile sunt programe suverane care se execută în afara L1, în timp ce stabilesc rezultatele pe L1 prin demonstrații.

Proprietăți cheie:

• Execuție suverană: Fiecare vProg își definește propriile reguli de transfer și dependență.
• Controlul dependenței pe bază de gaz: Un vProg nu poate citi starea unui alt vProg decât dacă plătește pentru consumul de resurse.
• Transferuri neatomice: Programele virtuale (vProgs) nu sunt transparente pentru L1 în același mod ca resursele native. Transferurile sunt asincrone și non-atomice.
• Cerință KAS încapsulată: Orice legământ neinline trebuie să utilizeze KAS încapsulat printr-o punte canonică. KAS-ul nativ L1 nu poate fi utilizat direct.

Acest design separă calculul și starea de L1, păstrând în același timp secvențierea și așezarea partajate.

Cine ar trebui să construiască vProg-uri?

Conform discuțiilor din comunitate, majoritatea dezvoltatorilor de aplicații obișnuiți ar putea să nu aibă nevoie de vProgs.

Totuși, vProgs ar putea fi atractiv pentru:

• Arhitecți Appchain
• Echipe care evaluează sisteme de tip rollup
• Proiecte care construiesc agenți AI cu o stare on-chain extinsă
• Designerii de sisteme comparând contractele L1, cumulările L2 și modelele hibride

vProg-urile combină secvențierea unificată L1 cu starea și calculul externalizate.

Ce rol joacă tehnologia Zero-Knowledge (ZK)?

Hardfork-ul integrează verificarea ZK pe L1, extinzând propuneri anterioare precum KIP-16.

Capacitățile acceptate includ:

• Verificare Groth16
• Poduri fără încredere către sisteme L2
• Aplicații potențiale orientate spre confidențialitate

Se așteaptă ca aplicațiile inițiale să ruleze în linie, portofelele generând direct dovezi. Chiar și implementările ZK bazate pe covenant-uri dezvoltate de contribuitori precum Hans și Maxim se așteaptă să ruleze pe hardware standard. Nu este necesară o infrastructură specializată pentru demonstratori pentru implementările timpurii.

Un laptop standard poate genera demonstrații în baza ipotezelor actuale.

Programele axate pe confidențialitate sunt posibile din punct de vedere tehnic după hardfork. Cu toate acestea, confidențialitatea nu este menționată ca un obiectiv principal al foii de parcurs.

Cum se leagă Sparkle de vProgs?

Sparkle este o arhitectură propusă de Anton pentru combinarea DAG-urilor computaționale și a demonstrațiilor ZK. Deși atât Sparkle, cât și vProgs utilizează componente CDAG și ZK, ele abordează întrebări de design diferite.

Caracteristica definitorie a vProg-urilor este reglarea dependențelor. Fiecare program își controlează debitul și evită dependențele externe arbitrare. Acest model susține compozabilitatea, păstrând în același timp izolarea.

Va afecta Hardfork securitatea, MEV-ul sau cerințele nodurilor?

• Buget de securitate: Nu se așteaptă niciun impact direct pe termen scurt. Îmbunătățirile depind mai degrabă de adoptarea reală a produselor decât de schimbările de infrastructură.
   
• Cerințe ale nodului: Nici o schimbare.
   
• Licitații MEV cu mită: Considerat prematur, având în vedere stadiul actual de dezvoltare a ecosistemului.
   
• Măcinare POW pentru STARK-uri: Discuțiile fac referire la comportamentul istoric al Ethereum timpuriu, unde adresele cu zerouri la început reduceau costurile cu gazul, ceea ce, la rândul său, a dus la piețe de tip „proof-of-work” (probabilitate de lucru) cu prețuri reduse. Menționarea a fost contextuală, mai degrabă decât o caracteristică actuală.

Ce adaugă SilverScript?

SilverScript este un limbaj de nivel înalt conceput pentru programele Kaspa. Acesta își propune să simplifice dezvoltarea de convenții și programe.

Obiectivele sale de design includ:

• Sintaxă care poate fi citită
• Accesibilitate pentru noii dezvoltatori
• Compatibilitate cu sculele automate

Se așteaptă ca SilverScript să reducă bariera pentru scrierea aplicațiilor bazate pe convenții odată ce resursele native vor fi lansate.

Concluzie

Hardfork-ul Kaspa, centrat pe covenant-uri, extinde funcționalitatea Layer 1 prin intermediul resurselor native, covenant-uri extinse și verificare ZK. Introduce CDAG pentru urmărirea structurată a dependențelor și pune bazele pentru vProg-uri suverane. Actualizarea păstrează cerințele existente ale nodurilor și consensul proof-of-work, permițând în același timp emiterea de token-uri programabile și transferurile atomice.

Activarea din 5 mai 2026 marchează un pas tehnic în foaia de parcurs a Kaspa. Aceasta adaugă programabilitate structurată la nivel de protocol și pregătește rețeaua pentru actualizări ulterioare, inclusiv DAGKnight și implementarea completă a vProgs.

Surse:

• Furcă rigidă centrată pe Kaspa ConvenantNumărătoare inversă pe Kas.live
• Firul Terah XMomente importante viitoare și Hard Fork centrat pe Covenant
• Kaspa ResearchUn model formal de bază pentru DAG-ul de calcul vProg