Предстоящият хардфорк на Kaspa, фокусиран върху Covenant: Какво знаем

Какво представлява хардфоркът на Kaspa, фокусиран върху завета?

Според Темата на Тера, Каспа подготвя хардфорк, фокусиран върху ковенантите, насрочен за активиране на основната мрежа на 5 май 2026 г. Надстройката се разширява Слой 1 (L1) програмируемост чрез въвеждане на вградени ресурси и разширена функционалност на споразуменията. Това също така полага основите за проверими програми (vProgs) и интеграции с нулево знание (ZK).

Kaspa работи като блокчейн с доказателство за работа, използвайки blockDAG архитектура. Надстройка Crescendo през май 2025 г. увеличи пропускателната способност до 10 блока в секунда (BPS). По този начин предстоящият хардфорк надгражда върху тази основа, без да променя изискванията за възлите или фундаменталните принципи на консенсуса.

Основните разработчици описват изданието като обхватно подобрение. То се фокусира върху активиране на директно издаване на токени, програмируеми правила за харчене и ZK проверка на L1. 

Какъв е графикът за хардфорка на 5 май 2026 г.?

Според темата на Тера, няколко важни етапа предшестват активирането на основната мрежа:

• Нулиране на Testnet 12 (TN12): Планирано за началото на февруари 2026 г. в подкрепа на тестването на ковенанти и местни активи.
   
• KIP за ангажимент на секвенсъра: Очаква се около 12 февруари 2026 г. Това предложение въвежда ангажименти за полезен товар на миньорите, за да се засили децентрализацията в реално време.
   
• Издание на SilverScript: Език за програмиране на високо ниво за писане на програми върху Kaspa. Разработен от Ори Нюман и сътрудници, той опростява разработването на завети.
   
• Хардфорк на основната мрежа: May 5, 2026.

Надстройките след хардфорка включват DAGKnight, насочен към адаптивен консенсус и пропускателна способност над 100 BPS, както и пълното внедряване на vProgs.

Как работят местните активи и завети на Каспа?

Местни активи на слой 1

Хардфоркът въвежда нативни активи, включително поддръжка за KRC20 токениТези активи съществуват директно на L1 и могат да бъдат прехвърляни атомарно.

Атомните трансфери се прилагат за:

• Редовни вградени споразумения
• Изпълнения на ковенанти по ZK и извън ZK
• Трансфери на токени KRC20

Вградените споразумения генерират незабавни доказателства в портфейла. Няма разделяне между данните за транзакциите и прехода на състоянието. Този дизайн поддържа атомарност и детерминистично изпълнение.

Разширени завети (Завети++)

Системата за ковенанти на Kaspa е вдъхновена от изследванията на Bitcoin върху програмируемите условия за харчене на UTXO. Covenants++ разширява тази система, за да позволи по-изразителни правила за транзакции.

Открийте обещаващи проекти...

Перспективни проекти...

(Реклама)

Статията продължава...

Случаите на употреба включват:

• Контроли за сигурност в стил трезор
• Механизми за ескроу
• Условни трансфери
• Структурирана логика на токените

Системата поддържа UTXO модел, а не изцяло базирани на акаунти интелигентни договори.

Какво представлява изчислителният DAG (CDAG)?

Хардфоркът въвежда изчислителната DAG (CDAG). CDAG записва всички декларации за четене и запис, направени от програми.

Тази структура:

• Проследява използването на ресурси
• Регулира зависимостите между програмите
• Прилага ангажименти за газ

Дизайнът е сравним с моделите за изпълнение в блокчейни като Solana и Sui, но е реализиран изцяло в blockDAG средата на Kaspa.

CDAG играе централна роля в осигуряването на суверенитета на vProgs.

Какво представляват vProgs и как се различават от интелигентните договори?

vProgs са суверенни програми, които се изпълняват извън L1, докато установяват резултатите на L1 чрез доказателства.

Ключови свойства:

• Суверенно изпълнение: Всеки vProg дефинира свои собствени правила за пропускателна способност и зависимости.
• Контрол на зависимостта, базиран на газ: vProg не може да прочете състоянието на друг vProg, освен ако не плаща за потреблението на ресурси.
• Неатомни трансфери: vProgs не са прозрачни за L1 по същия начин като нативните ресурси. Трансферите са асинхронни и неатомни.
• Изискване за опакован KAS: Всяко не-вградено споразумение за достъп (KAS) трябва да използва обвита KAS връзка през каноничен мост. Нативната L1 KAS връзка не може да се използва директно.

Този дизайн разделя изчисленията и състоянието от L1, като същевременно запазва споделеното секвениране и уреждане.

Кой трябва да изгражда vProgs?

Според дискусиите в общността, повечето обикновени разработчици на приложения може да не се нуждаят от vProgs.

Въпреки това, vProgs може да се хареса на:

• Архитекти на Appchain
• Екипи, оценяващи системи тип „рол-ъп“
• Проекти, изграждащи AI агенти с голямо състояние на веригата
• Системни дизайнери, сравняващи L1 договори, L2 обединявания и хибридни модели

vProgs комбинират унифицирано L1 секвениране с екстернализирано състояние и изчисления.

Каква роля играе нулевото знание (ZK)?

Хардфоркът интегрира ZK проверка на L1, разширявайки по-ранни предложения, като например КИП-16.

Поддържаните възможности включват:

• Groth16 проверка на доказателството
• Безнадеждни мостове към L2 системи
• Потенциални приложения, ориентирани към поверителност

Очаква се първоначалните приложения да работят директно, като портфейлите генерират доказателства директно. Дори ZK имплементации, базирани на ковенанти, разработени от сътрудници като Ханс и Максим, се очаква да работят на стандартен хардуер. За ранните внедрявания не е необходима специализирана инфраструктура за доказване.

Стандартен лаптоп може да генерира доказателства при настоящите допускания.

Програми, фокусирани върху поверителността, са технически възможни след хардфорка. Поверителността обаче не е посочена като основен фокус в пътната карта.

Каква е връзката между Sparkle и vProgs?

Sparkle е архитектура, предложена от Антон за комбиниране на изчислителни DAG и ZK доказателства. Въпреки че както Sparkle, така и vProgs използват CDAG и ZK компоненти, те разглеждат различни дизайнерски въпроси.

Определящата характеристика на vProgs е регулирането на зависимостите. Всяка програма контролира своята пропускателна способност и избягва произволни външни зависимости. Този модел поддържа композируемост, като същевременно запазва изолацията.

Ще повлияе ли хардфоркът на сигурността, MEV или изискванията за възли?

• Бюджет за сигурност: Не се очаква пряко въздействие в краткосрочен план. Подобренията зависят от реалното приемане на продукта, а не от промените в инфраструктурата.
   
• Изисквания към възела: Без промени.
   
• Търгове за откуп на MEV: Счита се за преждевременно, предвид настоящия етап на развитие на екосистемата.
   
• PoW смилане за STARK: Дискусиите препращат към историческото поведение на ранния Ethereum, където адресите с водещи нули са намалили разходите за гориво, което от своя страна е довело до пазари за grind-ване на proof-of-work. Споменаването е било контекстуално, а не е било текуща функция.

Какво добавя SilverScript?

SilverScript е език на високо ниво, предназначен за Kaspa програми. Целта му е да опрости разработването на споразумения и програми.

Целите на дизайна му включват:

• Четлив синтаксис
• Достъпност за нови разработчици
• Съвместимост с автоматизирани инструменти

Очаква се SilverScript да намали бариерата за писане на приложения, базирани на ковенанти, след като нативните ресурси бъдат пуснати в експлоатация.

Заключение

Хардфоркът на Kaspa, фокусиран върху ковенантите, разширява функционалността на Layer 1 чрез нативни активи, разширени ковенанти и ZK проверка. Той въвежда CDAG за структурирано проследяване на зависимости и полага основите за суверенни vProgs. Надстройката запазва съществуващите изисквания за възлите и консенсуса за proof-of-work, като същевременно позволява издаване на програмируеми токени и атомни трансфери.

Активирането на 5 май 2026 г. бележи техническа стъпка в пътната карта на Kaspa. То добавя структурирана програмируемост на ниво протокол и подготвя мрежата за по-нататъшни подобрения, включително DAGKnight и пълно внедряване на vProgs.

Източници:

• Ориентиран към Kaspa Convenant хард форкОбратно броене на Kas.live
• Тема на Тера XПредстоящи етапи и хардфорк, фокусиран върху Ковенанта
• Каспа РисърчФормален модел на гръбнака за vProg изчисление DAG