Координаційний форум KCC компанії Kaspa завершив роботу над трьома стандартами, що охоплюють інтерфейси ковенантів, авторизацію та взаємозамінні токени, встановлюючи спільні специфікації для розробників, які створюють застосунки в мережі.
Короткий огляд
- KCC-1 визначає спільні інтерфейси для гаманців, компіляторів, індексаторів та інших інструментів, що працюють із ковенантами.
- KCC-2 визначає п'ять стандартних схем авторизації, зокрема публічні ключі, скрипти та ідентифікатори ковенантів.
- KCC-20 встановлює правила передачі токенів і підтримує отримання токенів через наявний сумісний вихід.
- Завершення встановлює екосистемні конвенції без зміни правил консенсусу та без вимоги до кожного учасника їх приймати.
Координаційний форум KCC у своєму оголошенні від 21 жовтня повідомив, що KCC-1, KCC-2 та KCC-20 є остаточними та готовими до прийняття в усій екосистемі. Форум запросив розробників долучитися до його публічного каналу для запитань, обговорення реалізацій та підтримки.
Канонічний репозиторій стандартів 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 розвиває перші два стандарти, визначаючи суми токенів, право власності та інтерфейси передачі. У документі авторами названо Sivan Helfer, Sutton, Newman і Billot.
Його специфікація вимагає, щоб кожен ковенант токена публікував інформацію про програму, яку програмне забезпечення може використовувати для декодування стану та побудови передач. Конфігурації повинні розкривати підтримувані схеми володіння та обмеження на входи й виходи токенів.
Функція під назвою позикове отримання дозволяє відправнику використовувати наявний сумісний вихід токена одержувача як призначення. KCC-20 зазначає, що транзакція відтворює цей вихід із більшою кількістю токенів, зберігає його право власності та розширений стан і не може зменшити його вартість KAS.
Розділ безпеки попереджає, що заміна виходу змінює його посилання на транзакцію, роблячи недійсними непідтверджені транзакції, які витрачають попереднє посилання. Згідно з документом, гаманець повинен виявити заміну перед тим, як витрачати її.
Стандарт пов’язує еталонну реалізацію Argent зі згенерованими контрактами SilverScript і тестами відповідності Rust.
Остаточний статус несе вимоги до реалізації
KCC-0, документ, що регулює процес стандартів, вимагає більше, ніж завершення періоду остаточного розгляду. У ньому сказано, що конвенція стандартного треку потребує тестових векторів у формі, зрозумілій людині та машині, а також принаймні однієї публічної реалізації, яка проходить машинозчитувані перевірки.
Згідно з тими самими правилами, залежності повинні мати статус Final для інших KCC або Active для KIP. KCC-0 зазначає, що зміни статусу відбуваються через pull-запити, і індекс репозиторію повинен оновлюватися разом із ними.
KCC-0 описує машинозчитувані тестові вектори як авторитетну форму для автоматизованого тестування, коли вони супроводжують зрозумілі людині приклади. Його правила подання вимагають, щоб міркування безпеки охоплювали загрози, припущення щодо довіри та потенційні проблеми повторного відтворення, перш ніж документ стандартного треку зможе перейти до Last Call.
Керівний документ зазначає, що фіналізація не вимагає, щоб кожен учасник екосистеми реалізував конвенцію. Суттєві зміни зазвичай вимагають замінного KCC, тоді як виправлення та уточнення підпадають під правила внесення змін до документа.
Розробка застосунків Kaspa раніше включала окрему інфраструктуру Layer 2. Gate оголосила про інтеграцію Kasplex Layer 2 у квітні, уможлививши депозити та зняття KAS через EVM-сумісну мережу, як повідомляв crypto.news.
У своєму попередньому оголошенні про інтеграцію Gate заявила, що клієнти можуть переказувати KAS з базової мережі до гаманця Kasplex. Матеріали проєкту Kasplex описують двосторонній міст і зазначають, що розробники, знайомі з інструментами Ethereum, можуть розгортати контракти, змінивши свої кінцеві точки віддаленого виклику процедур.
Kasplex описує свій дизайн як легкий rollup, який розміщує байт-код EVM у транзакціях Kaspa та виконує його поза ланцюгом. Його документація зазначає, що Kaspa забезпечує впорядкування транзакцій і доступність даних, тоді як місткований KAS слугує газовим токеном Layer 2.
