Почему токенам Kaspa нужен индексер с поддержкой реорганизаций

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

В этой статье объясняется, почему такой индексер необходим, как он пошагово реконструирует живые ячейки Kaspa и какое место он занимает в архитектуре Kaspa Forge. Kaspa Tokens запланированы, но ещё не запущены; описанный здесь индексер — часть этого плана, а не развёрнутый сервис.

Почему сканирование обычным кошельком не работает

В Bitcoin и большинстве UTXO-цепочек кошелёк обнаруживает свой баланс, сканируя выходы транзакций, адресованные его собственному адресу. Адрес — это прямая кодировка хеша открытого ключа, поэтому любой выход, адресованный этому адресу, принадлежит тому, кто владеет соответствующим закрытым ключом. Простого просмотра истории адреса достаточно.

Токеновые ячейки-ковенанты Kaspa нарушают это предположение. Открытый ключ владельца встроен в ончейн-состояние ковенанта — 77-байтовую структуру, — а не в стандартное поле адреса. Обычный кошелёк P2PK, сканирующий историю своего адреса, не перечислит эти выходы, поскольку они не отображаются как платежи на обычный адрес Kaspa. Кошелёк должен понимать конкретный шаблон ковенанта, декодировать состояние каждого выхода и извлечь поле владельца, чтобы определить, совпадает ли оно.

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

Реорганизации GHOSTDAG: река, которая меняет русло

У Kaspa нет единой линейной цепочки. Протокол GHOSTDAG порождает ориентированный ациклический граф блоков, в котором несколько блоков могут майниться параллельно. Виртуальный блок — локальная для узла конструкция, указывающая на все текущие вершины — выбирает цепочку «выбранного родителя» через этот DAG. По мере поступления новых блоков выбранная вершина может меняться, а вместе с ней и выбранная цепочка. Это называется реорганизацией.

В Kaspa wiki это сказано прямо: «выбранная цепочка может меняться (поскольку виртуальная точка зрения меняется), это называется реорганизацией. В широком DAG небольшие реорганизации происходят часто». Это не катастрофические события — это нормальная работа. Блок, который мгновение назад был на выбранной цепочке, может оказаться на боковой ветви, а ранее не выбранный блок — стать частью канонической истории.

Представьте это как реку с несколькими руслами. «Основное русло» — выбранная цепочка — может сдвигаться по мере поступления новой воды. Небольшие сдвиги происходят постоянно. Для отслеживания токенов это имеет огромное значение. Токеновая ячейка, которая была отмечена как потраченная в транзакции, принятой одной выбранной цепочкой, может снова стать непотраченной, если эта цепочка будет отменена. И наоборот, непотраченная ячейка может внезапно оказаться потраченной транзакцией на вновь выбранной ветви. Любой индексер, игнорирующий реорганизации, будет сообщать о неверных балансах токенов Kaspa.

Ячейки-ковенанты: состояние токена живёт в UTXO

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

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

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

Конвейер индексера, шаг за шагом

Индексер BlockDAG с поддержкой реорганизаций для токенов Kaspa должен непрерывно выполнять следующий цикл:

1. Следить за принятой виртуальной цепочкой. Индексер подключается к узлу Kaspa и отслеживает принятую цепочку — последовательность блоков на пути выбранного родителя. Он ведёт chain_cursor, записывающий текущую принятую DAA-оценку и хеш.

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

3. Записывать переходы. Каждая транзакция, перемещающая токены, создаёт запись token_transition: идентификатор транзакции, DAA-оценка, при которой она была принята, тип операции (генезис или перевод), итоги по входам/выходам и статус валидации.

4. Обрабатывать реорганизации атомарно. При смене выбранной вершины индексер проходит назад от старой вершины и вперёд от новой, идентифицируя блоки, покинувшие или вошедшие в выбранную цепочку. Для каждого удалённого блока он обращается к undo_journal — журналу дельт, достаточных для отмены каждого изменения состояния, — и откатывает затронутые ячейки и переходы. Для каждого вновь принятого блока он применяет конвейер декодирования и классификации вперёд. Это атомарно: индекс никогда не находится в частично откаченном состоянии.

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

Модель сущностей, лежащая в основе этого конвейера:

token_families      — one row per token (Covenant ID, genesis, declared supply)
token_cells         — one row per UTXO (outpoint, owner, amount, spent/live)
token_transitions   — one row per accepted tx (kind, totals, validation)
token_metadata      — canonical name, ticker, decimals, image digest
chain_cursor        — current accepted DAA score and hash
undo_journal        — rollback deltas for atomic reorg handling

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

Почему зашифрованный профиль не может быть источником истины

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

Но он не может быть источником истины для токеновых балансов. Три причины:

Профиль не отслеживает цепочку. Это статический зашифрованный блок данных, а не живой процесс. У него нет подключения к узлу Kaspa, нет осведомлённости о новых блоках и нет возможности обнаруживать реорганизации. Баланс, записанный в момент T, может оказаться неверным в T+1, если реорганизация изменит порядок выбранной цепочки.

Токеновые ячейки не индексируются по адресу. Владелец находится внутри состояния ковенанта, а не в стандартном поле адреса. Ключи кошелька в профиле необходимы для авторизации расходования, но недостаточны для обнаружения существующих ячеек. Обнаружение требует сканирования цепочки с учётом шаблонов — обычная история адресов кошелька P2PK может не перечислить все токеновые ячейки.

Ячейки могут существовать на параллельных ветвях. В BlockDAG несколько блоков могут по-разному ссылаться на одну и ту же транзакцию. Ячейка, которая выглядит потраченной на одной ветви, может быть непотраченной на другой. Только индексер, отслеживающий непрерывно сдвигающуюся выбранную цепочку, может определить, какие ячейки являются каноническими в любой момент.

Поэтому профиль Desk хранит только то, что может знать независимо: какие токены создал пользователь (createdTokens[]), какие токены он отслеживает (followedTokens[]) и любые ожидающие намерения по транзакциям. Фактический баланс всегда запрашивается из API чтения индексера.

Как Kaspa Forge планирует его использовать

Индексер — это основа чтения для всех токеновых компонентов Kaspa Forge. Планируемые API-маршруты:

GET  /api/safe/tokens                                — list known tokens
GET  /api/safe/tokens/{covenant_id}                  — single token detail
GET  /api/safe/tokens/{covenant_id}/holders          — holder distribution
GET  /api/safe/tokens/{covenant_id}/activity         — transfer history
GET  /api/safe/tokens/{covenant_id}/cells?owner=...  — live cells for owner
POST /api/safe/tokens/submit                         — submit signed KF20 tx

Эндпоинты чтения не требуют аутентификации — они предоставляют публичные данные блокчейна. Эндпоинт submit принимает только полностью подписанную транзакцию, построенную клиентским подписантом token-wallet-wasm; сервер никогда не видит ключи и не конструирует транзакции. Публичные ответы сохраняют исходную сумму, владельца и происхождение состояния, чтобы любой сторонний клиент мог независимо повторно проверить представление.

В запланированной вкладке «Токены» в Desk будут использоваться эти эндпоинты для отображения балансов, построения превью переводов и показа активности. Граница подписанта гарантирует, что даже в случае компрометации сервер не сможет изменить получателя, сумму или шаблон транзакции — подписант отклонит несоответствие.

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

Зависимость от индексера для обнаружения. В отличие от Kaspa Safe, где одного узла достаточно для полного обнаружения хранилищ, поиск токеновых балансов зависит от индексера. Поле владельца внутри состояния ковенанта означает, что стандартное сканирование кошельком P2PK не найдёт токеновые ячейки. Если индексер отключится, токены останутся в безопасности в блокчейне — индексер не имеет прав хранения, — но запросы балансов и построение транзакций станут недоступны до его перезапуска или настройки альтернативной конечной точки чтения.

Глубина реорганизации против хранилища. Журнал отмен должен покрывать достаточную глубину для обработки самой длинной реалистичной реорганизации. В GHOSTDAG Kaspa реорганизации обычно неглубокие, но индексер должен быть консервативным. Более глубокий журнал означает больше хранилища; менее глубокий — риск неполного отката.

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

Независимость восстановления. Kaspa Forge планирует опубликовать индексер как открытый исходный код вместе с форматом дескриптора для каждого токена (сеть, Covenant ID, аутпоинт генезиса, хеш шаблона, дайджест метаданных) и CLI-утилитой восстановления. Цель: пользователь с сидом и дескриптором токена сможет восстановить свой баланс через собственный узел и совместимый индексер, не завися от хостинговой инфраструктуры Kaspa Forge. Это проектное обязательство, а не реализованный продукт.

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