Конверты KBRD и подписи BIP340 в Kaspa Boards

Как хранить и проверять структурированные данные вроде поста в соцсети на UTXO-блокчейне вроде Kaspa? Сам протокол поддерживает прикрепление произвольного массива байтов к каждой транзакции — поле payload. Но сырые байты бессмысленны без структуры и доказательства авторства.

Boards в Kaspa Forge решают эту задачу, определяя точный формат кодирования — конверт KBRD — и защищая его подписью BIP340 Schnorr. Это сочетание создаёт неизменяемый, верифицируемый и распознаваемый ончейн-пост. Это ключевой элемент стека протокола ончейн-данных Kaspa, который мы используем.

Проблема: структурированные данные на UTXO-цепочке

Транзакция Kaspa — это набор входов (UTXO, которые тратятся) и выходов (новые UTXO, которые создаются). Опционально она может нести payload — до 1 КБ произвольных данных. Часто это поле используется для сообщений, но без стандарта это просто кусок байтов. Чтобы построить надёжную систему вроде публичной доски, нам нужны три гарантии: 1. Структура: возможность распарсить разные поля (текст, ключ автора, флаги) из байтов payload. 2. Подлинность: криптографическое доказательство того, что данные были отправлены владельцем определённого ключа. 3. Целостность: доказательство того, что данные не были изменены при передаче.

Конверт KBRD и подпись BIP340 обеспечивают именно эти гарантии прямо на уровне транзакции.

Как работает механизм: анатомия конверта KBRD

Представьте конверт KBRD как стандартизированный контейнер для перевозки вашего поста. У него есть фиксированный заголовок, который говорит индексатору, как распаковать содержимое. Формат эволюционировал (v1 и v2), но базовые принципы остались теми же.

Упрощённое, концептуальное представление префикса конверта KBRD v2 (той части, которая подписывается) выглядит так:

[0x01, 0x02] // Магические байты KBRD + версия (например, 0x02 для v2)
[32 bytes]   // Эфемерный открытый ключ (ключ авторства, сжатый, x-only)
[16 bytes]   // Recovery Nonce (для детерминированного вывода ключа из сида в v2)
[1 byte]     // Флаги (битовое поле: например, `has_image`, `is_reply`)
[2 bytes]    // Длина слага доски (n)
[n bytes]    // Слаг доски (UTF-8, например, "/tech/")
[2 bytes]    // Длина текста (m)
[m bytes]    // Текст поста (UTF-8)
[32 bytes]   // SHA-256 хеш изображения (опционально, если установлен флаг `has_image`)
[32 bytes]   // ID транзакции для ответа (опционально, если установлен флаг `is_reply`)

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

Подписание через BIP340

Подпись покрывает не *весь* префикс конверта. Процесс выглядит так: 1. Вычисляется message_hash = SHA-256(байты_префикса_KBRD). 2. Этот 32-байтовый хеш подписывается схемой подписи BIP340 Schnorr приватным ключом, соответствующим ephemeral_pk.

// Концептуальный шаг подписания (Rust-подобный псевдокод)
let prefix_bytes = serialize(kbrd_prefix); // Структурированные байты выше
let message_hash = sha256(&prefix_bytes);
let signature = secp256k1_schnorr_sign(message_hash, author_sk); // author_sk для ephemeral_pk

Итоговый payload транзакции — это просто конкатенация префикса KBRD и 64-байтовой подписи BIP340.

Верификация: permissionless и детерминированная

В этом ключевая сила протокола ончейн-данных. Любой желающий может взять транзакцию Kaspa из BlockDAG, извлечь её payload и проверить: 1. Распарсить последние 64 байта как signature. 2. Предшествующие байты формируют prefix. 3. Вычислить message_hash = SHA-256(prefix). 4. Извлечь ephemeral_pk из начала префикса (байты 2–33). 5. Проверить signature по message_hash и ephemeral_pk.

Если проверка проходит, данные в префиксе гарантированно соответствуют тому, что задумал автор, и они навсегда зафиксированы в блокчейне.

Как это использует Kaspa Forge: полный конвейер

Конверт KBRD — не абстрактная спецификация; это живой фундамент нашего продукта Boards.

1. Запечатывание поста в Desk: Когда вы пишете пост в Kaspa Forge Desk, локальный WASM-код конструирует префикс KBRD v2 с вашим сообщением, выбранным слагом доски и свежим ephemeral_pk. Затем он детерминированно подписывает хеш префикса через BIP340 соответствующим author_sk (выведенным из сида вашего профиля). Далее кошелёк Desk формирует стандартную транзакцию Kaspa, финансирует её из имеющихся UTXO, прикрепляет запечатанный KBRD-пейлоад и транслирует её.

2. Индексация цепочки: Наш индексатор (board-indexer) непрерывно запрашивает узлы Kaspa через gRPC на предмет новых блоков. Для каждой транзакции он проверяет payload на наличие магических байтов KBRD. Если они обнаружены, выполняется описанная выше проверка BIP340. Только *проверенные* посты рассматриваются для индексации. Затем индексатор применяет уровень политики: детерминированно ранжирует посты по (daa_score, txid), используя оценку алгоритма корректировки сложности блока, разрешает деревья ответов, паркует ранние ответы к ожидающим родительским постам и сохраняет чистые данные в локальной базе. Здесь разделение очевидно: неизменяемые данные транзакции — это источник истины; индексированное представление — это производная, перестраиваемая проекция.

3. Обслуживание и модерация: Веб-приложение читает из базы индексатора. Действия модерации — такие как скрытие поста из-за NSFW-контента — влияют только на эту проекцию для чтения. Подписанный конверт KBRD в BlockDAG остаётся нетронутым. Наблюдатель может независимо проверить существование и содержание поста, запросив транзакцию из любого архивного узла.

4. Чаевые и ключи для сбора: Поле ephemeral_pk внутри конверта KBRD служит действительным адресом P2PK Kaspa. Чаевые отправляются непосредственно на этот адрес. Чтобы их собрать, Desk использует детерминированный путь вывода ("board/anon/<recovery_nonce>") для восстановления author_sk из сида, доказывая владение и переводя средства на основной кошелёк пользователя — процесс, полностью опирающийся на ончейн-фиксацию.

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

Эта система мощная, но сопряжена с компромиссами и присущими ограничениями.

• Данные против политики: Основной компромисс очевиден. Ончейн-данные (конверт KBRD + подпись) — неизменяемы, постоянны и проверяемы любым желающим. Представление индексатора мутабельно и зависит от политики. Пост, удалённый из представления Boards Kaspa Forge, по-прежнему существует, проверяемо подписанный, в BlockDAG. Это сделано намеренно.
• Размер payload: Лимит payload транзакции Kaspa (обычно 1 КБ) ограничивает объём текста и данных. Изображения не хранятся в блокчейне; хранятся только их SHA-256 хеши, которые ссылаются на хранилище вне цепочки.
• Защита от повторного воспроизведения и идентичность: Подпись конверта привязывает данные к ephemeral_pk, а не к конкретной транзакции. Индексатор реализует guard от повторного воспроизведения конверта (env_hash), чтобы предотвратить повторную трансляцию одного и того же подписанного конверта в новой транзакции с целью имитации или поднятия треда.
• Недетерминированность DAA Score: Транзакция может появиться в нескольких параллельных блоках DAG с разными daa_score, что влияет на порядок сортировки. Индексатор решает это, беря *минимальный* наблюдаемый daa_score для данного txid, сводя живое представление к пересборке с нуля. Глубокие реорганизации теоретически могут вызывать незначительные сбои в порядке, но они ограничены высокой частотой блоков Kaspa и безопасностью GHOSTDAG.
• Индексатор как необходимая линза: Без индексатора сырые ончейн-данные — это поток неупорядоченных, разрозненных транзакций. Задача индексатора — верификация, упорядочивание, построение тредов — именно то, что делает Boards удобными для использования. Это означает, что пользовательский опыт зависит от надёжности и честности оператора индексатора (в данном случае Kaspa Forge), хотя сырые данные остаются независимо аудируемыми.

Эта архитектура гарантирует, что Kaspa Boards построены на фундаменте проверяемой ончейн-истины. Конверт KBRD обеспечивает структуру, а BIP340 — криптографическую печать, создавая надёжный стандарт для данных в BlockDAG Kaspa.