Kaspa Python SDK 2.0.1 достиг стабильного статуса

18 июня Kaspa Python SDK обновился до версии 2.0.1 и был официально повышен со статуса бета до production/stable на PyPI. Для релиза, затрагивающего сериализацию ковенантов, расчёт storage-массы, события синхронизации кошелька и совершенно новый RPC-метод, стоит остановиться и разобраться, что изменилось — и почему эти детали важны для каждого, кто создаёт инструменты на Kaspa после Toccata.

Релиз был опубликован контрибьютором *smartgoo* и закрепляет зависимость от Rust на коммите rusty-kaspa cfafeb4c0 (v2.0.1). Это закрепление гарантирует, что Python-слой и нативный код узла согласованы по форматам сериализации, расчётам массы и сигнатурам RPC — необходимое условие для работы в продакшне.

Исправления привязки ковенантов: главное для разработчиков на Toccata

Наиболее значимые изменения в этом релизе — исправления сериализации CovenantBinding.

Ковенанты — фича Toccata, позволяющая ончейн-скриптам накладывать условия на будущие расходы — зависят от чётко определённого формата словаря при передаче данных между Python и Rust-узлом. До версии 2.0.1 вызов CovenantBinding.to_dict() возвращал вложенную структуру: ключи authorizingInput и covenantId оборачивались во внутренний ключ "inner". Метод from_dict() ожидал ту же вложенность. Это не соответствовало плоской структуре, описанной в документации 2.0.0 и в WASM SDK, из-за чего код, перенесённый между тремя SDK, мог молча формировать некорректные транзакции или выбрасывать ошибки ключей.

В версии 2.0.1 и to_dict(), и from_dict() используют плоскую структуру: {"authorizingInput": ..., "covenantId": ...}. Исправление приводит Python SDK в соответствие с документацией и WASM-слоем. Если вы создаёте инструмент, который конструирует или разбирает транзакции с ковенантами — кошельки, контракты эскроу, логику хранилищ, индексаторы — и обходили вложенный формат, ваш костыль теперь является багом. Обновитесь и протестируйте работу с новой структурой.

Связанное исправление касается создания PaymentOutput и TransactionOutput из словарей. Ранее, если в обычный словарь {"address": ..., "amount": ...} не был включён ключ "covenant", возникал KeyError. Это делало невозможным создание стандартного выхода без ковенанта из простого словаря без обязательного указания поля covenant. В версии 2.0.1 ключ covenant стал необязательным — как в документации и WASM SDK. Это небольшое улучшение эргономики, но оно снимает реальную проблему для каждого, кто пишет код построения транзакций, работающий и с ковенантными, и с обычными выходами.

GenesisCovenantGroup получил полноценный конструктор

GenesisCovenantGroup — структура группировки ковенантов на уровне генезиса — теперь можно создать напрямую:

group = GenesisCovenantGroup(authorizing_input, outputs)

Структура предоставляет authorizing_input и outputs как свойства и имеет метод __repr__ для отладки. Что важнее, Transaction.populate_genesis_covenants теперь принимает либо экземпляр GenesisCovenantGroup, либо обычный словарь с ключами "authorizingInput" и "outputs". Такой двойной подход упрощает построение транзакций как из структурированных объектов, так и из «сырого» JSON (например, при чтении из API или базы данных).

Ограничение расчёта storage-массы

Вспомогательная функция calculate_storage_mass теперь ограничивает среднее значение входных сумм снизу единицей, что соответствует поведению calc_storage_mass из rusty-kaspa v2.0.1. Без этого ограничения крайние случаи с очень малыми или нулевыми входами могли давать неопределённые или некорректные значения массы. Для майнеров и кода расчёта комиссий это исправление корректности, предотвращающее тонкие ошибки при проверках порога пыли и лимитов массы.

Новый RPC: get_seq_commit_lane_proof

Добавлен новый метод: RpcClient.get_seq_commit_lane_proof(request). Этот RPC был представлен в rusty-kaspa 2.0.0 и теперь доступен через Python-обёртки. Он возвращает подтверждение для последовательных коммитов в определённой полосе — данные, необходимые для верификации состояния относительно цепочки выбранных родителей GHOSTDAG в Kaspa.

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

События синхронизации кошелька включают прогресс SMT

События состояния синхронизации кошелька теперь содержат дополнительные данные на этапе импорта SMT (разрежённого дерева Меркла) в точке обрезки во время начальной загрузки блоков (IBD). Пayload содержит {processed, total}, предоставляя вызывающей стороне индикатор прогресса для шага, который ранее был «чёрным ящиком».