Toccata Hard Fork на Kaspa: Споразумения, ZK кодове за операции и нова цел за юни

КаспаПредстоящият хардфорк на Toccata ще добави два нови пътя за програмиране към мрежата: нативно L1 програмиране по ковенант и базирана на zero-knowledge (zk) приложна инфраструктура, като активирането на основната мрежа вече е планирано за 5-20 юни 2026 г., което е отложено от първоначалната цел 5 май.

Майкъл Сътън от Kaspa Core публикува подробна актуализация за това какво включва хардфоркът, защо датата е променена и как се очаква да се развият следващите няколко месеца. Форкът първоначално е иницииран от Ори Нюман като опит да се внесат ковенанти в скриптовия енджин на Kaspa, отчасти в отговор на дискусията за OP_CAT в Bitcoin средите. Оттогава той е прераснал в нещо значително по-голямо.

Какво представлява хард форкът Toccata?

Toccata е планиран хардфорк за мрежата Kaspa, който въвежда нови възможности директно в базовия слой. Хардфоркът, за по-малко запознатите, е надстройка на протокола, която не е обратно съвместима. Всички възли трябва да надстроят, за да продължат да участват в мрежата.

Името следва традицията на Каспа да използва музикални препратки за основни подобрения. Това произведение е кръстено на класическа музикална форма, токата, произведение, предназначено да демонстрира технически умения при свирене на клавишен инструмент.

На високо ниво, Токата добавя две неща към Каспа:

• Програмиране на завети за естествено L1 ниво чрез нов компилатор, наречен Silverscript
• Базирана на zk приложна инфраструктура, построен върху същите тези заветни основи

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

Какво представляват заветите и защо са важни за Каспа?

Споразуменията са условия, наложени върху това как средствата от транзакция могат да бъдат изразходвани в бъдеще. При стандартна транзакция с Bitcoin или Kaspa, след като монетите бъдат изпратени, получателят може да прави с тях каквото си поиска. Споразуменията променят това, като вграждат правила за харчене директно в скрипта.

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

За да направи разработването на завети по-достъпно, Kaspa Core финализира Silverscript, компилатор, иницииран от Ори Нюман, Майкъл Сътън, IzioDev и Manyfest. Silverscript е проектиран да улесни и улесни писането и внедряването на сложни завети директно в Kaspa L1, без разработчиците да е необходимо да работят на ниво суров скриптов енджин.

Какво представляват базираните ZK приложения?

Вторият стълб на програмируемост, представен в Toccata, са базирани zk приложения. Това е по-технически наситеният от двата и си струва да бъде разгледан внимателно.

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

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

(Реклама)

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

ZK е съкращение от zero-knowledge (нулево знание) - криптографски метод, който позволява на едната страна да докаже, че нещо е истина, без да разкрива основните данни. ZK доказателствата се използват все по-често в мащабирането на блокчейн, защото позволяват евтино и сигурно потвърждаване на изчисления извън веригата (off-chain).

„Базирана“ в този контекст означава, че zk системата следва изцяло L1 секвенцията. Базираното на zk приложение не може да добавя или премахва транзакции независимо. То е обвързано със собствения ред на транзакциите на Kaspa, което го прави надеждно без отделен секвенсор.

Токата въвежда няколко компонента в подкрепа на това:

• ZK кодове за проверка, включително гъвкав Groth16 верификатор и RISC Zero STARK верификатор
• Опкод за достъп до ангажимент за последователност, което позволява на базирани приложения да се закрепят към L1 подреждането
• КИП-21, архитектура на ангажименти за разделено секвениране, която гарантира, че разходите за доказване на zk приложението се мащабират със собствената му активност, а не с общата DAG активност.

RISC Zero STARK верификаторът вече е внедрен и активиран в testnet 12. Дали ще се активира в mainnet все още се решава.

Защо доказването на разходите е от значение

За да бъде практично всяко zk приложение, разходите за генериране на доказателства трябва да останат пропорционални на това, което самото приложение прави. Ако zk приложението трябваше да доказва работа спрямо цялата активност в по-широката DAG, разходите биха станали непредсказуеми и неуправляеми. KIP-21 решава това чрез разделяне на ангажиментите за секвениране, като запазва работното натоварване на всяко приложение самостоятелно.

Какво вече е налице?

Значителна част от хардфорка вече е имплементирана. Следните функции вече са изградени:

• Разширена поддръжка на опкодове за скриптовия енджин, гръбнакът на основните споразумения, съгласно KIP-17
• Идентификатори на Споразумения за управление на родословието като консенсусна и двигателна функция, съгласно KIP-20
• ZK опкодове с подсистема за предкомпилиране zk-verifier, под KIP-16, автор Александър Сафстром
• Опкод за достъп до ангажимент за секвениране
• KIP-21, автор Сътън и внедрен от Максим Бирюков, е напълно внедрен и в процес на преглед.

Етапи на доказване на концепцията, включително вградени zk споразумения и базирани zk споразумения с KAS каноничен мост, също бяха завършени от Maxim и изиграха ключова роля за оформянето на окончателния дизайн на вилицата.

Защо датата на хардфорка беше преместена на юни?

Първоначалната цел за основната мрежа беше 5 май 2026 г. Оттогава е преместена на прозорец от 5 до 20 юни 2026 г.

Причината е архитектурна. След като zk схемите и средата за изпълнение се свържат със структура за хеширане на секвенционни ангажименти, всякакви структурни промени след това се превръщат в критични промени. Грешното проектиране и поправянето му по-късно би било много по-разрушително, отколкото отделянето на допълнително време сега.

KIP-21 вече е проектиран да бъде съвместим с бъдещата схема за ангажименти, която евентуално ще бъде изисквана от vprogs, дългосрочната пътна карта на Kaspa за синхронно композируеми и проверими програми. Заключването на правилната структура преди активирането на основната мрежа избягва скъпи миграции по-късно.

Очаква се замразяването на функциите да бъде на 15 април 2026 г.

Какво се случва между замразяването на функциите и основната мрежа?

След замразяването на функциите на 15 април, Kaspa Core планира чисто рестартиране на специализираната тестова мрежа TN12 с включен пълният финален набор от функции. Това не е симулация на прехода от хардфорк. Това е чиста мрежа за тестване на пълния набор от функции в окончателния му вид.

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

След като тази работа приключи, ще се проведе тестов хардфорк върху TN10, дългосрочната тестова мрежа, за да се симулира пълен преход в стил основната мрежа. Датата на основната мрежа ще бъде твърдо кодирана едва след като тази репетиция приключи по начин, удовлетворяващ екипа.

Какво трябва да очакват операторите на възли

За миньорите и операторите на възли, надстройката е проектирана да бъде лесна. Възлите трябва да бъдат актуализирани и съществуващата функционалност трябва да продължи да работи. Очаква се изискванията за дисково пространство да се увеличат с приблизително 20 до 50 процента. Не се очакват драматични промени в инфраструктурата.

Какво всъщност Токата предлага за Каспа

Toccata добавя две работещи системи за програмиране към базовия слой на Kaspa: нативно L1 скриптиране чрез Silverscript и базирана zk приложна инфраструктура чрез KIP-16, KIP-20 и KIP-21. Голяма част от техническата работа вече е свършена. Остава финализирането на интерфейсите, сливането на чакащия клон в master и провеждането на пълна репетиция на TN10, преди да бъде потвърдена датата на mainnet.

Прозорецът от 5 до 20 юни 2026 г. съществува, защото екипът е избрал да оправи архитектурата на ангажимента за секвениране от първия път, вместо да я поправи по-късно в реални условия. За операторите на възли надстройката е проектирана да бъде лесна, без големи промени в инфраструктурата, освен умерено увеличение на дисковото пространство.

Ресурси

1. Каспа на XПубликация (април, 2026 г.)

2. Статия в блога от Майкъл Сътън: Kaspa Covenants++ “Toccata” Hard-Fork Outlook