Taproot и Schnorr подписи

Представь, что ты отправляешь Bitcoin с кошелька, который защищён multisig 3-of-5. В старом Bitcoin каждый наблюдатель видит: это multisig, тут 5 участников, 3 подписали. Хуже того, ты платишь в 4 раза больше комиссии, чем за обычный перевод, потому что все 3 подписи и 5 ключей занимают место в блоке. А если у тебя сложный контракт с 10 условиями, но сработало одно, ты всё равно раскрываешь все 10. Taproot решил все три проблемы одним обновлением: multisig неотличим от обычного перевода, комиссия одинаковая, и никто не знает, какие ещё условия были у твоего кошелька.

• **Lightning Network** — cooperative close каналов теперь неотличим от обычных переводов, что затрудняет отслеживание Lightning-активности цепочными аналитиками
• **Корпоративные кошельки** — multisig 3-of-5 с MuSig2 экономит ~73% на комиссиях и не раскрывает структуру кошелька на блокчейне
• **Протокол Ordinals** — снятие лимита в 10K байт на скрипт в Tapscript позволило записывать NFT (images, video) прямо в Bitcoin-транзакции, создав рынок на 1B+

Клаус Шнорр: 30 лет от патента до Bitcoin

Немецкий математик Клаус Шнорр изобрёл свою схему подписей в 1989 году и запатентовал в 1991. Подпись была проще, быстрее и математически элегантнее ECDSA. Но патент заблокировал её использование - и когда Сатоши Накамото создавал Bitcoin в 2008-2009, Schnorr-подписи были недоступны. Пришлось использовать ECDSA. Патент Шнорра истёк в 2008 году - буквально в год создания Bitcoin. Но к тому моменту протокол был уже запущен. Потребовалось 12 лет работы разработчиков (Pieter Wuille, Jonas Nick, Tim Ruffing и др.), чтобы интегрировать Schnorr в Bitcoin через soft fork Taproot (BIP-340/341/342), активированный в ноябре 2021 года.

Taproot стал крупнейшим обновлением Bitcoin с момента SegWit (2017). Его активация по механизму Speedy Trial показала, что Bitcoin-сообщество способно принимать сложные технические изменения без раскола.

Предварительные знания

• Bitcoin Script: programmable money
• Digital Signatures: ECDSA and EdDSA

Schnorr-подписи: линейность меняет всё

Bitcoin изначально использовал **ECDSA** для цифровых подписей. Алгоритм надёжный, но с серьёзным ограничением: подписи нескольких участников **нельзя объединить** в одну. Multisig 3-of-5 требует 3 отдельных подписи в транзакции - это дорого и раскрывает структуру кошелька.

**Schnorr-подписи** (BIP-340) решают эту проблему благодаря математическому свойству - **линейности**. Если ECDSA-подписи - это замки, которые можно открыть только по одному, то Schnorr-подписи - это замки, которые можно **сплавить в один**.

Ключевое свойство линейности: Если Алиса подписала сообщение $m$ и получила подпись $s_A$, а Боб подписал то же сообщение и получил $s_B$, то **сумма подписей** $s_A + s_B$ является валидной подписью для **суммы публичных ключей** $P_A + P_B$.

**Key Aggregation (MuSig2)** - протокол, позволяющий нескольким участникам создать **единый публичный ключ** и **единую подпись**. Со стороны блокчейна транзакция выглядит так, будто её подписал один человек.

MuSig2 работает в **два раунда**: 1. Каждый участник генерирует **nonce** и делится им с остальными 2. Каждый вычисляет свою **частичную подпись**, и они складываются в итоговую Результат: одна подпись (64 байта) вместо N подписей - независимо от числа участников.

**Batch Verification** - ещё одно преимущество Schnorr. Нода может проверить **N подписей одновременно** быстрее, чем по отдельности. Для блока с 2000+ транзакций это даёт ускорение верификации примерно в **2.5 раза**.

**Почему Bitcoin перешёл на Schnorr именно с secp256k1?** Schnorr-подписи работают на той же эллиптической кривой secp256k1, что и ECDSA. Это значит, что существующие приватные ключи и адреса **остаются валидными** - не нужно генерировать новые пары ключей.

MAST: Merkle-деревья для скриптов

До Taproot сложные условия траты Bitcoin (multisig + timelock + hashlock) требовали раскрытия **всего скрипта** при трате. Даже если из 10 возможных условий сработало одно - все 10 попадают в блокчейн. Это дорого и уничтожает приватность.

**MAST** (Merkelized Alternative Script Trees) решает обе проблемы: каждое условие траты помещается в **лист Merkle-дерева**. При трате нужно раскрыть только **одну ветку** - используемый скрипт и Merkle-доказательство. Остальные условия остаются скрытыми.

**Экономия масштабируется логарифмически.** Для скрипта с 1000 условиями (например, сложная DAO-казначейка): - Без MAST: раскрыть все 1000 скриптов - С MAST: раскрыть 1 скрипт + ~10 хешей ($\log_2 1000 \approx 10$)

**MAST + Schnorr = двойная приватность.** Если участники могут договориться (cooperative case), они используют **key path** - агрегированную Schnorr-подпись. MAST-дерево вообще не раскрывается. Только если возникает спор, транзакция переходит в **script path**, раскрывая одну ветку.

Tapscript: Bitcoin Script нового поколения

Оригинальный Bitcoin Script, заложенный Сатоши в 2009 году, имел жёсткие ограничения: максимум **10 000 байт** на скрипт, максимум **201 opcode** за выполнение, а multisig через **OP_CHECKMULTISIG** проверял подписи по одной - медленно и с неприятным побочным эффектом (off-by-one bug, съедавший лишний элемент стека).

**Tapscript** (BIP-342) - обновлённая версия Bitcoin Script, работающая внутри Taproot script path. Она не ломает совместимость (soft fork), но убирает устаревшие ограничения и добавляет новые возможности.

**OP_SUCCESS** - механизм для будущих обновлений. В Tapscript зарезервированы opcodes (OP_SUCCESS80-OP_SUCCESS254), которые сейчас делают скрипт **автоматически успешным**. Когда сообщество захочет добавить новый opcode (например, OP_VAULT для covenant), достаточно **soft fork**: старые ноды по-прежнему считают скрипт валидным, а новые - проверяют новую логику.

**Снятие лимита в 10K байт** открыло дорогу неожиданным применениям. В 2023 году протокол **Ordinals** использовал это для записи изображений, видео и даже полной копии игры DOOM прямо в Bitcoin-транзакции. Одна NFT-транзакция заняла почти **4 МБ** - целый блок.

P2TR: все транзакции неотличимы

До Taproot тип адреса **выдавал** информацию о владельце. P2PKH (начинается с `1`) - простой кошелёк. P2SH (начинается с `3`) - скорее всего multisig или Lightning. P2WSH (`bc1q`) - SegWit скрипт. Наблюдатель мог классифицировать кошельки ещё до анализа транзакций.

**P2TR** (Pay-to-Taproot, адреса `bc1p`) объединяет все типы транзакций в один формат. Внутри каждого P2TR-выхода скрыта **tweaked public key** - точка на кривой, которая может быть потрачена двумя способами:

**Главный прорыв приватности:** на блокчейне все P2TR-транзакции выглядят одинаково - `bc1p`-адрес и Schnorr-подпись. Невозможно отличить: - Обычный перевод одного человека - Multisig 5-of-7 корпоративного кошелька - Открытие/закрытие Lightning-канала - Выполнение сложного смарт-контракта - Наследование по timelock

**Tweaked key** - математический трюк, связывающий key path и script path. Внутренний ключ $P$ (aggregated Schnorr key) «подкручивается» (tweak) корнем Merkle-дерева: $Q = P + \text{hash}(P \| \text{merkle\_root}) \cdot G$ Это доказывает, что MAST-дерево «закоммичено» в выход, но раскрывается только при необходимости. Если MAST-дерева нет (simple single-sig), tweak всё равно применяется с пустым merkle_root.

**Taproot не гарантирует полную анонимность.** Если вы отправляете с P2TR-адреса на старый P2PKH-адрес - это создаёт «переход типов», который аналитик может использовать. Максимальная приватность достигается, когда **обе стороны** используют P2TR. По данным на 2024 год, около **15%** всех Bitcoin-выходов используют P2TR - процент растёт, но медленно.

Итоги

• **Schnorr-подписи** (BIP-340) обладают свойством линейности: подписи нескольких участников складываются в одну через протокол MuSig2, а batch verification ускоряет проверку блоков в ~2.5 раза
• **MAST** (Merkelized Alternative Script Trees) помещает условия траты в листья Merkle-дерева — при трате раскрывается только используемая ветка, а остальные ($\log_2 N$ хешей вместо $N$ скриптов) остаются скрытыми
• **Tapscript** (BIP-342) убирает устаревшие ограничения Bitcoin Script (лимиты 10K байт и 201 opcode), заменяет OP_CHECKMULTISIG на batch-friendly OP_CHECKSIGADD, и через OP_SUCCESS позволяет добавлять новые opcodes через soft fork
• **P2TR** (Pay-to-Taproot) делает все типы транзакций неразличимыми: multisig 5-of-7, Lightning-канал и обычный перевод используют один формат (`bc1p`-адрес + Schnorr-подпись). Помнишь multisig, который раскрывал 5 ключей и платил в 4 раза больше комиссии? Теперь он занимает столько же места, сколько обычный перевод, и никто не знает, сколько людей его подписали

Связанные темы

Taproot связывает криптографические примитивы с практическими протоколами Bitcoin:

• Цифровые подписи: ECDSA и EdDSA — Schnorr-подписи решают проблемы ECDSA (нелинейность, медленная batch verification), сохраняя ту же кривую secp256k1
• Bitcoin Script — Tapscript - эволюция Bitcoin Script: те же opcodes, но без лимитов и с новым OP_CHECKSIGADD вместо багового OP_CHECKMULTISIG
• Lightning Network — Taproot делает Lightning-каналы приватными: cooperative close через key path неотличим от обычного перевода

Вопросы для размышления

• Schnorr + MuSig2 позволяют N участникам создать одну подпись. Но что если один из участников отказывается подписывать (griefing attack)? Как MuSig2 справляется с этим, и почему для threshold-подписей (k-of-n) нужен отдельный протокол FROST?
• Ordinals используют снятие лимита в 10K байт для записи изображений в Bitcoin. Критики считают это «спамом», сторонники — инновацией. Как бы ты спроектировал лимиты Tapscript, чтобы разрешить сложные смарт-контракты, но ограничить запись произвольных данных?
• P2TR-адреса составляют лишь ~15% выходов Bitcoin (2024). Пока не все кошельки мигрировали, транзакции с P2TR-адресов парадоксально менее приватны, потому что выделяются. При какой доле адресов Taproot начинает реально защищать приватность, и как ускорить миграцию?

Связанные уроки

• crypto-28-digital-signatures