Кошельки с мультиподписью обманчиво просты в теории. Двое друзей, желающих совместно подписывать транзакции, казначейство DAO, требующее одобрения совета, бизнес с несколькими заинтересованными сторонами — концепция проста. Сложная часть — не криптография и не ончейн-механика. Это координация.
Как участники узнают о незавершённой сессии подписания? Кто транслирует итоговую транзакцию? Что происходит, когда Алиса выходит из сети в процессе подписания, координатор Боба аварийно завершается, а Чарли не помнит, отправил ли он уже свою частичную подпись? Традиционные решения отмахиваются от этих вопросов: «используйте доверенный сервер», «координируйте вне полосы» или «просто поднимите свою инфраструктуру».
Это не решения — это перекладывание ответственности на централизацию или операционное бремя. Но одноранговая координация решаема с помощью тщательной инженерии распределённых систем.
Эта статья описывает, как мы построили по-настоящему децентрализованную координацию мультиподписей для Lotus и почему это важно для всей криптовалютной экосистемы.
Что такое MuSig2 и почему это важно?
MuSig2 — это протокол мультиподписей для подписей Schnorr. Несколько сторон совместно создают единую агрегированную подпись, которая криптографически неотличима от транзакции с одной подписью.
Преимущества в конфиденциальности и эффективности существенны. Традиционная мультиподпись P2SH для трёх участников требует 99 байт открытых ключей и 210 байт подписей — 309 байт в сумме. MuSig2 с Taproot использует 33 байта для открытого ключа и 64 байта для подписи — 97 байт, сокращение на 69%. Что ещё важнее, транзакция не раскрывает информацию о количестве участников или пороге подписания.
Свойства безопасности строги. MuSig2 предотвращает атаки с подменой ключа через коэффициенты агрегации ключей, вычисленные из всех ключей участников. Протокол предотвращает атаки повторного использования nonce (которые привели бы к утечке приватных ключей) через тщательное управление сессиями и детерминированную генерацию nonce. Схема доказуемо безопасна в предположении дискретного логарифма, том же предположении, которое защищает одиночные подписи Schnorr и ECDSA.
В сочетании с Taproot MuSig2 позволяет реализовать сложное ончейн-поведение, которое выглядит как обычные платежи:
- Платёжные каналы со сложным разрешением споров — канал Алисы и Боба в стиле Lightning выглядит как стандартный адрес
- Казначейства DAO, требующие единогласного одобрения совета — мультиподпись 3-из-3 или 5-из-5 выглядит как единственный ключ
- Хранилища с временной блокировкой — средства заблокированы на шесть месяцев, если все стороны не согласятся на досрочное снятие
- Условное расходование — «заплатить Бобу, если выполнены условия, иначе вернуть Алисе»
Всё это выглядит в блокчейне как простые транзакции с одной подписью, если только не используется путь скрипта. Это не просто видимость конфиденциальности. Когда сложные транзакции неотличимы от повседневной активности, анализ блокчейна становится принципиально сложнее. Выигрывают все.
Протокол стандартизирован как BIP-327, реализован в Bitcoin Core и проверен криптографами. Но вот загвоздка: MuSig2 требует двух раундов интерактивного обмена.
Проблема централизованной координации
MuSig2 — это не смарт-контракт, который вы развёртываете и забываете. Это интерактивный протокол, требующий тщательной оркестровки:
Раунд 1: Обмен nonce Каждый участник генерирует nonce с использованием детерминированной генерации RFC 6979 (с дополнительной случайной энтропией по умолчанию для продакшн-безопасности) и делится публичными nonce. Все должны получить публичные nonce всех остальных, прежде чем продолжить.
Раунд 2: Обмен частичными подписями Каждый участник создаёт частичную подпись, используя свой приватный ключ, агрегированный nonce и данные транзакции. Эти частичные подписи объединяются в итоговую подпись.
Трансляция Кто-то должен отправить транзакцию в сеть. Кто? Что если он откажется? Что если произойдёт сбой?
Это создаёт проблему координации с несколькими сложными подзадачами:
Обнаружение и управление сессиями
Когда Алиса хочет потратить средства с адреса 3-из-3, который она делит с Бобом и Чарли, как её кошелёк сообщает Бобу и Чарли, что сессия подписания началась? Блокчейн не поможет — весь смысл в том, что ничего не происходит в блокчейне до завершения подписи. Традиционные подходы:
- Централизованный сервер-координатор: все подключаются к центральному сервису, который ретранслирует сообщения. Это работает, пока сервер не упадёт, не начнёт цензурировать транзакции, не будет скомпрометирован или пока оператор не решит взимать плату.
- Ручная координация: «Алиса отправляет Бобу и Чарли электронное письмо с hex транзакции. Боб отвечает со своей частичной подписью. Чарли в отпуске и не отвечает три дня.» Это не масштабируется.
- Собственная инфраструктура: каждый запускает сервер с публичным IP и координируется через прямые соединения. Это исключает мобильные кошельки, пользователей за NAT и всех, кто не готов управлять серверной инфраструктурой.
Аутентификация и безопасность
Как участники проверяют, что сообщения действительно отправлены ожидаемыми со-подписантами? В децентрализованной системе без центрального органа каждый узел должен самостоятельно проверять подлинность сообщений. Решение требует криптографического доказательства: сообщения подписываются приватным ключом отправителя, а получатели проверяют подпись против заявленного открытого ключа перед обработкой.
Атаки воспроизведения и повторное использование nonce
Что мешает Еве записать nonce Алисы из предыдущей сессии и воспроизвести его? Повторное использование nonce с разными сообщениями приводит к утечке приватных ключей. Протокол должен обеспечивать строгие фазовые переходы: нельзя отправить частичную подпись до сбора nonce, нельзя повторно использовать nonce в разных сессиях, нельзя подписывать разные транзакции в одной сессии.
Сбои координатора и переключение
Кто-то должен агрегировать частичные подписи и транслировать транзакцию. Очевидный выбор — назначить одного участника координатором. Но что если он отключится? Ждать бесконечно? Участники договариваются о новом координаторе вне полосы?
Ограничение частоты запросов и защита от DoS
В одноранговой системе что мешает злоумышленникам заваливать сессии подписания мусором? Нужно ограничение частоты, отслеживание репутации и возможность бана нарушителей — но без центрального органа.
Решение Lotusia
Наш подход объединяет три проверенных паттерна распределённых систем в единый слой одноранговой координации:
1. Многоуровневое обнаружение
Мы используем проверенную инфраструктуру libp2p с тремя взаимодополняющими механизмами обнаружения:
DHT (Распределённая хеш-таблица): Объявления о сессиях хранятся в DHT Kademlia (с репликацией k=20) с использованием идентификатора сессии, полученного из подписантов и сообщения. Когда Алиса создаёт сессию подписания, она публикует объявление в DHT. Боб и Чарли могут обнаружить его, запросив DHT с ID сессии. Это обеспечивает постоянное децентрализованное хранение без центрального сервера — сессии остаются доступными для обнаружения, даже когда создатель не в сети.
GossipSub: Для обнаружения подписантов в реальном времени участники публикуют объявления в темах PubSub, организованных по типу транзакции (например, musig2:signers:SWAP). Когда Боб объявляет о готовности к атомарным свопам, Алиса получает уведомление за 10-100 мс, если она подписана на эту тему. Это обеспечивает мгновенное обнаружение пиров без задержек опроса DHT.
Протокол прямых сообщений: После обнаружения друг друга координационные сообщения (nonce, частичные подписи) отправляются через протокол сообщений libp2p с маршрутизацией между пирами. Сообщения шифруются с использованием протокола Noise от libp2p и направляются через сеть к конкретным пирам, а не транслируются глобально.
Многоуровневый подход охватывает разнообразные сценарии: DHT для постоянного хранения сессий и обнаружения офлайн-участников, GossipSub для рекламы подписантов в реальном времени и прямой обмен сообщениями между пирами для собственно раундов подписания.
2. Сквозная криптографическая безопасность
Каждое сообщение протокола криптографически подписано подписями Schnorr. Объявления о сессиях, реклама подписантов, запросы на подписание и присоединения участников — все несут подписи, доказывающие, что отправитель контролирует свой заявленный приватный ключ. Этот слой аутентификации предотвращает отравление DHT, атаки с имперсонацией и подмену сообщений.
Архитектура безопасности реализует глубокоэшелонированную защиту через несколько независимых уровней:
Ограничение частоты: Пиры могут отправлять не более одного объявления в 60 секунд. Нарушения запускают автоматическую эскалацию — 10 нарушений приводят к постоянному занесению в чёрный список.
Устойчивость к Sybil-атакам: Каждый пир может объявить не более 10 открытых ключей по умолчанию (50 для верифицированных идентичностей, 100 для институциональных пользователей). Это предотвращает заполнение сети фиктивными участниками одним актором.
Отслеживание репутации пиров: Система ведёт чёрные списки (постоянные баны) и серые списки (временные приостановки) на основе поведения. Недействительные подписи, нарушения лимитов частоты и попытки спама — всё это влияет на репутационные оценки, определяющие обращение с пиром.
Принудительное соблюдение фаз протокола: Автоматы состояний обеспечивают правильный порядок сообщений. Nonce не могут быть отправлены до установления сессии. Частичные подписи не могут быть отправлены до завершения агрегации nonce. Транзакции не могут быть транслированы до финализации подписи.
Защита от воспроизведения сообщений: Каждое сообщение включает строго возрастающий порядковый номер для каждого подписанта в каждой сессии. Дублирующие или неупорядоченные порядковые номера вызывают отклонение и репутационные штрафы.
Идентификация на основе сжигания (опционально): Участники могут привязать свою идентичность к транзакциям блокчейна, доказуемо сжигая XPI в специальном формате с тегом LOKAD. Такие идентичности позволяют ротацию ключей без потери репутации — идентичность привязана к (txId, outputIndex), а не к эфемерным ключам, и требует периодов созревания (144 блока для регистрации, 6 блоков для ротации) для предотвращения временных атак. В будущей реализации это может стать обязательным компонентом установления пировой репутации.
3. Детерминированное избрание координатора
Именно эта часть обеспечивает элегантное переключение при сбоях. Вместо ручного назначения координатора все участники запускают один и тот же детерминированный алгоритм.
Метод избрания по умолчанию — лексикографическая сортировка:
function electCoordinator(signers: PublicKey[]): ElectionResult {
// Sort public keys by binary buffer comparison
const sorted = signers
.map((pk, idx) => ({
originalIndex: idx,
publicKey: pk,
buffer: pk.toBuffer(),
}))
.sort((a, b) => a.buffer.compare(b.buffer))
// First in sorted order becomes coordinator
return {
coordinatorIndex: 0,
coordinatorPublicKey: sorted[0].publicKey,
sortedSigners: sorted.map(item => item.publicKey),
// ... index mappings and election proof
}
}
Все предоставляют одни и те же открытые ключи, все сортируют их одинаково, все выбирают первый — без голосования, без коммуникации, без неоднозначности. Сортировка точно совпадает с порядком участников в агрегации ключей MuSig2, обеспечивая согласованность на протяжении всего протокола.
Когда координатор падает или отказывается транслировать? Система автоматически переключается на следующего участника в отсортированном порядке. Это продолжается вплоть до N-1 сбоев, то есть мультиподпись 3-из-3 перестаёт отвечать, только если все три участника одновременно не в сети.
Детерминизм критически важен. В распределённых системах консенсус дорог. Но когда вы можете принять решение без координации — потому что каждый независимо вычисляет один и тот же ответ — вы устраняете целые классы отказов. Реализация также поддерживает методы избрания на основе хеша, первого подписанта и последнего подписанта для специфических случаев.
Что это даёт
Эти паттерны в совокупности поддерживают сценарии, которые ранее требовали централизованной инфраструктуры:
Казначейства с мультиподписью: От общих счетов 2-из-2 до казначейств совета 10-из-10 (все n-из-n), с автоматическим переключением координатора, обеспечивающим возможность расходования даже при частичных сбоях.
Платёжные каналы: Двусторонние каналы (Алиса ↔ Боб), где любая сторона может инициировать обновление канала, и канал остаётся работоспособным, даже если программное обеспечение координатора одной из сторон аварийно завершается.
Атомарные свопы: Настоящие одноранговые кросс-чейн свопы, где участники координируют одновременное подписание обеих сторон свопа без третьей стороны.
Хранилища с временной блокировкой: Средства, требующие подписи всех участников до таймаута, одной подписи — после. Координация мультиподписи происходит бесшовно в фоновом режиме.
Протокол конфиденциальности SwapSig: Наш аналог CoinJoin, где несколько сторон координируют создание единой транзакции с объединёнными входами и выходами, нарушая ончейн-отслеживаемость при сохранении индивидуальной верификации подписей. Будущая статья блога проведёт глубокий анализ SwapSig.
Инфраструктура универсальна. Всё, что требует интерактивного многостороннего подписания, может её использовать.
Последствия для криптовалютной экосистемы в целом
Эта реализация не зависит от конкретной криптовалюты. Слой координации работает независимо от консенсуса блокчейна — чистая одноранговая сеть и криптографическая передача сообщений. Bitcoin может адаптировать это для мультиподписей Taproot. Ethereum может использовать это для пороговых подписей в абстракции аккаунтов. Любая криптовалюта, поддерживающая подписи Schnorr, может интегрировать эту инфраструктуру. Каналы Lightning, атомарные свопы, протоколы конфиденциальности, управление DAO и операции DeFi — все требуют интерактивной многосторонней координации. Одна и та же инфраструктура решает все эти проблемы.
Что ещё важнее, это доказывает жизнеспособность децентрализованной координации для продакшн-систем. Индустрия по умолчанию использовала централизованных координаторов не потому, что P2P-координация невозможна, а потому, что никто не поставил рабочую реализацию. Когда появляется повторно используемая инфраструктура — как TCP/IP для сетей или TLS для шифрования — разработчики перестают считать проблему необязательной. Это меняет базовые ожидания: децентрализованная координация становится стандартом, а не исключением.
Статус реализации и дальнейшие шаги
Реализация завершена и работает. Более 91 теста проверяют реализацию протокола, избрание координатора, сценарии переключения, аутентификацию сообщений и защиту от воспроизведения. Код находится в активной разработке уже несколько недель и обрабатывает граничные случаи, обнаруженные в ходе обширного тестирования.
Управление соединениями надлежащим образом изолировано. Ваш кошелёк поддерживает общие P2P-соединения с сетью Lotus, и они отделены от соединений, специфичных для сессий подписания. Лимиты соединений кошелька не блокируют сессии мультиподписей, а активность мультиподписей не исчерпает ваши общие слоты для пиров.
Агрегированный открытый ключ MuSig2 становится внутренним ключом Taproot. Сложные деревья скриптов (для резервных условий или временных блокировок) остаются скрытыми, если не используется путь скрипта, при этом раскрывается только та ветвь, которая была использована.
Реализация находится в lotus-sdk, нашем современном SDK на TypeScript для Lotus. Рабочие примеры демонстрируют:
- Базовое подписание 2-из-2 с автоматическим обнаружением
- Многостороннее избрание координатора и переключение
- Интеграцию с Taproot через ключевой путь и путь скриптов
- Управление сессиями и защиту от воспроизведения
Техническая документация охватывает архитектурные решения, вопросы безопасности, использование API и процедуры тестирования.
Путь вперёд
MuSig2 элегантно и доказуемо решил математическую проблему многосторонних подписей Schnorr, но инфраструктура координации оставалась централизованной. Эта реализация доказывает, что одноранговая координация практична. Инфраструктура универсальна и повторно используема — постройте один раз, используйте повсюду. Технология должна укреплять человеческие отношения, а не затруднять или заменять их.
Теперь начинается критическая часть: эксперименты и итерации. Программное обеспечение зреет через реальное использование, а не спекуляции. Посмотрите, как репутация сообщества работает на практике в социальных профилях Lotusia, или прочитайте о том, как мы ранжируем контент. Установите lotus-sdk, поэкспериментируйте с примерами, сломайте протокол, сообщите о проблемах. Реальное использование выявит граничные случаи и определит следующую итерацию. Lotus всегда был о том, чтобы делать вещи правильно. Лотосианская Черепаха движется медленно, но целенаправленно к победе; один осторожный шаг за раз.
Ресурсы:
- Документация MuSig2 P2P — Полный справочник API и примеры
- Репозиторий lotus-sdk — Исходный код и набор тестов
- Спецификация BIP-327 — Спецификация протокола MuSig2
- Документация Lotus — Руководства по блокчейну и разработке
Сообщество:
- Discord — Техническое обсуждение в реальном времени
- Telegram — Дискурс сообщества
- GitHub Issues — Отчёты об ошибках и запросы на функции