Хардфорк Toccata від Kaspa: умови, коди операцій ZK і нова ціль у червні

КаспаМайбутній хардфорк Toccata додасть до мережі два нових шляхи програмування: нативне програмування на основі ковенантів L1 та інфраструктуру додатків на основі нульового розголошення (zk), причому активація основної мережі тепер запланована на 5–20 червня 2026 року, що перенесено з початкової цілі 5 травня.

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

Що таке хард-форк Токата?

Toccata — це запланований хардфорк для мережі Kaspa, який впроваджує нові можливості безпосередньо в базовий рівень. Хардфорк, для тих, хто менш знайомий, — це оновлення протоколу, яке не є зворотно сумісним. Усі вузли повинні оновитися, щоб продовжувати участь у мережі.

Назва відповідає традиції 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-докази все частіше використовуються в масштабуванні блокчейну, оскільки вони дозволяють дешево та безпечно перевіряти обчислення поза блокчейном у блокчейні.

«Базований» у цьому контексті означає, що система zk повністю відповідає послідовності L1. Застосунок на основі zk не може додавати або видаляти транзакції самостійно. Він прив'язаний до власного порядку транзакцій Kaspa, що робить його надійним без окремого секвенсора.

Токата вводить кілька компонентів для підтримки цього:

• Коди перевірки ZK, включаючи гнучкий верифікатор Groth16 та верифікатор RISC Zero STARK
• Код операції доступу до зобов'язань послідовності, що дозволяє застосункам на основі L1 прив'язуватися до впорядкування L1
• КІП-21, архітектура розподіленого секвенування зобов'язань, яка гарантує, що витрати на доведення для zk-додатку масштабуються залежно від його власної активності, а не від загальної активності DAG.

Верифікатор RISC Zero STARK вже реалізовано та активовано в тестовій мережі 12. Чи буде він активований в основній мережі, ще вирішується.

Чому важливо довести вартість

Щоб будь-який zk-застосунок був практичним, вартість створення доказів має залишатися пропорційною тому, що робить сам застосунок. Якби zk-застосунок мав доводити роботу відносно всієї активності в ширшій DAG, витрати стали б непередбачуваними та некерованими. KIP-21 вирішує цю проблему шляхом розподілу зобов'язань щодо послідовності, зберігаючи робоче навантаження кожного застосунку автономним.

Що вже є?

Значна частина хардфорку вже реалізована. Наступні функції вже вбудовані:

• Розширена підтримка опкодів скриптового движка, основи основних ковенантів, згідно з KIP-17
• Ідентифікатори Ковенантів для управління походженням як консенсусної та рушійної функції, згідно з KIP-20
• Опкоди ZK з підсистемою попередньої компіляції zk-verifier, згідно з KIP-16, автор — Олександр Сафстром
• Код операції доступу до зобов'язань послідовності
• KIP-21, автор Саттон та впроваджений Максимом Бірюковим, повністю реалізований та очікує на розгляд

Maxim також завершив етапи перевірки концепції, включаючи вбудовані zk-ковенанти та zk-ковенанти на основі канонічного мосту KAS, і вони відіграли важливу роль у формуванні остаточного дизайну форка.

Чому дату хардфорку перенесли на червень?

Початковою цільовою датою основної мережі було 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. Значна частина технічної роботи вже виконана. Залишилося завершити доопрацювання інтерфейсів, об'єднати очікуючу гілку з головною та провести повне тестування на TN10, перш ніж буде підтверджено дату основної мережі.

Вікно з 5 по 20 червня 2026 року існує тому, що команда вирішила правильно налаштувати архітектуру зобов'язань щодо послідовності з першого разу, а не виправляти її пізніше в робочих умовах. Для операторів вузлів оновлення розроблено простим, без суттєвих змін інфраструктури, окрім незначного збільшення дискового простору.

Ресурси

1. Каспа на X: Пост (квітень 2026 р.)

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