Kaspa простыми словами: blockDAG, десять блоков в секунду и как работает мультиподпись
Большинство сетей на proof-of-work создают блоки по одному: майнер находит блок, все строят поверх него, а любой конкурирующий блок, найденный в тот же момент, выбрасывается. Kaspa исходит из другого вопроса: а что, если параллельные блоки вообще не пропадали бы впустую?
Ответ — blockDAG, и именно благодаря ему Kaspa может выпускать десять блоков в секунду, оставаясь сетью на proof-of-work. Поддержка Kaspa скоро появится в SSP, поэтому разберёмся, чем эта сеть отличается и как в ней работает мультиподпись.
От цепочки к DAG
Если в Bitcoin два майнера находят блоки почти одновременно, сеть временно разветвляется. В итоге один блок побеждает, а другой становится «сиротой» — вложенная в него работа просто теряется. Чтобы сироты появлялись редко, Bitcoin нацелен на один блок раз в десять минут: этого времени хватает, чтобы каждый блок разошёлся по всей сети до того, как будет найден следующий.
Kaspa снимает это ограничение. Каждый новый блок может ссылаться не на один, а на несколько предыдущих блоков, поэтому все блоки, созданные параллельно, становятся частью реестра. Структура перестаёт быть единой цепочкой и превращается в направленный ациклический граф — DAG.
Но у DAG самого по себе есть проблема: если два параллельных блока содержат конфликтующие транзакции, какая из них считается? Протокол консенсуса Kaspa, GHOSTDAG, решает её, согласованно упорядочивая все блоки. Он выделяет хорошо связанное большинство блоков, созданных честными майнерами, и выстраивает всё в единый общепринятый порядок, так что каждый узел приходит к одному и тому же выводу о том, какая транзакция была первой.
В результате Kaspa может работать со скоростью десять блоков в секунду — такой темп действует со времени обновления Crescendo в 2025 году — без потерь на сиротах, которые парализовали бы цепочку на такой скорости. Для защиты реестра по-прежнему используется proof-of-work.
Что это значит на практике
- Быстрые подтверждения. Транзакции попадают в блоки примерно за секунду. Как и в любой сети, для крупных сумм глубина подтверждений по-прежнему важна — каждый блок сверху делает отмену транзакции сложнее, — но эта глубина набирается быстро.
- Монеты, а не счета. Kaspa использует модель UTXO, как и Bitcoin: ваш баланс — это набор отдельных монет, а при расходе часть из них объединяется, и сдача возвращается вам.
- Прунинг. Узлы Kaspa не хранят всю историю вечно: данные старых блоков удаляются примерно через полтора дня. Текущее состояние всегда можно проверить, но долгосрочная история транзакций хранится у индексаторов и обозревателей блоков, а не на каждом узле.
- Мелкие единицы. Один KAS равен 100 000 000 sompi — наименьшей единицы Kaspa.
Комиссии измеряются в «массе»
Bitcoin оценивает место в блоке в байтах. Kaspa — в массе, которая объединяет несколько видов затрат:
- Размер — сколько байтов занимает транзакция.
- Операции подписи — каждая проверка подписи добавляет фиксированную величину, поэтому расход с мультиподписью весит больше, чем расход с одним ключом.
- Хранение — правило KIP-9 делает дорогими транзакции, создающие множество крошечных выходов, чтобы реестр не заполнялся пылью.
При обычных переводах это незаметно: комиссии небольшие. Но это объясняет некоторые особенности Kaspa — например, почему отправка самому себе очень маленькой сдачи может быть отклонена и почему кошелькам иногда приходится объединять множество мелких монет перед крупным платежом.
Как работает мультиподпись в Kaspa
В Kaspa намеренно мало типов адресов. Адрес kaspa:q контролируется одним ключом. Адрес kaspa:p — это адрес pay-to-script-hash: он привязан к скрипту, и чтобы потратить средства, нужно раскрыть этот скрипт и выполнить его условия.
Мультиподписное хранилище — это адрес kaspa:p, скрипт которого гласит: «M из этих N ключей должны подписать». Kaspa использует подписи Schnorr, на уровне консенсуса поддерживает до 20 ключей в скрипте, а стандартные транзакции ретранслирует с числом ключей до 15. Две детали делают работу с ней удобной:
- Идентификатор транзакции не включает подписи. Вы знаете окончательный идентификатор транзакции ещё до того, как кто-либо её подписал, — это упрощает согласование подписей между устройствами.
- Нет слоя SegWit или Taproot. В Kaspa всего три стандартных типа выходов — с одним ключом, его вариант на ECDSA и pay-to-script-hash, — поэтому правильно реализовать нужно только один вид мультиподписного хранилища.
Одна тонкость важна для безопасности. Подпись в Kaspa фиксирует только сумму того конкретного входа, который она подписывает, а не суммы всех входов. Поэтому аккуратный мультиподписной кошелёк заставляет каждого подписанта самостоятельно проверять расходуемые монеты, а не доверять суммам, полученным от другого устройства.
Kaspa в SSP
SSP добавляет Kaspa по той же модели 2-из-2, что и для всех остальных сетей: ваше хранилище — это адрес kaspa:p, построенный из одного ключа в SSP Wallet и одного в SSP Key, и каждое устройство независимо проверяет, что именно оно подписывает. SSP Enterprise будет поддерживать хранилища Kaspa с одобрением по схеме M-из-N.
Пока это недоступно: поддержка Kaspa проходит финальное тестирование и будет анонсирована вместе с примечаниями к выпуску, когда выйдет. Библиотека, на которой она основана, @runonflux/kaspa-core, уже открыта для всех, кто хочет её изучить или использовать повторно.
Честный итог
Kaspa берёт знакомую идею — proof-of-work, защищающий реестр UTXO, — и убирает узкое место «по одному блоку за раз», позволяя блокам образовывать DAG. В итоге получаются быстрые блоки, комиссии по массе, а не по байтам, и чистая архитектура мультиподписи, построенная вокруг одного типа скрипта.
Как и в любой сети, ваши монеты защищает не частота блоков. Их защищает то, кто контролирует ключи, — а при мультиподписи ещё и то, сколько из них должны согласиться.
