Блокчейн/Уровень IV · Глубины протокола/4.1 Script/Урок 3
Мультиподпись
Кворум, баг и ключ, которого никогда не существовало
МатериалыОбозреватель блоков с возможностью декодирования скриптов (например, mempool.space или blockchain.com)Исходный код Bitcoin Core, в частности логика интерпретатора скриптов для OP_CHECKMULTISIGСпецификации BIP147 и BIP327
Любопытство
- Почему скрипт, требующий двух подписей, извлекает три элемента из стека?
- Как пустая строка байтов может быть правилом консенсуса, а не просто соглашением?
- Что меняется, когда десять ключей объединяются в одну подпись, неотличимую от подписи единственного подписавшего?
Исследование
- Скрипты мультиподписи требуют, чтобы как минимум m подписей прошли проверку по n указанным публичным ключам. В запирающем скрипте указываются m, n публичных ключей и n; OP_CHECKMULTISIG извлекает из стека n, n ключей, m, а затем m подписей, которые должны соответствовать ключам в указанном порядке. Если предоставлено меньше m действительных подписей, трата недействительна.
- Ошибка в коде исходной реализации приводит к тому, что OP_CHECKMULTISIG извлекает из стека на один элемент больше, чем требуется для подписей. Этот «фиктивный» (dummy) элемент игнорируется при криптографической проверке, но должен присутствовать; если его нет, стек исчерпывается, и транзакция не проходит. Первые пользователи ставили на это место OP_0 — практика, сохранявшаяся годами, поскольку ноды принимали в этой позиции любое значение.
- BIP147 (NULLDUMMY), активированный вместе с SegWit в августе 2017 года, превратил этот вектор изменяемости (malleability) в правило консенсуса. Теперь фиктивный элемент должен быть пустым массивом байтов. Любое непустое значение, даже один нулевой байт, приводит к ошибке скрипта. Это лишило возможности изменять идентификаторы транзакций подменой содержимого фиктивного элемента и сделало хеш транзакции стабильным для всех последующих подтверждений.
- Правила стандартности определяют, какие скрипты мультиподписи ноды ретранслируют. Согласно политике Bitcoin Core по умолчанию, «голые» выходы мультиподписи ограничены тремя ключами. В обёртке P2SH мультиподпись может использовать до 15 ключей (ограничение — 520 байт скрипта погашения); в P2WSH — до 20. Это различие позволяет сложным корпоративным казначейским схемам работать, не раздувая базовый уровень транзакций.
- Устаревшие схемы мультиподписи заменяют два более новых инструмента. MuSig2 (BIP327, 2023) — отдельный протокол на основе подписей Шнорра из Taproot — агрегирует несколько публичных ключей в один ключ и создаёт стандартную подпись Шнорра; в блокчейне такая трата неотличима от обычной траты Taproot с одним ключом. Tapscript, часть самого Taproot, добавляет OP_CHECKSIGADD, который позволяет проверять подписи последовательно — без ошибки с лишним извлечением из стека и без ограничения в 20 ключей, присущего устаревшим опкодам.
- Чтобы изучить эту механику, откройте обозреватель блоков и найдите «голую» мультиподписную транзакцию эпохи до SegWit. Посмотрите на scriptSig: он начинается с OP_0, за которым следуют подписи. Сравните его с тратой мультиподписи P2WSH, где witness содержит пустой элемент, подписи и witness-скрипт со списком ключей. Обратите внимание на разницу в числе байтов: она отражает стоимость размещения полного списка ключей в выходе, а не во входе.
Ключевые факты
- OP_CHECKMULTISIG извлекает из стека один лишний элемент из-за исторической ошибки «на единицу» (off-by-one).
- BIP147 (NULLDUMMY) предписывает, чтобы на уровне консенсуса этот фиктивный элемент представлял собой пустой массив байтов.
- Политика Bitcoin Core по умолчанию ограничивает «голые» выходы мультиподписи тремя публичными ключами; P2SH допускает до 15, а P2WSH — до 20.
- MuSig2 агрегирует несколько ключей в одну подпись, так что трата выглядит как обычная трата Taproot с одним ключом.
- OP_CHECKSIGADD в tapscript заменяет OP_CHECKMULTISIG и позволяет выполнять пороговые проверки без ошибки с лишним элементом.
- Активация SegWit (август 2017 года) включала BIP147, который перевёл правило NULLDUMMY из политики ретрансляции в консенсус.
Упражнение девять, шесть, три, один
9СобратьПеречислите 9 описанных схем мультиподписи, которые вам удастся найти (в кошельках, на биржах, в Lightning, в планах наследования), указав параметры m-of-n и используемый тип скрипта.
6СгруппироватьРаспределите эти 9 по 6 группам по форме в блокчейне: «голый» (bare) мультисиг, P2SH, SegWit, обёрнутый в P2SH, P2WSH, путь скрипта Taproot или путь ключа Taproot с агрегированными ключами.
3Выделить главноеСведите шесть групп к трём компромиссам между конфиденциальностью, стоимостью в байтах и гибкостью восстановления, присущим каждому способу реализации мультиподписи.
1КристаллизоватьНапишите одно предложение о том, почему пустая строка байтов стала постоянным правилом консенсуса, а не изменяемым параметром политики.
Проверка фактов
Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.