Toccata привнесла ковенанты в мейннет Kaspa. Теперь вопрос в том, что на них будет построено — и кто решит, как эти части будут сочетаться.
24 июля 2026 года ведущий разработчик Kaspa Майкл Саттон опубликовал три согласованных объявления, которые намечают ответ: форум стандартов сообщества под названием Kas-Smiths, формальный процесс конвенций — KCC, концептуальную модель для представления состояния ковенантов в виде «акторов», и новый язык программирования Argent для написания приложений с ковенантами. Отдельно контрибьютор @IzioDev открыл черновой пул-реквест для KCC-0001 — первой формальной спецификации ковенантов в рамках нового процесса.
В совокупности эти релизы представляют собой самую раннюю инфраструктуру для разработки ковенантов во всей экосистеме Kaspa — слой между самим протоколом и независимыми кошельками, приложениями и инструментами, которые будут его использовать.
Kas-Smiths: Мастерская до фрагментации
Kas-Smiths — это форум сообщества и репозиторий GitHub, предназначенные для координации стандартов экосистемы, протоколов, инструментов, кошельков и приложений до того, как независимые команды начнут строить несовместимые реализации.
Из приветственного поста Kas-Smiths:
«Kas-Smiths — это мастерская для координации экосистемы Kaspa. Место для обсуждения и выработки стандартов, протоколов, инструментов, кошельков, приложений и общей инфраструктуры, которая строится поверх Kaspa. Цель — создать практическое пространство, где идеи могут быть предложены, оспорены, улучшены и в конечном итоге превращены в нечто, на чём экосистема сможет строить».
Различие с предложениями по улучшению Kaspa (KIP) намеренное. KIP регулируют изменения в самом протоколе Kaspa — правила консенсуса, структуру блоков, всё то, в чём должен соглашаться каждый узел. KCC, сокращённо от Kaspa Calls for Conventions, регулируют добровольные соглашения между независимыми проектами: как должны представляться взаимозаменяемые токены на чейне, как должны раскрывать свои интерфейсы скрипты ковенантов, как кошельки должны интерпретировать состояние контракта. Никто не принуждён принимать KCC, но проекты, которые это делают, получают взаимодействие друг с другом.
Среди ранних предложений, уже находящихся на обсуждении, — KCC-20 для стандартов взаимозаменяемых токенов и KCC-0001 для ABI состоятельных скриптов ковенантов — тема черновика от @IzioDev, к которой мы вернёмся ниже.
Модель акторов: UTXO ковенантов как состоятельные агенты
Параллельно с запуском форума Саттон опубликовал аргументацию в пользу определённой ментальной модели для рассмотрения состоятельных UTXO ковенантов Kaspa: модели «актора», заимствованной из параллельного программирования.
Основная идея в том, что UTXO ковенанта не следует представлять как общие изменяемые данные, лежащие в реестре. Вместо этого каждый актор-ковенант исключительно владеет своим собственным состоянием и исключительно авторизует изменения этого состояния. Транзакция — это сообщение — взаимодействие — которое запускает следующий переход состояния актора.
Как написал Саттон: «Транзакция — это взаимодействие/сообщение, которое запускает следующий переход состояния актора». Он завершил аргументацию предложением стандартной терминологии:
«Я утверждаю, что это правильная ментальная модель и терминология, которые следует установить при обсуждении сущностей, контролирующих состояние ковенанта: фрагмент кода, владеющий состоянием и исключительно авторизующий его мутацию/потребление».
Это не изменение консенсуса. Это концептуальная модель — способ для разработчиков обсуждать всё более сложные приложения с ковенантами по мере развития исполнительного уровня Kaspa. Но формирование имеет значение: выбор неправильной абстракции на раннем этапе может заключить сообщество в терминологию, которая усложнит последующую проектную работу. Верно сформировать ментальную модель сейчас, пока экосистема ещё достаточно мала для координации, — это сознательное вложение.
Модель акторов — парадигма программирования, при которой каждая сущность («актор») владеет своим приватным состоянием и общается с другими акторами исключительно через сообщения. В контексте ковенантов Kaspa каждый UTXO ковенанта — это актор; транзакции — это сообщения, которые продвигают его через последовательные состояния.
Argent: Язык для приложений с ковенантами
Третье объявление — это Argent, описанный как «язык и компилятор на основе модели акторов для многоконтрактных и мультиприложений для построения приложений с ковенантами Kaspa».
Argent моделирует UTXO ковенантов как акторов, владеющих типизированным состоянием, а транзакции определяют, как эти акторы переходят между состояниями — напрямую реализуя концептуальную модель, которую описал Саттон. Компилятор переводит файлы исходного кода .ag в аудируемые контракты Silverscript и портативные артефакты, которые потребляет argent-runtime, отвечающий за построение транзакций и управление состоянием ковенантов.
Документация ясно говорит о зрелости: синтаксис и API будут меняться по мере развития системы, и проект ещё не прошёл аудит. Это инструментарий ранней стадии, а не готовая к использованию инфраструктура. Но его появление сигнализирует о том, что сообщество разработчиков Kaspa переходит от написанных вручную скриптов ковенантов к более высокоуровневым абстракциям, которые могут масштабироваться до сложных приложений.
Для любого, кто строит на ковенантах Kaspa — или оценивает, стоит ли строить, — наличие даже эволюционирующего языкового слоя меняет расчёт. Писать необработанный Silverscript для каждого приложения с ковенантами трудоёмко и чревато ошибками. Язык, который компилируется в аудируемые контракты и управляет переходами состояний программно, снижает порог входа, даже если он ещё не полностью стабилен.
KCC-0001: Первая формальная спецификация ковенантов
Контрибьютор Kaspa @IzioDev открыл черновой пул-реквест, предлагающий KCC-0001 — спецификацию, которая определяет основную терминологию, двоичный интерфейс приложения (ABI) и байтовые макеты для ковенантов Kaspa.
Черновик явно не зависит от какого-либо конкретного исходного языка, компилятора, фреймворка или формата артефактов. Он не изменяет правил консенсуса. Он определяет общий словарь и макет данных, с которым могут согласиться различные инструменты: программы ковенантов, экземпляры ковенантов, продолжения, шаблоны, линия идентификатора ковенанта, роли лидера и делегатора и виртуальные элементы.
Как написал @IzioDev: «Как первый (по порядку) kcc, kcc-01 вносит эти допущения в публичное обсуждение, пока их легко поставить под сомнение и изменить».
Последняя фраза важна. KCC-0001 находится в черновике, открыт для публичного рецензирования, и предлагается именно сейчас — до того, как реализации закрепятся вокруг несовместимых допущений. Спецификация предоставляет общую основу для будущих инструментов ковенантов и совместимости.
Почему это важно для держателей KAS и пользователей самостоятельного хранения
Ни один из этих релизов не меняет того, что KAS делает сегодня. Ваш узел работает так же. Ваши транзакции проверяются так же. Что изменилось, — это инфраструктура, которая определит, как будут выглядеть приложения, поддерживаемые ковенантами, через полгода или два года — и будут ли они работать вместе.
Для держателей, использующих инструменты самостоятельного хранения, стандарты ковенантов напрямую влияют на качество и безопасность доступных им инструментов. Когда независимые проекты договариваются о том, как представляется состояние ковенанта, кошельки могут точно отображать состояние контракта. Когда они договариваются об ABI, инструменты аудита могут единообразно проверять контракты. Когда они договариваются о языке и компиляторе, ошибки могут быть обнаружены на более высоком уровне до того, как они дойдут до исполнения на чейне.
Это соединительная ткань между возможностями Toccata на чейне и реальными инструментами, которые делают их полезными. Хранилища и контракты эскроу, которые строит Kaspa Forge, — это именно тот тип приложений с ковенантами, который выигрывает от общих стандартов — не потому, что им они необходимы для функционирования, а потому что конвенции всей экосистемы делают возможным аудируемый, совместимый инструментарий в масштабе.
Общие стандарты ковенантов важны для каждого пользователя самостоятельного хранения. Когда независимые инструменты приходят к согласию о том, как контракты представляют состояние, аудит становится единообразным, кошельки точно отображают информацию о контракте, а пользователи могут проверять, что они подписывают. Онлайн-хранилище Kaspa Safe — один из примеров приложения с ковенантами, которое выигрывает от такого рода координации во всей экосистеме — как работает хранилище.
Ширший контекст: Импульс токенизации
Тот же отчёт Kasmedia отмечает, что институциональная токенизация продолжала набирать обороты в течение недели: Depository Trust & Clearing Corporation (DTCC) объявила о транзакциях в живом производстве с использованием токенизированных представлений ценных бумаг — включая акции и сделки «поставка против платежа» по государственным облигациям США/операциям РЕПО. DTCC описала это как «самую масштабную производственную инициативу по токенизации по широте вариантов использования, классов активов и числу участников», предваряя запланированный на октябрь 2026 года запуск своей Службы токенизации.
Это происходит на инфраструктуре с разрешённым доступом, принадлежащей существующим участникам финансового рынка. Это не имеет прямой технической связи с Kaspa. Но более широкий тренд — цифровые представления реальных активов, расчёт по которым происходит на чейне, — это тот же класс задач, которую стандарты ковенантов на Kaspa в конечном счёте сделают возможной на базовом уровне без разрешений с доказательством работы.
Экосистема Kaspa не пытается воспроизвести то, что делает DTCC. Она строит открытую, аудируемую, кастодиальную инфраструктуру, которая позволяет физическим лицам и небольшим организациям участвовать в том же типе программируемого расчёта по активам — без доверия кастодиану, без запроса разрешения и с ключами, которые никогда не покидают их устройство.
Что будет дальше
Объявления от 24 июля 2026 года — это фундамент, а не готовые продукты. Kas-Smiths требует участия сообщества для создания стандартов, которые стоит принимать. KCC-0001 находится в черновике и на рецензировании. Argent развивается и не прошёл аудит. Модель акторов — это предложенная конвенция, а не установленный факт.
Но фундамент, заложенный рано, пока экосистема ещё достаточно мала для координации, как правило, формирует всё, что последует дальше. Альтернатива — фрагментированные реализации, несовместимые стандарты токенов, каждая команда, изобретающая ABI ковенантов с нуля, — это исход по умолчанию, когда инфраструктуры координации не существует.
Для держателей KAS, которым не всё равно, что будет построено поверх их блокчейна, эти релизы стоит отслеживать. Они — разница между блокчейном с поддержкой ковенантов и экосистемой ковенантов.
Сопроводительная серия эссе от контрибьютора сообщества moose.kas также расширилась примерно до 140 страниц в 16 эссе, объясняя первый том его книги о Kaspa — полезное справочное чтение для всех, кто следит за развитием экосистемы.
FAQ
Что такое Kas-Smiths?
Форум сообщества и репозиторий GitHub, где разработчики Kaspa координируют стандарты, протоколы и инструменты для экосистемы — отдельно от KIP, которые изменяют сам протокол.
В чём разница между KIP и KCC?
KIP (Kaspa Improvement Proposals) определяют изменения в консенсусном протоколе Kaspa. KCC (Kaspa Calls for Conventions) определяют добровольные экосистемные конвенции, которые независимые проекты могут принять для улучшения совместимости.
Что такое Argent?
Язык программирования и компилятор на основе модели акторов для создания приложений с ковенантами на Kaspa. Он переводит файлы исходного кода .ag в аудируемые контракты Silverscript. Ещё не прошёл аудит.
Изменяет ли KCC-0001 правила консенсуса Kaspa?
Нет. Черновик спецификации явно указывает, что он не зависит от какого-либо исходного языка, компилятора или фреймворка и не изменяет консенсус.
Держите KAS там, где кражу можно отменить
Ковенант-сейф в мейннете Kaspa: ваши ключи, ваши правила, наш инструмент. Ончейн — бесплатно, навсегда.
Создать сейф
