Координационный форум 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 развивает первые два стандарта, определяя суммы токенов, право собственности и интерфейсы передачи. В документе авторами указаны Сиван Хелфер, Саттон, Ньюман и Билло.
Его спецификация требует, чтобы каждый ковенант токена публиковал информацию о программе, которую программное обеспечение может использовать для декодирования состояния и построения передач. Конфигурации должны раскрывать поддерживаемые схемы владения и ограничения на входы и выходы токенов.
Функция под названием заимствованный приём позволяет отправителю использовать существующий совместимый выход токенов получателя в качестве назначения. KCC-20 утверждает, что транзакция воссоздаёт этот выход с большим количеством токенов, сохраняет его право собственности и расширенное состояние и не может уменьшить его стоимость в KAS.
В разделе безопасности предупреждается, что замена выхода изменяет его ссылку на транзакцию, делая недействительными неподтверждённые транзакции, расходующие предыдущую ссылку. Согласно документу, кошелёк должен обнаружить замену до её расходования.
Стандарт связывает эталонную реализацию Argent со сгенерированными контрактами SilverScript и тестами соответствия на Rust.
Финальный статус влечёт требования к реализации
KCC-0, документ, регулирующий процесс стандартов, требует большего, чем завершение финального периода рассмотрения. В нём говорится, что конвенция стандартизационного трека нуждается в человекочитаемых и машиночитаемых тестовых векторах, а также как минимум в одной публичной реализации, проходящей машиночитаемые проверки.
Согласно тем же правилам, зависимости должны иметь статус Final для других KCC или Active для KIP. KCC-0 утверждает, что изменения статуса происходят через пул-реквесты, и индекс репозитория должен обновляться вместе с ними.
KCC-0 описывает машиночитаемые тестовые векторы как авторитетную форму для автоматизированного тестирования, когда они сопровождают человекочитаемые примеры. Его правила подачи требуют, чтобы разделы безопасности рассматривали угрозы, допущения о доверии и потенциальные проблемы повторного воспроизведения, прежде чем документ стандартизационного трека сможет перейти в Last Call.
В регулирующем документе указано, что финализация не требует, чтобы каждый участник экосистемы реализовал конвенцию. Существенные изменения, как правило, требуют заменяющего KCC, тогда как исправления и разъяснения следуют правилам внесения поправок в документ.
Разработка приложений Kaspa ранее включала отдельную инфраструктуру Layer 2. Gate объявила об интеграции Kasplex Layer 2 в апреле, обеспечив возможность внесения и вывода KAS через EVM-совместимую сеть, как сообщал crypto.news.
В своём более раннем объявлении об интеграции Gate заявила, что клиенты могут переводить KAS из базовой сети в кошелёк Kasplex. Материалы проекта Kasplex описывают двусторонний мост и утверждают, что разработчики, знакомые с инструментами Ethereum, могут развертывать контракты, изменив конечные точки удалённого вызова процедур.
Kasplex описывает свой дизайн как лёгкий роллап, который размещает байт-код EVM в транзакциях Kaspa и исполняет его вне сети. Его документация утверждает, что Kaspa обеспечивает упорядочивание транзакций и доступность данных, а мостовой KAS служит газовым токеном Layer 2.
