Как может работать ковенант токена Kaspa с фиксированным предложением

Ковенант токена Kaspa — это не глобальная запись баланса и не тикер на уровне консенсуса. Это семейство ячеек UTXO на слое Toccata сети Kaspa, каждая из которых несет фиксированную идентичность, положительную сумму и ключ владельца — всё обеспечивается исключительно скриптом расходования каждой ячейки. В этой статье объясняется, как токен с фиксированным предложением может быть создан, передан и проверен в Kaspa, с использованием профиля KF20-FIXED-v1, который Kaspa Forge разработал, но не развернул. Токены планируются; ничего из описанного ниже не является запущенным продуктом.

Какую проблему это решает

Базовый уровень Kaspa перемещает KAS. В нем нет нативной концепции пользовательских активов. До появления ковенантов Toccata единственный способ представить пользовательский токен в Kaspa — это обернуть его во внешний контракт или перенести с другого чейна — оба подхода вводят кастодианов, мультисиги или предположения о доверии вне чейна.

Ковенанты меняют уравнение. Ковенант — это UTXO, чей скрипт расходования может инспектировать транзакцию, которая его тратит: выходы, их скрипты, их значения. Это означает, что ячейка токена может обеспечивать соблюдение своих правил на уровне консенсуса — положительные суммы, сохранение предложения, авторизованное владение — не полагаясь на минтера, фабричный контракт или оператора платформы.

База знаний разработчика в wiki Kaspa описывает основы UTXO и GHOSTDAG, которые делают это возможным: мержсет каждого блока принимает транзакции из его прошлого, а виртуальная цепочка упорядочивает их детерминированно. Ковенантный токен работает на этом же механизме.

Что на самом деле представляет собой ячейка токена Kaspa

Токен в Kaspa — это не строка в базе данных. Это набор живых ячеек UTXO, все они разделяют один и тот же Covenant ID — 32-байтный идентификатор, который действует как постоянный отпечаток семейства токенов.

Каждая ячейка хранит:

covenant_id         стабильная родословная семейства токенов
template/profile    известная форма программы (напр. KF20-FIXED-v1)
owner_type          режим авторизации (v1: x-only P2PK/Schnorr)
owner_identifier    32-байтный публичный ключ текущего владельца
amount              положительное целое число в минимальных единицах токена
KAS value           отдельная сумма KAS, несущая UTXO и оплачивающая хранение/массу

Баланс пользователя — это сумма amount по всем живым ячейкам, которыми он владеет. Обращающееся предложение токена — это сумма по всем живым ячейкам в семействе. Ни то, ни другое не хранится как единое число в блокчейне; оба вычисляются путем сканирования ячеек.

Читаемые метаданные — имя, тикер, десятичные знаки, хеш изображения — фиксируются при генезисе и индексируются вне чейна. Они помогают кошелькам отображать токен, но не заменяют Covenant ID как источник идентичности. Два токена с одинаковым тикером, но разными Covenant ID — это разные семейства.

Профиль KF20-FIXED-v1

Первый токен-профиль Kaspa Forge намеренно минимален:

• Фиксированное предложение. Всё предложение создается в одной транзакции генезиса. После генезиса нет ячейки-минтера, контроллера, полномочия на минтинг и пути скрипта, который может увеличить сумму.
• Владение P2PK. Владелец каждой ячейки — это 32-байтный x-only публичный ключ Schnorr. Никаких мультисигов, таймлоков, управления DAO — это отдельные будущие профили, а не скрытые флаги в v1.
• Сохранение. Каждая транзакция передачи должна удовлетворять: сумма количеств на потребленных ячейках токена равна сумме количеств на ячейках-преемниках. Нет пути сжигания; предложение может только перемещаться, никогда не уменьшаться.
• Нулевая комиссия за обслуживание. Транзакция генезиса не несет комиссионного выхода для Kaspa Forge. Единственные затраты — это стандартная комиссия сети Kaspa и резерв KAS, заблокированный в каждой ячейке токена.
• Только положительная арифметика. Каждая сумма проверяется в блокчейне как строго положительная, и каждая сумма проверяется. Это намеренное отступление от примера KCC20 из апстрима, который (по состоянию на рассмотренный снимок SilverScript) суммирует знаковые суммы без защиты положительности или проверки сложения — путь, который принимал 1000 → 1400 + (-400) в локальном тестировании VM.

Профиль заморожен на уровне спецификации P0. Его закрепления компилятора, закрепления целевого консенсуса, селекторы ABI, макет состояния (77 байт) и матрица мутаций задокументированы и версионированы. Он не развернут.

Генезис: как рождается семейство токенов

Процесс создания, как задумано, проходит через следующие шаги:

1. Намерение. Пользователь открывает раздел Токены в Desk, выбирает «Фиксированное предложение» и вводит метаданные (имя, тикер, десятичные знаки), число общего предложения и одно или несколько начальных распределений — каждое сопоставляет публичный ключ получателя с суммой токенов. 2. Валидация. Клиент проверяет, что суммы положительные, что итог соответствует объявленному предложению, что в локальном индексе нет дубликата тикера или имени, и вычисляет канонический дайджест метаданных (хеш BLAKE3 отсортированных полей метаданных). 3. Выбор UTXO. Клиент получает текущие UTXO кошелька пользователя и свежую котировку комиссии от ноды. Приватный ключ остается в сессии браузера; он никогда не отправляется на сервер. 4. Построение транзакции. Специализированный модуль token-wallet-wasm строит точную транзакцию генезиса: он потребляет один или несколько UTXO KAS в качестве входов финансирования, создает один чистый выход токена для каждого распределения (каждый несет программу токена, ключ получателя, сумму распределения и резерв KAS), вычисляет Covenant ID из первой точки финансирования и всех чистых выходов токена, добавляет опциональный выход сдачи P2PK и вычисляет массу транзакции и сетевую комиссию. 5. Подтверждение. На экране отображается ID токена, необработанное и читаемое предложение, каждый получатель с его суммой, резерв KAS на ячейку и сетевая комиссия. Строка комиссии за обслуживание показывает ноль. 6. Подписание. Пользователь повторно вводит свой пароль. Модуль WASM перестраивает транзакцию с нуля, проверяет каждое поле на соответствие намерению и подписывает ключом Schnorr пользователя, используя стандартную рандомизированную вспомогательную случайность. 7. Отправка. Подписанная транзакция отправляется на ноду Kaspa. Серверный слой допуска повторно проверяет форму транзакции — отклоняя неправильно сформированные отправки до того, как они попадут в мемпул — но он не может изменить подписанные байты. 8. Индексация. После того как транзакция принята в виртуальную цепочку, отдельный индексер, устойчивый к реорганизациям, сканирует блок, классифицирует выходы как ячейки токенов, записывает семейство токенов и помечает токен как имеющий проверенную историю. Только в этот момент токен появляется в публичном каталоге.

Передача: сохранение в действии

После создания ячейка токена может быть потрачена — передана новому владельцу — путем удовлетворения ее ковенантного скрипта. Правила строгие:

• Все потребленные ячейки токена в транзакции должны принадлежать одному и тому же Covenant ID.
• Все ячейки-преемники должны продолжать тот же Covenant ID.
• Сумма количеств на потребленных ячейках должна равняться сумме на ячейках-преемниках (сохранение).
• Каждая сумма должна быть строго положительной.
• Каждая авторизация владельца должна быть действительной подписью Schnorr над точным контекстом транзакции, привязанной к конкретному индексу входа.
• Нет смешивания между семействами: транзакция не может комбинировать ячейки из двух разных семейств токенов.
• Не принимаются неизвестные типы владельцев или поля расширения.

Передача, которая разделяет одну ячейку на 1000 единиц на две (скажем, 600 получателю и 400 сдачи отправителю) — это одна транзакция с двумя выходами токенов. Строитель сортирует входы, формирует точную форму преемника, и подписывающий проверяет полный пакет перед созданием подписи.

Как Kaspa Forge строит и проверяет

Архитектура разделяет обязанности на три слоя:

Клиент (Desk + token-wallet-wasm). React UI собирает намерение пользователя. Модуль WASM — это узкая поверхность: он принимает типизированные намерения, а не произвольные неподписанные транзакции. Он перестраивает каждую транзакцию из входов, наблюдаемых нодой, проверяет сеть, профиль, ID токена, суммы, владельцев, значения KAS, скрипты выходов, массу и комиссию — затем подписывает. Ключ существует только внутри разблокированной сессии, а временный буфер обнуляется после использования. Сервер не может подменить получателя, сумму предложения или шаблон без обнаружения несовпадения подписывающим.

Сервер (допуск + публичный шлюз). Сервер предоставляет типизированные эндпоинты для чтения семейств токенов, ячеек, держателей, активности и метаданных. Эндпоинт submit принимает только полностью подписанную транзакцию и повторяет проверки допуска перед пересылкой на ноду. Сервер никогда не строит транзакцию, никогда не запрашивает сид и никогда не подписывает.

Индексер (отдельный сервис). Индексер, устойчивый к реорганизациям, потребляет принятую виртуальную цепочку, классифицирует события токенов с использованием версионного классификатора профиля, ведет журнал отмен для атомарного отката во время реорганизаций и материализует производные представления — балансы, держатели, обращающееся предложение — из канонических живых ячеек. Эти производные представления вторичны; каноническая истинность — это всегда набор живых ячеек в блокчейне.

Только для чтения верификатор KCC — чистая граница Rust — позволяет Desk и индексеру независимо проверять вызовы KCC против закрепленной спецификации апстрима, не доверяя классификации сервера.

Компромиссы и честные границы

Это планируется, не запущено. По состоянию на август 2026 года, спецификация P0 заморожена, а инженерная работа P1 ведется в изолированном репозитории. Контракт, типизированный допуск, ABI на уровне компилятора, подписанный прямой генезис, золотые скрипты, векторы Covenant ID и воспроизводимый манифест существуют как артефакты, но имеют статус P1_SIGNED_GENESIS_COMPLETE_NOT_DEPLOYABLE. Оставшиеся ворота проверки P1, независимый пакет доказательства консенсуса P2 и производственная инфраструктура не завершены. Kaspa Forge Tokens нельзя использовать сегодня.

Черновики KCC из апстрима не являются консенсусом. KCC-0001, KCC-0002 и KCC-0020 находятся в ветке main репозитория KCC, но сохраняют статус Черновика. KCC-0021 остается открытым пулл-реквестом. Профиль KF20-FIXED-v1 закрепляет свои собственные точные версии апстрима и не претендует на ретроспективную совместимость с KCC20.

Пример KCC20 из апстрима небезопасен. Официальный пример SilverScript KCC20 на рассмотренном снимке суммирует знаковые суммы без защиты положительности или проверки сложения. Локальное тестирование VM подтвердило, что он принимает отрицательные распределения, которые раздувают видимое предложение. Производственный профиль решает это с помощью границ и проверяемой арифметики в блокчейне, но это намеренный выбор дизайна, а не исправление апстрима.

Отсутствие минтера означает отсутствие пути обновления. Как только токен KF20-FIXED-v1 создан, его предложение неизменно. Нет скрытой функции минтинга, нет контроллера для ротации, нет механизма управления. Это особенность для токенов с фиксированным предложением, но это означает, что профиль не может поддерживать активы, требующие продолжающейся эмиссии. Будущий профиль KF20-CAPPED-v1 — с минтером-контроллером, максимальным предложением и ротацией полномочий — есть в дорожной карте, но будет отдельным семейством ковенантов со своим аудитом и доказательством консенсуса, а не расширением v1.

Метаданные — это истина вне чейна. Имя, тикер и изображение фиксируются при генезисе и индексируются, но они не обеспечиваются ковенантным скриптом. Кто угодно может создать токен с вводящим в заблуждение тикером. Защита — это Covenant ID: это единственная стабильная, проверенная консенсусом идентичность. Кошельки и индексеры должны импортировать токены по Covenant ID, а не по тикеру.

Обработка реорганизаций. Протокол GHOSTDAG сети Kaspa производит частые небольшие реорганизации в широком DAG. Индексер ведет журнал отмен для атомарного отката и повторного применения состояния токенов через границы реорганизаций — тот же механизм, который уже используется в запущенных продуктах-ковенантах Kaspa Safe и Kaspa Escrow.

FAQ

Что такое ковенант токена Kaspa?

Ковенант токена Kaspa — это смарт-контракт на основе UTXO на слое Toccata сети Kaspa, который обеспечивает соблюдение правил токена (предложение, владение, передача) непосредственно в условиях расходования каждой ячейки-выхода, без глобального реестра балансов.

Как обеспечивается предложение токена KF20-FIXED-v1?

Общее предложение создается ровно один раз во время генезиса. После этого ни минтера, ни контроллера не существует. Каждая передача должна сохранять сумму количеств во всех потребленных и созданных ячейках токена, делая инфляцию невозможной на уровне скрипта.

Что такое Covenant ID и почему он важен?

Covenant ID — это уникальный идентификатор, получаемый из точек финансирования транзакции генезиса и чистых выходов токена. Он служит стабильной идентичностью всего семейства токенов — каждая последующая ячейка в этом семействе несет тот же Covenant ID. Это единственная идентичность токена, проверенная консенсусом; тикер и имя — это метаданные.

Может ли кто угодно создать токен Kaspa?

Профиль KF20-FIXED-v1 разработан как не требующий разрешений: любой пользователь с парой ключей Kaspa мог бы создать токен с фиксированным предложением через свой профиль Desk, без одобрения со стороны Kaspa Forge или какого-либо центрального органа. Однако этот продукт планируется и еще не запущен.

Что предотвращает отрицательные или завышенные суммы токенов?

Контракт KF20-FIXED-v1 обеспечивает только положительные суммы и проверяемую арифметику в блокчейне. В отличие от примера KCC20 из апстрима (который суммирует знаковые суммы без защит), производственный профиль проверяет границы каждой суммы и проверенные суммы всех ячеек-преемников.

Запущен ли Kaspa Forge Tokens?

Нет. По состоянию на август 2026 года, Kaspa Forge Tokens — это планируемая архитектура с завершенной спецификацией P0 и ведущейся разработкой P1. Это не запущенный продукт, и его нельзя использовать сегодня.