Подписи Schnorr и агрегация multisig

В предыдущей статье мы прошлись по тому, как SSP реально строит multisig-кошелёк on-chain: пути BIP48, два xpubs в лексикографическом порядке, redeem script, против которого chain проверяет. Вся эта механика построена поверх конкретной схемы подписи — ECDSA на кривой secp256k1, той же схемы, с которой Bitcoin запустился в 2009 и которую большинство сетей унаследовали.

Эта статья про другую схему подписи — Schnorr — и про то, что меняется, когда строишь multisig поверх неё. Главное изменение: Schnorr поддерживает агрегацию — при правильном протоколе n подписей от n cosigners могут быть сведены в одну подпись, которая on-chain выглядит как обычная подпись одиночного ключа. Кошелёк ведёт себя как multisig-кошелёк, но chain никогда не видит multi-сути. Это имеет реальные последствия для комиссий, приватности и того, какие виды multisig становятся экономически жизнеспособными.

TL;DR

• ECDSA — это то, чем подписывает большинство нынешнего multisig (включая SSP сегодня). Каждый cosigner производит отдельную подпись; chain проверяет их все. Стоимость и след масштабируются с n.
• Schnorr — другая схема подписи, включённая в Bitcoin через апгрейд Taproot 2021 года. У неё есть математическое свойство — линейность — которого нет у ECDSA. Линейность позволяет несколько Schnorr-подписей складывать в одну валидную подпись для комбинированного ключа.
• MuSig2 — современный практический протокол, превращающий это математическое свойство в работоспособный multisig-протокол. n cosigners запускают короткий интерактивный протокол, каждый вносит один раунд nonce и одну частичную подпись; результат — единственная Schnorr-подпись, неотличимая от одноключевой.
• Это строгий выигрыш на стороне верификации — комиссии, раздувание блокчейна и приватность все выигрывают. Не бесплатный выигрыш на стороне подписи: агрегация требует аккуратной работы с nonce, и багованная реализация может слить приватные ключи.
• SSP сегодня использует BIP48 + ECDSA multisig на поддерживаемых сетях. Roadmap — добавлять пути Schnorr/MuSig2 там, где сеть их поддерживает, не ломая существующую модель 2-of-2, которая у пользователей уже есть.

Быстрое освежение, что делает подпись

Цифровая подпись доказывает верификатору две вещи: эта конкретная сообщение было подписано кем-то, кто держит приватный ключ к этому публичному ключу. On-chain «сообщение» — это хеш транзакции, «публичный ключ» — это адрес (или то, что его выводит), а «верификатор» — каждый узел в сети. Если подпись проходит, транзакция валидна; иначе — отклоняется.

ECDSA — схема, которую используют Bitcoin и большинство EVM-сетей — хорошо изучена, консервативна и нормально работает для случая одного подписанта. Проблема в том, что происходит, когда хочешь, чтобы несколько подписантов авторизовали ту же транзакцию. У ECDSA нет способа объединять подписи. Если хочешь two-of-two, chain должна хранить обе подписи и обе проверять. Three-of-five, пять подписей. Транзакция растёт с числом cosigners.

What is multisig описывает протокольную часть — m из n ключей, redeem-правила, chain накладывает порог. На чём та статья не задерживается, это на стоимости: под ECDSA все эти подписи живут в транзакции. P2WSH 2-of-2 транзакция реально больше и дороже для бродкаста, чем single-sig транзакция с тем же эффектом.

Что меняет Schnorr

Schnorr-подписи, изначально предложенные в конце 1980-х, были обойдены в оригинальном дизайне Bitcoin из-за патентной неопределённости того времени. Они математически чище ECDSA в одном конкретном смысле: они линейны. Если s1 — валидная подпись на сообщении под ключом P1, а s2 — валидная подпись на том же сообщении под ключом P2, то s1 + s2 — валидная подпись на том сообщении под P1 + P2. И ключи, и подписи складываются.

Почему это важно: внезапно становится возможным объединять подписи до того, как они попадут в chain. Вместо двух подписей в транзакции хранится одна — сумма. Верификатор проверяет одну подпись против суммы двух публичных ключей, которую оба подписанта могут вычислить заранее. С точки зрения chain итоговая транзакция выглядит неотличимо от транзакции, подписанной одним ключом.

ECDSA так не умеет. Математика ECDSA содержит мультипликативный инверс, ломающий линейность; суммы ECDSA-подписей не являются валидными подписями. Поэтому multisig на ECDSA вынужден отправлять все индивидуальные подписи on-chain. Chain инспектирует каждую отдельно.

Bitcoin поставил Schnorr-подписи (через BIP340) в рамках soft fork Taproot 2021 года. Сами подписи немного меньше ECDSA (64 байта против ~71), но куда большая история — что линейность включает, когда сочетаешь её с multisig.

MuSig2 — multisig, который on-chain выглядит как одна подпись

Честная версия «можно складывать Schnorr-подписи» в том, что это надо делать аккуратно. Наивный подход — пусть каждый cosigner выберет nonce, поделится частичной подписью, всё сложим — сливает материал ключа при повторных подписях и уязвим к классу атак «rogue key». Практический протокол агрегации должен защищаться от обоих.

MuSig2 — результат примерно десятилетия шлифовки этой задачи. Это де-факто стандарт для n-of-n Schnorr multisig: при подписании cosigners обмениваются двумя раундами nonce, каждый создаёт частичную подпись, и один из них складывает частичные в финальную агрегированную подпись. Результат — одиночная Schnorr-подпись, валидная против одного агрегированного публичного ключа, on-chain неотличимая от одноключевой.

Несколько важных пунктов о MuSig2:

• Сейчас это n-of-n. Чтобы получить истинное m-of-n (например 2-of-3) под агрегацией, нужна дополнительная машинерия — FROST лидирует среди предложений — и оно ещё допиливается под прод. Так что в 2026 SSP мог бы чисто агрегировать только дефолт 2-of-2. Конфигурации 2-of-3 и выше из статьи-селектора всё ещё в основном используют ECDSA-style on-chain видимость.
• По-прежнему требует, чтобы оба cosigner были онлайн для подписи. Агрегация не уменьшает число нужных подписантов; она только сжимает финальный выход. UX тот же, что сегодня — два устройства подписывают одну транзакцию — но on-chain след результата меньше.
• Багованная реализация MuSig2 может слить ключи. Работа с nonce тонкая. Продакшн-деплои опираются на хорошо проаудированные библиотеки (модуль MuSig2 в libsecp256k1, стек rust-bitcoin и т.д.) по этой причине.

Что это значит для SSP сегодня

SSP сегодня на каждой поддерживаемой сети использует BIP48-производный ECDSA multisig. Два устройства, два приватных ключа, две отдельные подписи on-chain. Это корректно, проаудировано (Halborn — см. отсылку inside-ssp-2025-halborn-audits в существующей 2-of-2 статье), и интероперабельно с любым другим BIP48-совместимым кошельком. Минус — платишь полную on-chain стоимость 2-of-2.

Roadmap отсюда, простыми словами: добавить кодовый путь Schnorr/MuSig2 для Bitcoin (где Taproot живёт и стабилен), который подписывает тот же 2-of-2 кошелёк через агрегацию. Пороговая семантика кошелька не меняется — оба устройства всё равно должны подписывать. On-chain байты сжимаются, а итоговая транзакция выглядит как single-sig трата.

Для пользователя это в основном проявится как:

• Чуть более низкие комиссии Bitcoin на транзакцию.
• Улучшенная приватность — кошелёк перестаёт кричать «я multisig-кошелёк» в chain-аналитику.
• Более быстрая сверка для UI кошелька (чуть меньше данных на адрес фетчить и парсить).

Это не — и стоит это сказать ясно — обновление безопасности. Криптография сравнимо сложна, просто структурирована иначе. Причина внедрения — эффективность и приватность, не сырая безопасность.

Что это значит для стоимости, приватности и UX

Три места, где это приземляется, когда агрегация массово развёрнута на сети:

Стоимость. Bitcoin берёт комиссии приблизительно по размеру транзакции в vbytes. ECDSA P2WSH 2-of-2 транзакция значительно больше эквивалентной Taproot-MuSig2. Для кошельков с маленьким балансом, отправляющих мелкие суммы, относительная экономия комиссии может быть 20–30%. Для бизнесов с высоким throughput абсолютная экономия на годовых комиссиях — настоящие деньги.

Приватность. Сегодня, когда кошелёк бродкастит P2WSH 2-of-2 трату, этот факт виден всем, кто запускает блок-эксплорер. Продвинутые chain-аналитические фирмы кластеризуют адреса по паттернам трат, и «этот адрес — multisig» — сильный кластерный сигнал. Schnorr-агрегированная трата выглядит идентично single-sig трате. Кластерный сигнал исчезает.

UX. UX подписи в SSP — подпиши в браузере, потом подтверди на телефоне — не меняется. Оба устройства всё ещё производят частичные подписи; кошелёк просто комбинирует их перед бродкастом вместо того, чтобы бродкастить обе. С точки зрения пользователя единственное видимое изменение — «кошелёк ощущается дешевле в использовании».

На горизонте есть и более глубокий UX-выигрыш. Когда m-of-n агрегация (через FROST или аналогичное) будет готова к проду, можно представить SSP 2-of-3 кошелёк — как solo recovery сетап, который описывает предыдущая статья — который on-chain выглядит как обычный single-sig кошелёк. Третий «recovery» ключ — это действительно третий подписывающий ключ, но chain никогда об этом знать не должна.

Что это значит для тебя

Три вывода:

1. Тебе не надо думать о Schnorr, чтобы правильно использовать SSP. Setup 2-of-2, который у тебя сегодня, построен на хорошо проаудированном ECDSA multisig, и таким он остаётся независимо от того, как приземлится агрегация. Следующая статья серии (social recovery vs multisig) сознательно игнорирует агрегацию, потому что вопрос кто может тратить независим от как подпись выглядит on-chain.
2. Агрегация — это апгрейд «комиссии и приватность», не «безопасность». Если когда-либо увидишь кошелёк, рекламирующий «MuSig2 = безопаснее», будь скептичен. Криптографическая безопасность хорошо реализованного MuSig2 сравнима с хорошо реализованным ECDSA multisig; выигрыши в другом.
3. Смотри на поддержку сетью, а не на маркетинг кошелька. Schnorr живёт на Bitcoin и принимается в EVM-мире через account abstraction. Сети, которые его хорошо поддерживают, — это те, где SSP первым раскатит агрегированный multisig; везде ещё BIP48 + ECDSA остаются правильным и безопасным дефолтом.

Следующая статья этой серии, Social recovery vs multisig, смещает фокус с криптографии на операции: когда тянешься к multisig и когда social recovery выигрывает? Оба защищают от потери ключей; они отвечают на разные вопросы. Для быстрого освежения, какие устройства SSP использует сегодня и почему, Meet SSP Wallet остаётся отправной точкой.