Майбутній хардфорк Kaspa, орієнтований на Ковенант: що нам відомо

Що таке хардфорк Kaspa, орієнтований на Ковенант?

За оцінкою Тема Тераха, Каспа готує хардфорк, орієнтований на ковенант, запланований на активація основної мережі 5 травня 2026 року. Оновлення розширюється Рівень 1 (L1) програмованість шляхом впровадження власних ресурсів та розширеної функціональності ковенантів. Це також закладає основу для перевірені програми (vProgs) та інтеграції з нульовим розголошенням (ZK).

Kaspa працює як блокчейн Proof-of-Work, використовуючи архітектуру blockDAG. Оновлення Crescendo у травні 2025 року збільшили пропускну здатність до 10 блоків за секунду (BPS). Таким чином, майбутній хардфорк базується на цьому фундаменті без зміни вимог до вузлів або фундаментальних принципів консенсусу.

Розробники-основачі описують реліз як масштабне оновлення. Він зосереджений на забезпеченні власної емісії токенів, програмованих правилах витрат та верифікації ZK на рівні L1. 

Який графік хардфорку 5 травня 2026 року?

Згідно з темою Тера, активації основної мережі передує кілька етапів:

• Скидання Testnet 12 (TN12): Заплановано на початок лютого 2026 року для підтримки тестування ковенантів та власних активів.
   
• Зобов'язання секвенсора KIP: Очікується приблизно 12 лютого 2026 року. Ця пропозиція запроваджує зобов'язання щодо корисного навантаження майнерів для посилення децентралізації в режимі реального часу.
   
• Реліз SilverScript: Мова програмування високого рівня для написання програм на Kaspa. Розроблена Орі Ньюманом та його колегами, вона спрощує розробку ковенантів.
   
• Хардфорк основної мережі: Травень 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 через канонічний міст. Рідний L1 KAS не може використовуватися безпосередньо.

Така конструкція відокремлює обчислення та стан від L1, зберігаючи при цьому спільне упорядкування та встановлення розв'язків.

Кому варто створювати vProgs?

Згідно з обговореннями в спільноті, більшості звичайних розробників додатків може не знадобитися vProgs.

Однак, vProgs може звернутися до:

• Архітектори Appchain
• Команди, що оцінюють системи зведення
• Проєкти, що створюють агенти штучного інтелекту з великим станом у мережі
• Системні розробники порівнюють контракти 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, де адреси з провідними нулями знижували витрати на пальне, що, своєю чергою, призвело до появи ринків Proof-of-Work Grind. Згадка була радше контекстуальною, ніж актуальною функцією.

Що додає SilverScript?

SilverScript — це мова програмування високого рівня, розроблена для програм Kaspa. Вона спрямована на спрощення розробки ковенантів та програм.

Його цілі дизайну включають:

• Читабельний синтаксис
• Доступність для нових розробників
• Сумісність з автоматизованими інструментами

Очікується, що SilverScript знизить бар'єр для написання застосунків на основі ковенантів, як тільки нативні ресурси будуть запущені.

Висновок

Хардфорк Kaspa, орієнтований на ковенанти, розширює функціональність першого рівня за рахунок нативних активів, розширених ковенантів та ZK-верифікації. Він впроваджує CDAG для структурованого відстеження залежностей та закладає основу для суверенних vProgs. Оновлення зберігає існуючі вимоги до вузлів та консенсус Proof-of-Work, водночас дозволяючи випуск програмованих токенів та атомарні передачі.

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

джерела:

• Орієнтований на Kaspa Convenant хардфоркЗворотний відлік на Kas.live
• Тера Х ТемаМайбутні віхи та хардфорк, орієнтований на Ковенант
• Дослідження КаспиФормальна модель магістралі для обчислювальної групи даних vProg