Kaspa завершила три стандарти для рідних токенів та додатків з угодами

Форум координації KCC Kaspa завершив три стандарти, що охоплюють інтерфейси угод, авторизацію та обмінювані токени, встановлюючи спільні специфікації для розробників, які створюють додатки в мережі.

Резюме

• KCC-1 визначає спільні інтерфейси для гаманців, компіляторів, індексаторів та інших інструментів, що працюють з угодами.
• KCC-2 специфікує п’ять стандартних схем авторизації, включаючи публічні ключі, скрипти та ідентифікатори угод.
• KCC-20 встановлює правила передачі токенів і підтримує отримання токенів через існуючий сумісний вихід.
• Завершення встановлює екосистемні конвенції без зміни правил консенсусу або вимоги до кожного учасника їх приймати.

Форум координації KCC повідомив у оголошенні 21 жовтня, що KCC-1, KCC-2 та KCC-20 є остаточними та готовими до впровадження в екосистемі. Форум запросив розробників приєднатися до його публічного каналу для запитань, обговорень реалізації та підтримки.

Вітання $KAS. KCC-1, KCC-2 та KCC-20 тепер остаточні, що означає, що вони готові до повного впровадження в екосистемі.

Ми запрошуємо розробників Kaspa приєднатися до публічного каналу KCC, щоб ставити запитання, отримувати підтримку, обговорювати реалізації та ділитися тим, що ви створюєте.

Приходьте будувати з нами. --- Форум координації KCC (@kccforum) 21 жовтня 2026 року

Канонічний репозиторій стандартів Kaspa перераховує всі три документи як остаточні. Його індекс ідентифікує KCC-1 як специфікацію угод, KCC-2 як специфікацію авторитету, а KCC-20 як стандарт застосування для угод з обмінюваними токенами.

Репозиторій описує KCC як спільні конвенції для незалежних реалізацій. Його документація відокремлює ці конвенції від змін у консенсусі або поведінці основного вузла, які належать до пропозицій покращення Kaspa.

Стандарти Kaspa охоплюють різні частини розробки додатків

KCC-1 визначає загальні терміни, структури даних та інтерфейс бінарного додатку, або ABI, для угод. Специфікація описує, як програмне забезпечення кодує інформацію, викликає функції програми та ідентифікує стан, що переноситься між транзакціями.

Його автори, Роман Більо, Майкл Саттон та Орі Нуман, визначають компілятори, гаманці, індексатори та будівельники транзакцій серед інструментів, які повинні погоджуватися на ці деталі. Документ зазначає, що незалежні реалізації потребують спільних форматів, окрім простого створення скриптів, які проходять перевірки консенсусу.

Специфікація KCC-1 залишає розробникам свободу вибору мови програмування, компілятора та фреймворку. Його спільний інтерфейс охоплює точки входу програми, шаблони стану та правила для обробки транзакцій, що включають кілька входів.

У тому ж документі автори відрізняють основні правила інтерфейсу від функцій, які залежать від ідентифікаторів угод. Програми без прив’язок до угод можуть дотримуватися KCC-1, але специфікація зазначає, що вони не отримують гарантії походження та авторизації, надані KIP-20.

KCC-2 визначає, хто може авторизувати операцію

KCC-2, написаний Більо та Саттоном, специфікує, як програми ідентифікують авторитет і мінімальні перевірки, необхідні для встановлення його схвалення. Авторитетом може бути публічний ключ, зобов’язання щодо ключа, скрипт або продовжуюча лінія угод.

Специфікація призначає стандартні ідентифікатори п’яти схем авторизації. Його варіанти з публічним ключем охоплюють підписи Schnorr та ECDSA, тоді як інші варіанти дозволяють скрипту або лінії угод брати участь як авторитет.

Для авторизації за хешем публічного ключа KCC-2 вимагає, щоб транзакція розкривала відповідний публічний ключ, співвідносила його хеш з збереженим значенням авторитету та надавала дійсну підпис. Специфікації вищого рівня визначають підписане повідомлення та будь-які подальші умови.

Реєстр авторитетів резервує окремі діапазони для стандартних та індивідуальних схем. KCC-2 дозволяє учасникам приймати індивідуальні схеми без очікування стандартизації, за умови, що їх визначення специфікують формат, значення та перевірки схвалення.

Згідно з схемою ідентифікаторів угод, затвердження вимагає внеску від ідентифікованої лінії угод. KCC-2 зазначає, що угода вищого рівня може накладати додаткові перевірки на програму та стан цього внеску.

KCC-20 визначає правила передачі та отримання токенів

KCC-20 базується на перших двох стандартах, визначаючи кількість токенів, право власності та інтерфейси передачі. У документі вказані Сіван Хелфер, Саттон, Ньюмен та Біллот як його автори.

Його специфікація вимагає, щоб кожна угода токена публікувала інформацію про програму, яку програмне забезпечення може використовувати для декодування стану та створення передач. Конфігурації повинні розкривати підтримувані схеми власності та обмеження на вхідні та вихідні токени.

Функція, що називається запозиченим отриманням, дозволяє відправнику використовувати існуючий сумісний вихід токена отримувача як призначення. KCC-20 зазначає, що транзакція відтворює цей вихід з більшою кількістю токенів, зберігає його право власності та розширений стан і не може зменшити його значення KAS.

Розділ безпеки попереджає, що заміна виходу змінює його посилання на транзакцію, що робить недійсними непідтверджені транзакції, які витрачають попереднє посилання. Гаманець повинен виявити заміну перед її витрачанням, відповідно до документа.

Стандарт пов'язує реалізацію Argent з генерованими контрактами SilverScript та тестами відповідності Rust.

Остаточний статус несе вимоги до реалізації

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

Залежності повинні бути фінальними для інших KCC або активними для KIP, відповідно до тих же правил. KCC-0 зазначає, що зміни статусу відбуваються через запити на злиття, і індекс репозиторію повинен бути оновлений з ними.

KCC-0 описує тестові вектори, що читаються машиною, як авторитетну форму для автоматизованого тестування, коли вони супроводжуються прикладами, що читаються людиною. Його правила подання вимагають, щоб питання безпеки вирішували загрози, припущення довіри та потенційні проблеми повторного використання, перш ніж документ стандартного треку може увійти в останній виклик.

Управлінський документ зазначає, що фіналізація не вимагає, щоб кожен учасник екосистеми реалізував угоду. Суттєві зміни зазвичай вимагають заміни KCC, тоді як виправлення та уточнення слідують правилам внесення змін документа.

Розробка додатків Kaspa раніше включала окрему інфраструктуру другого рівня. Gate оголосила про інтеграцію Kasplex Layer 2 у квітні, що дозволяє депозити та зняття KAS через мережу, сумісну з EVM, як повідомляло crypto.news.

У своєму попередньому оголошенні про інтеграцію Gate зазначила, що клієнти можуть передавати KAS з базової мережі до гаманця Kasplex. Матеріали проекту Kasplex описують двосторонній міст і зазначають, що розробники, знайомі з інструментами Ethereum, можуть розгортати контракти, змінивши свої кінцеві точки віддаленого виклику процедур.

Kasplex описує свій дизайн як легкий роллап, який розміщує байт-код EVM у транзакціях Kaspa та виконує його поза ланцюгом. Його документація зазначає, що Kaspa забезпечує упорядкування транзакцій та доступність даних, тоді як KAS, що передається через міст, слугує токеном газу другого рівня.